在製造業的工業2.0中應用MOM系統

介紹

什麼是製造運營管理 (MOM) 系統和 IT 架構的最佳實踐？

行業專家對製造型別和供應網路有何建議？

管理思維和企業文化是否因不斷變化的全球市場而過時？

MOM 技術是否過於昂貴，IT 架構是否無法快速適應市場變化？

長期以來，製造企業一直不願為運營工作流程採用新思維。在工廠裝置不斷髮展的同時，支援智慧裝置的工作流程仍然主要基於紙質交易來執行生產訂單，彷彿在說：“我們的方法已經執行了多年，為什麼現在要改變它們？” 有了這種想法，智慧技術的世界已經向前發展，並將製造公司甩在了後面。全球很少有製造公司能跟上智慧操作方法的最新發展，只有真正進步的公司才採用這些智慧製造發展，通常是通過 10 到 15 年的試錯過程。

正如 2008 年 Aberdeen Group 和 2010 年 MOM 研究所示，這些 20% 的“同類最佳”進步公司通過更快、更輕鬆地適應市場變化而勝過競爭對手。它們不受難以更改的不靈活的遺留系統或阻止應用程式更改和更快推出新產品的眾多“點對點”介面的限制。他們的 MOM 系統的靈活性使他們能夠產生更高的整體裝置效率 (OEE) 並增加完美訂單，從而降低了工廠運營和供應鏈現金到現金的成本。他們靈活的 MOM 系統使他們能夠實時響應制造指標，並通過更好的溝通來實際改進運營，從而減少浪費並提高效率。這些公司的製造軟體應用程式的總體擁有成本 (TCO) 通常也較低，從而進一步降低了運營成本並提高了競爭優勢。

不幸的是，大多數製造公司正處於一種真正令人悲哀的境地。非進步公司的製造技術專家，即組織中負責實施和維護製造執行系統 ​​(MES)、MOM 和自動化等製造技術的人員，顯然通過專注於基於部門的單點解決方案而讓他們的公司失望。然而，這不僅僅是製造技術人員的錯。製造技術供應商以及沒有遠見卓識的老式終端使用者管理，必須首當其衝。

大多數製造系統供應商寧願將他們的研究資金花在改進他們當前（通常是過時的）的架構和為過時的軟體新增新功能上，而不是開發新的、漸進的架構。將整合技術作為應用程式的一部分，而不是將其從應用程式中抽象出來並將其作為 Web 服務提供，這也是一個更好的商業案例。如果整合可以作為服務提供，那麼客戶為什麼要在擴充套件時“拆除並替換”或繼續支援已安裝的應用程式？即使多年前 OLE for Process Control (OPC) 出現，這種想法在少數分散式控制系統 (DCS) 供應商和自動化協會中仍然盛行。只有在進步的終端使用者開始請求（甚至堅持）OPC 連線性之後，OPC 才成為自動化級別的事實上的標準。

根據Aberdeen 的研究，80% 以上的終端使用者製造技術人員不知道什麼是更好的；他們接受技術供應商告訴他們的有關服務支援的任何內容並且不再考慮它，因為他們經常被供應商軟體所謂的“新的和改進的”功能所矇蔽。

那麼，終端使用者製造技術人員和製造軟體供應商（MES/MOM 供應商）需要改變什麼思維？

這些小組需要接觸由 Gartner Group 開發的 Manufacturing 2.0 (Mfg. 2.0) 的思想和概念，然後得到 MESA 和 ISA-95 Best Practices 等行業組織的案例研究和最佳實踐研究的支援工作小組。一旦製造公司開始要求基於 Mfg. 2.0 架構的靈活 MOM 系統，供應商將不得不效仿（如上所述，即使是 DCS 供應商最終也會接受 OPC 連線，即使不情願）。

本文探討了上述“同類最佳”進步公司必須克服的四個主要觀念和障礙，如此才能使其 MOM 系統架構被企業廣泛接受為公司戰略。

本文討論了四種障礙或看法，以證明終端使用者製造技術人員和供應商的思維不是主動進取的，而是被動的。這些是：

1. 為什麼是 MOM 而不是 MES？

2. 為什麼在製造業中使用面向服務的架構 (SOA)？

3. 為什麼選擇將MDM用於製造業？

4. EMI 的最佳定位是針對商業智慧 (BI) 還是與商業智慧 (BI) 搭配？

