The end of the Fieldbus Wars?

A heckling from Martin Rostan, Executive Director, EtherCAT Technology Group. This article provides a strong opinion on the state of the Fieldbus Wars by a veteran in this industry, but does not necessarily refect the views of the Industrial Ethernet Book and its staff.

“THE TIME OF THE FIELDBUS WARS IS OVER. Finally, there will be the one universal communication standard supported by everyone. All devices will be interoperable and third-party manufacturers can confgure them without trouble: conformance tested and certifed. The new standard will be stable immediately.

Hence, there won’t be any versioning problems – at least, all versions will be completely downward compatible. Performance won’t be an issue, either, since the new technology is much quicker than all existing ones. The implementation of the devices will be easy to realize just by using standard chips since one relies on IT standards consistently.

This is also why costs will be reduced. IT know-how won’t be necessary for the start-up engineer and cyber security won’t be a challenge anymore, too, because the process data will be encrypted and each sensor will have a certifcate, which updates itself automatically on a regular basis.

The feldbus organizations will be obsolete – there’ll only be one single standard. And do not forget, by the end of 2019 the necessary products will be available and plants can be realized with the new standard. All that is possible because of the OPC Foundation with its new Field Level Communications (FLC) initiative.”

This is, approximately, the current dream that is being promoted as reality by the marketing departments of some protagonists. Finally, all of the world’s big players in automation are part of one initiative. What could be better than that?

Speaking frankly

I think it’s time to pour some cold water on this matter!

Let’s begin with the current members of the FLC Steering Committee. Together the 23 frms have a great market share in the automation market, but they defnitely have different interests. From my point of view, there are four groups.

The first group comprises the losers of the last feldbus war. Their own industrial Ethernet solutions weren’t accepted, so they are currently searching for a successor. The second group thinks that OPC UA is a suitable technology for the communication between controls but favors another bus system below the control – and will surely not give up that system for OPC FLC. The third group wants to sell components and chips to the others.By the way, their members naturally have very low interest in a growing system based on standard IT components.

And the fourth group is probably the largest: I call this the FOMO (“Fear Of Missing Out”) group, and its members think, ‘What if there’s something meaningful happening without us? Let’s join them, just in case…’

But who belongs to which group? The members of the frst group naturally shout the loudest for the initiative. Here, history shows that not every howling wolf leads to realization or even market penetration.

So far, Beckhoff and KUKA have said most clearly that they’ll sustainably support OPC as a relevant and open communication standard, but, of course, will continue to use EtherCAT below the controller for IO and motion control. It seems that Siemens, Rockwell and Mitsubishi plan to take a similar route.

I can absolutely not imagine that those companies would turn their system architecture upside down and sacrifce their industrial Ethernet technologies PROFINET, EtherNet/IP and CC-Link IE on the altar of FLC. From the user’s point of view, that’s good. The technological competition between the systems is essential to drive the technologies.

Speaking of performance

The fairytale that OPC UA with TSN is 18x faster than all existing systems doesn’t become more true by just repeating it over and over. We asked one of the few automation experts from the IEEE 802.1 TSN task force to recalculate it. In all machine control scenarios, even a single 100 Mbit/s EtherCAT segment reaches shorter communication times than Gigabit Ethernet networks upgraded with TSN elements.

Namely, independent from the used protocol and under the optimistic (and non-standard) assumption that TSN comes with cut-through switching. Dividing the EtherCAT segment, 100 Mbit/s EtherCAT beats every Gbit/s TSN system by far. Which user would prefer a Gigabit physical layer for drives, I/Os and sensors if he/she can have better (or only suffcient) performance on a 100Mbit/s basis? For this reason, the TSN approach of the EtherCAT Martin Rostan has worked in industry communication for 27 years. For 14 years he has served as Executive Director of the EtherCAT Technology Group. His strongly stated opinion is that he thinks that the currently much described expectations from OPC UA and TSN are infated. Plus, the system will be available only in a few years. Let us know your thoughts on this technology: editor@iebmedia.com.

