定義運營系統架構

王振耀發表於2022-01-03
架構

介紹

供應商提供的資訊系統隨著新功能和實施策略不斷髮展。可用選項的複雜性和多樣性使許多公司難以充分討論和比較可能滿足或不滿足其要求的替代方案。

供應商通常會推廣由公司或個人工具箱中的產品或解決方案支援的架構。如果公司對其運營系統的架構沒有清晰的願景，它通常會採用供應商的方法。這種方法可能最適合正在開發的系統；然而，在許多情況下並非如此。

在沒有目標“未來”架構的情況下，採用供應商的方法是不可避免的。隨著對系統敏捷性和相關運營管理能力的日益依賴，提高標準的必要性顯而易見。公司必須能夠了解他們的生產流程和結構，以此作為實際流程改進的基礎。一旦理解，現狀和目標未來架構將作為討論和對映替代方案的共同基礎。

本文介紹了用於描述作業系統和讓利益相關者參與基於產品獨立架構的專案的技術，並附有示例。

這種方法改變了與供應商談判中的遊戲規則，從以產品為中心的評估轉變為以作業系統能力為討論重點的評估。產品選擇過程包括需求和與關鍵設計原則的一致性。

介紹了一系列最先進的企業和解決方案架構概念，可用作開發作業系統架構 (OSA) 的起點。然後，該架構可用於指導任何專案，從最小的升級到最大的企業解決方案。

什麼是運營系統架構 (OSA)？

維基百科以這種方式描述系統架構：“系統結構或系統架構是定義系統結構和/或行為的概念設計”，而業務運營則是“涉及執行一個系統的那些持續的重複（迴圈）活動。為利益相關者創造價值的業務。業務運營的結果是從企業擁有的資產中獲取價值。資產可以是有形的，也可以是無形的。”

注意：運營活動通常被稱為“車間”或“一線”活動。就本文而言，ISA-95 中描述的製造運營管理 (MOM) 簡稱為“運營”或“運營管理”，因為許多流程工業將 MOM 簡稱為運營或工業運營。

運營系統代表那些支援業務和運營流程和活動的系統。作業系統架構是指定義作業系統的結構和/或行為的概念設計。它描述瞭如何應用運營技術 (OT) 來滿足業務目的的框架。

OSA 適用於廣泛的組織，例如製造、零售、諮詢、採礦、分銷和航空公司。當 OSA 在製造公司內應用時，它通常被稱為製造系統架構 (MSA)。然而，這些概念不限於任何特定領域。大多數企業都有運營元件，例如採礦、能源，甚至供應鏈，都可以被視為生產能力。OSA 概念同樣適用於所有這些領域。

運營系統的 OSA 定義受許多因素的影響，包括環境（技術、文化、公司結構、位置等）和業務目標（敏捷性、產品組合、供應鏈等）方面的挑戰。架構可以用不同的工件（文件、原則、圖片、示意圖、要求、規範和標準等）來表示以適應環境。

在實踐中，由於物理、文化和業務邊界，這些表示經常斷開連線。組中運營站點的體系結構表示通常根據歷史（升級計劃、所有權等）以及每個工廠和工廠之間的工程團隊、資訊科技和運營團隊之間的關係而有所不同。

這些方面為提高運營效率和敏捷性帶來了許多挑戰。如果沒有共同的參考點和語言，就很難在工廠中跨組織部門利用最佳實踐或在公司內跨部門進行討論。使用標準工具和技術參考開發通用 OSA 是應對這些挑戰的重要基礎。考慮其他從業者的最佳實踐可以最大限度地減少“重新發明輪子”的情況。藉助行業和技術標準，其他人（例如，供應商和整合商）可能會在先前的瀕臨滅絕期間接觸這些標準，從而使記錄的概念能夠被其他人（例如，供應商和整合商）認可。

OSA 與企業架構的關係

許多公司將企業架構解釋為在實踐中應用架構的定義和框架。企業架構傳統上應用於資訊科技領域，並且在將 OSA 引入討論時作為很重要的參考。

本文件中使用的定義來自麻省理工學院 (MIT) 資訊系統研究中心 (MIT CISR)，該中心將企業架構定義為“業務流程和IT基礎設施的組織邏輯，反映了公司運營模式的整合和標準化要求。”

由開放基金會 (www.opengroup.org/togaf) 建立的開放組架構框架 (TOGAF) 是 IT 組用來定義定義和應用企業架構的能力、開發方法、內容和工具的流行框架。在 TOGAF 中，一個公司定義了一個或多個企業。在 TOGAF 術語中，運營被視為企業，而 OSA 為運營企業定義了企業架構。

從企業架構的角度來看，OSA 被認為是企業架構 (EA) 概念對公司運營元件的應用。從 OSA 的角度來看，與 TOGAF 相比，OSA 提供了一個以運營為中心的框架，並利用了其他工具（例如，Gartner Brick 模型）和規範。它擴充套件和完善了 EA 以滿足運營需求。

實現 OSA

開發 OSA 面臨的挑戰包括：

  • 確定 OSA 的範圍
  • 開發一個可持續的架構
  • 開發目標受眾可以理解的架構
  • 開發可擴充套件的架構

確定 OSA 的範圍

