Hubbry Logo
FieldbusFieldbusMain
Open search
Fieldbus
Community hub
Fieldbus
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Fieldbus
Fieldbus
Fieldbus
View on Wikipedia
from Wikipedia

A fieldbus is a member of a family of industrial digital communication networks[1] used for real-time distributed control. Fieldbus profiles are standardized by the International Electrotechnical Commission (IEC) as IEC 61784/61158.

A complex automated industrial system is typically structured in hierarchical levels as a distributed control system (DCS). In this hierarchy the upper levels for production managements are linked to the direct control level of programmable logic controllers (PLC) via a non-time-critical communications system (e.g. Ethernet). The fieldbus[2] links the PLCs of the direct control level to the components in the plant at the field level, such as sensors, actuators, electric motors, console lights, switches, valves and contactors. It also replaces the direct connections via current loops or digital I/O signals. The requirements for a fieldbus are therefore time-critical and cost-sensitive. Since the new millennium, a number of fieldbuses based on Real-time Ethernet have been established. These have the potential to replace traditional fieldbuses in the long term.

Description

[edit]

A fieldbus is an industrial network system for real-time distributed control. It is a way to connect instruments in a manufacturing plant. A fieldbus works on a network structure which typically allows daisy-chain, star, ring, branch, and tree network topologies. Previously, computers were connected using RS-232 (serial connections) by which only two devices could communicate. This would be the equivalent of the currently used 4–20 mA communication scheme which requires that each device have its own communication point at the controller level, while the fieldbus is the equivalent of the current LAN-type connections, which require only one communication point at the controller level and allow multiple of analog and digital points to be connected at the same time. This reduces both the length of and total number of cables required. Furthermore, since devices that communicate through a fieldbus require a microprocessor, multiple points are typically provided by the same device. Some fieldbus devices now support control schemes such as PID control on the device-side instead of forcing the controller to do the processing.

History

[edit]

The most important motivation to use a fieldbus in a distributed control system is to reduce the cost for installation and maintenance of the installation without losing the high availability and reliability of the automation system. The goal is to use a two wire cable and simple configuration for field devices from different manufacturers. Depending on the application, the number of sensors and actuators vary from hundreds in one machine up to several thousands distributed over a large plant. The history of the fieldbus demonstrates how these goals have been approached over time.

Precursors of fieldbuses

[edit]

General Purpose Interface Bus (GPIB)

[edit]

Arguably the precursor field bus technology is HP-IB as described in IEEE 488[3] in 1975. "It became known as the General Purpose Interface Bus (GPIB), and became a de facto standard for automated and industrial instrument control".

The GPIB has its main application in automated measurements with instruments from different manufacturers. It is a parallel bus with a cable and connector with 24 wires, limited to a maximal cable length of 20 metres.

Bitbus

[edit]
Bitbus controller card with Intel 8044

The oldest commonly used field bus technology is Bitbus. Bitbus was created by Intel Corporation to enhance use of Multibus systems in industrial systems by separating slow i/o functions from faster memory access. In 1983, Intel created the 8044 Bitbus microcontroller by adding field bus firmware to its existing 8051 microcontroller. Bitbus uses EIA-485 at the physical layer, with two twisted pairs - one for data and the other for clocking and signals. Use of SDLC at the data link layer permits 250 nodes on one segment with a total distance of 13.2 km. Bitbus has one master node and multiple slaves, with slaves only responding to requests from the master. Bitbus does not define routing at the network layer. The 8044 permits only a relatively small data packet (13 bytes), but embeds an efficient set of RAC (remote access and control) tasks and the ability to develop custom RAC tasks. In 1990, the IEEE adopted Bitbus as the Microcontroller System Serial Control Bus (IEEE-1118).[4][5]

Today BITBUS is maintained by the BEUG - BITBUS European Users Group.[6]

Computer networks for automation

[edit]

Office networks are not really suited for automation applications, as they lack the upper-bounded transmission delay. ARCNET, which was conceived as early as 1975 for office connectivity uses a token mechanism and therefore found later uses in industry.

Manufacturing Automation Protocol (MAP)

[edit]

The Manufacturing Automation Protocol (MAP) was an implementation of OSI-compliant protocols in automation technology initiated by General Motors in 1984. MAP became a LAN standardization proposal supported by many manufacturers and was mainly used in factory automation. MAP used the 10 Mbit/s IEEE 802.4 token bus as a transmission medium.

Due to its scope and complexity, MAP failed to make a big breakthrough. To reduce the complexity and reach faster processing with reduced resources the Enhanced Performance Architecture (EPA) MAP was developed in 1988. This MiniMap[7] contains only levels 1, 2, and 7 of the Open Systems Interconnection (OSI) basic reference model. This shortcut was taken over by later fieldbus definitions.

The most important achievement of MAP is Manufacturing Message Specification (MMS), the application layer of MAP.

Manufacturing Message Specification (MMS)

[edit]

The Manufacturing Message Specification (MMS) is an international standard ISO 9506[8] dealing with an application protocol and services for transferring real time process data and supervisory control information between networked devices or computer applications published as a first version in 1986.

It has been a model for many further developments in other industrial communication standardizations such as FMS for Profibus or SDO for CANopen. It is still in use as a possible application layer e.g. for power utility automation in the IEC 61850 standards.

Fieldbuses for manufacturing automation

[edit]

In the field of manufacturing automation the requirements for a fieldbus are to support short reaction times with only a few bits or bytes to be transmitted over not more than some hundreds of meters.

MODBUS

[edit]
Main article: Modbus

In 1979 Modicon (now Schneider Electric) defined a serial bus to connect their programmable logic controllers (PLCs) called Modbus. In its first version Modbus used a two wire cable with EIA 485 UART signals. The protocol itself is very simple with a master/slave protocol and the number of data types are limited to those understood by PLCs at the time. Nevertheless, Modbus is (with its Modbus-TCP version) still one of the most used industrial networks, mainly in the building automation field.

PROFIBUS

[edit]
Main article: PROFIBUS

A research project with the financial support of the German government defined in 1987 the fieldbus PROFIBUS based on the Fieldbus Message Specification (FMS).[9] In practical applications, it proved too complicated to handle in the field. In 1994 Siemens proposed a modified application layer with the name Decentralized Periphery (DP) which reached a good acceptance in the manufacturing industry. As of 2016, the Profibus is one of the most installed fieldbuses in the world[10] and reached 60 million installed nodes in 2018.[11]

INTERBUS

[edit]
Main article: INTERBUS

In 1987 Phoenix Contact developed a serial bus to connect spatially distributed inputs and outputs to a centralized controller.[12] The controller sends one frame over a physical ring, which contains all input and output data. The cable has 5 wires: besides the ground signal, two wires for the outgoing frame and two wires for the returning frame. With this cable is it possible to have the whole installation in a tree topology.[13]

The INTERBUS was very successful in the manufacturing industry with more than 22,9 million devices installed in the field. The Interbus joined the Profinet technology for Ethernet-based fieldbus Profinet and the INTERBUS is now maintained by the Profibus Nutzerorganisation e.V.[14]

CAN

[edit]
Main article: CAN bus

During the 1980s, to solve communication problems between different control systems in cars, the German company Robert Bosch GmbH first developed the Controller Area Network (CAN). The concept of CAN was that every device can be connected by a single set of wires, and every device that is connected can freely exchange data with any other device. CAN soon migrated into the factory automation marketplace (with many others).

DeviceNet was developed by the American company Allen-Bradley (now owned by Rockwell Automation) and the ODVA (Open DeviceNet Vendor Association) as an open fieldbus standard based on the CAN protocol. DeviceNet is standardised in the European standard EN 50325-2. Specification and maintenance of the DeviceNet standard is the responsibility of ODVA. Like ControlNet and EtherNet/IP, DeviceNet belongs to the family of CIP-based networks. CIP (Common Industrial Protocol) forms the common application layer of these three industrial networks. DeviceNet, ControlNet and Ethernet/IP are therefore well coordinated and provide the user with a graded communication system for the management level (EtherNet/IP), cell level (ControlNet) and field level (DeviceNet). DeviceNet is an object-oriented bus system and operates according to the producer/consumer method. DeviceNet devices can be client (master) or server (slave) or both. Clients and servers can be Producer, Consumer or both.

