數字化轉型，正在成為[敏感詞]吸引力的大講堂，所有的企業家都在爭相恐后登臺發表自己的戰略。而工業4.0，這一五六年前紅遍天的企業戰略，則似乎被人拋棄了。

但這種冷落，其實只是一個假象。德國本土的工業4.0工作組正在低調而穩步的推進地基的建設。

美國以PLM為基礎的數字孿生概念，已經以各種方式被廣泛演繹，光彩照人的時候，德國則采用穩扎穩打的方式，從設備入手，圍繞著機器的互聯互通而做足功課。但對比其他國家產業界的調門，德國工業4.0工作組則一直像是地下工兵，意欲打通地下隧道的工程奇跡往往無人問津。工業4.0工作組已經推動7年的資產管理殼AAS（Asset Administration Shell）——一種將世界折疊在一個螺殼里的藝術，正在露出健壯的輪廓，就像是雕塑家即將塑形的思考者雕像。管理殼，簡單說就是給一臺機器，或者一只機械手，更小的如一個軸承，建立一個數字身份證。德國人把這個看成數字孿生的一種等價物。這意味著，每臺機器都將穿上可通訊的盔甲，就像《博物館奇妙夜》的晚上，所有的物體，全部復活。管理殼激活了它們，數字化工業世界里的沙盤，正在緊鑼密鼓推演之中。

工業4.0屠龍刀，即將煉成。

一切要素數字化。

這就是工業4.0所要追逐的目標。無論是產品設計研發，還是工藝，或者生產運行，和智能產品，全部用一套數據流，從頭走到尾。這個一開始就令人驚嘆的野心，正在走向可能性。管理殼，就是這個野心的宇宙爆炸起點，從這里看過去，一切宇宙的時間和空間都是從這里膨脹出去的。

資產管理殼AAS可以理解為工業4.0模型標準體系的總稱，它由若干套子模型標準和一套總體模型規范形成。這些子模型，就是構建數字模型體系的樹根，而它們也絕非空穴來風，都是選自各自領域中[敏感詞]代表性的標準，然后進行適配性改造。

管理殼，正在為每一個部件，建立詳細的畫像；還要配上通訊協議。實際上，它是正在為未來所有的機器互聯、互操作做好準備。

圖1 管理殼的形態

但管理殼，遠遠比一個數字馬甲要復雜。它并非只是給機器穿上一件數字外衣。

設想一下沒有萬維網的時代。圖片、word、表格都已經廣泛存在。但它們如何共享？它只能你傳給我傳給它，非常有限的傳播。

于是網頁出現了，它采用HTML格式，可以將表格、圖片、文本等資源，通過一系列網址(URI)獲取。所有的人，只要打開這個網頁，就可以看到同樣的內容——準確無誤地再現。

可以將管理殼理解成一個網址，在這上面，電機、機器人、機床，或者物料，都被網絡化、資源化了，從而可以在管理殼上，自由瀏覽和下載。

如果說互聯網是為人們共享網頁而生，那么管理殼就是為機器建立共享主頁而生。有了管理殼，機器之間將可以輕松地完成通訊。

作為出口大國，德國深知與全球貿易接軌的必要性。因此德國開發了eCl@ss分類系統。它采用了面向對象的設計理念，可以組合出具有唯一性的產品類別、關鍵字代碼和產品描述。這也是目前唯一通過ISO/IEC標準認證的產品分類格式。

作為供應商和客戶之間信息交換的標準，eCl@ss采用了四級目錄結構，關鍵字涉及到12000個術語。它包含了大約3.8萬種產品分類和1.6萬種產品標簽，基本上囊括了目前所有在使用的產品和服務。eCl@ss目前逐漸在工業、商業、食品和服務等領域被廣泛使用。尤其是在德系汽車工業中，大部分零部件產品基本都使用eCl@ss分類系統來進行管理和采購。

eCl@ss簡化了在電子商務領域內的產品數據應用，使得從供應鏈一開始的采購，訂貨到最終結算的所有流程中均有一致性的產品電子規范。有著如此龐大的連接能力，這意味物料、機器已經建立起天然的聯系。那么如何讓eCl@ss的顆粒度足夠精細，以至于可以達到相互通訊的地步？

eCl@ss就像是一個工業詞典，讓資產管理殼AAS找到了產品分類依據。它應用廣泛，為管理殼的各種模型提供了一致性的語義標簽。所有人的用語，都需要到《新華字典》里找出來，于是大家說法一致。凡是《新華字典》里沒有，都是火星語。工廠里不接受火星語。eCl@ss就是工廠里的新華字典。