系統的範圍對 OSA 有重大影響。在沒有明確定義的邊界的情況下，OSA 最終會描述一個範圍比所需範圍更廣的系統。範圍蔓延是運營專案的一個眾所周知的挑戰；如果變化在 OSA 定義期間考慮的範圍內，範圍蔓延不會影響 OSA。但是，如果 OSA 的開發邊界允許範圍蔓延，則 OSA 將比所需的更復雜。明確定義範圍並信任參與者以最大程度地減少範圍蔓延可促進 OSA 的開發，該 OSA 的詳細程度與解決方案設計一致。

可能需要一個高層次的總體架構，但在任何時間點都只需要詳細說明架構的一部分。將範圍限制為支援即時需求所需的最低能力非常重要。將 OSA 的範圍限制在交付業務價值所需的最低限度，並繼續嚴格評估該範圍是否可以簡化或進一步縮減。冗餘和非增值活動是需要削減的典型標誌。

開發一個可持續的架構

這一挑戰往往與範圍挑戰相牴觸。範圍是否允許未來的擴充套件？通過把架構開發成路線圖，並把非必要的活動推到未來的空間，這種範圍上的挑戰可以降到最低。

應用 PASS 原則：計劃一切，從小處著手。

並非所有長壽問題都與範圍相牴觸。在許多情況下，在系統元件、系統邊界和互操作性標準方面定義 OSA 的原則有助於縮小範圍並提供更強大的解決方案。

與許多硬體和運營裝置時間框架​​相比，IT 技術正在短時間內重塑其架構正規化的基礎。這是開發持久架構的重要因素。運營硬體和裝置的生命週期通常比 IT 技術更長，這會影響 OSA 路線圖的時間段。它們可以從三年到十五年的許多開始、停止和邊緣化的成功而有所不同（對於具有 MOM 願景的公司）。

這些時間段方面加強了對 OSA 實施（產品、硬體等）獨立性的需求。OSA 必須描述系統的基本元素以及它們支援哪些業務需求。元素的實施在整個公司可能會有所不同，並且會隨著時間的推移而變化。這些與時間相關的實施因素（當前和未來）在 OSA 中作為每個元素的路線圖被捕獲。Gartner Brick模型描述了系統的技術構建塊（Bricks，http://www.gartner.com/pages/story.php.id.2230.s.8.jsp）和每個磚塊的路線圖。Gartner 的積木和模式為捕獲此資訊提供了有用的基礎。

開發一個目標受眾可以理解的架構。

通過考慮哪種格式和語言可以理解，預先審查目標受眾是很重要的。在資訊、電氣、機械和質量工程師以及財務人員如何表示和解釋設計方面存在根本差異，此外還有先前個人經驗的影響。需要多個檢視才能使關鍵利益相關者理解並就架構達成一致。如果利益相關者無法理解 OSA，就不能指望他或她簽署它。

開發可擴充套件的架構

可擴充套件性本身具有多重含義。

  • 技術可擴充套件性：可跨硬體平臺、資料庫技術、作業系統等進行擴充套件。 OSA 在技術領域表示和要求中解決了這一問題。
  • 部署可擴充套件性：可擴充套件到各種實施規模和效能需求。在開發 OSA 時，系統的部署可擴充套件性將從小到大的運營專案擴充套件到最大的企業解決方案專案視為挑戰。這種部署可擴充套件性可以在 OSA 中通過原則和非功能性需求來表示。

OSA 需要能夠在一致的框架中應對這些挑戰。OSA 允許將架構的核心定義與架構的實現方面分開。在實踐中，OSA 的實現通常有兩種形式：

  • 企業架構 (EA)：EA 識別“模式和實踐”，這些模式和實踐由組織中實施的解決方案的架構應用，並具有長期穩定性和可擴充套件性。EA 以所有利益相關者同意的格式定義原則和概念、邏輯和流程設計元件，跨專案重複使用，並隨著時間的推移與不斷變化的戰略方向和不斷變化的環境同步進行調整。
  • 解決方案架構 (SA)：SA 通常代表具有（或具有）目標業務目標的一個或多個特定專案的架構。SA 為特定增量（實現特定能力水平的專案集）提供整體技術解決方案，並將整體方法聯絡在一起。SA 通常包含概念、邏輯、過程和物理設計的各個方面。目標是提供足夠的技術和實施細節以進行一個或多個專案的開發、測試和實施的方法。實現通常有“我們昨天需要它”的時間壓力和“告訴我們我們需要做什麼”的問題。因此，與業務流程領域相比，SA 在運營環境中更加面向需求。

在小型專案和公司中，很難區分 EA 和 SA。在更大和更模組化的專案中，區別（通常是必要的）更清楚地呈現出來，並通過元件的重用和系統的模組化來證明。

OSA 的推導

有許多方法可以發展一個組織或公司的 OSA。兩種方法是：

  1. 採用現有產品作為OSA的基礎
  2. 獨立於現有產品的OSA表示的實現

第一種選擇可能是一條更快的路徑，但有副作用，即不一定提供適當的架構來滿足公司的需求，並將公司與產品/供應商聯絡起來。

第二種選擇需要對範圍和方法進行更多的分析和澄清，這實際上減少了在更大、更復雜的專案中的工作量。

採用現有產品作為 OSA 的基礎

在缺乏現有運營系統模型的情況下，公司通常會利用在運營和/或企業中使用的產品中定義的資料、整合和流程模型。這種方法為許多組織提供了堅實的基礎。然而，它有一個隱含的假設，即現有產品具有充分關注作業系統需求的概念設計。鑑於大多數產品專注於作業系統的特定方面並在其開發中做出特定假設，這種方法不太可能為基礎廣泛的作業系統架構提供基礎。

