目錄
從PLC 歷史談起
PLC （可編程邏輯控制器）是美國汽車行業Bedford 協會的一位聰明的僱員Richard E. Morley在1968年發明的。起初的名稱爲模塊化數字控制器（Modular Digital Controller MODICON），在GE 公司的一個諮詢項目中，採用Programmable Logic Controller （PLC）的名稱，Bedford協會也更名爲Modicon PLC。成爲世界上第一個PLC 供應商。第一臺商業應用PLC 產品MODICON084。
Morley先生爲了使當時的技術人員和維修電工易於理解和編程PLC。採用了類似繼電器接線圖的，也就是梯形圖來爲PLC編程。這種方式一直延續到現在微處理器時代。自動控制工程師接受的培訓和工作經驗都是基於梯形圖編程方式。
目前PLC 已經成爲使用最爲廣泛的制動控制設備。在生產線控制，機牀設備，動車，地鐵中，PLC產品幾乎無處不在。
PLC 可編程邏輯控制器一直是中國自動控制廠商心中的梗。PLC領域長期以來都是歐，美，日企業把控的地盤。 在上個世紀80年代我曾經有機會在英國的Allen-Bradley公司學習PLC技術，回國後也曾極力地宣傳PLC 的重要性，但是並沒有被多少人認可，不久，無錫輕工系統的一家國企曾引進GE公司的PLC 產品（大散件組裝，實際上就是整機引進），而Allen-Bradley 公司在廈門設立了獨資公司。逐步在中國推廣PLC產品和技術。後來西門子，日本三菱等公司也相繼進入中國市場。之後的幾十年間，也有一些公司嘗試開發國產的PLC 產品，不過終究沒有成爲氣候。目前少數國內PLC 公司。他們的產品主要是面向“自主可控”的重點領域。在普通工業市場沒有競爭力。
從硬件上來看，PLC 並不是十分複雜的工業電腦。也沒有多少專用電路。開發上並沒有多少不可逾越的地方。問題主要出在軟件上。編程環境，可靠的嵌入式程序還是有難度的，成爲了PLC 產品的護城河之一。
事實上，在國外PLC 產品的軟件也大多數並不是硬件廠商開發，而是第三方軟件公司開發的。比較集中的是Taylor Software,和 ICOM。其它軟件公司不是被硬件設備公司收購了，就是倒閉了。後來Taylor Software,被Total Control Products收購，之後這家公司又被GE Fanuc收購，而施耐德公司購買了Taylor 的一部分軟件。
現在許多的PLC 廠商是購買的CoDeSys 公司的編程工具和嵌入式運行時程序（runtime）。 目前很多廠商的PLC控制器使用的都是Codesys系統，比如匯川技術的中型PLC，德國倍福的控制器，日本歐姆龍以及法國施耐德等等主流廠家也都有基於codesys平臺二次開發的控制器產品。
PLC標準化-IEC 61131-3
各家PLC廠商的編程環境和語言是相互不兼容的。也就是爲西門子PLC 編寫的程序無法再三菱PLC上運行。爲了解決這一困境。國際電工委員會IEC 於1982 年，發佈了IEC 61131-3 標準。致力於PLC 標準化工作。IEC 61131-3標準很重要，因爲它爲所有符合該標準的軟件產品帶來了一致性。無論集成開發環境（IDE）的品牌或用戶界面桌面的名稱如何，功能和功能塊看起來都一樣，並具有相同的定義的輸入和輸出，從而使工程師或維護人員能夠從任何製造商的軟件中快速瞭解邏輯和程序流程。
該標準定義了五種編程語言：
- 梯形圖LD
- 功能塊（FBD）
- 順序功能圖（SFC）
- 結構化文本（ST）
- 指令表 IL 類似於計算機的彙編指令
IEC 61131-3定義了標準數據類型，命名約定，程序流程和各種其他編程元素。當PLC OEM聲明其編程軟件符合IEC 61131-3時，通常意味着該軟件符合部分標準。IEC聲明，要符合要求，編程包必須至少支持五種語言中的一種。CoDeSys可能是唯一支持所有這五個平臺的編程平臺。
PLCOpen協會
人們意識到僅有一個標準是不夠的，還有許多的事情要做。於是成立了PLCOpen 協會。來推廣，論證和進一步規範IEC 61131-3標準。
PLCopen是一個獨立的全球組織，可根據用戶需求提供工業自動化效率。它成立於1992年，總部位於荷蘭，在美國，日本，中國和韓國設有支持辦事處。
前面提到，在IEC 61131-3中，除了傳統的梯形圖和指令表以外，提出了功能塊圖編程（FBD）方式。這是一種基於圖型的編程方式。
FBD 類似於硬件的電路圖，一個PLC 程序是由若干個功能塊用線連接起來的。功能塊都有一個或多個輸入和輸出。塊的功能是其輸入和輸出狀態之間的關係。下面是一個FBD的例子，是不是很像硬件的原理圖？
類似於原理圖，基本的功能塊相當於小規模集成電路。基礎的功能塊包括了
除了這些在 IEC 61131-3 標準中規範的核心功能塊以外，在PLC 中還有大量的功能塊。例如
- 算術功能塊
- 移位功能塊
- 字符串功能塊
- 轉換功能塊
- 通訊功能塊
還可以有許多許多，事實上用戶可以編寫自己的功能塊，它們可以使用梯形圖，結構化語言或者其它程序設計語言來實現。複雜功能塊提升了PLC 的能力，例如電機控制，PID和運動控制類的功能模塊。未來也許會有AI 功能塊。但是功能塊就像程序庫那樣。如何能保證不同廠商開發的功能塊相互兼容，是一個需要相互規範和協調的事情。PLCOpen 在功能塊設計等方面，提出了更進一步的規範。例如軟件構造指南，運動控制用戶指南和安全用戶指南等。
按照IEC 61131-3 標準編寫的PLC程序要最終在PLC中運行，需要通過翻譯成硬件可執行的機器指令，或者一種中間代碼在PLC 運行程序中解釋執行。對於機器代碼和中間代碼的規範並沒有在IEC 61131-3 中明確規範，具體的做法有兩種：
1 將PLC 程序翻譯成爲C或者C++ 語言，使用C語言編譯器編譯成爲機器代碼
2 輸出中間代碼，由PLC運行時解釋執行（就像JAVA的JVM那樣）。
各個廠商的中間代碼是格式不開放。這對軟件仿真，調試，版本控制等帶來的不便。於是PLCOpen 成立了一個名爲TC6 for XML（可擴展標記語言）的工作組。形成了IEC 61131-3的XML格式。
不同廠商的IDE 軟件可以輸出XML 文檔。然後將XML文檔進一步轉換成爲特定PLC的輸出代碼。
綜上所述，PLCOpen 協會致力於IEC 61131-3 的進一步規範。不過，它並沒有開源任何PLC 開發環境和PLC 運行時。它只是一些規範而已。
網絡上有一個OpenPLC 項目，名字經常會和PLCOpen 混淆。其實OpenPLC 是一個開源項目，將樹莓派改造稱爲PLC ，不夠它相對簡陋，還是停留再業餘愛好者水平。
IEC 61499標準
IEC 61131-3只是一個設備上的程序的標準。但是現代控制系統走向分散數字控制系統時。IEC 61131-3顯得不夠了。
於是，IEC 與2008年首先發布了面向分佈式控制系統的標準IEC61499.
IEC 61499定義了一種特定領域的建模語言，用於開發分佈式工業控制解決方案。IEC 61499通過改進軟件組件的封裝來擴展IEC 61131-3，以提高可重用性，提供與供應商無關的格式，並簡化對控制器到控制器通信的支持。它的分發功能和對動態重新配置的固有支持爲Industry 4.0和工業IoT應用程序提供了必需的基礎結構。
基於IEC 61499的控制技術可用於對整個工廠和設備進行編程，即使在分佈式控制系統中具有多個控制器也是如此。
IEC 61499與IEC 61131-3，的不同
IEC 61499
- 事件驅動程序執行
- 完整系統的編程
- 實時啓用
- 使用其他IEC 61499工程工具創建的程序無需導入/導出即可進行處理
- 控制邏輯可以分配給多個控制器。定義了控制器之間的通訊
- 任何符合IEC 61499的工程工具均可使用不同供應商的庫
IEC 61131
- 循環程序執行
- 單個控制器的編程
- 實時啓用
IEC 61499 功能塊
IEC61499 標準使用基於功能塊圖形編程方法，功能塊（FB）是其重要的概念。
和IEC 61131-3 中的功能塊類似，61499 的功能塊有數據輸入和數據輸出(底部)。與61131 不同的是 61499 的功能塊具有事件輸入和輸出端（頂部）。這是反映了兩種標準不同的控制方式。
在PLC 中，是採取循環程序控制方式，或者稱爲掃描（Scanning）控制方式。在一個循環週期（通常爲1ms）中，PLC 讀取所以的輸入端，將輸入端子的狀態存放在存放在內存，然後執行梯形圖一次，修改內部和輸出狀態。
在IEC 61499 控制器中，外部輸入產生一個事件信號，每個功能塊只有輸入事件發生變化時，內部功能才運行一次。同時輸出新的事件和輸出新的數據。由此可以看出，61499 控制器採取的一種異步控制方式。系統中的事件和數據也許在一個控制器內部傳遞，也可能通過網絡在系統的多個設備之間傳遞。61499 系統的通信機制更適合採納發佈訂閱模式（publish/subscribe）。
IEC 61499定義了在開發應用程序時可以使用的三種類型的FB：
- 基本功能塊（BFB）
- 基本功能塊（BFB）
- 服務功能塊（SFB）
IEC 61499的編程方式
在一個分佈式系統中，我們通常的方式是定義每個控制器的功能以及控制器之間的通信協議，數據格式，API，然後分別開發各個控制器內部程序和服務器程序。而在IEC 61499 中則不同，它是從系統的角度開發一個有各種功能塊組成的程序。然後將程序中的各個功能塊映射到每一個物理控制中。這個過程稱爲Mapping。
IEC 61499 使設計者從系統的角度開發應用程序。設計者不再關心設備之間的接口和通信。這樣做的好處是提高的程序開發的效率。不像傳統方式開發分佈式控制系統那麼碎片化。
IEC61499的開發者
和PLC 控制程序類似，IEC61499 開發工具同樣由少數的第三方公司開發，其中比較著名的是奧地利的nxtControl公司，它是符合IEC 61499分佈式系統控制技術領域的全球領導者。公司成立於2007年，過去十年來，公司已在這項技術上投入近1500萬歐元。2017年nxtControl 公司被施耐德公司收購
利用nxtControl的建築和工業自動化軟件，可使用拖放功能在多個控制器之間輕鬆實現整個工廠的控制智能化。交互通信的實現是完全自動的。基礎標準IEC 61499的事件驅動執行模型更易於將控制邏輯集成到更高層次的IT系統和雲應用中，創建一個從現場層到管理層的無縫數據高速通道。
IEC61499 開源項目Eclipse 4 diac
值得幸喜的是，與IEC 61131-3 不同，IEC61499 標準的開發工具出現了一個開源項目-Eclipse 4 diac。
4diac 是基於eclipse IDE 框架和Java 開發的ICE611499.它包括四個部分 ：
- IDE 開發環境-使用Java編寫
- FORTE – 一個運行時，使用C++編寫
- 功能塊庫
- 系統實例
對IEC 61499 開發的看法
- 相對古老的PLC而言，IEC 61499控制系統還比較年輕，傳統的制動控制廠商還沒有完全成熟的產品。如果現在加快研發投入，有機會彎道超車。
- 出現了Eclipse 4 diac 這樣的開源項目，能夠大大幫助我們進入IEC61499 控制系統的開發領域。當然在開源項目上完善和優化還有許多的工作要做。畢竟，開源項目爲我們指明瞭方向，讓我們知道從哪裏開始。
- 硬件模塊化，標準化很重要。IEC61499 的功能塊實現了硬件和軟件的分離，硬件的虛擬化，參數化，但是所以的功能塊最終還是要mapping 到控制器的硬件上去運行。硬件不規範和模塊化，很難去開發針對所有接口的功能塊。之前，我們嘗試開發基於圖形化的開發工具，經驗告訴我們，開發一些AND ，OR，Counter 等基礎功能塊比較容易，但是一旦開發複雜一點的功能塊，就必須和硬件模塊開發同步進行。每開發一個硬件模塊，就同步地開發一個或者幾個功能塊。
- 要從某個具體的行業開始。和上面第3點類似，如果漫無目標地開發同樣的功能塊。你會發現工作量非常大，而且到具體的應用時總髮現還缺一個。所以一開始針對某個特定領域比較合適，nxtControl好像也是從建築自動化開始的。做好一個行業，再做一個行業。讓你的功能塊滿足特定行業的所有應用場景。
- 如果我們現在什麼也不做，PLC的今天，就是IEC61499 控制系統的明天，我們永遠進入不了自動控制的高端領域。什麼工業4.0，工業物聯網，中國製造2025 都將是浮雲。
- 梯形圖，組態軟件的概念在控制工程師心中已經根深蒂固。其它方式他們難以接受。IT工程師和自動控制工程師就像雞和鴨對話，尿不到一個壺裏。IT 工程師只有妥協，纔有機會。
如果有人點贊，我將繼續這個話題。國內網絡中，這個課題的文章並不多。