對於這些概念中的每一個，它們的含義和適合的位置都將被單獨探索，以使製造技術人員瞭解這些概念以及接受並朝著這一願景努力。本文最後評估了多年來使用的不同整合方法，並將它們與當前提出的“最佳實踐”和 Mfg. 2.0 進行了比較。

為什麼是MOM而不是MES？

新的思維早已經超越了老舊的 MES，進入了製造運營管理或 MOM（包括 MES）領域。

製造運營管理本身並不是什麼新鮮事物；它的存在時間比 MES 還長。新的是 MESA 和 ISA 採用了 ISA-95 標準中的 MOM 定義，而不是“舊”的 MES 概念。

是什麼讓 ISA-95 MOM 與眾不同？ISA-95 MOM 包括許多運營活動和功能，這些活動和功能傳統上不是 MES 的一部分，因為它由 AMR Research（Gartner Group）定義。ISA-95 MOM 的覆蓋範圍也比 MESA 在 1990 年代開發的傳統 11個域要廣泛得多。不能使用這些過時的 AMR 或 MESA 模型來指導和設計系統。另外，MES這個詞，雖然年代久遠，但一直讓人迷惑不解。如果請 10 個人定義他們理解中的MES，請準備好獲得 10個不同的定義的情況。另一方面，MOM 更容易定義，因為它使用 ISA-95 第 3 部分 (MOM) 標準中的框架。

APICS（運營管理協會，前身為美國生產和庫存控制協會）將運營管理定義為：

1. 將投入轉化為成品和服務的活動的計劃、排程和控制。

2. 重點研究領域。通過研究設計工程、工業工程、管理資訊系統、質量管理、生產管理、庫存管理、會計和其他影響功能的概念，對製造或服務組織進行有效的計劃、排程、使用和控制組織的運作。

3. 製造執行系統是參與車間控制的程式和系統，它使用： (1) 用於直接和監督控制製造裝置的程式邏輯控制器和過程控制計算機；(2) 收集歷史效能資訊，然後生成報告的過程資訊系統， (3) 圖形顯示；(4) 警報/告警/觸發器，通知操作人員工廠當前和最近發生的情況。

根據 ISA-95 第 3 部分的定義，還收集質量控制資訊，其中實驗室資訊管理系統：（LIMS）或質量管理系統（QMS）可能是此配置的一部分，以將工作流程和轉換流程條件與質量資料聯絡起來. 從而可以確定、分析因果關係並主動將其程式設計到系統中。這就是製造智慧。有時，質量資料會影響用於滿足產品規格的控制引數，無論是動態的還是離線的。MOM 系統可以是支援此功能的任何系統。

ISA-95 MOM 的標準定義為指定系統的功能、任務和資料交換提供了所需的框架。ISA-95 第 3 部分將 MOM 定義為“製造設施第 3 級內協調製造中的人員、裝置和材料的活動、功能和交流。” 它包括生產運營管理、維護運營管理、質量運營和庫存運營管理（見圖 1-1，第三層）。

儘管自 2000 年以來它一直在 ISA-95 中，但只有中等數量的製造技術人員和數量有限的供應商已將 MOM 接受到他們的解決方案中。積極構建和支援 ISA-95 MOM 的工作的更少，而堅持使用過時的術語 MES的更多。

在一般小組討論中對術語“ISA-95 MOM 系統”的思考和使用向聽眾表明，技術專家或供應商可能實際上已經閱讀、看到或聽說過 ISA-95 標準。

圖 1-1：製造公司的 ISA-95 功能層次模型

為什麼在製造業中使用面向服務的架構 (SOA)？

製造公司落後的下一個證據是他們缺乏基於標準的整合願景。控制MES/MOM級別的技術標準化與基於整合的願景不同。由於使用點對點介面和缺乏協調的資訊模型，這種缺乏會導致大資料完整性問題。“復刻和替換”計劃不是基於標準的整合願景。對於大多數公司來說，這些標準化舉措是成本過高且不切實際的。

什麼是基於標準的整合願景？

首先，這是一個願景，其中資料傳輸和傳輸功能從應用程式本身抽象到基於標準的服務層，作為獨立於不斷變化的業務流程執行的製造資訊模型。