Technology Group (ETG) as well as EtherCAT G technology, which will be brought into ETG by Beckhoff in September 2019, combine a Gbit/s backbone with 100 Mbit/s EtherCAT feld devices, which remain unchanged.

Additionally, with TSN we have to expect a new level of complexity. Right now, the OPC TSN approach is building on seven IEEE 802.1 standards and has already produced seven additional relevant standards, and others will follow. The IEEE 802.1 Q standard alone has a count of 2,000 pages. OPC UA itself contains 14 standards with three newly added extensions.

We may not forget that devices must be tested for their conformance to all those standards comprehensively. Compared to that, the current feldbus standards are almost lean. No wonder that, differently from the feldbuses, there are no experts to be found who know about the whole architecture.

This leads us to stability and versioning. I think it’s fancy to suggest implementing OPC FLC ‘step by step’; Missing technology modules could just be ‘reloaded’ in the feld.

A selection of the IEEE TSN standards – more are in progress. EtherCAT will use the frst three technologies to make the EtherCAT Automation Protocol for connecting controls real-time capable and to connect EtherCAT segments with TSN networks.

For a Tesla driver, it might be quite hip to fnd a new feature in the driver assistance system when he turns on his car in the morning, but brakes, lights and the steering wheel should be there at delivery. One cannot reload hardware. And to upgrade system features via frmware updates in the feld only works halfway reliably, when all devices come from the same company. But maybe this is exactly what is desired?

By the way

With EtherCAT, neither the one nor the other is required. Although many new features have been added over time, there’s only one version of the protocol. Current devices can run without problem in plants installed in 2004. Also, interoperability with EtherCAT is not a dream of the future but proven thousands of times.

Just like the available device variety, more than 2,000 registered manufacturers of EtherCAT devices send a clear signal. By the way, 94 percent of the automation suppliers in the OPC FLC Steering Committee already offer EtherCAT products that are available today and proven in the feld.

Experience shows

Everything takes longer than originally expected. Much longer. Even in the foreseeable future this cannot be asserted about TSN seriously. The IEEE standard that is relevant for time synchronization and thus for all other real-time features is currently again in the discussion phase. Approaches for vendor-independent configuration are at a very early stage. The frst TSN chips for devices and some 3-porters with preliminary features were shown at the Embedded World show last February. A few multiport-chips were claimed to be shipping, but one could not fnd any market-released TSN switches with these products in the show or on the web.

But this does not really matter yet, since most parts are completely missing on the software side. OPC UA PubSub was released in 2018 and has been modifed by an amendment this year. But to date there are neither network management nor device profles. However, OPC UA PubSub wasn’t planned to be a feldbus system either.

Thus, the specifcation OPC UA for Devices (DI) is not a device profle, but describes how you can write one. So far there’s not even an I/O profle and nor are there profles for modular I/O devices or drives. Also the whole ecosystem needs to be built up frst: support and training, conformance testing and certifcation, etc.

I have focused primarily on the development and promotion of fieldbus systems on a professional level for 27 years now and think I can count myself as a veteran of the feldbus wars. And experience shows that everything takes longer than expected originally, much longer.

But also OPC Field Level Communications and its ecosystem, too, will be completed one day and possibly even be halfway stable. But that will take a few more years – not months.

Combined with Time Sensitive Networking, it will reach a performance level that will be suffcient for some applications of today’s standard. And it will oust some of the feldbus war losers – but not the winners who are accepted and used all over the world for good technical reasons. And this is in the best interest of the users.

EtherCAT has not achieved its incredible success because so many companies support it, but rather so many companies support EtherCAT because it is technologically convincing. It’s also not clear what the advantage is of an OPC FLC TSN IP65 box with 8 digital inputs and not yet standardized 8-pole M8 connectors and an unfavorable energy balance due to Gbit/s Ethernet in contrast to an EtherCAT device that is faster even today.

The potential of TSN is signifcantly higher for the networking of production lines where synchronized controls and low latency times can coordinate interactions among machines much better. That’s where TSN technologies belong and that’s where they’ll be used by EtherCAT.

Dipl.-Ing. Martin Rostan, Executive Director,

EtherCAT Technology Group.