CANopen was developed by the CiA (CAN in Automation), the user and manufacturer association for CANopen, and has been standardized as European standard EN 50325-4 since the end of 2002. CANopen uses layers 1 and 2 of the CAN standard (ISO 11898-2) and extensions with regard to pin assignment, transmission rates and the application layer.

Fieldbuses for process automation

[edit]

In process automation traditionally most of the field transmitters are connected over a current loop with 4-20 mA to the controlling device. This allows not only to transmit the measured value with the level of the current, but also provide the required electrical power to the field device with just one two-wire cable of a length of more than a thousand meters. These systems are also installed in hazardous areas. According to NAMUR a fieldbus in these applications has to fulfill these requirements.[15] A special standard for instrumentation, IEC/EN 60079-27, describes requirements for the Fieldbus Intrinsically Safe Concept (FISCO) for installations in zone 0, 1 or 2.

WorldFIP

[edit]

The FIP standard is based on a French initiative in 1982 to create a requirements analysis for a future field bus standard. The study led to the European Eureka initiative for a field bus standard in June 1986 that included 13 partners. The development group (réseaux locaux industriels) created the first proposal to be standardized in France. The name of the FIP field bus was originally given as an abbreviation of the French "Flux d'Information vers le Processus" while later referring to FIP with the English name "Factory Instrumentation Protocol".

FIP has lost ground to Profibus which came to prevail the market in Europe in the following decade - the WorldFIP homepage has seen no press release since 2002. The closest cousin of the FIP family can be found today in the Wire Train Bus for train coaches. However a specific subset of WorldFIP - known the FIPIO protocol - can be found widely in machine components.

Foundation Fieldbus (FF)

[edit]

Foundation Fieldbus was developed over a period of many years by the International Society of Automation (ISA) as SP50. Foundation Fieldbus today enjoys a growing installed base in many heavy process applications such as refining, petrochemicals, power generation, and even food and beverage, pharmaceuticals, and nuclear applications.[16]

Effective January 1, 2015, the Fieldbus Foundation has become part of the new FieldComm Group.[17]

PROFIBUS-PA

[edit]

Profibus PA (process automation) is used for communication between measuring and process instruments, actuators and process control system or PLC/DCS in process engineering. Profibus PA is a Profibus version with physical layer suitable for process automation, in which several segments (PA segments) with field instruments can be connected to Profibus DP via so-called couplers. The two-wire bus cable of these segments takes over not only the communication, but also the power supply of the participants (MBP transmission technology). Another special feature of Profibus PA is the widely used device profile "PA Devices" (PA Profile), [18] in which the most important functions of the field devices are standardized across manufacturers.

Fieldbuses for building automation

[edit]

The market of building automation has also different requirements for the application of a fieldbus:

The BatiBUS defined in 1989 and used mainly in France, the Instabus extended to the European Installation Bus (EIB) and the European Home Systems Protocol (EHS) merged in 1999 to the Konnex) (KNX) standard EN 50090, (ISO/IEC 14543-3). In 2020 495 Member companies offer 8'000 products with KNX interfaces in 190 countries worldwide.[19]

LonWorks

[edit]

Going back to the 1980s, unlike other networks, LonWorks is the result of the work of computer scientists from Echelon Corporation. In 1999 the communications protocol (then known as LonTalk) was submitted to ANSI and accepted as a standard for control networking (ANSI/CEA-709.1-B), in 2005 as EN 14908 (European building automation standard). The protocol is also one of several data link/physical layers of the BACnet ASHRAE/ANSI standard for building automation.

BACnet

[edit]

The BACnet standard was initially developed and is now maintained by the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) starting in 1987. BACnet is an American National Standard (ANSI) 135 since 1995, a European standard, a national standard in many countries, and global ISO Standard 16484 since 2003.[20] BACnet has in 2017 a market share of 60% in building automation market.[21]

Standardization

[edit]

Although fieldbus technology has been around since 1988, with the completion of the ISA S50.02 standard, the development of the international standard took many years. In 1999, the IEC SC65C/WG6 standards committee met to resolve difference in the draft IEC fieldbus standard. The result of this meeting was the initial form of the IEC 61158 standard with eight different protocol sets called "Types".

This form of standard was first developed for the European Common Market, concentrates less on commonality, and achieves its primary purpose—elimination of restraint of trade between nations. Issues of commonality are now left to the international consortia that support each of the fieldbus standard types. Almost as soon as it was approved, the IEC standards development work ceased and the committee was dissolved. A new IEC committee SC65C/MT-9 was formed to resolve the conflicts in form and substance within the more than 4000 pages of IEC 61158. The work on the above protocol types is substantially complete. New protocols, such as for safety fieldbuses or real-time Ethernet fieldbuses are being accepted into the definition of the international fieldbus standard during a typical 5-year maintenance cycle. In the 2008 version of the standard, the fieldbus types are reorganized into Communication Profile Families (CPFs).[22]

Structure of fieldbus standards

[edit]

There were many competing technologies for fieldbuses and the original hope for one single unified communications mechanism has not been realized. This should not be unexpected since fieldbus technology needs to be implemented differently in different applications; automotive fieldbuses are functionally different from process plant control fieldbuses.

IEC 61158: Industrial communication networks - Fieldbus specification

[edit]

In June 1999 the IEC's Committee of Action (CA) decided to take a new structure for the fieldbus standards beginning with a first edition valid at the January 1, 2000, in time for the new millennium: There is a large IEC 61158 standard, where all fieldbuses find their place.[23] The experts have decided that the structure of IEC 61158 is maintained according to different layers, divided into services and protocols. The individual fieldbuses are incorporated into this structure as different types.

The Standard IEC 61158 Industrial communication networks - Fieldbus specifications is split into the following parts:

  • IEC 61158-1 Part 1: Overview and guidance for the IEC 61158 and IEC 61784 series
  • IEC 61158-2 PhL: Part 2: Physical layer specification and service definition
  • IEC 61158-3-x DLL: Part 3-x: Data-link layer service definition - Type x elements
  • IEC 61158-4-x DLL: Part 4-x: Data-link layer protocol specification - Type x elements
  • IEC 61158-5-x AL: Part 5-x: Application layer service definition - Type x elements
  • IEC 61158-6-x AL: Part 6-x: Application layer protocol specification - Type x elements

Each part still contains several thousand pages. Therefore, these parts have been further subdivided into subparts. The individual protocols have simply been numbered with a type. Each protocol type thus has its own subpart if required.

In order to find the corresponding subpart of the individual parts of the IEC 61158 standard, one must know the corresponding protocol type for a specific family.

In the 2019 edition of IEC 61158 up to 26 different types of protocols are specified. In IEC 61158 standardization, the use of brand names is avoided and replaced by dry technical terms and abbreviations. For example, Ethernet is replaced by the technically correct CSMA/CD or a reference to the corresponding ISO standard 8802.3. This is also the case with fieldbus names, they all are replaced by type numbers. The reader will therefore never find a designation such as PROFIBUS or DeviceNet in the entire IEC 61158 fieldbus standard. In the section Compliance to IEC 61784 a complete reference table is provided.

IEC 61784: Industrial communication networks - Profiles

[edit]

It is clear that this collection of fieldbus standards in IEC 61158 is not suitable for implementation. It must be supplemented with instructions for use. These instructions show how and which parts of IEC 61158 can be assembled to a functioning system. This assembly instruction has been compiled subsequently as IEC 61784 fieldbus profiles.

