WinCC用户归档实战：产线批次数据追溯案例

简介：这份资源是面向工业自动化工程师与WinCC学习者的用户归档实践案例包，聚焦西门子WinCC中动作（Actions）与标准模块（Standard Modules）的协同使用，帮助解决实时数据存储、历史数据归档与后期分析报表等实际问题，适合具备一定WinCC基础、希望深入掌握数据管理的中级技术人员。压缩包为rar格式，共290个文件，约36.21MB，以250个rpl归档数据文件为主，另含mdf、ldf数据库文件、dum、sav、ini配置、pdl画面、xml、cfg及脚本模块等，覆盖归档数据、项目配置与可复用代码单元。目前已有1153人学习下载。通过案例中的示例项目与脚本代码，读者可理解动作触发归档任务、标准模块完成数据过滤转换与压缩存储的完整链路，并学习归档间隔、保留期限与存储介质等策略设计，提升WinCC项目的数据管理效率与故障排查能力。

1. 从一次产线数据追溯需求说起：为什么用户归档值得单独做一套案例

去年帮某实验室做产线数据追溯时，遇到一个很典型的需求：操作员在 HMI 上点一下“批次开始”，系统就要把这一批次的工艺参数、操作人、起止时间、报警记录全部绑定存下来，事后能按批次号、时间段、操作人任意组合查询，还要能导出成表格交给质量部门。听起来不复杂，但真动手才发现，用趋势曲线或报警记录去凑这套逻辑，查询维度一多就散架。后来把方案切到 WinCC 的用户归档（User Archive）上，才把“按业务字段存、按业务字段查”这件事做干净。这份案例就是围绕这个场景展开的，适合正在做毕设、课设，或者要交付一套产线数据管理方案的工程师参考。用户归档和趋势、报警最大的区别在于：它的字段是你自己定义的，不是系统预设的时间戳加数值，所以它能承载“批次号、工单号、操作人”这类业务语义，这也是它值得单独拎出来做一套完整案例的原因。

2. 需求拆解与技术选型：用户归档到底解决哪类问题

2.1 先分清用户归档和趋势、报警的边界

很多人第一次接触用户归档，会下意识把它当成“另一种趋势记录”，结果设计到一半发现查询逻辑根本对不上。我一般会先用一张表把三者的职责划清楚，避免后面返工。

从这张表能看出来，用户归档的核心价值是“业务字段可自定义 + 查询维度自由”。如果你的需求里出现了“按批次号查”“按操作人查”“按工单号导出”这类描述，基本就该考虑用户归档，而不是硬套趋势。

2.2 技术选型：为什么用用户归档而不是外部数据库

当时也评估过另一条路——用脚本把数据写到外部数据库，再自己写查询界面。这条路不是不行，但在 WinCC 单机或小型产线场景下，有几个现实问题：一是要额外维护数据库服务和连接配置，二是查询界面得自己开发，三是和 WinCC 的权限体系要重新对接。用户归档的优势在于它本身就是 WinCC 的内置组件，归档组态、变量连接、查询控件、权限控制都是现成的，组态工作量比自建数据库小一个量级。

选型的判断标准我通常这么定：如果数据量在百万条以内、查询维度不超过五个、不需要跨系统共享，优先用用户归档；如果数据量更大或要和 MES 对接，再考虑外部数据库。这份案例按前者设计。

2.3 功能清单与验收口径

需求拆完之后，我习惯先列一份功能清单，作为后面组态和验收的依据。这份案例的功能范围包括：

• 归档字段：批次号、工单号、操作人、开始时间、结束时间、温度设定值、压力设定值、实际温度、实际压力、备注
• 触发方式：操作员点击“批次开始”按钮写入一条记录，点击“批次结束”更新结束时间和实际值
• 查询方式：按批次号精确查询、按时间段范围查询、按操作人筛选，支持组合条件
• 导出方式：查询结果导出为 CSV 表格
• 权限控制：操作员只能写入和查询自己的记录，管理员可查询全部并导出

验收口径也要提前定好，否则答辩时容易被问住。我一般会定三条硬指标：单条记录写入响应时间小于 500ms；一万条记录下组合查询返回时间小于 3 秒；导出 CSV 字段与归档字段一一对应，无乱码。这三条后面在验收章节会展开怎么测。

