Industrial IoT Development Services

OPC-UA (OPC Unified Architecture, the industrial protocol that replaced OPC Classic and is now the standard for modern SCADA and industrial controller connectivity) client integration for SCADA platforms including Wonderware InTouch/AVEVA System Platform, Ignition by Inductive Automation, Siemens WinCC, Rockwell FactoryTalk, and GE iFIX. The integration approach uses a dedicated OPC-UA client deployed as a service on the plant network DMZ: the client browses the OPC-UA server's address space on first connection to enumerate available nodes and tags, maps the relevant tags to a local data model, and subscribes to monitored item changes with a configurable publishing interval (100ms for high-frequency vibration data, 1-second for temperature and pressure, 30-second for slow process variables). Data change notifications are received via the OPC-UA subscription mechanism -- meaning the system receives updates only when values change beyond a configurable deadband, which dramatically reduces network traffic and processing load compared to polling every tag on a fixed interval. OPC-UA secure channel configured with X.509 certificate-based authentication (Basic256Sha256 security policy) and message signing and encryption enabled -- the OT security requirement that prevents man-in-the-middle attacks on industrial networks without requiring changes to the SCADA server configuration. Historical data read using the OPC-UA Historical Access service for backfilling periods where the cloud connection was unavailable. The integration is deployed as a read-only consumer of the OPC-UA server -- it does not write setpoints or control commands, and it requires no changes to SCADA configuration, control logic, or PLC programs, which is the non-negotiable requirement for OT teams who cannot accept risk to production-critical systems from an IT-initiated integration project.

Modbus TCP polling for network-connected legacy PLCs, VFDs (variable frequency drives), energy meters, and process controllers where OPC-UA is not available -- which describes the majority of equipment installed before 2015 in most industrial environments. The Modbus collector polls the register map documented for each device (function code FC03 for holding registers, FC01 for coils, FC04 for input registers) at a configurable scan rate from 250ms for fast process variables to 60 seconds for slowly-changing environmental data. Modbus RTU over RS-485 handled via USB-to-RS-485 adapters or serial-to-TCP converters (Moxa NPort, Advantech EKI series) for equipment on multi-drop serial networks where each device on the bus has a unique Modbus slave address. Register map development when vendor documentation is unavailable: we use manual interrogation with Modbus tools (ModScan, QModMaster) and OEM documentation requests to establish the register map before development begins, adding several days to the scoping phase but preventing the scenario where the integration is built on an assumed register map that turns out to be wrong. Protocol gateway setup for proprietary industrial protocols that don't expose Modbus or OPC-UA: Kepware KEPServerEX (supports 150+ industrial drivers including Allen-Bradley EtherNet/IP, Siemens S7, Mitsubishi MELSEC, Omron FINS) deployed on an industrial edge PC translates proprietary protocols to OPC-UA, which the cloud platform then reads via the standard OPC-UA client. Hardware data loggers (Datapaq, IOtech, Yokogawa) deployed for equipment with no digital communication interface, logging to local SD storage with scheduled USB extraction or cellular upload. The protocol selection for each integration point is documented in the technical assessment before any development begins so the plant's OT team can review and approve the approach before work starts.

Sensor data pipelines structured specifically to support predictive maintenance models -- which require different data handling than monitoring dashboards because the signal of interest (an early bearing defect, a developing insulation fault) is buried in high-frequency raw data that must be processed before a model can interpret it. For rotating equipment health monitoring, accelerometers capture vibration data at 1kHz-25kHz sampling rates; the raw time-series is processed at the edge into frequency domain features (FFT spectrum, RMS amplitude by frequency band, envelope spectrum for bearing defect frequencies) before transmission upstream, reducing data volume by 99% while preserving the diagnostic signal. Temperature trend monitoring uses multi-point PT100 or thermocouple arrays on motors, gearboxes, and bearings; baseline temperature profiles established per operating condition (load, speed, ambient temperature) so deviations from the expected operating-point temperature are detected rather than threshold breaches on an absolute value. Pressure and flow deviation detection for hydraulic and pneumatic systems: statistical process control (Western Electric rules applied to the rolling 100-sample window) flags deviations from steady-state before they breach fixed alarm limits. Energy consumption anomaly detection via power meter data (kW per cycle or per unit produced): a 7% unexplained increase in motor power draw is an early indicator of mechanical drag or bearing friction that will progress to failure if not investigated. Feature engineering pipeline: raw sensor data cleaned (outlier removal, gap filling for communication interruptions), aggregated into statistical features (mean, standard deviation, kurtosis, skewness, peak-to-peak per time window), enriched with operational context (production rate, product type, shift) before feeding the predictive model. CMMS integration (IBM Maximo, SAP PM, eMaint, Limble) via REST API: when the model output exceeds the configured alert threshold, a work order is automatically created with the equipment tag, fault description, recommended inspection action, and sensor readings at the time of alert pre-populated.