According to IEC 61158-1[24] the Standard IEC 61784 is split in the following parts:

  • IEC 61784-1 Profile sets for continuous and discrete manufacturing relative to fieldbus use in industrial control systems
  • IEC 61784-2 Additional profiles for ISO/IEC 8802 3 based communication networks in real-time applications
  • IEC 61784-3 Functional safety fieldbuses – General rules and profile definitions
  • IEC 61784-3-n Functional safety fieldbuses – Additional specifications for CPF n
  • IEC 61784-5-n Installation of fieldbuses - Installation profiles for CPF n

IEC 61784-1: Fieldbus profiles

[edit]

The IEC 61784 Part 1[25] standard with the name Profile sets for continuous and discrete manufacturing relative to fieldbus use in industrial control systems lists all fieldbuses which are proposed by the national standardization bodies. In the first edition in 2003 7 different Communication Profile Families (CPF) are introduced:

Swiftnet, which is widely used in aircraft construction (Boeing), was included in the first edition of the standard. This later proves to be a mistake and in the 2007 edition 2 this protocol was removed from the standard. At the same time, the CPF 8 CC-Link, the CPF 9 HART protocol and CPF 16 SERCOS are added. In the edition 4 in 2014 the last fieldbus CPF 19 MECHATROLINK was included into the standard. The edition 5 in 2019 was just a maintenance revision without any new profile added.

See List of automation protocols for fieldbuses that are not included in this standard.

IEC 61784-2: Real-time Ethernet

[edit]

Already in edition 2 of the fieldbus profile first profiles based on Ethernet as physical layer are included.[26] All this new developed Real-time Ethernet (RTE) protocols are compiled in IEC 61784 Part 2[27] as Additional profiles for ISO/IEC 8802 3 based communication networks in real-time applications. Here we find the solutions Ethernet/IP, three versions of PROFINET IO - the classes A, B, and C - and the solutions of P-NET,[28] Vnet/IP[29] TCnet,[30] EtherCAT, Ethernet POWERLINK, Ethernet for Plant Automation (EPA), and also the MODBUS with a new Real-Time Publish-Subscribe MODBUS-RTPS and the legacy profile MODBUS-TCP.

The SERCOS solution is interesting in this context. This network from the field of axis control had its own standard IEC 61491.[31] With the introduction of the Ethernet-based solution SERCOS III, this standard has been taken apart and the communication part is integrated in IEC 61158/61784. The application part has been integrated together with other drive solutions into a special drive standard IEC 61800-7.

So the list of RTE for the first edition in 2007 is already long:

2010:

2019:

2023:

In 2010, a second edition was published to include CPF 17 RAPIEnet and CPF 18 SafetyNET p. In the third edition (2014), the Industrial Ethernet (IE) version of CC-Link was added. The two profile families CPF 20 ADS-net[32] and CPF 19 FL-net[33] were added to the fourth edition in 2019.

For details about these RTEs see the article on Industrial Ethernet.

IEC 61784-3: Safety

[edit]

For functional safety, different consortia have developed different protocols for safety applications up to Safety Integrity Level 3 (SIL) according to IEC 61508 or Performance Level "e" (PL) according to ISO 13849. What most solutions have in common is that they are based on a Black Channel and can therefore be transmitted via different fieldbuses and networks. Depending on the actual profile the safety protocol does provide measures like counters, CRCs, echo, timeout, unique sender and receiver IDs or cross check.

The first edition issued in 2007 of IEC 61784 Part 3[34], named Industrial communication networks – Profiles – Functional safety fieldbuses includes the Communication Profile Families (CPF):

SERCOS does use the CIP safety protocol as well.[36] In the second edition issued in 2010 additional CPF are added to the standard:

In the third edition in 2016 the last safety profile CPF 17 SafetyNET p was added. A new edition 4 is expected to be published in 2021. The standard has now 9 different safety profiles. They are all included and referenced in the global compliance table in the next section.

Compliance to IEC 61784

[edit]

The protocol families of each brand name are called Communication Profile Family and are abbreviated as CPF with a number. Each protocol family can now define fieldbuses, real-time Ethernet solutions, installation rules and protocols for functional safety. These possible profile families are laid down in IEC 61784 and compiled in the following table.

As an example, we will search for the standards for PROFIBUS-DP. This belongs to the CPF 3 family and has the profile CP 3/1. In Table 5 we find that its protocol scope is defined in IEC 61784 Part 1. It uses protocol type 3, so the documents IEC 61158-3-3, 61158-4-3, 61158-5-3 and 61158-6-3 are required for the protocol definitions. The physical interface is defined in the common 61158-2 under type 3. The installation regulations can be found in IEC 61784-5-3 in Appendix A. It can be combined with the FSCP3/1 as PROFIsafe, which is defined in the IEC 61784-3-3 standard.

To avoid the manufacturer having to list all these standards explicitly, the reference to the profile is specified in the standard. In the case of our example for the PROFIBUS-DP, the specification of the relevant standards would therefore have to be

Compliance to IEC 61784-1 Ed.3:2019 CPF 3/1

IEC 62026: Controller-device interfaces (CDIs)

[edit]

Requirements of fieldbus networks for process automation applications (flowmeters, pressure transmitters, and other measurement devices and control valves in industries such as hydrocarbon processing and power generation) are different from the requirements of fieldbus networks found in discrete manufacturing applications such as automotive manufacturing, where large numbers of discrete sensors are used including motion sensors, position sensors, and so on. Discrete fieldbus networks are often referred to as "device networks".

Already in the year 2000 the International Electrotechnical Commission (IEC) decided that a set of controller-device interfaces (CDIs) will be specified by the Technical Committee TC 121 Low-voltage switchgear and controlgear to cover the device networks. This set of standards with the number IEC 62026[37] includes in the actual edition of 2019 the following parts:

The following parts have been withdrawn in 2006 and are not maintained anymore:

  • IEC 62026-5: Part 5: Smart distributed system (SDS)
  • IEC 62026-6: Part 6: Seriplex (Serial Multiplexed Control Bus)

Cost advantage

[edit]

The amount of cabling required is much lower in fieldbus than in 4–20 mA installations. This is because many devices share the same set of cables in a multi-dropped fashion rather than requiring a dedicated set of cables per device as in the case of 4–20 mA devices. Moreover, several parameters can be communicated per device in a fieldbus network whereas only one parameter can be transmitted on a 4–20 mA connection. A fieldbus also provides a good foundation for the creation of a predictive and proactive maintenance strategy. The diagnostics available from fieldbus devices can be used to address issues with devices before they become critical problems.[38]

Networking

[edit]

Despite each technology sharing the generic name of fieldbus the various fieldbuses are not readily interchangeable. The differences between them are so profound that they cannot be easily connected to each other.[39] To understand the differences among fieldbus standards, it is necessary to understand how fieldbus networks are designed. With reference to the OSI model, fieldbus standards are determined by the physical media of the cabling, and layers one, two and seven of the reference model.

For each technology the physical medium and the physical layer standards fully describe, in detail, the implementation of bit timing, synchronization, encoding/decoding, band rate, bus length and the physical connection of the transceiver to the communication wires. The data link layer standard is responsible for fully specifying how messages are assembled ready for transmission by the physical layer, error handling, message-filtering and bus arbitration and how these standards are to be implemented in hardware. The application layer standard, in general defines how the data communication layers are interfaced to the application that wishes to communicate. It describes message specifications, network management implementations and response to the request from the application of services. Layers three to six are not described in fieldbus standards.[40]

Features

[edit]

Different fieldbuses offer different sets of features and performance. It is difficult to make a general comparison of fieldbus performance because of fundamental differences in data transfer methodology. In the comparison table below it is simply noted if the fieldbus in question typically supports data update cycles of 1 millisecond or faster.