3. 总体设计：归档结构、变量连接与查询界面的职责划分

3.1 归档结构设计：字段类型与长度怎么定

用户归档的字段定义是整个方案的地基，字段类型定错了后面查询和导出都会出问题。这份案例的归档结构设计如下：

字段长度我一般会留出余量，比如批次号实际可能只用 20 位，但定 32 位，避免以后编码规则变了要改归档结构。改归档结构意味着已有数据可能对不上，这是很麻烦的事，所以前期宁可宽一点。

3.2 变量连接：WinCC 变量到归档字段的映射

归档字段本身不存值，值来自 WinCC 变量。组态时需要把每个归档字段和一个内部变量或过程变量绑定。这份案例里，批次号、工单号、操作人来自 HMI 输入框绑定的内部变量，温度压力来自 PLC 过程变量，时间字段用脚本写入。

// WinCC 全局脚本：批次开始时写入归档记录 // 触发方式：HMI 按钮“批次开始”的鼠标点击事件 #include "apdefap.h" void OnClick(char* lpszPictureName, char* lpszObjectName, char* lpszPropertyName) { // 读取 HMI 输入框绑定的内部变量 char* batchNo = GetTagChar("Tag_BatchNo"); char* orderNo = GetTagChar("Tag_OrderNo"); char* operator = GetTagChar("Tag_Operator"); // 读取 PLC 过程变量 double tempSP = GetTagDouble("Tag_TempSP"); double pressSP = GetTagDouble("Tag_PressSP"); // 写入用户归档，参数依次为归档名、字段名、值 // 实际项目中通常用 UA_Write 系列函数或归档控件接口 UA_WriteTag("UA_BatchRecord", "BatchNo", batchNo); UA_WriteTag("UA_BatchRecord", "OrderNo", orderNo); UA_WriteTag("UA_BatchRecord", "Operator", operator); UA_WriteTag("UA_BatchRecord", "TempSP", tempSP); UA_WriteTag("UA_BatchRecord", "PressSP", pressSP); // 写入开始时间 UA_WriteTag("UA_BatchRecord", "StartTime", GetLocalTime()); // 提交记录，这一步不能漏，否则数据只在缓存里 UA_Commit("UA_BatchRecord"); }

这段脚本的关键点有三个：一是字段写入顺序要和归档结构一致，二是UA_Commit必须调用，否则记录不会真正落盘，三是时间字段用GetLocalTime()取本地时间，如果产线跨时区要改成 UTC 再转换。参数说明上，UA_WriteTag的第一个参数是归档名称，第二个是字段名，这两个名字必须和归档组态里完全一致，大小写敏感。

3.3 查询界面设计：组合条件与结果表格

查询界面用 WinCC 的在线表格控件加用户归档查询控件组合实现。上部放查询条件区，包括批次号输入框、时间段选择器、操作人下拉框；下部放结果表格，列与归档字段对应。

查询逻辑的核心是拼查询条件。用户归档查询控件支持设置过滤条件，我一般用脚本动态设置：

// 根据界面输入动态设置查询过滤条件 void SetQueryFilter() { char szFilter[512] = ""; char* batchNo = GetTagChar("Tag_QueryBatchNo"); char* operator = GetTagChar("Tag_QueryOperator"); // 批次号非空则加入过滤条件 if (strlen(batchNo) > 0) { sprintf(szFilter, "BatchNo = '%s'", batchNo); } // 操作人非空则追加条件，用 AND 连接 if (strlen(operator) > 0) { if (strlen(szFilter) > 0) { strcat(szFilter, " AND "); } strcat(szFilter, "Operator = '"); strcat(szFilter, operator); strcat(szFilter, "'"); } // 把拼好的条件设置给查询控件 SetPropChar("QueryPanel", "ArchiveQuery", "FilterSQL", szFilter); }

这里有个容易翻车的点：字符串拼接时单引号必须成对，文本字段的值要用单引号包起来，数值字段不用。如果查询结果为空，先检查拼出来的 SQL 字符串，十有八九是引号或空格的问题。

4. 关键实现：写入、查询、导出三段核心逻辑

