企业官网建设流程全解析

做工业自动化的人大概率都经历过这个场景：中控室里并排放着好几台InTouch图控电脑，一套装置一个站，或者一个车间三台机，每台都蹲在自己那块流程画面前。平时还好，一旦夜班赶上装置波动，几台机器同时报警，屏幕上红黄闪烁一片，现场就是一阵鸡飞狗跳。等生产规模上来，人不可能二十四小时盯住每一块屏幕，把分散在多台InTouch里的报警数据统一收拢，直接推送到责任人手机上，就成了刚需。SMSAlarm就是专门干这件事的报警整合与短信通知工具，这篇文章讲的就是我怎么用它把多台InTouch图控电脑的数据整合到一张网里，让每条报警都能被准确、及时地送出去。

这篇文章适合这么几类人看：刚接触InTouch的工程师、维护多套HMI的系统集成人员、想给车间做报警体系改造的自动化小组。内容不会停在概念层，后面会给出可以直接照着配置的操作步骤，也会把我在现场踩过的坑、调试时的判断思路一起写出来。先看明白数据是怎么流动的，再动手去配，比直接照抄一通配置要稳得多。

1. 整合思路：先想清楚要整合的是哪一类数据

1.1 图控电脑里的数据其实分三个层次

很多人一说“整合数据”，就恨不得把InTouch里的所有东西都拧到一块，真去做了才发现是想复杂了。实际上，InTouch图控电脑里的数据可以分成三层：

• 实时过程值：压力、流量、液位这些PV值，通过DAServer或OPC链路在InTouch画面里刷新，是生产监控的“现场直播”。这类数据变化快、时效性强，不适合让短信工具去追，也没必要。
• 报警与事件：高低报警、偏差报警、开关量变位、操作员操作记录等。这是整合的核心，也是SMSAlarm真正要处理的东西。
• 历史与趋势：InTouch支持把历史数据写到本地或SQL里，供报表和趋势分析使用。这部分跟急迫的短信通知关系不大，可以后续再接历史库，不必放在第一阶段的整合范围里。

明确了这三层，整个项目的边界就清楚了：我们要整合的，本质上是多台InTouch的报警事件流，而不是所有数据。SMSAlarm不需要去连每一台图控电脑的画面程序，它需要的是一个能持续、稳定拿到报警事件的通道。

1.2 为什么整合要靠报警数据库，而不是直接读画面

InTouch有个特点：报警信息在每台图控电脑的内存里是独立的，A站的报警，B站画面上完全看不到，除非做了额外的转发或共享配置。所以想靠“画面联动”去整合多台机，是很脆弱的做法。

InTouch本身提供了报警数据库记录器（Alarm DB Logger）这样的组件，可以把符合条件的报警事件通过ODBC实时写入关系数据库。这条链路是产品自带的，经过大量现场验证，稳定性远比自己写程序去抓内存、抓OPC点强。而且它天然适合多机汇聚：三台InTouch各自写库，但写的是同一个库、同一套表结构，从数据库视角看，报警事件就已经被整合在一起了。SMSAlarm再接上这个数据库，就等于站在一个统一的报警数据源上去做规则匹配和短信分发。

这个思路的核心词是“解耦”。InTouch只负责产生报警并落库，SMSAlarm只负责读库和发短信，两边谁出问题都不至于把对方拖死。InTouch某台机器重启、ODBC短暂断线，数据库里最多是少了几秒的写入；反过来SMSAlarm服务器宕机了，InTouch的报警照样写库，等服务恢复后再补发或者人工查漏就行。这种松耦合的架构，在工业现场比什么都重要。

1.3 三条候选技术路线的取舍

真正动手之前，我还对比过另外两条路线，这里一并写出来，方便大家判断自己现场该怎么选。

我最终选了路线C。理由很直白：短信通知本身就不是为了做到毫秒级，现场值班人员能接受的延迟是十几秒。用SQL做中间缓冲，换来的是架构极大的简化——新增一台InTouch，只需要把它的ODBC指到同一个库，SMSAlarm端几乎不用动。后面生产规模扩大，这套结构可以直接扛住，不用推倒重来。

