上述唯一 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 层） 沟通I3 概念的第 3 层充当与 ISA-95 模型的规划级别（第 4 层）的主要通信接口。该接口必须基于现场或公司的 ERP 系统来实现。一些ERP系统直接支持基于ISA-95的标准协议B2MML，这使得直接从队列层中基于ISA-95的表中处理数据变得更加容易。例如，其他 ERP 系统使用高级编程接口 (API) 或基于文件(CSV、XML)的接口。
确定推荐和应用的协议取决于具体的 ERP 系统、公司的雄心和项目的规模。
如果可能，与I3接口的最明显方式是使用 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 发送不同的事务。