賈子翔 翟春輝 賈 捷
中國聯(lián)通研究院 北京 100176
隨著5G、大數(shù)據(jù)以及邊緣計算的蓬勃發(fā)展,在“中國制造2025”及德國“工業(yè)4.0”政策、行業(yè)標桿的驅(qū)動指引下[1],越來越多的傳統(tǒng)工業(yè)企業(yè)渴求在智能制造領域?qū)で笸黄?。在對傳統(tǒng)工業(yè)進行互聯(lián)網(wǎng)化升級改造的過程中,5G“低時延、高可靠、大帶寬”的性能滿足了其對于無線高速網(wǎng)絡連接、低時延計算和高數(shù)據(jù)安全的需求,充分保障了設備數(shù)據(jù)從OT向IT的實時傳輸、快速計算以及敏捷響應的能力。移動邊緣計算(MEC)[2]的興起,使得在設備側(cè)部署具備存儲計算能力的小型服務器成為現(xiàn)實,可以減少工業(yè)數(shù)據(jù)在不同節(jié)點傳輸?shù)奶鴶?shù),大幅縮短了設備數(shù)據(jù)從采集到展現(xiàn)的時延,進一步保障了工業(yè)監(jiān)控的實時性需求。
“云化”即依托邊緣云的應用承載能力,實現(xiàn)軟件定義的控制系統(tǒng),本文將介紹如何依托云化實時工業(yè)控制系統(tǒng)實現(xiàn)工業(yè)自動化監(jiān)控。
工業(yè)智能化監(jiān)控系統(tǒng)與網(wǎng)絡通信的發(fā)展緊密相連,早期出現(xiàn)的此類工業(yè)應用所需的設備、傳感器以及服務器,采用有線網(wǎng)絡方式連接,存在靈活性差、造價昂貴、不易擴展、響應時延大以及監(jiān)控數(shù)據(jù)容易丟失等缺陷。
隨著5G的商用和普及以及邊緣計算技術的進步和發(fā)展,為工業(yè)設備數(shù)據(jù)的遠程監(jiān)控提供了發(fā)展前提和技術環(huán)境,很快遠程設備數(shù)據(jù)監(jiān)控系統(tǒng)被應用在了各行各業(yè)中。典型的設備監(jiān)控系統(tǒng)基于物聯(lián)網(wǎng)模型構建,物聯(lián)網(wǎng)網(wǎng)絡通常不是一個單純的IP網(wǎng)絡,它常常涉及多個異種網(wǎng)絡的集成,從而進行業(yè)務通信和數(shù)據(jù)交換。通常工業(yè)監(jiān)控應用的系統(tǒng)架構一般包括測控設備(傳感器、測控儀、攝像頭等)、工控設備、智能網(wǎng)關、應用服務端及客戶端,測控設備作為設備數(shù)據(jù)的采集端,采集到的工業(yè)OT數(shù)據(jù)通過PLC(Programmable Logic Controller,可編程邏輯控制器,工業(yè)控制的核心)控制傳輸至工業(yè)網(wǎng)關,通過智能網(wǎng)關的協(xié)議解析,將OT數(shù)據(jù)轉(zhuǎn)化為監(jiān)控應用可用的IT數(shù)據(jù),經(jīng)過網(wǎng)絡傳輸至應用服務端進行數(shù)據(jù)解析和數(shù)據(jù)持久化,在客戶端經(jīng)過圖表渲染呈現(xiàn)給應用使用者?,F(xiàn)階段OT側(cè)工控設備普遍采用傳統(tǒng)PLC,需要專門的編程環(huán)境,且編程難度高,使用困難,且不同型號的控制器對應不同的協(xié)議,需要額外適配專用的網(wǎng)關,靈活性及擴展性較差。
工業(yè)自動化監(jiān)控系統(tǒng)承載了對工業(yè)設備數(shù)據(jù)實時監(jiān)控、統(tǒng)計分析的基本需求,PLC作為OT側(cè)控制核心,滿足設備聯(lián)網(wǎng)、數(shù)據(jù)采集、云端控制等需求,通過云化網(wǎng)關實現(xiàn)協(xié)議解析、數(shù)據(jù)上傳、指令下達,實現(xiàn)對工業(yè)設備的自動化監(jiān)控。本節(jié)將從技術選型和系統(tǒng)架構等方面介紹如何設計并構建該系統(tǒng)。
PLC是一種具有微處理器的用于自動化控制的數(shù)字運算控制器,可以針對工業(yè)設備工作產(chǎn)生的數(shù)據(jù),通過循環(huán)掃描,采用集中采樣、集中輸出的工作方式,控制數(shù)據(jù)經(jīng)以太網(wǎng)連接或者外部訪問協(xié)議(OPC-UA、MODBUS等)的方式向外傳輸。
云化PLC[3]即軟件定義的PLC,通過軟件配置實現(xiàn)控制設備行為、參數(shù)配置及組態(tài),以開放平臺的形式供用戶使用,可靈活適配不同的供應商。云化PLC包括軟件定義的控制系統(tǒng)、桌面系統(tǒng)、組態(tài)以及編程套件等,集成了傳統(tǒng)工控機和PLC的全部功能。與傳統(tǒng)PLC相比,云化PLC優(yōu)勢明顯,如表1所示。
表1 云化PLC與傳統(tǒng)PLC對比
云化PLC選用遠程IO模塊,實現(xiàn)IO系統(tǒng)配置的模塊化,利用總線通信的方式,大大減少了現(xiàn)場復雜的走線。云化PLC還支持內(nèi)置集成云化網(wǎng)關軟件,支持豐富的工業(yè)協(xié)議,解決了因工業(yè)現(xiàn)場通信協(xié)議多樣化、不統(tǒng)一帶來的數(shù)據(jù)采集困難等問題。此外,由軟件定義的云化PLC可靈活編排和擴展,面向復雜多樣的應用場景,可通過軟件升級支持工控系統(tǒng)的柔性化和靈活性配置,無需因需求升級導致大規(guī)模更換控制器,實現(xiàn)降本增效。
MQTT是IBM推出的一個極其輕量級的發(fā)布/訂閱消息傳輸協(xié)議,構建于TCP/IP之上,提供有序、可靠的數(shù)據(jù)傳輸機制。
由于物聯(lián)網(wǎng)設備普遍性能低下,且網(wǎng)絡連接質(zhì)量也不可靠,因此在設計協(xié)議時需要重點考慮以下特性:
1)足夠輕量,方便嵌入式設備快速解析和響應;
2)支持雙向通信,即服務器和客戶端之間可以相互收發(fā)消息;
3)由于多數(shù)物聯(lián)網(wǎng)設備網(wǎng)絡時延不穩(wěn)定,實際生產(chǎn)中設備也不適合持續(xù)等待服務器響應,因此協(xié)議需要支持異步傳輸機制;
4)足夠靈活,支持設備和服務的多樣化。
MQTT最初便是為物聯(lián)網(wǎng)設備的網(wǎng)絡接入而設計的[4],具備以下主要特點:
1)發(fā)布訂閱模式,支持一對多及雙向消息發(fā)布;
2)1字節(jié)固定報頭和2字節(jié)心跳報文,擁有較小的網(wǎng)絡傳輸負載;
3)針對不同場景,支持三種級別的數(shù)據(jù)服務質(zhì)量(QoS,只有一次、最少一次和最多一次),按需保障數(shù)據(jù)準確性和傳輸效率。
這些特點讓MQTT完美適配基于物聯(lián)網(wǎng)構建的工業(yè)設備數(shù)據(jù)傳輸需求,可通過較少的代碼、有限的帶寬以及穩(wěn)定的性能為設備提供實時可靠的消息服務。
MQTT擁有生產(chǎn)者(Publisher)、消費者(Subscriber)和代理服務器(Broker)三種角色,其關系如圖1所示。生產(chǎn)者和消費者作為客戶端,對彼此無感知,只需通過配置好的IP及端口與Broker建立連接,生產(chǎn)者可將數(shù)據(jù)發(fā)布至Broker指定主題(topic),消費者可根據(jù)需求,訂閱所需主題的數(shù)據(jù)。
圖1 MQTT架構
時序數(shù)據(jù)是基于穩(wěn)定頻率或非固定周期頻率持續(xù)產(chǎn)生的一系列基于時間維度的指標監(jiān)測數(shù)據(jù),普遍存在于工業(yè)設備、儀表、傳感器產(chǎn)生的數(shù)據(jù),呈現(xiàn)出一定的趨勢性和規(guī)律性[5]。時序數(shù)據(jù)庫是一種針對時序數(shù)據(jù)高度優(yōu)化的垂直型數(shù)據(jù)庫,且以時間為索引,支持時序數(shù)據(jù)的快速寫入和多維度實時查詢等功能。
在實際工業(yè)生產(chǎn)中,特別是在IoT物聯(lián)網(wǎng)以及OPS運維監(jiān)控領域,由于工業(yè)設備的持續(xù)工作,因而會不間斷地產(chǎn)生數(shù)據(jù),所需的數(shù)據(jù)存儲規(guī)模甚至會達到TB、PB級,傳統(tǒng)關系型數(shù)據(jù)庫很難支撐這么大的數(shù)據(jù)量以及這么大的寫入壓力。大規(guī)模IoT物聯(lián)網(wǎng),對數(shù)據(jù)存儲的需求主要包括:
1)低存儲成本:數(shù)據(jù)量呈指數(shù)級增長,且因貼近實際生產(chǎn),對成本敏感;
2)彈性:工業(yè)設備監(jiān)控場景存在業(yè)務數(shù)據(jù)爆發(fā)式增長的場景,需要擁有足夠靈敏的彈性伸縮能力,能夠快速擴容應對增長的業(yè)務需求;
3)高性能寫入:工業(yè)設備數(shù)據(jù)采集頻率較高,需要支持7×24小時不間斷高壓力海量數(shù)據(jù)寫入能力;
4)高性能查詢:由于要保證數(shù)據(jù)分析的實時性,對海量數(shù)據(jù)查詢的實時性有較高要求;
5)高穩(wěn)定性:對于工業(yè)軟件的普遍性要求,避免設備數(shù)據(jù)丟失影響自動化業(yè)務。
工業(yè)場景的數(shù)據(jù),普遍存在以下特點:
1)都有時間戳,且按時間順序生成;
2)采集頻率高,單條數(shù)據(jù)不長,但數(shù)據(jù)規(guī)模極大;
3)寫入頻率遠高于查詢頻率;
4)很少需要更新特定時間點的數(shù)據(jù)內(nèi)容。
面對海量數(shù)據(jù)存儲,傳統(tǒng)數(shù)據(jù)庫多是采用主備架構,且對于時序數(shù)據(jù)存儲壓縮性能不佳,通常要求有較高的服務器硬件配置,這對于成本敏感的工業(yè)企業(yè)是難以承受的;在海量數(shù)據(jù)寫入方面,傳統(tǒng)數(shù)據(jù)庫單機寫入吞吐低,很難滿足海量時序數(shù)據(jù)的寫入壓力,分布式集群模式在工業(yè)應用中也不現(xiàn)實;在查詢性能方面,如未人工建立索引,按時間、標簽等多維度的海量數(shù)據(jù)聚合分析性能較差,難以滿足較高的實時性需求。相比之下,時序數(shù)據(jù)庫利用時間遞增、維度重復、指標平滑的特性,擁有較高數(shù)據(jù)壓縮比,通過預降精度,對歷史數(shù)據(jù)做聚合,可有效節(jié)省存儲空間;時序數(shù)據(jù)庫支持海量時序數(shù)據(jù)的批量寫入,不支持數(shù)據(jù)更新;針對時序數(shù)據(jù),時序數(shù)據(jù)庫默認對時間建立索引,且通過緩存、routing等技術提高查詢并發(fā),可對海量時序數(shù)據(jù)進行實時查詢和聚合分析。此外,時序數(shù)據(jù)庫采用無鎖設計和多核技術,讓數(shù)據(jù)插入和查詢的速度比傳統(tǒng)數(shù)據(jù)庫有了質(zhì)的飛躍[6]。
結合工業(yè)場景數(shù)據(jù)的特點,綜上所述,時序數(shù)據(jù)庫無疑是工業(yè)設備數(shù)據(jù)持久化的上佳選擇,它本身的分布式架構,使其不再依賴昂貴的硬件,在普通的x86服務器甚至虛擬機上都可運行,大大降低了使用成本。
本節(jié)介紹如何運用前面介紹的關鍵技術,構建通用的工業(yè)監(jiān)控系統(tǒng),系統(tǒng)由三層架構構成:設備接入層、協(xié)議解析層和應用表示層,如圖2所示。
圖2 系統(tǒng)架構設計
1)設備接入層
當PLC投入運行后,其工作過程一般分為三個階段,即輸入采樣、用戶程序執(zhí)行和輸出刷新三個階段。完成上述三個階段稱作一個掃描周期。在整個運行期間,PLC的CPU以一定的掃描速度重復執(zhí)行上述三個階段,實現(xiàn)對設備的控制和數(shù)據(jù)的采集。結合2.1中所述優(yōu)勢,本系統(tǒng)采用云化PLC軟件,與云化網(wǎng)關部署在MEC服務器中,滿足廠區(qū)數(shù)據(jù)的高性能接入、計算、傳輸需求,保障信息安全,降低傳輸成本。
2)協(xié)議解析層
作為OT和IT的分界線,工業(yè)網(wǎng)關支持豐富多樣的工業(yè)協(xié)議,將工業(yè)世界的數(shù)據(jù)通過協(xié)議解析轉(zhuǎn)化為IT世界可用的結構化數(shù)據(jù),向下可作為大規(guī)模分布式設備(如工業(yè)控制器、傳感器、儀器儀表、數(shù)控機床等)的接入節(jié)點,向上可通過以太網(wǎng)、無線網(wǎng)等多種信道通過TCP等網(wǎng)絡協(xié)議傳輸數(shù)據(jù)至工業(yè)應用,構建工業(yè)設備與應用之間的橋梁。
3)應用表示層
工業(yè)監(jiān)控應用通過微服務實現(xiàn)前后臺分離,應用后臺作為MQTT消息的消費者客戶端,訂閱特定topic的實時數(shù)據(jù),并通過數(shù)據(jù)解析模板配置的方式,無需編程開發(fā),按照模板即可對訂閱的數(shù)據(jù)解析入時序數(shù)據(jù)庫,實現(xiàn)對工業(yè)數(shù)據(jù)的持久化。同時時序數(shù)據(jù)庫可以通過配置Retention Policy,即數(shù)據(jù)保存策略,設置數(shù)據(jù)的存儲時間、存儲備份數(shù)等參數(shù),保障不同數(shù)據(jù)可以按需保存,定期清理過期數(shù)據(jù),防止溢出硬件存儲能力。應用前臺主要有兩種模式,一種是通過AJAX輪詢等方式,實時通過圖表等方式可視化展現(xiàn)最新的監(jiān)控數(shù)據(jù),為企業(yè)決策者多維度、多形態(tài)地展示參考;另一種針對專業(yè)工程師或設備操作員,模擬產(chǎn)線構建圖形組態(tài),提供HMI(人機交互)界面,使得操作員可以根據(jù)監(jiān)控數(shù)據(jù)發(fā)現(xiàn)設備問題,在線通過界面遠程操作并修正設備。在反控設備時,通常由應用后臺作為HTTP RESTful請求的客戶端,將操作指令或配置參數(shù)封裝在請求體,向網(wǎng)關或者支持HTTP的設備發(fā)送請求,用戶操作全程對設備信息無感知,所有的請求方式、請求參數(shù)以及觸發(fā)條件均在應用啟動時預先配置完成。
本文以某大型工業(yè)企業(yè)智能皮帶糾偏應用為驗證背景,基于第2節(jié)中所介紹的系統(tǒng)架構,構建在皮帶糾偏應用中關鍵網(wǎng)絡時延的監(jiān)控應用,分別驗證該系統(tǒng)設計的可行性和異常捕獲及云化控制能力。
如圖3所示,整個網(wǎng)絡監(jiān)控應用依托于皮帶糾偏網(wǎng)絡監(jiān)控流程,主要由MEC服務器中部署的組件保證應用的正常工作及功能驗證(圖2中所示的模塊除設備均部署在MEC內(nèi)),MEC外的組件主要用來保證設備和工控系統(tǒng)之間網(wǎng)絡的連接,流程中各模塊簡介如下。
圖3 皮帶糾偏網(wǎng)絡監(jiān)控流程
1)糾偏設備:由兩臺皮帶糾偏電機及傳感器組成,通過兩臺工業(yè)IO設備進行modbus(工業(yè)領域通信協(xié)議的業(yè)界標準,并且現(xiàn)在是工業(yè)電子設備之間常用的連接方式)信號傳輸,與工業(yè)IO通過有線連接,糾偏操作通過部署在MEC的云化PLC控制;
2)工業(yè)IO:承擔工業(yè)信號的輸入/輸出,輸入指從儀表進入控制系統(tǒng)的測量參數(shù),輸出指從控制系統(tǒng)輸出到執(zhí)行機構的參量;
3)工業(yè)交換機:承擔工業(yè)IO與DTU之間的通信,與二者均通過有線連接;
4)5GDTU:5G數(shù)據(jù)傳輸單元(5G Data Transfer Unit),是專門用于將串口數(shù)據(jù)轉(zhuǎn)換為IP數(shù)據(jù)或?qū)P數(shù)據(jù)轉(zhuǎn)換為串口數(shù)據(jù)通過無線通信網(wǎng)絡進行傳送的無線終端設備,系統(tǒng)采用聯(lián)通的“先鋒者2號”產(chǎn)品,提供工業(yè)控制接口,集成通用工業(yè)現(xiàn)場總線協(xié)議,可以快速為行業(yè)用戶提供5G無線網(wǎng)絡接入能力;
5)5G宏站:與MEC服務器通過光纜連接,提供其對外界的5G無線通信能力;
6)MEC:即邊緣計算服務器,部署了云化PLC(集成了網(wǎng)關)、MQTT代理、監(jiān)控應用以及時序數(shù)據(jù)庫(采用influxDB)。
“先鋒者2號”在測試環(huán)境中IP為10.250.2.143,結合其支持端口映射的特性,將兩臺工業(yè)IO的業(yè)務端口502、503分別映射到“先鋒者2號”設備的10.250.2.143:502和10.250.2.143:503,實現(xiàn)分別控制兩臺糾偏電機。本應用主要監(jiān)測兩個點位的網(wǎng)絡通信時延,一個是控制端(即MEC中的監(jiān)控應用)到“先鋒者2號”的通信網(wǎng)絡時延(以`xianfengzhe2`表示),另一個是控制端到糾偏設備的端到端時延(以`time_delay`表示)。
網(wǎng)絡時延數(shù)據(jù)的采集方式通過部署在MEC中的shell腳本,使用tcping命令定時分別ping“先鋒者2號”的100、502、503端口(日志信息如圖4所示),其中100代表控制端到“先鋒者2號”的時延,即`xianfengzhe2`,502、503則分別代表控制端到兩臺糾偏設備的端到端時延。該shell腳本在捕獲時延數(shù)據(jù)之后,會將其拼接成如圖5的數(shù)據(jù)格式,發(fā)布到MQTT特定topic。
圖4 日志信息
圖5 網(wǎng)絡時延數(shù)據(jù)
監(jiān)控應用作為消費者客戶端,訂閱該topic實時獲取數(shù)據(jù),并解析入influxDB時序庫,同時監(jiān)控應用會對目標庫進行AJAX輪詢,一旦有數(shù)據(jù)增量,便實時同步至前臺展示,監(jiān)控效果圖如圖6所示,其中藍線表示控制端到兩臺設備通信的端到端時延(time_delay),紅線表示控制端到“先鋒者2號”時延(xianfengzhe2)。需要注意的是,xianfengzhe2理論上應該小于time_delay,但由于實際情況中,“先鋒者2號”為設備數(shù)據(jù)提供5G無線接入傳輸能力,而xianfengzhe2的意義則是驗證5G網(wǎng)絡在設備和終端間是否可用,即當其有正常數(shù)值時表示5G接入網(wǎng)絡正常可用,當其值為‘-1’時表示5G接入網(wǎng)絡連接已斷開。圖6中偶爾出現(xiàn)的xianfengzhe2>time_delay的情況是由于兩個時延數(shù)據(jù)采集的shell腳本分別獨立運行,為了驗證5G網(wǎng)絡可用,xianfengzhe2的獲取需要加上接收回傳響應信息所需的時延,而time_delay是直接的單向通信時延。
圖6 網(wǎng)絡時延實時監(jiān)控
由于influxDB有豐富的統(tǒng)計函數(shù)庫,同時支持以時間維度對數(shù)據(jù)進行周期性統(tǒng)計報表。以2021.2.21~2021.2.25期間全天實時監(jiān)控數(shù)據(jù)為例,得到的統(tǒng)計信息如表2所示,設備管理者可以根據(jù)這些數(shù)據(jù)得知網(wǎng)絡的狀況,進而判斷是否會影響設備正常工作。由于“先鋒者2號”主要起了5G網(wǎng)絡接入的能力,`xianfengzhe2`字段所示時延無較大意義,只為測試網(wǎng)絡連接是否正常,端到端網(wǎng)絡時延性能是重要監(jiān)控指標,如果網(wǎng)絡發(fā)生閃斷(通信狀態(tài)timeout,`time_delay`表示為`-1`),可快速重連。
表2 網(wǎng)絡時延重要指標統(tǒng)計
網(wǎng)絡時延超過100ms將對皮帶糾偏產(chǎn)生滯后影響,容易導致生產(chǎn)事故,因此當網(wǎng)絡時延大于100ms時,需要監(jiān)控系統(tǒng)預先設定策略,觸發(fā)云化PLC反控糾偏設備的糾偏開關調(diào)整為延時糾偏模式(參數(shù)為JP_MODE:02),直到網(wǎng)絡時延恢復正常,再控制糾偏開關回到正常模式(參數(shù)為JP_MODE:01)。正常模式下,現(xiàn)場的視頻攝像頭收集皮帶偏轉(zhuǎn)數(shù)據(jù)、物料數(shù)據(jù)進行糾偏判斷、物料識別和調(diào)整糾偏力度控制。高通信時延作為該場景下存在的影響正常糾偏的主要因素,影響圖像數(shù)據(jù)的實時傳輸、解析和響應,延時糾偏模式因此被設計用來保障在時延過大時仍能確保皮帶的正常工作,其核心設計思路是暫時不根據(jù)圖像響應判斷糾偏程度和力度,而通過機械控制的液壓桿維持皮帶穩(wěn)定,保證物料不掉落,待時延切回正常模式后,重新由糾偏開關控制糾偏電機進行糾偏修復。
本節(jié)重點驗證應用的云化控制能力,即通過部署在MEC中的監(jiān)控應用傳遞控制參數(shù)給同樣部署在MEC的云化PLC,進而控制設備糾偏方式的轉(zhuǎn)變。由于云化PLC集成了支持HTTP RESTful接口訪問的云化網(wǎng)關(MEC內(nèi)網(wǎng)IP:172.16.0.21:48082),因此在發(fā)生超高網(wǎng)絡時延時,由監(jiān)控應用服務端向網(wǎng)關(與云化PLC集成)對應的API PUT一個變更參數(shù),使得云化PLC控制參數(shù)JP_MODE由01變更為02并輸出相應的控制信號,通過其所在MEC依托的5G宏站向現(xiàn)場發(fā)送,位于現(xiàn)場的“先鋒者2號”負責接收該5G控制信號,經(jīng)由工業(yè)IO轉(zhuǎn)化為實際控制的電信號,通過工業(yè)線纜傳輸?shù)狡КF(xiàn)場端,伺服電機接收到電信號驅(qū)動糾偏開關按延時糾偏模式進行糾偏。整個響應控制過程,用戶在用戶界面(監(jiān)控面板)是無感知的,為了方便驗證,監(jiān)控系統(tǒng)提供了支持HTTP API訪問的測試功能。在網(wǎng)絡狀況正常時,如圖7所示,向該接口發(fā)送GET請求查詢當前JP_MODE的值,可以看到響應結果為01;在時延超過100ms時,如圖8所示,采用同樣的GET請求,響應結果JP_MODE參數(shù)值變更為02。
圖7 正常網(wǎng)絡狀況下的糾偏參數(shù)
圖8 異常網(wǎng)絡狀況下的糾偏參數(shù)
本文以傳統(tǒng)工業(yè)智能化轉(zhuǎn)型為背景,針對設備自動化監(jiān)控場景,基于云化控制、解析的理念提供了一套通用解決方案,并以實際生產(chǎn)場景加以驗證。該方案由5G和MEC驅(qū)動,滿足了實際工業(yè)生產(chǎn)中對于數(shù)據(jù)傳輸實時性和準確性的要求,構建了對工業(yè)數(shù)據(jù)多維度、多形態(tài)可視化展現(xiàn)并快速定位工控問題的能力,解決了海量工業(yè)應用在數(shù)據(jù)維度智能化不足的問題。在可以預見的將來,隨著技術不斷成熟和場景的不斷優(yōu)化,云化的工業(yè)自動化控制必將在工業(yè)智能化改造進程中畫上濃墨重彩的一筆。