Fieldbus Bus power Cabling redundancy Max devices Synchronisation Sub millisecond cycle
AFDX No Yes Almost unlimited No Yes
AS-Interface Yes No 62 No No
CANopen No No 127 Yes No
CompoNet Yes No 384 No Yes
ControlNet No Yes 99 No No
CC-Link No No 64 No No
DeviceNet Yes No 64 No No
EtherCAT Yes Yes 65,536 Yes Yes
Ethernet Powerlink No Optional 240 Yes Yes
EtherNet/IP No Optional Almost unlimited Yes Yes
Interbus No No 511 No No
LonWorks No No 32,000 No No
Modbus No No 246 No No
PROFIBUS DP No Optional 126 Yes No
PROFIBUS PA Yes No 126 No No
PROFINET incl. IRT No Optional Almost unlimited Yes Yes
SERCOS III No Yes 511 Yes Yes
SERCOS interface No No 254 Yes Yes
Foundation Fieldbus H1 Yes No 240 Yes No
Foundation HSE No Yes Almost unlimited Yes No
RAPIEnet No Yes 256 Under Development Conditional
Fieldbus Bus power Cabling redundancy Max devices Synchronisation Sub millisecond cycle

Market

[edit]

As of 2008, in process control systems, the market is dominated by Foundation Fieldbus and Profibus PA.[41] Both technologies use the same physical layer (2-wire Manchester-encoded current modulation at 31.25 kHz) but are not interchangeable. As a general guide, applications which are controlled and monitored by programmable logic controllers (PLCs) tend towards PROFIBUS, and applications which are controlled and monitored by a digital/distributed control system (DCS) tend towards Foundation Fieldbus. PROFIBUS technology is made available through Profibus International with headquarters in Karlsruhe, Germany. Foundation Fieldbus technology is owned and distributed by the Fieldbus Foundation of Austin, Texas.

See also

[edit]

References

[edit]

Bibliography

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Fieldbus

View on Grokipedia
from Grokipedia
Fieldbus is a family of industrial digital communication protocols designed to connect field devices—such as sensors, actuators, valves, and controllers—in systems, enabling bidirectional, exchange over a shared serial bus to facilitate distributed control and monitoring. These protocols replace traditional point-to-point analog wiring, like 4–20 mA signals, with more efficient serial networks that reduce cabling costs, simplify installation, and support topologies including bus, , ring, and configurations. Standardized under frameworks such as IEC 61158, Fieldbus systems adhere to subsets of the , typically implementing the physical, data link, and application layers to ensure and predictable performance in harsh industrial environments. The concept of Fieldbus emerged in the late 1970s and 1980s as automation evolved from centralized architectures to distributed control, driven by initiatives like ' project and the need for digital integration in manufacturing and process industries. Key variants include for factory automation, (with H1 for low-speed process control at 31.25 kbps and HSE for high-speed Ethernet-based systems at 100 Mbps), , and , each tailored to specific applications while promoting device-to-device communication and fault-tolerant operation. Organizations like the FieldComm Group oversee certification to guarantee compatibility, with features such as link active schedulers (LAS) in ensuring deterministic real-time scheduling for closed-loop control even during host system failures. In modern industrial settings, Fieldbus plays a pivotal role in enhancing system efficiency, diagnostics, and , supporting integration with higher-level like Ethernet and technologies while complying with safety standards such as IEC 61508. Its adoption has significantly reduced hardware requirements—such as marshalling panels—through virtual marshalling and functionality, leading to faster commissioning, tighter process control, and lower lifecycle costs in sectors including oil and gas, chemicals, and power generation.

Overview

Definition and Purpose

Fieldbus is a (LAN) designed for connecting industrial control systems, including sensors, actuators, and controllers, to enable real-time communication in environments. It functions as a digital, serial, multidrop data bus that facilitates the interconnection of low-level industrial control and instrumentation devices. This supports bidirectional digital communication, allowing data to flow between field devices and higher-level systems such as operator stations. The primary purpose of fieldbus is to enable efficient bidirectional data exchange for monitoring, control, and diagnostics in industrial settings, particularly those with harsh environmental conditions like high , , and temperature extremes. By supporting distributed processing, it allows control functions to be performed closer to the process, reducing latency and improving system responsiveness. This capability enhances overall reliability and enables advanced features like remote diagnostics without interrupting operations. In contrast to traditional analog wiring systems, which require separate point-to-point cables for each signal—often resulting in hundreds of wires per installation—fieldbus consolidates multiple signals onto a single digital bus, significantly reducing cabling complexity and costs. Some fieldbus implementations further incorporate power delivery over the same bus wires, eliminating the need for additional power cabling and simplifying deployment in field environments. This shift from analog to digital transmission also improves immunity and over longer distances. Fieldbus networks typically employ flexible topologies tailored to industrial layouts, such as linear bus configurations for multidrop connections, ring setups for , or arrangements for centralized distribution, allowing adaptation to diverse physical constraints. These topologies support the integration of multiple devices while maintaining real-time performance in demanding applications.

Core Principles

Fieldbus systems operate on the principle of , which guarantees the timely delivery of messages to support real-time control in industrial . This is achieved through scheduled communication cycles that define precise intervals for data transmission, such as macrocycles where critical process variables are exchanged with minimal —typically on the order of milliseconds—to prevent delays that could disrupt control loops. is fundamental for applications requiring predictable response times, ensuring that sensors and actuators synchronize effectively without non-deterministic interruptions. A key aspect of fieldbus design is and , enabled by adherence to international standards that allow integration of devices from multiple vendors on a single network. These standards promote a vendor-neutral , where devices can communicate seamlessly through common protocols and device descriptions, facilitating plug-and-play functionality and reducing dependency on systems. This openness supports scalable automation setups, where heterogeneous equipment from different manufacturers operates cohesively without custom interfacing. Fieldbus communication is structured around an adaptation of the OSI model, emphasizing the physical, data link, and application layers to streamline industrial data exchange. The physical layer handles signal transmission over media like twisted-pair cables, the data link layer manages access control and error checking, and the application layer processes user-specific functions such as control and diagnostics, omitting higher OSI layers for efficiency in resource-constrained environments. This layered approach ensures modular design, where each layer can be optimized independently for reliability and performance in harsh settings. Fault tolerance in fieldbus systems incorporates mechanisms like and robust error detection to maintain operational continuity amid failures. may involve duplicate paths or backup schedulers, while error detection techniques, such as cyclic redundancy checks (CRC), verify and achieve extremely low undetected error rates over extended periods. These features enhance system resilience without compromising , allowing graceful degradation rather than total outages. Power and are addressed through designs that accommodate industrial challenges, including for hazardous areas and (EMC) to mitigate noise interference. limits energy levels to prevent ignition risks, often using barriers or low-power signaling, while EMC compliance employs encoding schemes like biphase to preserve signal quality over long distances in electrically noisy environments. This ensures reliable operation in process plants, where combined power and data transmission over a single cable reduces wiring complexity while upholding safety standards.

Historical Development

Early Precursors

The early precursors to fieldbus technologies emerged in the mid-20th century as industrial automation grappled with the limitations of analog and pneumatic control systems. Analog signaling, particularly the 4-20 mA current loop, became a dominant standard in process control by the 1950s, transmitting a single variable (such as or pressure) over twisted-pair wiring with a "live zero" at 4 mA to distinguish faults from valid low readings. However, these loops were inherently limited to point-to-point communication, susceptible to electrical noise over long distances, and incapable of supporting multi-device networks or exchange, which hindered scalability in increasingly complex factories. Pneumatic systems, prevalent from the early , relied on (typically 3-15 psi signals) transmitted through tubing to operate valves, actuators, and controllers in hazardous environments where electrical systems posed explosion risks. While reliable in isolated applications, suffered from slow signal propagation (limited to about 1,100 ft/s), mechanical wear on components, and difficulty implementing complex logic without extensive hardwiring, making them inefficient for modern production demands. The marked a pivotal push toward in industrial instrumentation amid rising factory complexity and the advent of microprocessors, with organizations like the Instrument Society of America (now ISA) advocating for unified terminology and interfaces to replace bespoke systems that were rigid, space-intensive, and prone to wiring errors. , using electromechanical switches for sequencing operations, dominated until then but required physical rewiring for changes, amplifying downtime and costs in dynamic environments. A key innovation was the General Purpose Interface Bus (GPIB), also known as IEEE-488, developed by in the late 1960s to enable automated control of test instruments. Initially deployed in HP's 1965 minicomputer-based systems, GPIB evolved through collaboration with in the early 1970s, featuring an 8-bit parallel transmission over a up to 20 meters long, with handshaking for reliable data transfer and addressing for up to 15 devices in a multi-master configuration. Standardized by the IEEE in 1978, it facilitated talker-listener interactions for instrument synchronization but was constrained to short-range, non-real-time applications due to its nature and lack of serial . In the early 1980s, introduced Bitbus as a serial protocol for distributed control in embedded systems, addressing the need for low-cost, noise-immune communication in industrial settings. Released in 1983 based on the 8051 microcontroller with added fieldbus firmware, Bitbus employed physical layer for multidrop topologies up to 4,000 meters, using a master-slave with synchronous data link control (SDLC) for error-checked messaging at rates up to 2 Mbps. It supported up to 250 nodes for modular I/O expansion but was eventually overshadowed by more versatile fieldbuses due to its proprietary elements and limited bandwidth for high-speed data.