這種方法的一個常見直接結果是，公司最終會用產品本身來描述架構。他們已將關鍵分析推給供應商。一個跡象是，除了基於物理裝置和物料清單的一些基本表示之外，對生產過程沒有達成共識。如果您詢問工廠或過程設計，即使是高階術語，您也會看到產品的螢幕或幫助系統。這本身並不是一件壞事。然而，對產品的依賴系統的範圍和定義是，它假設供應商的產品方向與公司的方向相同。

這種方法的另一個結果是產品可能無法實現其全部功能。這在更復雜的產品中更有可能，例如 ERP 和 MES/MOM 系統。實施是從最初實施的角度來理解的，但從那時起，人員一直在前進，沒有人真正清楚地瞭解什麼可以實現，什麼已經實現。如果不注意隨著時間的推移保留應用程式的意圖，則此問題也可能存在於產品無關的方法中。然而，這種情況更有可能發生在供應商交付模型中，該模型通常不關注付費參與的範圍，並在系統中使用另一個部門或另一個國家的產品開發團隊，該團隊不受實施團隊管理或訪問，在整合商交付模型中，專案團隊專注於整合團隊。

獨立於產品的 OSA 表示的實現

為了實現產品獨立的 OSA 表示，系統首先以專注於公司挑戰和機遇的形式定義。在此階段包括有限的供應商參與（僅供參考，而非指導）；在 OSA 定義到令人滿意的詳細程度後，供應商被正式引入流程。強調資源或技能的公司通常會聘請獨立專家來促進這一過程。

OSA以獨立於具體實施的形式描述了系統的結構和行為，其詳細程度由公司的需求決定。OSA與系統的業務驅動力相關，通常以系統的能力路線圖的形式，與業務能力和目標相一致。給一個青少年的第一輛車配備法拉利是沒有意義的。在這個少年逐漸成熟之後，如果他/她的技術能力和需求仍然適合跑車，那麼法拉利可能是正確的選擇。

架構的詳細程度隨著模型的廣度而變化，與公司的需求相一致。例如，與供應鏈整合相比，該公司認為更需要關注生產管理和流程控制。因此，生產管理和過程控制比其他領域更詳細。

這種方法的優點是，架構的範圍和方法與組織的方向一致，支援跨越多個產品的倡議，以實現需求和多個階段來實現預期的功能。同樣，分階段與公司的成熟度相一致，並推動組織在流程和工具集方面的靈活性。

通常，當終端使用者採用產品或供應商的架構時，對系統架構與需求的詳細瞭解會從終端使用者轉移到供應商。在某些情況下，這是一種合理的權衡。在其他情況下，它是一個限制因素，阻止使用者、組織釋放運營能力的全部能力（可以通過多種方式衡量：投資回報率、吞吐量等）。鑑於許多供應商是全球性組織，供應商在專案中聘用的架構師可能不熟悉（並且可能沒有時間充分了解）終端使用者系統的細節。這種情況對終端使用者來說是危險的。

公司已經使用這兩種方法開發了有效的解決方案。然而，那些選擇實現獨立於產品的表示的公司可能擁有更靈活、更持久的架構，隨著時間的推移不斷髮展，並且能夠更有效地與供應商合作以獲得他們需要的東西。

一些公司遵循基於產品的實施方法，因為他們不確定如何以獨立於產品/供應商的形式來處理解決方案。供應商相信他們的架構能夠滿足所有環境的所有需求，並通過引人注目的演示來傳達資訊。要採取獨立於產品/供應商的方向，終端使用者需要對其採用這種方法的能力充滿信心。為了滿足這一需求，公司通常會聘請分析師和中小企業專家(SMEs)。

開發產品獨立 OSA 的步驟

1. 形成 OSA 團隊結構

與任何活動一樣，要取得成功，OSA 的形成必須得到公司的支援和預算的推動。通過從試點專案開始並從這些經驗中學習，可以減少對運營的破壞性影響。看到這種方法的價值的公司組成了來自不同領域的架構師團隊，指導委員會為每個團隊提供指導。在各種規模的專案中，引入外部中小企業和與外部諮詢機構合作的能力是過程的一部分。無論承諾是一個架構師還是多個架構師，業務的參與和支援都是這個過程的關鍵要素。

這個過程最好由一個多學科團隊參與，該團隊包括來自公司所有學科和技術領域的利益相關者。運營/業務領域團隊的組成可能包括來自以下學科的一名或多名成員：

  • 工程/工藝工程
  • 財務總監和規劃師
  • 運營/持續改進
  • 質量保證/合規
  • 技術
  • 資訊科技
  • 維護
  • 營銷
  • 供應鏈
  • 生產
  • 主題專家
  • 資訊架構
  • 自動化/控制
  • MOM/MES
  • ERP
  • 專案管理/促進

2. 開發-OSA

獨立於產品的 OSA 的演變相對簡單，遵循圖 4-1 所示的一些基本步驟。這個過程是迭代的，從巨集觀層面開始，然後深入到對業務驅動程式最有價值的領域。 

圖 4-1：OSA Aligned 的開發步驟

使用業務驅動程式深入研究這些步驟時，將使用一個基本流程，類似於運營系統工程和開發中使用的流程：

  1. 確定現有業務需求和運營挑戰和痛點並確定其優先順序。
  2. 確定與一流公司、技術和已知標準的差距。
  3. 根據現有業務需求和運營痛點對業務的價值對其進行排名。

