圖1是用戶喜歡用哪些編程語言的調查結果。用得最多的是結構化文本語言，其次是梯形圖，再次是功能塊圖，第四是順序功能圖，其它編程語言位居最后，在其它編程語言中用的最多的是C/C++語言。

從用戶這些語言的偏好看，可以得出以下結論：

（1）各種編程語言運用的差距并不大，沒有特別多的，即使居第一的結構化文本也不過比居于第五的其它語言多得有限。

（2）明顯可見，用戶對于面向對象的語言如結構化文本語言和C/C++語言更為青睞。這反映了在智能制造和工業互聯網的應用中面向對象的編程語言更能滿足用戶編程的需求。

（3）許多PLC的編程環境支持用C/C++語言編寫功能塊。

↑圖1 用戶采用PLC編程語言的調查結果

為什么這次調查沒有列出指令表（IL）語言呢？

這是因為在2012年更新的IEC 61131-3 V.3編程語言國際標準規范中，雖然還保留了IL語言，但已經有提議將將它從5種編程語言中剔除。隨著時間的推移，使用這種類似匯編語言的IL對PLC編程的人越來越少，幾乎失去了存在的價值。

這里順便指出，結構化文本語言ST在國內的普及程度很差。有一個原因是某些在國內應用相當廣泛的小型PLC不支持ST編程，影響了它的推廣使用。面向對象的編程OOP正在隨著智能制造和工業互聯網的需求快速地發展，而IEC 61131-3規范的5種編程語言中ST是最容易實現OOP的。因此，這一傾向值得重視。如果我們國家繼續沿著按某些自動化公司的PLC產品機型進行工科教育，那么在PLC的開發和應用方向上將永遠步少數幾個工業發達國家的后塵，很難有翻身的機會。

從調查的結果看，熟練掌握梯形圖語言和結構化文本語言的比例較高，熟練掌握功能圖語言次之，熟練掌握順序功能圖語言的比例較低。而不了解順序功能圖語言的比例最高。

看起來結構化程度很高、而且最適宜表達順序工藝，工藝與編程對應得最好（也即程序的可讀性最好）的順序功能圖語言，在歐美普及程度不算高。這也令人有所不解。

源于法國的這種PLC編程語言獲得了一些專業組織青睞，譬如美國OMAC推的PackML就重點選擇了SFC作為包裝行業的編程語言，符合順序控制工藝的機械加工和批處理加工的比比皆是，為什么SFC的使用者不多呢？一種可能性是被調查的樣本還不夠多，或者說被調查的細分行業還不夠全。

↑圖2 掌握編程語言的熟練程度

調查從軟件的可靠性、軟件的易用性、不同供應商軟件平臺所編制的應用軟件的移植性、I/O配置軟件和不同供應商的PLC控制器之間的通信等5個方面征詢意見。

結果不出所料，認為軟件可靠性好和很好的占大多數，認為軟件的易用性中等和好的占大多數，認為應用程序移植性差、較差和中等的占大多數，認為I/O配置軟件中等和好的占大多數，認為不同供應商PLC控制器間的通信差和中等的占大多數。

這些調查結果實事求是地反映了當前PLC編程軟件和平臺的現狀，表明不同軟件和平臺開發出來的應用軟件的移植性遠遠達不到最終用戶的要求，這也是單純基于IEC 61131-3的開發軟件和平臺難以基本解決的問題，更遑論徹底解決的問題。

看來要解決這一問題需要另辟蹊徑，譬如說美國開放流程自動化系列標準OPAS正在開發以IEC 61499為依托的應用程序的移植性，已經取得了實驗室的驗證，進一步需要進行工業實踐的驗證。

↑圖3 用戶對軟件平臺的評價

這次調查有一個出乎所料的結果就是，PLC在流程控制領域中的應用呈現增長趨勢，超過73%的被調查者反映他們采用PLC進行流程控制，而采用DCS在流程控制中的只占27%左右（見圖4）。當然，規模巨大的流程控制（如I/O點接近10萬點或超過10萬點，非DCS系統莫屬，在這方面PLC系統還有很長的路要走。

PLC在流程控制中的應用超過DCS，估計原因有幾個方面：

一是PLC的性價比遠超DCS，在PLC能滿足流程控制的系統要求的時候，選擇PLC的投入要顯著的少，維護成本也隨之下降。

二是PLC的性能有較大的提升，在一定的成程度上可以替代DCS的功能。

三是調查樣本有可能不夠全，參與調查的以流程控制為主的企業不夠多。

↑圖4  PLC在流程控制中的應用超過DCS

編程軟件和編程平臺的用戶在調查中通過額外的留言反映了他們的想法和意見，他們希望PLC的供應商在其編程軟件方面能更好地滿足用戶的需要。下面按有關的題目分門別類的闡述。

 應用軟件的移植性問題 