4.1 写入逻辑：批次开始与结束的两段式写入

批次数据不是一次写完的，开始时有设定值和开始时间，结束时才有实际值和结束时间。我一般用两段式写入：开始时插入一条新记录，结束时更新这条记录。

// 批次结束时更新记录 void OnBatchEnd() { char* batchNo = GetTagChar("Tag_BatchNo"); double tempPV = GetTagDouble("Tag_TempPV"); double pressPV = GetTagDouble("Tag_PressPV"); // 构造更新条件，按批次号定位记录 char szCondition[128]; sprintf(szCondition, "BatchNo = '%s'", batchNo); // 更新实际值和结束时间 UA_UpdateTag("UA_BatchRecord", "TempPV", tempPV, szCondition); UA_UpdateTag("UA_BatchRecord", "PressPV", pressPV, szCondition); UA_UpdateTag("UA_BatchRecord", "EndTime", GetLocalTime(), szCondition); UA_Commit("UA_BatchRecord"); }

两段式写入的好处是记录从开始就存在，中途如果操作员忘记点结束，至少开始时间和设定值还在，事后能补。如果做成结束时一次性写入，中途断电就全丢了。这是血泪经验，早期项目里吃过亏。

4.2 查询逻辑：组合条件与分页处理

查询逻辑除了前面说的条件拼接，还要考虑数据量大时的分页。用户归档查询控件本身支持分页，但需要设置每页记录数。我一般设成 50 条一页，避免一次性加载太多卡界面。

// 设置分页参数 SetPropWord("QueryPanel", "ArchiveQuery", "PageSize", 50); SetPropWord("QueryPanel", "ArchiveQuery", "CurrentPage", 1); // 执行查询 SetPropChar("QueryPanel", "ArchiveQuery", "Command", "Query");

分页参数里PageSize是每页记录数，CurrentPage是当前页码。如果查询结果超过一页，界面上要放上一页/下一页按钮，按钮事件里改CurrentPage再触发查询。这个逻辑不复杂，但漏了分页，数据一多界面就假死。

4.3 导出逻辑：CSV 生成与编码处理

导出功能是质量部门最看重的，他们要拿数据去做报表。导出用脚本遍历查询结果，逐行拼 CSV 字符串再写文件。

// 导出查询结果为 CSV void ExportToCSV() { // 打开文件，注意用二进制模式避免换行符被转换 FILE* fp = fopen("D:\\Export\\BatchData.csv", "wb"); if (fp == NULL) return; // 写 BOM 头，解决 Excel 打开中文乱码 unsigned char bom[] = {0xEF, 0xBB, 0xBF}; fwrite(bom, 1, 3, fp); // 写表头 fprintf(fp, "批次号,工单号,操作人,开始时间,结束时间,温度设定,压力设定,实际温度,实际压力,备注\n"); // 遍历查询结果逐行写入 // 实际项目中通过归档查询接口获取记录集 int rowCount = GetQueryRowCount("QueryPanel", "ArchiveQuery"); for (int i = 0; i < rowCount; i++) { fprintf(fp, "%s,%s,%s,%s,%s,%.2f,%.2f,%.2f,%.2f,%s\n", GetQueryValue("QueryPanel", "ArchiveQuery", i, "BatchNo"), GetQueryValue("QueryPanel", "ArchiveQuery", i, "OrderNo"), GetQueryValue("QueryPanel", "ArchiveQuery", i, "Operator"), GetQueryValue("QueryPanel", "ArchiveQuery", i, "StartTime"), GetQueryValue("QueryPanel", "ArchiveQuery", i, "EndTime"), GetQueryDouble("QueryPanel", "ArchiveQuery", i, "TempSP"), GetQueryDouble("QueryPanel", "ArchiveQuery", i, "PressSP"), GetQueryDouble("QueryPanel", "ArchiveQuery", i, "TempPV"), GetQueryDouble("QueryPanel", "ArchiveQuery", i, "PressPV"), GetQueryValue("QueryPanel", "ArchiveQuery", i, "Remark")); } fclose(fp); }

