WinCC动态查询报警记录并导出Excel的完整方案

搞上位机的兄弟肯定遇到过这个需求：操作员说不想每次都找工程师导报警，想自己在画面上选个时间段、勾个报警类型，点一下查询，报警记录就出来了，最好还能一键导成Excel。这就是典型的WinCC动态选择报警记录场景。

这个需求看起来不起眼，做起来却有不少门道。WinCC自带的报警控件确实能看记录，但筛选项固定、样式不好改、导出格式也死板，碰上要做交接班报表、故障统计分析的时候根本不够用。我前段时间在项目里完整做了一套“动态选择报警记录”功能，把查询界面、SQL拼接、表格展示、Excel导出全跑通了，今天把整个方案和踩过的坑都写出来。案例基于经典WinCC V7.x（V7.4/V7.5测试通过），如果你用的是博途里的WinCC RT Advanced，后面我会专门说差异。

1. 方案对比与选型思路

1.1 三种常见实现路线对比

做报警记录动态查询，我见过的大概有三条路：用WinCC自带报警控件、用SQL直查数据库、用WinCC报表系统。先看对比。

很多项目一开始图省事用自带控件，做到后面发现导出格式调不动，筛选项加不了，又推倒重来。我的建议是：只要操作员明确提出了“自己选条件、自己导数据”这类需求，就一步到位走SQL直查。

1.2 为什么选“SQL直查+表格控件”

这个案例的核心诉求是“动态选择”，也就是查询条件在运行时不固定，由操作员现场决定。WinCC报警控件的筛选虽然能通过脚本设置，但它的筛选逻辑是封装好的，很多字段不能随意组合，比如“按设备名称模糊查+只查未确认的报警+时间范围”这种组合，控件就不太好使。

SQL直查的思路很简单：WinCC的报警记录本来就是往SQL Server数据库里写的，我直接用VBS脚本拼接SQL语句去查这张表，把结果填到画面里的表格控件上。这样查询条件完全由我代码控制，想怎么组合就怎么组合，展示样式也能完全跟着项目风格走。

这个方案还有一个隐藏好处：查询结果可以很方便地二次加工。我在项目里除了展示，还用同一套查出来的记录做了简单的统计计算，比如每种报警类型出现次数、每日报警趋势，这些用自带控件是做不了的。

1.3 先说清楚这个方案的边界

不是所有WinCC环境都适合用SQL直查。经典WinCC V7.x的项目库就是SQL Server库，报警归档在里面，直查没问题。但博途里的WinCC RT Advanced，报警归档不一定落SQL库，这招就不太好使了，优先用报警控件加脚本筛选，或者做成运行时导出。

另外要注意，SQL直查读取的是已经归档的报警记录，实时性有延迟。如果你想做“当前正在发生的报警”实时列表，那应该用WinCC的报警控件或者变量连接，而不是查数据库。

我做完这套功能后最大的体会是：方案本身不复杂，真正花时间的是摸清报警库的表结构，以及处理好各种边界情况。下面重点讲这两块。

2. 报警数据从哪来：库、表、字段定位

2.1 WinCC报警归档的数据落点

经典WinCC项目装好后，SQL Server会创建一个以项目名命名的数据库，默认实例名通常是.\WinCC。报警记录就存在这个库里，不在单独的外部数据库。

很多教程会让你新建一个外部SQL库，再用脚本往里写数据，方便做报表。这个思路没问题，适合跨系统集中管理。但在这个案例里，报警数据本来就实时写进项目库了，直接查项目库，少一层中转，数据最全，也省心。只有当你的报表系统需要和其他产线数据做关联分析时，才值得单独建库同步。

2.2 用SQL Profiler一招定位真实表名与字段

这里必须说一个坑：WinCC不同版本、不同补丁下，报警归档的表名和字段名是有差异的。网上搜到的教程里直接写死表名，比如ALGV2_SIMATIC_...，换台机器可能就不一样。最稳妥的办法是现场定位，不要凭记忆猜表名。

定位方法很简单，三步：