那些參與過企業整合專案的人認為這是面向服務的體系結構（SOA），但SOA通常是製造業中的一個髒話- 不是因為這個概念不合理，而是因為製造技術專家及其供應商對SOA的瞭解不夠，無法接受它，並與希望在製造業中應用SOA技術的企業架構師合作。畢竟，基於專案思維，點對點整合比長期實施基於 SOA 的整合要快得多、容易得多。製造技術人員寧願保護自己的整合願景，將企業架構師排除在外，也不願嘗試理解和應用該技術。製造工程和企業 IT 之間的這種文化差距是一個長期存在的戰場。

大多數製造技術人員認為，將SOA概念應用於製造業是令人髮指的，而且永遠不會奏效。大多數與企業架構師交談過的人都意識到，企業架構師只是不瞭解製造環境的複雜性。因此，製造技術人員長期以來一直對任何 IT 架構討論持懷疑態度，例如作為 SOA 基礎的 Web 服務。但持懷疑態度的製造技術人員必須根據 Gartner 和 MESA 瞭解 SOA 的實際作用，然後思考它如何應用於製造業，特別是MOM。製造系統技術人員和企業 IT 之間分歧的最終結果是，基於獨立系統的獨立資料模型集的資料完整性普遍較差。因此，當一個典型的工業工廠需要 15 到 20 個系統來處理一個生產訂單時，資料損壞是常態，因為資料被彙總到報告、排程、計劃和供應鏈活動中。SOA允許從獨立的、自描述的和可互換的程式碼模組（稱為"服務"）建立複合業務應用程式。這些服務可在服務匯流排上使用，在服務匯流排上，它們使用流程編排排列到業務流程或複合應用程式中。當SOA被用作整合策略時，它帶來了一個自描述的原子業務服務目錄，這些服務一起用於建立業務流程（包括製造操作流程）。

對於 SOA，我的想法是業務和市場的需求驅動IT系統，而不是IT系統決定業務的執行方式。這帶來了靈活性，這是 MOM 系統的主要要求之一，因為製造要求經常變化。

許多公司（包括製造公司）已經實施了企業服務匯流排 （ESB），專門用於簡化整合。這些 ESB 架構尚未深入到製造本身，這是有充分理由的。企業層（第4層）和製造運營層（第三層）不相同，工作不相同，並且具有完全不同的優先順序、資料型別、事務型別以及業務與操作流程。只有一小部分製造過程資料可以上升到企業級，然後通常僅以彙總形式進行。但是，大量製造過程資料在工廠的 第1層到第3層內共享，以處理 15 到 20 個系統中的單個生產訂單。

由此我們可以得出：“對於 MOM，由於事務數量大、引數資料負載高以及操作應用程式的近乎實時的要求，因此需要單獨的製造服務匯流排 （MSB）。MSB可以縮小到一個工廠或工廠的一個區域，或者跨多個生產設施，具體取決於工廠應用程式支援的操作工作流程的事務/資料負載和響應要求。”

因此，我們需要為工作流程定義製造業SOA（GSOAm），它看起來與支援企業業務流程的SOA非常不同。我們還將在我們的製造企業架構中擁有一個 ESB 和一個 MSB。問題是，我們如何將這個概念賣給企業架構師和製造技術人員？他們每個人都有一個特定的世界視，如圖 1-2：企業 SOA — 正在進行的工作。

SOA 顯示為功能層，如圖 1-2 所示。底層由現有或舊版應用程式組成，這些應用程式為如何使用業務資料奠定了基礎。這些是"任務關鍵型"應用程式，可保持業務的日常執行。下一層提供整合。在 SOA 中，整合層是使用企業服務匯流排 （ESB） 實現的。ESB 層提供安全性、傳輸、中介和事件服務。它還可以提供業務指標和工作流或業務流程引擎。

業務服務（中間）層是服務的抽象層，用於基礎IT系統。這些服務是 SOA 中的工作。它們使用包裝業務應用程式的 Web 服務描述語言 （WSDL） 進行表示。

業務流程層由通過組合業務服務層中的服務以生成複合應用程式而建立的業務流程組成。複合應用程式是在 SOA 中執行應用程式開發的新方法（後面的將更詳細地討論）。

圖 1-2：企業 SOA-A 正在進行的工作“

