报警消息系统是SCADA系统中非常重要的组成部分，用来监视自动化系统的异常和事件，借助于可视或有声提示，帮助操作人员快速发现、定位、解决处理故障和错误，从而有效减少宕机时间和生产事故的发生，并能通过消息归档，追溯报警和事件，进而分析事故起因、认定事故责任等。WinCC提供了功能强大的报警消息系统。
在实际项目组态中，也许大家对报警的应用都有自己的看法或疑问，如何设置和灵活使用WinCC 消息报警等，这些将是这次交流的重点。
此次集中探讨将持续至6月4日，其中有突出表现的网友将获得加倍精华奖励积分；最终所有有效留帖的网友将获得加倍发帖金币；根据交流情况，会酌情赠送小礼品。
交流结束后将整理精华内容，供大家分享参考。
预祝大家交流愉快，收获丰富！

楼上的方法很不错,呵呵,不过每条报警都要按下图设置:

"触发一个动作"要选上,这样才会触发GMsgFunction函数。
我采用的方法是选择"控制中央信令设备",这样设置后，当报警触发时会触发一个设置好的变量。如下图进行设置：

上图中“变量”里选择一个变量，当这种类型的报警被触发后，将触发这个变量。根据这个变量就可以在脚本中进行声音处理了。
当然这个变量如果是一个外部TAG，然后用这个外部TAG去触发一个电铃或者报警灯应该更好。呵呵，我觉得WINCC的设计者设计初衷应该就是这样，这样的话结合报警的确认功能，可以更好的实现报警。也就是说当报警出现时，外部TAG有效，电铃响，而且如果不进行报警确认，则电铃会一直响，直到所有报警被确认(所有报警被触认后,上述中央信令信号将无效)为止。
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

alarm 编辑器里编辑报警效率确实不高，一条一条的加，有点急人。
要是要加入大量报警，还是WinCC组态工具好用些，在excel 表格里拖拽自动填充、拷贝速度快多了。
用它批量建变量，很爽。
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

就一个感觉，

WinCC V6.2 开始添加的 SAH，
智能报警隐藏是真不错。

例如，2台机组，
1#正常停机，结果会有数百上千个报警 “涌”过来，
因为检测不到现场信号，就有大量的报警被触发了，但是这些其实不算报警。
这个时候，假如没有SAH，
2# 机组正常的报警，可能会被淹没，或者排在后边，
以至于你看不见，而忽略了真正应该注意的报警。
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

最近比较忙，没有时间发帖子，根据PCS7的使用经验，现简单的谈谈我的看法，按照楼主的提示如下：
1.报警可视：这个我想大家都很熟悉了，一般都会在监控画面的最上方设置个“报警条”，这个“报警条”显示最新的报警信息，当新报警出线，会以“闪烁”方式提示；具体的报警信息查询，我们一般都会制作一套单独的报警画面显示不同的报警信息，如：确认的信息，系统报警，错误报警，诊断信息等等，这些就以个人的喜好以及客户的要求而定了；
2.报警有声提示：目前用的最多的当然是HORN的方式；组态简单，又无需另加脚本。报警的有声提示往往是计算机声卡+音箱，或者外加扬声器，通过PLC输出DO触发扬声器发声；
3.快速发现：
（1）报警条
（2）ICON闪烁及颜色变化
（3）声音提示
4.定位：“报警条”旁边设置定位按钮，当最新的报警产生时，可通过这个定位按钮跳转到相应的画面，并且报警的设备位号以“高亮”显示，同时设备的ICON以颜色变化及闪烁功能提示；
5.解决处理故障和错误：这个工作就需要在ALARM LOGGING做好信息提示文本编辑。再一个就是诊断信息的读取以及报警显示，这个是解决处理问题的重要信息。
6.消息归档：报警控件+ALARM LOGGING的方式可以进行报警归档以便问题查找和责任追溯；
7.追溯报警和事件：消息归档+操作记录的归档信息=分析事故起因、认定事故责任。

写的不详细，有时间再来补充！
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

