【編者按】基礎的模型問題是工業(yè)互聯(lián)網繞不開的話題，必須把工業(yè)原有的基礎模型大量測試的驗證道路走完，否則就無法真正的對制造業(yè)有什么大的幫助。

我們互聯(lián)的標準是什么?

世界經濟論壇在2014年的工業(yè)互聯(lián)網推進障礙調研中發(fā)現(xiàn)第一大障礙是“缺乏互操作標準”，這個問題比較典型，按照我們反復強調的，如果你沒有數(shù)據(jù)的統(tǒng)一規(guī)范與標準，即OPC UA的信息建模，那么就意味著大量的數(shù)據(jù)讀寫操作和工程量投入，那么，第一步數(shù)據(jù)連接的問題將會變得沒有“經濟性”，因此，現(xiàn)在的實際情況就是，很多工業(yè)互聯(lián)網公司的本質可能更多在于“導表”，這是個體力活，其實，你聽上去高大上，但是實際上是個沒有技術含量的活，我必須強調的是，沒有OPC UA肯定可以實現(xiàn)數(shù)據(jù)連接，沒有人說必須、一定要采用OPC UA這樣的規(guī)范與標準，但是，如同在之前的文章中所描述，OPC UA會是一個必然的道路，就是說，如果你不想走OPC UA這條路，但是，按照最經濟有效的設計道路走的話，你可能最終還是會設計成OPC UA這個樣子，你可以叫自己的標準與規(guī)范，這個沒所謂。

因為如果不解決經濟性問題，現(xiàn)在大量的人力投入在數(shù)據(jù)連接、驅動、接口的調試上，想想人工成本，尤其是來自IT的工程師成本，這肯定是場災難。

因此，我特別擔心他們何時盈利的問題，我想目前國內有200多個所謂的工業(yè)互聯(lián)網平臺，我實在擔心他們的盈利能力，因為，傳統(tǒng)的自動化廠商其實都有穩(wěn)定的盈利模式，包括像Microsoft、華為這樣的軟件、通信平臺提供者，目前的工業(yè)互聯(lián)網公司其實都沒有所謂的技術，其實實在現(xiàn)有這些大廠的基礎上“攢”的一個平臺—畢竟，你以為平臺真的那么容易開發(fā)啊?

借助于開放的IT技術來攢一個所謂的工業(yè)互聯(lián)網平臺這件事情，OT的人都可以干，我覺得我的確比較委婉，按照戴老師的話就是，其實制造業(yè)沒有互聯(lián)網平臺照樣在運行，因此，就目前的生存而言，對于制造企業(yè)而言，可能沒有工業(yè)互聯(lián)網倒沒有問題—除非如工業(yè)互聯(lián)網平臺們所說的能夠帶來生產效率的真實的提升和優(yōu)化。

關于標準的這個疑問來自于似乎很多工業(yè)互聯(lián)網平臺從業(yè)者對工業(yè)的通信了解非常少，究竟有多少現(xiàn)場總線這個問題不斷被問及，而至于制定規(guī)范，OPC UA ,TSN也少有人了解，因此，我想沒有通信規(guī)范與標準，這些平臺和別人怎么交互，多個工業(yè)互聯(lián)網平臺之間怎么交互?

有沒有自己的開發(fā)工具?

對于所謂的“平臺”，我一直比較困惑，因為，我一直覺得“平臺”這個東西必須是一個完整的架構才能稱之為平臺，工業(yè)互聯(lián)網，為什么就會有一個平臺呢?云，那就是云的架構，一般由已有的技術提供商來提供，一個平臺是不是應該包括以下幾個部分啊?

(1)運行時(Runtime)，參考Linux、Windows的Kernal，你是否需要一個核心的任務調度機制啊?這個當然我不懂，不過，PLC都是有任務調度的，如VxWorks的實時控制循環(huán)，通信調度。

當然了，對于工業(yè)互聯(lián)網這些廠商用的什么runtime我不了解—不過，既然做工業(yè)，它就必須考慮“實時”調度問題，這跟非工業(yè)應用場景不同，因為非工業(yè)場景，你的操作系統(tǒng)可以是非實時的系統(tǒng)。

(2)開發(fā)環(huán)境，無論是Microsoft.net還是Java，或者像貝加萊的Automation Studio、Siemens 的Portal，它總是需要一個開發(fā)環(huán)境，這個環(huán)境能夠對不同的開發(fā)庫進行集成，并且對不同的底層通信開發(fā)驅動可以被調用，我不大懂，工業(yè)互聯(lián)網的開發(fā)環(huán)境是什么?