門戶/儀表板層由資料聚合和視覺化組成。圖 1-2 的問題在於，製造運營（或 MOM）系統只是需要與其他企業系統整合的眾多其他系統之一。然而，對於大多數公司而言，這些其他（非 MOM）系統已經整合並在企業級別執行，其中 MOM 系統是不同的並在工廠或站點級別執行。MOM 系統通常不是每個站點的單個系統，而是可能由多個系統組成，這些系統都基於可用資源執行實時工作流程。這使事情變得複雜，並且是尚未使用基於 ESB 的體系結構整合第3層系統的最大原因之一。

然而，希望是有的，因為有一些案例研究表明，有些公司已經在本文提出的第 3 層內應用了 SOAm。這些案例研究來自 Gartner、ARC、Aberdeen和MESA。

Gartner 和 MESA 在白皮書 #27 "SOA in Manufacturing Guidebook"中提出的 SOAm 體系結構如圖 1-3 所示：面向製造業的 SOA。（SOAm） 一些關鍵的實時差異。如圖1-3所示，架構與該架構密切相關。企業體系結構如圖 1-2 所示。

在圖 1-3 中，MOM 系統被描述為元件，而企業應用程式僅被描述為需要連線到製造服務匯流排的多個系統之一。圖 1-3 強調，如上所述，由於大量事務、高引數資料負載和操作應用程式的近實時要求，因此需要單獨的 MSB。根據工廠應用程式支援的操作工作流的事務/資料負載和響應要求，MSB 可以縮小到一個工廠或一個工廠區域，或者擴充套件到多個生產設施。Mfg. 2.0 的一個關鍵方面是，解釋了製造主資料管理 (mMDM) 不同於企業業務流程ESB 上的 MDM。Mfg MDM 為一組不同的製造運營管理應用程式提供服務，例如排程、路線執行以及警報和事件應用程式，它們比代表企業計劃的 MDM 具有更精細的物件、屬性和生產規則集，（主）排程和物流。

圖 1-3：製造用 SOA (SOAm)：一些關鍵的實時差異

因此，該架構是相似的，但用於不同的目的。考慮到這一觀點，製造技術人員有一個很好的對立面，可以與企業IT架構師討論非特徵化工作流程的實時架構，並向他們傳達企業檢視（圖1-2）和製造檢視（圖1-3）之間的區別。基於優化所需的高度變化，製造技術人員現在可以證明需要將MSB與ESB隔離（即使使用相同的技術）。

那麼，在一家全球企業中，合適的 MSB 數量是多少？每個製造工廠或園區一個？

根據需要支援事務流量？對此我們並不清楚，但每個地理站點至少有一個 MSB 連結到 ESB 是有意義的。如果沒有將MSB作為通用基礎架構元素的架構策略和路線圖，並且不會使任何單個軟體專案承擔安裝MSB本身的負擔，則很難為每個站點實現匯流排。這種缺乏長期的製造架構願景可能是 SOA 作為應用程式概念尚未被廣泛接受的另一個原因。

為什麼選擇將MDM 用於製造業？

很少有製造技術人員聽說過主資料管理 (MDM)，也很少有人瞭解 MDM 的實際含義。這進一步證明了 80% 以上的終端使用者的保守思想。企業解決方案長期以來一直依賴於 MDM 系統來確保不同企業級解決方案之間的命名一致性和資料轉換。製造技術人員甚至沒有考慮過這一點，正如製造系統之間點對點介面的激增所看到的那樣。

在圖 1-2 和 1-3 中應該注意的一件事是每個體系結構中的不同 MDM 元件。MDM 是用於關聯不同應用程式之間的資料的工具。

那麼，什麼是主資料，為什麼它很重要？

“主資料管理 (MDM) 包括一組流程和工具，這些流程和工具一致地定義和管理組織的無事務資料實體（可能包括參考資料）。MDM 的目標是提供用於收集、聚合、匹配、整合、保證質量在整個組織中持久儲存和分發此類資料的流程，以確保在持續維護和應用程式使用這些資訊時的一致性。”

MDM 解決方案中常見的流程包括源標識、資料收集、資料轉換、規範化、規則管理、錯誤檢測和糾正、資料整合、資料儲存、資料分發和資料治理。

為什麼需要區分企業 MDM 和製造 MDM (mMDM)？據 MESA 的說法，在絕大多數情況下，工程物料清單（BOM），路線或企業資源規劃（ERP）或配方/產品生命週期管理（PLM）系統的一般配方缺乏必要的詳細程度：

