來源：TSNLAB 微信公眾號

寫在前麵，TSN組態協同實踐案例的關鍵特征：

1、沒有對端側設備的軟硬件升級提出要求；

2
、開發工作主要在自動化軟件上完成 - 這裏體現了OT工程師和IT工程師的配合；

3、不改變工業用戶的現有使用習慣。

---------------------------------

讀過《端到端的TSN方案需要TSN端設備嗎？》、《加速TSN應用的兩個路徑：流量自學習與組態協同》的讀者一定了解這樣一個結論：當TSN端設備和網絡設備協同工作時

，TSN端到端的效果是最好的（包括有界低時延的保障、易用性等）。

這裏的協同，就體現在“控製麵協同”和“數據麵協同”上。前者是易用性的關鍵，而後者則影響有界低時延的保障性能。

控製麵協同：

為便於理解，我們再次使用這張圖：

用戶和網絡交互信息的接口


，TSN標準中叫做用戶網絡接口（UNI，User-Network Interface）。在純分布式模型中
，這個接口具體通過網絡協議夾帶信息實現

，如多流注冊協議（MSRP，Multiple Stream Registration Protocol）
，正在製定的資源分配協議（RAP，Resource Allocation Protocol）等；在分布式用戶、集中式網絡模型中

，這個接口存在於用戶端設備和集中式網絡配置（CNC，Centralized Network Configuration）控製器之間；在純集中式模型中，這個接口存在於代表用戶的集中式用戶配置（CUC，Centralized User Configuration）控製器和CNC控製器之間。對於後兩種情況
，標準TSN並未限定接口的具體形式
，例如可以通過RESTCONF、NETCONF協議實現。

相比於UNI的實現機製而言
，更重要的是它在TSN方案部署流程中的位置
，和具體要傳遞的重要信息。端網協同的TSN方案部署流程說起來非常簡單，三步：用戶聲明信息（需求），網絡進行資源預留（配置），用戶發送報文。用戶與網絡的交互，在第一、第三步中都存在。在第一步中
，用戶要告知網絡最重要的信息，就是我的流量從哪兒來（源地址）、到哪兒去（目的地址）
，流量的特征
，對時延保障（上限）的需求。其中，流量的特征（TSpec，TrafficSpecification）在UNI標準定義中，通過周期、每周期的最大報文數量、baowenzuidachangdujinxingmiaoshu。zaidisanbuzhong
，wangluoyaogaozhiyonghu，ziyuanyuliushifouchenggong。ruguochenggong
，yonghusuihoufachulaidebaowen，jiunenggoudedaowangluotigongdebaozhang。

TSN還提供了一種TSpec的de擴kuo展zhan，用yong戶hu可ke以yi額e外wai告gao知zhi網wang絡luo
，在zai每mei個ge周zhou期qi內nei
，可ke以yi在zai特te定ding的de時shi間jian段duan內nei執zhi行xing信xin息xi的de發fa送song。而er網wang絡luo結jie合he對dui資zi源yuan預yu留liu的de整zheng體ti設she計ji，給gei用yong戶hu指zhi定ding一yi個ge具ju體ti的de發fa送song時shi間jian。例li如ru，用yong戶hu告gao知zhi網wang絡luo，需xu要yao以yi每mei100ms為周期，發送1個不長於1000Byte的報文
，並且可以在每個周期的0-20ms之間執行發送；網絡最終反饋用戶，請在每個周期的第10ms發送報文。

由you於yu上shang述shu流liu程cheng，是shi通tong過guo在zai用yong戶hu和he網wang絡luo之zhi間jian交jiao互hu協xie議yi信xin息xi完wan成cheng的de
，和he用yong戶hu業ye務wu本ben身shen所suo需xu要yao的de報bao文wen傳chuan輸shu無wu關guan，所suo以yi在zai網wang絡luo的de視shi角jiao下xia，我wo們men稱cheng其qi為wei控kong製zhi麵mian的de協xie同tong。

數據麵協同：

端和網在數據麵的協同


，是控製麵實現了正確交互
、網絡完成了配置之後的自然結果。具體說明

，在一個網絡設備的出端口A的隊列a上，規劃了使用CBS來承載10條流，而這10條流通過TSpec折合出來的總帶寬，一定不大於該隊列a所述的CBS class的配置參數IdleSlope
；或規劃了使用一個ATS scheduler來承載10條流，那這10條流通過TSpec折合出來的總帶寬，一定不大於該ATS scheduler的配置參數CommittedInformationRate。

再以使用門控調度為例。例如A、B兩個端設備，都需要以每100ms為周期發送報文
，且可以在每個周期的0-20ms之間執行發送。A、B兩個設備發出的報文需要在同一個網絡設備的出端口A上競爭轉發時間，網絡通過規劃
，決定讓A設備在0ms發送報文，讓B設備在5ms發送報文，則可以避免這種競爭。

由於我們在《加速TSN應用的兩個路徑：流量自學習與組態協同》一文中已經表達了，需要在不更改現有端設備的條件下實現端到端TSN部署
，所以，組態協同方案及其實踐，主要體現在控製麵協同。

組態協同方案的效果，用一句話就可以表達：用戶在使用工業自動化軟件進行設備組態時
，TSN控製麵的所有工作在同期就完成了。

OPC UA + TSN 組態協同方案：

基於open62541開發OPC UA控製係統
，與TSN進行協同的核心思想如下圖所示。具體來講，TSN配置中間件提供接口供OPC UA程序調用，從而使端設備具備“分布式用戶
、集中式網絡配置模型”中與TSN網絡進行標準化交互的能力。

具體實現的係統如下：TSN中間件以C語言庫的形式提供函數功能，在用戶開發OPC UA和EtherCAT主站時被調用
，從而主站具備將關鍵流量特征（TSN時間同步下的周期定時發送）和需求信息上報網絡的能力；網絡控製器CNC以網絡和流量信息為輸入，編排出TSN門控信息，自動下發配置；用戶端設備發出的各關鍵流，與其對應路徑上交換機的門控狀態匹配，保障有界低時延
，實現了一套傳送帶切割的模擬自動化係統。

61499 + TSN 組態協同方案：

下圖為某61499軟件的組態界麵

，已支持TSN功能。工作原理很簡單：61499軟件後台可以調取關鍵流量的特征信息
，從而轉遞給軟件後台的TSN網絡配置模塊；後者基於流量信息，一方麵可以識別這些關鍵流
，另一方麵對這些關鍵流使用相應的TSN調度機製
，從而保障其有界時延、零丟包。

用戶操作過程如下：

1
、將網段設置為TSN，端設備連接在這個網段上；

2
、在設備欄選擇TSN交換機
，拖入組態界麵，連接到網段上；

3、輸入交換機的IP地址等基本信息；

一鍵配置使能TSN。

上述兩個案例的詳細信息亦可參考TSN測試床彙總 （截止2023.12）。

這樣的實踐案例
，給加速TSN的應用落地帶來打了一劑強心針。回顧最前麵寫到的關鍵特征，相信大家會有更好的體會：

1、沒有對端側設備的軟硬件升級提出要求

；

2
、開發工作主要在自動化軟件上完成 - 這裏體現了OT工程師和IT工程師的配合
；

3、不改變工業用戶的現有使用習慣。