圖2 eClass形成了規范的語義

于是，德國工業4.0平臺，跟德國電氣協會ZVEI，以及eCl@ss標準組織通力合作，使eCl@ss用戶可以將其中的要素，快速標準化，形成資產管理外殼身上的一段胎記，或者一塊基因片段。它會自我表達，自己是誰。

eCl@ss作為采購環節中最常用的分類，終于可以發揮更大的作用。eClass就是一個文件，但沒有搜索能力。也沒有上網能力。一個圖片如果不被嵌入到HTML中，那就無法通過3W被查找到。同理，借助AAS的網絡化能力，第三方用戶或系統，就能通過網絡查找到相應的eCl@ss資源供。

同時，隨著工業4.0計劃的推動下，eCl@ss開始進入到工藝設計系統(如AutomationML)以及自動化系統中（如OPC UA）：在工藝設計階段，eCl@ss可作為機床加工件/倉儲自動化貨柜的規格數據輸入，而在自動化系統中，eCl@ss則可為機器人/質檢系統提供一系列產品空間相關的數據。

AAS，激活了eCl@ss的能力。不過，它們基本上是同一撥成員，一起推動工業4.0的企業推手。 

如何用工程數據，描述一個工廠？如何將兩條皮帶之間的距離，告訴打算從中間闖過的AGV小車？六個機器人協同工作時，如何記錄它在空間中的軌跡，不至于相互碰撞？

這意味著，在生產線上，需要有一種語言，描述工廠里的空間關系、控制邏輯。

AutomationML語言（Automation Markup Language），正是這種面向工廠對象的語言。它可以用形式化的描述方式，將工廠里面鍋碗瓢盆的瑣碎，從產品、物料、裝備或者加工過程，全部描繪出來。AutomationML也可以理解成一種構建工廠三維地圖的語言，它可以將一個工廠或者產線，進行數字化重構。在這種語言的描述下，真實的工廠，通過語言的傳遞變成了一個虛擬工廠。當然這只是一個模型。而大量仿真、計算軟件，就可以在這個模型上開始啟動，各自操起家伙，驅動不同的鍋碗瓢盆。

作為一種基于XML的描述語言，無論是管道工程、電氣設計、PLC編程、機器人編程等，都可以加入進去。實際上，AutomationML就是要解決的是這些不同工程要素之間的信息標準化，如機器人、AGV等對象之間的信息交換策略。

簡單說，AutomationML就是語言，一種圖形化、低代碼的建模語言，建模方便，它是自動化系統參數的輸入。

圖3 離線與在線的綜合

現在，管理殼AAS，已經將它集成在內，從而為AAS確立未來調用時候的相互邏輯關系。

這其中AutomationML可以兼容3D模型，這一點非常重要。在設計、仿真等環節，存在大量3D 模型的格式。這些CAD一般是以中立性的STEP或者IGES格式，也有西門子所管控的JT格式。但是要將這些模型，變成工廠的描述方案，則還需要一種標準。作為3D立體幾何模型的XML描述方案，最早源自索尼游戲開發的CollaDA格式，被AutomationML所采納。實際上在機器人調用幾何空間和動態軌跡的時候，就是采用了CollaDA格式。

還有另外一種軟件，正在進入這個陣地。那就是計算機輔助制造軟件CAM軟件。它正在從有限的數控機床，快速進入機器人行業，從而改變機器人現場示教編程的低效。在很多場合，一臺機器人在現場等待編程的時間，能夠占到90%以上。這意味著一臺機器人90%的時間都在睡覺。而這種示教機器人的惰性，正在被CAM的離線編程逐步所取代。既然CAM能夠完成機器人的路徑規劃，如果進一步拓展，它當然可以繼續指揮AGV車、指揮物料的行走，再加上它最擅長的機床，那么它會更好地對產線設備進行路徑協同。這個時候，它就不再像以前那樣只輸出G代碼供機床使用；而是可以借助AutomationML語言，輸出XML格式，從而真正建立產線上各臺機器行動軌跡的大仿真。

管理殼，正在跟CAM/CAPP等工藝設計軟件，建立更多的連接。這是屬于管理殼的巨大勝利。也使得數字化車間，將發生更大的軟件驅動的景象。