• 通過共享的商店資源執行詳細的路線。
• 設定批次系統執行的處理邏輯。
• 調整批量大小以匹配本地裝置資產併為這些資產提供有限的容量排程。
• 設定詳細的機器設定。

異構遺留系統、對受控 MOM 系統的信任/不信任、資料所有權問題和資料不一致使這個問題更加複雜。缺乏強大的通用資料架構會促進不受監管的資料定義激增、點對點整合和狹隘的資料管理策略。在製造環境中，所有這些都會轉化為多種型別的浪費和增加的成本。

執行生產流程所需的主資料高度依賴於各個流程、資產和特定站點的考慮因素，所有這些都以比典型的企業流程（例如新產品引入、持續改進、訂單輸入或應付賬款處理）高得多的頻率發生變化。因此，製造主資料混合了與站點級別詳細資訊（例如客戶 ID 或企業訂單輸入系統和工廠之間共享的高階產品規格）以及特定於站點或“本地”的詳細資訊，例如作為裝置執行特性（可能因當地溼度、溫度和驅動速度而異）甚至當地原材料特性。資料要求也可能因文化或國家/地區而異，例如貨車運輸法規、運輸時間和海關要求，這些可能都會影響生產和運輸計劃。

此外，即使物理製造過程相似，財務法規也可能會影響各種工廠運營的佈線、劃分和整合方式，以及原材料轉化為成品的核算方式。

企業主資料與“本地”或製造主資料之間的這種自然劃劃分，建議了選單分解主資料管理 (mMDM) 的特定架構方法，該方法大量借鑑了企業 MDM 模型，但已針對製造環境的特定要求進行了調整。

想想一家隨著時間的推移收購了各種製造實體的公司。它已經整合了其企業系統，但在站點級別，情況有所不同。不同的地點可能對相同的原料有不同的稱呼（例如，11% HCl、鹽酸、池酸、11% 鹽酸），這種相同的原料在批次系統、SCADA 系統、LIMS、儲存系統、排程系統和 MOM 系統中也可能具有不同的名稱。這種一致性的缺乏使得營運長很難從 COO 的角度報告鹽酸的消耗量，因為如果沒有 mMDM，則必須為每個站點和系統定製消耗量查詢，以便提取訂單消耗量。

當然，另一種方法是啟動命名標準化工作，這可能需要數年時間才能完成，因為大多數第2層和第3層的系統都需要進行更改。這甚至沒有考慮到視覺化的重新開發和操作員的再培訓。問題是，一旦命名標準化完成：

• 誰擁有主命名權和命名規則？
• 隨著新產品、材料、流程和裝置的新增和更改，誰確保工廠不會隨著時間的推移再次發生分歧？

上面的例子是一個非常簡單的例子，對於一種原材料，但它也必須應用於其他資源、公用事業、裝置、操作引數、配方、WIP 和產品。否則，資料損壞就是經過驗證的結果。例如，如果一家公司實施了條形碼掃描解決方案，則特定產品或元件的物料編號可能因供應商而異。將此提升到全球層面，考慮一下語言翻譯和當地法規如何影響系統中物件的名稱以及如何對物件進行分類，以及不僅以螢幕顯示物件資料，而且以使用者的本地語言顯示資料的複雜性，同時仍然使資料可用於整合。

系統如何知道哪些產品/元件已收到或已發給工廠，而無需在某個地方進行一些翻譯？

因此，mMDM 解決了當今製造公司在第3層和第4層系統之間實現更靈活整合時遇到的許多問題。

圖 1-4 顯示了 mMDM、MDM、SOA 和 SOAm 之間的關係以及它們如何協同工作。

提議的企業和工廠之間架構拆分的目標是在不降低系統之間整合的有效性和效率的情況下提高應用程式的靈活性。它還將介面機制從應用程式中抽象為無論應用程式發生更改都可以執行的服務。這種方法將阻止許多點對點介面損壞資料，並使系統在適應不斷變化的條件方面更加靈活。

圖 1-4：供應網路是 E-SOA 和 SOAm 的融合

SOAm 體系結構還將業務流程及其編排從各個應用程式抽象到操作業務流程管理層。現在，一個人可以與多個應用程式互動以跟蹤或管理生產訂單，甚至沒有意識到他/她正在應用程式之間跳轉。