(3)開發(fā)工具，無論是C/C++,Java,Python或者其它任何語言，你用什么開發(fā)，那你就會牽扯到不同的API，那么這些平臺與這些開發(fā)工具之間是怎么集成的?

如果這么多公司號稱有“平臺”，那我想知道目前這些平臺里的運行時、開發(fā)環(huán)境、開發(fā)工具都是些什么呢?

如果工業(yè)互聯(lián)網平臺的企業(yè)不說要替代現(xiàn)有的制造業(yè)運行架構，我們當然不會關心這個問題，但是，有些工業(yè)互聯(lián)網平臺號稱要替代現(xiàn)有的架構，我想這個問題就有討論的必要了，就是你目前的操作系統(tǒng)是否具有實時能力?你的網絡—很多對現(xiàn)場總線都不是很了解的人怎么知道數(shù)據(jù)怎么連接呢?并且很多人對現(xiàn)場總線的了解基本上仍然停留在Modbus和CAN總線的年代—看了很多他們做的演講稿，談到底層設備往往就說Modbus和CAN，其實，現(xiàn)在工業(yè)網絡主體是實時以太網，至于OPC UA over TSN，連自動化圈里目前能講清楚并投入研發(fā)應用的還不多，我特別想知道的就是難道我不懂人家的牛，如果你號稱“平臺”且想要顛覆現(xiàn)在的架構，我就特別想了解如何顛覆的?好讓我們知道人生應該走向何方。

另外一個就是覺得似乎大部分工業(yè)互聯(lián)網平臺的人對PLC的了解似乎仍然停留在20年前的“邏輯”控制時代，其實今天工業(yè)里的控制器早已不是過去的“可編程邏輯控制器”那么簡單了，現(xiàn)在的PLC可以玩什么呢?

-->機器學習：No Problem，其實，機器學習就是算法問題，那么這個算法是運行在你的工業(yè)互聯(lián)網平臺上，還是運行在PLC上，你以為PLC不能運行算法，那可能你對今天的PLC了解太少，PLC完全可以跑個機器學習算法，什么GA、貝葉斯這些都可以玩，因為，基于VxWorks、RTOS架構下的PLC可以支持高級語言編程，在1992年貝加萊推出的黑色系列當年運行的就是PSOS+的定性分時多任務操作系統(tǒng)，那個年代就可以用BASIC編程了，現(xiàn)在，你想C/C++,Python其實都可以。

-->復雜運動控制：在20年前這個事情也可以做的，控制器的架構之前是采用PLC+專用運動控制模塊，在90年代就有這樣的架構，而運動控制在本質上是數(shù)學問題，CNC是插補算法，而機器人則是齊次變換庫，那么這些數(shù)學問題運行在一個強大的硬件處理器上和RTOS上同樣是可以的。

-->機器人：機器人通常也是采用嵌入式操作系統(tǒng)+Windows兩個，現(xiàn)在的控制器都可以實現(xiàn)這個。

-->回路調節(jié)—回路調節(jié)也在于算法。

歸根結底一句話，工業(yè)控制的本質是數(shù)學，無論是哥柯諾莫夫的系統(tǒng)論—奠定了今天人工智能的各種數(shù)學模型，維納的控制論、香農的信息論，其實都是數(shù)學問題，工業(yè)領域都是數(shù)學問題，這個數(shù)學問題運行在PLC上、PC上還是云上?這個不重要，用什么來做這件事情是由經濟性來決定的。

但是，換個角度，自動化卻不斷的在采用IT技術來擴展自身，包括以太網的使用、Web技術在控制器中的應用、新的FPGA芯片、MATLAB/Simulink、FMU/FMI都往自動化平臺上集成，以擴展自身的能力，因此，好像工業(yè)互聯(lián)網的總想顛覆制造業(yè)，但是，工業(yè)的人似乎沒有想過要顛覆誰。

有多少模型的積累?

很多工業(yè)互聯(lián)網平臺都覺得“數(shù)字孿生”這個詞可有意思了，覺得人工智能可有前途了，但是，我覺得可能他們忽視了幾個問題：

(1)我們有模型嗎?

在一個通過“測繪”或“逆向工程”而發(fā)展了很多年基礎上的制造業(yè)，原始性的設計實際上是非常少的，因為原創(chuàng)性設計需要建模，并且去測試驗證，而我們簡化了這個最為耗費研發(fā)投入的過程，直接測繪了已經被驗證的設計，這個的確降低了成本，也縮短了研發(fā)周期，但是，這也使得我們沒有基礎的模型，知其然不知其所以然—知道“What”，卻不知道“Why”—這個模型基礎弱，就會導致所有的學習算法必須“空轉”，無法去驗證。