當現場設備需要協作時，它們應該采用何種通訊協議與工程建模方法？如何實現二者的可識別性，進而完成工業互聯網最重要的屬性：互操作。OPC UA就是抱著這樣的雄心而出現。它不僅統一了通訊協議框架，而且也使得各個設備有著相同的信息模型。

OPC UA天生是一種軟件化思維，這其中就包含了標準化、簡單化等原則。這跟設備現場OT界的私有化、多樣性、非標是完全不一樣的。可以說，工廠里各個設備都可以看成自有江湖的俠客，相互不通氣，每臺設備說的都是江湖黑話。而OPC UA則致力于將標準化，引入到設備層。OPC UA的引入，可以有效支持語義互操作，它可以承載各種語義模型，而且提供了強大的通訊協議接口。

如果說AutomationML提供了描述工廠對象的描述語言，那么OPC UA就是一種基于對象的協同框架。

在裝備及產線層面，已有眾多系統對OPC UA模型與通訊接口進行了支持，其中包括離散行業的機器人、機床、3D打印機等；在流程與能源行業，多家DCS系統支持OPC UA通訊協議及信息模型。同時，隨著機器/產線與工藝設計、計劃系統的深度融合，OPC UA也在積極地制定與AutomationML（工藝設計格式）、ISA 95（生產運營系統）相兼容的配套規范。

可以看到OPC UA已在近幾年取得了不錯的成績，它正在頑強地向下滲透，刺進黑暗的設備黑盒子。在此過程中，德國機械設備制造學會VDMA給予了大力的支持，它在有計劃地將各種機械設備分門別類地進行信息建模指南。

圖4 VDMA機械類別與OPC UA滲透率

VDMA，為這些類別都做了OPC UA的模型。工程設備、自動化設備，都變成規范化的設備模型。相當于可以這些規范，可以做系統集成和功能調整。如讀卡器RFID，設定有幾個指令。開始掃描、一直掃描（是否有RFID靠近）等。而機器視覺，則有拍照、旋轉、放大、縮小等指令，全部規范化。這些指令，都可以自由拖拽。這意味著，一個現場技術工人，就可以簡單使用復雜設備，給機器編程。原來很復雜的自動化開發工作，就可以傻瓜化。

想一想，操作大疆無人機的時候，只需要拖拽，就可以實現一系列飛行運動。OPC UA的信息建模，就是為了使得“編程平民化”。

當人們抱怨年輕人不肯下工廠的時候，卻從來未曾想過這些工廠陳舊的操作界面會嚇跑年輕人。這些設備操作的理念，基本是一百多年留下來的遺產。這期間，機械化、自動化和信息化，不斷更新，但勞動者都需要做出各種復雜的動作才能應付。而未來的車間，一定都是界面化操作。這才是迎接90后成為工廠主力的最好禮物。這些云原生的數字居民，一開始就是一個“屏生活”的時代：他們只學會了使用指尖來敲打鍵盤或者觸摸顯示屏。只有工廠里重現“屏操作”這樣的顛覆性工作場景，年輕人才能真正下得車間。這意味著藍領、白領的工作界限正在模糊，操作人員就是編程人員，編程人員就在現場。沒有足夠的底層信息建模，調整工藝的難度和工作量是不可想象的，人們不得不返回辦公桌去操作計算機。但這樣的時代，終將過去。

當我們滿心歡喜地迎接數字化工廠的時候，千萬不要忘記迎接云原生的數字居民也進入了工廠。一臺機器、一個工廠被操作的界面至關重要，它只屬于指尖操作。

那么資產管理殼，是如何進行傳遞的？它必須在工廠里面最通用的格式中，找到一種出口。這一點它選擇了XML和JSON作為輸出格式。這兩個格式，在IT界應用廣泛，而在制造系統中的IT系統，應用非常多。無論是ERP或者MES，數據庫的數據導出來的都是XML或者JSON格式，描述一個工單、人員、成本等。

而管理殼AAS的語言格式，則完全支持XML和JSON的表達方式，于是世界看上去可以統一起來了。管理殼可以作為一種AASX格式進行對外輸出。這個aasx文件是開放XML格式，可以自由下載和傳輸，而且可以集成到各種服務。更重要的是，管理殼還可以作為 REST API提供，從而提供一種設備無關的讀取特征。

