IEC61499 與OPC UA

          第四次工業革命的一個關鍵點就是将工廠中的房間裡的所有東西都數字化，它們包括生産過程，裝置和部件數字化，增加它們的互操作性。為了達到數字化，需要努力建立一系列标準來建立統一的接口，實作異構的項目透明地通信。通過這種标準化技術，傳統的實體裝置和數字技術互相的融合。建構所謂的資訊實體系統（ Cyber-Physical  System），将這些CPS 連接配接到網絡中。在這個概念下，一個電機，泵，閥門或者一台CNC 機床都是一個CPS。在資訊系統中，CPS 可以看作為實體裝置的數字孿生（digital twin）。CPS 是計算機科學，資訊技術和通信技術發展的産物。而CPPS 稱為資訊實體生産系統，它代表了CPS 進一步融入制造業科學和技術。比如工藝，控制流程等技術訣竅。制造領域數字化的目标就是将工廠中的房間中的是以東西都改造成為CPPS。

     下面是工業4.0 的元件模型（The Industrie 4.0 Component model）。這個元件模型指定每個資産（邏輯的或者實體）封裝在一個标準化的數字容器中-管理殼（Adminsitration Shell）。它能夠實作所有I4.0 元件之間的描述，協同操作和通信。

CPPS 中涉及的計算機和通信技術非常多，基本的數字化目标有兩項：

    協同操作   

       各個CPPS能夠通過網絡實作協同操作是實作工業4.0 的理想，人們甚至提出了“即插即生産”的概念，不同廠商的軟體，裝置通過網絡協定能夠實作互相操作。顯然，需要有一個統一的協定标準，而且這個協定将是語義網協定。也就是說，既要聽的見，還要聽的懂。 OPC UA 協定就是為此設計的。OPC UA 已經成為工業4.0 RAM I4.0 模闆通信協定事實标準(de facto Standard). 

    作業流/制程控制

          如果一個實體資産（asset）不需要可程式設計控制，比如一個傳感器，或者一個閥門。那麼CPPS 中隻要有OPC UA 伺服器就足夠了。但是如果控制裝置中包含了作業流/制程控制（Work flow / recipe control)。就需要一種高效率的編排工具。 IEC61499 是分布式工業控制的模型，它提出了基于事件功能塊編排應用程式的方法。可以作為調用資産中各種軟體部件的工具。

    将OPC UA 和IEC61499 标準融入CPPS 模型中。可以建立可程式設計自動化控制器（PAC）的CPPS架構。如下圖所示：

I

 OPC UA 和IEC61499 成為了兩個工業4.0 的重要标準，我們就來探讨基于OPC UA 和IEC61499 标準的PAC的架構以及實作過程中需要考慮的問題。

OPC UA

     網絡和各種論壇上讨論OPC UA的人也也來越多了起來。幾年内前，我寫了一篇關于OPC UA 的博文《OPC UA的本質》，從面向對象的概念出發，介紹OPC UA 的基本概念和邏輯。雖然比較粗糙，但是卻是我所有博文中獲得點贊最多的一篇。這樣充分說明，OPC UA 技術已經開始普及。關心它的人也越來越多。

     OPC UA 是建立數字化模型的工具。可以實作裝置，軟體元件和服務的統一的數字化呈現。對照傳統的網絡OSI 七層模型，它應該是表示層協定，而且它是一個語義網協定。OPC UA描述語義的方式采取了面向對象程式設計的思想。OPC UA 資訊模型是節點的網絡（Network of Node,），或者稱為結構化圖（graph），由節點(node)和引用(References)組成，這種結構圖稱之為OPC UA 的位址空間。這種圖形結構可以描述各種各樣的結構化資訊(對象)。

​​節點(nodes) : 共計有8種節點(對象,對象類型,變量,變量類型,視圖,方法,引用,資料類型)。節點之間的互相引用建構成為Node 網絡圖。

