1. 课程导入与EcoStruxure架构全景

在开始学习工业数据模型与治理之前，先建立一个整体认知：EcoStruxure并不是单一软件，而是施耐德电气面向工业、楼宇、数据中心与基础设施的开放式物联网架构体系。它把现场设备、边缘控制器、本地监控系统与云端分析平台串联起来，让数据从产生位置一路流向决策位置。本课程关注的“工业数据模型与治理”，正是这条数据链路上最容易被忽视、却决定项目成败的中间层。

学习目标

完成本课程后，你应当能够：理解EcoStruxure三层架构中数据模型所处的位置；区分OT侧设备语义与IT侧业务语义的差异；掌握以统一命名空间（UNS）和资产层级为核心的数据建模方法；能够为典型产线设备设计可复用的标签命名、类型定义与元数据结构；理解数据质量、生命周期、权限与审计等治理要素如何落地；并能在EcoStruxure平台中完成从设备接入、模型映射到数据服务发布的完整链路。

数据模型与治理在EcoStruxure中的定位

EcoStruxure通常被描述为三层结构：最底层是互联互通的产品（Connected Products），包括PLC、变频器、仪表、传感器等现场设备；中间层是边缘控制（Edge Control），包括Modicon控制器、Harmony HMI、EcoStruxure Power Monitoring Expert等本地系统；最上层是应用、分析与服务（Apps, Analytics & Services），包括AVEVA系统平台、EcoStruxure Building Operation、云侧分析等。

数据模型与治理横跨这三层。在设备层，它表现为变量命名与单位约定；在边缘层，它表现为标签映射、资产层级与本地缓存策略；在云与应用层，它表现为统一命名空间、数据字典、主数据与访问控制。如果缺少这一层，现场数据只能以“点”的形式存在，无法被业务系统理解，也就无法支撑跨系统分析与优化。

OT与IT融合的核心挑战

OT世界关注实时性、确定性与设备可用性，变量命名往往由工程师按习惯定义，例如“M1_Run”“Tank1_Level”；IT世界关注一致性、可追溯性与业务语义，期望看到“产线A/灌装单元/液位/当前值”。两者直接对接时，常见问题包括：同一物理量在不同系统中名称不同；单位不统一导致数值误判；时间戳精度与时钟源不一致；设备更换后历史数据无法关联；以及权限边界模糊，现场工程师能改的标签，业务分析人员却无法信任。

解决思路不是让OT迁就IT，也不是让IT迁就OT，而是在中间建立一层“语义翻译与治理规则”。具体做法包括：定义资产层级模板，把设备、产线、工厂组织成树形结构；为每个数据点绑定唯一标识、工程单位、数据类型、采集周期与质量码；建立命名规范并强制校验；在边缘侧完成协议转换与本地缓存，保证断网时数据不丢失；在平台侧通过统一命名空间发布数据服务，让上层应用按业务路径订阅。

整体课程路线图

本课程共30章，按“认知—建模—治理—落地”四条主线展开。前几章建立EcoStruxure架构与数据治理的基本概念；随后进入数据建模实操，包括资产层级设计、标签命名规范、数据类型与单位定义、UNS统一命名空间构建；接着深入治理专题，覆盖数据质量、生命周期、权限、审计与主数据管理；最后通过典型产线与楼宇场景，完成从设备接入、模型映射到数据服务发布的端到端案例。

一个贯穿课程的示例场景

为便于理解，课程将反复使用一个简化场景：某工厂有一条灌装产线，包含一台PLC、一台变频器、两个液位变送器和一个流量计。PLC内部变量命名为“M1_Run”“Tank1_LV”“Tank2_LV”“Flow1_PV”。在未治理状态下，这些点被直接上传到云平台，业务人员无法判断“Tank1_LV”对应哪个罐体、单位是毫米还是百分比、数据是否可信。

经过数据建模与治理后，这些点被映射为统一命名空间中的路径，例如“PlantA/Line1/Filling/Tank1/Level/Value”，并附带单位“mm”、数据类型“Float”、采集周期“1000ms”、质量码“Good”。同时，资产层级中记录Tank1的容积、安装位置与所属产线。这样，上层分析应用可以直接按业务路径订阅数据，而不需要了解PLC内部地址。