IBM從2015年就一直在推一種API（應用程序編程接口）經濟，它的意思是各種能力都要網絡資源化，并可借助API接口供大家相互調用，并最終實現各項能力的組合。實際上，IBM發明了一種RestAPI的格式，它跟終端設備無關，因此各種數據和功能模塊，都可以在設備終端自由調用。

德國工業4.0工作組顯然吸收了IBM的想法。它認為，首先可以將一個管理殼通過文件包的方式發給另外一方，另外一方打開后重新抽取使用。但是，這是一種最原始、最傳統的管理殼內容的使用方式。進一步，可以按照IBM所定義的方式來，那就是機器也可以是API經濟的一部分。這種情況下，可以通過API調用一個管理殼，實現復雜信息的交換。

圖5 管理殼交互信息的方式（中間部分為IBM的API經濟）

但德國人更前進了一步。它甚至認為API經濟，仍然是一種被動的方式。如果是用管理殼，則可以實現主動交互的多對多的方式，機器之間的訪問，可以變得更加自主化。

圖6 主動型管理殼的信息交互

這三種不同的借用管理殼交換信息的方式，難免會使人們意識到，每個機器都可能成為一個話癆，未來工廠的機器之間，將有著說不完的話。這實際正是德國工業4.0的2030愿景：自治、互操作性和可持續發展。要做到機器自治，它們之間必然要開口說話——希望它們不會因為出現故障而相互謾罵，或者機器罵人。

至此，可以看到，管理殼動用了四大支柱，來構建一個可彼此交互的智能機器世界。

圖7 管理殼的四大護法金剛

不同方言的人要說話，必須先確立基準。而機器互聯，則需要統一的語言。資產管理殼，吸收了四塊不同領域的成果，從而使得“機器都說普通話”大大向前邁進了一步。

第三方的管理殼服務商已經行動起來。德國一家Xitaos公司，就是將管理殼看成是一個“數據連接器”，或者是一個數字空間與物理空間的陰陽交匯的交叉點。不妨說，管理外殼是“數字孿生”的外在軀殼。這使得數字孿生，可以成為一種類似PDF格式，跨設備自由傳播，而最后只需要一個PDF閱讀器。工廠傳遞管理殼，人們可以像使用PDF一樣，來使用數字孿生。只做一個管理殼領域的PDF閱讀器，這正是Xitaos的工作。

圖8 管理殼的流程

它為德國威騰斯坦提供了管理殼的服務。后者是一家機電一體化驅動系統，包括伺服齒輪箱、伺服電機、伺服變頻器等。

圖9 SAP的數據被重新定向成應用程序

Xitaos為威騰斯坦提供全流程的設備備件與維護管理的管理殼服務。它最大的難點在于數據的異構性，多元數據要聚合在一起，而且最終顯示要完全獨立于終端設備。