圖 1-4：供應網路是 E-SOA 和 SOAm 的融合，闡明瞭 SOAm 角色與企業 SOA 的關係。Mfg 2.0 是一種 SOA 方法，而不是一個在需求驅動的製造業中包含多樣性、複雜性和新活力的應用程式，同時：

• 利用稀缺的製造人才。
• “ 放棄和利用製造業投資，而不是撕掉並用更好的“老鼠夾”取而代之。”
• 消除軟體可用性和僵化資料模型作為構建、部署和採用製造應用程式的障礙。
• 在內部和擴充套件的企業產品和運營流程上進行協作。
• 轉變為擅長以低成本輕鬆更改業務和運營流程的應用程式和治理。

即使使用 SOAm 和 mMDM，除非訊息結構和資料交換採用標準格式，否則整合也不會高效和有效。

這就是 ISA-95 在確保介面有效性和一致性方面再次發揮重要作用的地方。如果沒有標準化的資料交換結構和模式，甚至 mMDM 和 SOAm 都無法實現介面重用。

ISA-95 提供了資訊交換標準以及基於由 World Batch Forum（WBF，現在與 MESA International 合併）開發的企業到製造標記語言 (B2MML) 的標準化資料結構和 XML 訊息模式，包括用於資料交換的動詞和名詞。在整個製造運營中實現標準化可確保開發標準服務以適應多種應用。

EMI 最適合還是反對商業智慧 (BI)？

製造系統思維落後狀態的最後一個證據是企業製造智慧（EMI）在製造業中的採用率緩慢。大多數工廠經理和營運長都希望使用 EMI，但他們的製造技術人員卻無法採用 EMI，而傳統商業智慧 (BI) 技術已在企業層面得到應用。因此，製造業被迫應用並非為實時資料和流程設計的企業 BI 解決方案。這導致了大量失敗的專案以及報告、排程和計劃以及供應鏈中完整性較差的資料。

但是，如果公司已經實施了BI解決方案，為什麼還要實施呢EMI？

要回答這個問題，請參見圖 1-4。在這種隔離的架構中，同時顯示了 BI 和 EMI（圖中稱為 OI 或操作智慧）。EMI 和 BI 有不同的目的，它們針對的是問題集和受眾。表單 MDM 與 MDM 的適用理由相同，因為特定於製造的報告和智慧在BI中資料的內容、上下文和資料頻率是不同的。

BI 解決方案中的資料通常以與 ERP 系統中相同的低頻率進行交易，例如每日價值。對於想要了解輪班或每小時發生的情況的工廠經理來說，BI 是不夠的。BI 工具的設計和實施通常不會考慮製造操作的實時性及其非常高的資料速率。因此，BI 無法處理製造運營所需的高頻率資料接收和報告/視覺化所需的快速響應時間。

高管使用 BI 工具作為公司的戰略分析和決策工具。從他們的 BI 系統中，他們可以看到一段時間內各個工廠和站點的盈利能力，這使他們能夠做出決策，例如是否關閉工廠或改變製造策略。由於它們的資料基於定義的時間段，因此與實時工作流程的 EMI 相比，BI 系統通常處理更容易確認和驗證的數字和結果；高管們希望確保他們在做出決策時擁有準確的資料。

驗證/確認或審計步驟通常會在實際事件和資料最終進入 BI 解決方案之間增加相當長的時間。

然而，現場級生產人員不能等得到稽核和驗證的細節後再採取行動。如果報告或 EMI 儀表板指示出現問題，他們有責任進行調查並採取糾正措施。如果進料率低於計劃，生產經理不會等到明天 BI 系統中等待確認的結果再採取糾正措施。他/她要調查，或者讓其他人調查，如果結果是誤報，一切都很好，危機避免了。如果出現問題，經理會採取糾正措施，或者沒有，否則，經理至少知道並預計明天不會有來自 BI 系統的不良結果。生產主管討厭驚喜，即使是好的驚喜。

因此，EMI 系統具有三個目的：

1. 對潛在問題進行實時預警，以便人員做出決策或採取行動。
2. 提供有關歷史資料的“切片和切塊”資料以改進流程。
3. 為第2層的裝置和第3層的系統的介面定址提供大型庫和方法。

EMI 擁有以個人提供的粒度和頻率提供的資料、應用程式。這可以從幾秒鐘到幾天不等，具體取決於特定的操作要求。資料也可用於每個裝置、生產線或處理單元，並且可以彙總為小時、班次、天或周。EMI 系統的粒度更接近實時，它們通常被用作運營經理的實時儀表板。

