把 OPC UA 接入 TEEPTRAK OEE 平台

开始之前

• 机器上的一台 OPC UA 服务器，或者在没有服务器的机器前面放一个网关。
• 一个状态源。布尔型“运行”位勉强可用，但状态机要好得多，这个差别会体现在每一份停机报告里。
• 一个统计良品和废品的计数器。边沿检测布尔量是退路，不是设计方案。
• 平台采集器与每台服务器之间的证书信任。
• 计划生产时间和订单上下文的来源，而这个来源不是设备。

配置方法

1. 弄清楚机器实际暴露了什么用通用客户端连接，读取 ServerCapabilities 代码，并对照 MachineToolType、PackML 状态机或 Machinery 构建块检查类型定义。这决定了该集成是一次映射工作还是逐台机器的标签工作，而且只需要几分钟。
2. 先映射状态，再映射数值可用率来自状态机，而不是从主轴电流推断是否在运行。在存在 MachineryItemState 和 MachineryOperationMode 的地方，两者都要映射：运行模式才是区分计划停机和故障停机的依据。
3. 映射计数器，而不是边沿让平台指向计数器节点，并显式处理复位和回绕。在某个采样间隔上对布尔量做边沿检测，会在高速时漏计产品。
4. 把原因作为事件订阅带 ConditionClassId 的 Part 9 condition 给出带时间戳、已分类的停机原因，可以干净地归因。从采样寄存器推断出的原因做不到。
5. 按分析节奏调优订阅对 OEE 来说 1 秒通常绰绰有余。对模拟量设死区，对计数器使用状态与数值触发，规划队列大小，并加上心跳，使断开的连接与空闲的设备可以区分。
6. 补足设备缺少的上下文计划生产时间、班次日历、订单与工艺路线以及标准节拍时间来自平台自身的配置或 ERP/MES。在 MES 支持的情况下，以 ISA-95 Job Control V2 为目标是基于标准的路线。

地址空间是什么样子

采集器为每台机器订阅一组节点，并映射到平台内部的设备模型上。机器实现了伴随规范时，该映射可在不同厂商之间通用；未实现时，映射是逐台机器的，并且必须随固件变更持续维护。这一差别正是坚持在采购阶段而非安装之后要求伴随规范的主要理由。

陷阱

• 布尔型运行位无法区分换型和故障停机，因此得到的可用率数字是错的，而且日后极难排查。请在规格阶段争取要到状态机和运行模式。
• 计数器回绕和复位的处理是虚假产量的真实来源。请向机器制造商确认计数器的位宽和复位行为。
• PLC 内嵌服务器常常只有 ServerTimestamp 是有意义的。带错时间戳的停机记录比没有记录更糟。
• 在任何 OEE 推广中，真正的工期风险是整个设备群的证书信任，而不是 OPC UA 集成本身。
• 嵌入式服务器上的订阅和会话上限远低于基于 PC 的服务器。在按每个标签一个订阅来设计之前先查清楚。

从中获取 OEE 数据

这就是本页的全部主题。可用率来自状态和运行模式，性能来自计数器与声明的理想节拍之比并记录程序版本，质量来自不合格品和返工计数，原因来自条件事件。边界是明确的，值得写进任何规格书：计划生产时间、班次日历、订单和标准节拍不在设备中，必须来自平台或 MES。

最后核对日期 2026 年 9 月 7 日，对照 OPC UA 1.05.07。OPC UA Connect 是教育资源，与 OPC Foundation 无隶属关系。