1. 课程导入与平台目标定义
在开始搭建任何一套生产历史数据平台之前，最容易被忽略、却最影响成败的一步，是先把"为什么建、给谁用、用到什么程度"讲清楚。WinCC 本身已经具备归档能力，为什么还要单独建设一个"生产历史数据平台"？答案往往不在软件功能，而在数据消费方式的变化：当查询从"某台操作站上看一条趋势"变成"多个部门、多个系统、跨年度地反复取数、比对、分析"时，原有的单机归档就难以支撑了。
WinCC 的变量归档（Tag Logging）与报警归档（Alarm Logging）是平台的数据源头。它们以压缩归档段的形式保存在运行系统所在计算机上，典型归档周期从 500ms 到 1min 不等，归档段按时间切分，常见配置为单段 1 天或 1 周。这种设计的出发点是"就地记录、就地查看"，因此它的强项是实时趋势与短期回溯，弱项则是长期保存、跨站汇聚和大批量导出。生产历史数据平台要解决的，正是这三件事。
平台的核心价值：从"能看"到"能算、能共享"
可以把平台的价值归纳为四个层次。第一层是长期留存：把 WinCC 归档段按策略转存到独立的数据库或历史库中，避免因运行计算机磁盘容量、项目重新下载或系统重装导致历史数据丢失。第二层是统一汇聚：当产线存在多台 WinCC 服务器或单站系统时，把分散的归档按统一时间基准和统一位号命名汇聚到一处。第三层是高效查询：支持按时间段、按设备、按批次批量取数，而不是逐条趋势手工导出。第四层是对外服务：以接口形式向 MES、报表系统、能源管理系统或数据分析工具提供数据，让历史数据真正进入业务闭环。
这四层价值决定了平台的边界。它不是实时监控系统的替代品——实时画面、联锁、报警确认仍由 WinCC 运行系统承担；它也不是一个万能的 BI 工具，平台负责把数据可靠地"存下来、取出来"，至于复杂的统计建模、机器学习预测，通常交给下游工具完成。把边界划清，后续的存储选型、接口设计、性能指标才有依据。
典型用户角色与他们的真实诉求
平台建成后会被多类角色使用，而他们的诉求差异很大，直接决定了查询接口和数据结构的设计取向。
- 现场操作与值班人员：关心最近几小时到几天的趋势，用于判断工艺是否偏离、复现异常工况。诉求是"快"，响应应在秒级，查询范围小。
- 工艺工程师：关心某个参数在整批次或整月内的变化规律，需要把多个位号对齐到同一时间轴做相关性分析。诉求是"准"和"可导出"，对时间戳精度和单位一致性敏感。
- 设备与维护人员：关心设备启停次数、运行时长、故障前后的参数快照，用于判断劣化趋势。诉求是"能按事件取数"，即围绕报警或状态跳变取一段前后数据。
- 生产管理与报表人员：关心班次、日、月的产量与能耗汇总，通常按固定模板定期出表。诉求是"稳定、可重复"，同一查询每次结果应一致。
- 信息化与自动化工程师：关心接口是否规范、数据是否可追溯、异常能否补数。诉求是"可运维"。
下面这张图把数据从 WinCC 归档到各类用户的流转关系梳理出来，可以直观看到平台在整条链路中的位置，以及不同角色对应的数据消费场景。
建设目标如何量化
目标如果只写成"实现历史数据长期存储"，后续验收时几乎无法判断是否达标。建议把目标拆成可测量的指标，并在项目启动阶段就与使用方确认。以下是一组示例指标，实际数值需根据产线规模、磁盘预算和查询并发量调整，此处仅作为设定方法的参考。
| 维度 | 示例指标 | 说明 |
|---|---|---|
| 留存周期 | 在线保存 ≥ 3 年 | 按每点 8 字节、压缩比约 5:1 估算容量 |
| 查询响应 | 单点位 24h 数据 ≤ 2s | 覆盖操作与值班人员的日常回溯 |
| 批量导出 | 10 万数据点 ≤ 30s | 面向工艺分析与报表场景 |
| 数据完整性 | 归档段转存成功率 ≥ 99.9% | 失败段需可识别、可补转 |
| 接口可用率 | ≥ 99.5%（月度） | 面向 MES 等下游系统 |
这些指标之间存在相互制约。例如把留存周期从 1 年延长到 3 年，存储成本近似线性增长；把查询响应从 5s 压到 1s，往往需要在历史库上建立更细的时间索引，写入开销随之上升。因此在目标定义阶段，应当明确哪些指标是硬约束、哪些可以折中，避免后期反复返工。
边界定义：明确"不做什么"
边界比目标更容易被忽视，但它决定了项目范围是否可控。结合前面的分析，本节建议明确以下几条边界：
- 不替代实时监控：实时画面、报警确认、联锁逻辑仍由 WinCC 运行系统承担，平台只消费已归档的数据。
- 不改变采集精度：平台沿用 WinCC 原有的归档周期与死区设置，不因平台建设而调整现场采集参数，避免影响原有系统稳定性。
- 不承担复杂建模：统计建模、预测分析、机器学习等由下游工具完成，平台提供规范的数据出口即可。
- 不引入第二套位号体系：平台内的位号命名、单位、量程必须与现有 WinCC 项目保持一致，必要时通过映射表转换，而不是重新命名。
一个具体的判断示例
假设某车间有 3 台 WinCC 单站系统，每台归档约 2000 个变量，归档周期 1s，需要保存 3 年。按每点每次记录 8 字节、压缩后约 1.6 字节估算，单台年数据量约为 2000 × 86400 × 365 × 1.6 ≈ 100 GB，三台合计约 300 GB/年，3 年约 900 GB。这个量级用一台带 RAID 的普通服务器加关系库或时序库即可承载，无需分布式集群。反过来，如果变量数达到 5 万点、周期 500ms，年数据量将上升到 TB 级，此时就需要重新评估存储架构。这个估算过程本身就是目标定义的一部分——它让"长期保存"从一个模糊愿望变成可核算的容量需求。
把价值、角色、场景、指标、边界这五件事在项目启动阶段理清，后续的采集方案、存储选型、接口设计才有稳定的出发点。这也是本课程把"导入与目标定义"放在第一章的原因：平台建设的第一步不是装软件，而是把需求讲明白。