從一份用戶調查看PLC程式語言和編程平臺的現狀和趨勢

2019年PLCopen國際組織和美國的automation.com網站聯合進行了PLC用戶編程偏好的調查。總數為200個響應者絕大部分來自北美和歐洲。調查的結果反映了PLC編程的趨勢，以及用戶對PLC編程軟體供應商的一些想法和意見。這些對我國的自動化領域的發展，特別是以PLC為主要手段開發工業控制系統的工程師們也有一定的參考價值。

一、用戶喜歡用哪些程式語言？

圖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 掌握程式語言的熟練程度

三、對PLC編程軟體平臺的要求

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

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

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

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

圖3 用戶對軟體平臺的評價

四、流程控制採用PLC呈現增長趨勢

這次調查有一個出乎所料的結果就是，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服務端功能塊規範。現在還只有很少的編程平臺能夠提供按規範開發的OPC UA的功能塊。

六、後記

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

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

註：本文由作者為《工控百家談》獨家撰稿，如需轉載請與我們聯繫。
作者簡介彭瑜，教授級高工，上海工業自動化儀表研究院技術顧問，PLCopen中國組織名譽主席，工信部智能製造標準化體系建設工作組專家，國家智能製造標準化協調推進組專家諮詢組專家。