Are all TSN networks the same?

© WEKA Trade Media

TSN networks can be operated in different ways depending on the requirements of the application domain in which they are used. It is therefore important to define common rules - such as the 'End Station Model' - for operation within a network as well as their properties and the set of TSN features that are required in the network devices.

On the one hand, the common 'End Station Model' describes the mechanisms with which packets are transmitted into the network on a time-controlled basis. It also describes how the corresponding elements of the network configuration can be assigned to individual applications. The common model is particularly important for the configuration, because in order to be able to integrate manufacturer-independent end devices into a network, the behaviour of the devices must be known, which is parameterized by the respective characteristics of the end devices. Properties such as time-controlled transmission and time synchronization in the end device are essential for a common model. Configuration details, such as possible cycle times, number of time-controlled transmission slots and precision of synchronization, do not necessarily have to be defined, but should remain flexible and adaptable to the respective application. If this information is disclosed, a configuration unit can take this into account.

Equally relevant is the minimum set of mechanisms in the TSN bridges, which forms the basis for the quality of service guarantees (QoS guarantees) in the network. Agreement on common mechanisms - such as time-aware shaping and preemption in TSN bridges - forms the basis for domain-wide guarantees. Here too, the exact form must remain open but transparent. For a neutral definition of a network, the selection of TSN features and their minimum characteristics should be based on the purely abstract level of the IEEE mechanisms.

Rene-Hummen is Manager Technology and Innovation at Hirschmann Automation and Control.

© Hirschmann

As already mentioned, not every TSN network will be identical in real-life use. As the specifications for end devices and bridges describe a minimum set, the guarantees that can be given in a network can be influenced by adding additional features and by varying the characteristics of these features. It should be noted here that devices with as uniform a set of features as possible should be used within a network. Only then can the respective mechanisms be used network-wide. TSN domains are the key to achieving homogeneity of features in a network area. Within a TSN domain, it must be ensured that all devices support a uniform set of features that are required to achieve the guarantees in the TSN domain and are specified when the domain is defined. Individual devices can also provide additional mechanisms. However, the use of such mechanisms only brings limited additional benefits, as they are not necessarily available everywhere. Another characteristic of a TSN domain is that only one configuration unit - in the central case only one Centralized Network Configuration (CNC), but possibly several Centralized User Configurations (CUC) - may be active within a domain, so that the network configuration can always be kept consistent and is only controlled from one location.

The interaction of these individual components is shown in the image on the next page and ensures uniform behaviour of the network traffic that is controlled by the TSN mechanisms. The exact behavior can be adapted to the applications, the network or the protocols used, but is always based on the features and properties that are available domain-wide.

A concrete example

Physical network with logical central configuration units

© Hirschmann

By clearly modeling the behavior of end stations and bridges using the minimal functions, a separation between application and network requirements can be created. This can be clearly seen in the example of OPC FLC. In the planning phase, only the application requirements are modeled with regard to data volume and temporal behavior. All common traffic models, such as deadline, cyclic latency or bandwidth, can be described here. Integration involves a general setup of the network, in which specific guidelines are already preconfigured. Examples of this are domain boundaries at which ingress shaping is to be applied or time synchronization within a domain. In the final step, the operational phase, applications register with their application requirements in the network. These are then resolved in accordance with the network policies already configured in the domain and the properties and mechanisms available in the TSN bridges. This results in a network configuration that ensures that the existing quality of service requirements are met.

Stephan Kehrer is Senior Architect in the CTO Office at Hirschmann Automation and Control.

© Hirschmann

In the past, integrating new applications into existing networks was a task that mainly had to be carried out manually if the integration entailed a change to the QoS configuration. However, as configurations can quickly become complex, there is a considerable risk of errors creeping into the configurations if they are reconfigured manually. It is therefore important to automate the translation of application requirements into a configuration for simple and flexible use of the more complex mechanisms from the TSN toolbox. This is done in the central configuration model within a TSN domain using CUCs and the CNC. For OPC UA applications, the OPC UA TSN Working Group is working on standardizing the terminal device interface. Based on the models specified in IEEE Std 802.1Qcc, end stations transmit their application requests via OPC UA and the CUC and wait for the stream configurations, which are returned after successful calculation and configuration. However, testbeds showed some time ago that the basic data structures defined in IEEE Std 802.1Qcc are not sufficient to enable a standardized configuration workflow.

To close this gap, the IEEE 802.1 TSN Task Group launched a project, IEEE P802.1Qdj, in which Hirschmann is playing a leading role. One of the main objectives of this work is to enable application engineers to intuitively define and achieve the time requirements of communication in the future so that the network can automatically provide the corresponding guarantees, provided that sufficient capacity is still available.

What is already available?

Steps of an automatic TSN stream configuration using CUC and CNC

© Hirschmann

In order to enable the automatic integration of applications into existing networks, a large number of scenarios need to be covered. Implementation in a standardized configuration interface requires many factors to be taken into account. There are various demonstrators and cross-manufacturer projects to ensure that all requirements of real applications are recorded and taken into account as comprehensively as possible and that possible open points in existing specifications are discovered. For example, end device configuration via OPC UA in a TSN network was demonstrated for the first time at SPS 2018. At the TSN/A Conference 2020, Hirschmann and Schneider Electric will present an extension of this demonstrator as a completely automatic end-to-end configuration based on the current IEEE 802.1 and OPC UA standards.

It is important that the interfaces are based on a uniform consensus. Hirschmann has therefore published an exemplary OPC UA CUC under the name 'openCUC' on GitHub. This reflects the current specifications of OPC UA and IEEE in order to obtain extensive feedback for standardization. It shows that automatic TSN QoS configuration is no longer a dream of the future, but is already available to everyone. Testbeds, such as the IIC testbed in this case, are very important for a wider range of activities and for checking the completeness of the specifications.

The role of testbeds

Lukas Wüsteney is a Junior Architect in the CTO Office at Hirschmann Automation and Control.

© Hirschmann

The topic of configuration is essential for the successful use of TSN in productive networks. The basic approaches for configuring TSN networks as simply and comprehensively as possible in the future are not a completely new problem. Some models and basic principles have already been specified in IEEE Std 802.1Qcc. Extensions and adaptations for special application areas based on this are currently being discussed in various committees and driven forward in standardization projects such as IEEE P802.1Qdj. These approaches are being tested and further developed as part of various testbeds, demonstrators and projects such as openCUC. Testbeds are therefore a good way of gaining experience with the configuration of TSN networks.