定義營運系統架構

介紹

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

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

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

本文介紹了用于描述作業系統和讓利益相關者參與基于産品獨立架構的項目的技術，并附有示例。

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

介紹了一系列最先進的企業和解決方案架構概念，可用作開發作業系統架構 (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 的範圍限制在傳遞業務價值所需的最低限度，并繼續嚴格評估該範圍是否可以簡化或進一步縮減。備援和非增值活動是需要削減的典型标志。

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

應用 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。兩種方法是：

采用現有産品作為OSA的基礎
獨立于現有産品的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 的開發步驟

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

确定現有業務需求和營運挑戰和痛點并确定其優先級。
确定與一流公司、技術和已知标準的差距。
根據現有業務需求和營運痛點對業務的價值對其進行排名。

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

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

業務路線圖回顧

目前環境的現狀是什麼？
未來的環境是什麼？
長期目标是什麼？
到達那裡的步驟是什麼？按照：
- 業務成熟度
- 人員和流程
路線圖中的關鍵附加值和文化敏感性在哪裡？

系統功能/架構的發現

啟用業務流程中的步驟需要哪些功能？
确定底層架構：
- 有哪些進階概念？
- 什麼樣的架構能夠支援業務路線圖？
- 架構必須考慮最終狀态并展示其相對于最終狀态的演變。
從現有系統和技術采用的角度考慮營運和 IT 能力：
- 業務成熟度、了解和利用概念的能力需要進行文化和教育訓練練習。
- 适合業務成熟度級别的能力。通常有一個輕量級的臨時解決方案，适合業務的直接成熟度級别。随着成熟度的增長，必須規劃更有能力的系統。
哪些技術能力處于高水準？

對照MOM和IT标準進行分類

根據标準（ISA、ISO、IEC 等）表示系統元件
比較與現有技術（WS、SOA、REST 等）相關的系統架構。
對系統相對于其他系統（同類最佳等）的能力/成熟度進行分類，以識别差距/機會。

能力/架構路線圖開發

确定技術/能力的最終狀态。
記錄在能力和架構方面邁向最終狀态的步驟。

對業務要求的步驟排名

使能力和架構路線圖與業務需求保持一緻。

細化/深入研究高價值領域

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

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

OSA 是什麼樣的？

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

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

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

用于系統和企業架構的要求和表示的已釋出标準和架構是：

Zachman 架構 (http://en.wikipedia.org/wiki/Zachman_Framework)
TOGAF 9
ISO/IEC 40202、ISO 15926 等
Gartner 磚塊模型
ISA-88、ISA-95、ISA-99、ISA-100、ISA-101、ISA-104、ISA-106等

任何這些标準的采用和符合程度都取決于組織的環境、文化和流程。此架構文檔并未深入研究這些标準中的任何一個，但建議将其作為參考架構進行審查。實際标準采用的級别必須基于對 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、ERP 等）專注于業務規則。
- 消息中介應用（EAI 和 BPM 産品等）專注于消息中介（傳輸、分發和傳遞規則）。
接口/消息
- 消息在行業标準（B2MML、EDIFACT 等）中定義，是以與應用程式無關。
- 中介引擎是與應用程式無關的規則，專注于傳輸、傳遞和映射功能。
- 從應用程式級接口到标準模型的消息在标準映射元件中執行。
- 應用程式接口的應用程式接口參數被視為消息定義，并且盡可能與應用程式無關；任何特定于應用程式的參數都通過中介映射元件映射到标準模型中。
- 消息流遵循預定義的模式。
- 對話的代碼元件和配置在版本化存儲庫中進行管理。
- 資訊交換記錄在标準流程中
- 應用程式是松散耦合的。消息交換必須是異步的。同步消息交換被實作為協調的異步對話。
解決方案開發
- 80% 的消息實作是通過配置實作的；一旦定義了工廠模型和制造資訊模型，20% 需要自定義實施。
- 在部署自定義實作的地方，代碼群組件在受版本控制的存儲庫中進行管理。

3. 标準支援和一緻性

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

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

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

這種方法可幫助熟悉标準的參與供應商了解用于描述系統的語言，并了解标準未應用的位置。

4. MOM 系統架構

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

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

MOM高層架構（MOM HLA）
架構模型
資訊流模式

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，直到更大的企業實施。

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

“老天爺給你的任何機會，你也不會珍惜，更不會深入下去，你認為自己就是窮命，最喜歡通過脈脈閱讀免費的職場技巧。如果你還是杠精思維，任何事情，跑上來先論證困難，給自己一個不幹不參與的充分理由，那你完了。人生不過是短短十五年的機會，到了四十歲，你還在屌絲堆裡，啥也不幹，那你沒希望了。”