1. 在服务器上打开SQL Server Management Studio，连接到.\WinCC。
2. 启动SQL Profiler，选择WinCC项目库作为跟踪数据库。
3. 在WinCC运行画面里打开自带的报警控件，手动做一次时间范围筛选。

这时切回Profiler，就能看到WinCC自己执行的那条SELECT语句，表名、字段名全在里面。照着这个写自己的SQL，绝对错不了。

我第一次做这个案例时，就是靠这个方法发现目标表名并不是网上教程里说的那个，而是带了一长串GUID后缀。要是直接照搬网上的表名，查出来的数据肯定是空的。

2.3 理解关键字段：时间、消息文本、设备、状态

拿到真实表结构后，重点找这几类字段。WinCC的报警归档表字段很多，但不是每个都用得上。

• 时间字段：报警到达时间、确认时间、离开时间。注意底层可能存的不是datetime类型，而是整数秒或者字符串格式，查询时要做转换。
• 消息文本字段：报警显示的文字内容，比如“1号电机过载”。
• 设备或变量名字段：报警来自哪个变量，可以用来过滤具体设备。
• 状态字段：报警当前状态，是否已确认、是否已离开。

项目里具体字段名以你查到的为准。我这边案例中，时间字段底层是整数秒存储，显示层才转成日期时间。所以SQL里做时间范围过滤时，不能直接写where arrive_time between '2024-01-01' and '2024-01-02'，得先把前端传过来的时间转成对应的整数格式，或者在SQL里用DATEADD函数转换。

这里分享一个通用判断方法：如果你不确定字段是否可以直接用datetime比较，就先在Management Studio里看几条数据的原始值。如果是几百位的大数字，就是时间戳；如果是20240101123000这种字符串，就按字符串截取比较。这个案例里我用的方案是：前端拿到的起始、结束时间，在VBS里先格式化成和目标字段一致的格式，再拼接进WHERE条件。

2.4 连接字符串的配置要点

VBS里用ADODB连接项目库，连接字符串长这样：

Dim connStr connStr = "Provider=SQLOLEDB;Data Source=.\WinCC;Initial Catalog=MyPlant;Integrated Security=SSPI"

几个关键点：

• Data Source用.\WinCC，表示本机WinCC默认实例。如果连接远程服务器，换成服务器IP和端口，比如192.168.1.10,1433。
• Initial Catalog换成你的项目数据库名，注意区分大小写。
• Integrated Security=SSPI用Windows集成认证。WinCC运行系统和SQL Server在同一台机器上时一般没问题，但如果SQL Server做过权限收紧，可能需要单独建一个只读账号，用User ID和Password方式连接。我建议生产环境建个只读账号，别用sa，安全第一。

排错提示：如果VBS脚本报“未找到提供程序”，检查系统里有没有SQLOLEDB驱动。WinCC自带的运行环境一般都有，但有些精简系统可能会缺，换成Provider=SQLNCLI11试试。

3. 动态查询界面与VBS脚本落地

3.1 画面布局与对象组态

查询画面我按“上条件、中表格、下按钮”的布局来做，操作员看起来直观，代码也好维护。

上边是筛选条件区域，放了这些对象：

• 开始时间、结束时间：用WinCC的“日期时间”输入控件，或者直接用IOField绑定字符串变量。
• 报警类型：一个下拉框（ComboBox），选项有“全部、上限报警、下限报警、设备报警、系统报警”。
• 确认状态：下拉框，选项有“全部、已确认、未确认”。
• 设备编号：文本框，支持模糊输入，可以填“01”查所有设备号带01的报警，也可以留空查全部。

中间放一个表格控件，我用的MSFlexGrid，行数和列数在脚本里动态设置。有些精简系统没有这个控件，也可以用ListView，但列表样式在WinCC运行画面里美化起来不如网格方便。

下边放三个按钮：查询、导出Excel、清空条件。

3.2 动态拼接WHERE条件：从下拉框到SQL

这是整个案例最核心的脚本逻辑。按钮的Click事件里写VBS，思路是先收集界面上的条件，再拼SQL字符串。

核心代码结构如下：

