During the last two decades, fieldbus has completely transformed the way communication takes place in the fields of manufacturing industries. The contemporary launch of real-time fieldbuses has opened up its functionality within the multi-axis motor control and other time-critical applications. Fieldbus has been primarily designed to establish easy interoperation, smarter network designs, increased data accessibility and minimised stress on the design facets of safety protocols.
It has been observed that we often use Ethernet LAN for all our regular connectivity in our offices, so why do manufacturing industries not follow the same protocol? In this contemporary era of Industry 4.0, where connectivity plays an integral role, and IIoT is on every program, how beneficial are the fieldbuses? If there are so many available fieldbuses, how do control elements manage to communicate with one another? Or how is the serious topic of interoperability addressed?
The primary objective of a fieldbus was to restore any point-to-point links between sensors to PLCs or CNCs or other controllers. The fieldbus further explains the electrical features of the connection and also demonstrates the protocol. With the presence of flexible electronic modules, the attention to electrical characteristics has diminished, and observation of protocols has seen a surge.
Electrical features, protocol & standardisation
Fieldbuses can be further undisclosed by several features or characteristics. Mostly under this circumstance, one checks for speed (bit-rate), number of nodes authorised (single-master, multi-master), flexibility in topology (linear, multidrop, ring, tree, star), enhanced presence (redundancy), methods of data seizing (polling, cyclical, event initiated), how new nodes can be implemented (system reset, on-the-fly), how fall-out of one or more nodes can be distinguished and corresponding recovery processes and so on.
The process of communication protocols is the set of rules and regulations which helps to further define the different syntax elements and the ‘grammar’ – the position of all the present elements, the recognised values and the importance of the same. By following a certain kind of protocol, it becomes easily possible to commence a particular communication, various flag errors in communication, analyse a broken communication and come up with a suitable solution to recover from the break. Also, to be more specific, communication protocols should be made common across vendors to make their job of maintenance and spares easy. Yet, the world of fieldbuses is a genuine Tower of Babel, and the species and sub-species of protocols that are categorised can easily be analogised with the same branch, mostly not quite compatible with each other.
Why are there so many fieldbuses available?
It has been observed that due to the massively diversified variety of application areas and equally varied demand on the properties, a large number of fieldbuses have sprung up. As a result, manufacturers usually define and develop their process in order to attain the best execution process from their products.
The various diverse application areas that are available in this area are process plants, building automation, discrete manufacturing and, to some smaller extent, safety automation, and also, sub-species emerged from specific industries, like power generation, oil & gas, automobiles, breweries, and so on. The area of sensors (this was called the ‘field’ and hence, comes the name, fieldbus) certainly have their buses that various manufacturers are significantly using.
As we all further explore the world, along the process of intoning, there are just too many protocols for comfort available. But essentially, what is desired in this process is interoperability. That means no matter what bus proactively runs as the backbone in the plant, a sense of freedom should be available to continue to buy and connect a device from any vendor, and the system should be further able to talk to this new device and vice-versa.
The fascinating aspect of this particular process is that interoperability can be achieved at various levels. Here what we can do is, we can take some relevant reference model from ISO, the famous seven-layer model. The communication stack is abstracted into seven layers – a standard called The Basic Reference Model for Open Systems Interconnection. What’s more, we can show interoperability for two devices at any one or more of the seven layers. The task of protocol conversion gets shifted to the next higher level.
Over a period of time, many endeavours were initiated to appear at a standard protocol. This gave rise to many ‘standard’ protocols – vendors’ standard protocols, buyers’ standard protocols, industry body standard protocols. However, for a few organisations, the usual association of vendor manufacturers has evolved standards – which means an agreement among their members has been mutually done. In the further detailed nature of things, these members, after achieving the mutual agreement, go ahead and, during the implementation process, provide an ultimate additional feature of their own to give special benefits. Unfortunately, these add-ons prevent complete interoperability.
Open protocols & focus of Industry 4.0
A different approach is to provide the entire protocol stack in the public domain. With this, every manufacturer has a possibility to incorporate compatibility into his devices with such a protocol without having to pay any license or royalty fees. The open-source approach has many enthusiastic followers. But if manufacturers would push in add-on features on the top of this definition, once again, we have some incompatibility.
Besides, Industry 4.0 is a new era in manufacturing and business. The focus of today is to extract value out of data for various purposes. One important strategy is the aggregation of data from various sources and recording it together with the context of data creation.
Interplay with data systems
In this era of Industry 4.0, we are hungry for data. The requirement of data for these purposes is very different from the real-time deterministic demands of operation and control. However, the data sources are quite nearly the same, so we should see many changes in the times to come. Since Industry 4.0 lays a strong emphasis on collaboration end-to-end along the value chain, there has to evolve better ways to share data.
The emergence of the Industrial Internet of Things (IIoT) and new possibilities for connectivity with wireless and Ethernet are changing the protocol landscape. New value in integrating public and private enterprise clouds, operational systems and business domains present new protocol harmonisation opportunities in industrial environments. Deployment of wireless in the shop floor is in the beginning stages. A number of protocols have already sprung up, such as LoRA, ZigBee, Wireless HART etc.