TWI812958B - 用於在網路中發送訊息之方法、裝置、系統、電腦程式及資料結構 - Google Patents

用於在網路中發送訊息之方法、裝置、系統、電腦程式及資料結構 Download PDF

Info

Publication number
TWI812958B
TWI812958B TW110119603A TW110119603A TWI812958B TW I812958 B TWI812958 B TW I812958B TW 110119603 A TW110119603 A TW 110119603A TW 110119603 A TW110119603 A TW 110119603A TW I812958 B TWI812958 B TW I812958B
Authority
TW
Taiwan
Prior art keywords
network
message
messages
publisher
devices
Prior art date
Application number
TW110119603A
Other languages
English (en)
Other versions
TW202147811A (zh
Inventor
克里斯多夫 曼金
Original Assignee
日商三菱電機股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日商三菱電機股份有限公司 filed Critical 日商三菱電機股份有限公司
Publication of TW202147811A publication Critical patent/TW202147811A/zh
Application granted granted Critical
Publication of TWI812958B publication Critical patent/TWI812958B/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1859—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast adapted to provide push services, e.g. data channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本發明係關於一種用於在具有通訊模式的網路中傳送訊息之方法，該通訊模式涉及該網路上之發布者裝置及訂戶裝置，該方法包含：- 提取所接收訊息之酬載(DataSetMessages)，並在同一組合式訊息內串連該等酬載，- 向該組合式訊息新增標頭，該標頭包含發布者裝置(PublisherId=k)之單一識別符，該發布者識別符係為預定識別符，以便將該組合式訊息指定給至少一個經選擇的訂戶裝置。

Description

用於在網路中發送訊息之方法、裝置、系統、電腦程式及資料結構
本揭露係關於方法、裝置及系統，用於在具有通訊模式之網路中傳送訊息，該通訊模式涉及該網路上之發布者裝置及訂戶裝置。
開放平台通訊統一架構(Open Platform Communications Unified Architecture(OPC UA))係廣泛用於自動化中之靈活性最佳努力(best-effort)通訊，逐漸取代OPC Classic、以及許多特定於供應商之協定。OPC UA在實現跨應用領域及自動化控制層次結構之各層級之統一標準化及安全通訊。
OPC UA規範已擴展，利用基於發布/訂閱資料交換原理之通訊(以下簡稱「PubSub」)，開闢了新使用情境，包括「多對多(many-to-many)」通訊。另外，OPC UA PubSub與時間敏感網路連結(Time Sensitive Networking(TSN))之整合旨在實現附有關鍵即時要求之通訊。
以下是有關OPC UA之更多詳細內容。OPC UA係一種用於基於TCP/IP的工業通訊之用戶端-伺服器協定，其標準化為IEC 62541。OPC UA伺服器對在物件導向資訊模型中結構化之資料及功能提供存取。 用戶端使用一組標準化服務與資訊模型互動。各服務為互動定義請求及回應訊息。然而，訂閱機制亦可僅在通知出現時才推送通知。
下文提出與所謂的「時間敏感網路連結(TSN)」有關之更多詳細內容。在IEEE 802.1標準系列裡，用於即時通訊之乙太網路的增強功能最初係開發為音訊視訊橋接(AVB)，最近已被擴展為時間敏感網路連結(TSN)。IEEE 802.1AS中規定的時脈同步方案以及經由IEEE 802.1Qbv之時槽保留轉移容量係自動化網路中附有即時限制條件之基礎標準。
已將工業通訊流量類型定義為符合在工業應用中發現之不同常見使用案例，包括其與TSN標準之關係。除了提供作為開放標準框架之效益外，在工業通訊中引進TSN還帶來了一些技術及效能方面之改善：˙潛在更高之流通量，˙透過橋接網路中的多點跳躍以差異化且經保證服務品質來混合連接之靈活性，˙工業用例及消費性裝置兩者都屬意之廣泛技術之規模經濟。
OPC UA中之「發布/訂閱」機制讓許多訂戶就主題進行註冊，其中已發布之訊息係轉發給訊息之主題的所有訂閱者。此特徵讓許多訂戶可採用與舊有現場匯流排中實現之通訊方案類似之方式接收相同之訊息。已發布訊息之內容係藉由所謂的PublishedDataSet來定義，其代表來自OPC UA伺服器之資訊模型的變數與事件源之集合。可靈活組配PublishedDataSet，並可在伺服器中查詢其描述以解譯已發布資訊之語意。
OPC UA標準規範(第14節)係定義OPC UA PubSub到現有發布/訂閱協定之映射，尤其是MQTT(訊息佇列遙測傳輸(Message Queuing Telemetry Transport))及AMQP(先進訊息佇列協定(Advanced Message Queuing Protocol))。這些協定定義用於訊息分發之中央代理，並且常用於公用網際網路中。該標準亦定義基於UDP之自訂分發協定及對應之訊息布局UADP，這仰仗IP標準所提供之多播機制。使用UADP時，訂戶就由特定IP多播位址識別之多播群組進行註冊。
這種附二進制編碼訊息之傳輸非常適合在生產環境中頻繁傳輸少量資料之情況。發送至此位址之PubSub訊息將轉發給群組之所有成員。此一映射將發布者複雜度很大之一部分委派給現有網路基礎架構(路由器、交換機等)。最後，該標準亦定義直接透過資料鏈路層，即乙太網路，以相同之UADP布局，對PubSub訊息之傳輸。
在該組態中，OPC UA PubSub可與TSN整合以進行即時傳輸，並且承載UADP酬載之乙太網路訊框係藉由特定乙太類型(0xB62C)來識別。這種在乙太網路TSN上之映射使OPC UA PubSub實作態樣有可能非常輕巧，該等實作態樣假設固定之PublishedDataSet，並且直接產生所欲網路訊息，而無需在OPC UA伺服器中發現之軟體及網路交換額外負擔(overhead)。
下文提出與OPC UA中之發布/訂閱原則有關之更多詳細內容。DataSet構成了由Publisher所提供並由Subscriber(s)所耗用之訊息之酬載。Publishers及Subscribers係鬆散地耦合，並且其主要關係在於共同理解DataSets、包括這些資料的訊息之發布特性、以及訊息導向中間軟體。PubSub訊息稱為NetworkMessages。其包括：- 標頭資訊(例如：識別及安全資料)，以及 - 一或多個DataSetMessages(酬載)。
各DataSetMessage係建立自DataSet。Publisher的稱為DataSetWriter之組件產生連續一連串之DataSetMessages。DataSets之語法及語意係由DataSetMetaData描述。Publisher中DataSet之資訊選取及資料採集參數稱為PublishedDataSet。
圖1繪示這些不同角色及實體。DataSet係建立自事件或建立自變數值樣本。此應用程式-資料收集器之組態稱為PublishedDataSet。DataSet欄位可代表：Publisher中之內部變數、來自Publisher或由Publisher收集之事件、網路資料、或來自子裝置之資料。DataSet之結構及內容係由DataSetMetaData定義。
為了發布，將DataSet編碼成DataSetMessage，有可能進一步將其與其它DataSetMessages組合以形成NetworkMessage之酬載，如圖2所示。DataSetWriter係組配成用於編碼及傳輸含有DataSet資料之DataSetMessage。DataSets之組態以及取得資料以供發布之方式可使用OPC UA PubSub標準規範中定義之PubSub組態模型來組配。
圖3所示為包括DataSetMessage欄位、DataSetMessage、NetworkMessage及傳輸協定在內之NetworkMessage之構造中之不同層。
可將DataSetMessage欄位定義為DataSetMessage中特定DataSet欄位之表徵。DataSet欄位含有實際值，該實際值具有與其相關聯之附加資訊，諸如狀態及時間戳記。DataSetMessage係產生自DataSet，並且由標頭及DataSet之經編碼欄位所組成。取決於組態，DataSetMessage標頭可含有附加資訊，諸如： - 識別符DataSetWriterId，其識別DataSetWriter並間接識別PublishedDataSet，- 序號，- 時間戳記，- 版本ID，- 「保持連線」狀態。
作為資料合約，DataSetMetaData定義DataSetMessage中含有之欄位。DataSetMessage及NetworkMessage之標頭設定定義Publisher與Subscriber之間的通訊合約。NetworkMessage係DataSetMessages之容器，其包括標頭，用於傳達與DataSetMessages共同之資訊：
- PublisherId：識別發布者。
- 安全資料：僅可用於支援訊息安全性之編碼。在訊息映射中指定相關資訊。
- 促進欄位：從亦於標頭中發送之DataSet選出之欄位。
- 酬載：一或多個DataSetMessages。
酬載由DataSetMessages所組成，可根據經組配訊息安全性來加密。可「促進」DataSetMessage之個別欄位使其「脫逸」加密，並從而用於篩選及轉發。促進欄位之組態取決於NetworkMessage格式及使用之協定。在任何例中，均未將NetworkMessage標頭加密以啟用篩選及轉發。
現在，關於此訊息交換中涉及之實體，Publisher係發送 NetworkMessages之PubSub實體(如圖2所示)。其係為任意實體，不一定是特定網路節點(例如附特定IP或MAC位址之網路節點)或應用程式。Publisher通常可由一或多個發送訊息之網路節點所組成。
單一Publisher可支援多個PublishedDataSets及多個DataSetWriters。DataSetWriter係Publisher之邏輯組件。對於訊息發送，根據PublishedDataSet，訊息之建立始於要發布之資料集合(DataSet)，從而產生DataSet之個別欄位。
DataSetWriter接著從DataSet建立DataSetMessage。可將屬於相同WriterGroup之DataSetWriters建出之DataSetMessages插入單一NetworkMessage。DataSetMessages之格式及編碼係藉由一些組態參數(此處未定義)來固定。
NetworkMessage係建立自DataSetMessage、DataSetWriterId、DataSetClassId、ConfigurationVersion，其取自DataSetMetaData，與PublisherId一起定義在PubSubConnection上。訊息之結構係協定特定的。
NetworkMessages可基於與WriterGroup相關聯之PublishingInterval來循環發送，並且係從各PublishingInterval之開頭，以給定偏移量PublishingOffset發送。
Subscriber係組配成用來及/或使用發現機制來確定要訂閱哪些DataSetMessages以及要在哪個訊息導向中間軟體上訂閱。NetworkMessage標頭中之未加密資料係由Subscriber用於識別及篩選相關之Publishers、DataSetMessages、DataSetClasses。
一旦確定DataSetMessage相關，便將其轉發至對應之DataSetReader以供解碼成DataSet。接著，在Subscriber內進一步處理或調度所得之DataSet。
Subscriber藉由確立連線，例如藉由參與UDP多播群組或乙太網路多播群組，向訊息導向中間軟體所支援之分布群組註冊。
Subscriber將相關Networkmessages中感興趣之DataSetMessages調度給各DataSetReader，使用DataSetMetaData中提供之資訊解碼成DataSets。
圖4匯總PubSub組件與其在建立不同訊息編碼階段中之角色之間的關係。相對於PubSub訊息映射，在可透過UDP/IP或乙太網路傳輸之訊息之UADP編碼之文脈中，可提出下面之說明作為實施例。UADP訊息映射定義不同任選標頭欄位、欄位設定以及不同訊息類型與資料編碼。
圖5所示為一般UADP NetworkMessage布局。不同標題及欄位是否存在，端視PubSub通訊組態參數而定。使用安全性時，對酬載及填塞(padding)欄位進行加密，如果將簽署及加密組配為有效，則對整個NetworkMessage進行簽署。NetworkMessage只有在簽署有效時才予以簽署。
圖6進一步繪示NetworkMessage之酬載及酬載標頭之通用格式。在這裡，還可存在或忽略標頭及欄位，端視DataSetMessage布局組態而定。
為NetworkMessages之傳輸指定兩種傳輸協定：OPC UA UDP及OPC UA乙太網路。以下詳細說明中僅說明OPC UA乙太網路。 UADP NetworkMessage係作為最大1522位元組尺寸之VLAN標記乙太網路II訊框之酬載予以傳輸。用於UADP通訊之IEEE註冊之OPC UA乙太網路類型係0xB62C。
在透過TSN進行傳輸之情況下，由Writergroup建立之NetworkMessages係透過TSN串流發送，其可藉由IEEE 802.1CB中指定之串流識別功能來識別。典型之識別功能將目的地或來源MAC位址與包封NetworkMessages之乙太網路訊框之VLAN-ID結合使用。
將PubSub層級時序參數(PublishingInterval及PublishingOffset)映射到TSN時序參數上主要是藉由使用IEEE 802.1Qbv所提供之排程方案來完成，其允許定義傳輸週期以及這些週期內之傳輸次數，即傳輸偏移量。
下文說明以固定式布局資料進行週期性通訊之NetworkMessage格式。NetworkMessages及DataSetMessages之UADP標頭格式係設計為具有靈活性，並且藉由啟用或停用標頭內之個別欄位來支援不同使用案例。
所以，可能之標頭欄位組合之數量造成其實作態樣之複雜度增加。反之，有些具有特定使用案例之應用域可依賴組態，其中標頭布局包括合理之一組標頭選項，以針對不同使用案例在靈活性、可交互運作性與支援之間提供折衷。
OPC UA第14部分之附錄C說明這些使用案例之一：在即時資料之循環交換中使用PubSub。在這種組態中，於每個PublishingInterval轉移之資料之布局具有固定性，並且可藉由組態從 Publishers及Subscribers得知。當DataSetMessages之尺寸恆定時，甚至可進一步推送最佳化。
接著，假設以下條件：- 各NetworkMessage含有相同數量之DataSetMessages，- NetworkMessage內DataSetMessages之序列於每個PublishingInterval具有等同性，- 每個DataSetMessage內欄位之布局於每個PublishingInterval具有等同性。
PublisherId及WriterGroupId識別WriterGroup。NetworkMessageNumber係用於WriterGroups，其在數個NetworkMessages中發送其DataSets。GroupVersion允許Subscriber驗證DataSetMessages及其DataSet欄位之預期布局。
圖7中所示之標頭布局繪示此使用案例未實施安全性時的狀況。當實施安全性(例如僅簽署)時，標頭布局包括附加之安全標頭及簽章，如圖8a所示。DataSetMessage標頭係縮減為圖8b所示之欄位。
下文提出訊息布局實施例。第一實施例係沒有安全性之固定訊息布局。這種組態確保每個NetworkMessage均具有恆定之標頭及DataSet欄位布局。訊息之編碼及解碼由於所有欄位之偏移量恆定而簡化。酬載標頭得以省略，其標準含有之資訊係由Subscriber推導自DataSetMetaData、DataSetWriter及WriterGroup。這種組態假定各DataSetMessage之尺寸均恆定，這可以藉由組態來保證。
適當的組態亦保證DataSetMessages之數量及其在 NetworkMessage內之序列於所有發送之NetworkMessage都維持等同。圖9中繪示這些屬性。
第二實施例係具有安全性之固定訊息布局。相同組態可予以安全地擴展，並且導致圖10所示之緊密NetworkMessage格式。
要解決之問題：接著，OPC UA為複雜系統之實體之間的資訊交換指定了非常靈活之方案，能夠支援各式各樣的應用域。支援這些交換之通訊協定中反映這種靈活性。
這種靈活性係以潛在之巨大額外負擔為代價，如圖5所示之基本NetworkMessage格式所示。圖19展示表格，該表格匯總可能在沒有安全性之PubSub NetworkMessage中找到之不同標頭所引起之額外負擔。
對於(N+1)個DataSetWriters，此布局可能導致最大訊息長度為：21+11+[1+(N+1)x2]+10+PF+(N+1)x2+PL個位元組。
鑑於未促進欄位(沒有在NetworkMessage之未加密部分中複製)，這會產生47+4N個位元組之潛在額外負擔。
當使用上述緊密UADP布局傳送循環資料時，額外負擔接著減少，如圖20所示之其餘白底列所匯總。
無論DataSetWriters之數量是多少，緊密布局在沒有安全性之情況下，可能導致最大訊息長度為：4+11+PL個位元組，賦予15個位元組之額外負擔。
雖然緊密UADP布局使PubSub額外負擔大量減少，後者仍 必須在其應用環境中加以考量，尤其是，基於高速乙太網路TSN之控制的那一個，其中酬載通常受限於一百個位元組。
在此一組態中，最小MAC層乙太網路額外負擔由以下各項所構成：- MAC目的地位址(6個位元組)，- MAC來源位址(6個位元組)，- VLAN標籤(4個位元組)，- 乙太網路類型(2個位元組)，向OPC UA訊息新增另外18個位元組。
本發明旨在改善這種情況。為達此目的，本方法旨在一種用於在具有通訊模式之網路中傳送訊息之方法，該通訊模式涉及該網路上之發布者裝置及訂戶裝置，該方法包含：- 提取所接收訊息之酬載，並在同一組合式訊息內串連該等酬載，- 向該組合式訊息新增標頭，該標頭包含發布者裝置之單一識別符，該發布者識別符係被預定，以便將該組合式訊息指定給至少一個經選擇的訂戶裝置。
此一實作態樣之實施例在下面所論之圖14中示出，其特別展示上述組合式訊息之結構(具有一個標頭，但有大量串連酬載來自各別裝置)。這種實作態樣可能，除其他外，減少普通控制器裝置之額外負擔。
一般而言，在一具體實施例中，前述所選訂戶裝置可以是該 控制器裝置。控制器裝置控制網路中發行前述所接收訊息之裝置。
尤其是，可基於相對於控制器裝置及/或發行裝置之準則，來選取這些網路裝置中用以實施該方法之一個網路裝置。更特別的是，如上所述之方法可藉由這些發行裝置之一、或藉由連接至這些發行裝置並與其控制器裝置有關之一個裝置來實施。
一般而言，前述準則可至少包含網路之當前拓樸型態(要予以列入考量，以便在一方面發行裝置與另一方面其控制器裝置之間指定最適之中間裝置，用以進行以上方法)。
在一具體實施例中，所接收訊息具有附同一發布者識別符之標頭(圖14上之PublisherId=k)，而所接收訊息係由複數個相異發布者裝置發行。進行該方法之裝置可接著識別這些訊息，並予以收集在一個單一組合式訊息中，如圖14所示。
各所接收訊息可包括與發行該所接收訊息之裝置有關之識別符(其可以是另一識別符，有別於普通PublisherId，以及例如所謂的「WriterGroupId」(在圖14中=1,2,3…)，其可定義這些訊息之接收順序)。此外，在該具體實施例中，此發行器識別符在前述酬載串連中定義所接收訊息之酬載之順序。這些識別符已從標準規範「開放平台通訊統一架構」得知。
更普遍來說，在一具體實施例中，網路係係根據「開放平台通訊統一架構」類型之標準來操作，涉及該方法之裝置係透過該網路來連線，並且發布者裝置之前述單一識別符係PublisherID識別符。
更特別的是，網路可根據「時間敏感網路連結」類型之標準 來進一步操作。
一般而言，如上述，該發行器識別符之類型可以是WriterGroupID，其定義PublishingOffset之時序，並藉此定義該所接收訊息之該酬載在該酬載串連中之順序。
此外，如圖14所示，可從以同一預定週期持續時間所接收之訊息提取串連之酬載。一般而言，在圖15所示之具體實施例中，此週期持續時間可對應於多工器裝置之PublishingInterval。
本發明亦旨在經選擇而充當多工器裝置、且經組配而實施上述方法之網路裝置。此裝置可根據諸如當前拓樸型態(例如，其相對於其它裝置在網路中之中心性)之準則來選擇，及/或亦如下文所述，根據裝置之各別特定功能來選擇。
本發明亦旨在一種系統，其包含發行訊息之網路裝置、以及用以接收該等訊息之多工器裝置，並且係組配成用來實施如上述之方法。
本發明亦旨在此一系統之控制器裝置，並且係組配成：- 用來接收附有該預定發布者識別符之該組合式訊息，並且- 用來解譯該酬載串連。
本發明亦旨在一種包含指令之電腦程式，該等指令在由網路裝置之處理器執行時，令該網路裝置實施如上述之方法。其亦旨在一種儲存此類指令之非暫時性電腦儲存媒體。
由於在網路之裝置(例如通常是控制器裝置)處收到包含如上述之組合式訊息結構的信號會令此裝置以特定方式解譯該信號，因此，本發明亦旨在此一信號。此信號通常包含在具有通訊模式之網路中發布之 訊息之資料，該通訊模式涉及該網路之發布者裝置及訂戶裝置，其中該信號包含：- 包括發布者裝置之單一識別符的標頭之資料，以及- 由該網路之各別裝置發起之複數個串連酬載之資料。
下文將參照附圖介紹本發明之可能具體實施例之更多詳細內容及優點。
S1~S7:步驟
圖1展示經典之發布/訂閱方案。
圖2展示DataSets及DataSetMessages。
圖3展示PubSub訊息層及包封。
圖4展示PubSub實體及交換之訊息。
圖5展示一般UADP NetworkMessage格式。
圖6展示NetworkMessage酬載詳細內容及DataSetMessage標頭格式。
圖7展示在沒有安全性之情況下，用於循環PubSub通訊之緊密NetworkMessage格式。
圖8a展示在僅有簽署之情況下，用於循環PubSub通訊之緊密NetworkMessage格式。
圖8b展示在僅有簽署之情況下，用於循環PubSub通訊之緊密NetworkMessage格式。
圖9展示沒有安全性之固定式緊密訊息布局。
圖10展示具有安全性(僅簽署)之固定式緊密訊息布局。
圖11根據具體實施例之一實施例，繪示用於工業控制之網路拓樸型態、以及特定拓樸型態(圖11之下部)在實施本發明方面之使用。
圖12根據先前技術，展示朝向控制器裝置PLC之獨立NetworkMessages。
圖13根據本發明，展示組合式NetworkMessage。
圖14繪示多工器操作。
圖15在具體實施例之一實施例中繪示用於最小多工處理潛時之NetworkMessages排程。
圖16示意性展示具有數個裝置之系統，並且在這項實施例中，還展示網路中之數個控制器。
圖17展示對應表，其係根據網路之拓樸型態及/或根據網路中裝置之功能來建置，並且為連結至特定控制器之各裝置群組定義可能之多工器裝置，該特定控制器被定義為該群組之裝置所發布之訊息的訂戶。
圖18展示根據本發明的方法之可能步驟(可能代表根據本發明的電腦程式之一般演算法)。
圖19展示表格，該表格匯總在沒有安全性之PubSub NetworkMessage中可能找到的不同標頭所引起之額外負擔。
圖20展示表格，該表格匯總當使用緊密UADP布局傳送循環資料時，在沒有安全性之PubSub NetworkMessage中可能找到的不同標頭所引起之額外負擔。
本發明提出藉由將由一組裝置(通常是網路中作為通訊裝置之感測器及/或致動器)發送之獨立NetworkMessages組合為單一NetworkMessage，來減少PubSub通訊中之額外負擔。如下所示，多工器裝置(圖11-下部之參考多工器)可實施如下：- 使用裝置之PubSub發布功能之適應組態，- 實施PubSub多工處理功能，該多工處理可能取決於不少，其一是網路拓樸型態中之位置，- 實施NetworkMessage排程功能。
這種實作態樣允許將最初由一組裝置產生之若干NetworkMessages組合成要由訂戶接收之單一NetworkMessage。在一具體實施例中，訂戶可以是單一實體，並且較佳為控制器裝置，諸如所謂的「可程式化邏輯控制器」(以下稱為PLC)，其在本地控制網路拓樸型態中之一組裝置(感測器及/或致動器)(透過如圖11所示之PLC連結來控制)。
圖11展示可在工業生產線中或在機器內找到之控制拓樸型態之典型具體實施例，其中PLC(可程式化邏輯控制器)控制一組裝置(感測器及/或致動器)。控制器與裝置之間的資訊及命令係循環交換，並且各裝置通常處置短資訊資料(例如16位元命令、8位元計數值等)。
在先前技術解決方案中，當使用OPC UA PubSub通訊時，一簡易組態可使各裝置均包括發布者及/或訂戶。在此一映射中，發布者包括產生NetworkMessages之WriterGroup，NetworkMessages含有要由裝 置發送之DataSetMessages。各裝置接著傳送其自有獨立NetworkMessages，從而在PLC連結上產生一連串訊息，如圖12所示。
可在各週期內定址的裝置之數量為以下之函數：- 週期之持續時間，- NetworkMessages之長度。
NetworkMessages之額外負擔，即乙太網路及PubSub額外負擔，之總量所佔據之鏈路容量部分具有兩種雙重效應：- 給定裝置數量的控制週期持續時間之限制，- 一個週期內受控裝置數量之限制。
在乙太網路TSN網路上實施OPC UA PubSub時，由於乙太網路訊框標頭所導致之額外負擔無法壓縮：MAC位址、VLAN標記及乙太類型都是TSN橋接處理對應串流所需要的。因此，僅減少PubSub額外負擔即允許克服上述先前技術限制。
如圖12及13之確實比較所示，單一網路訊息：- 蒐集不同裝置之酬載，並具有- 用於識別一個單一發布者之單一標頭，以及- 圖13之實施例中之單一乙太網路標頭，依據本發明並且如圖13所示，造成有可能限制上述額外負擔。
在此單一網路訊息之讀者之另一側，PLC之訂戶實體之ReaderGroup係組配成用來適當地解譯及解多工處理在此單一NetworkMessage中接收之DataSetMessages，如以下在本說明書中所介紹。
關於裝置發布者組態，在一具體實施例中，與NetworkMessage標頭有關之組態係使得：必需組合NetworkMessages的所有裝置都被視為形成一分散式發布者，並且組配成具有相同PublisherId。
與Group Header有關之組態係使得：各裝置均以特定WriterGroupId發送其NetworkMessages，WriterGroupId識別發布者內之裝置。
在給定之Writer Group在每個PublishingInterval或週期僅發送一個NetworkMessage之限制條件下，可忽略NetworkMessageNumber。如果Writer Group在每個PublishingInterval發送數個NetworkMessages，他們係以一致的NetworkMessageNumbers而背對背發送。
在WriterGroup傳送各NetworkMessage時，SequenceNumber便會單調(monotically)增加。
與NetworkMessages酬載有關之組態使得酬載之布局得以保持，如OPC UA第14部分附錄C中所述：預定之一連串固定格式DataSetMessages。
DataSetMessage內之個別DataSet欄位保持不變。
可保留各DataSetMessages中之DataSet欄位的其中之一，以供插入對整個DataSetMessage運算出之完整性檢查碼。然後，可由目的地訂戶實體中之DataSetReader將此完整性代碼(例如CRC-16)用於檢查DataSetMessage之有效性。
此時在下文說明多工處理功能。
PubSub多工器可透過其網路輸入接收乙太網路包封之NetworkMessages，並透過其網路輸出發送組合式乙太網路包封之NetworkMessage。PubSub多工器至少有兩個輸入及單一輸出，如圖11之下部所示。
當整合於裝置中時，多工器之至少一個輸入接收原始NetworkMessages，即未包封在乙太網路訊框中，由與多工器共處一地(共置)之應用程式所產生。
如圖14所示，多工器依賴數種資料結構及變數以進行NetworkMessages組合：˙與各PublisherId相關聯之酬載傳送緩衝區(PLTxBuf)，亦即，與各Publisher相關聯，來自各Publisher之所接收的NetworkMessages將予以組合，˙與各WriterGroup相關聯之酬載偏移量(PLOffset)，WriterGroup包含在Publisher中，來自Publisher之所接收的NetworkMessages將予以組合。
PLTxBufk與Publisher k相關聯。
PLOffsetk i與WriterGroup i(WriterGroupId=i)相關聯，係包括在Publisher k(PublisherId=k)中，PLOffsetk i指出偏移量，參考PLTxBufk之基數，其中，以PublisherId=k及WriterGroupId=i接收之NetworkMessage之酬載(DataSetMessages)被儲存。
多工器所產生之NetworkMessages包括以下資訊：
˙在NetworkMessage標頭中：PublisherId=k
˙在群組標頭中：
○WriterGroupId=mux，其中mux係與多工器相關聯之值
○GroupVersion=與多工器實體相關聯之值，由組態固定
○NetworkMessageNumber=1：假設每個PublishingInterval不超過一個Networkmessage係產生自NetworkMessages的組合
○SequenceNumber=每次產生新的In NetworkMessage時，藉由多工器之NetworkMessage產生功能遞增之值。
組合式NetworkMessage中之酬載布局，尤其是DataSetMessages之順序，係由多工器組態定義。
較佳組態在於將DataSetMessages與特定WriterGroup保持相關聯，按照其最初在內送NetworkMessages中之順序進行分組，以免多工器進行額外之重新排序。
圖15中展示NetworkMessages排程。一般而言，有可能利用裝置及多工器共用之PublishingInterval來減少NetworkMessages組合操作之潛時。這可藉由為裝置中所包括之各WriterGroup組配適當之PublishingOffset來實現。的確提醒將PubSub層級時序參數(PublishingInterval及PublishingOffset)映射到TSN時序參數上主要是藉由使用IEEE 802.1Qbv所提供之排程方案來完成，其允許定義傳輸週期以及這些週期內之傳輸次數，即傳輸偏移量。傳輸之循環時序從而可藉由此類偏移標準限制條件來定義。
如圖15所示(圖中未將網路或內部傳播延遲所造成之可能 潛時列入考量)，可組配裝置WriterGroups之PublishingOffsets，以便提供多工器進行NetworkMessages組合所需之最小餘量，從而保證最小之多工處理潛時。
現請參閱圖16，可將複數個裝置DEVi、DEVj、…連結至控制器PLC-A，使得當裝置DEVi、DEVj、…係發布者時，PLC-A係訂戶。其它控制器(PLC-B等)可能在網路中，並且可連結至其它發布者裝置DEVk、DEVl等。當然，裝置DEVi、DEVj、…中之一個或數個裝置可以是第二控制器PLC-B之發布者，反過來，DEVk、DEVl等中之一個或數個裝置可以是控制器PLC-A之發布者。
網路之至少一個節點可充當多工器，用以處理由裝置DEVi、DEVj等傳送之PubSub訊息。一般而言(但非強制性)，多工器可以是DEVi、DEVj等中之裝置，可根據網路之拓樸型態、及/或根據節點之相應功能等來選擇。任選的是，可選擇數個多工器以分別處理一方面由裝置DEVi、…、DEVm發送之訊息、及另一方面由裝置DEVm+1、…、DEVj發送之訊息。在這裡，第三多工器可處理從裝置DEVi、…、DEVm、及DEVm+1、…、DEVj兩群組所接收之PubSub訊息，以為了共用控制器PLC-A將該等訊息組合。
因此，可將網路之至少一些節點編程為具有多工處理功能，以便將不同PubSub訊息組合成單一訊息，新增不同酬載(DataSetMessages)，但保持單一標頭，如圖13及14所示。一般而言，在圖14之實施例中，多工處理訊息之節點實體係裝置m，編程為附有此一多工處理功能。可對其它裝置1、2、…、n進行編程以隨著相同發布者識別 符PublisherID=k來發布其訊息，k可與m相等或不同。當裝置m在PublisherID=k下接收已發布訊息時，裝置m係經編程以將該等訊息組合，更具體地說，依照取決於各訊息標頭中所示WriterGroupID之順序將其酬載串連，以便遵守其各自PublishingOffset，如以上參照圖15所闡釋。在另一具體實施例中，圖14之發布者裝置1、2、…、n可經編程以隨著其自有PublisherID(1、2、…、n)發布其訊息，並且多工處理裝置m可經編程以識別這些識別符PublisherID(1、2、…、n)，以便組合接收自對應裝置1、2、…、n之訊息。
請再次參閱圖16，各裝置典型可包含一通訊介面COMD，其連接至與記憶體MEMD相配合之處理器PROCD，記憶體MEMD儲存諸如其發布者識別符PublisherID等WriterGroup之資料、以及電腦程式之指令，用以建置並發送附有酬載及標頭之NetworkMessages，該標頭，除其他外，包含此類識別符。在PublisherID要以多工處理裝置PublisherIDI更換之一些具體實施例中，電腦程式可施用此一功能。更特別的是，如果指定這些裝置之一充當多工處理裝置(例如，以網路之拓樸型態為依據)，則可憑藉此一多工處理功能來增強電腦程式(儲存在此裝置之記憶體MEMD中)。
此外，各控制器PLC亦可包含通訊介面COMC，通訊介面COMC係連線至與記憶體MEMC相配合之處理器PROCC，記憶體MEMC特別儲存電腦程式之指令，用以解譯由多工器裝置發布之組合式訊息(及其組合式酬載)。
現請參閱圖17，對應表可，除其他外，根據網路拓樸型態及 /或網路中之裝置功能來定義(例如，藉由網路排程器來定義)。因此，表格可為各控制器PLC-A、PLC-B等定義：- 對於此控制器可以是發布者裝置之裝置(分別是DEVi、DEVj等；DEVk、DEVl等)，- 以及用以將此類發布者裝置所發布之訊息組合之多工器裝置(DEVm1；DEVm2)。
控制器PLC-A、PLC-B等用以接收數則訊息並解譯其標頭之額外負擔因此可在多工器DEVm1、DEVm2上予以逐出，以便僅在控制器側處理單一訊息中所接收之酬載。
此外，各控制器可處理更多訊息，然後在一個週期內控制更多裝置，或對於相同數量之要傳送資料(或最終對於相同數量之要控制裝置)，控制週期可更短。
現請參閱圖18，因此，第一步驟S1可包括(例如在網路排程器側)定義如先前參照圖17所介紹之對應表。在一具體實施例中，可在步驟S2將此表格之指令至少發送至各多工器裝置，各多工器裝置至少儲存：- 多工器裝置m及對應控制器PLC-A與之連結之群組之PublisherID=k，並且- 任何未來組合式NetworkMessage之標頭均應包括之WriterGroupID=m。
於此步驟S2，亦可將PublisherID=k發送至裝置DEV1、DEV2等，以便在訊息要以PLC-A作為訂戶發布時加以使用。控制器PLC- A亦可儲存PublisherID=k，以便在隨著此一PublisherID予以接收時將組合式訊息列入考量。
在本具體實施例中，於步驟S3，多工器裝置MUX接收由裝置DEV1、DEV2、DEV3等所發布之訊息，且係隨著PublisherID=k(使多工器裝置將其列入考量)、以及其自有WriterGroupID=1、3、2等接收。基於這些相應識別符WriterGroupID=1、3、2，多工器裝置係組配成用來管理這些訊息之酬載之順序，在步驟S4中附有對應之偏移量，並且有可能用以重新排列該順序(酬載之順序變為例如#1、然後#2、然後#3)。
可進行從群組(PublisherID=k)接收訊息並組合其酬載之步驟S3及S4，直到一個週期在步驟S5中結束為止。較佳的是，只要從裝置DEV1、DEV2及DEV3接收訊息，便將酬載組合，而且實施酬載組合不需要等待週期結束。該週期之持續時間可由多工器裝置之PublishingInterval定義，如圖15所示。PublishingOffset定義相對於週期開頭之時間，可於該週期開頭傳送NetworkMessage。為此，PublishingInterval及PublishingOffset可以是要由多工器裝置於步驟S2儲存之其它資料。
在週期結束之前(起自測試S5中之箭頭KO)，多工器可傳送串連之NetworkMessage，串連之NetworkMessage包含從裝置DEV1、DEV2、DEV3接續接收之訊息之接續酬載，係以該順序排列，並且多工器至少向其新增：- 群組(=k)之PublisherID，以使得控制器PLC-A會將按該順序排列之這些酬載之組合產生之訊息列入考量， - 其自有WriterGroupID(=m)，以使得任何其它多工器或控制器均可使用其由WriterGroupID=m給予之偏移量，需要在數個組合式訊息中仲裁優先順序。
的確提醒此資訊WriterGroupID的確有可能以一般方式管理PubSub訊息之發布偏移量。
最終，於步驟S7中，多工器裝置隨著此標頭發布新組合式訊息，以便由控制器PLC-A視為訂戶。
起自測試S5之箭頭OK對應於目前週期結束時之情況，並且對於新週期之開頭，多工器裝置等待從裝置DEV1、DEV2、DEV3、或可能從其它裝置接收新訊息。
因此，似乎本發明利用IEEE 802.1 TSN及OPC UA第14部分(PubSub)標準中規定之不同機制，並且其實作態樣不需要任何進一步標準化。
由於這種最佳化允許改善OPC UA Pub通訊效能，因此當然可有助益地將本發明施用於基於OPC UA PubSub之控制系統，從而提供高效能(短控制環)基於OPC UA PubSub之工廠自動化產品。然而，可使用相同種類之資訊組織將相同原理施用於其它通訊協定。
S1~S7:步驟

Claims (14)

  1. 一種用於在具有通訊模式之網路中傳送訊息之方法，該通訊模式涉及該網路上之發布者裝置及訂戶裝置，該方法包含：- 提取所接收訊息之酬載，並在同一組合式訊息內串連該等酬載，- 向該組合式訊息新增標頭，該標頭包含發布者裝置之單一識別符，該發布者識別符係被預定，以便將該組合式訊息指定給至少一個經選擇的訂戶裝置，其中該等所接收訊息具有標頭，該標頭附有同一發布者識別符，該等所接收訊息係由複數個相異發布者裝置所發行。
  2. 如請求項1所述之方法，其中，該經選擇的訂戶裝置為發行該等所接收訊息之網路裝置之控制器裝置。
  3. 如請求項2所述之方法，其中，以相對於該控制器裝置及/或發行該等所接收訊息之裝置之準則為基礎，選取該等網路裝置中之裝置以實施該方法。
  4. 如請求項3所述之方法，其中，該準則至少包含該網路之當前拓樸型態。
  5. 如請求項1至4中任一項所述之方法，其中，各所接收訊息包括與發行該所接收訊息之裝置有關之發行器識別符，該發行器識別符定義該所接收訊息之該酬載在該等酬載之串連中的順序。
  6. 如請求項1至4中任一項所述之方法，其中，該網路係根據「開放平台通訊統一架構」類型之標準來操作，並且其中，發布者裝置之該單一識別符係PublisherID識別符。
  7. 如請求項6所述之方法，其中，該網路係進一步根據「時間敏感網路連結」類型之標準來操作。
  8. 如請求項6所述之方法，其中，各所接收訊息包括與發行該所接收訊息之裝置有關之發行器識別符，該發行器識別符定義該所接收訊息之該酬載在該等酬載之串連中的順序，以及其中，該發行器識別符係WriterGroupID，其定義PublishingOffset之時序，並藉此定義該所接收訊息之該酬載在該酬載串連中之順序。
  9. 如請求項1所述之方法，其中，該等串連之酬載係提取自同一預定週期持續時間(PublishingInterval)內所接收之訊息。
  10. 一種網路裝置，其係經選取以充當多工器裝置，並且係組配成用來實施如請求項1至9中任一項所述之方法。
  11. 一種通訊系統，其包含發行訊息之網路裝置、以及用以接收該等訊息之多工器裝置，並且該多工器裝置係組配成用來實施如請求項1至9中任一項所述之方法。
  12. 一種控制器裝置，係控制如請求項11所述之通訊系統，且其係組配成用來接收該組合式訊息，並且用來解譯該等酬載之串連，其中該組合式訊息附有該預定發布者識別符。
  13. 一種包含指令之電腦程式，該等指令在由網路裝置之處理器(PROCC；PROCD)執行時，令該網路裝置實施如請求項1至9中任一項所述之方法。
  14. 一種資料結構，其係在實施如請求項1至9中任一項所述 之方法時所使用者，該資料結構包含在具有通訊模式之網路中發布之訊息之資料，該通訊模式涉及該網路之發布者裝置及訂戶裝置，其中，該資料結構包含：- 包括發布者裝置之單一識別符的標頭之資料，以及- 由該網路之各別裝置發起之複數個串連酬載之資料。
TW110119603A 2020-06-10 2021-05-31 用於在網路中發送訊息之方法、裝置、系統、電腦程式及資料結構 TWI812958B (zh)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
EP20305628.8A EP3923516B1 (en) 2020-06-10 2020-06-10 Message exchanges in "open platform communications unified architecture"
EP20305628.8 2020-06-10
WOPCT/JP2021/009697 2021-03-04
PCT/JP2021/009697 WO2021250960A1 (en) 2020-06-10 2021-03-04 Method, device and system for transmitting message in network

Publications (2)

Publication Number Publication Date
TW202147811A TW202147811A (zh) 2021-12-16
TWI812958B true TWI812958B (zh) 2023-08-21

Family

ID=71579529

Family Applications (1)

Application Number Title Priority Date Filing Date
TW110119603A TWI812958B (zh) 2020-06-10 2021-05-31 用於在網路中發送訊息之方法、裝置、系統、電腦程式及資料結構

Country Status (7)

Country Link
US (1) US20230231732A1 (zh)
EP (1) EP3923516B1 (zh)
JP (1) JP7442692B2 (zh)
KR (1) KR20230003576A (zh)
CN (1) CN115699684A (zh)
TW (1) TWI812958B (zh)
WO (1) WO2021250960A1 (zh)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060133372A1 (en) * 2004-10-29 2006-06-22 Samsung Electronics Co., Ltd. Apparatus and method for multiplexing packet in mobile communication network
US20100214978A1 (en) * 2009-02-24 2010-08-26 Fujitsu Limited System and Method for Reducing Overhead in a Wireless Network
CN110943853A (zh) * 2018-09-21 2020-03-31 罗伯特·博世有限公司 传输方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7489688B2 (en) 2003-12-23 2009-02-10 Agere Systems Inc. Frame aggregation
US9407585B1 (en) 2015-08-07 2016-08-02 Machine Zone, Inc. Scalable, real-time messaging system
JP6265182B2 (ja) 2015-08-20 2018-01-24 横河電機株式会社 無線中継機器、処理装置、無線通信システム、及び無線通信方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060133372A1 (en) * 2004-10-29 2006-06-22 Samsung Electronics Co., Ltd. Apparatus and method for multiplexing packet in mobile communication network
US20100214978A1 (en) * 2009-02-24 2010-08-26 Fujitsu Limited System and Method for Reducing Overhead in a Wireless Network
CN110943853A (zh) * 2018-09-21 2020-03-31 罗伯特·博世有限公司 传输方法

Also Published As

Publication number Publication date
CN115699684A (zh) 2023-02-03
JP7442692B2 (ja) 2024-03-04
EP3923516B1 (en) 2024-02-28
KR20230003576A (ko) 2023-01-06
US20230231732A1 (en) 2023-07-20
WO2021250960A1 (en) 2021-12-16
EP3923516A1 (en) 2021-12-15
JP2023515911A (ja) 2023-04-14
TW202147811A (zh) 2021-12-16

Similar Documents

Publication Publication Date Title
CN110943899B (zh) 一种epa工业总线与时间敏感网络适配系统及方法
CN104170291B (zh) 用于处理精确时间协议的方法和网络节点
JP7289332B2 (ja) 電子制御ユニット、フレーム生成方法及びプログラム
US7441048B2 (en) Communications system and method for synchronizing a communications cycle
Lim et al. Performance analysis of the IEEE 802.1 ethernet audio/video bridging standard
US20130070788A1 (en) Method and Apparatus for Interchanging Data, and Network
Silva et al. On the adequacy of SDN and TSN for Industry 4.0
JP7330395B2 (ja) ゲートウェイデバイスを通じて１次ネットワークドメインを２次ネットワークドメインと相互接続する方法、プログラム、媒体、およびデバイス
CN111585862A (zh) 一种EtherCAT与TSN网络互通的实现方法及装置
Yang et al. TC-Flow: Chain flow scheduling for advanced industrial applications in time-sensitive networks
TWI756666B (zh) 在封包交換網路中藉由通訊實體之電腦手段實施之方法、及其電腦程式及電腦可讀取之非暫時性記錄媒體、以及封包交換網路之通訊實體
CN113196710B (zh) 分发节点、自动化网络和用于传输报文的方法
US7853706B2 (en) Method, interface and network for cyclical sending of Ethernet telegrams
TWI812958B (zh) 用於在網路中發送訊息之方法、裝置、系統、電腦程式及資料結構
Hummen et al. Tsn–time sensitive networking
Wang et al. Time-sensitive networking for industrial automation: Challenges, opportunities, and directions
US20210258264A1 (en) Interface apparatus between tsn-devices and non-tsn-devices
US20050286450A1 (en) Deterministic communication system
Goller Looking Inside Real-Time Ethernet
Park et al. Design of an integrated fieldbus gateway
US20240179065A1 (en) Network Device, Time-Sensitive Network System and Auto-configuration Method Thereof
Cena et al. Efficient polling of devices in CANopen networks
Steiner et al. IEEE 802.1 Audio/Video Bridging and Time-Sensitive Networking
Ojewale On Preemption in Time-Sensitive Networking (TSN)
Cena et al. New efficient communication services for ISO 11898 networks