智能集成接口：I3 ISA-95 的应用

介绍

多年来，使用基于制造运营管理 （MOM） 的应用程序的制造 IT 顾问试图说服制造商这些类型的应用的高价值。实时 MOM 解决方案是唯一一组能够精确优化工厂日常运营的 IT 应用程序，可为其可用性流程带来可创造的价值，但制造商在认识到实施 MOM 的任何给定部分所产生的可操作指标与用于可见性和界面的定期关键绩效指标 （KPI） 之间的差异方面上进展缓慢。

决策者通常非常不愿意在他们的工厂或企业中开始任何类型的MOM实施，因为这些项目的规模很大，风险很高，成本很高。从历史上看，由于客户对软件的了解不够，许多 MOM 项目在按时或按预算结束时都存在重大问题。这通常是由于项目中的某个人，无论是销售人员、程序员，甚至是客户，试图在解决方案的第一个 MOM 项目中使解决方案 100% 地满足客户的需求。所有各方都不同意可实现的MOM项目和功能路线图。因此，项目参与者往往忽视了项目的真正和可实现的目标。

本文中描述的 I³ 概念基于众所周知的标准，包括 ISA-95 和 B2MML，并为企业资源规划 (ERP) 系统和过程控制系统之间的集成添加了一些进一步的功能。

本文描述了 I³ 方法，并提供了一个如何在“现实生活”中应用标准的示例。

MOM 项目受到运营部门和企业集团之间相互冲突的优先级的影响，因此当目标在时间功能范围内相距甚远时，保持项目重点总是很困难的。当项目团队不关注近期目标时，最初的目标几乎永远不会实现。

在 MOM 领域，公司面临着“永恒的软件困境”，使用商用现货 (COTS) 软件工具应用简单的解决方案，只需配置（无需编程）即可执行项目功能和任务；节省大量开发时间和资金（但会增加接口和报告成本），最终得到仅满足您 80% 需求的解决方案，或应用编程工具并修改解决方案以完全满足您的需求，尽管这样做需要大量的编程、较长的时间和良好的架构技能。

在I³方法论，这两者都有一些元素——一些标准软件和一些编程。

最好的做法是从小处着手解决文化采用和一致性问题，然后将功能扩展到路线图，而不是强迫公司实施所谓的全面 MOM 解决方案。本章节中详细介绍了一种称为“智能集成接口”(I³) 的项目方法。

MOM 项目和功能路线图对于长期（例如，X年）业务目标和/或包含项目利益相关者需求的已定义和指定策略的成功至关重要。有了这样的路线图，项目成员就可以将这些目标和策略作为项目中的指导里程碑，并随时重新审视它们以确认它们是否走上正轨。

但要在预算内按时实现指导性里程碑，应始终明确定义短期目标并进行有效沟通，以便容易看到和实现这些目标。

在 I³ 项目中，任何 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 层）之间建立一个集成基线。因此他们可以以智能高效的方式交换数据。I³ 方法比仅仅集成或连接系统更进一步；它还为解决方案增加了一些智能，以便在工厂运营中有效执行和响应。

这就是 I³ 作为集成概念发挥作用的地方。

I³ 是什么？

I³ 概念基于将软件功能块置于规划层和控制层之间，形成 MOM 解决方案（ISA-95 中的第3层）。I³涵盖了制造运营的某些部分（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 层）

沟通

I³ 概念的第 3 层充当与 ISA-95 模型的规划级别（第 4 层）的主要通信接口。该接口必须基于现场或公司的 ERP 系统来实现。一些ERP系统直接支持基于ISA-95的标准协议B2MML，这使得直接从队列层中基于ISA-95的表中处理数据变得更加容易。例如，其他 ERP 系统使用高级编程接口 (API) 或基于文件(CSV、XML)的接口。

确定推荐和应用的协议取决于具体的 ERP 系统、公司的雄心和项目的规模。

如果可能，与I³接口的最明显方式是使用 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 图以图形方式显示业务和运营如何处理不同的日常情况以及要使用的规则。这使得在此处描述的解决方案中更容易实现规则。

将 I³ 映射到 ISA-95

I³ 概念的核心部分在很大程度上依赖于 ISA-95 标准。

在第3层内以及第2层和第4层间定义运营管理功能、任务和交换的标准是全球制造商设计下一代 MOM 解决方案的绝佳方法。

ISA-95 标准中的一些模型解释了 I³ 的功能如何映射到标准。图 7-3 显示了 ISA-95 第 3 部分中描述的生产运营管理活动模型的哪些特定部分已在解决方案中实施。

图 7-3：生产运营管理的活动模型

使用“生产数据收集”是因为生产数据是从流程中收集并交换到 ERP 系统的。之所以使用“生产跟踪”，是因为已向 ERP 系统报告了所用资源（物料、位置和机器）和生产物料（中间和成品、实际与计划）的摘要。

“生产调度”的一小部分是通过为操作员提供一个简单的生产订单调度列表来使用的。

可以使用 B2MML 消息与 ERP 进行通信，以建立公司对预定义接口的集成基线标准。在某些情况下，B2MML 接口可以从 ERP 系统通过 I³系统应用到过程控制系统。当然，如果以后需要，这可以更轻松地从一个系统更改为另一个系统 (ERP-I³-PCS)。

结论

从任何 MOM 解决方案的核心功能（IT 系统之间的集成）开始，将使项目和解决方案变得简单，使其适应制造商的当前需求，同时以更低的成本满足未来的需求。如果这样做，随着全球市场推动制造商组织的变化，扩展功能可能会被迅速部署。制造商的成功归功于适应性强的 MOM 和集成解决方案本身。由于 I³概念是在模块中构建的，因此构建所需的内容然后稍后添加功能非常简单。只需“离线”将功能添加到正确的模块，测试功能和接口，然后交换旧模块和新模块。

所描述的概念 (I³) 最适合已安装 ERP 系统和过程控制系统（负责大部分执行部分）并且只需要两者之间的通信接口的工厂。

尽管 I³是解决制造过程和 ERP 系统之间通信问题的简单方法，但在一些现场实施此解决方案仍然可能是“矫枉过正”。I³应该被视为基于未来功能需求的选项，即使接口保持更简单，例如，可能不需要处理该站点的业务逻辑和/或异常。

另一方面，如果处理业务逻辑的需求非常复杂，建议考虑标准化的现成解决方案，而不是尝试从头开始对解决方案进行编程。这将为公司节省时间和金钱。

如果制造商拥有从头开始实施系统的新建工厂，在这种情况下，通常最好的方法是从核心功能开始，然后扩展功能。

本文中描述的解决方案不是“产品”。它只是一种处理生产和 ERP 之间接口的方法或概念，许多创新制造商已成功应用。从一个项目到下一个项目已经并且将会有一定数量的重用。但是在新项目中，需要对 MOM 和接口要求进行分析，以确定必要的功能并决定 I³是否是最佳方式。

MOM 转型路线图对于长期（例如，X年）业务目标以及包含项目利益相关者需求的已定义和指定战略的成功仍然至关重要。如前所述，始终牢记总体目标和画面，并对公司现在的业务需求、未来的预期以及系统的价值进行初步分析，这一点至关重要。可以在X年内找到（即定义指导里程碑）。如果您不了解或不了解 MOM 解决方案的可能性以及可能存在的陷阱（例如，集成许多不同的 IT 系统），这将很难甚至不可能做到。

因此，制造商的最佳做法是与经验丰富的 MOM 顾问合作，他们以前尝试过类似的事情，并且可以将解决方案引导到正确的方向。