Evolution in Automation Networks

The 1980s marked a pivotal transition in industrial from proprietary point-to-point wiring and early general-purpose networks to specialized fieldbus systems designed for real-time, distributed control at the device level. This evolution was driven by the need for greater , reduced cabling costs, and enhanced diagnostics in complex and process environments, moving beyond isolated sensor-actuator links toward integrated digital communication infrastructures. A key initiative in this period was the Manufacturing Automation Protocol (MAP), launched in 1980 under the leadership of to enable factory-wide integration of computer systems and machinery. Based on the IEEE 802.4 token bus standard, MAP sought to provide a network for high-level data exchange across an entire plant but proved overly complex, expensive, and bandwidth-intensive for field-level applications involving sensors and actuators. Complementing MAP was the Manufacturing Message Specification (MMS), formalized as ISO 9506 in the late as an application-layer standard to facilitate messaging and object-oriented communication in heterogeneous systems. MMS allowed for abstract modeling of devices and processes, promoting but remaining geared toward upper-level rather than rugged, low-level field connections. The push toward field-level buses intensified in the late , particularly from the oil and process industries, which demanded intrinsically safe, deterministic networks for hazardous environments and closed-loop control. This led to the formation of the ISA SP-50 committee in 1985, which focused on developing an open digital fieldbus standard tailored to process needs, emphasizing low-speed, multi-drop topologies over the high-speed designs of earlier protocols like . A major milestone came in 1994 with the establishment of the Fieldbus Foundation through the merger of WorldFIP and the Interoperable Systems Project (ISP), aiming to accelerate adoption of an open, vendor-neutral fieldbus for process control amid ongoing rivalries. This formation highlighted the broader competition between proprietary vendor-specific systems—such as those from major instrument makers—and emerging open standards, ultimately fostering compromises that shaped international fieldbus architectures by the late .

Major Fieldbus Protocols

Protocols for Manufacturing Automation

Protocols for manufacturing automation encompass fieldbus systems optimized for environments, emphasizing high-speed data exchange for machine-level control in factory settings. These protocols support rapid, deterministic communication between programmable logic controllers (PLCs), sensors, actuators, and drives, facilitating efficient assembly lines and robotic operations. Key examples include , DP, INTERBUS, CAN, and , each designed to handle cyclic data transfers with minimal latency. MODBUS, developed in 1979 by Modicon (now ), serves as a foundational protocol for industrial automation. It operates over physical layers in a master-slave architecture, where a single master queries multiple slaves using function codes to read or write data from registers such as coils, inputs, holding registers, and input registers. This request-response model ensures simple, reliable polling for discrete I/O status and control values. Variants like MODBUS TCP extend the protocol to Ethernet networks, encapsulating Modbus messages within TCP/IP for higher-speed integration in modern factory setups while maintaining . PROFIBUS, introduced by in 1989, represents a versatile standard for factory floor connectivity, with the DP (Decentralized Periphery) variant tailored specifically for high-performance manufacturing . It employs a token-passing mechanism among multiple masters to manage bus access deterministically, supporting transmission speeds up to 12 Mbps over cabling for fast cyclic exchanges of process data. The protocol's segment coupler feature allows hybrid network configurations, linking segments with fiber-optic extensions to extend coverage in large-scale production facilities without compromising . INTERBUS, originating from Phoenix Contact in the late , provides a robust solution for sensor-actuator interfacing in motion-intensive applications. Its ring topology enables continuous data circulation, with mechanical daisy-chaining via integrated connectors that simplify wiring and support high update rates at 500 kbps for precise in drive control and positioning tasks. This design minimizes cabling complexity while ensuring fault-tolerant operation through loop-back diagnostics. Note that INTERBUS is a legacy protocol, with Phoenix Contact providing support for existing installations but no new developments as of 2022. The Controller Area Network (CAN), pioneered by Bosch in the 1980s for automotive applications and later adapted for industrial use, offers a multi-master broadcast protocol suited to distributed control in . It utilizes CSMA/CA with non-destructive bitwise , where message identifiers determine priority, allowing higher-priority packets to transmit without interruption during bus contention. This priority-based messaging ensures real-time responsiveness for safety-critical signals and commands in dynamic factory environments. DeviceNet, developed in the 1990s by (now ) and managed by ODVA, is a device-level network based on the CAN physical and data link layers with the (CIP) for application services. It supports speeds of 125, 250, or 500 kbps over a trunkline-dropline with 24 V DC power delivery, enabling up to 64 nodes over distances up to 500 meters. DeviceNet facilitates peer-to-peer and client-server messaging for connecting sensors, actuators, drives, and PLCs in manufacturing automation, promoting and reduced wiring in assembly and packaging lines.

Protocols for Process Automation

Protocols for process automation prioritize reliability, , and support for continuous control in hazardous environments such as chemical plants, oil refineries, and pharmaceutical facilities, where long-distance communication and low-speed, deterministic data exchange are essential for monitoring and regulating fluid flows, temperatures, and pressures. These protocols adapt fieldbus principles to handle requirements under standards like IEC 60079 for explosive atmospheres, enabling power delivery over the bus while limiting energy to prevent ignition. WorldFIP, developed in during the as a protocol, employs a producer-consumer model where producers broadcast variables to multiple consumers via a central bus arbitrator, ensuring deterministic real-time communication suitable for hierarchies. Although initially targeted at like automotive assembly, WorldFIP has been adapted for applications through its inclusion in the EN 50170 standard, supporting continuous control in chemical and oil sectors by providing a unified for sensors, actuators, and controllers over distances up to 1 km at 1 Mbit/s. Its producer-distributor-consumer (PDC) architecture minimizes latency in variable exchanges, making it viable for monitoring where synchronized from multiple field devices is critical. Foundation Fieldbus (FF), emerging from a 1990s merger of international efforts including WorldFIP and the Interoperable Systems Project (ISP), offers two complementary segments: H1 for field-level at 31.25 kbit/s, supporting up to 32 devices over 1,900 m segments with for hazardous areas, and HSE (High-Speed Ethernet) at 100 Mbit/s for supervisory control integrating with plant-wide systems. The H1 variant enables control-in-the-field through distributed function blocks—such as PID controllers and analog blocks—that execute control logic directly in devices, reducing wiring and central processor loads in continuous processes like in refineries. HSE facilitates high-speed data exchange for host systems, bridging H1 networks while maintaining redundancy for uptime in critical operations. PROFIBUS-PA, an intrinsically safe extension of the PROFIBUS family for process automation, utilizes Manchester Bus Powered (MBP) physical layer with Manchester coding to deliver both communication and low-voltage power (typically 10-15 mA) over a single twisted-pair cable, supporting up to 32 devices in explosive environments without additional power supplies. Designed for hazardous areas in oil, chemical, and pharmaceutical plants, it complies with the FISCO model for intrinsic safety, allowing segment lengths up to 1,900 m at 31.25 kbit/s while encoding data to ensure reliable transmission in noisy, long-distance setups. This power-over-bus capability simplifies installation in remote process units, enhancing safety by limiting electrical energy per IEC 60079-11. A distinctive feature of is its Device Descriptions (DDs), standardized using the Electronic Device Description Language (EDDL), which enable plug-and-play by providing self-describing parameters, diagnostics, and configuration menus for devices from different vendors, streamlining integration in complex process setups. FF protocols also achieve compliance with for , incorporating certified function blocks and redundancy options to meet SIL () requirements in safety instrumented systems for refineries and chemical plants. Key milestones include the 1994 launch of the Fieldbus Foundation—formed by merging the ISP Association and WorldFIP North America—to drive FF standardization and testing, with the organization merging with the HART Communication Foundation in to form the FieldComm Group, which continues to oversee . Initial tests included evaluations at refineries like Exxon's facility. Adoption in refineries and plants accelerated post-, following the 2000 introduction of Host Interoperability Support Testing (HIST) and widespread deployment for reduced cabling and advanced diagnostics, as seen in expansions at BP's Sudbury .

