3. FactoryTalk Batch系统架构与组件
FactoryTalk Batch 不是单一软件，而是一组协同工作的服务与客户端组件。理解它的架构，关键不是记住六个名字，而是弄清“谁负责什么、谁和谁通信、数据往哪里流”。本节围绕 Batch Server、Batch Client、eProcedure、Material Manager、Equipment Manager、Report Manager 六个组件，说明它们的部署位置与通信机制。
一、整体架构：服务端与客户端分离
FactoryTalk Batch 采用典型的 C/S（客户端/服务器）架构。核心是 Batch Server，它承载批次引擎（Batch Engine），负责配方解析、批次状态机推进、单元分配与步骤调度。所有批次运行状态、配方实例、设备模型都保存在 Server 侧，客户端只是“看”和“操作”的窗口。
围绕 Server 部署的组件可分为三类：
- 操作类客户端：Batch Client（批次操作员界面）、eProcedure（电子化操作指导）。
- 资源管理类服务：Material Manager（物料管理）、Equipment Manager（设备管理）。
- 报表类服务：Report Manager（批次报表与追溯）。
它们通过 FactoryTalk 的目录服务（FactoryTalk Directory）互相发现，并借助 RSLinx Enterprise / FactoryTalk Linx 与底层 Logix 控制器通信。下图给出六个组件的部署位置与主要通信路径。
二、Batch Server：批次运行的中枢
Batch Server 是唯一持有“批次运行态”的组件。它加载配方（Recipe）与设备模型（Equipment Model），把配方中的单元过程（Unit Procedure）映射到实际设备单元（Unit），再按顺序推进操作（Operation）与阶段（Phase）。
Server 与控制器之间通过 RSLinx Enterprise 或 FactoryTalk Linx 建立通信。配方中的 Phase 通常绑定到控制器里的 Add-On Instruction 或 Phase 逻辑，Server 下发命令、控制器回传状态。例如一个“加料”Phase，Server 向控制器写入目标重量 250.0 kg，控制器执行后回传“完成”与“实际值 249.8 kg”。
Server 的部署要点：
- 通常部署在独立的 Windows 服务器上，不与其他高负载应用混装。
- 需要 FactoryTalk Directory 指向正确的域或本地目录。
- 与控制器通信依赖 RSLinx Enterprise 的通信路径配置。
- 批次历史数据写入 Historian 或 SQL，供 Report Manager 查询。
三、Batch Client 与 eProcedure：操作与指导
Batch Client 是操作员日常使用的界面。它连接到 Batch Server，显示当前批次列表、批次状态（Running / Held / Complete）、当前步骤与报警。操作员可以启动、暂停、恢复、中止批次，也可以确认人工步骤。
eProcedure 面向需要人工介入的步骤。当配方执行到人工操作节点时，eProcedure 会弹出图文指导，操作员按提示完成操作并确认，Server 才继续推进。它把“纸质 SOP”变成可追溯的电子记录，确认时间、操作员账号、步骤结果都会写入批次历史。
两者的通信机制相同：通过 FactoryTalk Directory 找到 Batch Server，建立 DCOM 或 FactoryTalk 服务连接，读取/写入批次状态。区别在于 Batch Client 偏“控制”，eProcedure 偏“指导与确认”。
四、Material Manager 与 Equipment Manager：资源建模
Equipment Manager 负责建立设备模型。它把现场设备抽象为“单元（Unit）—设备模块（Equipment Module）—控制模块（Control Module）”的层级。例如一条反应线可建模为：反应釜单元 → 加料模块、温控模块、搅拌模块。Batch Server 调度时，就是按这个模型分配资源。
Material Manager 负责物料与配方的绑定。它维护物料名称、批次号、容器、数量等信息，并在批次运行时把物料消耗记录到批次历史。例如配方需要“原料 A 250 kg”，Material Manager 会校验物料是否可用、记录实际消耗量，并支持物料追溯。
这两个组件通常与 Batch Server 部署在同一主机或同一网络域内，通过 FactoryTalk 服务与 Server 交换模型数据和运行数据。它们不直接与控制器通信，而是把资源信息提供给 Server，由 Server 统一调度。
五、Report Manager：批次追溯的出口
Report Manager 从 Batch Server 的历史数据库（Historian / SQL）读取批次数据，生成批次报表、批次摘要、物料消耗报表、报警与事件报表。它支持按批次号、配方名、时间范围、物料等条件查询，是质量追踪与合规审计的主要工具。
它的通信路径是“读历史库”，而不是实时连接 Server。因此 Report Manager 可以部署在工程师站或独立报表服务器上，不影响批次运行。典型报表字段包括：批次 ID、配方版本、开始/结束时间、各步骤实际值、操作员确认记录、物料批次号。
六、部署与通信的关键检查点
| 检查项 | 说明 | 常见问题 |
|---|---|---|
| FactoryTalk Directory | 所有组件必须指向同一 Directory | 客户端找不到 Server |
| DCOM 配置 | 跨主机通信需配置 DCOM 权限 | 连接被拒绝 |
| RSLinx Enterprise | Server 与控制器通信路径 | Phase 无法下发 |
| 设备模型一致性 | Equipment Manager 模型与配方匹配 | 单元分配失败 |
| 物料绑定 | Material Manager 物料与配方对应 | 批次启动校验不通过 |
| 历史库连接 | Report Manager 能访问历史数据 | 报表无数据 |
理解这套架构后，后续配置配方、建立设备模型、绑定物料、生成报表时，就能清楚每一步操作发生在哪个组件、数据流向哪里、出问题该查哪一段通信链路。