Ethernet in the factory
Configure TSN networks automatically
Ethernet TSN is considered a promising approach for establishing open real-time communication. However, the diversity of the TSN standards also increases the complexity of the networks. Management and automatic configuration mechanisms are currently still simple.
As part of SmartFactory-KL, DFKI scientists are researching, among other things, how an application-driven instantiation of encapsulated production functions can be realized at module level in the form of production modules. The overall system structure currently consists of ten production modules from different manufacturers.
© SmartFactory-KL / C.ArnoldiEver since the term 'Industry 4.0' was proclaimed at the Hannover Messe 2011, the digitalization and end-to-end networking of production has been the focus of science and politics. Changing market requirements demand customized products with ever shorter product life cycles - modular, scalable systems using plug & play represent a solution approach here.
However, classic project planning solutions in automation technology do not yet provide for true Plug&Play. In real-time critical applications in particular, control and communication must be planned as an integrated solution. Although supporting engineering tools are available for this purpose, these can only be used for a static application and mostly for proprietary technologies. In other words: today, mainly proprietary fieldbus solutions are used, which fulfill the static requirements of classic automation systems, but fragment the network into manufacturer-dependent isolated solutions and also do not support real hot plugging.
One technology that is becoming increasingly popular in this context is Time-Sensitive Networking (TSN). TSN defines global and improved time synchronization (802.1AS-Re) and one of the core standards for implementing deterministic data transmission, the Time-Aware Scheduler (802.1Qbv). This makes it possible to subdivide the synchronized time and thus reserve dedicated and prioritized time slots.
In this way, real-time data can be transmitted in time-prioritized slots without being influenced by non-real-time data. Maximum latency times of 122 µs can be achieved with Fast Ethernet with a frame length of 1518 bytes and 12.2 µs with Giga-bit Ethernet. Other mechanisms such as guard bands (IEEE 802.1Qbu) and frame preemption (IEEE 802.1Qbu) can reduce the cycle time to 5.12 µs and 0.512 µs respectively.
Figure 1: TSN infrastructure in modular factory systems: A standardized layer 2 network can help to simplify the connection of modules via conventional fieldbus stacks or machine protocols such as OPC UA.
© DFKI / SmartFactory-KLIn addition to the new, improved Ethernet mechanisms, TSN has the potential to carry out the next standardization step on layer 2 of the ISO/OSI 7 layer model (data link) and thus provide a generic network infrastructure in automation technology(Figure 1). This generic infrastructure can be used to provide a deterministic infrastructure for both classic fieldbus protocols and IT services as well as future protocols such as OPC UA Pub/Sub.
Various activities demonstrate the industry's interest in utilizing the strengths of TSN. For example, a working group within the OPC Foundation is working on evaluating the combination of OPC UA via TSN. The Profibus user organization and Sercos International also want to combine the strengths of Profinet or Sercos III and TSN in order to benefit from a standardized infrastructure or to combine the protocol stacks with TSN. In the future, this should also help to expand interoperability when setting up cross-manufacturer production systems.
Network configuration as a sticking point
So far, so good. However, the TSN mechanisms mentioned currently still have to be configured manually. Dividing the network into defined time slots, for example, requires manual calculation and configuration of each network participant. This can be an obstacle to the introduction of TSN, particularly in flexible and modular systems. Changing a component and making changes to the system often results in a (re-)configuration of the network. With high real-time requirements, the TSN mechanisms must be adapted accordingly and introduced into the network - a process that is not only time-consuming, but can also potentially cause errors that are difficult to diagnose.
Operators of IT networks are faced with a similar problem today. These are now so complex that manual management is almost impossible. Even minor configuration errors can paralyze entire networks. Consequently, the decision is often made to leave networks as untouched as possible so as not to jeopardize their functionality. In view of the high dynamics required by modern IT structures, however, this is ultimately not an option. For this reason, a rethink is currently taking place in network technology with the aim of meeting the constantly increasing network requirements.
New paradigms such as Network Functions Virtualization (NFV) and Software Defined Networking (SDN) play a key role in this context. The latter describes the concept of the physical separation of control flow functions and the data level. The control level of a network component is transferred to a central Network Operating System (NOS), which controls and monitors several network devices.
Figure 2 shows the structure of an SDN network architecture. The devices in a network only have one data layer. This level communicates with the controller via a well-defined southbound API. The programmability of the network is enabled via a northbound API of the controller in order to offer virtualized network functions. On the one hand, the controller can actively and passively collect information from the network and thus represent the status of this network and abstract the decentralized data levels as a central data level. On the other hand, control commands can be sent to the network devices via the SDN controller. The programmability of these functions also potentially enables complete automation of the network configuration. This allows dynamic and 'smart' networks to be realized.
How the SDN paradigm can be adapted to TSN networks is shown by the proposal for a TSN system, which provides for the central configuration of TSN switches and a communication interface to network participants(Fig. 3). The idea of the SDN controller is divided here into two logically separate functionalities - a subscriber configurator (TK) and a network configurator (NK).
The conversion from SDN to TSN
Within a TSN system, the device configurator is responsible for the communication and configuration of devices in a TSN network. Quality requirements or configuration parameters can be transmitted by the network participants or the TC via an open communication interface, which can be implemented using a participant protocol such as OPC UA or REST. This means that the TC can also take on the tasks of a conventional project planning tool; although this does not enable dynamic configuration, it can represent an integrated engineering approach and offers the possibility of simple integration of TSN into classic automation solutions.
The network configuration is managed by a (logically) central NK. According to the SDN paradigm, a well-defined southbound or network management protocol is used for communication between the configurator and the network components - in this case the TSN switches - to configure the communication connections. The southbound protocol can be implemented both via classic network management protocols - such as SNMP or Netconf/Restconf - and via the SDN protocol OpenFlow. Although the former does not fulfill the strict definition of SDN with the separation of control and data levels, classic network components can also be recorded and managed. In any case, however, information modeling must be clearly defined across manufacturers - in the case of SNMP with the Management Information Base (MIB) or in the case of Netconf/Restconf with the YANG modeling language. Belden/Hirschmann, for example, has realized a simple implementation of a supporting network configurator with the SNMP protocol.
The aforementioned SDN protocol OpenFlow offers an alternative to the classic management protocols. This is being driven forward by the Open Network Foundation (ONF), promotes a complete decoupling of the control and data levels and is already being used by IT companies such as Google to manage large backbone networks. OpenFlow has direct access to the hardware or data level of a network component and implements a match-action model with the help of flow tables and flow entries. The latter define rules in the data layer that determine which characteristics are used to identify packets and how they are to be handled - i.e. to which port they are forwarded, for example.
OpenFlow does not currently support rules for real-time communication, but these could be integrated in principle. However, the granularity of an OpenFlow match rule must be taken into account. If the granularity is too high, this could stand in the way of a cut-through procedure and increase the latency.
Figure 4 shows how such a TSN system or SDN can be used in a modular factory system to implement plug & play at network level with specific network requirements. When a new network subscriber - such as a production module - is added to the network, it can log in to the SDN controller with its specific requirements. The central SDN controller reconfigures the network based on the requirements of the (new) network subscriber in order to provide the required communication quality between the individual modules.
In conclusion, it can be said that With time-sensitive networking, conventional Ethernet in accordance with IEEE 802.1 and IEEE 802.3 can not only be expanded to include determinism with low latency times, but also increase reliability and security. Particularly in conjunction with OPC UA, TSN can form the basis of an open and manufacturer-independent Industry 4.0 communication standard. However, classic fieldbus protocols can also benefit from a generic TSN infrastructure. In addition to the expected lower costs of TSN components, the infrastructure offers a high level of investment security. In future, it will be necessary to further evaluate how TSN can usefully support a complete plug & play scenario, even with real-time requirements. In addition to the necessary network components, a central configuration component and a standardized network information model must be defined.
(The article is based on the VDI report 2293 Automation 2017).
Authors:
André Hennecke is a research associate in the SmartFactory KL technology initiative;
Stephan Weyer is a research associate at the German Research Center for Artificial Intelligence.

