2. 数据链路与运行环境设计

2.1 一套典型的多机报警整合场景

我用一个实际做过的项目来说明。某化工厂有三个生产装置：公用工程、反应单元、储运区。每个装置有一台InTouch图控电脑，三台机器分别放在中控室的不同工位，各自通过独立网段连到对应PLC和DAServer。车间之前的报警全靠人盯屏，夜班只有两个人，三台机同时响根本看不过来。

改造后的架构是这样的：三台InTouch机都通过ODBC把报警事件写到一台集中服务器上的SQL Server数据库；同一台服务器上也装了SMSAlarm服务，SMSAlarm定时扫描报警表，命中规则后通过短信网关设备把内容发到值班工程师手机上。三台图控电脑的报警数据，最终在数据库层面汇成了一条流。

这里有个细节要提醒：中控室的图控电脑和后台服务器之间如果要跨网段、跨VLAN，得提前把所有防火墙策略和网络路由理清楚。ODBC走的是TCP连接，端口一般是SQL Server的1433，有些现场的网络管理员对这些端口管得特别严，最好在项目启动时就拉着网络一起开会，别等联调时才发现连不上。

2.2 数据在链路里到底怎么流动的

数据链路可以分成四段，每段的作用说清楚，后面配置的时候你就知道每一步是在解决什么问题。

第一段，InTouch内部。操作员站上的InTouch运行系统检测到某个Tag值越过报警限值，产生一条报警事件。这一步不需要额外配置，报警管理系统会在内存里维护它。

第二段，从InTouch到SQL Server。报警数据库记录器（Alarm DB Logger）订阅InTouch报警系统，按照配置好的过滤条件，把符合条件的报警通过ODBC写入SQL Server的Alarm表。这是整个链路里最关键的一段，也是多机整合真正发生的地方——三台InTouch写的是同一张表。

第三段，从SQL Server到SMSAlarm。SMSAlarm按设定的轮询间隔去查Alarm表里新增的记录，读取Tag名称、报警值、状态、优先级这些字段，然后把拿到的一批报警事件交给规则引擎。注意，SMSAlarm本身不直接跟InTouch打交道，它眼里只有数据库里的记录。

第四段，从SMSAlarm到手机。规则引擎判断哪条报警该发给谁、走什么优先级，然后通过短信网关把内容发送出去。短信网关可以是现场插的工业短信猫，也可以是运营商短信接口，取决于采购的设备。

设计成四段式的好处，除了刚才说的解耦，还在于每一段的故障都可以独立排查。报警没到手机，我可以从第四段往前一段段检查：短信网关通不通、SMSAlarm日志有没有收到新记录、数据库里有没有新增报警、InTouch端写库成不成功。这个排错思路后面会展开细讲。

2.3 时间同步是“多机整合”的第一前提

这个坑我会放在很前面讲，因为它最容易在项目后期爆发。三台InTouch如果各自使用本机系统时间，时间偏差哪怕只有几十秒，在数据库里就会出现报警顺序错乱：实际先发生的报警记录时间反而靠后，SMSAlarm按时间去重和关联多站事件时就会判错。

比如储运区那边已经连续报警三次了，反应单元这边才刚收到第一条，人不在现场，光看短信会觉得逻辑完全不对。所以项目一开始就应该把三台InTouch、SQL服务器、短信网关服务器全部接入NTP时间同步，统一到一个时间基准。这个动作不复杂，但一定排在所有配置之前做完，别等联调发现问题再回头补，到那时候报警数据已经混了一段，洗数据很痛苦。

3. 实操全过程：把多台InTouch接进SMSAlarm

下面这部分是可以直接照着做的分步流程。我按“从零到有”的现场实施顺序来写，并以三台InTouch、一台SQL Server、一台SMSAlarm服务器的架构为例。

3.1 Step 1：在SQL Server上建库建账号

先在集中服务器上把报警数据库建出来。我用的是SQL Server，库名建议起得语义清楚，既然以后可能要接更多站，就叫SCADA_AlarmDB这样的名字。

