Time Sensitive Networking (TSN) is seen across all industries as the basis for future convergent real-time networks. Previous real-time solutions are typically closed all-in-one systems designed for specific applications, from the hardware to the software to the application profile. TSN is different: it is simply a collection of extensions to the Ethernet standard that provide various functions for deterministic communication.

The most relevant mechanisms are time synchronization according to 802.1AS, traffic shaping on a time basis (802.1Qbv) or credit basis (802.1Qav), the possibility of interrupting frames (frame preemption, 802.1Qbu) as well as standards for redundancy and network configuration.

Which of these mechanisms should be used in which combination and configuration and with which performance characteristics - such as accuracies or memory sizes - for a specific application is not further specified in the TSN basic standards. Different solutions can typically be found for individual applications. However, the choice has a significant impact on the hardware and software required for the infrastructure and endpoints, as well as on the interoperability between them. Devices that would support all standards in their maximum configuration with all configuration options would be very complex and expensive. Application-specific solutions, on the other hand, always have the basic idea of standard hardware and inexpensive hardware. The market therefore has a great interest in defining profiles for specific application classes. In the TSN environment, groups have been formed for various sectors, in particular for the industrial, automotive, ProAV and aviation sectors, which have set about defining profiles. These differ in terms of technical details. However, they also differ in terms of whether a profile merely specifies what infrastructure and endpoints must support or whether the profile also ensures interoperability between applications based on it.

So how far have the individual profiles progressed? Employees and specialists from the specialist groups summarize the results to date and the status quo of the respective activities.

Milan - The TSN profile of the ProAV industry

Manufacturers in the audio/video industry are developing a system network called Milan on the basis of TSN. Henning Kaltheuner comments on the current status of the work.

Henning Kaltheuner, Head of Strategic Business Development and Market Intelligence at dbaudio: "As a network that is also used on the move in particular, Milan must support plug and play."

© dbaudio

Mr. Kaltheuner, what is the motivation behind Milan's work?

Henning Kaltheuner: Milan was launched in the fall of 2016 on the initiative of some leading manufacturers in the pro audio industry. The main motivation lies in the need to be able to position products that were previously considered and marketed individually - speakers, amplifiers, processing/mixing - only in a networked system context in the future. 'Everything will be networked' is an undisputed perspective throughout the ProAV industry, but the 'when' and 'how' have long been open questions.

The decisive factor here is that if the system and network represent essential parts of the customer benefit in the application, then manufacturers must be able to master these aspects themselves and implement them in creative solutions. This is not possible on the basis of proprietary protocols, but requires cooperation on open standards. TSN is the way forward.

What would be a typical use case covered by the profile? Can you name typical KPIs?

Milan will be used as a system network at events of all kinds, large concerts and festivals, in media installations in theaters, opera houses, concert halls, churches and conference centers as well as for media in general building installations for commercial applications such as stores and companies.

As a network that is also used for mobile applications in particular, Milan must support plug and play. Such networks include components of widely varying complexity and bandwidth. Scaling the standard from small endpoints to units with thousands of audio channels is an essential KPI.

Which standards does Milan use and to what extent?

Milan is essentially based on IEEE 802.1BA-2011, 802.1Q-2014, 802.1AS-2011, IEEE 1722-2016 and IEEE 1722.1-2013, whereby Milan predominantly specifies which parts of these specifications are used in which way in order to achieve actual end-to-end interoperability.

In addition, Milan itself specifies an optional redundancy scheme for endpoints, which defines two network ports as primary and secondary with seamless switchover in case of network failures.

It is important to note that Milan endpoints can use all Avnu-certified AVB switches as switches.

Is interoperability of applications based on the profile a goal?

