從一份用戶調(diào)查看PLC編程語言和編程平臺的現(xiàn)狀和趨勢

一、用戶喜歡用哪些編程語言？圖1是用戶喜歡用哪些編程語言的調(diào)查結(jié)果。用得最多的是結(jié)構(gòu)化文本語言，其次是梯形圖，再次是功能塊圖，第四是順序功能圖，其它編程語言位居最后，在其它編程語言中用的最多的是C/C++語言。

從用戶這些語言的偏好看，可以得出以下結(jié)論：（1）各種編程語言運用的差距并不大，沒有特別多的，即使居第一的結(jié)構(gòu)化文本也不過比居于第五的其它語言多得有限。（2）明顯可見，用戶對于面向?qū)ο蟮恼Z言如結(jié)構(gòu)化文本語言和C/C++語言更為青睞。這反映了在智能制造和工業(yè)互聯(lián)網(wǎng)的應(yīng)用中面向?qū)ο蟮木幊陶Z言更能滿足用戶編程的需求。（3）許多PLC的編程環(huán)境支持用C/C++語言編寫功能塊。圖1

用戶采用PLC編程語言的調(diào)查結(jié)果為什么這次調(diào)查沒有列出指令表（IL）語言呢？

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

這里順便指出，結(jié)構(gòu)化文本語言ST在國內(nèi)的普及程度很差。有一個原因是某些在國內(nèi)應(yīng)用相當廣泛的小型PLC不支持ST編程，影響了它的推廣使用。面向?qū)ο蟮木幊蘋OP正在隨著智能制造和工業(yè)互聯(lián)網(wǎng)的需求快速地發(fā)展，而IEC61131-3規(guī)范的5種編程語言中ST是最容易實現(xiàn)OOP的。因此，這一傾向值得重視。如果我們國家繼續(xù)沿著按某些自動化公司的PLC產(chǎn)品機型進行工科教育，那么在PLC的開發(fā)和應(yīng)用方向上將永遠步少數(shù)幾個工業(yè)發(fā)達國家的后塵，很難有翻身的機會。編程的熟練程度從調(diào)查的結(jié)果看，熟練掌握梯形圖語言和結(jié)構(gòu)化文本語言的比例較高，熟練掌握功能圖語言次之，熟練掌握順序功能圖語言的比例較低。而不了解順序功能圖語言的比例最高。

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

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

圖2

掌握編程語言的熟練程度三、對PLC編程軟件平臺的要求調(diào)查從軟件的可靠性、軟件的易用性、不同供應(yīng)商軟件平臺所編制的應(yīng)用軟件的移植性、I/O配置軟件和不同供應(yīng)商的PLC控制器之間的通信等5個方面征詢意見。

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

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

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

圖3

用戶對軟件平臺的評價四、流程控制采用PLC呈現(xiàn)增長趨勢這次調(diào)查有一個出乎所料的結(jié)果就是，PLC在流程控制領(lǐng)域中的應(yīng)用呈現(xiàn)增長趨勢，超過73%的被調(diào)查者反映他們采用PLC進行流程控制，而采用DCS在流程控制中的只占27%左右（見圖4）。當然，規(guī)模巨大的流程控制（如I/O點接近10萬點或超過10萬點，非DCS系統(tǒng)莫屬，在這方面PLC系統(tǒng)還有很長的路要走。

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

一是PLC的性價比遠超DCS，在PLC能滿足流程控制的系統(tǒng)要求的時候，選擇PLC的投入要顯著的少，維護成本也隨之下降。二是PLC的性能有較大的提升，在一定的成程度上可以替代DCS的功能。三是調(diào)查樣本有可能不夠全，參與調(diào)查的以流程控制為主的企業(yè)不夠多。

圖4

PLC在流程控制中的應(yīng)用超過DCS

五、調(diào)查中許多用戶的想法和留言

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

有用戶認為，采用PLCopen的XML規(guī)范來解決多個軟件供應(yīng)商的移植性問題，看來不太可能真正付諸實現(xiàn)，或者總是難以適當?shù)卣５剡\行。

最好是供應(yīng)商現(xiàn)在能夠為編程環(huán)境提供開放的腳本語言的接口，在這樣的環(huán)境下代碼轉(zhuǎn)換和自動操作比較容易進行。

