Protocol Migration

What do fieldbus to Ethernet migration services cover?

Fieldbus to Ethernet migration services migrate a device from a legacy network onto industrial Ethernet.

This is typically for device manufacturers, machine builders and instrument makers. We migrate a device from a legacy network, CANopen, PROFIBUS DP, a serial link or HART, onto POWERLINK, EtherCAT, PROFINET, Modbus TCP or Ethernet-APL, and we carry the application logic across without rewriting it. The engagement usually falls into one or more of these shapes:

• An assessment before anyone commits. What changes, what carries, and what the new network costs in cycle time, node count and payload, ending in a prototype running on your hardware.
• One product, one new network. The whole migration of a single device or controller, from stack replacement through to acceptance at production speed.
• The carry-across only, where you already have the new platform and need the accumulated logic ported onto it correctly.
• A dual-running period, old and new coexisting while the installed base ships, with a planned cutover in place of a flag day.
• Re-testing on the new network. Conformance pre-testing and acceptance for a migration somebody else performed.
• Your engineers taken through it. Training runs alongside the first product’s migration, with support behind your team as later products move.

We move the product and the devices around it. We do not run floor migrations or commission machines. Our engineers work alongside yours through integration and acceptance, onshore for that phase and remotely after it.

What changes in a migration, and what carries across?

The stack, the driver and the timing budget change; the application logic and the data model carry across.

Four things change, and only the first is the protocol:

1. The stack changes.
2. The driver beneath it changes.
3. The application logic above it is ported, not rewritten.
4. The timing budget the whole product was designed around moves.

The timing budget is the one that surprises programmes. A new network does not simply run faster; it changes the relationship between cycle time, node count and payload per cycle, and a device that was comfortable at one point on that curve can be marginal at another. Those three are specified figures for each protocol, so the assessment starts there and then measures your actual device against it.

What usually carries across untouched is your accumulated engineering investment: the processing logic, the device data model, the calibration and parameter sets, and the meaning of your diagnostics.

Which protocol migrations do you do?

We migrate CANopen, PROFIBUS DP, serial and HART devices onto POWERLINK, EtherCAT, PROFINET, Modbus TCP and Ethernet-APL.

Six pairs come up repeatedly, and each has its own character:

• CANopen to POWERLINK or EtherCAT. The most common request, driven by node count and cycle time. The object dictionary is the part that carries across most cleanly; the timing assumptions buried in the application are the part that usually does not. As an example, our team has taken a device network from CANopen to POWERLINK and held a 2 ms cycle on the result.
• POWERLINK to EtherCAT. Rarely about capability and usually about a customer’s installed base or a procurement document. The two are close enough that the work concentrates on the process image and the master relationship.
• PROFIBUS DP to PROFINET. The best-supported path in the industry, because both live under the same organisation and the migration was planned for. The GSD becomes a GSDML, and the device model largely survives.
• Serial to Modbus TCP. The register map carries across almost unchanged, which makes this look like the easy one. The difficulty arrives later, when the application meets a TCP link that fails differently from an RS-485 one. A serial timeout and a dropped TCP socket are different failure events, and application code written for one does not handle the other correctly.
• HART to Ethernet-APL. The instrument migration, and the one where the physical layer is the point: two wires carrying power and data into a hazardous area under the 2-WISE intrinsic-safety concept, with the digital data HART already carried finally arriving at full rate instead of through a 4-20 mA loop.

Can the existing hardware carry the new stack?

Often it cannot, and that is the first thing the assessment establishes.

Industrial Ethernet asks for more than a fieldbus did: a MAC and usually two ports with an integrated switch so the device can sit in a line topology, more flash and RAM for the stack, and for the isochronous protocols, silicon with protocol acceleration or an FPGA behind it. An MCU chosen years ago for a CANopen node rarely has any of that. So a fieldbus to Ethernet migration is frequently a board change as well, and the assessment is where that gets decided, before any hardware is committed to. Where the hardware is being replaced anyway, the two jobs are cheaper together: embedded systems covers the new board, and obsolescence management covers the case where a discontinued part forced the change in the first place.

Should I migrate the device, or put a proxy in front of it?

Sometimes the proxy is the right answer, and we will say so.

PROFINET defines the proxy in its own specification: a device on the Ethernet network that represents a whole PROFIBUS segment behind it, so existing slaves keep running unmodified. Gateways do the equivalent job for other pairs.

• What it buys. Nothing is re-certified, nothing is re-tested, and a working segment stays working.
• What it costs. It carries process data reliably and often carries little else. Diagnostics, parameterisation and device-specific services frequently do not survive the translation, so the engineer at the controller loses visibility of the device behind it. It adds a translation hop the original design did not have, and it leaves the obsolete network in the field, where the parts still have to be bought and the skills still have to be kept.

The practical test is what you are selling. A machine builder keeping a plant running chooses the proxy. A device manufacturer whose customers now specify Ethernet gets no benefit from one, because their product is still a PROFIBUS product. If the proxy is the answer, the work belongs to device and network integration.

What does a migration do to certification?

A migration starts certification again.

A device that was certified on PROFIBUS DP is not certified on PROFINET, and the test suite it has to pass belongs to the new network, not the old one. Migration budgets commonly miss this, and it surfaces late, after the schedule is already public. We run the new network’s conformance test cases in-house before the lab is booked, on the migrated device itself. The certificate is issued by the accredited lab, as it was the first time.

When is a migration the wrong answer?

A migration is the wrong answer when the network is not the constraint.

• A part went end-of-life. If a product is being forced onto new hardware because a controller, processor or FPGA went end-of-life, that is a platform problem and it belongs on obsolescence management, where the network and the logic both stay put.
• Several devices have to interoperate. If the real requirement is that several devices on different networks must interoperate, that is device and network integration and nothing needs migrating at all.

We say so at the assessment stage, because the expensive version of this mistake is discovering it after the stack has been replaced.

How do you keep the installed base supported during a migration?

We do not require the installed base to move.

A fleet in the field is still generating revenue and still under support obligation, so a migration that strands it has failed regardless of how well the new variant works. The practical answer is a period where both variants are built and supported from one codebase, with the network layer isolated well enough that the difference stays contained instead of spreading through the application. The isolation has two benefits: it makes the current migration containable, and it makes the next one cheaper, because vendor module lifecycle schedules are often out of your control.