在OPC UA 能夠廣泛地應用之前，需要建立各個行業統一的OPC UA 模型。比如建立泵，閥門，CNC機床，注塑機等等實體裝置的OPC UA 模型。這不僅需要研究部門，自動控制化廠商和标準化組織的努力，更需要其它行業達成共識。

           推動OPC UA 升溫的一個原因是大型自動控制系統廠商的軟體開始支援OPC UA 了（比如西門子的WinCC）。如果第三方研發的裝置具有了OPC UA 伺服器功能，就可以順暢地接入由這些大型的軟體建構的系統之中。畢竟小型裝置廠商自行開發大型的上位機軟體是困難的。當然，從更高的站位思考的問題，由于OPC UA 是一個開放的，與廠商無關的國際标準。我們有機會借此擺脫傳統大廠的壟斷，開發自主可控的工業自動化系統，軟體和裝置。當然，這需要我們足夠努力，并且達成共識。

 IEC61499

        控制裝置中普遍采用PLC 的梯形圖，後來發展成為IEC61131-3 程式設計方式。它們是一種基于周期執行方式的程式設計方式。這種程式設計方式已經移植到工業PC上，實作所謂的軟體PLC。當大資料，人工智能，資料分析，雲計算等技術開始引入工業領域時，人們發現PLC 的計算能力是有限的。IEC61131-3也同樣具有很大的局限性。    

             IEC61499 支援基于模型地開發分布式工業測量，控制與監督系統。它的最大特點是基于事件的功能塊。應用程式是一個由功能塊執行個體通過連結構成的功能塊網絡。通過遠端部署的方式将應用分段部署到分布式裝置中運作。實作總體設計，分布式部署營運。IEC16499 基于事件的功能塊網絡的概念更加展現了面向對象的程式設計思想。事件的産生與傳遞類似與面向對象程式設計中類執行個體的調用關系。從概念上講，IEC61499 是一種面向分布式工業控制系統的模組化工具，但是它本質上是通過為分布式控制系統模組化，實作控制政策，算法，軟體元件等資源的形式化應用。OT 工程師最終是使用它來建立功能塊網絡圖。盡管在IEC61499 中沒有稱之為“程式program”，而叫做“應用Application”。是以，我仍然覺得IEC61499 标準提供了一種基于模型的分布式工業自動控制系統程式設計方式。

IEC61499 與OPC UA相結合

     OPC UA 是一個統一架構的資訊模型，而IEC61499 是建構分布式工業控制系統的模型。OPC UA 用于不同裝置和軟體元件之間的資訊交換，而IEC61499 用于建立分布式控制系統的應用。前者更适合通信，而後者更适合建立應用。由此看來，它們的關注點有所不同。如果将OPC UA 和IEC61499 兩大标準的技術相結合，可以建構成為工業4.0 中的所謂資訊實體生産系統（Cyber-Physical Production System）的模型。

   我們來讨論如何在IEC61499 可程式設計自動化控制器中融合OPC UA 。首先，我們以著名的IEC61499 開源項目4diac和施耐德公司最近釋出的EcoStruxure開放自動化平台  為例，介紹目前這兩種技術融合的方式。然後再讨論如何進一步地融合這兩項重要的技術。

 4idac 項目中的OPC UA  

         4diac 項目中實作OPC UA 的方式比較直接，IEC61499運作時IForte 内部采用了開源open62541 OPC UA 協定棧，通過現有的通信服務接口功能塊來實作OPC UA 的伺服器和用戶端的實作。 它們包括了Publish/Subscribe,Server/Client 功能塊。

     與實作諸如MQTT，HTTP等其它通信協定類似， 4diac 采用通信功能塊的ID 參數（ID  資料輸入）來指定與OPC UA 軟體子產品的操作，它分為兩部分（遠端操作為三部分）由逗号區分：

opc_ua[ACTION;ENDPOINT;PAIR1;PAIR2;...]

ACTION

ACTION 指定OPC UA 的操作， 包括：

1. READ
2. WRITE
3. CREATE_METHOD
4. CALL_METHOD
5. SUBSCRIBE
6. CREATE_OBJECT
7. DELETE_OBJECT
8. CREATE_VARIABLE
9. DELETE_VARIABLE

ENDPOINT

     ENDPOINT 限于opc ua Client模式，指定了 遠端OPC UA 伺服器的IP 位址，使用# 結束。

例如：

 opc.tcp://192.168.0.100:4840#

PAIR

指定節點的名稱和資料類型。

格式為：BROWSENAME,NODE_ID

 4diac 完全是依靠 通信功能塊的ID 來操作opc ua的 。它的缺點是ID格式複雜，容易搞錯。如果OPCUA 模型比較複雜，功能塊應用中通信服務接口功能塊會比較多，而且容易造成某些混亂。

下面是4diac 中使用opc ua的一些例子:

使用變量的Flip-Flop 應用

使用變量的加應用

通過OPC UA 方法調用IEC 61499 功能塊子程式

  下面是一個加法的例子，在應用中分别使用了OPC UA 的伺服器和用戶端。

由此可見，4diac 中的forte 實作OPC UA 還是十分簡單的做法，不過，如果要實作複制的OPC UA 模型，功能塊網絡會比較複雜。

