Coexistence & Convergence in TSN-based Industrial Automation Networks

 
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
 
System
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!
 
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 4 should be integrate-able to this functional unit (then is
this functional unit „a safe neighbourhood/TSN domain“
anymore? It should be.)
 
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
 
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?)
Slide Note
Embed
Share

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.


Uploaded on Sep 14, 2024 | 0 Views


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


  1. Coexistence & Convergence in TSN-based industrial automation networks Marius Stanica, IEEE/IEC JP 60802, July 2018, Frankfurt

  2. 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

  3. 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)

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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?)

Related


More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#