Fieldbus & Device Networks

What do industrial fieldbus integration services cover?

Industrial fieldbus integration services port and bring up a device's communication stack on your hardware.

This is typically for device manufacturers, machine builders and instrument makers. We port and bring up CANopen, CAN FD and J1939, Modbus RTU and TCP, IO-Link, AS-i and PROFIBUS DP on your hardware, author the device description files that have to ship with them, and run the conformance test cases in-house before you book the lab. As an example, our team has delivered PROFIBUS PA interfaces for process pressure transmitters, carried PROFIBUS PA and DP segments forward unchanged through a controller platform replacement, and built CAN node software for marine and off-highway vehicle systems that transfers directly to J1939 and ISOBUS work. The engagement usually falls into one or more of these shapes:

• A device stack is ported onto your MCU, SoC or FPGA and handed over with its build environment, brought up against real bus traffic and not a simulator.
• The master side is built, where your product drives a segment instead of sitting on one. Fieldbus master development covers the mixed case too, a device that is a slave upward and a master downward.
• Configuration and compliance files are produced. IODD device description development for IO-Link, EDD for process instruments, GSD for PROFIBUS DP, and FDT/DTM device driver development where a plant’s frame application is the way in.
• A PC-side configuration and diagnostic tool is created, the application that commissions, parameterises and diagnoses your device on the bus.
• The network and controller are chosen. Fieldbus controller selection consulting that ends in a prototype on your hardware rather than a recommendation slide.
• Your engineers are trained on the bus you have chosen, with the first device brought up alongside them.

We do not commission machines or plants. The communication layer inside your product is ours to build and test, and we do that with your engineers, onshore while integration and test are running and remotely afterwards.

Do I still need to consider fieldbus for a new product?

Yes, often: the constraints that produced fieldbus have not gone away.

• The constraints still hold. A device network is chosen against device count, cable budget, power envelope, connector cost and what the customer’s installed base already runs. On those terms a two-wire IO-Link drop or a CANopen segment is still the cheapest way to reach a sensor, and real-time Ethernet sits above them, not in place of them.
• Most machines run more than one. They will keep doing so. Our work is usually adding one network to a product that already speaks another, so the effort goes into what the second network does to the timing, the power budget and the data model of a device that was designed around the first.

What does a fieldbus device stack port involve?

A port gets a protocol running correctly on a particular part.

The stack has to fit the memory the part actually has. The timing has to hold when the bus is busy, not only when it is idle. The object dictionary or process image has to match what the master expects. And the device has to behave when a segment is misconfigured, because in the field it will be. It is the same discipline our team applies on the Ethernet side, where communication stacks have been taken through conformance testing on several silicon families. Both ask one question: does this device behave correctly as a participant, under load, on a network the customer controls.

What do device description files decide?

A description file decides whether an engineer in the field can use your device without calling you.

An IODD, EDD or GSD is what a configuration tool reads to learn your parameters, their units, their permitted ranges and how to present them. Get it wrong and the device works while being unusable:

• Parameters that display without units.
• Ranges that let the controller write a setting at start-up that the firmware rejects.
• A diagnostic code the tool cannot name.

As an example, for IO-Link the description file is the manufacturer’s responsibility. The consortium publishes the editor and the IODD-Checker that validates the result, and a manufacturer’s declaration of conformity ships with the device. We author against the tools that will read the file, then validate on the frame applications a customer actually runs. FDT/DTM device driver development applies the same discipline to a frame application instead of a description file.

What does fieldbus conformance pre-testing save?

Pre-testing saves a booking, and usually a launch date.

The consortiums say so themselves. CAN in Automation maintains the official certification laboratory for CANopen conformance approval, and its own guidance is to send pre-tested devices in. IO-Link, PI and the other bodies work the same way, with a checker or a test tool available to the manufacturer long before the formal attempt. We run your device against those test cases in-house, on real bus traffic, so problems surface during pre-testing and not at the formal attempt. The certificate is issued by the consortium’s accredited lab, never by us.

What to consider for a device that speaks to two networks?

Two networks on one device is an architecture decision before it is a stack decision.

• Shared state. A device on two networks has to resolve shared state that a single-network device never faces: two masters with different ideas about the same object, or two cycles that were never designed to coexist. Deciding which side owns a parameter, and what the other side sees when it changes, is part of the design step.
• Where it becomes a gateway. Where the answer is a translating device instead of a dual-stack one, the work moves to device and network integration, which covers architectures spanning several devices and networks rather than one device’s protocol layer.

Who develops the communication stack for a process transmitter?

We do, and it is the protocol integration part of any transmitter project.

That is process transmitter device stack development, backed by the delivered PROFIBUS PA example above. A transmitter project splits three ways, and the split decides which of the three you need:

Most transmitter projects need at least two of the three, and the scope follows from which parts those are.