介绍

供应商提供的信息系统随着新功能和实施策略不断发展。可用选项的复杂性和多样性使许多公司难以充分讨论和比较可能满足或不满足其要求的替代方案。

供应商通常会推广由公司或个人工具箱中的产品或解决方案支持的架构。如果公司对其运营系统的架构没有清晰的愿景，它通常会采用供应商的方法。这种方法可能最适合正在开发的系统；然而，在许多情况下并非如此。

在没有目标“未来”架构的情况下，采用供应商的方法是不可避免的。随着对系统敏捷性和相关运营管理能力的日益依赖，提高标准的必要性显而易见。公司必须能够了解他们的生产流程和结构，以此作为实际流程改进的基础。一旦理解，现状和目标未来架构将作为讨论和映射替代方案的共同基础。

本文介绍了用于描述操作系统和让利益相关者参与基于产品独立架构的项目的技术，并附有示例。

这种方法改变了与供应商谈判中的游戏规则，从以产品为中心的评估转变为以操作系统能力为讨论重点的评估。产品选择过程包括需求和与关键设计原则的一致性。

介绍了一系列最先进的企业和解决方案架构概念，可用作开发操作系统架构 (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. 业务路线图回顾

• 当前环境的现状是什么？
• 未来的环境是什么？
• 长期目标是什么？
• 到达那里的步骤是什么？按照：
  • 业务成熟度
  • 人员和流程
• 路线图中的关键附加值和文化敏感性在哪里？

2. 系统功能/架构的发现

• 启用业务流程中的步骤需要哪些功能？
• 确定底层架构：
  • 有哪些高级概念？
  • 什么样的架构能够支持业务路线图？
  • 架构必须考虑最终状态并展示其相对于最终状态的演变。
• 从现有系统和技术采用的角度考虑运营和 IT 能力：
  • 业务成熟度、理解和利用概念的能力 需要进行文化和培训练习。
  • 适合业务成熟度级别的能力。通常有一个轻量级的临时解决方案，适合业务的直接成熟度级别。随着成熟度的增长，必须规划更有能力的系统。
• 哪些技术能力处于高水平？

3. 对照MOM和IT标准进行分类

• 根据标准（ISA、ISO、IEC 等）表示系统组件
• 比较与现有技术（WS、SOA、REST 等）相关的系统架构。
• 对系统相对于其他系统（同类最佳等）的能力/成熟度进行分类，以识别差距/机会。

4. 能力/架构路线图开发

• 确定技术/能力的最终状态。
• 记录在能力和架构方面迈向最终状态的步骤。

5. 对业务要求的步骤排名

• 使能力和架构路线图与业务需求保持一致。

6. 细化/深入研究高价值领域

结果是系统的运营能力的优先列表，然后必须与业务价值保持一致，并得到用于开发/实施的业务案例的支持。这是 OSA 开发的一个重要方面。如果它与业务的需求和价值无关，那么为了乌托邦式的愿景而设计优雅的架构是没有意义的。

说明 OSA 意图的另一种方式是，有效的 OSA 使人员和系统能够满足业务需求。操作系统（人和机器）能够更有效地满足业务需求（敏捷性、效率、灵活性等）。OSA 支持业务流程以及这些流程的持续改进。

OSA 是什么样的？

操作系统架构的表现形式和内容取决于所代表的环境。可以将典型 OSA 的组件描述为特定表示的模板。

典型的 OSA 组件是（这些组件将在高级架构中介绍）：

1. 使业务驱动因素与 OSA 路线图和 MOM URS 保持一致
2. 指导原则
3. 标准支持和一致性
4. 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、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，直到更大的企业实施。

有了这种能力，公司就可以在不受供应商偏见影响的情况下更好地捕捉其运营流程的真实语义。有了这些模型，与供应商在实施中的接触发生了变化，在下订单之前，对核心概念的讨论就摆在桌面上，而不是在项目进行中或之后才被发现。