很多企業開始宣稱“軟件定義自動化”、“軟件定義制造業”。其實，早在2013年，美國著名的媒體連線(Wired)就以更為宏大的敘事制造了“Software Define X”這個詞。當然更早的是斯坦福大學在2006年就提出了“Software Define Network-軟件定義網絡”，然后“軟件定義汽車”等各種概念就出來了，今天人們開始高呼“軟件定義制造”、“軟件定義自動化”。軟件定義是有意義的，因為它的核心要旨在于用軟件來應對變化的世界。
“自動化以后是個吃軟飯的行業”。—覺得這是個好話題，一直試圖去描述這個話題。今天，大家說軟件定義制造、軟件定義自動化，其實，通俗地說，就是我們自動化行業越來越多靠軟件贏得未來的生存。
實際上，自動化早已是一個由RTOS、行業工藝軟件、網絡連接、HMI、AI、標準化如PLCopen構成的軟件系統。而圖1則是在十多年前就繪制的一個關于“軟件價值”體系的描述。
圖1-自動化的軟件價值體系
那個時候，我們繪制這個的核心敘事在于“軟件構成了核心競爭力”—但這個敘事是給用戶來說明，他們的機器中差異化競爭力來自軟件，這里核心在“工藝”。也就是之前我和“工業軟件”群經常談到的一個話題，即，除了看得到那些以產品形式存在的工業軟件，還有大量尚未受到足夠重視的。即，隱藏在嵌入式系統里，每臺機器里的軟件，以及生成這些軟件的軟件。自動化行業里，平臺工具軟件如Automation Studio、Portal、Logix、EcoStructure、TwinCAT等。
之所以軟件定義，是因為VUCA這個詞所描述的世界正在悄然發生，且更加加劇—以消費世界為例，它的各個維度的改變正在給制造業帶來極大的難題—在理想狀態下，企業自然希望通過極致的規模化來攤銷成本，進而獲得極致的成本優勢。如圖2，VUCA帶來了復雜性，需要得到有效的解決，數字化被賦予了重任，這個也就以各種軟件的形式來實現。
圖2-VUCA時代數字化的意義
在一個產品需求更為復雜的時代，讓制造企業，尤其是那些代工企業，他們會必須面對眾多的產品需求，這些需求還特別的碎片化。并且，還需求特別的著急，因為人們習慣了明天就能收到貨，如果是后天就可能放棄購買。
軟件定義制造的不斷演進
運動控制實現產品變化的生產。所以，一種靈活的、可重配置的產線是迫切的需求—這個通過傳統的機械調整，就會非常的慢，且成本高昂。因此，制造業的自動化一直在尋找更為妥善的解決問題的辦法。這樣，就產生了靈活的機器來改變配置，機器的控制+伺服控制就成為了必然的選擇。在30年前，在機器里采用伺服電機，是為了實現更高的加工精度和速度，但在很多機器上，伺服電機并不在同步時工作，而是在機器換單的時候，對機器進行調整。例如，裁切刀的刀輥換成伺服驅動，這樣，裁切尺寸變化的時候僅需參數設置即可執行新的裁切任務—當然，這里的伺服電機本身是作為一個同步軸的，它會跟隨被裁切紙張的尺寸。但是，在印刷機的斜拉版、壓印力調節、機械的機構調節，在瓦楞紙的換刀、書刊膠裝/騎馬訂等場景里，伺服電機僅在需要更換規格時動作。然后不參與同步的電子齒輪、電子凸輪等動作—這里大量伺服電機的使用就是為了靈活的應對產品規格的變化。
同時，為了實現這些機械加工的效率，又實現了連線生產，像飲料的吹灌旋貼，開清棉、長流程的離散制造都在實現這樣的連線，中間更多使用機器人、AGV是為了提高效率。因為，必須把換單造成的那些時間損失都得彌補過來—這個時候就需要通過網絡來把整個機器連接起來，而不是用硬接線的方式來實現啟動同步。通信就成為了實時控制的關鍵一環，而這些機器可以通過這種統一的通信連接實現同步，在軟件層，對這些參數的上下行進行讀寫就成為了機器配置的關鍵。
圖3-連線生產，從印刷到書刊輸出
運動控制的問題是它主要在機器內，例如定位主要解決單點的問題，同步也僅解決多個軸的關系，但它無法解決在機器和機器之間的輸送這個難題。
磁懸浮輸送解決機器-機器間的可定義性
進一步的，人們發現控制主機實現了軟件定義的任務編排，網絡實現了數據流動和交互的接口，但機械的輸送還是個難題—當年，CIMS/FMS這些其實就因為這個原因，無法被有效的運行。因此，才產生了柔性輸送系統，即，現在被稱為磁懸浮輸送的系統，它打通了最后一個難以被“軟件定義”的環節。通過“電-磁”轉換，將傳輸系統轉為可以被軟件定義的“單件流”、“連續流”—這符合精益對于產線的編排需求，因為它可以實現排隊、配合加工等，可以讓物料流動、配合加工成為一個被軟件快速可重配置的形式。這進一步推進了軟件定義制造的可能，如圖3所示。
圖4-運動控制從一維增加到六維
因此，伺服電機、機器人、磁懸浮輸送解決了產線中的局部修改，以及在機器間物料流的解決。
通信-解決協作中的信息流
在軟件層面，人們實現了加工過程的狀態建模來實現生產的重組—用軟件的“編排”來實現生產線的重組。之所以，采用狀態模型，就是因為它可以被邏輯編程。像PackML、JDF、ISA-95、IEC61850、Unimat等垂直行業的規范，就是為了能夠對這些生產過程進行統一的行規設計—這樣就可以快速的參數下發。而新的MTP則是針對自動化系統的統一規范，來實現工廠的管理層任務解析并下發—可以通過OPC UA來實現這些通信的連接與數據的封裝，提供了一個統一的框架。
圖5-PackML協作橫向與縱向的機器聯網
物理建模與AI-解決知識的復用問題
對于制造業，如果每次都要對一個任務進行編程，或者對于一些知識都要重新組織，那么工作量還是很大的。為了把知識進行有效的復用，工程師們就開始想在知識封裝上下點功夫。
在知識的挖掘的幾個典型范式里，人們經常把遠古時代的科學發現定義為人的天賦來實現的。而基于笛卡爾的方法論以及牛頓、萊布尼茲這些偉大科學家在第二個階段，人們開始將物理的公式作為解決問題的思路。而在計算機出現后，這些物理模型的驗算就成為了計算機要去干的事。但是，這種基于物理知識的畢竟是有限的，它需要先驗知識和已有的數據積累，才能更為精準的模型。而這無法滿足越來越復雜的世界對于知識的苛求。那么，新的范式，基于AI就成為了一個必然的選擇。
圖6-MapleSim的張力控制建模與仿真
再進一步，人們又發現這些系統由于過于復雜，且存在很多“不可見的深淵”—即，在復雜的系統里，他們會產生效率無法被最優的問題。因為，復雜系統，它的路徑規劃會形成非常多的組合，這無法被人用公式來計算—因為，這是一個“陷阱”，就是被窩在系統里的能力，它無法被有效的發掘。包括引發生產產品品質的干擾因素，例如相關性的、隨機誤差造成的無法被有效的觀測和梳理。這就使得人們尋求通過“數據驅動的建模”來挖掘這些背后的規律。產生了對人工智能的需求—而人工智能，則又是一個軟件。
軟件的模塊化-實現知識復用
用高級語言封裝算法，且構建出“高內聚、低耦合”的應用模塊，然后讓這些模塊快速重組，來搭建整個機器的應用程序。這個就是要用模塊化的軟件開發來實現—但是，自動化它所面對的機電又是一個高耦合的領域，因此，基于物理建模的方法在計算機出現后就開始被大量使用
圖7-軟件工程的模塊化思想
在軟件工程領域，著名的工程師Fredric在70年代，覺得軟件正在陷入泥潭—后來隨著模塊化技術的普及，軟件的危機在被解決。在制造業同樣如此，人們通過模塊化來實現機器的快速軟件重組。
AIGC編程-讓工程邁入更為靈活的時代
隨著系統的復雜性不斷提高，我們要面對各種各樣的算法、AI分析、界面等，程序會變得越來越復雜。傳統的編程即使是增強模塊化，仍然不夠，因為它的門檻也比較高，尤其是機電工程領域。
AIGC編程就成為了一個潛在的方法，因為，它會繼續使用原有的知識、模塊來為工程師快速搭建架構，進行“按需”軟件設計。盡管它目前尚不是很完善，這里，尤其是指制造領域的機器和產下，但，如果能夠定義統一的規范進行約束，那么，相信它的準度、深度進一步發展。其可用性會更高。
據此發展下去，軟件未來自動生成軟件，自動化工程師則將成為一個顧問，或者一個“橋梁”，它連接用戶端模糊、不確切的需求，以及組織復雜的機電工藝之間的“關聯”與“架構”。即，未來需要的是機電、工藝系統的“架構師”，而不是“Coder”。
基于建模的開發與模型交互
但是，這個還不夠，畢竟，在機電領域里，不如純軟件領域那么方便。太過于碎片化，因此，采用物理仿真的自動代碼生成也成為了一種辦法-Mathworks就在2008年推出了為自動化領域的工程師們開發的SimulinkPLC,通過C代碼的生成來實現模塊的生成。Modelica組織則試圖在不同的機械軟件間進行模型的數據互換，開發了FMU/FMI接口，這個不僅在純的CAD/CAE軟件之間，也在物理建模和自動化軟件間進行了這樣的接口。當然，后續OPC UA會接續這個模型，使得其更為廣泛的連接到不僅基于模型工程（MBE）的領域，如云端系統、垂直領域的軟件之間的接口數據統一。
因此，我們可以看到，要實現“軟件定義制造”。想吃上軟飯，這個鏈條里的基礎操作系統、硬件的嵌入式軟件、實時網絡到多業務流數據的匯集、行業規范、數字化設計軟件、開發工具、AI、云端，這一切都需要進行有效的組織，形成有機整體，這個事情才能真正被實現。
軟件定義制造的未來的難題？
軟件定義制造，就目前看，還有很多現實的難題需要突破。真正想吃上軟飯，還是需要解決一些關鍵的問題，并非僅僅技術的。
誰為這些軟件買單？
軟件必須成為一種有效的盈利模式，硬件可以統一設計制造，由OEM/ODM廠商來代工生產。而每個企業的競爭力將由是否能夠解決特定問題，實現以軟件、服務為主的盈利。
要真正實現“軟件定義制造”，就必須確定軟件的價值，并將軟件成為一種嚴格封裝的，知識產權邊界明晰的產品。且，能夠獨立的運行在跨平臺的系統上。
要實現真正的軟件定義制造，有幾個方面必須做到：
①軟件的獨立性，為了解決這個問題，在IT業界采用了包括容器技術、Docker等各種方案，這些方案對于IT系統架構在統一的硬件上而言，相對比較容易。因為，純軟件行業，他們的規范性是足夠的—而在制造業，這個軟件的標準實現就由于過于強耦合的硬件、操作系統，而難以真正做到隔離。
因此，未來的自動化系統，它應該是操作系統更為通用，例如采用Linux，RT-Linux，且實現與開發環境的剝離。應用軟件可以脫離廠商的硬件，在通用的硬件上來實現部署，例如你可以把它部署在嵌入式系統，也可以在PC、服務器、云端。
②軟件必須是可以被獨立銷售的
這個環境似乎目前還不能看到，只是有些端倪，畢竟，長期依靠硬件吃飯的行業，真的把軟件剝離出來，會傷害既得利益者的盈利能力。這是IT業界進入制造業一直試圖去顛覆的，盡管這個步伐看上去很難。這也是制造業的特殊環境—因為，可靠性、穩定性的需求是基礎需求。
但是，這并非不可完全解決，即，純粹的硬件廠商+IT的能力，因此，這個時候，自動化和這些試圖進入制造現場進行顛覆的人就產生了沖突。那么，這就會看誰更能堅決的帶來商業價值。但，作為自動化領域的廠商必須去開放的接受這個事實，依靠硬件或軟硬結合的方式肯定是個能吃5-10年的，至于再過10年后，會發展成什么樣，就不好說了。
③統一標準與規范的建立
為了實現各個層級的軟件的南北向數據、東西向數據的打通，統一規范是必須的。這個規范究竟是什么？是OPC UA嗎？目前這是個選擇，但也未必就是唯一的選擇，當然，OPC UA可以把各種選擇都給納入它的框架之下。因為，它與IT那些標準規范具有先天的工程思維。
可能制造業會不同，相對比較嚴格的—現在的很多標準尚未被有效的使用，就是因為在實際的“智能連接”上需求尚未真正達到一致。因此，很多概念僅在前沿的企業那里會看到雛形，或者試驗型產線。
在各個軟件間形成快速的接口數據交互、以及程序間的交互—就像MTP，如果自動化廠商都遵循MTP，那么，當產線上的數據進行了修改，它也可以被下發給不同的PLC，并且，寫入變量中，或自動讀取。如果AIGC編程也能按照這個接口標準來定義對象、數據格式，那么是否意味著，即使是它生成的程序，也可以被PLC直接讀取呢？這個約束機制，本身就是一個探索過程，但，用“規則”約束自動編程系統。在可行性上可以進行探索—軟件自動構造的方法，既可以通過系統建模、語言建模、軟件接口、模型接口—至于那種方法更好，可能通過多個接口和機制的聯合行動，大家也是可以做到最終的交互。
圖8-MTP用于在氫電解槽系統里協作
在圖這個架構里，電解槽相關的水處理、變流器、壓縮機、電解槽、干燥系統、存儲系統之間會形成一個整體。當系統需要更新數據和升級配方，則會統一的數據下發，以實現遠程的升級。
這些工具的最佳組合—會被探索出來，例如，在通信接口方面，模型交互方面，其實，不必完全構造，而是讓系統學會各個接口規范，并讓程序按照這個接口來實現—反倒，這個可能對于推理強的AI更容易掌控局面。因為，我們要做的太復雜的時候，人反倒是難以實現的—但，人可以為機器提供校驗，它還會學會你的校驗過程。
④自動化還得是個咨詢公司
前面提到，如果我們希望做到軟件定義制造，而又有AIGC編程、模型交互、模塊化設計，凡此種種。我們也說了，這個能夠讓機器和系統更快的自動構造。而這個時候，你會發現，最為重要的不再是編程，設計，而是“架構”，即，用戶的需求到實現之間的這個橋梁。
將用戶需求翻譯為機器可實現，這并非易事。因為，人的需求往往是模糊，不確定的，且存在隱藏的、沒有被發現的—甚至提出需求的人自己也不清楚。
那么，這個時候，其實特別需要具有“咨詢顧問”能力的工程師來解決這個問題。即，它能夠梳理需求的邏輯，并能對需求進行精確的定位，并且，能夠關聯機械設計、電氣、工藝、AI分析之間的關系，它能夠把它表達為Prompt去給AI系統。讓它去實現，然后還能給它的實現進行修正。
這可能不是一個工程師能完成的，而是一個由多個人和跨企業專家構成的團隊，但這個團隊需要具有咨詢顧問的提問、分析能力—它不止于跨學科，還跨職能去實現項目的組織。
⑤知識產權保護
要想真正實現軟件定義制造，那么，在知識產權保護方面，就必須有非常強的機制。當然，這種機制不一定是法律的機制，也可以是技術的實現方法，配合法律法規。
這里也會牽扯到非常多的權利問題，即，數據權屬問題、知識的歸屬，以及復制的權限。包括信息安全保護機制確保數據資產的安全。
所以，這個吃軟飯，能成為一種穩定的飯票，還需要很長的時間發展。從目前來看，這個方向有端倪，但尚未到真正意義“軟件定義制造”。
作者：宋振華
