What Does TSN Configuration Look Like Today and In the Future?

The anticipated configuration complexity of TSN is giving many end users mixed feelings about this new technology. They understand how TSN works and the benefits it will offer, but fear it will be difficult to use. It is true that TSN isn’t a plug-and-play technology today, but by implementing a few concrete steps, teams will be well on their way to make the utilization of the different TSN standards a much more user-friendly experience and make successful configurations a rule, not the exception!

Current Challenges with TSN

Let’s say you are a truck driver and need to deliver express goods from a factory in one state to the distribution center in another region. You are travelling on a one-lane road and eventually reach an intersection where a traffic cop is at the scene, directing each vehicle on when they can pass. Just as you pull up, a police car with emergency lights comes up behind you, trying to pass to reach an urgent situation. Naturally, the traffic cop assumes the police car’s trip is a higher priority than yours, so he directs you to stay put and for the police car to take the right of way. You knew to let the police car pass; the police car knew to forge ahead and there was no severe travel interruption for either party.

TSN configuration works like the traffic cop, serving as the time-aware scheduler ensuring that high priority and time-critical information can get through the network with no interference. A single lane of streamlined traffic is easy to manage, but when multiple priority information frames need to pass through various streams at the same time in a complex topology, the difficulty of configuring these communication paths increases greatly.

Priority frames are free to travel without network interferences when sent on their own stream.

For engineers, the ability to configure their networks so the arrival of high priority frames at their destination happens without any disturbances is no easy feat. These complex networks have different real-time requirements, and the more information that needs to get from sending to receiving devices, the more difficult it is to configure additional streams. To successfully manage the end-to-end communication of devices, teams must factor in a lot of information: the planned transmission time, residence time at intermediate switches, path delays, anticipated jitter and expected arrival time. It’s a complex challenge that requires a clear strategy with actionable steps.

Three Things to Keep in Mind When Thinking About TSN Configuration

While the complexity of TSN configuration is off-putting to some, there are ways to simplify the process and make implementation easier. Here’s what you should keep in mind when considering TSN configuration in the future:

1. TSN builds upon an intent-based communication model, which results in reservations for time critical streams, while still maintaining compatibility with regular network equipment. This means that configuration of streams is only necessary for network traffic requiring real-time guarantees while regular network traffic does not need to be configured. A maintenance technician, for example, can still connect his laptop to a TSN network to install a software update without the need for any configuration -- and without disrupting the real-time communication. To set up the protected real-time streams, the communication requirements of the involved devices need to be known and transformed into schedule configurations.

In a first step, this will mean that configuration of streams needs to be done by manual engineering, using the assistance of centralized tools like network management software. The next step towards the goal of an automated configuration will then be tools that contain algorithms, assisting the engineer by automatically computing streams between end-devices based on the communication relations engineered by the user. The final step will then be a fully automated configuration environment, where users only need to determine the devices that need to participate in the real-time communication and what their individual communication requirements are.

The automated system can do all the other decisions behind the scenes, including setting up the network schedule and configuring the devices involved in the communication. Of course, there will be the possibility of verification and manual correction of real-time streams by engineers, even in such highly automated configuration scenarios of the future. However, manual verification or modification of streams will be an option for those requiring them, and not a necessity.

2. Lean on IEEE P802.1Qcc configuration models to facilitate assisted -- and in the long run automated -- configuration of network streams. The configuration models provided in this part of the TSN standard series allow for both a centralized automation of stream configuration and a distributed one. The centralized approach is making use of different logical entities such as a central user configuration (CUC), a central network configuration (CNC) and their interfaces to the involved end stations (such as PLCs) and switches. The distributed approach offers a standardized interface for the end stations to provide their requirements and uses this information for a distributed calculation of stream paths and reservations without a central logical entity.

3. Utilize the assistance provided by configuration software today to avoid manual configuration of abstract time interval and gate state numbers on every single device. Graphical tools can be leveraged to visualize the involved time slots and provide configuration through graphical front-ends. A demonstration of how this might look in the future was demonstrated by Belden/Hirschmann at the SPS/IPC/Drives trade show in 2016.

It’s worth expanding a bit on the point about logic entities for the centralized configuration model: the CUC and CNC both play important roles in the distribution of reliable transmissions.

Exact time synchronization is key for disruption-free frame transmission.

The CUC takes requirements from end-devices or detects transmission availability based on sensor data. Once the required communication relations between sending (so called talkers) and receiving (so called listeners) devices have been established, that information will be transferred to another centralized entity, the CNC, that has full and global knowledge of network resources and topology. It then uses this information to find a path that fits the communication requirements between talker and listener. This path is subsequently configured as the transmission path for the stream between the devices.

Someday soon, this degree of logic will be automated, but it is not yet fully available. Until then, network management software with graphical capabilities can help ease stream configuration as previously described.

The centralized configuration model from IEEE P802.1Qcc.

Automating Communication with TSN

There is no doubt industrial network engineers are eager for TSN, but the dread of implementation complexity and confusion around how to set up the new mechanisms is dampening the excitement. Taking away these burdens from end users and reducing configuration stress is actually one of the primary goals of TSN. As the networking framework becomes automated over the next few years, it will help alleviate the burden of coordinating network traffic even further and reduce the extensive network knowledge required by end users.