Dim strSQL, strWhere, strTimeFrom, strTimeTo strWhere = "" ' 时间条件：必选，避免全表扫描 strTimeFrom = ScreenItems("IOTimeFrom").Text strTimeTo = ScreenItems("IOTimeTo").Text If strTimeFrom = "" Or strTimeTo = "" Then MsgBox "请选择开始时间和结束时间" Exit Sub End If strWhere = " WHERE 到达时间字段 >= '" & FormatTimeStamp(strTimeFrom) & "'" strWhere = strWhere & " AND 到达时间字段 <= '" & FormatTimeStamp(strTimeTo) & "'" ' 报警类型：下拉框选项转条件 Dim strType strType = ScreenItems("CBType").Text Select Case strType Case "上限报警" strWhere = strWhere & " AND 消息编号字段 LIKE '1%'" Case "下限报警" strWhere = strWhere & " AND 消息编号字段 LIKE '2%'" Case "设备报警" strWhere = strWhere & " AND 消息编号字段 LIKE '3%'" End Select ' 确认状态：用确认时间字段是否为空来判断 Dim strState strState = ScreenItems("CBState").Text If strState = "已确认" Then strWhere = strWhere & " AND 确认时间字段 IS NOT NULL" ElseIf strState = "未确认" Then strWhere = strWhere & " AND 确认时间字段 IS NULL" End If ' 设备编号：模糊查询 Dim strDevice strDevice = Trim(ScreenItems("IODevice").Text) If strDevice <> "" Then strWhere = strWhere & " AND 设备字段 LIKE '%" & strDevice & "%'" End If strSQL = "SELECT 到达时间字段, 消息文本字段, 设备字段, 确认时间字段 FROM 报警表名" & strWhere & " ORDER BY 到达时间字段 DESC"

注意几个细节：

• 时间条件是必选的，这个一定要做成强制限制。报警表动辄几十上百万条数据，没有时间边界直接查询，画面会卡死，数据库也会被拖垮。
• 拼接字符串时，日期时间统一转换成字段底层存储的格式，比如统一成YYYYMMDDHHMMSS的字符串，这样SQL里可以直接比较。
• 用MsgBox做条件校验虽然简单粗暴，但很有效。操作员忘选时间时，弹个提示比按钮没反应好得多。

3.3 查询结果填充到表格控件

SQL拼好之后，用ADODB执行查询，再把结果一条条填进MSFlexGrid。这一步我封装了一个子过程，方便后面刷新和导出复用。

Sub FillGrid(sqlText) Dim cn, rs, i, j Set cn = CreateObject("ADODB.Connection") cn.ConnectionString = "Provider=SQLOLEDB;Data Source=.\WinCC;Initial Catalog=MyPlant;Integrated Security=SSPI" cn.Open Set rs = CreateObject("ADODB.Recordset") rs.CursorLocation = 3 ' adUseClient rs.Open sqlText, cn, 3, 1 ' adOpenStatic, adLockReadOnly Dim grid Set grid = ScreenItems("GridAlarm") grid.Rows = rs.RecordCount + 1 grid.Cols = 4 ' 表头 grid.TextMatrix(0, 0) = "到达时间" grid.TextMatrix(0, 1) = "报警文本" grid.TextMatrix(0, 2) = "设备编号" grid.TextMatrix(0, 3) = "确认时间" ' 数据行 i = 1 Do While Not rs.EOF grid.TextMatrix(i, 0) = rs.Fields(0).Value grid.TextMatrix(i, 1) = rs.Fields(1).Value grid.TextMatrix(i, 2) = rs.Fields(2).Value grid.TextMatrix(i, 3) = rs.Fields(3).Value i = i + 1 rs.MoveNext Loop rs.Close cn.Close Set rs = Nothing Set cn = Nothing End Sub

这里有个性能经验：rs.CursorLocation设置为adUseClient，先把查询结果取到客户端内存，再循环填充。服务器端的游标不适合这种大批量数据遍历，响应会慢很多。

数据量大的时候，建议在网格下方加一行提示，显示“共查询到XXX条记录”。我是在FillGrid子过程里统计rs.RecordCount，赋给一个文本对象显示的。

