TSN: Changing the face of automation

TSN: Changing the face of automation

TSN: Changing the face of automation

With the changes in the market coming alongside Industry 4.0 we have seen a huge shift in the structure of industrial networks with increased requirements for access to the data from the “shop floor” to the “top floor”. As this model moves, the line between the automation systems and the I.T. systems becomes blurred leading to new requirements to ensure that these converged systems operate with the same expected outcomes.

Several existing communications technologies allowing for real-time communications, such as EtherCAT, PROFINET IRT, and Sercos III, have a disadvantage in this scenario as they are not easily integrated into the converged architecture due to their limited compatibility with the overall Ethernet networks.


TSN (Time-Sensitive Networking) offers a solution to the following scenarios

  • Highly dependable real-time communication of critical and non-critical networks on the same network.
  • Fully Ethernet compatible solution to allow enough backbone bandwidth to the increasing sensor and background data which flows across and between both the OT (Operational Technology) and IT (Information Technology) networks.
  • Backward compatibility with existing Ethernet networks.


What is TSN?

TSN is a new standard of hardware supported technology that allows the configuration of your network such that you can choose how critical and non-critical traffic will be treated.

An example of time-critical traffic is used in the control of the plant process. Sensor devices react to control and command data from the Programmable Logic Controller (PLC) and return their feedback to the PLC. During this time, sensor-generated data for monitoring the process is sent up to the Supervisory control and data acquisition (SCADA)system which is less time-critical or even to a cloud-based system.

The ability to mix critical and non-critical traffic in this way is an important part of the increasingly interconnected systems that are becoming the standard for companies who are trying to move towards more cloud-based centralised control of their automation systems.


What did we do before TSN?

When building networks with a mixture of critical and non-critical traffic, a common practice has been to create two independent networks so that you can guarantee they don’t have an impact on each other. The concept doesn’t fit well in an interconnected system where you want to feed all the sensor data for the automation system up to a centralized or cloud-based SCADA system. It also falls over with new industrial cybersecurity requirements as generally these devices have increased cost, so duplicating architecture becomes more expensive than previously thought.

The above reasons (and more) are the driving force behind the inception of TSN becoming a standard as it offers the previously stated ability to be able to intermix the critical and non-critical systems on the same hardware. This allows for potential savings by investing in smarter hardware with better industrial Cyber Security features.

How exactly does it achieve this?

TSN is a mixture of technology solutions under one banner however we will focus on the two key functions which are most used. 

  • Time Synchronisation
  • Traffic Scheduling


Time Synchronisation

The Time synchronization functions built into the TSN protocol are handled by the 802.1AS standard and require a hardware-based solution (i.e. specialized hardware) so it cannot be reversed when implementing into existing hardware.

The 802.1AS time synchronization standard is an adaptation of the existing PtPv2 functionality to suit the requirements of TSN. The reason this is so critical is that for us to guarantee end-to-end delivery of data across the network, whilst guaranteeing that the critical traffic is treated with priority over the non-critical traffic, we first need to ensure that all the devices involved have the same time source and are accurately synchronized.

Much like the PtPv2 protocol, 802.1AS works by having a centralized time source called a “Grand Master” and this hands out the time to the nearest 802.1AS bridge in a “master” and “slave” arrangement where the “Grand Master” is the master and the bridge is the slave. From this point on, the same relationship is created where the first Bridge, who received its time from the “Grand Master”, is the master and the other device is the slave. The store and forward approach is used consistently throughout the network, right up to the endpoints, with an auto-correction built into the hardware to ensure that accuracy is maintained.

The time synchronization method much like PtPv2 is for nano-second accuracy by measuring the path delays in the network and doing adjustments to increase the accuracy of the time being sent.


Traffic Scheduling

Now that we have our time synchronization giving us a common time across the entire system, we have the ability to make decisions and have that decision make sense across the network, as the common time allows for all devices to work cyclically on a time schedule much like the automation devices they are providing communications for.

This is something that must be configured for each network and can become quite complex, with many people already starting to work on tools to assist in the management and configuration of this.

We have included an image (see figure 1) that shows a great example of how this might look visually with a cycle-based system, with two traffic schedules created.

The first section (labelled VLAN priority 3) is for our time-critical traffic used for controlling important processes inside our factory automation system. This data is given a dedicated time each cycle to transmit across the network that no other device can use. This guarantees that it will have the same performance no matter what other conditions are present on the network.

Then after this timing window, we have created a common section (labelled 2) for the remainder of the traffic, as it is all more or less of the same importance (in our made-up scenario), falling into the same category of “non-critical”.

There can be some concerns with the design if you look at each section of 1 (critical) and 2 (non-critical) there is a dedicated time period for transmission of traffic, but Ethernet does not allow for ‘half sent’ data across the network.

To combat this there is a function called “Guard Bands” which allows you to put a space at the end of each section of dedicated time to ensure that even if the maximum frame size is being sent across the network you will still have time to have it finish before the next cycle starts.

FIGURE 1 - by Ulgorash CC BY-SA 4.0

TSN is an important new protocol for any system that is looking to integrate both critical and non-critical systems on the same bus (or Ethernet network). It allows for dedicating time through a scheduling process, that will guarantee the same performance under any condition for your critical process.

The ability to create a deterministic standard-based Ethernet network is a new and novel concept that may change the way we think about automation system designs going forward.

For more information on this topic please keep checking ControlLogic.com.au for technical based webinar sessions from System Integrator partners. It will no doubt be a topic that will be developing over time.


Related Products