上個世紀九十年代，國際電工委員會（IEC）就着手製定IEC16499標準，它是一個面向分佈式工業過程，測量和控制系統的一個基於功能塊編程的國際標準。它於2000年正式發佈了第一部分，2005年全部發布完成。按照IEC 的規矩，每隔五年會修訂一次，最近一次修訂是2015年。IEC61499 工作組的成員來自於美國，日本，英國和許多歐洲國家。它們代表了工業控制的供應商和用戶。
就這麼一個陣容強大，花費了很大努力開發的標準，學術界的研究還比較熱，出現了許多的論文。而工業界似乎是冰火兩重天，一直是不溫不火。除了奧地利的nxtControl 公司以外，像西門子，施耐德，Honeywell大公司始終沒有商業化的產品出現。就像研華公司曾經在2016年推出了ADAM 6600 ，支持IEC61499。現在在它們的網站上已經不見了蹤影。施耐德收購了nxtControl 公司，在它們的建築自動化產品中具有功能塊圖形編程，但是任然是基於 IEC-61131-3 的PLC 功能塊標準，並沒有使用IEC61499。Rockwell 自動化公司收購了 ISaGRAF公司，現在在Rockwell 公司的網站上還能看到 ISaGRAF的產品資料。但是也好像只是一個軟件孤零零地在那裏。在施耐德公司的另一個產品-用於遠程工業測量和控制的Foxboro SCD2200 RTU 產品中，聲稱內置了ISaGRAF的編程環境。支持IEC61131-3 和IEC16499 編程。真是夠亂的。
問題到底出在哪裏呢？不得而知。也許大公司覺得IEC1131-3 用的夠好，沒有必要那麼急得切換到IEC16499？ 還是什麼別個考慮？ 本人曾經花了一年多的時間研究數據流圖形化編程技術，根據自己的體會，在這裏談談IEC61499 產品實現的困難吧。
IEC61499 的核心概念是功能塊（Function block）編程。其目的是採用面向目標程序設計的思想，使工業控制軟件封裝成爲功能塊形式的軟件組件（Software component）。而且功能塊與資源無關（所謂資源你可以理解爲硬件設備）。一個分佈式控制的應用軟件，是一個功能塊網絡，可以將功能塊網絡分解成若干段，將每一段映射到分佈式的設備中去運行。當映射的時候，自動地插入了通信服務接口功能塊。這就是IEC61499 爲我們描寫的理想狀態。如果設計一個複雜的分佈式應用系統變成爲通過拖動功能塊，連線繪製一個功能塊網絡那麼簡單的話。當然是十分誘人的。專家會一下子總結出一堆優點，描繪令人激動的場景出來。
不過具體實現的過程中，會遇到許多的問題：
1 功能塊不可能完全與資源獨立
除非假設你的設備的性能無限地大，否則功能塊就不可能完全與資源，也就是運行功能塊的硬件設備無關。工業測量控制系統具有很高的實時性要求。使用軟件實現的功能塊在不同的硬件平臺上運行時間會有很大的差異。比如一個FFT 功能塊在cortex-M和cortex-A，或者X86 處理器上的運行時間是完全不同的。
2 功能塊不可能完全與網絡無關
和第一點相同的原因，不同的網絡和協議對系統性能，時延的影響是非常大的。
3. 誰來開發功能塊
另一個大的問題是誰來開發各種功能塊，用什麼語言來開發功能塊？功能塊網絡編程真的很誘人，但是誰來開發這些功能塊呢？IEC61499 編程環境會開發一些基本的功能塊，它們包括了基礎的事件功能塊，通信服務功能塊。而硬件設備廠商會開發一些與硬件有關的服務接口功能塊，例如IO子系統的讀寫服務功能塊。但是，一個複雜的分佈式控制系統不僅僅是PID那樣簡單的功能塊那麼簡單，它需要的功能塊是非常多的，比如FFT功能塊，信號濾波功能塊等等。這些功能塊由誰來編寫呢？理論上IEC61499 提供了複合功能塊的概念，用戶可以使用一些基礎功能塊來實現複雜的功能塊，不過這對控制工程師的要求就非常的高，學習曲線變得陡峭。國內的控制工程師實際上連PLC中的功能塊都使用甚少，所以讓控制工程師編寫功能塊是不太現實的。於是只能指望專業的平臺公司或者第三方開發者來開發各種功能庫，像nxtControl 公司，他們提供了許多的功能塊庫。包括建築自動化庫，過程控制庫，機器自動化庫。由此看來，只有針對某一個特定的領域，才能開發出功能塊庫。這是一個工作量巨大的任務。另一方面，即使你開發的足夠的庫，在具體的應用中，控制工程師還會覺得少一個庫。工業過程控制系統真的是有千變萬化的需求。
還有一個問題是使用什麼工具來開發具體應用中專用的功能塊程序。IEC61499 並沒有規定功能塊編程的程序設計語言，理論上任何語言都可以用來編寫功能塊程序。不過，功能塊不僅是在開發平臺上連個線，繪製功能塊網絡那麼簡單，他們最終要部署到各種資源中去。所謂部署，就是將功能塊網絡的”程序” 下載到設備上，和IEC61499 兼容的運行時，資源共同完成功能塊的實際控制功能。這些程序也許是一個XML 文檔，也許是一個java 程序。設備上的運行時就像一個虛擬機一樣解釋執行這個功能塊網絡。顯然，解釋器方式的運行效率不高，而且對硬件資源的要求更高（通常需要linux 系統支持）。所以在小型設備中，更加傾向於將功能塊翻譯成爲C++，和運行庫一起編譯成爲設備的固件，下載到設備之中。當然這樣做增加了開發工具的複雜性和對硬件的依賴，而且對系統仿真和調試帶來了不便。
目前大致有三種不同的方式來編寫專用功能塊程序的方式：
- 使用現成的功能塊來構建複合功能塊
- 使用java 編寫功能塊
- 使用C/C++編寫功能塊。ISaGRAF 就是輸出C 語言源碼。
最後一個問題是如果使用過分低級的功能塊來編寫複雜的複合功能塊，會使軟件的碎片化十分嚴重。從而影響軟件的執行效率。
未來的研究方向：
-針對某一個領域中使用ICE61499 的概念和框架。
要聚焦某個具體的應用纔可能實用化。要不然只能用於學術研究和教育。只有針對具體的應用，將行業種的經驗，know-how封裝成爲功能塊，來會產生使用它的動力。用戶往往就是這樣，當他需要某個功能，而剛好只有某一項技術才能解決，纔會驅動自己硬着頭皮去學習新技術。要不然你讓一個工廠的控制工程師去學習像labviews ，matlab python 這樣的新技術比什麼都難。免費，開源，公開課都不好使。
-開發面向具體應用的功能塊庫，比如CNC機牀控制，建築自動化，能源管理等領域。
如果沒有行業的背景，開發通用的功能塊，覺得再怎麼努力都無法滿足用戶的需要。我們以前開發數據流圖形設計語言的時候就是如此感覺。要達到像NI 那樣的境界，又不是一日之功。
-要與硬件設備同步開發。
在特定硬件平臺上測試功能塊的性能和行爲，這就像芯片設計一樣，要有silicon prove 的過程。
-小型裝置上的功能塊傾向於使用C/C++ 實現
效率更高，使用的硬件資源比較少，我們再嘗試再STM32H743 平臺上開發IEC61499 的運行時程序。而HMI 或者服務器端的功能塊可以多樣化語言來開發。特別是java,javascript,python 或者Go 語言。
-IEC61499 與其它物聯網技術融合。
IEC61499 標準只是一種分佈式系統的建模方式和概念，它並沒有涉及任何實現技術。在具體實施過程中可以使用大量物聯網最新技術 MQTT，OPC UA，Docker 容器等等。而目前物聯網系統最缺乏的是系統建模和軟件組件標準化。所以IEC61499 和物聯網可以完美地互補。
個人看法，並不成熟。感興趣的朋友可以多多交流。