3.4 一键导出Excel

导出Excel是操作员用着最爽、也是踩坑最多的功能。核心思路是用VBS创建Excel的COM对象，把网格里的数据写进去，再保存文件。

Dim xlApp, xlBook, xlSheet, i, j Set xlApp = CreateObject("Excel.Application") xlApp.Visible = False Set xlBook = xlApp.Workbooks.Add Set xlSheet = xlBook.Worksheets(1) Dim grid Set grid = ScreenItems("GridAlarm") For i = 0 To grid.Rows - 1 For j = 0 To grid.Cols - 1 xlSheet.Cells(i + 1, j + 1) = grid.TextMatrix(i, j) Next Next Dim strFileName strFileName = "D:\AlarmReport\报警记录_" & Year(Now) & Month(Now) & Day(Now) & Hour(Now) & Minute(Now) & ".xlsx" xlBook.SaveAs strFileName xlBook.Close xlApp.Quit Set xlSheet = Nothing Set xlBook = Nothing Set xlApp = Nothing

三个实战中容易踩的坑：

• 目标文件夹必须提前建好，Excel不会自动创建目录。报错“文件不存在”十有八九是这个原因。
• 文件名加时间戳，避免每次导出覆盖之前的文件。操作员导完发现忘存，还得重新导，有版本号方便追溯。
• xlApp.Quit之后一定记得Set xlApp = Nothing释放COM对象，否则内存里会残留很多Excel进程，WinCC长时间运行会越来越卡。

要是系统装的是64位Office，而WinCC运行库是32位进程，直接创建Excel COM对象可能报“远程过程调用失败”。我遇到这个情况后，给操作员电脑统一装了32位Office就解决了。如果实在不想折腾Office版本，可以改成导出CSV文件，Excel也能打开，用文本流写文件，完全不依赖COM。

3.5 定时自动刷新实现

动态查询不仅要手动查，还要支持定时自动刷新。我在WinCC全局脚本里建了一个周期执行的脚本，每60秒跑一次，读取当前画面上的筛选条件，自动重新查询。

关键点是刷新前判断当前查询条件是否有变化。我的做法是把最近一次查询的条件存到全局变量里，刷新时先比对，条件没变就不重复查询，避免数据库白白扛压力。

' 全局脚本，周期执行 If ScreenItems("GridAlarm").Visible = False Then Exit Sub End If Dim strNowFrom, strNowTo strNowFrom = ScreenItems("IOTimeFrom").Text strNowTo = ScreenItems("IOTimeTo").Text ' 上次查询的时间范围 Dim strLastFrom, strLastTo strLastFrom = HMIRuntime.Tags("LastQueryFrom").Read strLastTo = HMIRuntime.Tags("LastQueryTo").Read If strNowFrom <> strLastFrom Or strNowTo <> strLastTo Then ' 条件变了，触发查询 ' 调用FillGrid和更新LastQuery标记 End If

这个设计很实用：操作员上班打开画面，页面上自动刷新最新的报警，不用每次手动点查询。条件变更后立刻用新条件查，查完更新标记，下次条件不变就不动作。

4. 常见问题与排查实录

4.1 查不到数据：十有八九是这几个原因

我在调试时遇到过三次查不到数据的情况，每次原因都不一样。

第一次是表名搞错了。网上教程写的表名和我实际项目里的对不上，用Profiler一看才找到真实的表。这个不多说了，前面已经强调过。

第二次是时间字段格式不匹配。我开始直接拿界面上的datetime字符串去和数据库里的整数时间字段比较，结果当然查不到。后来把时间先转成和目标字段一致的格式再拼接，问题解决。

第三次是权限不够。连接字符串用集成认证，但WinCC运行服务的系统账号在SQL Server里只有public权限，没有读报警表的权限。给账号加上db_datareader角色后解决。

排查顺序建议：先跑一条最简单的SQL，用Management Studio执行，看能不能查到数据；再用VBS的MsgBox把最终拼接出来的SQL打印出来，直接复制到Management Studio里跑。这一步能定位80%的问题。

