Why software beats ASICs in fieldbus device deployment: embedded.com

Why software beats ASICs in fieldbus device deployment

Hardware implementation of Fieldbus has drawbacks. Software stacks running on the microcontroller can be a simpler alternative.

The conventional approach to making industrial devices Fieldbus compatible using hardware modules has many drawbacks. Now, the development of software stacks running on the embedded device microcontroller can offer a simpler and more flexible solution.

Industrial sensors are used in factories to measure physical quantities like temperature, pressure, light, and the level of liquids kept in storage vessels. The signals generated by these sensors are analog and must be converted into a digital form to be processed by a programmable logic controller (PLC), which supervises the process. Nowadays, Fieldbus networks are commonly used to transport the digital signals from sensors to the PLC (Figure 1), which then processes this information and responds as appropriate by sending control signals back over the network to a series of actuators, valves, and motors as required.

This article provides a brief overview of the many different Fieldbus networks currently in use while discussing the advantages of using a Fieldbus network to transport sensor readings and control signals in an industrial environment compared to legacy approaches. It then describes the conventional method used to make sensors and controllers compatible with a particular type of Fieldbus and considers the constraints that this introduces before finally proposing a much simpler, flexible, and cost-effective way to implement Fieldbus in industrial equipment.

Industrial programmable logic controller (PLC)
Figure 1: Industrial programmable logic controller (PLC)

What is Fieldbus?

Fieldbus is the umbrella term used for a family of industrial computer networks for real-time distributed process control, standardized by the Electrotechnical commission as IEC 61784/61158. Before the advent of Fieldbus, industrial input/output (IO) signals were transported using either voltage (RS232) or current (4-20mA) signals across dedicated links that connected individual devices on the factory floor back to the PLC.

As the size and scale of factories grew, this approach became increasingly unwieldy, requiring more and longer cables (up to several kilometers) that became almost impossible to trace and debug. Another disadvantage of analog signals is that they are susceptible to interference from the high levels of electrical noise present in an industrial environment (due to the switching of power supplies and stray magnetic fields from motors).

Fieldbus was invented to allow multiple IO devices to connect to a single network cable (bus) using digital signals (which are more robust in the presence of electrical noise). Because less wiring is required, a bus network made it much easier for industrial processes to grow in scale.

A helpful analogy might be to think of what Fieldbus is to industrial equipment; Ethernet is to PCs on a local area network (LAN) where additional devices can easily be added using network switches. Early Fieldbus networks were proprietary, which meant that different manufacturers developed many different types. No single industry standard has emerged, which means many (incompatible) versions are now used on factory floors worldwide. Some of the most common Fieldbus networks currently in use include:

  • Profibus
  • Modbus
  • CANOpen

The protocols primarily differ in the number of devices they can support, their command syntax, and their variety of physical interfaces. More recently developed real-time Fieldbus networks can operate using an ethernet interface and cabling, but they are not interoperable. These include:

  • EtherCAT
  • Profinet
  • EtherNet/IP  
Common Fieldbus networks
Figure 2: Common Fieldbus networks.

Why hardware isn’t the only answer

For an industrial device or controller to operate on a specific Fieldbus network (e.g., Profibus), it needs to be able to ‘speak the language’ of that network. Usually, this is provided by selecting a dedicated application-specific integrated circuit (ASIC) or hardware module to perform that function.

While this may appear to be a low-risk and convenient solution, it has several drawbacks that are not immediately obvious. A significant limitation is that it restricts the device from communicating with the specific version of Fieldbus implemented by the ASIC or hardware module. Thus, immediately narrowing the market for a device to only customers using that particular Fieldbus network in their industrial processes.

For a device to be able to operate on other Fieldbus networks, a different ASIC or module must be used. Since ASICs use different packages and have different pin functions, this can require a costly and time-consuming system redesign. Other disadvantages of this approach are that it restricts the functionality of the industrial device to that provided by the ASIC/module because making changes to a pre-configured software stack can be difficult and may not be supported by the manufacturer. Therefore, this impacts the number and types of features that can be engineered into new product designs.

Furthermore, because the ASIC or module may only be sourced from its manufacturer, vulnerability to supply-chain disruption and future price increases are potentially a concern. Some ASIC and module manufacturers may also insist on a royalty payment for each device sold, resulting in an unavoidable overhead that persists over the entire product lifetime.

Reasons why a software approach may work better

An emerging ‘soft’ alternative to the hardware approach is to source a Fieldbus software stack to run instead on the system microcontroller in an embedded device. This approach has many advantages – it enables a fully customized product offering and allows equipment manufacturers to take complete ownership of their supply chain. Furthermore, eliminating the requirement for a hardware module produces an immediate cost-saving by reducing the bill of materials (BOM).

Another benefit of this approach is that it can reuse the same design within different products. Simply modifying the code in the software stack to allow the microcontroller to communicate with another Fieldbus makes it possible to bring a new product to the market much more quickly than where a hardware redesign is required.

A software-based approach also makes it easy to add innovative and customized features to higher-end product offerings by changing the code in the stack. As an example, when using RT-Labs’ Profinet device stack for Profinet implementations, its small code footprint makes it much less complex than other Profinet stacks, meaning it’s well-suited for use in embedded systems.


Fieldbus is a mature technology, but its benefits in industrial process control mean that it is still widely used in factory environments worldwide. The conventional approach to making industrial devices Fieldbus compatible has been to use an ‘off-the-shelf’ ASIC or module. While this may offer a low-risk technology solution, it has the potential to become high-risk if the hardware supply chain cannot be guaranteed.

Using a Fieldbus software stack is an alternative approach that provides greater flexibility, more innovation, lower costs, and reduced vulnerability to supply-chain interruption.

Hans-Erik Floryd - RT-Labs

Hans-Erik Floryd is chief technology officer and co-founder RT-Labs. He has over
20 years’ experience in real-time software design and development.

Related Content:

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.