库建好后，创建两个登录账号：一个给InTouch端用，负责写入（记为scada_writer）；一个给SMSAlarm端用，负责查询（记为scada_reader）。为什么要拆两个账号而不是共用一个？因为InTouch的ODBC连接串和SMSAlarm的连接串都写在配置文件里，一旦泄露或者被误改，职责边界清楚能最大程度降低风险。给scada_writer的权限就是针对Alarm表的INSERT和SELECT，给scada_reader的就是SELECT。工业系统的数据库账号权限最小化，这是多年实践下来的铁律。

表结构方面，直接用InTouch报警数据库记录器自带的模板建表就行。它默认提供的Alarm表已经包含WWTagName、WWAlarmState、WWAlarmValue、WWPriority、WWProcess、WWDate、WWTime这些关键字段，足够SMSAlarm做规则匹配。不要自作聪明去改字段名，除非你已经完全搞清楚每个字段的含义。我见过有人为了“好看”把字段改成中文名，结果标准组件和后续扩展全都不认。建好表之后，在WWDate、WWTime和WWTagName上建好索引，后面查询会舒服很多。

3.2 Step 2：每台InTouch机器上配置ODBC

这一步是整篇文章里最容易翻车的地方，我单独拎出来重点讲。

InTouch运行系统是32位进程，很多人会在服务器上打开64位的ODBC管理器，配好了一个系统数据源，测试连接也通过了，结果InTouch里怎么都找不到这个DSN。原因就是InTouch根本不会去64位数据源那里找连接。正确做法是打开32位的ODBC管理器，路径在C:\Windows\SysWOW64\odbcad32.exe。我看到过不少现场在这个点上卡了大半天，其实换个入口重配一遍就好了。

DSN类型用“系统DSN”，因为InTouch的进程可能运行在某个系统账号下，用户DSN不一定能被看到。驱动方面，早期InTouch版本对老SQL Server驱动兼容性更好，新版本则建议用较新的ODBC Driver，具体看版本对应的支持矩阵，现场以实测为准。配置完一定要先测试连接，确认能连通到集中服务器的SCADA_AlarmDB。

三台InTouch机器都要配DSN，而且DSN名称最好统一，比如都叫AlarmDSN。统一命名后面维护的时候不用每台去猜，配置文件也能整齐一些。

3.3 Step 3：配置报警数据库记录器并验证单机写入

打开InTouch里的报警数据库记录器（Alarm DB Logger Manager），新建一个数据库连接会话（DBCS）。在配置里指定前面建的DSN、登录账号，然后选择要写入的报警表。

这里有两个配置项值得展开说：

• 优先级过滤：InTouch的报警优先级通常从1到999，数字越小优先级越高。你需要在这一步决定哪些报警值得进数据库。我的建议是初期只要把真正需要短信通知的优先级区间放进来，比如优先级小于等于200的才写库。其余低级别报警如果也全部写库，表会膨胀得很快，回头筛选规则还得再费一遍功夫。
• Tag名过滤条件：如果有些Tag只是提示性的，不想让它触发短信，可以在写入的时候就过滤掉。多机整合环境下，这一步做得越细，后面的规则配置越轻松。

配好后先在单台InTouch上做验证：人为触发一个高优先级报警，比如把一个液位模拟量强制到高高报限值以上，然后去SQL Server里查Alarm表，确认能查到刚才那条记录，字段内容正确。这一步过了，说明这台机的写入链路是通的。其余两台在Tag名和ODBC配置上重复同样操作即可。我这边单机验证时发现记录没写进去，最后查下来是Alarm DB Logger里的DSN凭据填错了，服务账号没有数据库写入权限，这类问题在配置阶段就要排干净。

3.4 Step 4：规范多台机的Tag命名与来源标识

单机写入通了，不代表多机整合就大功告成。三台InTouch同时往同一张表里写，你必须在数据层面能区分出“这条报警来自哪台站”，否则规则引擎和后续追溯都会抓瞎。

