A resource-based approach

Figure 2: The different layers in the endpoint, as well as their core functions and interfaces.

© TenAsys

While networks are typically developed and considered very explicitly in the OT environment, in IT they are usually seen as a given part of the infrastructure and used as an available resource. A resource view is also possible in the OT environment: instead of standards, network configurations and low-level communication, users can see various communication relationships. What the resource is here can differ depending on the approach to using TSN:

• Physical network interfaces
• Traffic classes with certain deterministic guarantees
• Streams with guaranteed deterministic properties

Applications can be developed on the basis of these communication resources without in-depth knowledge of the technology. However, the prerequisite is that a subordinate system implements this abstraction and takes care of the necessary configuration.

Systems basically consist of hardware-software combinations. TSN-capable hardware in the form of network controllers is increasingly coming onto the market and can implement some of the functions. However, it should be noted that there is no such thing as "the" TSN hardware, but that different controllers offer different hardware support, whereby complementary software functions are always required. Particular attention should be paid to the widely used controllers that efficiently support various TSN functions but were not specifically developed for TSN use (e.g. the I210 Ethernet controller from Intel). Accordingly, a great deal of expert knowledge is required in addition to the software components in order to use them effectively. From an endpoint perspective, three layers can be identified(Fig. 2):

• Application layer
• Abstraction layer
• Hardware layer

Figure 3: Application example with virtualized control systems.

© TenAsys

There are interfaces between the layers. The corresponding hardware-specific interfaces are used from the hardware to the abstraction, while the resource-based approach is reflected at the interface between the abstraction and the application: there are communication resources for sending and receiving as well as management interfaces for the resources.
The resource-based approach allows the entire system - from the hardware to the application interface - to be mapped uniformly using resource maps. A map is required for both the send and receive directions. In the send direction - starting from the physical interface, which represents the root - the resources are divided into ever new resources via various shapers.

These different shapers can be used:

• Time-aware shaper
• Credit-based shaper
• Priority-based shaper
• Stream-based shaper

These can correspond exactly to the respective TSN functions, for example the time-aware shaper according to IEEE 802.1Qbv. In addition, shapers can also be implemented only locally in the endpoint, for example to enable fine-grained traffic classes for a larger number of parallel applications in the endpoint with fair access to the network.

In the receive direction, which is also described by a map, the incoming data from the physical interface is further divided using filters.

The resources defined in the maps correspond to the user interface. The user can therefore select various entry points - from the physical interface to fine-grained traffic classes - to realize his application. The configuration of the resource maps is decisive for the efficiency of the approach. Depending on the usage, various options are provided:

• Static or default configurations
• (Partial) configuration using interfaces to centralized or distributed network management or application engineering
• Manual configuration using APIs
• Use of specific configurations for TSN-based solutions such as Profinet over TSN or CC-Link IE TSN

The send and receive logic is implemented in the abstraction layer and the hardware, which are configured on the basis of the maps.

TSN: Application example and implementation perspective

Figure 4: Resource maps for the application example of several virtual controllers.

© TenAsys

The virtualization of multiple controllers is a typical use case for TSN. The main advantage of this approach is that multiple virtual controllers can run in parallel on a multi-core industrial PC. So instead of deploying and managing many discrete hardware controllers, plant operators can consolidate all their real-time control tasks on a few powerful multi-function automation controllers.

This use case will serve to illustrate the resource-based approach. It is assumed that three machines, each with two axes, are operated using virtualized controllers. All controllers are to be executed on the same endpoint. The communication between the controllers and the drives consists of real-time streams in both directions, configuration data to be prioritized and best-effort data for monitoring functions(Figure 3).

To implement the communication, resource maps are set up on both the receiving and sending sides, which combine various shapers and filters(Fig. 4). The actual applications are implemented based on the resources. On the application side, for example, it would be possible to use the stream resources for OPC UA pub/sub traffic, the prioritized traffic class for OPC UA client servers, as well as the use of best-effort for access via web-based monitoring.

The prospects for implementation

The resource-based approach can be used in real-time operating systems, but requires in-depth interventions in the classic network architecture. This requires close coupling with time synchronization and, in particular, with application scheduling. The resource-based approach is currently being integrated and tested in the INtime RTOS from TenAsys.

This approach makes it possible to develop real-time applications based on TSN without having to understand the intricacies of TSN components, traffic shaping and timing offsets in detail. Instead, the INtime application development tools and utilities act as a network configuration interface, allowing solutions to be implemented at the application level and executed deterministically, depending on what the use case requires. At the same time, standard IT workloads can be run on the same platform, for example via Windows, without interfering with the real-time applications.

The author: Christopher Main is President and CTO at TenAsys.

© TenAsys

The demonstrators expected in 2024 should not only present the approach, but also make an important contribution to the cross-platform abstraction of real-time applications and their communication.