1015 【萬泉河】PLC程序中也可以有中間件
我們認為，自動化行業(yè)是無限接近IT行業(yè)的，然而又是個相對獨立和小眾的小行業(yè)。
所以， IT行業(yè)中的大部分理念和思想，大都可以對標到自動化行業(yè)中， 找到相應的影子。
所以，當我們對前方的路看不清的時候，不妨抬起頭來觀摩參考下隔壁，他們都在做什么， 怎么做的， 做的東西使用的方法是不是我們可以拿來借鑒，有多少程度可以借鑒。 遠比我們自己拍腦瓜閉門造車要容易的多。
我已經寫過很多相關的文章了，介紹IT行業(yè)的理念， 以及我自己的思考與實踐，把這些理念方法應用到PLC行業(yè)。
比如，面向對象的程序方法，code review, 軟件架構師，高內聚低耦合，編程規(guī)范，程序移植等等。
當然PLC行業(yè)還是存在一定的特殊性，也相對封閉， 有自己的行業(yè)特點，所以隔壁好多思想方法并沒那么容易直接拿過來套用。 也所以，我好多相關文章寫出來， 很多人讀不懂， 不理解。
比如，前面一篇程序移植的文章發(fā)表后，后面的跟帖中有一位抬杠專業(yè)戶的質問，按照煙臺方法做的程序，程序從一個PLC平臺移植到另一個廠家的平臺，移植前后， 代碼相同部分有多少？而不同之處有多少？
如果順著這位杠子手的邏輯回答， 那顯然只能按他預設的答案回答了。 不管用不用煙臺方法，結果都是一樣的，相同部分幾乎沒有，而幾乎全部都是不相同的。
比如我做的西門子之外的各個品牌的標準化程序，不管是CODESYS倍福，還是三菱歐姆龍，尚不提最新的信捷等小PLC，就單看三菱的程序， 把BST的庫函數移植到三菱GX2平臺，SCL程序代碼復制到三菱ST語言之后，每行都要包含2-3個錯誤，一個MOTOR塊，如果一字不改的話， 錯誤要超過1000個。 而把錯誤逐個修改之后，你要問相同部分有多少？嚴格來說，沒有一句相同的！
所以，按照這位提問者的邏輯，他顯然是贏了。贏了他自己。
而顯然，這位是不曉得軟件編程中有個中間件的概念的。
對于中間件，其實都不需要什么名詞解釋，因為很容易理解，名詞本身就是詞義。 當然也可以從網絡搜索到標準的名詞解釋。
中間件是一類連接軟件組件和應用的計算機軟件，它包括一組服務。以便于運行在一臺或多臺機器上的多個軟件通過網絡進行交互。該技術所提供的互操作性，推動了一致分布式體系架構的演進，該架構通常用于支持并簡化那些復雜的分布式應用程序，它包括web服務器、事務監(jiān)控器和消息隊列軟件。 [2]
中間件(middleware)是基礎軟件的一大類，屬于可復用軟件的范疇。顧名思義，中間件處于操作系統(tǒng)軟件與用戶的應用軟件的中間。 [2]
中間件在操作系統(tǒng)、網絡和數據庫之上，應用軟件的下層，總的作用是為處于自己上層的應用軟件提供運行與開發(fā)的環(huán)境，幫助用戶靈活、高效地開發(fā)和集成復雜的應用軟件。在眾多關于中間件的定義中，比較普遍被接受的是IDC表述的：中間件是一種獨立的系統(tǒng)軟件或服務程序，分布式應用軟件借助這種軟件在不同的技術之間共享資源，中間件位于客戶機服務器的操作系統(tǒng)之上，管理計算資源和網絡通信。 [2]
然而，這個概念又與我提到的其它詞匯一樣， 不能直接對標找到PLC行業(yè)的解釋。 甚至，之前也無人正式針對性的介紹過。 或許，未來，網絡搜索關鍵詞“PLC” + “中間件”，應該主要會搜到萬某的本文。
所以，在PLC行業(yè)，怎樣才叫中間件，需要單獨去思考和定義。
打個比方，比如控制一個工件的移動， 會使用伺服或者步進電機，通過驅動它們，位置模式，或者速度模式，或者速度+位置的模式，達到工藝需要的結果。
拋開步進電機或者其它的代用方案不談， 只談伺服電機本身，就可能有多種控制方案，控制器可以有多個品牌，通訊方式也可以有多種，脈沖方式或者DP, PN, ETHERCAT等多種工業(yè)總線。 甚至具體的控制方式也可以多種，工藝對象和EPOS等。
然而， 你可以把所有的方式都各自封裝為單獨的中間件，而放給工藝邏輯的只有接口指令，比如在工藝邏輯中， 只包含對伺服的位置指令或者速度指令。
那么，未來的工藝實現，就可以與具體的伺服選型方案無關了。 比如工藝要求步驟1， 定位移動到相應位置，2，以設定速度運行，等待結束條件；3， 給定目標位置，達到位置。
按照工藝要求完成調試后， 哪怕未來更換了伺服電機品牌， 甚至不再使用伺服電機， 比如油缸。而上述的工藝邏輯代碼不需要修改，可以繼續(xù)使用。
甚至，即便PLC的型號品牌更換了， 也只是根據其語法規(guī)范做一些替換移植， 而不需要被具體的內部控制方法困擾。
這就是中間件的意義。
一定有人一眼就看懂了，講了半天， 這不就是FB嗎！FB就是中間件的話， 那我早就會了啊！
沒錯， 中間件當然要通過FB功能塊來實現，但你做的FB是否能達到中間件的功能， 你的工藝邏輯中是否夾雜了所使用的伺服方案特有的指令和方法模式，在面向移植需求的時候，能否簡單實現移植？
或者， 去回答一下樓上那位杠子手的問題， 代碼移植前后的相似度有多少？
我在做信捷等小PLC的標準化開發(fā)的時候， 最頭疼的便是其伺服實現。 伺服通過脈沖控制，而每個脈沖輸出靠系統(tǒng)變量來控制，使用的系統(tǒng)變量各不相同。 想做成一個統(tǒng)一的FB塊，都非常困難， 更何提中間件了。
當然， 在某位學員的幫助下，繞了很多圈子，最后還是實現了。 但實現過程不夠簡潔。
而我所見過的所有品牌的項目程序，相關部分應用都深度耦合成一鍋粥，離本文所預期的中間件目標都還相差很遠。
不過，最后還是提一下，如果未來這個行業(yè)足夠成熟，標準化架構方法普及之后， 中間件倒是可以成為一個不錯的中間產品，甚至可以形成一定規(guī)模的交易市場。任何做項目的一方， 需要什么中間件的時候，市場上巡視一番， 找到合適的買回家，簡單使用拼接，自己的工藝項目就完成了。
以這樣方式描述未來愿景，比以往高內聚低耦合的語言，是不是更親和，更容易理解了？
當然啦， 不要誤解歪了， 煙臺方法不賣任何中間件， 也不倒賣中間件， 我只傳授制作中間件和使用中間件的方法。 煙臺方法的學員們之間，可以互相交流交換中間件，因為方法是通用的，他們之間交流沒有障礙。
而非煙臺方法的學員，目前看來就很難了。
滬公網安備31010802001143號