關(guān)于編程平臺的相互交叉兼容性的問題，有用戶認為應(yīng)該引起重視。但另一種意見則認為，一般的PLC供應(yīng)商和開發(fā)商都難以與他們的競爭對手合作，試想將一根以太網(wǎng)網(wǎng)線從羅克韋爾的ControlLogixPLC上接到西門子的S7-400的以太網(wǎng)口，想象得到如果能夠真能通信起來，這豈不是滑天下之大稽嗎。顯然用戶對移植性的問題是不抱太大的希望的。不過，希望已經(jīng)開發(fā)的代碼能夠?qū)崿F(xiàn)更多的交叉移植性，一直是用戶希望解決的事情，但至少到目前為止，這還是沒有很好的解決方案。OPCUA有用戶認為，完全接受OPCUA的支持這種可能性實屬異想天開，真正實現(xiàn)的可以說是鳳毛麟角。也有用戶提出，應(yīng)該能夠定義自己的信息模型和采用其它的標準信息模型（如PackML和其它）。

有一個用戶提出很好的建議，PLCopen的IEC61131-3的OPCUA信息模型應(yīng)該完全發(fā)揮結(jié)構(gòu)化文本語言ST面向?qū)ο缶幊蹋∣OP）的性能。這樣用OPCUA通信應(yīng)該實現(xiàn)起來就簡單了，只要一個接口便可以在OPCUA網(wǎng)絡(luò)中點開一個實例，接著按程序中的一個對象（功能塊FB）那樣進行處理。這樣最終得到一個面向通信的架構(gòu)和面向?qū)ο蟮木幊?。不過我們?nèi)匀恍枰獱顟B(tài)機進行方法的調(diào)用。為什么不這樣做呢？可靠性

有用戶認為，現(xiàn)在有些PLC編程平臺的集成開發(fā)環(huán)境IDE往往并不完善，或者有時會出現(xiàn)操作系統(tǒng)藍屏。顯然，可靠性問題出現(xiàn)在現(xiàn)代的集成開發(fā)環(huán)境內(nèi)，每個供應(yīng)商都太忙于將他們的編程環(huán)境集成到一個工具中，同時還實現(xiàn)新的喜好性能，而花在提高可靠性方面的投入不夠。希望編程平臺的開發(fā)商要認識到，可靠性和可用性問題常常造成最終用戶昂貴的時間損失。編程特性關(guān)于編程平臺的改善，調(diào)查中用戶提出了改進的意見。如在用ST鍵入能時自動完成標簽命名的全部；能給出有意義的出錯信息；文檔能易于存取和能搜索；軟件開發(fā)者應(yīng)該對客戶負責(zé)，給予技術(shù)支持；在梯形圖編程的框架下允許嵌入復(fù)雜的編程；能夠?qū)崿F(xiàn)由順序功能圖語言自動自動生成代碼；能在編程平臺系統(tǒng)中開放像C/Java的編程語言；文本文件的編譯采用C語言類型的編程工具的方法，具有版本管理、歸檔、管理、實用程序庫，以及轉(zhuǎn)換為另一種編譯程序/另一種版本/另一種語言的能力。還有用戶提出，采用現(xiàn)代的編程方法和技術(shù)，軟件供應(yīng)商應(yīng)該有更好的源代碼控制（Git）、單元測試等的知識和集成能力。所謂Git是一種在軟件開發(fā)期間跟蹤源代碼變化的分布式版本控制系統(tǒng)，專門用來協(xié)調(diào)編程人員之間的工作，但也可以用來跟蹤任意組合的文件的變化。PLCopen和OPC

UA的協(xié)同工業(yè)4.0和數(shù)字化轉(zhuǎn)型推動著先進的物聯(lián)網(wǎng)IoT方法，這就是語義信息模型。工業(yè)自動化工業(yè)已經(jīng)在支持建立開放的語義模型，這就是為什么PLCopen和OPC基金會建立聯(lián)合工作組來滿足這一需求。其結(jié)果包括IEC61131-3的OPCUA信息模型標準，以及PLCopen和OPCUA合作開發(fā)的IEC61131-3的OPCUA客戶端功能塊規(guī)范和OPCUA服務(wù)端功能塊規(guī)范。現(xiàn)在還只有很少的編程平臺能夠提供按規(guī)范開發(fā)的OPCUA的功能塊。

六、后記

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

國內(nèi)經(jīng)過多年的發(fā)展，雖然沒有真正具有市場競爭力的有關(guān)軟件產(chǎn)品出現(xiàn)，但畢竟一些DCS和PLC的公司（如浙江中控、、和利時、杭州優(yōu)穩(wěn)）都擁有自用的編程平臺環(huán)境。杭州電子科技大學(xué)計算機學(xué)