简介：针对西门子WinCC用户归档功能的实践案例，适合工业自动化与SCADA系统工程师。资源围绕如何利用动作与标准模块协同实现数据归档、存储与检索，涵盖配置触发条件、编写模块逻辑、设计归档间隔与保留期限等关键环节，可帮助读者掌握从实时数据采集到历史记录管理的完整方案。资源包共290个文件，压缩后36.21MB，以rpl文件为主（250个），配合mdf/ldf数据库文件、dum备份文件、sav与ini配置，以及pdl画面、xml/h等辅助文件，完整还原示例项目结构。已有1152人学习。通过案例中提供的步骤指南、示例项目及脚本代码，读者可掌握动作和标准模块的配合方式，理解归档触发、数据筛选、格式转换与压缩存储等实现思路，并能直接参考搭建自己的用户归档系统，提升WinCC项目中的数据管理效率与排错能力。
1. 用户归档：WinCC 里最容易被当成“变量记录”的功能
做过几套 WinCC 项目后你会发现，变量记录（Tag Logging）处理的是连续变化的过程值——温度、压力、流量，画出来是趋势曲线。但有一种需求它处理不了：操作员几点几分改了配方、这批产品的物料批次号是什么、这次设备的维护记录和负责人是谁。这些数据是“事件型”的，数量少、结构固定、要长期保存、要能随时按条件查出来做成表格或报表。用户归档（User Archive）就是干这件事的。它的本质是往 WinCC 的 SQL Server 里建立一张张业务表，通过脚本读写，配合自带的归档控件做查询显示。这套方案不挑场景，从单个实验台到整条产线都适用。这篇就从需求分析讲到验收答辩，给你一套能直接照搬的 WinCC 用户归档案例设计。
2. 需求分析与技术选型：什么时候该用用户归档，什么时候别用
2.1 三类典型需求：批次追溯、操作记录、配方存储
在做用户归档之前，得先分清业务上到底要什么。我在一个模拟项目X里遇到过三种典型需求。第一类是批次追溯，每生产一批产品，要把物料批次、生产时间、工艺参数、操作员姓名存下来，出问题时能反查是哪批原料、哪个环节出了偏差。第二类是操作记录，现场的操作员切换了运行模式、修改了某个设定值、确认了一条报警，这些动作本身要留痕，形成一条可审计的操作日志。第三类是配方存储，不同产品对应不同的参数组合，把这些组合保存起来，下次生产直接调用，不再每次手输几十个变量。
这三种需求有一个共同点：数据是“行”而不是“曲线”。变量记录存的是连续的数值序列，用户归档存的是离散的记录集合。理解这个区别就理解了选型的根本逻辑。
2.2 用户归档与变量记录、数据报表的职责边界
很多同学在课设里把用户归档当成变量记录的高级版，这是最常见的认知偏差。变量记录的特点是采集周期固定、存储密度高、主要以趋势图呈现，它的强项是“过程分析”。用户归档的特点是触发写入、按行追加、可以定义任意字段结构，它的强项是“业务追溯”。如果只是想把温度历史存下来画曲线，用用户归档是自找麻烦——查询控件和图表控件对连续数据的呈现能力完全不在一个级别。
用户归档和报表工具也有边界。用户归档负责“存得进去、查得出来”，报表负责“排得好看、打得出来”。实际项目里常见做法是在用户归档里存原始记录，查询结果导出到 Excel 后用模板再加工，生成带格式、带签名的正式报表。你不需要让归档控件直接排版。
2.3 组态环境与运行环境的版本匹配要点
选型里容易被忽略的是 WinCC 的版本匹配问题。用户归档在 Classic 环境下通过“User Archive”编辑器建表，在 Unified 环境下要通过 PLC Tag 和脚本实现，两者的存储机制和控件 API 完全不同。组态时的 VBS 脚本用的是归档变量，运行时的 SQL 连接是自动建立的，版本不一致会导致归档连接失败——这是个玄学概率问题，但绝大多数根因是组态软件和运行软件版本不一致。
另外要做备份策略。用户归档的数据存在项目数据库里，好像不用管，但项目数据库膨胀、事务日志堆积会造成查询越来越慢。我的做法是以月为单位做归档数据清理，保留最近 12 个月的有效数据，更早的通过导出 Excel 后从归档表中删除。注意这里说的“清理”是指删除归档记录，不是删数据库文件。
3. 总体架构设计：三张业务表与三个功能层的职责划分
3.1 三层结构：采集层、存储层、显示层
用户归档项目的架构可以拆成三层。采集层是从 WinCC 变量或 HMI 操作事件中获取原始数据，经过格式转换后交给存储层；存储层是用户归档编辑器里定义的若干张归档表，每张表对应一个业务实体；显示层是 WinCC 画面里的归档表格控件，负责查询条件输入、结果展示和导出。采集层和显示层都在画面运行时完成，存储层在组态阶段定义。
这个分层的价值在于：换掉显示层不影响数据写入，换掉采集层不影响历史数据查询。如果后续要把表格控件换成自绘的网页报表，存储层和采集层代码几乎不用动。我见过直接把脚本写在按钮里的做法，后来需求一变，所有画面里的脚本要重写一遍，那就是给自己挖坑。
3.2 三张核心表：物料批次表、操作记录表、配方参数表
以下是一个经过实际项目验证的建表清单。物料批次表存每个批次的完整生产信息，字段建议定义为：批次号、产品名称、生产开始时间、生产结束时间、物料批次号、操作员、关键工艺参数值、质量判定结果。操作记录表存人员动作日志，字段建议为：操作时间、操作员、操作类型、操作对象、变更前值、变更后值、操作结果。配方参数表存成熟的工艺配方，字段建议为：配方编号、配方名称、适用产品、参数名称、参数值、创建时间、修改时间。
每组字段都对应一个 WinCC 变量。建表时字段名不要用中文，运行时归档表格控件支持显示中文标题，但字段名用拼音或英文才稳妥。这里有个细节：物料批次表里不要单独建一条“测试记录”去验证功能，那会污染正式数据，正确做法是建完表之后，拿真的生产数据走一遍完整流程。
3.3 归档表与 WinCC 变量的连接方式
用户归档表和 WinCC 变量之间有两种连接方式。第一种是在归档编辑器里直接把字段绑定到某个内部变量，画面运行时写入的就是这个变量的当前值。这种方式适合配方参数表这种“当前设定值快照”的场景——操作员在画面里填好参数，按下保存按钮，脚本读取变量写入一条新记录。第二种是在脚本里显式指定字段值，比如在操作记录表里，时间是脚本自动取当前时间的，操作员是从登录用户变量里取，这些都可以在写入前临时赋值。
推荐优先考虑第二种方式。原因在于显式赋值灵活，可以从任意来源取数，也可以做格式转换，出错时检查逻辑也清楚。绑定变量的方式写脚本省事，但一旦表结构增加字段，绑定的维护量很大。我一般只在配方表这种字段完全固定的场景才用绑定方式。
4. 模块实现：从建表、写入到查询导出的完整落地
4.1 在 WinCC 中创建用户归档表的具体操作流程
打开 WinCC 项目管理器，在“User Archive”节点下右键新建归档，命名建议采用“表名前缀+业务名”的格式，比如 UA_BatchInfo、UA_OperationLog。新建归档后添加字段，每个字段定义名称、数据类型和显示标题。数据类型支持整数、浮点数、字符串、布尔值和日期时间。日期时间字段建议单独定义，不要用字符串存时间，否则查询时范围过滤会非常痛苦。
字段定义完成后设置字段属性。关键属性是“可显示”“可编辑”“主键”。查询结果表格控件默认显示所有可显示字段，可编辑字段决定运行时是否允许修改。主键字段在运行时保持唯一性，用于数据更新和删除时的定位。对于操作记录表，建议设一个自增的编号字段当主键，批次表则用批次号作为逻辑主键。
建完表之后要做一步验证操作：在归档编辑器里手动添加几条测试记录，然后回到画面里的表格控件查看能否按条件查出。这一步提前做，能排除掉相当一部分字段类型设置和显示设置的问题，避免后期脚本一跑才发现字段对不上。
4.2 通过 VBS 脚本写入数据的标准实现
写入数据是用户归档的核心操作。以下脚本是写入操作记录表的标准范式：
Sub WriteOperationLog(strOperationType, strObjectName, strOldValue, strNewValue) Dim objArchives, objArchive, objFields Dim strOperator ' 取当前登录的操作员用户名 strOperator = HMIRuntime.Tags("LoginUser").Read ' 打开用户归档对象 Set objArchives = HMIRuntime.Archives Set objArchive = objArchives("UA_OperationLog") ' 创建一条新记录 objArchive.Operations.NewRecord ' 给字段赋值。字段名与组态时定义的名字必须完全一致 objArchive.Fields("OptTime").Value = Now objArchive.Fields("Operator").Value = strOperator objArchive.Fields("OptType").Value = strOperationType objArchive.Fields("OptObject").Value = strObjectName objArchive.Fields("OldValue").Value = strOldValue objArchive.Fields("NewValue").Value = strNewValue objArchive.Fields("OptResult").Value = "OK" ' 保存到数据库 objArchive.Operations.Save End Sub脚本上半部分是从登录变量里取操作员名，下半部分是对归档对象进行写入。注意每个字段赋值之后最终必须要调用 Save 方法，否则全部白写。赋值时字段名大小写不敏感，但数据类型必须匹配，把字符串赋给整数型字段会直接报错。
这段脚本在画面运行时的调用方法是在按钮事件里这样写：
Call WriteOperationLog("修改设定值", "反应釜温度", "80.5", "85.0")实际项目里通常把写入逻辑封装成公共函数，放在全局脚本里，各个画面调用同一个入口。这样后续如果存储结构变了，只需要改这一个函数，不用翻遍所有画面。这也是为什么建议用显式赋值而不是绑定变量的第二层原因——脚本入口统一，维护点集中。
4.3 查询显示与 Excel 导出：表格控件和导出脚本的配合
查询显示用 WinCC 自带的用户归档表格控件。在画面里插入控件后，属性里选择数据源为对应归档表，然后配置查询字段和显示的列。运行时用户在查询区输入条件，点击查询按钮，控件的查询 SQL 就会带上条件重新执行。这个过程中不需要手写任何查询代码。
导出 Excel 是一个高频需求。这里给出导出脚本的关键片段，它负责把当前表格控件里的查询结果导出到 Excel 文件：
Sub ExportArchiveToExcel() Dim objExcel, objSheet, objCtrl Dim intRow, intCol ' 获取画面里的表格控件 Set objCtrl = ScreenItems("ArchiveTableControl") ' 创建 Excel 应用程序，注意对象名根据本机版本调整 Set objExcel = CreateObject("Excel.Application") objExcel.Visible = False Set objSheet = objExcel.Workbooks.Add.Worksheets(1) ' 表头行：列数从控件的列集合中获取 For intCol = 1 To objCtrl.Columns.Count objSheet.Cells(1, intCol).Value = objCtrl.Columns(intCol - 1).Header Next ' 数据行：行数从控件的行集合中获取 For intRow = 1 To objCtrl.Rows.Count For intCol = 1 To objCtrl.Columns.Count objSheet.Cells(intRow + 1, intCol).Value = objCtrl.Rows(intRow - 1).Cells(intCol - 1).Value Next Next ' 保存文件，路径可以带日期，避免每次覆盖同一份 objExcel.ActiveWorkbook.SaveAs "D:\ArchiveExport\" & Format(Now, "yyyymmdd") & "_操作记录.xls" objExcel.Quit Set objExcel = Nothing End Sub这段脚本是先读取表格控件结果集，然后逐行逐列写入 Excel。要注意控件的 Rows 和 Columns 索引从 1 开始，而 Cells 的索引从 1 开始，中间差一个偏移要处理对。导出前先创建目录，如果目录不存在，SaveAs 会报错，这是一个很低级但很容易忽略的坑。
查询条件和导出路径的维护建议做成配置文件，在全局脚本的启动事件里加载。不要直接在代码里写死日期或者单元格格式，因为换一台机器部署时，路径和 Excel 版本经常不一致。
5. 避坑与常见问题排查：用户归档最容易翻车的五个点
5.1 写入以后查询不到记录：字段没保存还是查询条件有问题
现象：脚本执行没有任何报错，工业生产画面提示“保存成功”，但表格控件里查不到刚写进去的数据。
原因：通常有三种可能。一是脚本里调用了 NewRecord 但没有调用 Save，数据只存在于内存对象里；二是归档表和查询控件的数据源不是同一个归档，比如写入时操作的是 UA_OperationLog，控件配置时选的是 UA_OperationLog_Test；三是查询条件里把时间字段过滤设了当天，而测试时系统时间跨了天。
解决：先在归档编辑器里手动打开表格看数据是否存在，排除画面查询的问题。再检查脚本是否每次都走到 Save 分支，可以加一个 MsgBox 在保存前后提示，确认保存动作真的执行了。最后核对控件数据源名称和查询条件，特别是默认的时间过滤范围。
5.2 大量写入导致画面卡顿：逐条 Save 的性能问题
现象：一次批量操作连续写入几十条甚至上百条记录时，画面明显卡顿，操作员点完按钮后界面过好几秒才恢复。
原因：用户归档每次调用 Save 都是一次数据库事务，逐条提交在数据量小时感觉不到，批量写入时事务开销被放大。
解决：优先从业务上控制写入频率，比如配方保存一次性写入的场景可以接受；但如果是操作日志这种高频率写入，考虑把多条记录合并成一次写入调用。在 WinCC 的归档对象模型里，可以多次调用 NewRecord 给字段赋值，最后一次 Save 时一次性提交所有记录。修改后的脚本结构是：循环里只做 NewRecord 和字段赋值，循环结束后调用一次 Save。
5.3 归档连接异常导致脚本报错：项目重复打开或版本漂移
现象：脚本执行到 Set objArchive = objArchives("UA_OperationLog") 时提示“对象不存在”或“未找到归档”，但归档编辑器里明明能看到这张表。
原因：最常见的是组态项目被重复打开，运行环境连接到了错误的项目数据库；另一种是项目从低版本 WinCC 移植后，归档连接配置没有刷新。
解决：关闭所有 WinCC 相关进程，重新打开项目并激活。如果依然报错，检查归档编辑器的链接配置，确认链接的是当前项目的 SQL 实例。移植项目建议删除用户归档节点下的缓存文件，重新连接一次以刷新数据库链接信息。
5.4 脚本能写入但控件不刷新：数据源重新绑定问题
现象：写入脚本执行成功后，画面上的表格控件仍然是旧数据，要手动切换画面再回来才能看到新记录。
原因：表格控件默认只在画面打开时执行一次查询，写入不会触发自动刷新。
解决：在写入脚本的函数末尾调用表格控件的查询方法，比如 objCtrl.ReQuery 或重新设置一次数据源。这个调用必须在 Save 之后执行，确保数据库已经提交。如果控件绑定查询 SQL，重新赋值查询语句同样能触发刷新。
5.5 长时间运行数据库膨胀：历史数据清理策略缺失
现象：项目连续运行几个月后，归档查询变慢，导出操作时间明显延长，组态软件打开项目都变得迟钝。
原因：用户归档数据和变量记录数据都存在同一个 SQL Server 实例，记录量持续增长导致数据库文件膨胀，索引效率下降。
解决：制定按月的清理策略。保留期内的数据完整保留，到期数据导出 Excel 存档后从归档表中删除。删除操作用归档编辑器自带的功能来做最稳妥，手动写 SQL 删表存在误删风险。规划磁盘空间时按单条记录 1KB 估算，100 万条记录大约 1GB 空间，提前留好预算。
6. 验收与答辩：功能清单、性能指标与演示的准备方法
6.1 功能验收清单
做验收前先列一份可勾选的清单，每一项都要有“能看出结果”的标准。写入验收标准是：在画面执行一次写入操作，打开归档编辑器能查到这条记录，字段值与画面设定值一致。查询验收标准是：按时间范围、按操作员、按对象名三个维度分别做条件查询，结果集正确。导出验收标准是：导出文件能打开，表头与实际显示一致，数据行数与控件显示行数一致。综合起来，这句话概括了验收的核心：写入有痕迹、查询有结果、导出有文件。
6.2 性能指标与稳定性检查
性能部分要当场演示，不要只报数据。批量写入 100 条记录的耗时目标控制在 3 秒以内，超过这个值就要检查脚本逻辑或考虑合并事务。连续写入 500 条后查询响应时间目标不超过 2 秒，超过则排查索引和数据库膨胀问题。稳定性的验证方式是反复执行“写入-查询-导出”完整流程五次，每次结果保持一致，不出现记录丢失或字段错位。
答辩时数据要注意口径，这个性能数字实测要能复现，完全虚构性能数据会容易在深入追问时露馅。诚实的做法是讲清楚测试环境，记录数量级和 WinCC 版本都列明，展示的是这组配置下能跑到的水平。
6.3 答辩演示的核心路径设计
演示不要从头到尾平铺，最容易被追问的破绽在现场操作时暴露。核心演示路径设计成三段：通过写入脚本新增一条记录，切到归档编辑器展示这条记录已经落库；在查询控件里按“操作员+时间范围”过滤出这条记录，展示条件查询正确；点击导出按钮，打开生成的 Excel 文件确认内容与查询结果一致。三个动作覆盖写入、查询、导出的完整链路，每个动作都有可见的交付物。
答辩高频问题往往会指向选型决策：为什么用用户归档而不是变量记录？为什么字段数据类型选字符串而不是数字？回答的关键是回到需求本身，讲清楚事件型数据和趋势数据的区别，以及追溯场景下的查询需求决定了字段结构设计。
最后说一个我的习惯，每次做归档方案都会强制走一遍完整流程再交付，哪怕只花十分钟。从那以后，再也没有出现过“保存提示成功但数据查不到”这类低级的交付事故。希望这篇 WinCC 用户归档案例拆解，能帮你把方案做完整、把答辩讲扎实。
本文还有配套的精品资源，点击获取