有用戶認為，采用PLCopen的XML規范來解決多個軟件供應商的移植性問題，看來不太可能真正付諸實現，或者總是難以適當地正常地運行。最好是供應商現在能夠為編程環境提供開放的腳本語言的接口，在這樣的環境下代碼轉換和自動操作比較容易進行。

關于編程平臺的相互交叉兼容性的問題，有用戶認為應該引起重視。但另一種意見則認為，一般的PLC供應商和開發商都難以與他們的競爭對手合作，試想將一根以太網網線從羅克韋爾的ControlLogix PLC上接到西門子的S7-400的以太網口，想象得到如果能夠真能通信起來，這豈不是滑天下之大稽嗎。顯然用戶對移植性的問題是不抱太大的希望的。不過，希望已經開發的代碼能夠實現更多的交叉移植性，一直是用戶希望解決的事情，但至少到目前為止，這還是沒有很好的解決方案。

 OPC UA 

有用戶認為，完全接受OPC UA的支持這種可能性實屬異想天開，真正實現的可以說是鳳毛麟角。也有用戶提出，應該能夠定義自己的信息模型和采用其它的標準信息模型（如PackML和其它）。

有一個用戶提出很好的建議，PLCopen的IEC 61131-3的OPC UA信息模型應該完全發揮結構化文本語言ST面向對象編程（OOP）的性能。這樣用OPC UA通信應該實現起來就簡單了，只要一個接口便可以在OPC UA網絡中點開一個實例，接著按程序中的一個對象（功能塊FB）那樣進行處理。這樣最終得到一個面向通信的架構和面向對象的編程。不過我們仍然需要狀態機進行方法的調用。為什么不這樣做呢？

 可靠性 

有用戶認為，現在有些PLC編程平臺的集成開發環境IDE往往并不完善，或者有時會出現操作系統藍屏。顯然，可靠性問題出現在現代的集成開發環境內，每個供應商都太忙于將他們的編程環境集成到一個工具中，同時還實現新的喜好性能，而花在提高可靠性方面的投入不夠。希望編程平臺的開發商要認識到，可靠性和可用性問題常常造成最終用戶昂貴的時間損失。

 編程特性 

關于編程平臺的改善，調查中用戶提出了改進的意見。如在用ST鍵入能時自動完成標簽命名的全部；能給出有意義的出錯信息；文檔能易于存取和能搜索；軟件開發者應該對客戶負責，給予技術支持；在梯形圖編程的框架下允許嵌入復雜的編程；能夠實現由順序功能圖語言自動自動生成代碼；能在編程平臺系統中開放像C/Java的編程語言；文本文件的編譯采用C語言類型的編程工具的方法，具有版本管理、歸檔、管理、實用程序庫，以及轉換為另一種編譯程序/另一種版本/另一種語言的能力。還有用戶提出，采用現代的編程方法和技術，軟件供應商應該有更好的源代碼控制（Git）、單元測試等的知識和集成能力。所謂Git是一種在軟件開發期間跟蹤源代碼變化的分布式版本控制系統，專門用來協調編程人員之間的工作，但也可以用來跟蹤任意組合的文件的變化。

 PLCopen和OPC UA的協同 

工業4.0和數字化轉型推動著先進的物聯網IoT方法，這就是語義信息模型。工業自動化工業已經在支持建立開放的語義模型，這就是為什么PLCopen和OPC基金會建立聯合工作組來滿足這一需求。其結果包括IEC 61131-3的OPC UA信息模型標準，以及PLCopen和OPC UA合作開發的IEC 61131-3的OPC UA客戶端功能塊規范和OPC UA服務端功能塊規范?，F在還只有很少的編程平臺能夠提供按規范開發的OPC UA的功能塊。

自從在國內活躍多年的德國KW公司被菲尼克斯收購后，因發展目標調整的關系，從2019年中開始不再發展基于IEC 61131-3的編程平臺的客戶。于是在國際和國內IEC 61131-3編程平臺市場中3S的CodeSys一枝獨秀，隨之漲價之風盛吹。

國內經過多年的發展，雖然沒有真正具有市場競爭力的有關軟件產品出現，但畢竟一些DCS和PLC的公司（如浙江中控、、和利時、杭州優穩）都擁有自用的編程平臺環境。杭州電子科技大學計算機學院的嚴義、鄔惠峰團隊的CASE平臺歷經十多年的錘煉和提升，在IEC 61131-3的編程平臺上增加了PLCopen運動控制規范的功能。與此同時，近年在北京和上海都出現了專門以開發IEC 61131-3的編程平臺為目標的公司，規模盡管不大，但由于創業著憑著許多年在這個領域內摸爬滾打的積累的技術，發展的還是有聲有色。我們期待在此工業軟件方向上會出現商品化產業化的突破。

此內容為轉載文章，如有侵權請及時聯系本站刪除！