Protocols for Building Automation

Fieldbuses for building automation primarily facilitate communication in non-industrial environments, such as (HVAC) systems, lighting controls, and security networks, with an emphasis on to accommodate varying building sizes and ease of integration across diverse vendor equipment. These protocols enable or client-server interactions that support energy-efficient operations and remote monitoring without the ruggedness required for industrial settings. Unlike manufacturing-focused networks, building automation fieldbuses prioritize user comfort, with legacy systems, and low-cost deployment over high-speed data transfer. LonWorks, developed by in 1989, represents an early protocol for distributed control in , leveraging chips that integrate three 8-bit processors for protocol handling and application execution. These chips enable devices to operate autonomously, forming a network suitable for HVAC, , and applications. LonWorks supports transmission over twisted-pair wiring or powerline carriers, allowing flexibility in retrofitting existing infrastructure. The protocol accommodates over 300 interoperable device types through standardized profiles defined by LonMark International, facilitating in large buildings. A key feature is the service pin, which, when pressed during commissioning, broadcasts the device's unique 48-bit Neuron ID to simplify network discovery and configuration. BACnet, formalized as ANSI/ASHRAE Standard 135 in 1995, adopts an object-oriented model to abstract building components like sensors, actuators, and controllers as standardized objects with and services. This approach ensures consistent representation across devices, promoting in HVAC, lighting, and systems. BACnet operates over networks such as BACnet/IP for Ethernet-based connectivity or MS/TP (Master-Slave/Token-Passing) for cost-effective serial links, supporting both local and wide-area deployments. It includes confirmed services, which require acknowledgment for reliable transactions like read/write operations, and unconfirmed services, such as event notifications, that enable efficient broadcasting without responses to enhance real-time . KNX, established in 1999 by the KNX Association through the merger of European standards EIB, BatiBUS, and EHS, is an open protocol for home and , particularly dominant in . It uses a twisted-pair bus at 9.6 kbps, supporting up to 57,600 devices in a multi-master for controlling , blinds, HVAC, , and . KNX enables centralized and decentralized configurations with ETS software for commissioning, ensuring vendor-independent and compliance with ISO/IEC 14543. Its adoption is widespread in residential and commercial buildings across for smart energy and comfort systems. In terms of adoption, BACnet holds dominant market share in North America (approximately 37% as of 2024), where it is the predominant protocol for new building automation installations due to its standardization and vendor support. LonWorks sees legacy use in Europe and smart grid applications, while KNX leads in European building controls.

Standardization Frameworks

IEC 61158 Specifications

The IEC 61158 series constitutes a multi-part that defines the , data-link layer, and specifications for various fieldbus communication protocols used in industrial automation networks. It establishes a framework for by specifying parameters such as ranging from 31.25 kbit/s to 1 Gbit/s, transmission media including twisted-pair cables, fiber optics, and options, and access methods like master-slave, , and producer-consumer models across more than 20 communication profile types (specifically up to Type 26). This structure ensures that devices from different vendors can communicate reliably in diverse industrial environments, promoting vendor independence without mandating proprietary implementations. The standard is organized into core parts that provide both general and type-specific definitions. IEC 61158-1 offers an overview and guidance, outlining the overall structure, relationships to other standards like IEC 61784, and the conformance for fieldbus systems. IEC 61158-2 details the specifications and service definitions, covering signaling, connectors, and cabling requirements to support robust data transmission over specified media. For the data-link layer, parts IEC 61158-3 and IEC 61158-4 define services and protocols, respectively, tailored to each communication type (denoted as -tt, where tt is the type number), handling framing, error detection, and . The is addressed in IEC 61158-5 (services) and IEC 61158-6 (protocols), enabling messaging for time-critical and non-time-critical operations between field devices and controllers. Evolution of the IEC 61158 series has incorporated advancements to address modern industrial needs, with editions updated through the to include Ethernet-based protocols and limited capabilities for enhanced flexibility in and . For instance, the 2023 edition of IEC 61158-1 reflects ongoing refinements to support higher-speed Ethernet integrations while maintaining with legacy fieldbuses. Notable communication profiles include Type 1, which specifies the H1 protocol for low-speed process control applications operating at 31.25 kbit/s over twisted-pair wiring, and Type 3, which defines for with bit rates up to 12 Mbit/s using physical media. These profiles exemplify the standard's role in standardizing diverse topologies to foster open, scalable systems.

IEC 61784 Profiles and Extensions

The IEC 61784 series establishes profiles that extend the foundational specifications of IEC 61158 by defining practical communication profile families (CPFs) tailored for industrial applications, ensuring and performance in fieldbus systems. These profiles map specific protocol implementations to the base layers of IEC 61158, addressing real-world needs in and process control without altering the core and physical layers. By grouping protocols into families, IEC 61784 facilitates device design and network integration, promoting standardized subsets that enhance reliability and scalability in environments. IEC 61784-1 focuses on digital data communication profiles for continuous and , defining CPFs that specify protocol subsets derived from IEC 61158 types. For instance, Communication Profile Family 1 (CPF 1) encompasses profiles for (FF), enabling seamless integration in process automation by outlining device behavior, conformance requirements, and application interfaces. Other families, such as CPF 3 for and , provide similar mappings to support factory automation, ensuring that devices adhere to defined communication rules for data exchange. This part emphasizes non-safety-related profiles, prioritizing ease of implementation across diverse fieldbus topologies. IEC 61784-2 addresses real-time Ethernet solutions by specifying CPFs for deterministic communication over Ethernet, crucial for time-critical industrial tasks. It includes profiles for with Isochronous Real-Time (IRT) capabilities in CPF 3, EtherCAT in CPF 12, and in CPF 2, each detailing mechanisms for low-latency data transfer and . Conformance classes within these profiles—such as Class A for basic real-time Ethernet, Class B for enhanced , and Class C for isochronous performance in —allow vendors to certify devices at varying levels of real-time capability, ensuring predictable below 1 ms for applications. These extensions bridge traditional fieldbus limitations with Ethernet's bandwidth advantages. IEC 61784-3 defines communication profiles (FSCPs) that integrate safety layers atop existing fieldbus protocols, aligning with requirements for safety integrity levels (SIL 1 to SIL 3). Notable examples include PROFIsafe (IEC 61784-3-3) for and , which employs black-channel principles to transmit safety data without modifying the underlying network hardware, and SafetyNET p (IEC 61784-3-20) for open safety architectures in . These profiles incorporate error detection mechanisms like cyclic redundancy checks and safe parameters to prevent hazardous failures, enabling certified safety functions in distributed systems. Recent amendments, such as IEC 61784-3:2021/AMD1:2024, further refine safety communication principles. Compliance with IEC 61784 is enforced through certification processes managed by organizations such as & International (PI) for PROFIBUS/PROFINET profiles and the Open DeviceNet Vendors Association (ODVA) for and CIP Safety. These bodies conduct interoperability tests and issue conformance certificates, verifying adherence to specified CPFs and conformance classes to guarantee plug-and-play functionality in multi-vendor environments. Ongoing updates as of 2025 aim to incorporate enhancements for (IIoT) integration, including support for (TSN) in Ethernet profiles to achieve sub-microsecond determinism for converged IT/OT networks. TSN extensions in IEC 61784-2 enable precise time synchronization and , addressing previous gaps in non-deterministic Ethernet for safety-critical IIoT applications.