這些使用者需求的排名決定取決於有效的運營工作流程，並且與技術無關。

引人注目的運營系統架構與解決業務需求和驅動因素的運營活動保持一致並提供支援。作為制定 OSA 使用者要求和優先事項的一部分，需要對當前的業務路線圖和優先事項進行廣泛的訪談和審查。

  1. 業務路線圖回顧
  • 當前環境的現狀是什麼？
  • 未來的環境是什麼？
  • 長期目標是什麼？
  • 到達那裡的步驟是什麼？按照：
    • 業務成熟度
    • 人員和流程
  • 路線圖中的關鍵附加值和文化敏感性在哪裡？
  1. 系統功能/架構的發現
  • 啟用業務流程中的步驟需要哪些功能？
  • 確定底層架構：
    • 有哪些高階概念？
    • 什麼樣的架構能夠支援業務路線圖？
    • 架構必須考慮最終狀態並展示其相對於最終狀態的演變。
  • 從現有系統和技術採用的角度考慮運營和 IT 能力：
    • 業務成熟度、理解和利用概念的能力 需要進行文化和培訓練習。
    • 適合業務成熟度級別的能力。通常有一個輕量級的臨時解決方案，適合業務的直接成熟度級別。隨著成熟度的增長，必須規劃更有能力的系統。
  • 哪些技術能力處於高水平？
  1. 對照MOM和IT標準進行分類
  • 根據標準（ISA、ISO、IEC 等）表示系統元件
  • 比較與現有技術（WS、SOA、REST 等）相關的系統架構。
  • 對系統相對於其他系統（同類最佳等）的能力/成熟度進行分類，以識別差距/機會。
  1. 能力/架構路線圖開發
  • 確定技術/能力的最終狀態。
  • 記錄在能力和架構方面邁向最終狀態的步驟。
  1. 對業務要求的步驟排名
  • 使能力和架構路線圖與業務需求保持一致。
  1. 細化/深入研究高價值領域

結果是系統的運營能力的優先列表，然後必須與業務價值保持一致，並得到用於開發/實施的業務案例的支援。這是 OSA 開發的一個重要方面。如果它與業務的需求和價值無關，那麼為了烏托邦式的願景而設計優雅的架構是沒有意義的。

說明 OSA 意圖的另一種方式是，有效的 OSA 使人員和系統能夠滿足業務需求。作業系統（人和機器）能夠更有效地滿足業務需求（敏捷性、效率、靈活性等）。OSA 支援業務流程以及這些流程的持續改進。

OSA 是什麼樣的？

作業系統架構的表現形式和內容取決於所代表的環境。可以將典型 OSA 的元件描述為特定表示的模板。

典型的 OSA 元件是（這些元件將在高階架構中介紹）：

  1. 使業務驅動因素與 OSA 路線圖和 MOM URS 保持一致
  2. 指導原則
  3. 標準支援和一致性
  4. MOM 系統架構（OSA 的真正核心）

用於系統和企業架構的要求和表示的已釋出標準和框架是：

任何這些標準的採用和符合程度都取決於組織的環境、文化和流程。此架構文件並未深入研究這些標準中的任何一個，但建議將其作為參考架構進行審查。實際標準採用的級別必須基於對 OSA 的附加價值。這是一個重要的考慮因素。

1. 使業務驅動因素與 OSA 路線圖和 MOM URS 保持一致

業務驅動因素和路線圖通常在 OSA 引用的其他文件中表示；通常，這些文件由各自領域（運營、工程、IT 等）的利益相關者擁有。業務驅動因素的範圍可能涵蓋對 OSA 價值不大的領域，但包含一系列目標和里程碑，為 OSA 提供有價值的背景和方向。業務驅動因素和路線圖建議哪些具體問題是重要的，以及為什麼。OSA 提供了實現這些目標的框架。在 OSA 中提供或作為單獨文件提供給 OSA 的關鍵業務驅動因素和願景中的關鍵業務驅動因素和願景的摘要，以提供有關目標架構支援什麼及其原因的背景資訊。

當前狀態定義

目前生產經營管理系統在哪裡？

今天面臨的挑戰和機遇是什麼？

運營管理使用者需求規範 (URS) 中必須有效定義未來或最終狀態，該規範首先必須全面定義運營管理的當前狀態以及支援系統和流程。必須對OSA路線圖中的功能和文化差距進行定性，以便進行規劃和投資回報率計算。

最終狀態定義

最終狀態定義回答了這個問題：未來生產系統需要在哪裡？

典型的運營系統優化路線圖涵蓋三到十五年，具體取決於所需的文化變革管理水平。

對那些不熟悉設施或在未來與生產系統互動的人來說，什麼會脫穎而出？

在五年、十年等時間內，要想具有全球競爭力，需要什麼樣的運營形式，要知道需要三到十五年的時間才能達到這個目標？

從當前狀態過渡到最終狀態所需的步驟

利益相關者總是希望看到他們資助的增量小步驟提供投資回報率的好處，同時保證這些步驟也與更廣泛的願景相一致。從當前狀態過渡到最終狀態所需的每個遞增步驟的投資回報率是多少？

這些步驟必須足夠小，以允許建立專案/工作計劃並由專案管理人員監控，同時儘可能不超過六到九個月。這種方法在專案進展過程中保留了靈活性，以適應不斷變化的需求和環境。也可能需要一些迭代才能獲得最終結果。

第一步中的細粒度細節：MOM URS