整合方法的演變

除了上述問題之外，Mfg 2.0願景採用緩慢的原因是不同的公司以不同的速度發展。製造技術人員的整合願景基於經驗、新思維和企業當前的整合狀態而發展。多年來，隨著技術的改進和發展，整合理論發生了變化並適應了新知識。每個公司在建立願景時都會根據公司的需求採用自己的願景或戰略，很少有公司根據新知識定期審查和更新他們的願景或戰略。

考慮到這一點，ISA、OAGi 和 MESA 等行業組織所宣稱的企業整合“最佳實踐”是什麼，它們是如何隨著時間演變的？

1. 以應用為中心

第一種也是最簡單和最常用的企業整合方法,是“以應用程式為中心”的方法，如圖 1-5 所示。在此方法中，生成程式碼以建立應用程式之間的點對點資料傳輸。由於專案心態，它仍然廣受歡迎，因為它快速且便宜（至少在最初階段）並且現場人員不需要新的培訓。因此，可以在確定需求後立即開始開發。

圖 1-5：以應用為中心的企業整合方法

這種方法的問題在於，新介面通常每次都是從頭開始開發，並且重用率最低，從而增加了開發成本。使用這種方法意味著所有專案都以自定義方式實現。由於系統之間的資料轉換通常是手動或硬編碼的，因此這反過來又很可能導致資料不一致。對一個應用程式的任何更改都意味著需要對介面進行昂貴的自定義更改，並且由於這些介面是自定義開發的，因此它們很脆弱且更改緩慢。由於需要在多個系統之間進行整合，因此需要以不同自定義格式提供相同或類似的資料，因此需要為每個需求開發新的介面。這種自定義點對點介面的激增，常常導致難以管理的介面“義大利麵”效應。當應用程式或介面的原始開發人員從他或她的“超級使用者”角色晉升時，這種方法的高度應用，會使成本會大大增加。

2. 以資料為中心

下一個演變是“以資料為中心”的方法，如圖 1-6 所示。在這種方法中，建立了一箇中央資料庫或資料倉儲，將來自多個應用程式的資料整理到一個公共資料儲存中。提取、轉換、載入 (ETL) 工具用於將資料從應用程式移動到資料儲存中。需要一個資料建模環境來確保資料儲存中資料的正確上下文化，並且通常使用資料倉儲環境和資料質量工具來確保資料有效性和儲存。還需要與資料倉儲相關的報告工具來確保資料的有效視覺化。

圖 1-6：以資料為中心的企業整合方法

這種方法提供了一箇中央、通用的資料來源，其中標準報表和儀表板為所有使用者提供相同的檢視。可以執行復雜的分析，並可以根據趨勢預測運營績效。該方法通過重新聚合的資料提高了“交付”效能。這種方法可以在簡單的報告和分析過程中有效的使用，在這些過程中，決策是在幾周和幾個月內做出的，而不是在幾天、幾小時或幾分鐘內做出。

這種方法的問題在於資料模型難以更改，因此需要預先充分了解資料使用情況。此外，由於 ETL 延遲或非同步更新頻率，資料可能很舊。因為只有單向資料流，這主要是一種報告方法而不是資料整合方法。

3. 以介面為中心

圖 1-7 所示的“以介面為中心”的方法在介面卡開發環境中使用了企業應用程式整合 (EAI) 工具，例如 WebSphere、Tibco 和 Vitria。開發介面卡不是開發點對點介面，而是將資料提取（或釋出）到公共 EAI 匯流排中。匯流排傳輸資料；和其他訂閱的介面卡將資料載入（或使用）到需要資料的應用程式中。

圖 1-7：以介面為中心的企業整合方法

這種方法用於公司範圍的整合，其中一箇中央傳輸介質必須能夠訪問所有資料，並且釋出和訂閱是必不可少的。匯流排通常有一個規則引擎，用於編寫規則來管理匯流排環境中的業務和操作流程。該方法還管理訊息傳遞並提供有保證的資料傳遞。它通常是單一供應商解決方案，可通過單一整合環境降低複雜性。它還具有從應用程式本身抽象出介面的優點，這意味著對應用程式的更改不一定需要更改介面卡。

