做DCS與MES集成這些年總有人問我你們跟DCS到底是怎么對接的這個問題表面上是在問接口實際上問的是整個工廠的數(shù)據(jù)底座。我見過不少項目接口一周就調(diào)通了數(shù)據(jù)也在界面上滾動顯示可過了三個月再回訪MES里的產(chǎn)量追溯還是對不上工藝曲線還是缺片段。為什么會這樣因為接口解決的是能不能拿到數(shù)據(jù)而數(shù)據(jù)貫通要解決的是拿到數(shù)據(jù)之后能不能直接用、用得放心。這篇文章要聊的就是后者。DCS分散控制系統(tǒng)負(fù)責(zé)車間里每秒鐘都在發(fā)生的實時控制MES制造執(zhí)行系統(tǒng)負(fù)責(zé)車間上層的生產(chǎn)管理兩個系統(tǒng)之間的數(shù)據(jù)貫通從來不是拉根線、開個端口那么簡單而是一整套從點位規(guī)劃、語義對齊、批次對應(yīng)到運維治理的工程路徑。我會把這條路徑拆開講透包括四種主流接口方式怎么選、點位表和批次為什么要認(rèn)真設(shè)計、上線后哪些坑一定會遇到以及沒有真實DCS環(huán)境時怎么驗證方案。想少走彎路的人可以照著這個思路去推。1. 為什么DCS和MES之間總是隔著一道墻1.1 控制的世界和管理的世界節(jié)奏完全不同DCS管的是一條產(chǎn)線、一套裝置里每秒鐘都在發(fā)生的控制回路、聯(lián)鎖邏輯和工藝參數(shù)。它的時間尺度是毫秒到秒追求的是穩(wěn)定、可靠、實時。MES管的則是一個工單從下達(dá)、投料、加工、檢驗到報工的完整生命周期時間尺度是分鐘、小時、班次追求的是合規(guī)、可追溯、可優(yōu)化。這兩套系統(tǒng)在設(shè)計之初就是兩種語言DCS在說PV值是57.3輸出是20%MES在說這批產(chǎn)品用了多少原料、設(shè)備OEE是多少。讓MES直接去理解DCS的一堆原始位號就像讓車間主任去讀PID圖紙一樣——不是看不懂是看不過來。DCS側(cè)一個中型裝置就是幾千個位號MES真正關(guān)心的可能只有其中幾十個而且這幾十個還要經(jīng)過換算、歸類、按批次聚合之后才算數(shù)。這種語義層面的錯位才是兩個系統(tǒng)之間那道墻的磚石。很多人以為問題出在網(wǎng)絡(luò)協(xié)議上實際上協(xié)議只是表象兩邊的數(shù)據(jù)世界觀不一樣才是根因。1.2 不打通的時候生產(chǎn)數(shù)據(jù)是怎么斷的在沒有做集成之前MES里那些跟DCS相關(guān)的數(shù)據(jù)是怎么來的很多工廠到今天還在靠人。最常見的做法是人工抄表每兩個小時操作員拿著巡檢本去記錄關(guān)鍵儀表的讀數(shù)回到中控室再敲進(jìn)Excel最后由統(tǒng)計員匯總后導(dǎo)入MES。這個過程有多脆弱不用我多說抄表時間不準(zhǔn)確、兩次記錄間隔不均勻、抄錯數(shù)字、Excel公式出錯、交接班信息對不上任何一個環(huán)節(jié)出問題MES里那行數(shù)就不干凈。還有一種常見做法是用U盤去DCS歷史站導(dǎo)出一份趨勢數(shù)據(jù)再找IT部門轉(zhuǎn)成MES能導(dǎo)入的格式。第一次做的時候大家還愿意配合等到每個月都要來一次這件事就變成誰都不想碰的爛攤子。時間一長MES的報表質(zhì)量全憑運氣。這些斷點帶來的直接后果是MES里的數(shù)據(jù)永遠(yuǎn)比現(xiàn)場慢半拍產(chǎn)量和能耗對不上賬質(zhì)量追溯時找不到當(dāng)時的真實趨勢。做過實施的人看到這里應(yīng)該已經(jīng)在點頭了這些都是天天見的場景。1.3 集成的本質(zhì)把連續(xù)的過程值翻譯成業(yè)務(wù)事件我一直覺得DCS與MES集成做得好的團(tuán)隊本質(zhì)上是把翻譯這件事做好了。DCS輸出的是一系列連續(xù)的過程值比如溫度曲線、壓力曲線、流量累積量而MES要的是一段段有業(yè)務(wù)含義的事件比如這批料在8點30分開始升溫這個批次在13點50分達(dá)到反應(yīng)終點。連續(xù)的數(shù)據(jù)不帶邊界業(yè)務(wù)又偏偏是按邊界組織的——這個邊界就是批次、工單、班次。所以真正的集成不應(yīng)該只是把數(shù)據(jù)搬過去還要把數(shù)據(jù)切好、貼上標(biāo)簽讓MES拿過去就能直接用。這也是為什么我會強(qiáng)調(diào)信息模型和批次對應(yīng)這兩件事做扎實了數(shù)據(jù)才叫貫通否則只是搬運。理解了這一層再看后面的接口選型和方案設(shè)計思路會清晰很多。2. 主流的集成路徑四種接法怎么選2.1 OPC DA/UA工業(yè)現(xiàn)場的事實標(biāo)準(zhǔn)做DCS集成繞不開OPC這個協(xié)議簇幾乎是工業(yè)控制領(lǐng)域的事實標(biāo)準(zhǔn)幾乎所有主流DCS廠商都提供OPC服務(wù)器包括中控、和利時、Honeywell、Siemens、Emerson、橫河。OPC有兩個主要版本必須區(qū)分開OPC DAData Access和OPC UAUnified Architecture。OPC DA年代較早底層基于Windows的DCOM機(jī)制在企業(yè)網(wǎng)環(huán)境下配置極其痛苦。防火墻要放行、DCOM權(quán)限要調(diào)、用戶賬戶要匹配任何一個環(huán)節(jié)出問題就聯(lián)不上而且DCOM的端口是動態(tài)分配的每次會話可能用不同端口這讓IT安全團(tuán)隊非常頭疼。但它太普及了很多老DCS和第三方系統(tǒng)至今仍然只支持OPC DA所以在存量項目里還會遇到。OPC UA則是全新一代設(shè)計跨平臺、支持加密和證書認(rèn)證、可以自定義信息模型還內(nèi)置了歷史數(shù)據(jù)訪問HA和告警事件AC服務(wù)。新建項目我強(qiáng)烈建議直接上UA不管是DCS原生支持還是加一臺邊緣網(wǎng)關(guān)把DA轉(zhuǎn)成UA都值得投入。選OPC路線的好處是協(xié)議本身已經(jīng)把點位瀏覽、數(shù)據(jù)質(zhì)量、讀寫屬性這些概念定義清楚了集成方不用自己發(fā)明輪子。但有個容易忽略的性能問題OPC服務(wù)器允許同時建立多少個客戶端會話、單點采集頻率上限是多少一定要在選型時問清楚。我遇到過OPC DA服務(wù)器被一個沒有節(jié)制的客戶端全量訂閱拖垮的情況后來限了采集范圍和頻率才恢復(fù)。這類問題不是協(xié)議本身的問題而是使用方式的問題事前做好容量規(guī)劃就不容易踩坑。2.2 數(shù)據(jù)庫直連最省事但最考驗集成方的自律很多國產(chǎn)DCS比如浙大中控的ECS-700、JX-300XP系列都提供實時數(shù)據(jù)庫或歷史數(shù)據(jù)庫的對外接口。一些項目為了讓MES盡快看到數(shù)據(jù)直接讓MES去連DCS的數(shù)據(jù)庫用SQL查詢實時數(shù)據(jù)。這種方式的優(yōu)點很直接實施快、調(diào)試方便、MES工程師自己就能搞定不用等DCS廠商排期。但缺點也很明顯。第一實時庫往往是DCS性能敏感的組件一個復(fù)雜的聚合查詢就可能把CPU打滿直接影響控制系統(tǒng)的穩(wěn)定性這在生產(chǎn)現(xiàn)場是不可接受的。第二DCS側(cè)的庫表結(jié)構(gòu)屬于廠商內(nèi)部實現(xiàn)一旦DCS升級版本或者出補(bǔ)丁表結(jié)構(gòu)變了MES這邊寫好的SQL就全廢維護(hù)成本很高。第三直接在庫層面操作會繞過DCS的權(quán)限控制和審計機(jī)制出了數(shù)據(jù)問題很難追蹤是誰動的。所以數(shù)據(jù)庫直連不是不能用而是必須有嚴(yán)格約束用只讀賬號、限定訪問時間窗口、優(yōu)先讀歷史庫而不是實時庫、大型聚合查詢走中間層緩存。有條件的話把數(shù)據(jù)先同步到一臺獨立的工業(yè)數(shù)據(jù)平臺里再讓MES去讀這個平臺既安全又穩(wěn)定。這個思路其實就是給MES和DCS之間加一道緩沖墊成本不高收益很大。2.3 文件交換與API/MQTT兩個極端的選擇文件交換是最古老也最可靠的方式之一。DCS側(cè)定時導(dǎo)出CSV、XML或者Excel文件通過FTP、SFTP或共享目錄交給MESMES按計劃導(dǎo)入。好處是簡單、不依賴復(fù)雜的網(wǎng)絡(luò)協(xié)議、兩邊完全解耦壞處是實時性差、文件解析容易出問題、數(shù)據(jù)量大了以后管理成本高。這個方案特別適合班報、日報、交接班記錄這類非實時、批量型的數(shù)據(jù)不要指望用它做秒級的產(chǎn)量統(tǒng)計。另一頭是API和MQTT?，F(xiàn)在很多新一代工業(yè)網(wǎng)關(guān)比如開源的Neuron、商業(yè)的Kepware等支持直接從DCS或PLC采集數(shù)據(jù)再以REST API或MQTT消息的方式對外提供。MES通過訂閱MQTT主題就能實時消費數(shù)據(jù)。這種模式很適合云化部署、多系統(tǒng)并發(fā)消費的場景網(wǎng)關(guān)層面還能做邊緣計算預(yù)處理比如先完成單位換算和量程歸一化再上送。但API/MQTT也有自己的坑。工業(yè)現(xiàn)場的網(wǎng)絡(luò)穩(wěn)定性遠(yuǎn)不如辦公網(wǎng)消息丟了怎么辦訂閱者離線期間的數(shù)據(jù)要不要補(bǔ)傳MQTT的QoS等級怎么選這些都要在設(shè)計消息主題和消費邏輯時提前想清楚。不要以為上了MQTT就一勞永逸它只是換了一種傳輸方式語義、質(zhì)量、時序這些問題一個都沒少反而因為異步化變得更隱蔽了。2.4 四種路徑的取舍對比我習(xí)慣用一張表來幫項目組做選擇每次討論到集成方案就把這張表擺出來讓業(yè)務(wù)方和IT方對著自己的場景判斷。集成路徑實時性實施成本維護(hù)難度適用場景主要風(fēng)險OPC UA/DA高秒級甚至更低中高中新建項目、多系統(tǒng)實時采集DCOM環(huán)境問題DA、性能調(diào)優(yōu)數(shù)據(jù)庫直連高低中國產(chǎn)DCS快速試點影響DCS性能、表結(jié)構(gòu)變更文件交換低分鐘到小時級低低班報、日報、批量歸檔實時性差、文件丟失API/MQTT高中中云化部署、多系統(tǒng)消費消息可靠性、斷線補(bǔ)傳這張表不是讓你照抄大部分項目按這個邏輯去選型不會跑偏。核心判斷依據(jù)永遠(yuǎn)是三個問題業(yè)務(wù)對實時性的要求有多高DCS廠商提供了哪些現(xiàn)成接口后續(xù)誰負(fù)責(zé)運維這套鏈路答案清楚了方案自然就浮出來了。3. 數(shù)據(jù)貫通的關(guān)鍵設(shè)計點位、批次與統(tǒng)一時基3.1 點位規(guī)劃只挑要負(fù)責(zé)任的數(shù)據(jù)DCS里一個裝置可能有幾千上萬個位號但MES真正需要的往往只有其中的10%到20%。點位規(guī)劃這件事直接決定集成鏈路的穩(wěn)定性和后續(xù)運維成本可很多人偏偏在這里偷懶覺得反正OPC支持全量訂閱把DCS所有點位一次性拉過來最省事。結(jié)果就是MES數(shù)據(jù)庫里塞滿了沒人看的變量哪個點是什么含義、單位是什么、量程是多少根本沒人說得清。經(jīng)驗做法是把點位分成三類。第一類是生產(chǎn)統(tǒng)計必須的比如投料量、產(chǎn)出量、關(guān)鍵工藝參數(shù)第二類是質(zhì)量追溯必須的比如反應(yīng)溫度、壓力、pH值的趨勢點第三類是設(shè)備與報警狀態(tài)比如運行狀態(tài)、故障信號、報警事件。與這三類無關(guān)的點一開始就不要接進(jìn)來寧缺毋濫。點位規(guī)劃的輸出是一張點位表至少要包含位號、工藝描述、工程單位、量程上下限、數(shù)據(jù)類型、讀寫屬性、采集周期、歸屬批次類型這些字段。舉例來說字段示例說明位號TE-101DCS側(cè)原始位號唯一標(biāo)識工藝描述反應(yīng)器溫度中文描述供MES展示工程單位℃換算后的統(tǒng)一單位量程下限/上限0 / 200用于量程歸一化數(shù)據(jù)類型float浮點、整型、布爾等讀寫屬性只讀不允許MES回寫采集周期2s關(guān)鍵工藝點高頻采集這張點位表是后續(xù)所有工作的基礎(chǔ)一定要和工藝工程師、DCS工程師、MES產(chǎn)品經(jīng)理三方一起確認(rèn)不要自己一個人對著圖紙拍腦袋。很多項目后面出問題追根溯源都是點位表沒做透單位沒統(tǒng)一、量程換算寫錯、幾個同類位號命名搞混。點位表做扎實了集成項目就成功了一半。3.2 批次與工單的對應(yīng)把連續(xù)數(shù)據(jù)切成業(yè)務(wù)切片這是DCS與MES集成里最有技術(shù)含量、也最容易被低估的環(huán)節(jié)。DCS的數(shù)據(jù)是連續(xù)的MES的管理單元是批次的怎么把連續(xù)的數(shù)據(jù)流切成一段一段有業(yè)務(wù)含義的切片直接決定追溯和統(tǒng)計能不能做準(zhǔn)。最常見的做法是時間窗口法。MES在工單下發(fā)時生成批次號并記錄生產(chǎn)開始和結(jié)束時間集成層根據(jù)這個時間范圍從歷史數(shù)據(jù)中截取對應(yīng)的趨勢片段歸檔到該批次下。這個方案實現(xiàn)簡單但依賴開始和結(jié)束時間是否準(zhǔn)確操作員如果提前投料、延后退出時間窗口就對不上追溯出來的曲線就會多一段或者少一段。更可靠的做法是讓DCS參與批次標(biāo)記。很多DCS支持通過配方或者階段來劃分生產(chǎn)階段DCS會在階段切換時打上時間戳集成層讀取這些階段事件再把它和MES的批次綁定。這樣切出來的數(shù)據(jù)就靠譜得多因為階段切換本身就是工藝上的真實邊界比人工記錄的時間點有說服力。我實際項目中還用過雙保險的做法DCS側(cè)按階段標(biāo)記批次事件MES側(cè)同時記錄工單的開始和結(jié)束時間兩側(cè)都傳回集成層對賬對不上就自動告警提示人工介入而不是默默生成一條錯位的追溯記錄。這個設(shè)計在質(zhì)量審計場景里非常有用。3.3 統(tǒng)一時基NTP校時與時間戳歸屬數(shù)據(jù)貫通之后最常見的靈異事件是DCS的歷史趨勢和MES的生產(chǎn)記錄對不上要么差幾分鐘要么跨了一個班次。99%的原因是兩邊服務(wù)器的時間不一致。DCS服務(wù)器走的是自己的時鐘MES服務(wù)器跑的是另一套時間源時間一長漂移幾十秒甚至幾分鐘很正常。要做數(shù)據(jù)貫通統(tǒng)一時基是前提。解決這個問題有兩個層面。第一讓DCS服務(wù)器、MES服務(wù)器、集成服務(wù)器都接入同一個NTP時間源統(tǒng)一校時并對所有服務(wù)器的時鐘偏差做周期性檢查。第二更重要所有歸檔到MES的數(shù)據(jù)時間戳一律取DCS側(cè)的時間戳而不是集成服務(wù)器的接收時間。為什么因為DCS的采集時間才是事件發(fā)生的真實時間集成服務(wù)器的接收時間只反映傳輸時延一旦網(wǎng)絡(luò)擁塞這個時間就會往后漂移批次和事件順序全亂。提醒一句時間戳歸屬這種問題光靠代碼層面意識不到一定要在設(shè)計評審時寫進(jìn)集成規(guī)范里。很多項目上線半年后數(shù)據(jù)對不上翻查日志才發(fā)現(xiàn)原因竟然是服務(wù)器時間差了8分鐘。還有一個容易被忽略的細(xì)節(jié)跨班次的生產(chǎn)批次。一個批次如果是23點50分結(jié)束的按MES的班次規(guī)則它應(yīng)該歸屬白班還是夜班這個歸屬邏輯最好配置在MES側(cè)不要硬編碼在集成層否則每逢交接班就會有人來找你改數(shù)據(jù)。把業(yè)務(wù)規(guī)則放在該放的地方集成層才能保持穩(wěn)定。3.4 信息模型與數(shù)據(jù)字典讓不同系統(tǒng)說同一種語言語義統(tǒng)一這件事說起來有點虛做起來非常實。同樣一個溫度DCS里叫TE-101MES里叫ReactionTemp臺賬里的中文名叫反應(yīng)器溫度。如果沒有一個數(shù)據(jù)字典把它們映射起來今天靠人記明天靠嘴傳后天就亂套了。信息模型的做法是在集成層建立一套統(tǒng)一的中間表或模型把DCS原始位號映射成標(biāo)準(zhǔn)化的業(yè)務(wù)對象。對象可以是設(shè)備、批次、工藝參數(shù)、報警事件等每個對象都有標(biāo)準(zhǔn)屬性MES不再直接面對DCS位號只和這個中間模型打交道。如果用的是OPC UA它本身就支持自定義信息模型可以把這些業(yè)務(wù)對象建模到UA的地址空間里。舉個例子{ pointId: TE-101, businessName: reactionTemp, description: 反應(yīng)器溫度, unit: ℃, range: [0, 200], dataType: float, source: DCS, mapping: UA:ns2;sTE_101 }這個JSON可以視為一條標(biāo)準(zhǔn)化的數(shù)據(jù)字典記錄MES收到消息后只要解析businessName就夠了不用關(guān)心底層位號怎么命名。如果用的是數(shù)據(jù)庫或MQTT就做一張標(biāo)準(zhǔn)數(shù)據(jù)字典表把所有點位的物理意義、單位、口徑寫清楚。這個工作看起來繁瑣但它恰恰是數(shù)據(jù)貫通和數(shù)據(jù)搬運之間的根本區(qū)別。搬運只關(guān)心能不能傳貫通還要關(guān)心傳過去之后能不能直接用。4. 一個集成項目的完整過程從接口定義到聯(lián)調(diào)上線4.1 先盤清楚現(xiàn)狀DCS型號、網(wǎng)絡(luò)拓?fù)浜徒涌谀芰Σ还苓x哪種集成路徑第一步永遠(yuǎn)是摸底。要搞清楚三件事DCS是什么品牌什么系列、控制網(wǎng)和信息網(wǎng)的拓?fù)溟L什么樣、DCS側(cè)有沒有現(xiàn)成的OPC服務(wù)器或數(shù)據(jù)接口。這一步不能只看文檔要拉著DCS工程師一起到現(xiàn)場確認(rèn)。很多工廠的DCS網(wǎng)絡(luò)在設(shè)計時壓根沒考慮過對上層系統(tǒng)開放數(shù)據(jù)接口機(jī)放在哪、IP怎么規(guī)劃、防火墻開不開端口都是要現(xiàn)場拍板的。建議在摸底階段就輸出一份《接口環(huán)境確認(rèn)表》內(nèi)容至少包括DCS型號與版本、OPC服務(wù)器軟件版本、接口機(jī)或歷史站的位置、可開放的網(wǎng)絡(luò)端口、點位表是否齊全、DCS時鐘是否支持NTP、DCS側(cè)是否有多余的算力來跑采集服務(wù)。這份表出來之后集成方案才不是空中樓閣。我見過一個項目藍(lán)圖階段把OPC UA吹得很漂亮到了現(xiàn)場發(fā)現(xiàn)DCS還是老的組態(tài)系統(tǒng)只支持OPC DA而且跑在Windows 2003上證書和加密根本別想。遇到這種情況方案必須當(dāng)場調(diào)整。4.2 網(wǎng)絡(luò)與安全方案控制網(wǎng)和信息網(wǎng)要有邊界DCS是負(fù)責(zé)生產(chǎn)控制的關(guān)鍵系統(tǒng)絕對不能讓MES直接裸奔著訪問。工業(yè)現(xiàn)場一般遵循控制網(wǎng)-信息網(wǎng)分層隔離的原則中間通過工業(yè)防火墻、網(wǎng)閘或者OPC UA網(wǎng)關(guān)做邊界保護(hù)。具體怎么做取決于現(xiàn)場條件預(yù)算充足的上一臺工業(yè)防火墻或單向網(wǎng)閘只允許OPC UA的端口通過配置白名單和證書認(rèn)證預(yù)算有限的至少要保證DCS的OPC服務(wù)器只對固定的集成服務(wù)器開放不暴露在辦公網(wǎng)里更不允許走公網(wǎng)傳輸。這里要特別提醒一個DR區(qū)OPC DA的DCOM協(xié)議在跨網(wǎng)段時很容易被防火墻攔掉因為DCOM的動態(tài)端口讓訪問控制很難做。如果兩邊隔了防火墻又必須用OPC DA不要硬鋼DCOM加一臺邊緣網(wǎng)關(guān)放在控制網(wǎng)邊界由網(wǎng)關(guān)完成協(xié)議轉(zhuǎn)換把DA轉(zhuǎn)成UA或者M(jìn)QTT再上送給MES。這樣既保住了控制網(wǎng)邊界又把集成方的頭發(fā)保住了。4.3 和DCS側(cè)組態(tài)配合的幾個實操細(xì)節(jié)DCS側(cè)對接不完全是IT活要尊重DCS工程師的工作方式和習(xí)慣。第一數(shù)據(jù)讀取本身不會影響控制功能但要注意OPC服務(wù)器的負(fù)載。建議配置采集頻率時分點位類型關(guān)鍵工藝參數(shù)可以1到2秒采一次一般統(tǒng)計點位5到10秒采一次設(shè)備狀態(tài)變化用訂閱方式更合適。第二如果DCS里某些點位本身沒有定義工程單位要么在組態(tài)側(cè)補(bǔ)充要么由集成層統(tǒng)一換算。流量累積值在DCS里可能是脈沖數(shù)換算成噸之后MES才能直接用這個換算關(guān)系和系數(shù)必須白紙黑字寫清楚否則換一個工程師來維護(hù)就全憑猜了。第三DCS報警信息如果要進(jìn)MES盡量通過OPC的AC服務(wù)來訂閱而不是自己去輪詢報警點位。輪詢會漏掉瞬時發(fā)生的報警AC有事件隊列和確認(rèn)機(jī)制能夠保證SOE事件順序記錄沒有丟失。這也解釋了為什么很多DCS廠家在回答控制系統(tǒng)有沒有聲音報警的問題時會把聲光報警當(dāng)作一個標(biāo)準(zhǔn)配置項報警的可感知性和可靠性本身就是DCS側(cè)很重視的功能集成方不要用自己的一套輪詢邏輯把它削掉。4.4 聯(lián)調(diào)驗證清單與驗收標(biāo)準(zhǔn)上線前一定要按清單逐項驗證不要指望一次聯(lián)調(diào)就能通。我習(xí)慣把這套驗證清單打印出來做完一項劃一項點位讀取每個點位能否讀到正確值質(zhì)量戳是否為Good單位換算抽樣10%的點位核對原始值與工程值換算結(jié)果是否一致時間戳采集DCS側(cè)時間戳和MES記錄時間戳確認(rèn)偏差在可接受范圍內(nèi)報警事件人為觸發(fā)一次真實報警確認(rèn)事件能完整到達(dá)MES且順序正確冗余切換如果DCS有冗余服務(wù)器拔掉主服務(wù)器網(wǎng)線觀察接管過程和恢復(fù)情況批量補(bǔ)傳模擬數(shù)據(jù)鏈路中斷5分鐘恢復(fù)后驗證數(shù)據(jù)能否補(bǔ)齊、不重復(fù)、不亂序性能壓測按滿負(fù)荷場景連續(xù)運行24小時觀察采集進(jìn)程的CPU、內(nèi)存和網(wǎng)絡(luò)占用。驗收標(biāo)準(zhǔn)要有量化指標(biāo)比如點位讀取成功率不低于99.9%數(shù)據(jù)端到端時延不超過5秒24小時運行無丟失、無重傳。這些標(biāo)準(zhǔn)要寫進(jìn)驗收報告雙方簽字確認(rèn)。沒有量化標(biāo)準(zhǔn)的聯(lián)調(diào)基本都是走過場上線后埋雷。5. 上線之后的數(shù)據(jù)質(zhì)量治理與報警對接5.1 數(shù)據(jù)質(zhì)量問題死值、漂移與質(zhì)量戳數(shù)據(jù)一旦跑上生產(chǎn)系統(tǒng)問題立刻現(xiàn)形。最常見的三類質(zhì)量問題幾乎每個集成項目都會遇到。第一類是死值。傳感器或者儀表故障時數(shù)值會長時間不變但MES不知道這是故障照樣拿去做統(tǒng)計產(chǎn)出一堆沒有意義的數(shù)據(jù)。解決辦法是在集成層做簡單診斷比如連續(xù)多個采集周期數(shù)值完全不變、且偏離工藝閾值時打上可疑標(biāo)記交給工藝工程師確認(rèn)。第二類是漂移。傳感器零點漂移會導(dǎo)致系統(tǒng)性偏差直接影響MES的能耗或產(chǎn)量計算。這個問題靠MES側(cè)的算法發(fā)現(xiàn)不了需要定期和DCS的儀表校準(zhǔn)記錄核對有條件的話關(guān)鍵計量點最好在集成層留一個手動校準(zhǔn)輸入讓周期性修正也留痕。第三類也是最容易忽略的是質(zhì)量戳。OPC和OPC UA本身都有質(zhì)量碼比如Good、Bad、Uncertain。很多集成項目在MES建表時壓根沒留質(zhì)量戳字段一發(fā)生通信抖動壞數(shù)據(jù)就混進(jìn)統(tǒng)計口徑里了。我的建議是集成層在歸檔時必須保留質(zhì)量戳字段寧可多存一個字段也不要事后查不到某條數(shù)據(jù)是否可靠。這一條寫進(jìn)設(shè)計規(guī)范里比任何培訓(xùn)都管用。5.2 報警與事件數(shù)據(jù)怎么傳從SOE到報警KPIDCS的報警信息是制造業(yè)里價值密度極高的一類數(shù)據(jù)但很多集成項目第一刀砍掉的就是報警對接理由是報警數(shù)據(jù)量大、語義復(fù)雜、MES里沒人看。這個取舍很可惜。DCS報警分幾類過程報警PV高、PV低、系統(tǒng)報警控制器冗余切換、通信中斷、SOE事件順序記錄。MES真正需要長期沉淀的是過程報警和SOE因為它們直接反映生產(chǎn)過程的穩(wěn)定性和異常工況。通過訂閱OPC AC事件報警可以在毫秒級到達(dá)MES而且自帶時標(biāo)和確認(rèn)狀態(tài)天然適合做追溯。有了這些數(shù)據(jù)MES能做的事就多了報警KPI每班報警次數(shù)、最頻繁報警點位、報警泛濫分析、關(guān)鍵報警響應(yīng)時間統(tǒng)計這些都是精益生產(chǎn)里的常用指標(biāo)。唯一要注意的是報警的量。一個中型項目一天可能有幾萬條報警事件建議做分區(qū)歸檔近期數(shù)據(jù)保留全量明細(xì)歷史數(shù)據(jù)按天聚合免得查個報表要掃全表。另外順帶說一句DCS報警通常有聲音報警機(jī)制比如音響或者蜂鳴器那是給現(xiàn)場操作員做實時提醒用的。MES做對接時不要把聲音當(dāng)成業(yè)務(wù)數(shù)據(jù)傳上去MES里只需要事件本身和狀態(tài)流轉(zhuǎn)就夠用了。5.3 集成鏈路自身的可觀測性集成平臺自己也是一個系統(tǒng)它有CPU、內(nèi)存、網(wǎng)絡(luò)、消息隊列、任務(wù)調(diào)度。太多項目在集成上線那天皆大歡喜三個月后某次網(wǎng)絡(luò)抖動斷了半天直到MES用戶發(fā)現(xiàn)數(shù)據(jù)顯示不對才有人去查中間的生產(chǎn)數(shù)據(jù)丟了多少都補(bǔ)不回來。所以集成層一定要有自己的監(jiān)控看板至少監(jiān)控四件事采集服務(wù)是否在線、每個DCS點位最近一次更新是什么時候、數(shù)據(jù)延遲多少、消息隊列積壓了多少。建議給核心指標(biāo)設(shè)置閾值告警數(shù)據(jù)延遲超過60秒就通知集成負(fù)責(zé)人而不是等用戶報障。這塊建設(shè)成本不高價值卻很大?？梢哉f一個集成項目的長期口碑一半靠點位表的嚴(yán)謹(jǐn)另一半就看這個監(jiān)控做不做得到位。上線不是終點運維才是真正的日常。6. 沒有實體DCS環(huán)境怎么驗證集成方案6.1 DCS學(xué)習(xí)版、仿真環(huán)境與虛擬化做MES或者做集成服務(wù)的團(tuán)隊手里經(jīng)常沒有真實的DCS環(huán)境但這不代表集成方案沒法驗證。一個路子是用廠商的學(xué)習(xí)版或培訓(xùn)系統(tǒng)。中控、和利時、西門子這些DCS廠商都有面向工程培訓(xùn)和教學(xué)的軟件包比如中控的DCS學(xué)習(xí)版可以跑組態(tài)和仿真邏輯能讓你理解DCS的組態(tài)方式、點位結(jié)構(gòu)、歷史趨勢導(dǎo)出邏輯。這些環(huán)境和真實控制器肯定有差距但拿來做集成聯(lián)調(diào)、跑通點位訂閱和數(shù)據(jù)落庫完全夠用。另一個路子是自建基于OPC UA的仿真DCS。有開源的OPC UA協(xié)議棧比如open62541配合一些數(shù)據(jù)模擬腳本可以生成各種工藝參數(shù)的仿真曲線。你可以在上面練習(xí)OPC UA客戶端開發(fā)、點位瀏覽、訂閱、歷史讀取甚至模擬壞質(zhì)量值和設(shè)備斷線。這樣練出來的經(jīng)驗和現(xiàn)場遇到的問題幾乎是同一套邏輯。6.2 用模擬器搭一個最小聯(lián)調(diào)環(huán)境具體搭建一套最小聯(lián)調(diào)環(huán)境不需要太多東西。核心組件是三個一個能模擬DCS數(shù)據(jù)的OPC UA服務(wù)器、一個集成中間件、一個MES側(cè)的接收端。OPC UA服務(wù)器可以用Prosys的OPC UA Simulation Server它自帶一批模擬信號點支持修改數(shù)值范圍、模擬質(zhì)量變化配置簡單二十分鐘就能跑起來。集成中間件可以用開源的Neuron工業(yè)網(wǎng)關(guān)或者Ignition計算平臺的Maker版前者偏網(wǎng)關(guān)采集后者偏SCADA和集成開發(fā)看你的技術(shù)棧偏好。MES端如果只是做接口驗證可以先用一個MQTT訂閱客戶端或者數(shù)據(jù)庫寫入腳本模擬不一定非要有一套完整的MES系統(tǒng)。這套環(huán)境跑通以后你已經(jīng)驗證了技術(shù)路線的可行性點位訂閱、實時傳輸、數(shù)據(jù)落庫。剩下的業(yè)務(wù)流程對接可以先用一張業(yè)務(wù)表來模擬工單和批次的關(guān)聯(lián)等真實系統(tǒng)接入時再做映射。這樣做的價值是集成方在項目進(jìn)場前就能把大部分技術(shù)風(fēng)險消化掉到了現(xiàn)場就能把精力集中在業(yè)務(wù)溝通和點位確認(rèn)上而不是在配置OPC客戶端上花掉第一個星期。6.3 給做集成服務(wù)的朋友一點建議最后聊一點個人經(jīng)驗。做DCS和MES集成技術(shù)難度其實沒有到高精尖的程度真正的難點在于你要同時應(yīng)對三種人DCS工程師關(guān)心的是別影響我的控制程序MES產(chǎn)品經(jīng)理關(guān)心的是業(yè)務(wù)數(shù)據(jù)對不對生產(chǎn)管理人員關(guān)心的是你千萬別讓我多干活。集成實施者夾在中間既要懂一點工藝又要懂一點通信還要有一點項目管理的耐心。我的體會是提前讓三方坐在一起把點位表和數(shù)據(jù)字典定下來比任何技術(shù)方案都重要。方案選錯了還能改語義沒對齊后面全是扯皮。排期上一定要留足夠余量聯(lián)調(diào)時間永遠(yuǎn)比想象的長網(wǎng)絡(luò)環(huán)境永遠(yuǎn)是別人說了算的DCS工程師永遠(yuǎn)有自己手頭的活要干——這些我都踩過。希望這篇文章能幫你省下幾步彎路把精力留到真正有價值的數(shù)據(jù)治理和業(yè)務(wù)優(yōu)化上去。