儘管運營管理 URS 檔案是戰略性的，但許多利益相關者從戰術上思考。利益相關者總是將 URS 視為第一步並重視它，因為它是所提議架構的第一個“試金石”。但是，URS 必須向利益相關者提供並傳達功能和 OSA 設計和部署的框架和方法，以便他們清楚地瞭解設計和部署所需的資源和成本。

對業務驅動因素和OSA路線圖的描述.很可能遵循原始檔。然而，對下面介紹的名詞結構做了一些概括。其格式可以類似於願景檔案的介紹，描述當前的狀態、未來的狀態，以及如何以小的、可實現的步驟達到這一目標

OSA 文件中介紹的體系結構提供了實現本節中介紹的專案或專案群元素的基礎能力。

2. 指導原則

OSA 以關鍵原則為指導，根據這些原則構建、指導 OSA 並使其與業務和運營要求保持一致。下面介紹了典型的 OSA 原則，其中一些原則被認為是系統級要求。事實上，許多指導原則轉化為供應商的要求。

在許多情況下，擁有單一的指導原則列表是可以接受的，因為該列表通常包含在範圍有限的描述中（程式資料完整性改進、專案線速度優化等）。在其他情況下，OSA 的範圍很廣，指導原則存在於單獨的檔案中，按章節分類。

以下指導原則列表代表了指導原則可能包含的內容的示例。它不是規定性的，而是指示要代表的主題和元素。

  • 系統表示
    • 該架構符合 ISA-95 標準。
    • 該架構符合 ISA-88 標準。
    • 業務流程使用 BPMN 標準表示。
    • 圖表使用 UML 2.2 結構呈現。
    • 功能描述獨立於供應商。
    • 在虛擬環境中執行的實現對具有效能和可用性要求的可擴充套件性有明確的定義，並描述了將利用虛擬環境中可用的哪些功能。
  • 診斷/健康
    • 系統中斷每五分鐘或更長時間報告一次。
    • 安全
    • 整合到系統中的所有應用程式都經過資料安全評估，包括：
      • 必須對通過網路傳輸的所有資料進行加密。
      • 不得將任何資料儲存在未加密的位置。
      • 使用者名稱和密碼應在安全的環境中進行管理。
      • 合規
    • 保留運營、材料、產品和財務資料一段時間的系統資料歸檔要求。
  • 可靠性
    • 災難恢復 (DR) 情況下的系統恢復在 24 小時內執行。

注意：這是一個例子；從 DR 到垂直行業通常要求有更嚴格的時間線。

  • 角色
    • 應用程式（MES/MOM、PLM、E​​RP 等）專注於業務規則。
    • 訊息中介應用（EAI 和 BPM 產品等）專注於訊息中介（傳輸、分發和交付規則）。
  • 介面/訊息
    • 訊息在行業標準（B2MML、EDIFACT 等）中定義，因此與應用程式無關。
    • 中介引擎是與應用程式無關的規則，專注於傳輸、交付和對映功能。
    • 從應用程式級介面到標準模型的訊息在標準對映元件中執行。
    • 應用程式介面的應用程式介面引數被視為訊息定義，並且儘可能與應用程式無關；任何特定於應用程式的引數都通過中介對映元件對映到標準模型中。
    • 訊息流遵循預定義的模式。
    • 對話的程式碼元件和配置在版本化儲存庫中進行管理。
    • 資訊交換記錄在標準流程中
    • 應用程式是鬆散耦合的。訊息交換必須是非同步的。同步訊息交換被實現為協調的非同步對話。
  • 解決方案開發
    • 80% 的訊息實現是通過配置實現的；一旦定義了工廠模型和製造資訊模型，20% 需要自定義實施。
    • 在部署自定義實現的地方，程式碼和元件在受版本控制的儲存庫中進行管理。

3. 標準支援和一致性

指示所支援和應用的標準是設定體系結構演示上下文的寶貴基礎。最好提供對適當標準的參考，以便讀者在需要時檢視標準。

在一些需求文件中，新增一個附錄是適當的，指示正在與架構一起使用的標準的相關元件。例如，當代表使用 ISA-88/95 的運營設施時，ISA-88/95 裝置角色模型元素可能會記錄在附錄中。

還應記錄對給定標準的符合（或不符合）水平。很少採用或完全遵守標準。在運營實施中，標準通常用作公共參考點（例如，ISA-88、ISA-95）。在這種情況下，該標準可能無法滿足組織的所有需求，但可以作為一個有價值的參考點，任何偏差都可以通過該參考點清楚地表達出來。符合標準並不總是可取的。在供應商評估期間，瞭解一致性和偏差時，它通常是一個有價值的工具，特別是當多個供應商參與或投標時。

這種方法可幫助熟悉標準的參與供應商瞭解用於描述系統的語言，並瞭解標準未應用的位置。

4. MOM 系統架構

架構表示是 OSA 的基礎。它定義了與之相關的作業系統的基礎。OSA 是作業系統的參考架構，其方式類似於企業架構師如何為企業系統定義參考企業架構。

典型的 MOM 系統架構表示如下三個基本元件：

  1. MOM高層架構（MOM HLA）
  2. 架構模型
  3. 資訊流模式