关于报警功能，SIEMENS公司不管是用WinCC、或用STEP7＋WinCC、或用PCS7系统都可实现很强大而完善功能，但是每种报警组态方法各有特点，虽功能一样，但组态效率确不一样。现我就这三种系统实施报警功能的特点分析总结如下：
1．WinCC方式——报警功能主要是通过手动对WinCC项目中逐一组态需要过程变量（Process Tag）完成的。很显然，逐一组态过程变量（Process Tag）的效率不高、时间长、重复工作量大，且还容易出错。
所以用这种方式组态报警只适用于组态报警变量较少的场合。既然手动逐一组态过程变量的效率不高，如果要组态的报警变量较多，我们一定会想到SIEMENS公司是否提供有一个组态报警模板，或报警功能块吗！且看如下。
2．STEP7＋WinCC方式——要高效组态报警功能不能仅依靠在WinCC中完成，还要利用STEP7编程软件，具体的说是利用STEP7系统功能库（SFB）中ALARM（SFB33）、ALARM_8（SFB34）、ALARM_8p（SFB35）、和NOTIFY（SFB36）这几个系统功能块的选择和组合。ALARM（SFB33）块能对单个变量组态报警；ALARM_8（SFB34）块能对8个变量组态报警，不带关联变量；ALARM_8p（SFB35）块也能对8个变量组态报警，但带关联变量（SD1～SD10）；NOTIFY（SFB36）块用于PLC热启动（Warm Restart）时读取启动信息（如OB块的加载编号等），然后初始化一些报警信息，或在PLC开机瞬间抑制一些不必要的报警信息。
ALARM（SFB33）、ALARM_8（SFB34）、ALARM_8p（SFB35）系统报警功能块功能相当强大，如果在项目编辑器SIMATIC Manager中编译（Compile）你的OS项目后，不仅可以在WinCC项目中自动生成报警归档变量（即打开Alarm Logging可看到），还可在使用的ALARM报警功能块上，对某个报警变量单独指定报警消息类型（Message Class）、报警优先级（Priority）报警确认方式（Acknowledgement）、填入自己需要的字符串作为报警事件（Event），和报警消息文本（Info Text）。这样，当在WinCC激活运行（Activate）中触发产生报警后，不仅可以清楚的知道报警变量名、报警时间、报警来源的程序块名、报警源程序块放置路径，及报警事件类型、报警提示消息文本等，可谓一应俱全。特别适用于需对多个相同的生产运行设备进行监控报警组态（如多台风机、泵，多个压力容器等），报警组态效率极高。
由于ALARM（SFB33）、ALARM_8（SFB34）、ALARM_8p（SFB35）系统报警功能块各有特点，用户需针对性的选择使用。鉴于篇幅原因，具体使用方法和步骤不再详述，可参阅相关技术文档。有兴趣的朋友我还可与其交流探讨。
3．PCS7方式——PCS7是SIEMENS公司全面集成的自动化（TIA）软件版本。报警功能组态除了遵循上面讲述的“STEP7＋WinCC”实现方式外，PCS7方式还可组态报警块图标（Block Icon）。在SIMATIC Manager中编译OS（Compile OS）后，组态的报警块图标（Block Icon）会在WinCC项目Graphics Designer中的Picture里自动生成，以用于放置在WinCC运行监控工艺画面中对应的检测点位置上直观地监控。
这大大增强了报警使用功能，用户不仅可以在报警列表（Alarm List）中清晰的查阅报警源变量信息，还在监控工艺画面中看到对应的报警块图标（Block Icon）提供的报警提示信息。PCS7项目通常使用CFC工具在AS中组态项目程序。（关于在PCS7中组态报警块图标（Block Icon）方法步骤较多，具体不再详述，使用时参阅相关技术文档）
总之，SIEMENS公司提供了丰富而强大的报警组态工具。仅靠OS侧的WinCC只能逐一对报警变量组态，要想高效、大批量的进行报警变量组态，更多的需要在AS侧的STEP7程序中多下功夫。由于过程控制与过程监视和监控密不可分，所以在设计报警时，只有将下位的过程控制部分AS程序与上位的监控组态OS程序相互融合考虑和规划，才能作设计出高效和优异的报警程序。
这种上位监控操作软件（WinCC）与下位过程控制PLC的软件（STEP7）既可独立使用，又可相互融合使用的特点，正是体现出SIEMENS公司一贯倡导的全面集成自动化（TIA）的理念，也使得SIEMENS公司自动化产品使用范围广，应用灵活。所以SIEMENS公司STEP7与WinCC相结合后，其产生的功效可不是简单的1＋1＝2。
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