Technical Implementation

Network Architecture

Fieldbus networks are structured to enable reliable connectivity between field devices such as sensors, actuators, and controllers in industrial environments, typically employing a multi-drop bus configuration that supports deterministic exchange. The physical and logical emphasizes simplicity and robustness, allowing for the integration of diverse devices while maintaining over extended distances. This setup contrasts with traditional point-to-point wiring by reducing cabling complexity and enabling shared communication channels. Common topologies in fieldbus systems include the linear bus, where devices connect sequentially along a single cable backbone, facilitating straightforward installation in process plants. Tree topologies extend this by branching from the main bus using couplers or junctions, while ring configurations provide by looping connections back to the source, enhancing in critical applications. amplify signals to extend segments, and segmenters isolate sections for or hazardous area compliance, allowing networks to span larger areas without performance degradation. Cabling primarily utilizes twisted-pair copper wires for cost-effective transmission, supporting data rates up to several Mbps while minimizing through shielding. Fiber optic media offers immunity to electrical and longer transmission distances, suitable for high-speed or electrically harsh environments, whereas options like modules enable flexible deployment in inaccessible locations. Maximum segment lengths vary by medium and speed; for instance, twisted-pair in DP achieves up to 1200 meters at 93.75 kbps. Device integration relies on standardized addressing schemes, such as unique node addresses from 0 to 125 in , assigned during configuration to prevent conflicts and ensure precise targeting. Gateways facilitate connectivity to higher-level networks like Ethernet, translating fieldbus protocols to IP-based systems for enterprise integration, often via linking devices that bridge segments. Scalability accommodates from as few as two nodes in simple setups to over 126 devices across multiple segments, limited by addressing ranges and power budgets but expandable via . For protocols like H1 and PA, power distribution concepts often involve supplying 24V DC directly over the bus cable, powering devices alongside data signals in a single pair, which simplifies wiring but requires careful budgeting to avoid voltage drops in longer runs. In modern implementations, hybrid architectures incorporate IoT gateways to merge legacy fieldbus with wireless protocols, enabling cloud connectivity and remote monitoring while preserving wired reliability for real-time operations. These additions address evolving needs in Industry 4.0, supporting seamless data flow from field devices to platforms.

Communication Mechanisms

Fieldbus systems employ various access methods to manage shared medium contention among devices, ensuring reliable transmission in industrial environments. Polling, often implemented in master-slave configurations, involves a central master device sequentially querying slaves for , providing deterministic access with predictable response times but potentially introducing latency if many devices are present. circulates a control token among devices, granting exclusive transmission rights and offering high suitable for time-critical applications, though it requires careful to avoid token loss. In contrast, Carrier Sense Multiple Access with (CSMA/CD) allows devices to transmit when the medium is idle, detecting and resolving collisions, but its nondeterministic nature can lead to variable delays, making it less ideal for real-time control compared to polling or token methods. Communication in fieldbuses distinguishes between cyclic and acyclic message types to balance regular process exchange with occasional events. Cyclic messages transmit periodic process , such as readings or commands, using a publisher-subscriber model where a publisher broadcasts once, and multiple subscribers receive it without individual acknowledgments, enabling efficient, deterministic updates for control loops. Acyclic messages handle non-periodic information like diagnostics, alarms, or configuration changes, typically via client-server interactions that request and respond on demand, ensuring flexibility for maintenance tasks without disrupting scheduled traffic. Error handling mechanisms in fieldbus networks maintain through detection and recovery protocols. Timeouts monitor response delays, triggering alerts or retries if a device fails to acknowledge within a predefined interval, preventing stalled communications. Retransmissions resend failed messages, often managed by a scheduler that attempts delivery up to a set limit before declaring failure, enhancing reliability in noisy environments. Heartbeat signals, such as periodic pulses, verify device liveness and clock alignment, allowing the network to detect and isolate faults proactively without relying solely on timeouts. Bandwidth allocation strategies in fieldbuses differentiate between fixed and dynamic approaches to optimize use. Fixed allocation reserves dedicated slots or channels for critical , including isochronous channels that guarantee synchronized, time-bound delivery for , minimizing in control applications. Dynamic allocation adjusts capacity on demand for variable loads, such as aperiodic messages, but requires mechanisms like reserved time slots to avoid overloading the segment and ensure . Performance metrics in fieldbus systems emphasize low latency to support closed-loop control, typically achieving end-to-end delays under 10 ms for process variables in manufacturing . As of 2025, emerging integrations of networks in industrial settings leverage ultra-reliable low-latency communication (URLLC) to extend wired to segments, enabling latencies under 10 ms for mobile assets while maintaining compatibility with legacy topologies such as bus or ring structures through hybrid architectures.

Advantages and Applications

Economic Benefits

Fieldbus systems offer substantial economic advantages over legacy analog wiring setups by minimizing material and labor requirements during installation. Traditional configurations often necessitate hundreds of individual cables for connecting field devices, whereas a single fieldbus cable can replace them, enabling multi-drop connections that streamline deployment. This reduction in wiring can cut installation costs by 30-40%, as evidenced by implementations where and cabling expenses are lowered through simplified layouts and fewer terminations. For instance, in industries, fieldbus adoption has demonstrated up to an 81% decrease in terminations compared to 4-20 mA systems, further amplifying savings in labor and materials. Maintenance costs are also markedly reduced through integrated diagnostics and predictive capabilities inherent to fieldbus protocols. Built-in device diagnostics allow for remote monitoring and early fault detection, which can decrease unplanned by enabling proactive interventions and cutting unnecessary maintenance activities by up to 63%. Asset management features, such as those in , facilitate that offsets reactive repairs, potentially lowering overall instrument maintenance expenses by as much as 50%. These efficiencies translate to operational reliability, with studies indicating 30% or more reductions in maintenance labor across the system lifecycle. The scalability of fieldbus enhances (ROI) by simplifying expansions and modifications without extensive rewiring, thereby lowering capital expenditures (CAPEX) for future upgrades. In large-scale applications like refineries, such as the Reliance Jamnagar Refinery in , fieldbus implementation supported efficient scaling across thousands of segments with minimal disruptions, contributing to significant wiring and commissioning savings. Commissioning times can be halved, from hours to minutes per device, supporting agile project adjustments. Over a typical 10-year lifecycle, these factors offset the higher initial device costs—often 20-30% more than analog equivalents—yielding (TCO) reductions of 30% or greater through cumulative savings in installation, operations, and . Recent TCO analyses for Ethernet-based fieldbuses, such as , affirm similar long-term benefits in 2020s industrial settings, with wiring and diagnostic efficiencies driving significant overall savings despite evolving network demands. In 2025, protocols dominate new installations in , accounting for 76% of nodes, with and together representing over 50% of that share— at 27% and at 23%. Traditional fieldbus protocols have declined to 17% overall, though maintains a significant presence in automation due to its reliability in continuous operations. Regional adoption patterns reflect established ecosystems: favors and for their integration with automation standards, while leads with , driven by compatibility with systems. In , adoption is diverse, with and gaining ground alongside legacy protocols like CC-Link and CAN-based systems in automotive and machinery sectors. Growth in fieldbus and related technologies is propelled by Industry 4.0 initiatives and the convergence of (IIoT), facilitating exchange and ; the market is projected to expand at a 7.7% (CAGR) through 2030, with migration from legacy fieldbus to Ethernet-based systems accelerating this trend. Key challenges include heightened cybersecurity vulnerabilities, exacerbated by post-2020 incidents targeting industrial control systems (ICS), such as attacks on (OT) networks, prompting stricter regulations. Additionally, the rise of wireless fieldbus options like ISA100.11a is addressing cabling limitations in hazardous environments, with adoption increasing in process industries for its and features. Looking ahead, (TSN) integration with fieldbus protocols is enabling deterministic communication in 5G-enabled smart factories, further solidifying Ethernet's dominance beyond 70% of new installations by enhancing convergence between OT and IT systems.