Real-time production dashboards built around OEE (Overall Equipment Effectiveness -- the product of Availability, Performance, and Quality -- the manufacturing KPI that combines all three loss categories into a single utilisation metric) calculated from live equipment data rather than end-of-shift manual entry. Availability calculated from actual machine state signals (running, idle, stopped, faulted) read directly from PLC outputs rather than operator-reported downtime; the calculation is per machine and per production line with drill-down to the individual downtime event record showing start time, end time, and stop reason (planned maintenance, unplanned fault, changeover, material shortage). Performance calculated from actual cycle time vs ideal cycle time: the machine counter reads pulses per completed cycle; when actual cycle time exceeds the rated speed by more than a configurable threshold, the performance loss is recorded as a speed loss event. Quality calculated from good units produced vs total units produced, with defect data fed from downstream inspection systems or manual entry on a shift report tablet. OEE displayed at machine level, line level, and site level so supervisors see both the headline number and where the losses are concentrated. Production count vs target displayed in real time with a projected end-of-shift count based on current OEE and remaining time -- giving the supervisor a predictive view of whether the shift target will be met with enough lead time to intervene. Downtime categorisation using a configurable reason code tree configured to your plant's terminology (not generic categories borrowed from a software template). Shift performance reports generated automatically from equipment data at shift end: shift OEE, downtime events with durations and causes, production count vs target, and top 3 downtime causes for the shift -- delivered to the outgoing supervisor's email or displayed on the shift handover screen before the debrief meeting.

Bidirectional integration between the IoT platform and the MES/ERP layer using the standard integration interfaces each system exposes: SAP via RFC/BAPI calls and the SAP Manufacturing Integration and Intelligence (MII) middleware; Oracle EBS/Cloud Manufacturing via REST APIs; Epicor/Infor via their respective REST or SOAP APIs; Microsoft Dynamics 365 via the Dataverse API; and standalone MES platforms (Rockwell FactoryTalk Production Centre, AVEVA ME, Tulip) via their published integration APIs. Data flows in both directions to close the OT-IT loop: production order data from ERP (order number, product code, target quantity, required start/end time) flows into the IoT platform to provide context for equipment readings -- so a machine cycle count is recorded against the specific production order it was running, not as a generic count that requires manual reconciliation at shift end. Production actuals (actual quantity produced, actual start/end time, downtime events with categories) flow back to ERP to update production order progress without a planner manually entering actuals from a paper shift report. The data entry that currently happens at the end of each shift is replaced by automatic ERP update from equipment data, saving 30-60 minutes per shift of admin work while also being more accurate than manually-entered operator reports. Quality integration: measurement data from CMMs (coordinate measuring machines), vision inspection systems, and manual quality check records fed into the ERP quality management module (SAP QM, Oracle Quality) to support certificate of conformance generation, non-conformance records, and supplier qualification data without re-keying. CMMS work order creation from IoT alert: when a predictive maintenance alert fires or an unplanned downtime event is recorded, a work order is created in the CMMS (IBM Maximo, SAP PM, or the CMMS in use) with the equipment asset number, fault description, sensor readings at time of alert, and suggested corrective action -- the maintenance team sees the context, not just a ticket number.

Edge computing architecture for plant floor environments where cloud latency is unacceptable for real-time alerting, connectivity to the internet is unreliable or deliberately restricted, or data sovereignty requirements mandate that raw production data does not leave the site network. Hardware selection guided by the operational environment: Advantech UNO industrial PCs (fanless, -20°C to 60°C operating range, DIN rail mountable) for clean industrial environments; Siemens SIMATIC IPC for integration with existing Siemens automation infrastructure; NVIDIA Jetson AGX Orin for edge deployments requiring GPU inference for computer vision or high-frequency vibration analysis. Edge software stack: data collection service polling OPC-UA and Modbus sources and publishing to a local MQTT broker (Mosquitto or HiveMQ Edge); stream processing using Apache Kafka on lightweight edge hardware (Confluent Platform Edge) or Apache NiFi for data routing and transformation; local time-series database (InfluxDB or TimescaleDB) for buffering data during cloud outages. Local operator interface: a web-based HMI served from the edge device accessible on plant floor displays and supervisors' tablets via the local network -- showing real-time machine status, active alerts, and shift production metrics without cloud dependency. Store-and-forward architecture: the edge device buffers all collected data locally; when the WAN connection to cloud systems is available, data is forwarded in chronological order with no loss; if the connection drops and recovers, the buffer is transmitted before switching to real-time mode. The edge device continues operating and alerting independently during cloud outages -- critical alerts (machine fault, safety threshold breach) are delivered to local displays and via local network notifications without requiring connectivity. Power and network resilience: UPS-backed edge hardware with a configurable graceful shutdown threshold to prevent data loss during power interruptions; dual-NIC configuration for independent OT and IT network connections maintaining the air gap between production network and business network.