In a previous article, we have seen the importance of controlling time in real-time embedded systems to guarantee and demonstrate that actions occur at the “right time”. Today, we’re going to continue to explore this concept of time guarantee, and others, in this article on a new type of communications network: Ethernet TSN.
Network ? TSN ?
A network enables communication between several computers. By connecting to the Internet to read this article, you are probably using several interconnected networks (Wi-Fi, Ethernet, etc.). In an embedded system like an aircraft, it’s the same thing. The various computers communicate with each other using several networks (AFDX, CAN, MIL-STD-1553, etc.).
EEthernet is a network communication protocol. Its role in the “protocol stack” is to choose which message (called a frame) to transmit. Created in the 70s, Ethernet was inspired by the wireless communication protocol [ALOHA], invented by the University of Hawaii, by transposing it to wired technologies. In the 90s, the protocol evolved to support switching and point-to-point [“full duplex”] links. This is the form of Ethernet that is most widely used today, particularly in business, data centre, industrial and even domestic networks.
TSN, for Time-Sensitive Networking, is the name of an IEEE task group that is proposing standards to extend the capabilities of Ethernet. This group is proposing new mechanisms known by extension as TSN mechanisms. The aim of these mechanisms is to enable the Ethernet network to satisfy the needs for determinism and reliability of highly heterogeneous communication flows. The first standards were published in 2009. Initially intended for the professional audio/video world to unify their networks, buses and analogue links, TSN has been since attracting a wide range of industrial sectors since 2012, including the automotive industry, data centres, 5G and factory automation. Today, TSN is composed of more than twenty standards.
Why add another network?
Our embedded systems already incorporate a large number of networks, so why should we be interested in TSN? TSN is perhaps the very answer to this problem. Existing networks were created to meet a single need (for example, low latency for CAN and high speed for MOST). This “one need = one dedicated network” equation very quickly led to dozens of dedicated networks in a vehicle the size of a car. TSN, with its promise of supporting highly heterogeneous flows, could simplify architectures by enabling a single network to be used for an entire vehicle.
Another argument is the multi-domain aspect of TSN. Indeed, it could avoid the use of solutions created specifically for one industrial sector, such as AFDX for aeronautics or SpaceWire for space. For example, it could reduce component costs thanks to the volume of the automotive industry, while guaranteeing high reliability and determinism inherited from the needs of the aerospace industry.
Furthermore, TSN does not “come out of nowhere”. Indeed, it is based on Ethernet, which is a mature, well-established base used in many industrial sectors. The Ethernet ecosystem is extensive, both in terms of tools (e.g. design, configuration and monitoring tools) and hardware (e.g. switches, network interfaces and measurement instruments).
Finally, TSN uses concepts that have already been proven in Ethernet networks used in critical systems. For example, there are mechanisms similar to the bandwidth sharing and policing of AFDX (used in the Airbus A350 and A380) or the time bandwidth sharing and synchronization of TTEthernet (used in the ORION capsule and Ariane 6 rocket). However, unlike AFDX and TTEthernet, TSN is based on open standards and offers greater modularity.
How does it work? The twenty or so TSN standards can be classified into four categories as described in the figure below. To define the use of TSN suited to the needs of an industrial sector, profiles have been proposed. Examples include P802.1DP for aerospace and P802.1DG for automotive. In the rest of this paragraph, we explain how the mechanisms envisaged in these two profiles work.
These profiles include two mechanisms for controlling the latency of frames passing through the network: CBS and TAS. CBS, for “Credit-Based Shaper” (IEEE802.1Qav), is a mechanism for limiting the bandwidth associated with a priority level. It is based on a token bucket that fills up over time and empties when a frame is sent. The latter can only be transmitted if there is a positive or zero number of tokens in the bucket. By limiting the throughput of frames with a given priority, this mechanism leaves transmission opportunities for frames with lower priorities, thereby reducing their latency. The counterpart is an increase in the latency of the frames submitted to it.
The TAS, for “Time-Aware Shaper” (IEEE802.1Qbv), is a mechanism for controlling access to the medium as a function of time. It controls which queues on an output port can transmit their frames using gates whose opening and closing are programmed according to a schedule, called the Gate Control List (GCL). This mechanism enables very low latencies to be achieved thanks to virtually zero waiting times in the FIFOs, if the reception of a frame is timed to the opening of the gate. However, the design of such a schedule is a complex task which requires the constraints of all the flows to be taken into account, as well as the topology of the network, the different latencies and the precision of synchronization. The latter is very important for optimal TAS operation. To ensure that the different instances of the TAS on the different output ports of the network devices are properly synchronized, it is necessary to share a common, precise and reliable clock throughout the network.
This clock sharing in a TSN network is carried out by a synchronization protocol called the “generalized Precision Time Protocol” (IEEE 802.1AS). This protocol is a specialisation for TSN networks of a well-known synchronization protocol: PTP. As well as enabling the use of synchronous TSN mechanisms, such as TAS, this synchronization benefits applications for distributed functions. The protocol works on the principle of a reference clock called the Grandmaster, which periodically shares its time measurement with the entire network. Another mechanism evaluates the frame traversal time so that it can be taken into account when the message from the Grandmaster is received. This enables synchronization precision of less than a microsecond to be achieved in networks with less than seven hops to reach the Grandmaster. This central role makes it a weak point for the network in terms of safety and cyber security. However, certain mitigation techniques are currently being standardised, for example with the P802.1ASed amendment.
In terms of reliability, there are two standards. The IEEE 802.1CB standard describes two mechanisms. The first of these is the stream identification function. It uses fields in the frame to associate a frame with a stream of frames. Each identified frame is associated with a stream identifier called streamHandle. This identifier is then used to determine whether or not certain mechanisms are applicable to this frame. One of these mechanisms is the second described in IEEE 802.1CB: FRER, for “Frame Replication And Elimination”. FRER enables a frame to be transmitted over several paths to avoid the loss of frames due to a failure on one path. To achieve this, replication points are configured to make one or more copies of the frame, which are then transmitted to different output ports. Elimination points are configured to delete frames where one of the copies has already been received.
PSPF, which stands for “Per-Stream Filtering and Policing” (IEEE 802.1Qci), checks compliance with a transmission contract per flow. If the contract is not respected, the mechanism can decide to delete the frames concerned to prevent the error from spreading to the rest of the network. This mechanism is therefore one of the keys to guaranteeing that flows meet their performance requirements. Without this mechanism, a faulty application could saturate the network and cause many flows to fail to meet performance constraints. Contracts can contain information such as the maximum size of frames in the flow, the bandwidth required and a frame transmission temporal profile. As with FRER, the flow with which the frame is associated is determined using a stream identification function.
In this article, we have discovered the fundamentals of TSN and why it is gaining popularity in the embedded world. Some of the TSN mechanisms envisaged for embedded networks were presented, and we touched on the complexity of TSN. However, this complexity is far from insurmountable with the help of dedicated tools such as those designed as part of the [EDEN] taking place at the IRT.
To go further: