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

從用戶這些語(yǔ)言的偏好看，可以得出以下結(jié)論：

（1）各種編程語(yǔ)言運(yùn)用的差距并不大，沒有特別多的，即使居第一的結(jié)構(gòu)化文本也不過比居于第五的其它語(yǔ)言多得有限。

（2）明顯可見，用戶對(duì)于面向?qū)ο蟮恼Z(yǔ)言如結(jié)構(gòu)化文本語(yǔ)言和C/C++語(yǔ)言更為青睞。這反映了在智能制造和工業(yè)互聯(lián)網(wǎng)的應(yīng)用中面向?qū)ο蟮木幊陶Z(yǔ)言更能滿足用戶編程的需求。

（3）許多PLC的編程環(huán)境支持用C/C++語(yǔ)言編寫功能塊。

↑圖1 用戶采用PLC編程語(yǔ)言的調(diào)查結(jié)果

為什么這次調(diào)查沒有列出指令表（IL）語(yǔ)言呢？

這是因?yàn)樵?012年更新的IEC 61131-3 V.3編程語(yǔ)言國(guó)際標(biāo)準(zhǔn)規(guī)范中，雖然還保留了IL語(yǔ)言，但已經(jīng)有提議將將它從5種編程語(yǔ)言中剔除。隨著時(shí)間的推移，使用這種類似匯編語(yǔ)言的IL對(duì)PLC編程的人越來越少，幾乎失去了存在的價(jià)值。

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

從調(diào)查的結(jié)果看，熟練掌握梯形圖語(yǔ)言和結(jié)構(gòu)化文本語(yǔ)言的比例較高，熟練掌握功能圖語(yǔ)言次之，熟練掌握順序功能圖語(yǔ)言的比例較低。而不了解順序功能圖語(yǔ)言的比例最高。

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

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

↑圖2 掌握編程語(yǔ)言的熟練程度

調(diào)查從軟件的可靠性、軟件的易用性、不同供應(yīng)商軟件平臺(tái)所編制的應(yīng)用軟件的移植性、I/O配置軟件和不同供應(yīng)商的PLC控制器之間的通信等5個(gè)方面征詢意見。

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

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

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

↑圖3 用戶對(duì)軟件平臺(tái)的評(píng)價(jià)

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

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

一是PLC的性價(jià)比遠(yuǎn)超DCS，在PLC能滿足流程控制的系統(tǒng)要求的時(shí)候，選擇PLC的投入要顯著的少，維護(hù)成本也隨之下降。

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

三是調(diào)查樣本有可能不夠全，參與調(diào)查的以流程控制為主的企業(yè)不夠多。

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

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

 應(yīng)用軟件的移植性問題 

有用戶認(rèn)為，采用PLCopen的XML規(guī)范來解決多個(gè)軟件供應(yīng)商的移植性問題，看來不太可能真正付諸實(shí)現(xiàn)，或者總是難以適當(dāng)?shù)卣５剡\(yùn)行。最好是供應(yīng)商現(xiàn)在能夠?yàn)榫幊汰h(huán)境提供開放的腳本語(yǔ)言的接口，在這樣的環(huán)境下代碼轉(zhuǎn)換和自動(dòng)操作比較容易進(jìn)行。

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

 OPC UA 

有用戶認(rèn)為，完全接受OPC UA的支持這種可能性實(shí)屬異想天開，真正實(shí)現(xiàn)的可以說是鳳毛麟角。也有用戶提出，應(yīng)該能夠定義自己的信息模型和采用其它的標(biāo)準(zhǔn)信息模型（如PackML和其它）。

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

 可靠性 

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

 編程特性 

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

 PLCopen和OPC UA的協(xié)同 

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

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

國(guó)內(nèi)經(jīng)過多年的發(fā)展，雖然沒有真正具有市場(chǎng)競(jìng)爭(zhēng)力的有關(guān)軟件產(chǎn)品出現(xiàn)，但畢竟一些DCS和PLC的公司（如浙江中控、、和利時(shí)、杭州優(yōu)穩(wěn)）都擁有自用的編程平臺(tái)環(huán)境。杭州電子科技大學(xué)計(jì)算機(jī)學(xué)院的嚴(yán)義、鄔惠峰團(tuán)隊(duì)的CASE平臺(tái)歷經(jīng)十多年的錘煉和提升，在IEC 61131-3的編程平臺(tái)上增加了PLCopen運(yùn)動(dòng)控制規(guī)范的功能。與此同時(shí)，近年在北京和上海都出現(xiàn)了專門以開發(fā)IEC 61131-3的編程平臺(tái)為目標(biāo)的公司，規(guī)模盡管不大，但由于創(chuàng)業(yè)著憑著許多年在這個(gè)領(lǐng)域內(nèi)摸爬滾打的積累的技術(shù)，發(fā)展的還是有聲有色。我們期待在此工業(yè)軟件方向上會(huì)出現(xiàn)商品化產(chǎn)業(yè)化的突破。

此內(nèi)容為轉(zhuǎn)載文章，如有侵權(quán)請(qǐng)及時(shí)聯(lián)系本站刪除！