瑞士银行亚太总行 新报警引擎保证银行设备安全

       瑞士银行亚太总行地处新加坡莱佛仕坊（图1），大楼共五十层，建成于2006年。由于公司的特殊性质，必须保证大楼所有设备高效、安全、稳定的运行，这就要求强化楼宇报警功能，并保证大楼的运行信息能够被全球信息中心随时查阅到，瑞士银行亚太总行在对银行信息中心的楼宇自动化控制系统进行选型时最终采用了Techcon系列楼宇控制系统。

图1 瑞士银行亚太总行

    楼宇自控系统首先保证银行信息中心的温湿度环境使其处于恒温恒湿状态；其次确保信息中心各种设备的稳定运行，对所有的电路都进行了智能监视；最后系统对大楼各处的报警系统进行综合管控从而提高楼宇安全警报功能。在保证系统正常运行的前提下对相关的机电设备运行情况的信息数据进行收集和分析，使系统一直处在良好的工作状态。

    在银行控制系统中，报警是非常关键的，在国内，常规的楼宇自控系统中报警并不是非常完善，问题主要集在三个方面：首先，当工程量大的时候报警信息过多，会显得非常零乱，没有层次。有很多信息处于重复报警，有的是无效报警，真正需要的报警常常会被淹没在庞大的报警信息中。公司做过很多4000点以上的项目，都存在着报警量过大的问题，经常有一夜之间出现数百条报警的情况，重要的报警（例如防冻报警、二氧化碳报警）在报警信息中检索起来非常困难，虽然可以在界面上看到，但是何时报警？要想查阅非常困难。其次，值班人员不会经常巡检中控界面上设备运行情况，也不可能随时在中央站待命，报警出现以后，值班人员不一定能在第一时间内知道，真正能够解决问题的技术人员也不一定能够在第一时间知道这些重要的报警，这样就导致对于一些报警很难及时的加以处理。怎么能够在报警出现后及时的通知到应该被通知的人员，是用户应该很慎重考虑的问题，同时也是各个集成公司的客户服务人员应当考虑的问题。最后对于报警出现的一系列反映，操作人员只能看到各种零散的事件趋势和报警，不能够整体的看到相关场景的重现。假设看到的是报警出现后的传感器检测回来的趋势图，当多条趋势图在一张界面中显示时，用户很难接收到直观的信息，但是如果客户看到的是事故发生时的组态界面，界面以秒为单位，逐步播放当时的情景，是否给客户的效果会更直接呢？

       Techcon系统核心操作软件TechVue采用的报警引擎就可以很好的解决在现存报警中所出现的一系列问题。

       如果需要有效的分析报警信息，首先就必须在所有的相关点上加载分类的标识，比如域（domain）和种（nature）。这些标识没有主从关系，只是为了很好的区分和过滤。例如在设置中可以划分几个域（空调、给排水、电梯、变配电、照明等），再划分几个种（温度、湿度、运行状态、故障、功率等等）。在配置点位时把这些信息配置上，例如送风温度属于空调域、温度种；变压器温度属于变配电域、温度种。这种方式给客户的信息比单纯给客户DDC编号和调试人员所命名的代码会更有意义。有了这个重要的前提，在实际工程中报警系统就可以被很好的管理起来，下面我们可以通过工程实例来评测加入域和种的概念后对报警系统所带来的益处。在工程报警栏中，可以设置图2中所示的表栏，这个表栏可以体现域也可以体现种的内容：

图2：分项检索表栏

在众多的报警信息中可以直接点击火灾温度部分检查温度报警，在所有报警信息中可以把火灾的报警直接红框标示出来，见图3：

图3：火灾温度标识

在大量的确认和没有确认的报警中，通过图4所示的域和种来很好的对所有的点进行分析和归类：

图4 域和种的筛选表

