How is data transported from the field level and made accessible to higher-level systems? What does the future of fieldbuses look like?
In the second part of our field article series, we explain which properties, possible uses and future prospects characterize fieldbuses.
In the early days of industrial automation, parallel wiring was used for data transmission. However, as the level of automation increased, so did the number of communication participants. The ever-increasing cabling effort was largely replaced by more cost-effective and faster fieldbus systems.
Field buses are mainly, but not exclusively, used in the field of automation and have become an integral part of more complex machines and systems. They can be used to connect sensors and actuators, also known as field devices, to control devices such as a PLC. Examples of field devices are motors, switches or drives.
A fieldbus is essentially characterized by two main components: the physical component, which represents the type of wiring and connection, and the coding used to define the data transmission. The network topology used plays a further role, but this is not a primary property of the fieldbus.
Typically, the fieldbus consists of quite simple hardware. A simple and at the same time cost-effective copper wire connection is usually sufficient. The fact that this approach is particularly cost-effective has led to fieldbuses becoming so widespread. In modern systems, in addition to conventional cabling, other connection media are now also possible, such as Ethernet, but also fiber optics, or wireless via WiFi.
Nadine Mensdorf, Product Management, SYS TEC electronic AG
However, the differences in the bus-specific coding in particular ensure the unwanted diversity. Depending on the fieldbus used, the data handling and the transmission behaviour differ. This includes, among other things, how telegrams, control commands, send and receive behavior are implemented and transmitted. It also differs which tools are used to ensure the reliability and security of data transmission and which measures are taken to prevent or correct misconduct.
For example, the use of checksums after a transmission has been completed can be used to determine data integrity, i.e. whether all packets have arrived. Strictly controlled access behavior can prevent more than one field device from sending simultaneously on the bus and data packets from colliding with each other or from arriving and being lost. These include the master-slave method, clock- or time-based access methods, or collision detection.
Prominent fieldbus representatives are Modbus, CAN/CANopen, Profibus, Profinet, EtherCat, Ethernet PowerLink or Ethernet/IP.
The different characteristics ensure that each fieldbus speaks its own language. As a result, different fieldbuses are completely incompatible with each other. Communication can only be made possible with the use of so-called gateways.
Gateways act as translation units between two fieldbus networks. You can translate the messages from Fieldbus A for use with Fieldbus B. They often also offer the option of sending data directly from the fieldbus to higher-level control systems. For example SCADA, MES and ERP systems.
A fieldbus is therefore used where data must be transmitted quickly, reliably and safely. These are then passed on to control systems, but are also required by higher-level control systems for evaluations. This means that field devices are usually used in relative proximity to regular network infrastructures.
Modern machines now often have their own Ethernet connection. Internally, these usually continue to use conventional fieldbuses, but these are no longer visible to the outside world.
The use of Ethernet interfaces makes it easier to connect newer machines to the existing infrastructure, since they do not have to be connected via additional gateways. This makes them more cost-efficient overall. In addition, regular Ethernet is much faster and enables a higher data rate.
Another reason why Ethernet moves into the field level so late is historically due to the development of microcontrollers. Especially since the required performance was not given, but also because of the higher price, microcontrollers with Ethernet interface were not attractive. In the last years this has changed more and more. The now very high computing power in such a small space enables very uncomplicated and affordable Ethernet capability. It is now also possible to realize Ethernet connections directly to the sensor.
Despite all positive developments in Ethernet use, gateways are still needed for a longer period of time. Usually, automation systems are only modernized piece by piece and not completely. This also results in a colorful mixture of different fieldbuses and networks.
The transfer of data to higher-level control systems has already been addressed. But what does that mean? With regard to the automation pyramid, fieldbuses are only located on the first two levels.
For all layers above, the actual fieldbus becomes relatively uninteresting, since from this point on it is mainly a matter of using the data, regardless of which fieldbus is used for transmission.
This data can then be made available to higher-level systems for further processing and evaluation, for example, for predictive maintenance. With predictive maintenance, the connection between the fieldbus - control system - control level provides status data from the machines for predictive maintenance of the systems. But a connection with SCADA, MES and ERP systems or a cloud is also conceivable.
Before the data can be transferred from the fieldbus, however, the corresponding packages must first be cleaned of transport-specific content and standardized.
The packets transmitted via the fieldbus are typically not passed on in raw form, but reduced to the relevant data. The content that is no longer required includes, for example, bus-specific coding. This data is forwarded via protocols such as MQTT and OPC-UA. MQTT, for example, only requires a data value (payload) and a corresponding affiliation (topic) and transmits both in a bundle. This can then be recorded relatively easily and reused.
This task can only be performed partially or insufficiently by the gateways already mentioned, since here not only a pure translation of the data is necessary, but also the preparation, standardization and extension of information.
That's where the so-called edge controllers are used, like our sysWORXX CTR-700. Similar to gateways, these can take over the translation of different fieldbuses, but can also process the data at the same time and forward it in a standardized way. In addition, they displace the conventional programmable logic controllers, as this role can also be taken over by an edge controller. In addition, they also implement tasks from the control level, in which they can react, for example, to previously defined threshold values with warnings and alarms. Thus they also enable an evaluation of the data and rule-based control protocols.
The sysWORXX CTR-700 can receive data directly from the field level, process it accordingly and then forward it via defined interfaces such as Ethernet, CAN,
OPC UA, etc. to higher systems, e.g. ERP systems. In addition, it offers various software packages from other manufacturers. For example, Node-RED is available by default. In addition, a secure remote maintenance access can be enabled by the TeamViewer-IoT client.
With this and other devices we stand as a service provider and device manufacturer for automation solutions exactly between field and control level. On request, this also enables individually adapted integration of the devices into the existing infrastructure.