想清楚这件事最迟在配DSN之前。推荐的规范是给每台装置设计统一的Tag前缀，例如公用工程是UT_开头、反应单元是RC_开头、储运区是ST_开头。这样一来，Alarm表里的WWTagName就天然带了装置信息，SMSAlarm的规则里可以通过前缀把报警路由到不同值班组。如果现场历史包袱太重，Tag不能随便改名，那就在Alarm DB Logger的配置里通过进程名（WWProcess）字段做区分，给每台机设置不同的进程名，效果类似。

我有一个实际体会：多机整合的复杂度，很大程度上取决于你愿不愿意在前期花半天时间去统一Tag命名规范。这个工作越早做，后面加人加站都省力。等系统上线后再回头去给几百个Tag改名，那个工作量会让你怀疑人生。

3.5 Step 5：配置SMSAlarm服务端

SMSAlarm端要做的事，概括起来就是“连库、扫表、定规则、发短信”。

先配置数据库连接：连接串指向SCADA_AlarmDB，账号用scada_reader，测试连通。轮询间隔一般设置在5到10秒，太短没意义，反而增加数据库压力；太长会影响报警送达体验，我习惯设到8秒左右，配合短信网关的发送速度，实际从报警产生到手机收到短信，一般在20秒以内，值班人员完全能接受。

然后是规则引擎配置，这是SMSAlarm的核心，也是最考验实施工程师对业务理解的地方。我会先画一张映射表：哪些优先级、哪些装置前缀对应哪些人员；哪些报警要在工作时间发，哪些在夜间也要发；哪些报警只需要发一轮，哪些需要升级。举个例子：反应单元的高高报报警，优先级高，要求无论白天黑夜都立即发给当班操作员，10分钟内如果没有确认，系统自动补发一条给车间值长。公用工程的一些低级别偏差，只在白班工作时间推送给工程师，夜间直接压下来，等第二天看日报。

SMSAlarm一般还提供去重和最小发送间隔设置。去重是为了防止同一条报警在短时间内被重复发送，最小发送间隔是防止某台机器故障时报警风暴把手机打爆。这两项必须一开始就设好。我见过有现场没设，结果一台设备喘振连续触发了几十条报警，几个人的手机全被短信刷屏，这种体验对项目口碑是毁灭性的。

3.6 Step 6：联调验证与交付清单

多机联调不要一上来就三台全测，要逐台来。我按下面这个清单跑一遍，基本可以放心交付：

1. 确认三台InTouch的NTP时间一致，时钟偏差在1秒以内。
2. 单台触发测试报警，确认Alarm表出现对应记录，WWTagName、WWPriority、WWProcess正确。
3. 确认SMSAlarm日志显示收到了这条记录，且短信网关成功发送。
4. 在手机上检查短信内容：Tag名、报警值、时间、装置信息是否齐全、是否乱码。
5. 重复触发同一条报警两次，确认去重生效，不会重复发送。
6. 模拟高优先级报警连续触发，确认最小发送间隔生效，不会短信风暴。
7. 断开某一台InTouch与SQL Server之间的网络，确认SMSAlarm不受影响，其他站报警照常推送。

这套清单跑完，基本可以认为多机整合链路是通的。后面就是持续运维和优化的问题了。

4. 现场踩过的坑与排查实录

4.1 多机整合的常见问题速查表

把我在几个现场遇到过的典型问题整理成一张表，方便大家对照排查。

4.2 我自己踩过的三个坑

第一个坑就是前面提到的64位ODBC。项目第一次联调，我在服务器上配置了一个64位DSN，测试连接一切正常，结果三台InTouch全部报“找不到数据源”。当时排查了大半天，最后反应过来InTouch是32位进程，把DSN放到SysWOW64对应的32位ODBC管理器里重建，问题立刻消失。这个坑发生概率极高，写出来就是希望大家少走这个弯路。

