Industrial IoT & Edge Integration

What does industrial IoT and edge integration cover?

Industrial IoT and edge integration covers everything between a machine's control layer and the business systems that consume it.

That means collection, normalisation, a data model worth consuming, transport northbound, and the security and compliance posture that lets any of it leave the plant. There are three entry points into that work. Brownfield IIoT retrofit engineering on lines that cannot stop. Greenfield edge integration on products being designed now. And a CRA compliance audit for industrial devices, which become regulated products the moment they are connected. This page runs northbound, data becoming information for MES, ERP and cloud; device and network integration runs southbound, protocol to protocol, between devices. Our team has built OPC UA to MQTT connectors for a remote-service platform on agricultural machinery, integrated OPC UA into Azure, delivered Node-RED modules into a customer’s cloud, and built a central gateway that lets any remote ERP pull live data from several machines over OPC UA, in place of the customer’s legacy MQTT bridge. The engagement is usually one of these shapes:

• An edge gateway or edge device. Edge gateway development and industrial edge device development in its northbound sense, thin or thick depending on where the processing belongs.
• A bridge between two data worlds. OPC UA to MQTT bridge development, OPC UA to HTTP REST bridge work, or a DDS to OPC UA gateway.
• Getting an installed line to talk. Industrial network gateway retrofit and brownfield asset connectivity, without controller replacement.
• The enterprise hop. MES ERP OT integration edge gateway work, and the OT/IT convergence design around it.
• Cloud telemetry and command. Machine-to-cloud integration, device-to-cloud telemetry and cloud-to-device command and control.
• An audit. Industrial device security audit against IEC 62443, and CRA readiness on a product that is already shipping.

An installed estate has to give up its data without being replaced. A new product has to be born connected and compliant. Or an existing connected product has to be audited against obligations that arrived after it shipped.

We do not commission the plant. We build a proof of concept, turn it into a deployable solution, and hand it to the commissioning party, with our engineers working alongside yours through integration and test.

What does the Cyber Resilience Act require of a connected product?

The CRA requires a secure update path, vulnerability handling and a generated SBOM, for the product's whole supported life.

Regulation (EU) 2024/2847 has applied vulnerability and incident reporting duties since 11 September 2026, with full enforcement from 11 December 2027, and it covers products with digital elements placed on the EU market. Each of the three has to hold in the field: the update path on units already deployed, the vulnerability process with somebody behind it, and the bill of materials generated rather than hand-written.

This sits on the IIoT page, not a compliance page, because connecting a machine is what pulls the obligation onto it. A CRA compliance audit for industrial devices is therefore usually commissioned at the same moment as the connectivity work, and it is far cheaper to build the update path during that project than to retrofit one onto a deployed fleet. We audit and we remediate. We do not certify. A notified body is needed for important class II and critical products, and for important class I products when harmonised standards are not applied. Critical products may instead need a European cybersecurity certificate.

How does brownfield IIoT retrofit engineering work on a line that cannot stop?

The retrofit runs alongside the controllers and never in the control path, so the line keeps running.

It is additive: OPC UA connectivity for existing production lines is built alongside the controllers, not through them, reading what is already there and publishing it northbound. Nothing about the machine’s control behaviour changes, which is what makes the change schedulable in a maintenance window instead of a shutdown. Where a data path already exists, such as a legacy MQTT bridge, it is replaced in stages: the new path reads alongside it, runs in parallel while the old path stays primary, and switches over in one planned window with the old path kept as a fallback.

• The installed estate. An installed estate is usually multi-vendor, multi-generation and undocumented, so multi-vendor machine data integration starts with finding out what is actually on the floor. Where a controller cannot expose what is needed, an edge device on the southbound side collects it at the device level instead.
• A unified namespace. Where the goal is unifying the data and not merely connecting it, a unified namespace gives it one consistent structure across sites. Getting that structure right is modelling work first and infrastructure work second, and it borrows directly from OPC UA information modelling.

What changes on a greenfield build?

The economics reverse: designing the data model, security posture and update path in costs a fraction of retrofitting them.

The data model, the security posture and the update path are one design conversation, not three, because each constrains the others. What a device reports shapes what a secure update has to touch, and both shape what evidence a CRA audit will later ask for.

Greenfield designs are routinely under-invested here, on the assumption that connectivity can be added at the end. It can, but retrofitting it costs substantially more, particularly once a CRA obligation attaches to a fleet that has no update mechanism.

When is an off-the-shelf edge gateway the right answer?

A catalogue gateway fits when the protocol pair is standard and nothing about the data model has to be designed.

Vendors including Hilscher and HMS Networks (Anybus) sell edge gateways covering the common fieldbus-to-MQTT and fieldbus-to-OPC UA combinations, and for a single machine on a well-known protocol a catalogue part is usually the right call and often the cost-effective one. Specifying one is a legitimate outcome of an assessment, and we will say so before any design work starts. Where cost is the deciding factor, a software-only connector on existing hardware is a third option and is frequently cheaper than either. Custom engineering earns its cost when one of three things is true:

• The combination is not one anybody sells.
• The gateway has to sit inside your product with your service story behind it, instead of beside it in a cabinet as a third-party part number.
• The data model has to be designed for the consumer rather than generated from the controller’s default tags.

The equivalent question on the southbound side, protocol to protocol between devices, is answered on device and network integration.

Where is the handoff boundary between edge and cloud?

The boundary is placed on latency, on bandwidth, and on where trust has to stop.

Thin edge thick edge architecture is driven by those three factors, not picked as a product category. A thin edge collects and transports, and the analysis happens in the cloud. A thick edge runs the analysis locally and sends the conclusions. Most real systems sit between the two and move along that range over their service life, which is why we treat it as a cloud-edge continuum instead of two fixed places.

The pattern we build most often is the plain one: collect at the machine, normalise at the edge, buffer locally so a link outage costs no data, and publish device-to-cloud on a data model designed for the consumer, not the raw output the sensors happen to produce. The command path back, cloud-to-device command and control, gets more design attention than the telemetry path, because a command changes the state of a machine while a reading does not.