施耐德EAE中的OPC UA 伺服器

       施耐德公司最近推出了他們基于IEC61499 的EcoStruxure開放自動化平台     EcoStruxure™Automation Expert，簡稱 EAE 2.0）.實際上，這個平台基于了他們早年收購的nexControl 公司的技術。筆者有幸成為了這個系統的早期使用者。有關使用的細節，在我以前的博文中有描述，這裡就不再贅述。我們介紹一下EAE2.0 中實作OPC UA 的方法。

 EAE 的軟體運作時中包含了一個OPC UA server。我們可以按照下面的方式測試EAE 的OPC UA 伺服器。

     在 EAE 2.0 中，開發環境是支援HMI 的。EAE 通過添加CAT 的方式來實作HMI 。CAT 是nxtControl 的概念，也就是 Composite Automation Type（CAT）複合自動化類型。CAT 并不是IEC61499 的概念和術語。它其實是一個複合功能塊，内部包含了一個HMI的服務功能塊。EAE 就是使用CAT 及其執行個體來建構HMI 的。為什麼這麼做呢，我猜想HMI 設定和選擇的東西要比功能塊更多，如果單純使用功能塊來組态HMI 的化會比較麻煩，是以他們在IEC61499 标準外面，搞了一個CAT ，對HMI 複合功能塊做額外的組态。有開發環境自動地産生HMI 界面和相應的功能塊配置。這樣要簡單一些。

          在EAE 的運作時上有一個OPC UA 伺服器。當你使用EAE 2.0 開發環境時，裝置屬性中有一個OPC UA Stack Configuration。将OPC UA Stack Configuration 屬性有Default 改成OVERWRITE 後，可以看見OPC UA 的各項屬性。

     但是你會發現OPC UA 參數清單中空空如也，不知道如何将IEC61499 功能塊網絡的變量和OPC UA 模型中的變量關聯起來。後來才發現，隻有 CAT_HMI  功能塊的輸入和輸出資料才會在OPC UA 模型中作為變量出現。

       這充分表明，EAE 2.0的設計思想非常清楚，OPC UA 和HMI一樣，是對外呈現資訊的接口。和HMI 接口本質上是一緻的。是以這樣安排非常的合理。正是應為EAE 的OPC UA 是建立在HMI 功能塊參數之上，而且采用了具有更強組态能裡的CAT 方式。使EAE 的OPC UA 組态能力要比4diac更強一些。

進一步研究

      是否有更好的方式來融合OPC UA 和IEC 61499 兩項技術呢？我們要從現有IEC61499 運作時的不足談起。我們先來看看IEC61499 裝置運作時的通信架構談起

     IEC 61499 運作時通信架構

   IEC61499 運作時具有兩個基本的通信端口，一個是管理指令口，用于功能塊應用的下載下傳，管理和監控。它是IEC61499 開發環境和運作時之間的通信。另一個是不同裝置中功能塊之間的通信。IEC61499 運作時的内部架構如下圖所示。

事實上，控制器還需要其它的通信接口，比如通路上位機或者雲端系統的通信接口。是以，系統架構就變成為下面的樣子：

更合理的架構

   上面的這種結構并不是合理的方式，首先，現在的IEC61499 控制系統普遍是将IDE和系統的監控，部署結合在一起的。在實際的控制系統中，系統中會保留一個IDE 工作站，又有一個SCADA 工作站。為什麼不可以使用OPC UA 來管理和監控IEC61499 的應用呢？

OPC UA 成為統一的接口

          更進一步地，可以将跨裝置的功能塊通信也可以通過OPC UA 來實作。是OPC UA  成為真正統一的協定。這對于促進開發自動化系統的實作是十分重要的。就目前幾個基于IEC61499 的項目來看，雖然在功能塊定義，描述方面部分實作了開放。但是不同的項目之間依然存在鴻溝，比如IDE 和運作時之間的通信協定，跨裝置的功能塊通信協定。不同的系統互相是不相容的。4diac 使用的是TCP/IP 加ANS.1 編碼，而施耐德EAE 中使用的是加密的websocket 協定。這些協定不統一，不開放，開發自動化系統就是不完全。

     筆者認為，使用OPC UA 作為IEC61499 系統的統一标準是解決這些問題的好方法。采用OPC UA 作為統一接口的IEC61499 系統如下圖所示：

  在圖中，IEC61499 PAC 也能夠通過OPC UA Client 去通路具有OPC UA Server 的CPS，例如西門子的CNC機床，或者某個機械臂。畢竟，現在具有OPCUA接口的裝置越來越多了。

當然，全部采用OPC UA 協定的話，可能會增加裝置處理器的開銷，進而增加CPU 的負擔。

實作的考慮

在基于opc ua /iec61499 運作時的實作中，有許多問題值得探讨：

1  IEC61499運作時核心與OPC UA 伺服器之間的資訊互動方式

PAC 中建立一個opc ua 的守護線程，每當外部client 接入，就建立一個線程來實作互動。IEC61499 運作時核心通過線程之間的消息隊列實作RPC 調用實作互動。

2  建構更加清晰的OPC UA 功能塊庫

   本人比較喜歡4diac 項目的OPC UA 的實作方式，因為這樣做能夠使得OPC UA 獨立于HMI 軟體實作。但是，它将通信服務接口功能塊來直接操作UPC UA的方法使用起來比較麻煩，特别是ID 字元串容易寫錯。可讀性差。我們可以嘗試建構獨立的OPC UA 功能塊庫，是概念上更清晰一些，并且提高IEC61499 運作時與OPC UA 伺服器之間互動的效率。我們會在後續的博文中介紹這方面的工作。

結束語

      本文結合工業4.0 中的I40 元件模型和CPPS 架構，讨論了IEC61499 PAC 中結合OPC UA 的幾種方式。最後提出了OPC UA+IEC61499 的統一架構，并且讨論在IEC61499 runtime 中實作的方法。這隻是筆者的一些思考。供讀者共同讨論。