第二个坑是报警范围放太宽导致的短信风暴。最初我一口气把几乎所有报警优先级都写进了数据库，SMSAlarm规则里也全量推送。结果一次设备扰动，一晚上发出去几百条短信，值班人员手机直接被打没电，还被领导点名批评。后来我花了整整半天去梳理报警优先级，把真正需要值班人员处理的报警从海量提示里筛出来，配上了去重和最小发送间隔，才把体验拉回正常。这里我的经验是：报警系统不是信息越多越好，短信通道的价值在于关键时刻拉响警报，而不是当聊天群。

第三个坑是时间同步。某个现场一开始没做NTP，三台InTouch的时间偏差越来越大，联调阶段数据分析时发现同一时刻的三站报警顺序完全是乱的。后来重新把每台机器接入统一NTP服务器，并加了校时告警，问题才算根治。后来我把“时间同步检查”列进了所有多机项目的开工清单，雷打不动。

4.3 报警表容量与数据寿命管理

多机整合另一个容易忽视的问题是报警表的容量。算一笔账：假设三台InTouch每天合计产生5000条报警事件，每条记录平均约200字节，一天的增量也就1MB左右，看起来不大。但工业系统是七乘二十四小时跑的，一年下来就是几百MB，加上SQL Server索引和日志，表会膨胀得很快，SMSAlarm的查询速度会明显恶化。

我的做法是给Alarm表配置一个定期归档任务：比如每个月把超过三个月的记录搬到历史表或者单独的归档库里，主表只保留最近三个月的数据。SMSAlarm的日常读取只碰主表，实时性有保障；需要追溯的时候，再去归档库查。归档任务建议放在凌晨低峰期执行，避免影响白天报警写入。数据库这层稳定了，整个报警链路的地基才算干净。

5. 整合之后的扩展玩法

多台InTouch的报警数据收拢到SMSAlarm之后，能干的事情就不只是发短信了。我把几个实测下来好用的扩展方向列一下。

分级上报与自动升级：这是最实用的一项。SMSAlarm规则里可以设定两级甚至三级上报：报警触发先发给当班操作员，若N分钟内无人确认，自动升级给值长或车间主任。实现上只需要在规则里加一个“未确认则延时转发”的动作，配合短信里附带的确认回复，就能形成一个简单的闭环。这个能力对夜班和节假日特别管用，相当于用短信机制做了一道自动兜底。

报警确认状态联动：InTouch的报警可以在画面里确认（Ack），这个状态如果能回写到数据库，SMSAlarm就能知道这条报警已经有人处理了，后续升级短信就不会再发。不过不同版本的InTouch对报警确认写库的支持方式不一样，实施前需要先验证，不要想当然。

短信通道冗余：我现在的项目都会建议客户准备双通道。主通道用现场短信网关设备，备份通道用运营商短信接口服务。SMSAlarm如果能支持多通道自动切换，主通道故障时自动切到备份通道。实际使用中，故障很少发生在软件层，反而更多是SIM卡欠费、信号差、短信猫死机这类很土的原因，双通道能把这些土问题兜住。

报警数据报表和大屏：报警数据已经集中到SQL里了，接报表工具、接看板都很方便。可以把每天的报警数量按装置、按优先级做统计，还能查漏报、误报。我见过一个现场用这套数据做了一个月度报警分析会，哪个装置报警频率异常高、哪个Tag总是抖动，一查便知，整改方向非常明确。

这些扩展都是在原有链路基础上叠加的，不需要动InTouch端，这也是当初选“数据库汇聚”这条路线的红利。

最后再分享一个我在多个项目里的个人体会：多机整合这件事，技术上真正的难点从来不在“把数据接进来”，而在“把报警的语义理清楚”。哪条报警值得让一个睡梦中的人被吵醒，哪条报警只需要在第二天早上看一眼报表，这是实施工程师和工艺人员一起才能定明白的事情。我习惯在项目启动时先拉上工艺、值班长开一个小时的报警梳理会，把优先级、受众、时段一条条定下来，后面整个配置过程就非常顺。如果你现在正被一堆屏幕和此起彼伏的报警折磨着，不妨也试着先从这一张优先级表开始做，数据链路的搭建反而是最枯燥也最不会出错的环节。