个人觉得horn工具对于触发报警声音还是比较方便的，可以用它将已经配置好的报警按照类别、类型、或者优先级的方式进行分类，然后按照分类可以调用不同的报警声音文件。
如果想使用电铃也没问题，其实horn的工作方式就是将不同的变量与不同的分类相关联，当属于这个分类的报警被触发时就会使和它关联的变量置位，这样一来，不就可以用置位外部变量的方式触发电铃响了。
如果是用声音文件，也可以为这个变量分配相应的声音文件，这样就可以触发不同的报警声音啦。
不用编写脚本也可以达到想要的功能。
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

强烈推荐一下：RSE 就是report system error，在线诊断PLC模块各种故障（插拔模块，掉站，断线短路），出了问题时他能马上告诉你哪个站哪个槽的哪个通道出了什么问题，而且不用自己写任何程序，光编译即可，真方便，好像不用授权，在Step7 的硬件组态里的选项菜单里直接运行一下就能编译自动生成出一堆诊断程序，而且它用的是 alarm 函数，主动上发诊断消息到上位机。
对于系统故障这种消息，没必要让上位机不断扫描，占用总线；使用alarm 函数逢变则报非常适合这种事件型的应用。
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

谈到报警设置，就不能不提到报警归档问题！
1.对于系统不是很大的项目，可以直接将报警归档储存在本机硬盘上就可以；
2.对于大系统，我想数据归档服务器是必要的，西门子提供了CAS服务器方式，可以通过终端总线将报警记录以及过程值归档记录储存在CAS服务器中；目前，CAS服务器已经支持冗余方式；
3.对于归档组态，西门子提供两种方式选择：时间段+数据段；
4.对于时间段+数据段的选择，还是要根据工艺及客户要求去设定。一般都只选取其中一种，方法就是将另外一种不选取的方式设置成一个很大的值，这样就相当于屏蔽掉了它的方式；我个人认为数据段的方式还是较为合理的，毕竟计算机本身的储存空间是受限制的。
5.如果使用了CAS服务器的话，还要考虑如果CAS数据储存量大后的处理；CAS提供了外界储存的功能，及可以通过光盘刻录，数据移动等外设方式实现；
6.一般来讲CAS的使用，基本上可以解决大量数据储存的功能了。我想很少有企业会要求数据5年以上的储存的。
个人看法，欢迎拍砖！
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

WINCC报警功能应该还是很强大的，能把报警功能灵活应用，也不是一件很容易的事。一般工程公司做工程的时候，大部分只注重画面，画面都做的非常漂亮，而报警一般都做的不深入，呵呵，有点偏激了。而老外的程序一般画面都比较简单，一般都用线条，很少用到位图，而报警做的就比较好。
报警功能的深入使用跟工厂的管理和操作规程也有很大的关系。比如说，象报警控件里的紧急确认功能，这个功能肯定是与操作规程有很大的关系的，我到现在也无法想象出什么时候需要紧急确认功能。
另报警处理机制和程序的可靠性也有很大的关系。比如说，在PLC有一条语句，根据一个条件去开一个电机，而为了安全可靠，把与这个电机相关的报警的确认位也串到条件中，但报警没有被确认的时候，这个电机就启动不了。这就要求操作员有在出现报警的时候，必须要对报警进行确认。这样带来的好处是有两方面：1.当虚假报警出现时导致设备不能正常启动,通过操作员的确认就可以正常启动设备。2.当报警发生过，现在已经消失了，但没有被确认，这样设备也不能启动。这就要求操作员一定要去关注设备的报警信息，有时候报警信息不关注是不行的。
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。