4.2 中文乱码与Excel导出异常

报警消息文本查出来中文乱码，这个常见于历史项目数据库字符集不一致的情况。解决办法是在连接字符串里加上Auto Translate=False，避免ODBC自动做字符集转换。

connStr = "Provider=SQLOLEDB;Data Source=.\WinCC;Initial Catalog=MyPlant;Integrated Security=SSPI;Auto Translate=False"

导出Excel后中文乱码，如果是用CSV方式，需要带UTF-8 BOM，Excel才会正确识别编码。如果用Excel COM写入单元格，只要系统区域设置正确，一般不会乱。

还有一个奇怪的坑：Excel导出时提示“文件正被占用”，其实是操作员之前手动打开了一个同名的Excel文件没关，SaveAs到同一个路径就会冲突。文件加时间戳后这个问题基本绝迹。

4.3 性能压不住？给查询设置安全边界

报警记录表数据量增长极快，一个中型车间跑一年，报警表几百万条很正常。没有边界条件的查询就是灾难。

我做了两个硬性限制：

• 时间跨度限制在31天内。操作员想查半年数据，分几次查，不让他一次拉全量。
• 查询结果超过5000条时，表格控件只显示前5000条，并在界面上提示“记录超过5000条，请缩小时间范围”。

实现上很简单，SQL里用TOP 5000限制行数，查询前在VBS里比较开始和结束时间，超过31天直接弹提示。

If DateDiff("d", CDate(strTimeFrom), CDate(strTimeTo)) > 31 Then MsgBox "查询范围不能超过31天，请缩短时间范围" Exit Sub End If

这样设计既保护了数据库，也保护了MSFlexGrid控件。我实测过，网格控件塞上万条数据，刷新就卡了，操作员体验很差。与其让他等半天，不如引导他做精确查询。

4.4 问题排查速查表

4.5 关于博途RT Advanced的特别提醒

前面说过，博途里的WinCC RT Advanced环境比较特殊，报警记录不一定在SQL Server库里。我帮朋友排查过一个TIA Portal V19的项目，RT Advanced的报警数据默认存储在运行系统的内部数据集里，直接连项目库查询这条路走不通。

这种情况下我不会硬套SQL直查方案，而是改用WinCC自带的报警控件，配合画面脚本在运行时动态设置筛选条件。虽然导出的灵活性差一些，但至少功能稳定可用。如果你确定要用SQL直查，前提是这个项目能把报警归档配置到外部数据库，或者用的是WinCC Professional，这个要看具体组态方式。

5. 案例复盘与可扩展的方向

做完这个案例，我自己复盘了几点体会。

第一，动态选择报警记录这个功能，真正提升的是操作员的工作效率，不只是做个查询界面。以前他们想筛一个设备、某个时间段、只看未确认的报警，得找工程师临时写SQL导出，现在自己动鼠标就行，省掉大量沟通成本。

第二，脚本里面最花时间的不是写SQL，而是处理各种异常场景，比如时间不选、条件冲突、数据量过大、Excel文件占用。这些边界情况处理好了，运行阶段才不会被现场频繁喊去改脚本。

第三，这套“SQL直查+表格控件+导出Excel”的思路，不只是报警记录能用，WinCC的变量归档、用户归档、操作记录，逻辑都是通的。我做第二个项目时把查询对象换成了操作记录表，代码复用了大半，开发周期压缩了至少一半。

最后分享一个我自己常用的小技巧：动态查询界面上加一个“重置”按钮，一键把所有下拉框和输入框恢复默认值。听起来很简单，但操作员用久了以后，界面上会残留各种筛选条件，查出来的数据怎么都不对，重置一下立马恢复正常。这个按钮在验收时往往比查询按钮还受欢迎。

如果这个项目后续还要扩展，可以考虑把报警记录定时汇总到独立报表库，对接车间的MES系统；或者用WinCC OPC UA服务器把报警数据开放给上层管理系统，让报表系统直接走OPC UA的报警接口取数。这些都是在查询功能稳定之后顺理成章的延伸方向，看项目实际需求来定就行。