导出这块有两个坑：一是文件要用二进制模式打开，否则 Windows 下换行符会被转成\r\n，某些系统读的时候多出空行；二是中文乱码，加 UTF-8 BOM 头是最省事的解法，Excel 能正确识别。如果导出字段里有逗号，还要做转义处理，把字段值用双引号包起来。

5. 避坑与常见问题：组态和运行阶段最容易翻车的五个点

5.1 归档记录写了但查不到

现象是脚本执行没报错，但查询界面一条记录都没有。原因通常是漏了UA_Commit调用，数据只在内存缓存里没落盘。解决方法是检查写入脚本末尾是否调用了提交函数，另外确认归档组态里“立即归档”选项是否勾选。

5.2 查询条件拼接后报语法错误

现象是点查询按钮弹出 SQL 语法错误。原因多是文本字段的值没加单引号，或者条件之间漏了空格和 AND。解决方法是把拼好的字符串先输出到诊断窗口看一眼，确认格式是Field = 'Value' AND Field2 = 'Value2'这种结构。

5.3 导出 CSV 用 Excel 打开中文乱码

现象是 CSV 里中文显示成乱码。原因是文件编码是 ANSI 而 Excel 默认按 UTF-8 解析。解决方法是在文件开头写入 UTF-8 BOM 头，三个字节EF BB BF，Excel 就能正确识别编码。

5.4 数据量大了查询界面卡死

现象是记录超过几千条后，点查询界面长时间无响应。原因是一次性加载全部记录，界面渲染扛不住。解决方法是启用分页，每页 50 条，配合上一页/下一页按钮，单次只加载一页数据。

5.5 操作员能查到别人的记录

现象是权限没隔离，操作员 A 能查到操作员 B 的数据。原因是查询条件里没加操作人过滤。解决方法是在查询脚本里自动追加当前登录用户作为过滤条件，除非当前用户是管理员角色。权限判断用 WinCC 内置的用户管理接口读取当前用户角色。

6. 验收与答辩：怎么证明这套用户归档方案是可靠的

验收这件事，我一般分三步走：功能验收、性能验收、异常验收。功能验收就是对着第 2 章的功能清单逐条过，写入一条记录，查出来字段对不对，导出 CSV 打开看列和数据是否一致。这一步最好用真实数据，别用测试用的假数据，假数据看不出编码和长度问题。

性能验收要造数据。我通常写一个循环脚本，连续写入一万条记录，然后测三个指标：单条写入耗时、组合条件查询耗时、导出耗时。写入耗时用脚本里加时间戳相减来测，查询和导出用秒表掐。前面定的指标是写入小于 500ms、查询小于 3 秒、导出小于 10 秒，实测下来一般写入在 100ms 左右，查询在 1 秒出头，导出看记录数，一万条大概 5 到 8 秒。

异常验收是最容易被忽略但答辩最容易被问的。我一般会测四个场景：写入过程中断电重启，看已提交的记录是否还在；查询条件输入特殊字符比如单引号，看会不会报错；导出时目标路径不存在，看是否有错误提示；非管理员用户登录，看能否查到全部数据。这四个场景覆盖了数据安全、输入健壮性、文件操作和权限控制，答辩时能说清楚这四个，基本就稳了。

答辩陈述我建议按“需求-设计-实现-验证”四段来讲，每段控制在两分钟。需求段说清楚为什么要做用户归档而不是趋势；设计段展示归档结构表和界面截图；实现段挑写入和导出两段脚本讲，重点说UA_Commit和 BOM 头这两个细节，评委一听就知道你真动手做过；验证段直接展示一万条数据的查询和导出结果，用数据说话比什么都强。

常见提问里有两个高频问题：一是“为什么不用数据库”，回答就按第 2 章的选型标准说，数据量和查询维度在用户归档的舒适区内，自建数据库是过度设计；二是“数据量再大怎么办”，回答是超过百万条考虑归档分段或迁移到外部数据库，用户归档本身支持按时间段归档到不同文件。

从那以后我每次做数据归档类项目，都会在组态完成后先跑一遍一万条数据的写入和查询，确认性能达标再往下做界面。这个习惯帮我提前发现过好几次分页没启用、索引没建的问题。希望这套案例的结构和实现细节，能帮你把用户归档这块硬骨头啃下来。

本文还有配套的精品资源，点击获取