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