Device & Network Integration

What do device network integration services cover?

Device network integration services cover the gateways, translation layers and tests that make several devices behave as one system.

This is meant for machine builders, device manufacturers and system integrators. As an example, our team has delivered gateway hardware holding a 2 ms cycle across eighteen units on one machine, and has demonstrated Sercos III interoperating with OPC UA over TSN. The engagement usually falls into one or more of these shapes:

• A gateway that does not exist yet. Modbus CANopen gateway integration, or any other pair where the off-the-shelf box maps the registers but not the behaviour.
• One box, several stacks. Multi-protocol industrial gateway development where two or more protocols share a processor and hold incompatible ideas about when they get it.
• Analogue and serial devices brought forward. 4-20 mA sensor to fieldbus integration, RS-485 serial device integration, and HART device data integration where the digital data already exists and never arrives anywhere useful.
• Interoperability testing. Two vendors’ devices run against each other properly, before a commissioning window discovers the problem.
• Your device inside someone else’s architecture. Device integration and test, with our engineers alongside yours during the phase where it matters.
• An edge device at the boundary. Industrial edge device development in its southbound sense, a box that collects and normalises from the device side.

We do not commission plants, floors or machines. The translation layer, the mapping and the test rig inside your product or your machine are ours to build, and we integrate and test them with your engineers, onshore while that phase is running and remotely afterwards.

Two boundaries, because two of our pages sit close to this one. Against real-time Ethernet: that page is one device’s protocol layer, this one is the architecture across several. Against industrial IoT and edge integration: that page runs northbound, data becoming information for MES, ERP and cloud, while this one runs southbound, protocol to protocol, toward the devices.

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

A catalogue gateway fits more often than buyers expect, and we evaluate that with you during design.

Specifying a catalogue part is a legitimate outcome of that call, and it is cheaper than anything we could build. The same question for a northbound gateway, one publishing to MES, ERP or cloud, is answered on industrial IoT and edge integration, where the catalogue is different and so is the test.

What are the common pitfalls in gateway development?

Data translation is typically straightforward, while timing, state and failure are the critical parts.

• Timing. Two networks rarely share a cycle, so a gateway that samples one side at the wrong moment produces data where every value is correct and the set of them describes a moment that never existed.
• State. Most protocols carry more than values, and mapping the values while dropping the session, the device state and the parameterisation gives you a gateway that passes bench testing and then loses synchronisation once it runs continuously.
• Failure. The default behaviour of a bad gateway is to keep publishing the last good value after the device behind it has gone. A stale reading presented as a live one is worse than no reading at all, and it passes every test that only checks whether a value arrived. We treat that as a design requirement and not a diagnostic extra.

How do you test interoperability without the customer’s plant?

We reproduce on the bench what the plant will do, and write down in the test plan what it cannot.

Interoperability testing industrial protocols means running two vendors’ devices against each other on real hardware, never against a simulator. A simulator only reproduces the behaviour its author already knew about, and interoperability failures are usually behaviour nobody documented.

Where a customer’s exact configuration cannot be reproduced, the gap is written down rather than assumed away. It is stated as a risk with a named test plan for the integration window, and we say which parts are verified and which are assumed before that window opens.

Can several off-the-shelf modules be replaced by one device?

Yes, one purpose-built device usually replaces them, and the saving compounds across the machine's service life.

• What a mixed cabinet carries. Four vendors’ IO modules, a serial converter and a protocol gateway mean four supply chains, four end-of-life exposures, four sets of firmware, and a commissioning procedure that has to account for all of them.
• What one purpose-built device removes. Most of the above, once the interfaces are the ones the machine actually uses instead of the ones the catalogue happened to offer.
• Which parts we do. The gateway and network side of the consolidation is this page; the device itself, board, enclosure and firmware, is embedded systems. The two are usually scoped together.

How do you integrate instruments that are already digital?

We read the digital data the loop already carries and patch it onto the same data network backbone.

For example, HART has carried digital diagnostics over the 4-20 mA loop for decades, and in most plants that data is never read, because reading it needed a handheld and a person standing next to the instrument. Bringing it onto a network is a small piece of engineering relative to the diagnostic value it unlocks, and it pairs naturally with the two-wire Ethernet path on protocol migration when the loop itself is being replaced.