1. 课程导入与平台定位
在集团化制造企业中，工厂往往不是孤立运行的。一个集团可能同时拥有华东、华南、西南甚至海外的多个生产基地，每个基地又各自运行着DCS、PLC、SCADA、MES、LIMS、能源管理系统等不同年代、不同厂商、不同协议的系统。当总部希望了解“所有工厂今天的单位产品能耗是多少”“A厂和B厂同一条产线的OEE差距在哪里”“某原料在三个工厂的库存能否互相调拨”时，数据往往散落在几十个数据库、上百张报表和无数个Excel文件中。AVEVA多工厂运营数据协同平台要解决的，正是这种“数据在、但用不起来”的问题。
一、平台要解决的核心问题
多工厂数据协同的难点并不在于“采集”，而在于“统一”和“可信”。同一类数据在不同工厂可能有不同的命名：A厂叫“1#熟料线”，B厂叫“KL-01”；同一个温度点，有的系统用摄氏度、有的用华氏度；同一个班次，有的从8:00开始、有的从7:30开始。如果这些差异不在平台层被统一，总部看到的任何汇总数字都不可信。
AVEVA多工厂运营数据协同平台的核心价值可以概括为三点：
- 统一语义：通过资产模型（Asset Model）和统一命名空间，把不同工厂的同类设备、同类测点映射到同一套模板下，使“1#熟料线”和“KL-01”在平台中指向同一类对象。
- 统一时序：通过时间序列服务对多源数据进行对齐、插值、单位换算和时区归一，保证跨厂对比时“同一时刻”是真正可比的。
- 统一视图：通过运营看板、KPI计算和事件管理，把分散的实时数据、历史数据和业务指标组织成总部、区域、工厂三级都能使用的视图。
需要强调的是，平台不是要替代各工厂现有的DCS或MES，而是作为“运营数据层”位于它们之上，做汇聚、标准化和协同分析。工厂原有的控制逻辑、安全联锁、生产执行流程保持不变。
二、典型适用场景
以下场景是该平台最常见的落地切入点，也是后续章节会反复用到的业务背景：
| 场景 | 典型问题 | 平台提供的能力 |
|---|---|---|
| 集团级KPI对标 | 各厂OEE、能耗、收率口径不一致 | 统一KPI模板、跨厂对比看板 |
| 集中监控与报警 | 总部无法实时掌握各厂关键装置状态 | 多厂实时数据汇聚、统一报警分级 |
| 能源与碳排放管理 | 能耗数据分散、无法按产品分摊 | 能源模型、单位产品能耗计算 |
| 跨厂库存与调度 | 原料、备件库存信息不透明 | 库存数据协同、调拨建议 |
| 设备健康与预测维护 | 同类设备故障模式无法跨厂复用 | 设备模型、振动/温度趋势集中分析 |
这些场景有一个共同前提：数据必须先“进得来、对得上、看得懂”。因此平台的整体架构不是简单的“采集—存储—展示”三层，而是围绕资产模型和时间序列两条主线组织的。
三、整体架构概览
从数据流向看，平台可以理解为五个层次：工厂侧数据源、边缘采集与缓冲、平台接入与建模、统一数据服务、运营应用。工厂侧的DCS、PLC、 historians、MES通过OPC UA、OPC DA、Modbus、SQL等接口把数据送到边缘节点；边缘节点做协议转换、断线缓存和初步过滤；平台接入层完成数据清洗、时间戳对齐和资产模型绑定；统一数据服务提供实时查询、历史查询、KPI计算和事件服务；最上层是总部看板、工厂看板、移动端和第三方系统。
下面这张图用“数据流+分层”的方式展示平台的整体架构。图中左侧是工厂侧数据源，中间是边缘与平台接入，右侧是统一数据服务和运营应用；箭头方向表示数据从工厂向总部汇聚，同时平台向工厂下发模型配置和KPI定义。
理解这张图时，建议抓住三条主线。第一条是数据上行：从工厂侧到边缘、到平台、到应用，数据逐步被标准化。第二条是模型下行：资产模型和KPI定义从平台配置后下发到边缘和工厂侧，指导数据如何被组织和计算。第三条是服务分层：实时查询、历史查询、KPI计算和事件服务是并列的能力，应用层按需调用，而不是把所有逻辑堆在一个看板里。
四、一个具体的协同示例
假设集团要对比A、B两个工厂熟料线的单位产品综合能耗。A厂DCS中该测点名为“KL1_Energy_kWh”，单位是kWh，时间戳为本地时间；B厂Historian中名为“B_KL_01_Power”，单位是MWh，时间戳为UTC。平台的处理过程是：边缘节点分别采集两个测点，平台接入层根据资产模型把两者绑定到“熟料线/能耗”模板，统一换算为kWh，统一到同一时区，再按班次聚合。最终在集团看板上，两个工厂的“单位熟料综合能耗”可以直接并列比较。如果某一天B厂数据缺失，平台会依据配置的插值策略标记数据质量，而不是直接显示一个看似正常的数字。