ProAV systems consist of heterogeneous components and are put together depending on the use case. Seamless interoperability at the network level is essential and this includes basic functionality regarding stream connectivity, device enumeration & control and redundancy. Milan as an Interoperability Profile covers these aspects based on the IEEE TSN standards. However, most manufacturers have their own applications, which usually do not claim to be universally valid, but form the basis for the manufacturer's specific value proposition. However, this is not a contradiction, but rather illustrates the possibilities of a system structure where a jointly agreed network layer offers room for individual innovation and cooperation. A network should not and must not be a straitjacket of restrictive rules, but must offer space for technical and business opportunities.

What stage of development is the profile at? When can we expect a release?

The first version of Milan has existed since 2019. An initial certification process has been underway at UNH in Boston since then and a number of products have already been successfully certified and are in practical use. This also includes a process for certified modules so that manufacturers can use them in their products as a quick introduction to Milan without major development and certification effort.

In autumn 2021, the Avnu Alliance will launch a new certification program based on a new simplified automated test tool and with new international test labs as partners. This will make it much easier for the many small manufacturers in the ProAV industry to have their products certified in the future.

What are the biggest challenges?

Companies in the ProAV industry are mostly medium-sized and have limited resources to develop complex technology standards. Milan is a technical and business necessity from a strategic point of view and yet a major challenge for a severely impaired industry, especially in times of pandemic. Fortunately, a climate of very constructive cooperation has developed between the companies, which goes far beyond the technical aspects and highlights the importance and necessity of networks in a very general sense.

P802.1DG - The TSN profile for automotive in-vehicle Ethernet communication

The automotive industry is developing the IEEE P802.1DG profile on the basis of TSN. Max Turner comments on the current status of the work.

Max Turner, Automotive Network Architect at Ethernovia BV: "The biggest challenge is that we don't know exactly what future mobility concepts should look like."

© Ethernovia

Mr. Turner, for which applications is the P802.1DG profile being developed?

Max Turner: We are developing IEEE P802.1DG for the automotive industry. In other words, primarily for use in private cars. Although it is to be expected that passenger cars will increasingly be equipped with ADAS functions, I think it would be interesting to investigate how the same technologies could be applied to actual self-driving robo-taxis.

What would be a typical use case covered by the profile? What are typical KPIs?

The profile is intended to cover all in-vehicle network architectures, i.e. from domain-based to zonal. The general view is that an Ethernet-based network is most beneficial to the industry as multiple services such as control, audio/video and web traffic can be carried over the same cable. This has been established as 'triple play' in the home and office environment for a number of years, but in the car we still mostly use specialized bus systems for different applications.

As far as KPIs are concerned, latency is the most important, followed by latency fluctuations and buffer requirements for switches.

Which standards does the P802.1DG profile use and to what extent?

I would like to mention in particular IEEE Std. 802.1AS for time synchronization, as well as IEEE 802.1Q in general. The Credit Based Shaper - CBS for short - of IEEE Std. 802.1Qav has already been in use in some vehicles for around ten years and is certainly also covered. The Asynchronous Traffic Shaper - ATS for short - in IEEE Std. 802.1Qcr offers a very similar functionality, which requires the Per-Stream Filtering and Policing - PSFP for short - of IEEE Std. 802.1Qci, which is of course also interesting for other functions. The similarities with known time-controlled systems put the Time Aware Shaper - IEEE Std. 802.1Qbv: Scheduled Traffic - on the list. For certain audio applications, Frame Preemption - IEEE Std. 802.1Qbu and IEEE Std. 802.3br - is certainly under discussion.

The rest of the list is unfortunately quite long if you also look at some of the configuration and network management protocols - in the IT sense, not the automotive sense.

Is the interoperability of applications based on the profile a goal?

Interoperability at the layer 2 level where these protocols play is definitely the goal and one of the key things that standardization bodies like the IEEE are striving for. Apart from that, application development in the automotive sector is not very homogeneous. Many OEMs have enriched Autosar with their own functions and features. The P802.1DG profile is more focused on the infrastructure and the underlying network technologies than on application-specific interfaces.

What is the development status of the profile? When can a release be expected?