在工程运行过程中，应当给用户一个非常清晰的报警统计界面，通过这种界面用户可以直接了解现在所存在的各个系统中报警数量的统计。如图5所示，用户在每张界面的右上角或者一个专署位置可以直接看到这个统计表，用户立即知道现在水系统没有报警，电力系统有4个相关报警，与火灾相关的检测有2个相关报警。在了解这些报警统计信息后就可以通过报警过滤器来进行检索，准确的查到没有得到确认报警的全部信息。

图5 报警统计图

从上面一系列图中可以清晰看到有了域和种的概念之后，通过组态对所有的报警信息进行灵活的分析和筛选，可以使管理人员在任何时刻都能了解楼宇各个方面的报警情况，包括相关报警是否被解除和确认。

       通过上述的处理已经对报警进行了第一步的优化，但是还不能达到很好的效果。报警一旦出现值班人员不一定能够在第一时间内知道，就算能够通过打印记录或声光提示能够及时发现报警也不一定能够处理，其中很重要的是值班人员不知道要去找谁来处理是最合适的。Techcon系统提供E-Mail报警和短信报警引擎，有了这样的手段就可以来处理报警责任问题。在处理这种报警的时候，首先确定楼宇设备的各子系统负责人，然后按照事件发生的类别，分别对各子系统负责人发送E-Mail或者短信，这部分工作能够很好的解决报警责任问题。

       报警的目的就是要提醒客户，并且无论客户是否采取行动，都应该按照预案自动采取一系列的连锁反应，当然这种反应会导致所有相关执行机构执行特殊命令，在执行过程中会使所有相关参数发生变化。在常规报警系统中，客户所得到的只是设备是否报警，对报警以后相关设备的变化并不能了如指掌，同时报警后所有的参数虽然客户可以通过趋势图去查阅，但由于数据过多，客户所得到的数据是片断的和破碎的，在这里推荐使用虚拟数据库，即VCR（Variable Communication Record）来处理这样的重要报警。图6表现了这种记录的核心思想：

图6 VCR数据交互图

数据通过各种通讯接口进入数据库，在事件触发后，数据库会按照一定的模式对当时的计算机组态界面进行录制，可以选择实时录制，也可以选择每过一段时间进行自动对组态进行复制，当需要回看当时触发事件后组态界面中所展现的全部界面时，系统通过特殊设置，直接进入虚拟数据库。在虚拟数据库中，只有储存的数据，没有实时数据的交互，所有的组态与真实数据库完全一样，用户可以通过图7的专用媒体播放软件对历史数据进行播放。

图7 分段播放事件触发情况

这样大的历史数据到底需要多大的存储量，这是很多客户很关心的问题，在下表中用一个案例对储存容量进行比较详细的计算。

表1 字节统计表

通过上表，在附加上字符行的结束位，统计大约60个字符，每个字符为1个字节，10个事件每秒录制一次，每周的存储量大约为360Mb，计算如下式所示：

储存量=10（事件）*60（秒）*60（分钟）*24（小时）*7（天）*60（字节）=360Mb 

文件不可能每秒都创建，一般每隔一个小时就对设备的录像就自动进行备份，形成文件，那么每个文件大约需要2.2Mb左右的空间，当用户需要察看图面的时候就调用这些文件来进行观测。

       2007年初瑞士银行亚太总行进行楼宇自动化控制系统的验收的过程中，甲方和顾问对系统进行最后检测时高度注意报警功能的展现，用户在验收的时候并不非常关心组态界面，首先给操作人员几个临时指定的手机号码并请操作者输到系统中，在按照用户临时制定的方案进行报警触发，例如在10：25手动关闭某台DDC，在10：37手动触发风机故障等等，在按照时间顺序触发一系列报警后，用户只关心打印机是否已经按照报警的时间打印出所有的报警，所有指定的手机是否按照权限分别收到应该收到的报警，对于最为重要的报警是否按照既定计划做出图像录制工作。在项目中，组态界面的背景图就是工程的平面布置图，组态界面的目的单一，就是让操作者能够在最短时间内定位系统，并且获得相关设备的信息。