References

  1. https://www.sciencedirect.com/topics/computer-science/fieldbus
  2. https://www.fieldcommgroup.org/technologies/foundation-fieldbus/foundation-technology-explained
  3. https://webstore.iec.ch/en/publication/19158
  4. https://www.isa.org/getmedia/42b5f039-e339-4c78-9710-1853f093d162/FoundationFieldbus-4thed_Verhappen-Pereira_Chapter1.pdf
  5. https://www.isa.org/getmedia/ec938d63-ccd5-4022-9a90-2baf5a616d34/Fieldbus-for-Process-Control_Berge_Chapter1.pdf
  6. https://assets.new.siemens.com/siemens/assets/api/uuid:3741da47-17f8-4d9c-b502-cc0da93df533/catching-the-process-fieldbus-2nd-edition.pdf
  7. https://literature.rockwellautomation.com/idc/groups/literature/documents/rm/rsfbus-rm001_-en-p.pdf
  8. https://www.hilscher.com/service-support/glossary/fieldbus
  9. https://instrumentationtools.com/history-3-15-psi-10-15-ma-4-20-ma-signals/
  10. https://www.thechemicalengineer.com/features/taking-a-look-back-at-control-part-1/
  11. https://www.isa.org/intech-home/2020/september-october/features/top-tech-75-years-of-automation-milestones/
  12. https://www.amplicon.com/actions/viewDoc.cfm?doc=GPIB-White-Paper.pdf
  13. https://www.hp9845.net/9845/tutorials/hpib/
  14. http://www.bitbus.org/faq.htm
  15. https://www.researchgate.net/publication/4232327_Fieldbus_Technology_and_Industrial_Automation
  16. https://felser.ch/papers/FE-TR-0203.pdf
  17. https://www.researchgate.net/publication/228733981_The_fieldbus_standards_History_and_structures
  18. https://www.emerson.com/documents/automation/article-fieldbus-years-en-37672.pdf
  19. https://www.prosoft-technology.com/kb/assets/intro_modbustcp.pdf
  20. https://www.modbustools.com/modbus.html
  21. https://www.profibus.com/technologies/profibus
  22. https://www.profibus.com/fileadmin/media/downloadsection/PROFIBUS_Systembeschreibung_ENG_web.pdf
  23. https://datasheet.octopart.com/2753698-Phoenix-Contact-datasheet-12864978.pdf
  24. https://www.bosch.com/stories/the-controller-area-network/
  25. https://www.ti.com/lit/pdf/sloa101
  26. https://www.bosch-semiconductors.com/media/ip_modules/pdf_2/m_can/mcan_users_manual_v331.pdf
  27. https://www.odva.org/technology-standards/key-technologies/devicenet/
  28. https://www.samsongroup.com/document/l453en.pdf
  29. https://www.bh-automation.com/Download/Resources/world-fip-protocol.pdf
  30. https://core.ac.uk/download/80916539.pdf
  31. https://www.fieldbusinc.com/downloads/primer1_1.pdf
  32. https://www.prelectronics.com/articles/understanding-profibus-and-its-role-in-industrial-automation/
  33. https://web-material3.yokogawa.com/TI38K03A01-01E.pdf
  34. https://www.knx.org/knx-en/for-professionals/What-is-KNX/A-brief-introduction/
  35. https://www.mordorintelligence.com/industry-reports/united-states-commercial-building-automation-market
  36. https://cdn.standards.iteh.ai/samples/100312/214d4c8548084087b2c840d5e58591dd/IEC-61158-1-2019.pdf
  37. https://www.felser.ch/download/iec_61158_fieldbus.html
  38. https://webstore.iec.ch/en/publication/59890
  39. https://webstore.iec.ch/en/publication/66931
  40. https://webstore.iec.ch/en/publication/83413
  41. https://www.fieldbusinc.com/downloads/fieldbus_comparison.pdf
  42. https://webstore.iec.ch/en/publication/83453
  43. https://www.felser.ch/download/iec_61784_profiles.html
  44. https://webstore.iec.ch/en/publication/83454
  45. https://webstore.iec.ch/en/publication/83456
  46. https://webstore.iec.ch/en/publication/66930
  47. https://www.profibus.com/fileadmin/media/downloadsection/supplementary_document/PNIO-CCs_7042_V11_Mar11.pdf
  48. https://www.ti.com/lit/pdf/ssztbz0
  49. https://webstore.iec.ch/en/publication/92216
  50. https://cdn.standards.iteh.ai/samples/102400/e9bb73647da146b3bcab99e5af8873dd/IEC-61784-5-2-2018.pdf
  51. https://webstore.iec.ch/en/publication/68894
  52. https://webstore.iec.ch/en/publication/62095
  53. https://us.profinet.com/documents/system-description-profisafe-technology-and-application/
  54. https://webstore.iec.ch/en/publication/79055
  55. https://www.profibus.com/fileadmin/media/downloadsection/installation_guide/PROFIsafe-Environment_2232_V26_Dec15.pdf
  56. https://www.odva.org/wp-content/uploads/2020/05/PUB00213R0_EtherNetIP_Developers_Guide.pdf
  57. https://www.odva.org/news/ethernet-ip-concurrent-connections-for-critical-applications-now-available-with-cip-safety/
  58. https://www.ethercat.org/en/downloads/downloads_7F993A551FBC4B65AA8F4279E863E953.htm
  59. https://www.profibus.com/fileadmin/media/downloadsection/installation_guide/PROFIBUS_Design_Guideline_8012_V129_Sep20.pdf
  60. https://www.embien.com/industrial-insights/profibus-protocol-communication-profiles-and-physical-layers
  61. https://www.profibus.com/technology/profibus/
  62. https://www.celduc-relais.com/en-us/fieldbuses/
  63. https://www.fieldcommgroup.org/sites/default/files/imce_files/technology/documents/FCG_TR10365%257B1.0.1%257D_FF_Ethernet-APL-Migration.pdf
  64. https://www.fieldcommgroup.org/technologies/foundation-fieldbus
  65. https://www.designnews.com/motion-control/connecting-wired-and-wireless-fieldbus
  66. https://jee.ucg.ac.me/index.php/files/article/view/202
  67. https://www.emerson.com/documents/automation/training-fieldbus-communications-en-41108.pdf
  68. https://www.researchgate.net/publication/226794324_A_Bandwidth_Allocation_Scheme_in_Fieldbuses
  69. https://www.spice.rwth-aachen.de/assets/pdf/michaelides2025industry5G.pdf
  70. https://us.profinet.com/white-papers/why-use-a-fieldbus/
  71. https://web-material3.yokogawa.com/reducing-lifecycle-costs-with-the-power-of-fieldbus.pdf
  72. https://www.nrc.gov/docs/Ml0913/ML091320121.pdf
  73. http://www.plant-maintenance.com/articles/fieldbus_asset_management.pdf
  74. https://www.emerson.com/documents/automation/article-fieldbus-success-stories-strategies-deltav-en-56346.pdf
  75. https://www.hms-networks.com/news/news-details/27-05-2025-hms-networks-report-industrial-trends-2025
  76. https://www.sciencedirect.com/science/article/pii/S108480452500270X
  77. https://www.archivemarketresearch.com/reports/fieldbus-solutions-for-process-479767
  78. https://5g-acia.org/whitepapers/integration-of-5g-with-time-sensitive-networking-for-industrial-communications/
Add your contribution
Related Hubs
User Avatar
No comments yet.