The profile is still at a very early stage of development. With the growth of the TSN tool set, as listed above, it is quite a challenge to select the right tools for the automotive use case. Many of them have been developed for very specific applications in telecommunication or computing center networks, and analyzing the differences and similarities takes more time than perhaps originally expected. We are still aiming to produce a good draft of the document within the next two years. The uncertainties in the automotive sector in general and the disruption of the regular IEEE meeting calendar due to Covid-19 have also played a delaying role.

What are the biggest challenges?

They lie in the uncertainty about future mobility concepts. In my personal opinion, the architectures will be very different: firstly in passenger cars that focus heavily on level 2 driver assistance systems, i.e. ADAS, secondly in passenger cars that want to provide some level 3 or even 4 automation in certain scenarios or ODDs, but focus on the human driver as the main operator of the vehicle, and thirdly in fleet-operated robo-taxis that no longer even have a human driver in daily operation, but rely entirely on the ADAS to control them in a very limited environment. There are differing opinions as to which of these three models will dominate the market in ten or 20 years' time. OEMs do not want to reveal their product strategies. They believe that these could be derived if they describe their network architectures in more detail.

IEEE P802.1DP/SAE AS6675 - The TSN profile of the aerospace industry

The aerospace industry is working on the IEEE P802.1DP/SAE AS6675 TSN profile. Abdul Jabbar comments on the current status of the work.

Abdul Jabbar, Senior Engineer at GE Research: "The aerospace industry is at a turning point: it needs an open network standard for the next generation of aircraft."

© GE Research

Mr. Jabbar, for which industry and which user is the profile being developed?

Abdul Jabbar: The IEEE P802.1DP/SAE AS6675 TSN profile is being developed jointly by IEEE and SAE for the entire aerospace industry. This includes commercial and military aircraft, unmanned aerial vehicles, satellites and other spacecraft. Since the on-board network affects more than just the network interfaces, this profile would impact many stakeholders in the aerospace supply chain.

What would be a typical use case covered by this profile? What are typical KPIs?

The working group, in close cooperation with industry, has collected a total of eleven use cases and their requirements and published a report, which is available on the project homepage. One example of the use of this profile is the aircraft control domain - ACD for short - for the avionics network in commercial aircraft or the vehicle management network in military aircraft. These use cases require determinism, high availability and reliability. Unsurprisingly, the KPIs fall into these categories and include latency limits, jitter and packet loss. One requirement that goes beyond the traditional KPIs is the security certifiability of the resulting network. While certification by a specific regulatory authority goes beyond the scope of the profile, the joint working group pays close attention to the aspects of the profile - such as complexity and verifiability, which play a decisive role in certification.

Which standards are used and to what extent?

Like all 802.1 profiles, the aerospace TSN profile is based on the IEEE 802.1 and IEEE 802.3 standards. In particular, the profile uses TSN standards for time synchronization, ingress policing and filtering, egress shaping, frame replication and elimination for redundancy, and ultimately for configuration. Although the aim is to fully utilize these standards, the profile allows for a more restricted or limited use of network features depending on the aerospace application. For example, aerospace networks are usually limited in terms of the number of nodes and the number of hops.

Is the interoperability of applications based on the profile a goal?

Interoperability is one of the main goals of the aerospace TSN profile. Until now, the aerospace industry has lacked network interoperability between devices, vendors and platforms. The goal of this profile is to enable seamless interoperability between end systems and switches so that system integrators can build systems more efficiently. The interoperability of applications is not a goal of this profile.

What is the development status of the profile? When can a release be expected?

The development of an IEEE profile usually comprises three steps: collection of use cases, derivation of requirements from use cases and development of a profile specification that fulfills the requirements of the use cases. In the case of the aerospace TSN profile, the first two steps have already been completed. The group is now working on a profile specification with TSN features that meet the requirements of the aerospace use cases. The expected completion date according to the project approval application is April 2023, but the profile should be technically ready much earlier.
be technically ready much earlier. In accordance with the IEEE standard development process, drafts will be available on the project homepage as soon as the standard is mature.

