2. FactoryTalk产品体系与OEE平台架构
OEE（设备综合效率）分析平台并不是单一软件，而是由采集、存储、可视化、计算与报表多个层次协同构成的系统。在罗克韦尔自动化的FactoryTalk体系中，FactoryTalk Linx、FactoryTalk Metrics、FactoryTalk Historian、FactoryTalk View等组件分别承担数据链上的不同角色。理解它们各自"管什么、不管什么"，是选型与架构设计的前提。
一、OEE数据链上的四类角色
OEE = 时间开动率 × 性能开动率 × 合格品率。要算出这三个因子，平台必须回答四个问题：设备现在处于什么状态（运行、停机、换型、故障）？这段时间内应该产出多少、实际产出多少？合格品与废品各是多少？这些数据如何被长期保存并回溯？
FactoryTalk Linx是数据链的起点。它本质上是通信与设备集成层，负责通过EtherNet/IP、OPC UA等协议，把ControlLogix、CompactLogix等控制器中的标签（Tag）实时读取出来。它不判断"停机是否属于故障"，只负责把PLC里的原始信号——例如运行位、故障位、计数器的当前值——稳定、低延迟地送到上层。选型时关注的是驱动覆盖范围、标签浏览能力、连接数与通信负载，而不是分析功能。
FactoryTalk Metrics是OEE计算的核心引擎。它把来自Linx的原始信号翻译成"设备状态"和"生产计数"，再按班次、工单、产品型号等维度汇总成OEE三因子。Metrics的关键能力在于状态建模：工程师需要定义哪些标签组合代表"运行"、哪些代表"计划停机"、哪些代表"非计划停机"，以及停机原因如何分类。它通常与FactoryTalk View配合，由操作员在HMI上确认停机原因，形成"自动采集+人工归因"的闭环。
FactoryTalk Historian是时间序列数据库层，负责长期存储过程数据。它按固定周期（如1秒、5秒）采集标签值并压缩存储，支持趋势回放、历史查询和跨班次对比。Historian不直接计算OEE，但它为OEE的追溯分析提供原始依据——当某天OEE异常时，可以回到Historian中查看当时的转速、温度、计数曲线，判断是性能下降还是停机导致。
FactoryTalk View是人机界面与可视化层。它既可以是操作员站上的运行画面，也可以是OEE看板的数据来源。View本身不做OEE计算，但它承担两个关键职责：一是向操作员展示当前设备状态与停机原因选择界面，二是把Metrics和Historian的结果以图表、仪表盘形式呈现给班组长和管理者。
二、选型原则：按数据链缺口选组件
实际项目中，四类组件并非必须全部采购。选型的核心逻辑是：先明确OEE数据链上缺哪一环，再决定引入哪个组件。
如果现场只有PLC和HMI，没有任何OEE统计工具，那么最小可行组合是Linx + Metrics + View。Linx负责把标签读上来，Metrics负责状态建模和OEE计算，View负责操作员确认停机原因和展示看板。这种组合适合单条产线、班次管理简单、不需要长期历史追溯的场景。
如果企业已经部署了Historian用于其他过程分析，那么OEE平台可以复用Historian作为数据底座，Metrics只负责状态逻辑和OEE汇总，历史趋势查询直接走Historian。这种组合适合多产线、多工厂、需要跨班次对比和长期趋势分析的场景。
如果现场已有FactoryTalk View作为标准HMI，那么新增Metrics时可以直接复用View的画面和操作员交互，减少重复开发。反之，如果View版本较旧、不支持Metrics所需的控件或数据绑定方式，则需要评估升级成本。
三、架构设计中的关键参数与判断依据
以一个典型的汽车零部件冲压线为例。该线有5台压机、1台机械手、1条传送带，节拍约12秒/件，每天两班各8小时，计划停机包括换模30分钟和班前会10分钟。
在Linx侧，需要采集的标签包括：每台压机的运行位（Run）、故障位（Fault）、行程计数器（StrokeCount）、机械手的循环完成位（CycleComplete）、传送带的运行位。采集周期建议设为100ms～500ms，因为冲压节拍快，周期过长会丢失计数。
在Metrics侧，状态建模需要定义：运行 = 所有压机Run为1且机械手CycleComplete在跳动；计划停机 = 换模信号或班前会信号；非计划停机 = 任一压机Fault为1或传送带停止超过设定阈值。停机原因分类建议不超过8类，便于操作员快速选择。
在Historian侧，建议对StrokeCount、Fault、Run等关键标签以1秒周期归档，保留至少13个月，以满足年度OEE对比和审计要求。
在View侧，操作员站需要两个画面：一个是实时状态画面，显示当前设备状态、当前工单、已生产数、废品数；另一个是停机原因确认画面，当Metrics检测到非计划停机时弹出，操作员选择原因后写回Metrics。看板画面则展示当班OEE三因子、趋势图和停机帕累托图。
| 组件 | 核心职责 | 关键选型参数 | 不负责的内容 |
|---|---|---|---|
| FactoryTalk Linx | 设备通信与标签采集 | 驱动覆盖、连接数、采集周期 | 状态判断、OEE计算 |
| FactoryTalk Metrics | 状态建模与OEE计算 | 状态分类数、班次模型、工单维度 | 长期历史存储、HMI画面 |
| FactoryTalk Historian | 时间序列存储与回放 | 采集周期、压缩率、保留时长 | OEE三因子计算、操作员交互 |
| FactoryTalk View | HMI展示与操作员确认 | 画面数量、控件兼容性、数据绑定 | OEE计算、历史数据存储 |
四、常见架构误区
第一个误区是把Historian当成OEE计算工具。Historian擅长存储和回放，但不具备状态建模和OEE三因子汇总能力。如果只用Historian，工程师需要自己写脚本或报表来计算OEE，维护成本高且容易出错。
第二个误区是让View承担过多计算逻辑。View的画面脚本可以做一些简单统计，但OEE涉及班次切换、工单切换、停机归因等复杂逻辑，放在View中会导致画面卡顿、逻辑分散、难以复用。正确做法是View只做展示和输入，计算交给Metrics。
第三个误区是Linx采集周期设置过粗。如果OEE分析需要识别短停机（如几秒的卡料），采集周期必须足够细。一般建议关键计数标签的采集周期不超过500ms，状态标签不超过1s。具体值需要根据设备节拍和OEE精度要求权衡。
总结来说，FactoryTalk四组件在OEE数据链上各司其职：Linx管"读得到"，Metrics管"算得准"，Historian管"存得久"，View管"看得清、确认得了"。选型时先画数据链，再找缺口，最后按缺口选组件，而不是一次性全部采购。架构设计的关键在于明确每个组件的边界，让数据在正确的层次上流动和沉淀。