介紹
多年來，使用基於製造運營管理 （MOM） 的應用程式的製造 IT 顧問試圖說服制造商這些型別的應用的高價值。實時 MOM 解決方案是唯一一組能夠精確優化工廠日常運營的 IT 應用程式，可為其可用性流程帶來可創造的價值，但製造商在認識到實施 MOM 的任何給定部分所產生的可操作指標與用於可見性和介面的定期關鍵績效指標 （KPI） 之間的差異方面上進展緩慢。
決策者通常非常不願意在他們的工廠或企業中開始任何型別的MOM實施，因為這些專案的規模很大，風險很高，成本很高。從歷史上看，由於客戶對軟體的瞭解不夠，許多 MOM 專案在按時或按預算結束時都存在重大問題。這通常是由於專案中的某個人，無論是銷售人員、程式設計師，甚至是客戶，試圖在解決方案的第一個 MOM 專案中使解決方案 100% 地滿足客戶的需求。所有各方都不同意可實現的MOM專案和功能路線圖。因此，專案參與者往往忽視了專案的真正和可實現的目標。
本文中描述的 I3 概念基於眾所周知的標準，包括 ISA-95 和 B2MML，併為企業資源規劃 (ERP) 系統和過程控制系統之間的整合新增了一些進一步的功能。
本文描述了 I3 方法，並提供了一個如何在“現實生活”中應用標準的示例。
MOM 專案受到運營部門和企業集團之間相互衝突的優先順序的影響，因此當目標在時間功能範圍內相距甚遠時，保持專案重點總是很困難的。當專案團隊不關注近期目標時，最初的目標幾乎永遠不會實現。
在 MOM 領域，公司面臨著“永恆的軟體困境”，使用商用現貨 (COTS) 軟體工具應用簡單的解決方案，只需配置（無需程式設計）即可執行專案功能和任務；節省大量開發時間和資金（但會增加介面和報告成本），最終得到僅滿足您 80% 需求的解決方案，或應用程式設計工具並修改解決方案以完全滿足您的需求，儘管這樣做需要大量的程式設計、較長的時間和良好的架構技能。
在I3方法論，這兩者都有一些元素——一些標準軟體和一些程式設計。
最好的做法是從小處著手解決文化採用和一致性問題，然後將功能擴充套件到路線圖，而不是強迫公司實施所謂的全面 MOM 解決方案。本章節中詳細介紹了一種稱為“智慧整合介面”(I3) 的專案方法。
MOM 專案和功能路線圖對於長期（例如，X年）業務目標和/或包含專案利益相關者需求的已定義和指定策略的成功至關重要。有了這樣的路線圖，專案成員就可以將這些目標和策略作為專案中的指導里程碑，並隨時重新審視它們以確認它們是否走上正軌。
但要在預算內按時實現指導性里程碑，應始終明確定義短期目標並進行有效溝通，以便容易看到和實現這些目標。
在 I3 專案中，任何 MOM 解決方案的核心功能都在 IT 系統之間的整合中得到解決，以簡化實施以適應客戶的業務需求。基於已建立的整合基線，當客戶及其組織準備好並需要擴充套件時，可以稍後擴充套件該功能。這是讓客戶通過全面的 MOM 解決方案取得成功的最可靠和最安全的方式的最佳實踐。
無論解決方案提供商是軟體供應商還是獨立於軟體的諮詢公司，本文中描述的許多相同問題在每個專案中都會面臨。
從製造商到製造商，甚至從工廠到工廠，MOM 領域中的解決方案在規模和複雜性上都大不相同。
本文是 MESA/ISA-95實踐的一部分，描述了開發基於 ISA-95 MOM 標準的製造運營管理系統的實踐。
說服和教育基於MOM的解決方案
ISA-95 標準詳細地描述了相關領域測層次。然而，這個過於簡化的數字經常用於與 MOM 相關的文章和銷售演示。因此，在看過許多這些簡報的生產經理的心目中，這就是 MOM 系統或體系結構的外觀和工作方式。在生產經理的心目中，MOM 解決方案只是安裝在 ERP 層和過程控制層之間的“白盒”。
在許多公司，經驗豐富的 MOM 顧問多年來一直試圖說服工廠經理和生產經理，MOM 解決方案是優化其日常運營和增加業務價值的唯一解決方案。MOM 系統被宣傳為包含唯一有效的功能集來控制工作流程變化和最小化浪費。通過事件和警報驅動的響應，MOM 系統使用可操作的指標來最小化異常條件或次優操作狀態的影響。
在分析他們工廠中已有的功能型別後，製造商發現大部分 MOM 功能（根據 ISA-95 的定義）已經存在，甚至可能在工廠經理或生產經理都沒有意識到的情況下。但是，不同系統之間沒有適當的整合，整個工廠也沒有通用、一致的定義。該功能通常分佈在許多不同的系統上，包括基於紙張的、文書處理、電子表格和資料庫應用程式——一些是商業產品，另一些是由員工建立的。如果工廠人員被問及用於質量保證、維護、可追溯性等的軟體應用程式，他們通常會說公司使用 Excel、資料庫或為此目的設計的 COTS 軟體包來處理 MOM 功能和任務。
實際上，運營商並沒有意識到他們的 ERP 系統和過程控制系統（ISA-95 模型中的第4層和第2層）和其他周圍系統之間，以及內部不同 ISA-95 第 3 層系統之間的巨大整合差距的大小。公司可以從彌補這些差距中獲得巨大價值，因為他們將受益於在所需響應時間內交換所需資料的自動化介面，從而最大限度地減少意外事件的影響。自動化資料收集和介面消除了生產區域的紙質表格和手動資料輸入（隨之而來的轉錄、打字和翻譯錯誤），以提供可靠、實時的資訊作為決策依據。
從軟體提供商的角度來看，縮小整合差距的一種方法是向公司出售一種新的 MOM 解決方案，該解決方案將替代或替換所有這些不同的“不同資料的 MOM 孤島”。但是，最佳實踐是建議從小處著手，首先將一組高價值系統整合到階段 1 MOM 解決方案中。第 1 階段 MOM 解決方案根據商定的 MOM 路線圖與具有可防禦投資回報 (ROI) 的小專案一起發展，從而在公司裡建立對 MOM 解決方案的更多理解和接受。
在採用這種方法的情況下，從核心 MOM 功能開始的建議，應基於在規劃層（ISA-95 中的第 4 層）和過程控制層（ISA-95 中的第 2 層）之間建立一個整合基線。因此他們可以以智慧高效的方式交換資料。I3 方法比僅僅整合或連線系統更進一步；它還為解決方案增加了一些智慧，以便在工廠運營中有效執行和響應。
這就是 I3 作為整合概念發揮作用的地方。
I3 是什麼？
I3 概念基於將軟體功能塊置於規劃層和控制層之間，形成 MOM 解決方案（ISA-95 中的第3層）。I3涵蓋了製造運營的某些部分（ISA-95 中的第 3 層）和 ISA-95 第 3 部分中定義的一些生產運營管理活動模型。這將在本文後面進一步描述。
該解決方案由以下三層構成：
- 第 1 層 - 介面
該層處理與控制層中不同型別的軟體系統和硬體元件之間的通訊。如果需要和需要，該介面層還可以處理與其他周圍系統的通訊。
- 第 2 層 — 佇列
第 2 層接收、排隊和處理從介面層快速傳入的資料。它儲存資料，直到業務邏輯層準備好處理它們並將訊息序列儲存到下一層。
- 第 3 層 - 業務邏輯
業務邏輯層從佇列中取出訊息，主要處理與ERP、產品生命週期管理（PLM）、供應鏈管理（SCM）或客戶關係管理（CRM）等企業系統的通訊。但除了與這些系統的基本通訊外，如果通訊中出現問題，該層還提供“智慧”錯誤和/或異常處理。如果需要，該層還可以提供用於監控制造操作的視覺化和各種儀表板。該層是該解決方案中最“智慧”的層，也可以描述為異常處理層。
這三個層將在以下各節中進一步詳細描述。
介面（第 1 層）
該模型中第 1 層的主要功能是與過程層中的控制硬體進行通訊。以及其他周邊系統：
- 可程式設計邏輯控制器 (PLC)
- 操作皮膚（OP皮膚）
- 其他 I/O（條碼閱讀器、條碼印表機、秤等）
其他可能接收資訊的周邊軟體系統：
- 監督控制和資料採集 (SCADA)
- LIMS/QA 實驗室資訊管理/質量保證）
- 分散式控制系統 (DCS)
- 計算機化維護管理軟體 (CMMS)
- 包含 ISA-95 第 3 部分中定義的功能的其他系統
從圖 7-1 的底部開始，第 1 層，介面，通過“I/O 通訊”塊從控制層硬體和軟體接收過程資料或事件記錄。在與生產車間的 PLC 等過程控制硬體進行通訊時，OPC 伺服器可以大大降低與生產車間的過程控制硬體的通訊難度。通常，需要與更簡單的硬體或其他軟體系統進行 MOM 通訊；因此，I/O 通訊塊處理例如序列介面和基於檔案的介面。
“確定 事務/命令”塊獲取傳入訊息，提取所需的命令/事務型別，並確定訊息來自流程行中的何處。
在通過“提供命令”塊將其傳遞到佇列（第 2 層）之前，“為命令附加Id”塊中的命令虛擬地附加了一個唯一 ID。ID 標識哪個裝置或軟體系統傳送了命令。該資訊本地儲存在“提供命令”塊中供以後使用。
“提供命令”塊簡單地接受命令並將其放入層佇列。由於佇列基於資料庫中的表，“提供命令”塊使用普通的結構化查詢語言 (SQL) 插入命令。
第 1 層檢視第 2 層佇列以檢視是否有準備處理的結果或訊息。這是在圖右側的“獲得下一條訊息”塊中完成的。
圖 7-1：第 1 層，介面
上述唯一 ID 用於“結果Id”塊中，通過“I/O 通訊”塊將結果或訊息引導回正確的裝置。訊息傳送後，標誌重新設定到“獲得下一條訊息”塊中，指示 I/O 通訊塊已準備好處理下一條訊息。
當然，其他功能，如視覺化、報警處理和資料採集，也可以新增到這一層。
第 1 層通常基於 Wonderware、Rockwell、Siemens、GEIP 等公司的 SCADA/HMI 軟體包等標準軟體。
佇列（第 2 層）
佇列層被新增到解決方案中，以將 PLC 和 SCADA 系統的“實時”世界與業務邏輯事務的較慢世界（一個非常重要的功能）分開，而不會丟失傳入訊息的順序（先來的）從第 1 層開始。在大多數 MOM 解決方案中，維護事件的順序尤為重要。因此，佇列層實現為先進先出 (FIFO) 佇列。
作為獎勵，佇列層會緩衝訊息/事件，以防與 ERP 系統或過程控制級別的連線丟失。
佇列層實際上分為兩個佇列：
- 生產計劃
- 生產業績
生產效能佇列包含與來自流程的事件相關的訊息，而生產計劃佇列包含要從 ERP 系統傳送到流程的訊息。兩個佇列的名稱取自 ISA-95 標準。
第 2 層的功能可以程式設計，但也可以由 Microsoft Message Queue、IBM 的 MQ 系列或類似的標準中介軟體處理。
在 MOM 專案中，最佳實踐是根據 ISA-95 對生產進度和生產效能的定義，在資料庫結構中構建第 2 層的兩個佇列。
如前所述，第 1 層中的“提供命令”塊從物理過程中獲取訊息，並將資料插入到資料庫的生產效能表中的正確表中。
第 1 層的“獲得下一條訊息”塊從資料庫的生產計劃部分的不同表中獲取新訊息。
當然，像 ISA-95 這樣的 MOM 標準的優點之一是，國際標準使得更改周圍層之一（例如，使用標準中介軟體或最新版中介軟體）變得更加容易，只要新層其資料結構和介面符合 ISA-95 標準。
業務邏輯（第 3 層）
溝通
I3 概念的第 3 層充當與 ISA-95 模型的規劃級別（第 4 層）的主要通訊介面。該介面必須基於現場或公司的 ERP 系統來實現。一些ERP系統直接支援基於ISA-95的標準協議B2MML，這使得直接從佇列層中基於ISA-95的表中處理資料變得更加容易。例如，其他 ERP 系統使用高階程式設計介面 (API) 或基於檔案(CSV、XML)的介面。
確定推薦和應用的協議取決於具體的 ERP 系統、公司的雄心和專案的規模。
如果可能，與I3介面的最明顯方式是使用 B2MML，因為 MOM 解決方案的資料庫基於 ISA-95 結構。但與解決方案的其餘部分一樣，沒有必要使介面變得比滿足專案需求所必需的更復雜。在某些情況下，基於文字檔案的簡單介面可能綽綽有餘。通過分析現在和未來介面的完整業務需求，並選擇合適的介面協議，流程和系統的適應性可以成為設計的一部分，從而顯著降低解決方案的總擁有成本。
錯誤處理
第 3 層包含檢測通訊錯誤（例如，與 ERP 系統的連線丟失）和在傳送/接收的訊息內容不正確時處理資料錯誤的能力。
為了使這一層正常工作，首先要實現的事情之一是能夠真正意識到從通訊對方返回的訊息中存在錯誤。ISA-95 的第 5 部分描述瞭如何以標準化方式處理此特定功能。在第 5 部分中，訊息接收器（正在處理資料）被定義為響應一條訊息，說明請求是被接受、拒絕還是修改。
在本文後面的實際示例中，這正是處理通訊錯誤所需的功能，這些錯誤最初是在解決方案的每個新專案中手動定義和程式設計的。
業務邏輯
第 3 層最重要的功能是用於處理預期情況或用例的規則集。特殊和定製的規則（“邏輯規則”）處理日常運營和業務中需要公司或站點特定決策的情況，其中公司的手動程式無法在沒有代價高昂的損失的情況下覆蓋這種情況。如今，很多公司都會向操作員或管理層傳送有關此類錯誤的警報，然後一個人做出決定並進行流程、工單、設定點等的手動調整。
第3層儘可能地自動化對不同錯誤場景的響應。
如圖 7-2 所示，每當“準備接收下一條訊息”標誌被設定時，“獲得下一條訊息”塊用於從第 2 層的資料庫表中選擇下一條訊息（由時間戳確定）。“確定事務”塊獲取訊息並解碼處理訊息所需的 ERP 事務。接下來，區塊取出訊息的相關引數，將交易傳送到ERP系統。如前所述，所使用的協議取決於 ERP 系統。
圖 7-2：第 3 層，業務邏輯
當收到來自 ERP 系統的“結果”訊息時（自動。通過輪詢資料，或通過其他功能——同樣取決於實現的介面），“錯誤處理”塊首先檢測它是否是異常（不是錯誤）訊息或返回錯誤。
如果是正常訊息，則“提供訊息/結果”塊將資料寫回到正確的第 2 層表中，從而設定“準備接收下一條訊息”標誌。
如果 ERP 系統返回錯誤訊息，則啟用“業務邏輯”塊。業務邏輯塊嘗試自動處理這種情況，然後（如果需要）向 ERP 傳送不同的事務。
一般來說，這一層應該能夠處理本地（特定於站點）的規則。業務邏輯層還處理全域性（企業範圍）規則，例如公司的質量保證規則是否允許將正常物料放置在已儲存環境監管物料的儲存箱中。
業務邏輯層的一大挑戰是業務邏輯規則（當然）非常不同，並且從一家公司到另一家公司，有時甚至在同一家公司的各個站點之間是非常不同的。因此，很難將許多功能從一個專案重用到另一個專案。從歷史上看，該層及其塊因此已針對每個專案進行了程式設計。
例子
應用業務邏輯層的情況有很多種（錯誤場景）。下面描述了這些情況的一些示例。
- 示例 1：機器在生產線上發生故障。首先，必須決定是否應暫停或在另一臺機器上處理生產或工作單元訂單。如果要在另一臺機器上加工，則必須確定替代路線和/或機器。然後，必須決定是否需要更改生產計劃，例如將訂單拆分為較小的批量或將訂單合併為較大的批量。此示例中的某些特定功能可以（並且經常）由配方或路線建模軟體直接涵蓋，但如果不存在此類外部功能，則決策邏輯會自動涵蓋，無需操作員干預此塊。
- 示例 2：通常需要業務邏輯來管理連續加工設施（如動物飼料廠或麵粉廠）中的儲存位置。
例如：當 ERP 系統想要將物料裝入特定的料倉時，許多經驗豐富的 MOM 整合商都會猶豫究竟應該使用哪一種方案。
- 示例1：根據 ERP 系統，特定的料倉有足夠的空間來裝運物料，但實際上（由於物理測量不準確或物料粘在內部）料倉在所有物料全部裝滿之前實際上已滿。 MOM 業務邏輯層需要自動決定剩餘物料將被引導到哪個倉，並使用所有批次的實際數量和位置更新 ERP。此決策和邏輯取決於許多加權因素，例如，之前可用垃圾箱中的內容（以避免物料交叉汙染或避免混合受環境監管的物料和正常物料）或基於對下一個容器的瞭解的最佳位置解除安裝物料。
- 示例2：將穀物接收到 100 噸倉中後，倉“高”容積感測器感應到倉已滿，並將“100 噸”報告回 ERP 系統。一段時間後，物料會壓縮成較小的體積。操作員實際檢查料箱以觀察現在有更多物料的空間，因此他手動將更多物料導向該料箱。然後，過程控制系統報告物料已移至（根據 ERP 系統）已經裝滿的料箱。同樣，MOM 業務邏輯層需要使用所有批次的實際數量和位置自動更新 ERP。
- 示例 3：業務邏輯塊處理的一個常見問題是當大量物料相互分層時的批次跟蹤。場景是批次 2 被物理新增到已經包含批次 1 的垃圾箱中。實際上，包含分層批次的垃圾箱在排放過程中以錐形形式相互作用，其中兩種物料發生了少量混合。這種型別的混合流變很難在任何型別的軟體中建模和程式設計邏輯，因此通常選擇其他兩種模型之一。
“偽物料”（1+2）邏輯模型在兩層之間使用“偽物料”層（data-wise）來覆蓋兩種物料的混合，需要當物料從料倉流出時放置。
後進先出 (LIFO) 模型表示物理裝入料箱頂部的新物料在邏輯上（資料方面）始終放置在料箱底部. 實際上，這與實際發生的情況很接近，但物理混合流變學很難在物料可追溯性應用中建模和實施。
為了定義這些型別的站點或公司特定場景的規則，必須通過一系列工程來完成經驗建模，以對物理過程的工作方式以及它們應該如何建模和程式設計進行徹底的分析應用。
需求分析
當要對業務邏輯層進行程式設計時，一個挑戰是讓客戶以可程式設計的形式實際定義他或她的業務和運營邏輯規則。如果它們不是 100% 定義的，則無法將它們程式設計到解決方案中。
根據專案的複雜性，有多種定義和指定規則的方法。在一些簡單的情況下，客戶直接快速地說明規則是什麼。但大多數情況下，必須對業務、運營和物理流程進行徹底分析，以確定互動、依賴關係以及不同情況的處理方式。對於業務和運營流程，業務流程管理 (BPM) 方法將業務規則和流程描述為“公認地”。對於物理過程，必須通過一系列工程測試來完成經驗資料的收集和建模。通常應用實驗設計 (DOE) 方法。本文不涉及 DOE 方法和經驗建模。
定義業務和運營邏輯規則的第一步，是使用由終端使用者工作組組成的流程操作團隊。他們由製造組織各個層次和職能的人員組成。該流程行動團隊描述了公司如何處理流程、資訊流、錯誤處理等。這些討論產生了 BPM 圖。MOM 的 BPM 圖以圖形方式顯示業務和運營如何處理不同的日常情況以及要使用的規則。這使得在此處描述的解決方案中更容易實現規則。
將 I3 對映到 ISA-95
I3 概念的核心部分在很大程度上依賴於 ISA-95 標準。
在第3層內以及第2層和第4層間定義運營管理功能、任務和交換的標準是全球製造商設計下一代 MOM 解決方案的絕佳方法。
ISA-95 標準中的一些模型解釋了 I3 的功能如何對映到標準。圖 7-3 顯示了 ISA-95 第 3 部分中描述的生產運營管理活動模型的哪些特定部分已在解決方案中實施。
圖 7-3：生產運營管理的活動模型
使用“生產資料收集”是因為生產資料是從流程中收集並交換到 ERP 系統的。之所以使用“生產跟蹤”，是因為已向 ERP 系統報告了所用資源（物料、位置和機器）和生產物料（中間和成品、實際與計劃）的摘要。
“生產排程”的一小部分是通過為操作員提供一個簡單的生產訂單排程列表來使用的。
可以使用 B2MML 訊息與 ERP 進行通訊，以建立公司對預定義介面的整合基線標準。在某些情況下，B2MML 介面可以從 ERP 系統通過 I3系統應用到過程控制系統。當然，如果以後需要，這可以更輕鬆地從一個系統更改為另一個系統 (ERP-I3-PCS)。
結論
從任何 MOM 解決方案的核心功能（IT 系統之間的整合）開始，將使專案和解決方案變得簡單，使其適應製造商的當前需求，同時以更低的成本滿足未來的需求。如果這樣做，隨著全球市場推動製造商組織的變化，擴充套件功能可能會被迅速部署。製造商的成功歸功於適應性強的 MOM 和整合解決方案本身。由於 I3概念是在模組中構建的，因此構建所需的內容然後稍後新增功能非常簡單。只需“離線”將功能新增到正確的模組，測試功能和介面，然後交換舊模組和新模組。
所描述的概念 (I3) 最適合已安裝 ERP 系統和過程控制系統（負責大部分執行部分）並且只需要兩者之間的通訊介面的工廠。
儘管 I3是解決製造過程和 ERP 系統之間通訊問題的簡單方法，但在一些現場實施此解決方案仍然可能是“矯枉過正”。I3應該被視為基於未來功能需求的選項，即使介面保持更簡單，例如，可能不需要處理該站點的業務邏輯和/或異常。
另一方面，如果處理業務邏輯的需求非常複雜，建議考慮標準化的現成解決方案，而不是嘗試從頭開始對解決方案進行程式設計。這將為公司節省時間和金錢。
如果製造商擁有從頭開始實施系統的新建工廠，在這種情況下，通常最好的方法是從核心功能開始，然後擴充套件功能。
本文中描述的解決方案不是“產品”。它只是一種處理生產和 ERP 之間介面的方法或概念，許多創新制造商已成功應用。從一個專案到下一個專案已經並且將會有一定數量的重用。但是在新專案中，需要對 MOM 和介面要求進行分析，以確定必要的功能並決定 I3是否是最佳方式。
MOM 轉型路線圖對於長期（例如，X年）業務目標以及包含專案利益相關者需求的已定義和指定戰略的成功仍然至關重要。如前所述，始終牢記總體目標和畫面，並對公司現在的業務需求、未來的預期以及系統的價值進行初步分析，這一點至關重要。可以在X年內找到（即定義指導里程碑）。如果您不瞭解或不瞭解 MOM 解決方案的可能性以及可能存在的陷阱（例如，整合許多不同的 IT 系統），這將很難甚至不可能做到。
因此，製造商的最佳做法是與經驗豐富的 MOM 顧問合作，他們以前嘗試過類似的事情，並且可以將解決方案引導到正確的方向。