Zachman 框架 (http://en.wikipedia.org/wiki/Zachman_Framework) 中更詳細地介紹了這三個元件。

Zachman 框架是一個企業架構框架，它提供了一種正式的、高度結構化的方式來檢視和定義企業。如圖 4-2 所示，Zachman 框架由一個二維分類矩陣組成，該矩陣基於六個交流問題（Why、How、What、Who、Where、When）的交集。

Zachman 框架不是一種方法論，因為它不暗示用於收集、管理或使用其描述的資訊的任何特定方法或過程。該框架以其建立者 John Zachman 的名字命名，他於 1980 年代在 IBM 首次開發了該概念。此後已多次更新。

Zachman“框架”是一種用於組織架構工件（換句話說，設計文件、規範和模型）的模式，它考慮了工件的目標物件（例如，企業所有者和建造者）和正在解決特定問題（例如、資料和功能）。

圖 4-2：Zachman 企業架構框架

4.1. MOM 高階架構 (MOM HLA)

OSA 是作為 MOM 高階架構 (MOM HLA) 引入的，用於標識架構範圍內涵蓋的架構的關鍵元素。在較大的系統中（“大”不限於大小；它還可以描述複雜性、變化等），架構被分解為與特定利益相關者特別相關的系統關鍵檢視。

MOM HLA 通常包含系統的關鍵概念和檢視的組合，它們設定了架構的意圖、重點和範圍。可能還描繪了有助於傳達架構的裝置/硬體級別。其中磚塊模型也可用於 MOM HLA 表示。

4.2. 架構模型

模型描述了架構的元件以及元件之間的互動。有許多建模工具可用於描述系統。本節詳細介紹了一些應用於製造運營系統的工具。

ArchiMate (http://www.opengroup.org/subjectareas /enterprise /archimate) 是一種開放組標準，它是一種開放且獨立的企業架構建模語言，得到不同工具供應商和諮詢公司的支援。ArchiMate 提供工具使企業架構師能夠以明確的方式描述、分析和視覺化業務領域之間的關係。Archimate 2 已經發展到與 TOGAF 完全一致。

ArchiMate 提供了廣泛的檢視，這些檢視結合起來以在上下文中傳達架構。

4.2.1. 磚塊模型

所示的磚塊模型基於 Gartner 磚塊模式，以幫助識別第4層業務和第3層MOM技術域中的關鍵域，如圖 4-3 所示。這些域是用磚塊建造的。這些積木中的每一個都可以擴充套件以呈現積木中的技術路線圖。

圖 4-3：MOM 磚塊模型示例

4.2.2. 邏輯模型

邏輯模型是系統內主要元件和系統內外的一些關鍵介面的表示。這些表現形式因受眾而異。

4.2.3、製造運營系統的標準模型

製造運營系統有多種模型。根據專家組多年的討論，IEC、ISO、NEMA、ISA 和 MIMOSA 只是提供模型模板的廣泛標準組的一個示例。這些模型用作給定 OSA 實施的參考模板。以下部分說明了從 ISA 標準派生的一些應用於作業系統的模型。

4.2.3.1. 組織模型

組織模型 (OM) 是由組織單元 (OU) 組成的層次結構。該概念已在整個業務系統和作業系統（例如 Active Directory）中廣泛使用。

用於表示企業和生產系統的元素與此模型相關聯。組織模型是將系統劃分為指定範圍和行為的區域的支柱。ISA-95 和 ISA-88 功能層次結構和裝置角色模型構成了在製造運營環境中構建架構組織模型的有用基礎。這些模型的層次性質使企業的規範能夠分解為從企業到現場，再到工廠/車間工作單元的詳細級別。這種分離允許定義活動和生產系統元素的範圍。

機器、站點或企業的操作程式是否在其應用範圍內？

層次結構允許深入瞭解關鍵領域的特定需求，並管理總體系統中各領域之間的關係。批次處理、離散、連續和混合生產區域之間處理語義的差異（和相似性）可以在此區域中進行審查。

示例：使用圖 4-4 中顯示的 ISA-95 裝置角色模型構造，開發了用於線表示的模板。該模板應用於各種工廠，以定義製造設施的標準模型。該模型用於進一步將製造設施分解為一致的表示。乍一看，所提出的簡單方法在允許物理設施之間和內部的裝置定義變化的能力方面受到限制。相關模型（資源、工作流、基礎設施等）的表示為從業者提供了在各種物理操作環境中全面構建制造操作的工具。 類似的方法也可用於在地理上定義跨全球或國家組織的工廠的企業表示。

圖 4-4：ISA-95 裝置角色模型示例

4.2.3.2、資源模型

資源是作業系統工作能力的重要定義。正確的表示對於理解如何在吞吐量、靈活性和質量方面改進系統至關重要。系統中的資源和已執行的工作流程之間存在重要關係。在定義資源模型之前，最佳實踐是定義工作流程型別、資源（裝置、材料和人員）和操作工作流：

  • 工作是為了達到目的或結果而從事的體力或腦力活動。
  • 資源是在流程或工作流程中完成工作所需的元素。
  • 工作流是執行工作的步驟序列。一個序列可以是一個步驟，每個步驟都可以分解為層次結構模型中的下級步驟。

資源模型將資源的表示定義為：

  • 人：人員
  • 機：生產裝置
  • 料：物料
  • 法：業務等（基於ISA-95的工作流程表示）
  • 環：環境

這裡有一個有趣的互動需要澄清：人和裝置在工作，但也是在工作流程的步驟中工作，作為工作流程的輸入（要求）。

一個人或裝置使用其他資源來完成一個系統中的工作。系統中資源的定義表明了系統完成工作的能力。給定活動的可用資源範圍由組織模型定義。這對於作業系統中的生產排程和裝置仲裁的定義很重要。

在某些領域，處理裝置（控制器、資料中心、機架等）被定義為資源。資源是作業系統工作能力的重要定義。

4.2.3.3. 工作流程圖

準確表示不同級別的工作流以及它們如何互動對於捕捉運營功能的本質及其在公司內的變化非常重要。

對運營中的工作流程有多種解釋，包括：

  • 配方
  • 路線：適用於離散行業的主路線和生產工藝路線
  • ISA-95 中定義的過程段、操作段和工作過程段
  • 業務流程
  • 工作說明 (WI) 或標準操作程式 (SOP)
  • 過程：ISA-88 中定義的配方、單元和控制配方

上述列表中有許多潛在的相似之處：

  • 這些表示的語義基本相同，儘管每個本體的視覺化和語義使它們看起來大不相同。
  • 捕獲運營系統中工作流的每個表示並將其呈現以供利益相關者同意非常重要。
  • 根據所需的詳細程度，製造操作具有多個級別的工作流程和複雜性。準確表示不同級別的工作流及其互動和依賴關係的能力對於捕獲所需級別的詳細作業系統功能非常重要，包括公司運營和工廠的工作流變化。

MOM 工作流示例

圖 4-5 中的圖表代表了作業系統中一些不同形式的工作流，該圖是通用的。實際上，運營系統的實現會簡單得多，因為它代表了特定於公司的生產和運營系統，並且可能使用特定的標準，例如業務流程建模符號 (BPMN)。

圖 4-5 使用 BPMN 表示法表示生產和運營系統中的互動工作流

圖 4-5 示例中的注意事項：

  • 不同的工作流程表示連結在一起以執行“整個生產過程。
  • 由於考慮到生產過程的物理環境，企業級過程得到了詳細擴充套件。
  • 源自 ISA-95 的左側企業、站點、工作中心和工作單位組織單位將資訊劃分為可管理的部分。
  • 工作流程（混合、製作、包裝）可以作為配方或路線實施，具體取決於公司。
  • 圓圈代表工作流程中的步驟。每個都有定義為資源和引數的輸入和輸出（參見 ISA-95 和 ISA-88 示例）。
  • WI 和 SOP 是工作流。
  • 工作流的目標是生產訂單中定義的產品。
  • Mix、Make 和 Pack 的工作流與工作中心和工作單位中的資源繫結以生產產品。
  • WI/SOP/SOC 是處於生產過程核心的重要工作流程。在許多情況下，它們以及控制配方是橡膠與道路相遇的地方。
4.2.3.4、標準符號

儘可能在 OSA 中使用標準符號。在現實世界中，可能有理由組合或擴充套件符號或使用非標準符號來傳達資訊。然而，只要有可能，就應該使用標準的表述，因為組織中的從業者更有可能理解、欣賞和支援他們。

常用的記號有：

  • 業務流程建模符號
  • 統一建模語言 (UML)
  • ISA-88 第 3 部分

雖然有許多專門的工具可用，但可以使用現成的桌面工具提供的模板來完成很多工作。

4.2.4 基礎設施模型

基礎設施元素彙集在一個基礎設施環境中，指示系統感興趣的元素和這些元素的規範。生成的基礎設施模型表明支援 OSA 應用程式級別和工作流程級別功能所需的底層系統和通訊網路。

該模型提供了關鍵基礎設施元素的指示，包括：

  • 伺服器
  • 機架
  • 機櫃
  • 機房
  • 客戶端
  • 網路模型
4.2.4.1. 伺服器

伺服器有多種形式。將伺服器的表示組合成一致的表示非常有用，可以跨企業、站點、生產線和機器級系統整合工作流功能。嵌入式系統中工作流功能的擴充套件模糊了作業系統中什麼是資訊和什麼是純控制的界限。因此，執行高階計算的能力現在是什麼系統級別最適合以可重用和可擴充套件的形式部署該功能的問題。

架構中通常表示的伺服器是：

  • 刀鋒伺服器：通常執行基於 Windows 或 Linux 的應用程式的物理或虛擬化管理程式環境。插入伺服器機架。
  • 資料集中器模組：這些工業控制器模組專注於資料收集，具有用於資料儲存和資料轉發或嵌入式歷史記錄模組的邏輯。
  • 線路控制器模組：工業控制器模組以線路電平控制為目標。
  • 機器控制器：工業控制器模組針對單個機器/工作單元控制（例如，混合器）。
  • 裝置伺服器模組：伺服器管理與工廠/運營設施內裝置的連線。

代表伺服器的選擇將取決於架構的範圍。

4.2.4.2. 機架

機架線上路、站點和資料中心託管伺服器，為連線到它們的專案提供電源和通訊。儘管在操作架構圖中並不常見，但在考慮將功能分配給特定伺服器/機架例項時，它們會成為重要的特性。

代表的機架型別有：

  • 伺服器機架：伺服器機房或資料中心中伺服器刀片的主機。
  • 控制器機架：工業控制器模組的主機，其形式為：
    • 過程控制器 — 機器：對單個機器或工作單元內的機器進行機器級基本控制
    • 過程控制器 — 生產線：生產線的生產線級控制
    • 資料集中器：自動化/資訊網路的資料採集和下載閘道器/網橋
4.2.4.3. 機櫃

為完整起見，機櫃內裝有過程控制機架。在控制系統中，這些被稱為電機控制櫃或電機控制單元，而在伺服器機房中，它們被簡稱為機櫃。

4.2.4.4. 機房

這些是包含機架和機櫃的資料中心、生產現場或生產線中的封閉區域。它們通常被稱為機房。

4.2.4.5. 客戶端

系統中所有客戶端的使用者和功能需求定義包括HMI、PC客戶端和移動裝置客戶端。

4.2.5. 網路模型

該模型指示系統感興趣的元素以及這些元素的規範。

這是系統內控制和資訊網路的表示：

  • 這種表示表示通過 VLAN、網橋、路由器和防火牆對網路進行隔離。
  • 網路跨越固定線路基礎設施（光纖/銅線）和無線連線。
  • 還應表示網路上具有網路功能的機器。
  • 網路配置通常會跨越控制、工廠資訊和企業網路，表明網路的分離。
  • 外部供應商和承包商對網路的訪問由通訊閘道器和配置的防火牆定義。

該模型還包括網路協議的表示，例如：

  • TCP/IP
  • 乙太網IP
  • 裝置網路
  • 專業網
  • 專業匯流排
  • Modbus TCP

4.3. 資訊流（AKA 資料交換）

資訊流（也稱為資料交換）捕獲系統內發生的一些動態互動。它們可以應用於系統內的所有域。呈現的詳細程度取決於系統。一系列資訊流表示可用於描述巨集觀和微觀層面的資訊交換。

資訊流表示和規範的資料交換分類是：

  • 資料採集
  • 資料倉儲
  • 主資料定義和所有者
  • 報告
  • 配置
  • 執行
  • 後期製作

OSA 有許多可用的架構概念；其中一些是：

  • 企業服務匯流排 (ESB)
  • 製造訊息匯流排 (MMB)
  • 製造運營服務匯流排 (MSB)
  • 操作訊息匯流排 (OMB)
  • 事件驅動架構 (EDA)
  • 面向服務的架構 (SOA)

這些架構下的機器對機器 (M2M) 資訊交換架構可能會影響或適合一組特定的資訊流。一些可用的架構是：

  • 網路服務
  • 釋出/訂閱
  • 具象狀態轉移 (REST)
  • 資料複製

OSA 選擇這些方法並將其與適合公司目的的方法保持一致。

推動這些機器對機器交換的是多種技術，它們的選擇取決於應用程式：

  • 複製引擎：具有簡單的資料庫到資料庫資料交換能力的引擎。
  • 訊息處理引擎：從源中提取資訊、執行基本中介（轉換/對映）並載入到目標系統中的訊息處理引擎。
  • 路由和中介引擎：擴充套件訊息引擎的轉換能力以提供路由和更復雜的中介能力的訊息處理引擎。
  • 流程編排：應用程式通過新增在轉換階段對訊息執行復雜訊息處理和邏輯的能力來擴充套件訊息引擎的轉換能力。

實現製造 OSA

隨著 OSA 的完成，已經建立了一個畫布來對映功能解決方案、需求和供應商的產品。該畫布允許其建立者根據 OSA 路線圖衡量各種供應商技術的適合度，並確定最佳適合度和必須填補的差距，以達到所需的功能級別。在這種環境中，鼓勵供應商（和其他人）在計劃中引入額外的功能和架構模式。隨著終端使用者變得成熟並瞭解更多資訊，OSA 路線圖本身每年都會在製造轉型中發展。

如前所述，這種方法的替代方案是允許供應商管理需求收集和解決方案描述。有意或無意地這樣做會使架構及其演變方向與其產品方向保持一致，這可能會或可能不會與業務需求保持一致。在這種情況下，建議對每個供應商的活動有一個獨立、客觀的看法，以防止供應商鎖定和錯失機會。

利用 OSA 並不是對公司運營演變的正常流程的重大改變。以下過程說明了在新技術發展過程中如何利用 OSA：

  • 概念——理念定義和價值論證：運營系統的變化是根據路線圖來衡量的，它可以更清晰地表示運營系統的變化以及這些變化的影響。
  • 資訊請求 (RFI)：向參與者提供利用 OSA 和使用行業標準術語和結構的流程文件，以幫助構建討論。更改範圍以路線圖中的總體 OSA 高階設計為限。範圍的任何變化都是可以理解的。與路線圖其他方面一致的附加資訊是可識別的，並且可以被理解為適合更廣泛的範圍。
  • 詢價/投標 (RFQ/RFT)：與 RFI 相同的概念，特別強調範圍定義。更清晰的參考模型為合同的討論和構建提供了更堅實的基礎。
  • 專案實施/部署：通過更清晰的範圍定義，減少了對流程早期未澄清的變化和問題的討論。

管理 OSA 的發展

責任矩陣的建立有助於利益相關者團隊瞭解他們應該參與哪些領域。雖然這主要是一項專案管理職能，但對角色和責任進行明確定義符合 OSA 的發展。利益相關者應該知道他們要為哪些領域做出貢獻以及他們要簽署哪些領域。

概括

已經介紹了用於開發 OSA 的技術和示例。雖然這些架構通常是在外部支援下開發的，但通過利用所提供的技術，可以為最小的專案建立一個有效的獨立於供應商的 OSA，直到更大的企業實施。

有了這種能力，公司就可以在不受供應商偏見影響的情況下更好地捕捉其運營流程的真實語義。有了這些模型，與供應商在實施中的接觸發生了變化，在下訂單之前，對核心概念的討論就擺在桌面上，而不是在專案進行中或之後才被發現。

相關文章