Mr. Rostan, why does Ethercat need an extension like Ethercat G at all?

Martin Rostan: Thanks to the higher bandwidth, Ethercat G extends the useful application range of our technology to particularly 'data-hungry' devices. The decisive factor here is that the protocol itself remains the same with Ethercat G. For Ethercat controllers, therefore, nothing changes initially: if they have a Gbit/s Ethernet interface, they can use Ethercat G immediately and without any software changes. The additional extension with so-called branch controllers leads to two important additional features: Firstly, bit rates can be mixed, i.e. 100 Mbit/s segments can be operated below a Gbit/s 'backbone' - and this can also be scaled up to 10 Gbit/s accordingly in the future with Ethercat G10.

Secondly, the branch controllers also allow the parallelization of telegram processing: as each frame no longer has to be routed through all network participants, this results in a considerable performance gain. With a Gbit/s backbone and 100 Mbit/s field devices throughout, we become around five times faster, with Gbit/s field devices even around seven times faster. In other words: even with the proven Ethercat field devices based on the robust 100 Mbit/s technology, a new level of performance is achieved with the Ethercat G extension.

Who exactly benefits from Ethercat G?

Martin Rostan: Basically all manufacturers and users of today's Ethercat devices, because they get a further, significant increase in performance without having to make any changes to their existing devices. In particular, for example, the manufacturers of cameras or high-end measurement technology components, for which Ethercat is now even better suited. Or suppliers of particularly sophisticated motion control devices, who benefit from the shorter cycle times and the associated even shorter control dead times.

Following the recent launch of Ethercat G in the ETG, what are the next steps?

Martin Rostan: Ethercat G and G10 are already well developed, but not yet finalized in every detail. The focus in the ETG is now on the specification work for the branch controller extension. Much of it is already finished, but we still need a few months to complete it. Of course, the corresponding extensions to the test specifications and the test tools, the incorporation into international standardization and so on are all part of this - everything that belongs to a proper fieldbus ecosystem.

Now there is also TSN and the ETG has already published a corresponding specification. How does this fit in with Ethercat G?

Martin Rostan: Our TSN activities are not losing any of their importance as a result of Ethercat G: We continue to see TSN technologies as an important addition to Ethernet, are an official liaison partner of the IEEE and were the first major fieldbus organization to publish a TSN specification for a reason. With the interface specified therein, we will connect Ethercat networks - also with Ethercat G - to heterogeneous TSN-capable Ethernet networks and thus expand the application range of our technology without having to change Ethercat field devices. Thanks to TSN technologies, our Ethercat automation protocol for networking Ethercat controllers via an existing Ethernet network will also become hard real-time capable. We are therefore linking up to TSN, while Ethercat G and G10 will become integral components of our technology family - with the usual simplicity that requires no IT expertise. In a nutshell, the strategy is: Ethercat to TSN networks wherever they already exist, and Ethercat G and G10 wherever the application creates a new control network.

How do you personally assess the current developments in TSN and Industrial Ethernet?

Martin Rostan: Ethercat is certainly benefiting from the unrest that TSN has brought to the market. PNO and CLPA are working on integrating TSN into Profinet and CC-Link IE and will still need years before their TSN-based systems are stable - and no one is implementing Profinet IRT any more. The ODVA does not yet seem to have a clear TSN strategy. Bosch Rexroth, for example, has recognized that TSN will be a long time coming and is consequently basing its new generation of controllers on Ethercat - which means that Sercos III has effectively been signed off.

I personally expect that the IEEE TSN Task Group will adopt the specification for TSN time synchronization at the end of this year or the beginning of next year - and that this will be the starting signal for the development of standard-compliant TSN chips. Even before these are available, individual manufacturers will be presenting TSN island solutions. And there is also still a lot of movement on the configuration side; among other things, it is not yet clear whether there will be a cross-manufacturer solution.