在這個場景中，SAP數據庫將相關產品的同步到云中的“SAP Drop”中。Xitaos通過ETL（提取轉換加載）的加工過程，形成一個變速箱的管理殼。這意味著，具有SAP特征的物料，被映射到eCl@ss目錄中一個國際登記數據編碼(IRDI）。憑借清晰唯一的語義，每個人都可以清楚地讀取。進一步，它通過亞馬遜上的AAS平臺，轉換為符合規范的模型格式，并在云端中通過管理殼轉換器進行呈現。它提供了標準的REST API接口，提供組件的信息。對于用戶而言，借助任何工業互聯網平臺，通過REST API很容易查詢到變速箱的生產日期、異地交貨和質量追溯信息。

以前產品規格都是在電腦里，提供文件但無法讀取。而現在，各種經過過的規范性文件，都可以借助于管理殼得以匯聚并且可以激活。

這個案例展示了一個開始，但如果將這個齒輪箱的查詢，看做是管理殼所呈現的一種能力。那么在工業互聯網上，有許多“能力”是可以共享的。把這些“能力”封裝成API，放到API Marketplace上去。這些API可以被調用者訂閱，或者組合，編排成全新的應用能力。而管理殼則始終是底層不可或缺的信息，它們就像是一個物體的原子一樣，構成了最基本的粒子信息。

那么，攜帶了原子級顆粒度信息的管理殼，將會呈現出何種更大的能力？

管理殼，把信息模型，通訊協議、工廠場景、數據格式等這些要素全部串起來。這樣看起來，它更像是一種基于HTML語言的www網站，通過HTTP就可以找到各種資源。就像每一段文字、圖片都有一個獨立地址，每一種機器、資源，都可以通過管理殼進行獨立訪問、獲取和傳遞。

有了這些準備，可以看看未來如何實現基于訂單驅動的多方協同生產。

德國智能工廠聯盟正在將協同制造，引入異地來實現。在一條示范產線上，它由三處不同的地點聯合完成，共同制造一輛可定制化的卡車。合約制造角色就是凱澤斯勞滕大學的機床與控制部，它負責對拖車油箱上部的結構進行銑削。盡管三個地點的三臺機器都具備銑削功能，但一套程序裝上去，可以實現不同的質量加工等級，加工速度也不一樣。這意味著，不同地點的機器，完全可以通過遠程來實現自選配置。對于其中一個廠家，它并不需要為自己的機床購買一套CAM軟件，或者也不需要自己的人員對CAM軟件進行路徑編程（這類人員一般都是很昂貴的），可以通過第三方提供CAM遠程服務，用AutomationML的描述格式，下載在本地的管理殼AAS之中。然后跟它的3D打印機進行連接。如果不需要很高的精度，就可以提供低價服務。反之，高價格就可以提供高精度。這意味著自主化的多智能體系可以相互溝通，以確定哪一個是根據客戶規格生產產品的最佳選擇。

那么，它們如何實現傳遞？

圖10 管理殼的供給側和消費側

可以想象，當不同的工廠都有自己的管理殼的時候，這些連接起來的管理殼，將會相互借力。一個工廠再也不需要擁有完整的能力，它可以借助其他廠商的服務，補齊自己所缺的一塊能力，就可以完成一個訂單的加工。

圖11 跨工廠的訂單驅動，得益于AAS的連接

以前都是私有通訊協議，組態會非常復雜。而現在由于各種設備，已經采用OPC UA的方式得以打通，設備適配就會變得很容易。對于工業廠商，就不需要應對各種復雜的定制化接口，IT和OT系統維護能力將會大幅度降低。這對于大廠，自然是一個好消息。

整個世界的IT與OT系統正在悄悄發生變化。一個公司的數字化系統要么足夠強大，強大到能夠向外溢出，為其他廠家實現能力復制；要么能力偏弱，這個時候它需要借助外力。數字化進程慢的公司，或許就考慮將部分數字化系統外包。

聯想正在致力于“內生外化”的服務能力，將自己的IT系統做成標準化，對外進行服務。為了面對內部7萬多名員工、35個工廠、近6000家供應商，它自己開發的混合云XCloud已經應對自如。而這種能力，同樣受到一個鋰電池大廠的青睞，它需要構建這樣的面向全球各個基地的混合云。IT系統正在走向微服務化，從而通過組合調動的方式，對外提供服務。這種方式將會使得領先企業的IT系統，越來越容易向外溢出，為其他企業服務。而反過來看，許多用戶工廠，或許將樂于接受 “CIO外包”的模式。

現在隨著管理殼的深入，這種現象也將在OT界——無論是設備端的調試還是維護變得普遍起來。對于小企業，不需要強大的IT能力，也可以沒有PLM軟件。它可以借助于第三方的服務，通過一種能力嵌入的方式，中小企業也能做大企業的事情。

如果深究一步，這是一種即插即產（Plug&Produce）的思路。它的目標是將制造系統分成多個過程模塊，這些模塊可以在生產繼續進行時連接在一起。這樣，就可以在幾分鐘內重新配置制造單元布局，而不是傳統方法中的幾天。從U盤機器，到U盤產線，U盤工廠也就呼之欲出了。

基于熱插拔式產線，或者進一步推進到U盤工廠，才是規模化解決協同制造的關鍵。這背后需要對機器建模有著更加深刻的基礎層的探索，而合手的工具都已經備齊，無論是低代碼編程、61499的建模語言，或者OPC UA語義與通訊、面向對象仿真，還是容器化的微服務和時間敏感網絡。這些工具，并不會自動形成顛覆性的力量；只有底層的語義連接和頭疼的機器建模，才是決定性的支柱。無論是多么優秀的頭腦風暴，都無法把概念之花演繹成樹苗；只有老老實實地把手和腳都插到了沉甸甸臟兮兮的泥土里，智能制造才會有真正的根基。

當人們追逐產線的柔性的時候，只在現場敲釘子、彎金屬是不足以實現的。只有底層連接，才有柔性之王。只有用底層標準將設備武裝起來，才能真正實現U盤工廠的即插即用：這才是智能制造[敏感詞]級的柔性。

為什么德國的資產管理殼AAS是一個非常接地氣的理念，也最有助于智能制造落地？因為它兼顧了老設備的改造。對于新設備，OPC UA直接嵌入，自然不存在舊設備升級的過程。而對于一個老設備，只要加一個插件，實現OPC UA服務，從而可以讓設備在線化、標準化；同時配一個AAS，就可以完成注冊而得以激活。那么這個老設備，就可以參與整個產線的設備互操作。

德國正在醉心于完成智能機器底層標準的主導權，資產管理殼是它最為重要的資產。對于子模型標準，它已經選好了對象，無論是eCl@ss、AutomationML，還是OPC UA。而VDMA則正在將幾十種自動化裝備及工程工具，制定了跟OPC UA配套的規范。這其中包括德國機床協會的機床連接協議UMATI，或者是機器人、3D打印設備都在其中。甚至廚房裝備協會的各類終端設備，如微波爐、冰柜等也在其中。而在設計類軟件中，也在推動eCl@ss分類目錄的使用；同時在產線工藝和物流模擬，大力推動AutomationML的落地。

在云這一層面，得到了微軟云和亞馬遜云的大力支持，在微軟AZURE部署管理殼變得非常容易。它們對于管理殼的云圖書館的建設非常積極。這意味著二者將徹底地進入未來工業云的領域。不知道阿里、華為、騰訊云是否為此做好了準備。沒有底層的根技術標準，上層的云都是同質化的計算能力。

圖12 管理殼上云

法國、日本和韓國，也都分別在工業設計軟件、機器人、機床等方面，參與管理殼的應用。

管理殼最感興趣的就是跟生態有關。艾默生的安沃馳閥島，最近宣布采用了先進電子控制技術AES，從而將閥島變得更加智能化。而且可以接入OPC UA。其實，這樣的門檻從技術角度或許并不高。但如果大家都在介入，那么這件事情就好玩了：生態就是靠著群起而進，才能實現。

如果沒有根部技術，生態就是五顏六色的肥皂泡。只有有人跟著一起玩，才會有所謂的生態。大筆一揮圈一個聯盟，是無法生態化的。沒有底層技術作為連接，又沒有市場蛋糕相互補位，所有的生態聯盟都不過是烏合之眾。

有人玩，才會有生態

如果沒有信息建模，低代碼編程是偽命題。讓“編程平民化”的低代碼正在變得普遍，但這種技術充滿陷阱。如果熱衷于表面上的功能拖拽，那么這仍然是一個應用層面的集成。只要在底層，對設備進行充分建模，并且加載統一的通訊協議，對工廠現場的低代碼編程才是真實的。

如果沒有設備的互操作能力，協同制造是偽命題。誰不喜歡協同制造？但這需要從底層設備的語義連接開始。如果只是致力于將設備的通訊協議連接起來，這充其量只能有限交換數據，而無法進行設備的即插即用。這意味著，現場仍然有大量的調試的工作。目前工業互聯網的語境，不過是粗糙地解決了表面上的通訊連接，這離機器的互操作相去甚遠。工業互聯網當前的框架設計，是無法實現跨車間、跨工廠的機器協同。

如果沒有根部技術，工業互聯網的狂歡就是一場經不起推敲的資本游戲。德國的管理殼技術與標準正在一路下沉——沿途德國制造商各路人馬紛紛加入。2019年一些傳感器廠商如巴魯夫，已經開始將傳感器的IO-link跟AutomationML集成在一起。這也使得資產管理殼，可以一路下沉到傳感層，同時也方便了電氣選型設計、現場通信配置。德國顯然是一個軍團在作戰。德國工業4.0工作組將所有這些各項指標的數字模型標準，稱為工業4.0語言；而能將這一系列標準進行串聯所構成的機器協作，則被稱為工業4.0互操作性(Interoperability)。可以說，自從2015年德國人提出工業4.0的參考框架之后，一直就在圍繞這個框架進行完善和修補。德國人是耐心的建筑師，一直在同一個地基上蓋房子。而中國人則是急性子人挖井，挖幾米就要換地方。德國人還是埋在地里拱土，而中國的智能制造已經開始攫取花葉和果實。今日之短見，來日能收獲的只會是貧瘠。

一花一世界，一樹一菩提。花里如何看到世界，樹中如何找尋菩提？資產管理殼AAS就是此花此樹。不過，德國人這次舉起了屠龍刀，它要統治的是所有機器的江湖。