2018年上海有兩家公司分別因為侵權而賠付達索1000萬，他們不愿意買正版的軟件平臺來用，認為它太貴，但是，實際上，這些建模仿真軟件設計目的都是降低研發(fā)風險的，如果你真的按照原創(chuàng)設計，構建物理模型、制作原型、測試、修改的循環(huán)，那么真正的研發(fā)就極其燒錢，這個時候你發(fā)現(xiàn)用建模仿真是可以大幅降低成本的，你一定會覺得買這些正版的軟件是非常合算的，我想他們不愿意買的原因是他們僅僅是為了“繪圖”的功能—因為供應鏈需要采用這個軟件的圖紙。

在一個沒有模型基礎上，你如何實現(xiàn)數(shù)字孿生?如何進行機器學習?

有些人覺得機器學習可以解決很多問題，還打算用機器學習來代替現(xiàn)有的控制模型-->按照之前柴院士有一次聊到的話題，你在互聯(lián)網應用場景里的學習很多都是大數(shù)據(jù)小問題，但是，在工業(yè)里是小數(shù)據(jù)，大問題，并且可解釋性成為了障礙—你說這樣學習可以，但，能解釋嗎?它有什么潛在的風險嗎?如果說0.1%的不確定，那么對工業(yè)而言，也是不可接受的。

很多人號稱要通過學習來改變工業(yè)現(xiàn)有的模式，你必須明白一點“傳統(tǒng)”那些模型實際上是“最經濟”的，學習模型的成本是比較高的，而且，機器學習模型主要解決“非線性”部分的，即，觀測器對現(xiàn)有的控制模型觀測中，無法求導的那部分任務進行學習—因此在單個控制系統(tǒng)已經達到局部最優(yōu)的情況下，工業(yè)里一直在尋找更為復雜的動態(tài)下的最優(yōu)，以前這個是算力不足，但是，現(xiàn)在的芯片、存儲、網絡技術使得這件事情變得可行—那么IT的貢獻在于工具和平臺的貢獻—就像很多人認為西醫(yī)目前最大的進步來自于測量工具的水平提高了，而非就在模型方面的貢獻，因為工業(yè)做這些已經非常久的歷史了。

這也是我比較奇怪的，那些真正提供平臺的企業(yè)如Microsoft、華為這些本身有非常強大平臺、研發(fā)支撐的企業(yè)倒是很低調，定位自己的角色在于平臺與工具。

但是，很多工業(yè)互聯(lián)網平臺—特別強調一下，說自己屬于“平臺”的—我覺得你這些平臺可能只是微軟、IBM、華為他們的“系統(tǒng)集成”角色比較合適，如果是這個角色，那就必須要深入工業(yè)中的應用場景實現(xiàn)上，那么就有很多問題需要解決

(1)你知道該怎么為復雜的參數(shù)進行分析嗎?可能你連這些參數(shù)是什么都不知道，但是，你一旦要進入這個領域，如果沒有一個資深業(yè)內工藝專家，你根本就沒有任何可能性進行學習。

(2)你的模型是什么?就是網上下載的開源學習代碼?這個要是能玩的話，那制造業(yè)的工藝專家為什么不自己玩，非要你來給我玩?

數(shù)據(jù)真的那么容易獲取嗎?

這是個很現(xiàn)實的問題，之前我曾經寫過，預測性維護的偽命題，即，如果這個機器故障數(shù)據(jù)很多，那么這個機器可能在客戶那里就會被淘汰，第二個問題是，如果你能采集到故障信號，但是，故障數(shù)據(jù)可能是很少的—而與之對應的關聯(lián)數(shù)據(jù)如果缺乏完整性的話，這個模型就無法學習到真正的原因，而這個就需要大量的積累經驗。因此，數(shù)字化的學習必須與實際的模型相結合，在這方面，擁有自主模型的工業(yè)基因的企業(yè)反倒是有條件的，但是，就是缺乏數(shù)字化工具，但是，如果你是做平臺的，你有榔頭卻沒有釘子就比較尷尬了。

三無的工業(yè)互聯(lián)網平臺能活多久?

在風力發(fā)電市場比較熱鬧的時候，國內蜂擁而上的有89家主機制造商(2012年左右)，那個時候大家就說，這個行業(yè)最終能活下來的大約就15家，現(xiàn)在來看，這是真的，而光伏行業(yè)在熱的時候，那場景就是做鞋子、做襪子、打火機的都蜂擁而上的去做光伏了，太賺錢了，現(xiàn)在呢?

對的，我們主要想說的是“有標準”、“有工具”、“有模型”的平臺才能真正在未來為制造業(yè)賦能、帶來轉型的效率提升，否則，就是風險投資中的“風險”而不是“投資”。