2. WinCC系统架构与数据源梳理
在WinCC与MES集成的项目中，真正决定集成难度的往往不是通信协议本身，而是WinCC内部的数据究竟存放在哪里、以什么形式存在、能否被外部稳定读取。很多现场问题——比如MES读到的产量比实际少、报警丢失、批次数据对不上——根源都在于没有把WinCC的数据源梳理清楚。本节从WinCC项目结构入手，逐层拆解变量管理、归档系统、报警记录和用户归档这几类数据存储机制，明确哪些数据适合直接对接MES，哪些需要转换或二次处理。
一、WinCC项目结构：数据存在的物理边界
一个WinCC项目在磁盘上是一个以项目名命名的文件夹，内部包含几个关键子目录：GraCS存放画面文件，ScriptLib存放全局脚本，ArchiveManager存放归档配置，而运行期数据则集中在项目文件夹下的TagLoggingFast、TagLoggingSlow、AlarmLogging等目录中。理解这个结构的意义在于：MES要取的数据，最终都落在这些目录对应的数据库或文件里，而不是散落在画面中。
WinCC项目分为单用户项目、多用户项目和分布式项目三种形态。单用户项目中，所有数据集中在一台服务器上；多用户项目中，客户机只负责显示，数据实际存储在服务器；分布式项目则通过多台服务器分担不同区域的数据采集。对MES集成而言，必须明确“数据源主机”是哪一台，否则会出现MES连接了客户机却读不到归档数据的情况。这是集成方案设计的第一步，也是现场最容易忽略的一步。
二、变量管理：实时数据的入口
变量管理是WinCC与PLC之间的数据通道。变量分为过程变量、内部变量和系统变量。过程变量通过通信驱动（如S7-1200/1500的S7协议、Modbus TCP等）与PLC地址绑定，例如M0.0、DB100.DBD0；内部变量不连接PLC，仅用于画面逻辑；系统变量由WinCC自身产生，如时间、用户登录状态。
变量在WinCC中按“变量组”组织，例如可以建立“产线A”“产线B”两个组，每组下再按设备细分。这个组织结构直接影响MES的读取效率：如果MES需要按产线批量读取，变量组划分清晰就能减少遍历时间。变量属性中，名称、数据类型、地址、采集周期是四个关键字段。采集周期决定了MES能拿到多快的数据变化，例如设置为100ms的变量，MES通过OPC UA订阅时最快也只能感知到100ms级别的变化。
需要特别注意的是，过程变量本身不存储历史，它只反映当前值。MES如果只读过程变量，得到的是“此刻”的状态，无法回溯。因此，凡是需要历史趋势、班次统计、批次追溯的数据，都必须依赖归档系统，而不是变量本身。
三、归档系统：历史数据的存储核心
WinCC的归档系统（Tag Logging）负责将过程值按时间序列存入数据库。归档分为快速归档和慢速归档：快速归档用于采集周期短、变化快的过程值，默认存储在TagLoggingFast中；慢速归档用于变化缓慢的数据，存储在TagLoggingSlow中。两者在数据库层面是分开的，MES查询时需要明确目标归档属于哪一类。
归档的配置包含几个关键参数：归档周期（多久存一次）、归档时长（存多久）、压缩方式（是否启用死区压缩）。死区压缩是一个容易踩坑的参数：如果设置死区为1℃，那么温度在0.5℃范围内的波动不会被记录，MES读到的曲线会显得“台阶化”。对于需要精确追溯的工艺参数，死区应设为0或很小的值。
归档数据在SQL Server中存储，WinCC默认使用CC_<项目名>数据库。归档值表通常以ArchiveValue或类似命名存在，字段包括时间戳、数值、质量码。MES可以通过SQL直接查询，也可以通过WinCC的连通性软件包（Connectivity Pack）提供的OLE DB接口读取。直接查SQL效率高但耦合强，走连通性软件包更规范但需要额外授权。
四、报警记录与用户归档：事件与批次数据
报警记录（Alarm Logging）存储的是报警事件，包括报警产生时间、确认时间、消失时间、报警文本和优先级。报警数据同样存入SQL Server，表结构围绕Alarm相关表展开。MES对接报警数据时，通常关注的是“某批次生产期间发生了哪些报警”，因此需要按时间范围关联查询，而不是简单拉取全部报警。
用户归档（User Archive）是WinCC中一个相对独立的数据存储机制，它允许用户自定义表结构，用于存储批次号、配方号、操作员、检验结果等业务数据。与Tag Logging不同，用户归档不是按固定周期自动写入，而是由脚本或画面操作触发写入。例如，在批次结束时，通过C脚本或VBS脚本将批次号、产量、合格数写入用户归档表。MES读取用户归档，就能直接获得结构化的批次记录，而不需要从多个归档变量中拼凑。
用户归档的配置在WinCC的“用户归档”编辑器中完成，可以定义字段名、数据类型和索引。一个典型的批次表可能包含：BatchID（文本）、ProductCode（文本）、Quantity（整数）、StartTime（日期时间）、EndTime（日期时间）。MES通过SQL查询这张表，即可获得完整的批次清单。
五、数据源梳理的实操方法
面对一个已有的WinCC项目，梳理数据源可以按以下顺序推进：先打开变量管理，导出变量清单，标注哪些是过程变量、哪些需要归档；再检查归档配置，确认快速/慢速归档的划分和死区设置；然后查看报警记录，确认报警文本和优先级是否满足MES的展示需求；最后检查用户归档，看是否已有批次表，字段是否完整。
下面这张图展示了WinCC内部四类数据源与MES读取方式之间的对应关系，可以帮助快速判断某类数据应该走哪条路径。
从图中可以清楚看到，四类数据源对应四种不同的MES读取策略。过程变量走OPC订阅，归档数据走SQL或连通性软件包，报警按时间范围关联查询，用户归档直接查表。把这张对应关系确定下来，后续的接口开发和调试就有了明确的依据。
最后需要提醒的是，WinCC的归档数据和用户归档数据都存储在SQL Server中，但WinCC对数据库的写入是持续进行的。MES查询时应避免在WinCC归档切换或数据库维护窗口期执行大批量查询，否则可能造成锁等待甚至影响WinCC正常运行。合理的做法是错峰查询，或通过连通性软件包提供的只读接口访问，把对WinCC运行的影响降到最低。