What are the biggest challenges?

While there are still some important tasks related to the theoretical analysis of traffic shapers and policers for aerospace networks, the biggest challenge is the lack of time of TSN and aerospace experts. And this at a time when the aerospace industry is at a turning point and wants to introduce an open network standard for the next generation of vehicles being developed.

The IEC/IEEE 60802 standard - The TSN profile for industrial automation

The automation industry is working on the IEC/IEEE 60802 standard for a TSN profile. Ludwig Winkel comments on the current status of the work.

Ludwig Winkel, Consultant for Standards & Regulations: "We expect the first release of 60802 by the end of 2022."

© Ludwig Winkel

Mr. Winkel, for which industry and users is the profile being developed?

Ludwig Winkel: The IEC/IEEE 60802 standard is intended for industrial automation. In other words, for users primarily from the manufacturing and process technology industries.

In recent years, the IEEE 802.1 Task Group TSN has developed a toolbox of diverse technical possibilities that cannot be considered as a system in itself and are in part mutually exclusive. These standards were primarily created by the information and communication industry. From the perspective of the OSI model, only layers 1 and 2 are in the scope of IEEE 802. One or more 'time-sensitive networking' profiles - i.e. TSN profiles - are necessary for industrial automation in order to make sensible use of the diverse technical possibilities offered by the various standards of the working groups in IEEE 802.

What would be a typical use case covered by the profile? Can you name typical KPIs?

A key use case of the standard is the convergent network approach. In other words, end users want to operate the Real-time Ethernet communication profiles of the IEC 61784-2 standard side by side on a shared infrastructure - shared switches and cabling. They also want to share parts of the standards in IEEE 802.1 Task Group TSN. Not all 25 profiles will probably support the 60802 standard, but the most widespread consortia on the market, such as PNO, ODVA, OPC-F, CC-Link and Ethercat, support 60802 through the active or passive participation of their experts.

Which standards are used and to what extent?

The 60802 standard focuses on four areas of use, which naturally also has an impact on the standards used or to be generated:

Firstly, the convergent network. This approach is essentially characterized by two IEEE 802 standards: clock synchronization based on IEEE 802.1AS and the pre-emption mechanism for transmission speeds of 10, 100 and 1000 MB/s, which ensures low latency times with low jitter.

Secondly, the planning and parameterization of the TSN communication domains: A convergent network that is to have components from different manufacturers requires a standardized model and a standardized interface for planning and parameterization. For this reason, several IEE 802.1 extension projects are underway.

Thirdly, the system properties of the TSN communication domains: In the past, system properties were rare or non-existent in IEEE 802. The motto was that the standards contain normative elements per device. Considerations such as "How long does the transmission take via 64 switches" were not answered. Since July 2020, the 60802 Joint Working Group has prevailed over IEEE 802.1 to also consider the system properties.

Fourthly: securing the transmission: The requirements of industrial automation for the convergent network necessitate a convergent cybersecurity approach in particular. The necessary prerequisites for this are to be created within the framework of 60802.

Is interoperability of applications based on the profile a goal?

Industrial automation applications clearly require interoperability.

What stage of development is the profile at? When can a release be expected?

According to initial plans, the project should be completed in 2021. The marriage of IEC and IEEE is one reason for the delay, because the IEC and IEEE processes have to be worked through.

The development status of the 60802 project is that a fourth Committee Draft document is circulating at IEC for comment. The document is identical to the D1.3 document at IEEE 802.1, which was approved as a 'TSN Task Group ballot'. A first release of 60802 is expected at the end of 2022. The publication of Edition 1 is planned for 2023.

What are the biggest challenges?

The system aspects that were a matter of course in standardization work for industrial automation have only been included in this joint project since July 2020. The interoperability requirements in industrial automation go so far that the quantity structures of resources in the devices also play a role. This point has been a bone of contention for years, but we are well on the way to solving this problem in the future 60802 standard.