Time-Sensitive Networking (TSN) extends standard Ethernet according to IEEE 802.1 with functions for deterministic data communication, is considered a key enabler for convergent IT/OT networks and is therefore crucial for the digitalization of production. The necessity as well as the fundamental suitability of TSN are accepted across all industries, but there is great uncertainty regarding the specific use of the mechanisms, configuration and engineering.
Discussions regularly mix technical and company policy aspects, as well as questions about how something should be configured and what the result of the configuration should be. This leads to confusion and hinders rapid progress. A large part of the problem can be explained historically: In the industrial environment, communication is traditionally seen as part of the application and is subordinate to it. Developers are used to specifying communication at bit and byte level and having control over the exact timing.

This is at odds with an infrastructure-based approach, which is a prerequisite for the successful and scalable use of TSN for digitalization. Similar to standard IT, applications use the infrastructure and interact with it via management interfaces, but there is no direct control over it. As distributed real-time applications are usually to be implemented in an industrial context - for example a virtual PLC (vPLC) that interacts with distributed sensors and actuators - this is where the biggest difference to the requirements in IT can be found: The determinism that the infrastructure must fulfill.

The convergent infrastructure

Figure 1: The application engineering workflow.

© ISW

Although the future digital infrastructure for manufacturing companies still faces many technical challenges and is subject to various interpretations, there is fundamental agreement on its structure. Instead of IT on the one hand and loosely coupled OT systems on the other, an infrastructure that can be used equally by IT and OT applications is emerging. The central components are computing platforms and communication networks that extend continuously from the field to the on-premise cloud. This infrastructure must meet deterministic requirements. This applies in particular in the direct vicinity of OT, for example for networks to field components, but also for the computing platforms and the connectivity to these, on which vPLCs are to be executed, for example.
Management is of central importance for the future infrastructure, both for the computing resources and for the network. The latter must be able to manage the available resources system-wide and across all applications based on the requirements of the applications and configure the communication infrastructure. In the context of TSN, the Central Network Controller (CNC) should be mentioned here. The CNC receives requests for required streams from the applications or their engineering systems. For this purpose, the engineering tools assume the role of a Centralized User Configuration (CUC), which is described in IEEE 802.1Qcc. Based on these requests, the CNC allocates network resources, configures the infrastructure, such as switches, and informs the CUCs of the exact communication parameters, such as transmission times. Due to the centrality of the CNC, the resources of the network can be used optimally.

The compute nodes in the network provide computing capacity and allow software to be flexibly deployed and executed on them as required. In combination with the dynamic creation of convergent communication, this enables versatile production systems that can be defined by software as required, as is the case with software-defined manufacturing, for example.

The basic digital infrastructure of compute, communication and management can be expanded with additional entities. One example of this is a repository in which containerized applications are stored and from where they are loaded onto compute nodes during deployment. A registry for the onboarding of components in the network is also useful. This allows devices that are added or replaced to be automatically integrated into the network without having to manually assign IP addresses, configurations or similar.

Application engineering

Figure 2: The GUI of the prototype engineering tool.

© ISW

What does the basic application engineering workflow for distributed real-time applications look like? The application is divided into distributed tasks that are connected to each other in a defined and deterministic way. Tasks can be hardware-independent or defined for a specific device. A typical example of this is the vPLC-based control of a conveyor belt with various actuators and sensors for detecting, manipulating or pushing off workpieces. The vPLC is hardware-independent and can be deployed on suitable platforms, such as an IPC or edge system. The other tasks are the interfaces and local controls of the components, for example the conveyor belt, a vision system or even a simple pneumatic actuator. These tasks are permanently linked to the hardware. In order to operate the distributed real-time application, the tasks and components must communicate with each other via a network while complying with the deterministic requirements.

The schematic procedure for engineering a distributed real-time application is as follows (Fig. 1):

In the first step, the desired applications are selected. The information on the available applications can, for example, come from the repository mentioned above. The next step is to select the appropriate compute nodes in the network on which the respective applications are to be executed. This can be done manually or automatically based on the required and available resources. The applications are then deployed on the selected devices. The communication between the applications must now be defined, specifying the required QoS, and calculated by the central network management (e.g. CNC). The resulting configurations must then be transferred to the devices. This should allow the distributed application to be executed.

The engineering tools

Figure 3: The input screen for specifying the QoS parameters for a TSN stream.

© ISW

Future engineering tools must enable the described workflow; they basically correspond to the tools currently in use (e.g. for PLC controls), but differ in some aspects. A prototype engineering tool (Fig. 2) shows the extent to which this is the case. The tool is not a fully-fledged product, but rather shows the holistic engineering in the context of future infrastructures and the relevant interactions. The main view shows a visualization of the topology of the network and the connected devices. It shows the physical connections between the devices (compute nodes, switches) on the one hand and the communication of the individual applications on the other. Information on the TSN streams and other convergent traffic, the applications and the available devices are listed on the left-hand side.

Due to the complexity of convergent networks and communication, the operation of such engineering tools plays an important role. When viewing the workflow for application engineering, the desired applications can be dragged and dropped from the list on the left onto the corresponding compute nodes in the topology view. This opens an input mask for specifying the deployment parameters - such as the CPU commitment or the thread priority. The same applies to the definition of communication: by connecting two applications, communication can be established between them. Here too, various parameters are queried to specify the QoS. Figure 3 shows this for a TSN stream. One-to-many (publish-subscribe) communications can also be created by adding further applications as receivers (listeners). By saving the request, the information is transmitted in the background using an engineering framework (see web tip). The framework then transfers the requests to the network management - in this case to a CNC - and then transmits the calculated communication configurations to the respective end devices.

Independent implementation

The author: Stefan Oechsle is a research associate in real-time communication at ISW.

© ISW

In order for users to be able to implement such application engineering, engineering by the user must not be neglected. The engineering tool presented here is purely a user interface for interacting with the engineering framework in question. The easy-to-use interface in combination with the central configuration and management framework illustrates how future engineering tools could look and function. It is important that the complexity of the overall system remains hidden as far as possible so that these new technologies, paradigms and approaches can be accepted.