Coexistence & Convergence in TSN-based Industrial Automation Networks
This document explores the coexistence and convergence aspects in TSN-based industrial automation networks, discussing topics like configuration models, traffic shaping mechanisms, network redundancy, and seamless/non-seamless solutions. It delves into the problem statement of configuring TSN features across different functional units and network segments. The needed functions for synchronized reservations management involving Head-CNC, Local-CNC(s), and bridges are also outlined to ensure efficient network operations.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Coexistence & Convergence in TSN-based industrial automation networks Marius Stanica, IEEE/IEC JP 60802, July 2018, Frankfurt
Topics Coexistence of the TSN configuration models Coexistence of two traffic shaping mechanisms o For the same traffic type o Convergence of network segments supporting various port/media redundancy mechanisms o Seamless: IEEE 802.1 CB, IEC 62439 PRP, HSR o Non-seamless: IEC 62439 MRP, DLR
Coexistence. Configuration. Problem statement Operations & Engineering Section Centralized configurable System Operations Server Control Engineering Server Network Management Server Operations & Engineering Network Infrastructure Process & Field Mixed methods of TSN features configuration Operations & Engineering: fully-centralized Network Infrastructure: fully-centralized Process & Field: mixed Functional Unit 1: fully-distributed Functional Unit 2: fully-centralized Functional Unit 3: fully-distributed Head-CNC: a CNC which has an understanding of the whole system Local-CNC: a CNC for a functional unit (if needed/relevant) a physical subnetwork Examples of TSN domains: Functional Unit 1, Functional Unit 2, Functional Unit 3, Network Infrastructure, Operations & Engineering, Communication2HMI System has to work! Workstation O&E Switch 1 O&E Switch 2 Network Infrastructure Section Centralized-configurable Backbone Switch 1 Backbone Switch 2 Backbone Switch 3 Process & Field Section P&F Switch 3 Drive 1 P&F Switch 2 P&F Switch 1 Drive 5 Controller 4 Controller 1 IO Device 1 Drive 2 Drive 6 Controller 5 Controller 2 IO Device 2 Drive 3 Drive 7 Controller 6 Controller 3 IO Device 3 Drive 4 Functional Unit 2 Centralized-configurable Functional Unit 1 Distributed-configurable Functional Unit 3 Mixed (d, c)
Coexistence. Configuration. Needed functions Synchronised and joint (dynamic and/or static) reservations management Actors involved Head-CNC, Local-CNC(s), bridges Understanding of the system Head-CNC has knows/discovers the capabilities of the whole network, including of bridges which are not centralized-configurable Synch (between fully-distributed and centralized bridge resource-related reservations) Head-CNC polls boundary bridges of the fully-distributed subnetwork(s) for currently allocated reservations Head-CNC informs the boundary bridges (of the fully-distributed subnetwork(s)) about reservations made over the centralized model CNC-hierachy control Head-CNC polls Local-CNC(s) for their centralized-allocated resource reservations Race conditions avoidance Locks must be in place while a poll is ongoing for a bridge, both for bridges and CNC reservations Locks must be also in place in bridges and Local-CNC(s) when Head-CNC poll happens Reservations conflict management Head-CNC must be capable of handling conflicts: identification, analysis, solution, information of all parties Security Authentication Diagnostics Early identification of misconfigurations Support for troubleshooting in case of misconfigurations Nice to have: Dynamic resource-usage optimization Head-CNC may perform regular analysis of the traffic and of application communication requirements and may propose optimizations, following current situation
Coexistence. Traffic shaping. Problem statement TSN domain for Functional Unit 1 Only cyclic communication traffic type/pattern (for now, let us consider just this example) within this Functional Unit Three Drives and a PLC supporting the same traffic shaping mechanism for cyclic communication (i.e. Qav) One Drive (Drive 4), supports only another traffic shaping mechanism for cyclic communication (i.e. only fixed priority) and it is brought in, i.e. as a fast replacement (until a new device arrives following order) Daisy-chain ring topology Bridges support both traffic shaping methods TSN configuration model: as presented in Slide 3, thus Drive 4 supports only fully-distributed TSN configuration Drive 1 P&F Switch 2 P&F Switch 1 Drive 2 Drive 3 Controller 6 Drive 4 (can only fixed prio) Drive 4 should be integrate-able to this functional unit (then is this functional unit a safe neighbourhood/TSN domain anymore? It should be.) Functional Unit 1 Traffic shaper for cyclic: Qav
Coexistence. Traffic shaping. Needed functions Synchronization between traffic shaping mechanisms It depends on which exact traffic shapers do we refer to The example with Qav and Fixed Priority is rather easy and can be handled by the fully- distributed TSN configuration model If the preponderent traffic shaper would have been Qbv and the added device would only support Qav, then the fully-distributed TSN configuration model would not be enough (as of todays Qcc) to support such an use case, without the support of a CNC Configuration coexistence concepts from the previous chapter would be a good fit Head-CNC must be capable of Understanding which traffic shapers are supported in the system Calculate the correctly needed reservations Send the reservations towards the bridges of Functional Unit 1
Convergence. Redundancy. Problem statement Same system as in Slide 3 Seamless media redundancy model is IEEE 802.1 CB in the Operations & Engineering and Network Infrastructure Seamless media redundancy model in Functional Unit 1 is a different one: i.e. HSR Could be also viceversa than in the pictured example: there is a functional system working on a given seamless media redundancy (i.e. HSR, PRP, ) and an new functional unit based on IEEE 802.1 CB is added Functional Unit 1 should be integreatable without the need of additional hardware Operations & Engineering Section .1 CB Operations Server Control Engineering Server Network Management Server Workstation O&E Switch 1 O&E Switch 2 Network Infrastructure Section .1 CB Backbone Switch 1 Backbone Switch 2 Backbone Switch 3 Drive 1 P&F Switch 2 P&F Switch 1 Drive 2 Drive 3 Controller 6 Drive 4 Functional Unit 1 Other seemless redundancy
Convergence. Redundancy. Needed functions Compatibility between mechanisms of doubling/elimination of double frames must be achieved, for seamless mechanisms Non-seamless media redundancy protocols (i.e IEEE RSTP, IEC 62439 MRP) are already coexistent with 802.1 CB PRP, HSR are interoperable with 802.1CB (at least partly?)