這種方法的問題在於使用者必須遵守專有的 EAI 供應商標準，因此應用程式供應商無法開發開放的行業標準解決方案。所有資訊也流經中央匯流排，阻礙了該方法的可擴充套件性。此外，EAI許可證通常非常昂貴。

4. 以模型為中心

“以模型為中心”的方法，其中開發服務而不是介面卡。使用的工具通常包括登錄檔/儲存庫、BPM或工作流工具、安全性、監控以及用於治理和生命週期管理的服務開發環境。

當業務和運營流程或基礎 IT 技術頻繁更改以配置不同站點的業務流程或技術的變化時，此方法特別有用。因此，這種方法非常適合當今的運營環境，因為在這種環境中，更改頻繁，並且每個全球站點都有自己的基礎結構、過程和工作方法。

這種方法有助於開發和採用諸如機器資訊管理開放系統聯盟 (MIMOSA)、ISA-95、開放應用程式組整合規範 (OAGIS)、企業到製造標記語言 (B2MML) 等介面的行業標準. 任何 ERP 或 MOM 供應商都可以提供整合功能，從而提供必要的敏捷性和靈活性，以便在不影響介面服務或資料交換的情況下快速更改流程。在這種方法中，IT 技術與業務流程分離。資料傳輸服務也像“以介面為中心”的方法一樣從應用程式中抽象出來，業務流程規則引擎也是如此。這種方法還可用於將傳統技術與“最佳實踐”方法相結合，從而使漸進式採用成為可能。

這種“最佳實踐”方法沒有被更廣泛採用的原因是它需要開發人員陡峭的學習曲線；需要全面的治理和服務管理；它需要“良好”的服務才能最大程度地重複使用。此外，供應商在釋出與 Web 服務相容的應用程式和服務方面非常緩慢。

這種方法也被 MESA 定義為 Mfg 2.0體系結構的一部分。

ERP/MOM 整合“最佳實踐”

隨著整合方法隨著時間的推移而發展，標準化在技術層面上進行了嘗試（首先是資料倉儲，然後是EAI）。以模型為中心的方法（Mfg 2.0 架構）不僅將介面從應用程式中抽象出來，而且還將應用程式從基礎技術基礎架構中移除。

要使 Mfg 2.0 架構發揮作用，需要在製造公司內定義和實施標準。根據 Gartner（並由 MESA 承保）的說法，“應用程式互操作性需要介面標準化。只有5%的介面是中介軟體的功能。另外95%是應用程式語義的函式。” 因此，重要的是應該減少對技術標準化的關注，而應更多關注資料交換過程中使用的語義的標準化。這種與 ISA-95 相結合的 Mfg 2.0 架構不僅提供了零活整合架構的對映，還提供了使真正整合成為可能的通用標準和通用語言。

結論

從當前的遺留系統和整合轉向基於標準的整合願景顯然不會在一夜之間發生。現在需要的是一種務實的方法，將當前的整合工作與實現基於標準的願景的分階段方法結合起來。

基於遺留系統構建的實用 Mfg 2.0 架構，在這種實用方法中，為尚未整合或基於 SOAm 架構的系統開發標準服務，然後實施。對於已經整合的應用程式，開發服務以將舊技術與新架構相連線。這些遺留應用程式會隨著時間的推移逐步淘汰，如果這種淘汰是適當的，或者在被替換之前保留到生命週期結束，則不會失去對實時工作流程的支援。

通過這種務實的方法，遺留基礎設施與新思維相結合。但是，要使這種務實的方法取得成功，企業將需要一個由熱情的製造技術人員支援的長期 Mfg 2.0 戰略。要使製造技術人員對 Mfg 2.0 充滿熱情，他們必須克服偏見，擁抱企業架構師，並開始研究和應用新思維。

因此，他們需要開始使用 MES 而不是 MOM，因為這將使他們處於正確的心態。他們需要開始瞭解 SOA，並且必須擺脫“以應用程式為中心的整合”，因為服務的概念是 Mfg 2.0 架構的基礎。他們需要開始找出 MDM 如何幫助並停止採取簡單的方法，促進“介面擴散”。他們需要通過了解 BI 的實際作用以及 EMI/OI 和 BI 的不同之處來正確定位 EMI 或 OI，以便為製造經理提供正確的決策資訊。那些不改變思路的製造企業，在系統開發方面將會停滯不前。