Concrete Steps for PROFINET@TSN Implementation
Without real-time communication, many automation tasks in control and motion applications would be unthinkable. This is why lots of expectations are currently being raised regarding Time Sensitive Networking (TSN) technology and many questions asked as well. What’s the guaranteed transfer time, latency and performance? Can I continue using existing technologies? When will the new technology be ready? PI is providing concrete answers to these questions.
A lot of details stand in the way of implementing the new technology. One of the most important requirements is that users continue to be able to use their tried-and-tested PROFINET applications and existing architectures. The new technology should also still be manageable by the user – it’s hard to sell added complexity.
PI has taken a closer look and begun by getting an overview of what is needed by the various different options of TSN for automation. It’s essential to understand what TSN actually stands for. The technology defines the path of communication and behavior of the switches/bridges from the source across multiple switches to the destination to guarantee real-time behavior (shown in figure 1). In IEEE 802.1, several processes for TSN have been specified so that the best mechanisms for the required real-time behavior are available, depending on the application. Not all of these processes are suitable for automation. For audio and video transmissions, for example, a “waterfall model” (IEEE 802.1Q – Credit-based shaper/IEEE 802.1BA) offering transfer times of 10 – 20 ms and only one transmission direction is suitable. This makes sense for streaming services, but a one-way solution is not suitable for control loops. Also, the cycles are too slow.
A Good Choice
PI chose four TSN mechanisms which are especially important for the real-time transmission requirements in automation. They are the following:
- Time synchronization as per IEEE 802.1ASrev (i.e. Less than 1 µs jitter for transmission list control and synchronous applications)
- Enhancements for scheduled traffic (time slots for real-time data and other data) as per IEEE standard 802.1Q-2018 (previously IEEE 802.1Qbv)
- Frame preemption as per IEEE 802.1Q-2018/IEEE 802.3-2018 (previously IEEE 802.1Qbu/IEEE 802.3br) (interruption of low-priority telegrams)
- And link layer discovery as per IEEE 802.1AB for recording the topology.
These processes are ideal for low latency and high performance. These are typically the same principles which apply for IRT (isochronous real time). In other words, PI sets the right course in the past.
Simplifying Complexity
Admittedly, the mechanisms involved – especially against the backdrop of international standardization – are very complex. Who wants to know exactly how the switch for transiting information works? It must be a declared goal to design the new technology as simple as possible for the user, while at the same time remaining flexible for future Industry 4.0 use cases.
The good news is that it’s actually getting easier for the user, as today network configuration (i.e. The specification of communication paths from the controller to the device) is part of the engineering. In the future, this task will be transferred to the software of PROFINET devices and is, therefore, part of runtime in the controller or device. It’s necessary to note that every PROFINET device contains not only device parameters, but can also provide network parameters. This not only disencumbers the user but also increases flexibility.
In the future, there will be a Network Management Engine (NME) in every TSN domain, developed by PI experts and described in the specification. The NME will cover:
- Network configuration
- Topology discovery
- Path planning
- Best NME negotiation
The last point is required if, for example, multiple controllers are present and a decision has to be made regarding which information is more important and must, therefore, be passed through faster. The user then only needs to define simple rules for the network for the configuration calculation. The rules are:
- The selection of a working clock master (typically a PLC)
- Data rate (e.g. 100 Mbps or 1 Gbps)
- Domain name
- Scheduling the update cycles
These settings are made quickly, especially since they are defined for the entire network (the entire domain) and not for each device. This reduces expenditure considerably. Creation of a specified topology in the engineering phase is also no longer necessary, but still possible if required.
The NME calculates the paths and required settings in the switches using these basic settings and the results of the online topology discovery – for example, which switch is to be passed through with which information on what time. Here, the destination MAC addresses are defined for the TSN streams in order to parameterize switches from the controller to the device, for example. This procedure is also recommended in IEC/IEEE 60802. As additional (more extensive) coordination is required, therefore enabling a convergent network across all possible configurations, however, PI decided to already offer a compatible, yet practical, way to get started with TSN technology today: the NME.
The advantage for the user is that they have the same user perspective (IO data, parameterization, PROFINET behavior, etc.) as before. Considering the more than 20 million devices with PROFINET installed, this is a reassuring thought. The core architecture of PROFINET also remains the same, such as PROFINET state machines for the startup, data exchange, diagnostics, etc. Only the NME or the corresponding communication for downloading parameters for the network are added.
Proven Evidence
The proof that this really works was first shown by the demo model at the PI stand (Figure 3) on the SPS trade fair in November 2018 and afterward also at the Hanover Trade Fair in April this year. This demo was a combination of a variety of available TSN hardware modules and PROFINET stacks tested for network synchronization, IO synchronization, integration of existing devices and network load. It was shown that real-time-capable IO applications with a jitter of less than 1 µs are just as possible as plug-and-work during network changes. The easy connection of existing PROFINET devices and the robustness of PROFINET communication, even with high network loads, were also demonstrated. Though IEC/IEEE 60802 is not yet complete, the mechanisms developed by PI are already working. At the same time, the solution is so flexible that they can even be integrated if changes are made.
In the live demo, prototype implementations from different companies (Analog Devices, Hilscher and Texas Instruments) worked together with their respective proprietary hardware and firmware platforms. Interoperability between technology suppliers is crucial for PI. Only in this way do device manufacturers have the possibility to choose a platform that is best suited to their specific device. This is why PI also logically chose compliance with the TSN IA profile of IEC/IEEE 60802 once it’s specified. It’s there that the hardware requirements for automation, among other things, are defined so that an even larger ecosystem of semiconductor suppliers can be relied on for implementing the fieldbus interface.
Outlook
As with other PI projects, it has proven valuable to begin concrete implementation in the hardware and firmware through a variety of technology companies while at the same time working out the corresponding specifications. For instance, it’s possible to assess how the specifications can be implemented in real products and to verify whether the specification is consistent, complete and interoperable.
As a whole, this completes the next step of a proof of concept. The specification work has been recently completed. Other implementations are already in the works, as are preparations for corresponding certification tests. With this, the most important steps on the path toward implementing the new TSN technology are already being taken.