丁宁

(博康云信科技有限公司上海分公司,上海200233)

机场飞行区安全防范系统主要取决于飞行区机坪及围界安全。飞行区围界作为空侧与陆侧隔离的主要安全屏障,建设过程存在时间长、范围广、数量多、更新快的现状,需建设一套扩展性好、兼容性强、运行稳定的安防系统,针对多厂家不同设备要能兼顾共性和差异,同时为后期建设提供前瞻性,将需增加的功能或者接入的设备预留对接接口,避免后期安防系统结构大面积重写和替换。

1 项目概况

本项目属于改造扩建项目,视频监控系统将标清摄像机升级为高清摄像机,同时按机场7003 规范扩大了录像时间到90 天。围界探测报警系统从原来总线型的报警设备更换为物联网报警设备,将报警精度提高到3-5 米一个防区单位,设备数量增加到8 千多个。辅助照明系统保留了原有围界位置的两套系统,在新建设的区域增加了一套新的辅助照明系统。围界广播保留了原有围界位置的两套围界广播系统,在新建设的围界区域新增一套广播系统。新增一套智能分析系统用于围界越界预警。因此,机场飞行区安防系统需要将一套视频监控系统、一套围界报警系统、一套智能分析系统、三套辅助照明系统和三套围界广播系统统一控制管理。

2 系统工作流程

2.1 日常工作模式,主要使用视频监控系统对围界的环境进行了解掌控,通过围界广播系统与岗亭或者巡逻人员进行语音沟通,每日定时对辅助照明系统进行开关操作,检查系统运行状况和故障信息。

2.2 报警工作模式,出现报警信息,系统自动切换,对围界报警系统和智能分析系统的接入获取围界闯入或触碰攀爬围栏报警信息,将报警信息采集后交给事件管理服务进行清洗、匹配、转换、联动控制消息生成等工作,最后将联动控制消息交给呈现端进行报警信息的电子地图位置显示、报警实时视频图像在电视墙或者大屏幕显示系统进行切换,同时控制视频系统的报警防区关联的球机实现预置位转向,向围界广播系统发送前端报警音并打通控制中心与前端围界广播的喊话通道,对前端入侵行为进行劝阻警示,部分报警区域的辅助照明系统执行开启操作,补充光源。当工作人员处理完毕后,关闭辅助照明系统、关闭语音广播、关闭报警视频联动,系统恢复到日常工作模式。

3 系统集成平台管理系统架构

以高内聚、松耦合为理念,通过采用微服务架构将业务系统组件化和服务化,整个集成平台分为三层：设备接入层、服务管理层和应用框架层,如图1 所示。

3.1 设备接入层

图1 系统集成平台管理系统架构示意图

设备接入层用于屏蔽不同厂商安防产品接口的差异性,对平台提供统一的设备接入接口及适配服务,在开发中使用了微服务的架构设计方法[1],针对每个厂商产品提供独立组件,不同组件间没有业务上的耦合调用,可以独立开发和独立部署,极大的提高了工作效率。

以报警设备为例,首先设计用于保存报警设备编码、IP 地址、访问用户名、密码等信息的数据库表结构,报警设备的接入组件读取这些信息后,调用厂家提供的SDK,输入以上设备信息后连接到所有的报警设备。建立好连接后,通过SDK提供的报警上报接口获取非法触碰、攀爬等信息,然后将信息进行筛选,同一个设备在一个时间段内重复的报警信息只向上层服务发送一次。

对于广播设备,采用同样方式设计用于保存广播设备的设备编码、广播终端通道、广播是否空闲状态、音量大小等信息的数据库表结构,由于广播设备采用的是TCP 网络通信的方式来下发控制命令和状态信息上传的,因此要根据厂家提供的TCP 通信协议来解析和创建命令包。考虑到有三种不同的围界广播设备,为每种设备开发了一个接入服务,服务之间不会有消息交互,通过各自的通信协议来管理围界广播设备。

其它几种设备也采用相类似的微服务架构进行设计。

根据现场需接入设备类型将对应的接入组件启动,若某些设备需升级更换,只要把对应的组件停止运行即可从系统架构中移除。其中各个厂商的安防子系统独立运行,自行实现内部业务流程,和集成平台的接入仅有数据交互而无功能耦合,集成平台中的组件是否运行正常也不会影响各个厂商安防子系统的正常工作。

3.2 服务管理层

服务管理层提供各类运行服务,包括统一管理服务和事件管理服务两大部分。其中统一管理服务包括身份认证管理、资源管理和系统配置管理。事件管理服务包括事件配置服务、事件转换服务和报警联动服务。

身份认证管理使用非对称加密算法对用户密钥进行管理[2],设计了身份认证服务供需要认证的终端访问,终端连接上身份认证服务后,向服务端请求服务公钥,然后用服务公钥加密终端公钥然后将加密的信息发送给服务端,服务端收到信息后,用服务私钥进行解密,同时保存这个连接提供的终端公钥,这样服务端和终端完成了服务公钥和终端公钥的交换。终端然后向服务端发送登录信息,包含用户名、密码的登录信息经过服务公钥加密后发送服务端,服务端用服务私钥解密后来进行用户名和密码的认证,通过认证后,根据不同用户分配对应权限。

资源管理考虑到围界报警设备数量有8 千多个探测器,首先采用防区分级的方式将探测器划归不同的防区,例如现场划分了150 个防区,这样每个防区就只有60 个左右的探测器,通过给每个探测器分配一个地址码作为在归属的防区内唯一标识这个设备,例如01-23 指01 号防区的第23 号地址码的探测器,当收到报警消息时,上传的信息中带有防区号和地址码,通过这两个信息可以唯一确定这个探测器,然后在数据库的联动配置中,可以检索到这个探测器关联的摄像机、广播、辅助照明等设备信息。由于这些数据都存放在数据库中,每次访问数据库都会给数据库造成一定的压力,在报警量比较频繁的时候就会引起排队检索,访问数据积压问题又会影响报警的响应,不能满足即时的性能要求。考虑到数据库主要进行资源配置信息的检索,频繁写入的要求不高,数据库中的配置数据一般不会发生变化,因此在设计时采用了高性能的Redis 来对关系型数据库进行补充。Redis 是Key-Value 数据库,可以将关系型数据库中的资源配置信息缓存在内存中,通过哈希算法进行快速的访问。例如将防区号和地址码作为参数查询对应的探测器时,服务首先通过Redis 的接口查询在内存中是否已经保存了这个探测器的信息,如果没有保存,服务会访问关系型数据库把存放在设备数据表中对应的探测器信息获取出来,同时保存一份在Redis 的内存中,可以将“01-23”这个字符串作为Key,其它的信息数据作为Value,这样当下次服务再进行查询时会发现Redis 中已经保存了这个探测器的信息,就直接获取此信息,无需再到关系型数据库中获取数据了。在实际中通过使用Redis,可以将检索的时间从2s 缩短到20ms,极大的提高了效率。

事件配置服务保存了每种事件类型所应当携带的信息,例如不同的围界报警设备有的带有设备ID,有的带有IP 地址,这些信息需要记录在事件中进行传输。笔者设计统一的事件信息结构,包括设备ID、设备IP 地址、设备地址码等,如果围界报警设备不包含设备地址码,只有IP 地址,那么设备地址码字段设置为空,通过这种统一的事件信息结构才能在接入层和服务层用一套标准的数据结构解析出正确的信息,再转给事件转换服务进行转换。

事件转换服务根据配置信息,将报警事件转换为发送给不同联动设备,其中包括：发送给呈现端的包含防区ID、区域位置、联动的摄像机以及球机预置位的信息。发送给围界广播接入服务的包含广播设备ID、播放警示音的索引、播放音量大小和播放自动关闭时间的信息。发送给辅助照明接入服务的包含照明设备ID、开关照明命令的信息。

报警联动服务将转换好的事件信息发送给呈现端因为包含了防区ID、区域位置,系统电子地图就可以查询出应当将哪个区域进行居中高亮显示,然后将联动的摄像机编号输入到视频模块进行视频切换。如果联动的是球机,就将球机的预置位发送给视频模块,视频模块给球机发送调用预置位的命令,进行球机预置位移动。发送给辅助照明接入服务的信息带有照明设备ID 和开关命令,辅助照明接入服务通过调用厂家的SDK,将设备ID 和开关命令作为参数调用相应的接口,来控制照明设备的开启关闭。发送给广播接入服务的信息通过厂家的SDK 接口打开指定设备ID 的广播号角,根据警示音的索引来播放对应的声音文件,通过音量数值调整播放声音的大小。

由于需要在多个分布式系统间同步数据,在不同进程间进行消息交换,虽然单个数据量不大,但是数据的数量多,对于反应速度和可靠性要求极高,通过传统的TCP 服务监听转发的模式无法满足项目的需求。通过研究,选择了RabbitMQ消息服务中间件,采用发布/订阅消息的模式进行数据的传输。当报警接入服务产生报警信息时,需要将数据“发布”到RabbitMQ 的消息队列中,消息队列会自动将数据推送到事先“订阅”该消息的系统,例如事件转换服务。所以,若某个接入服务需要获得接入消息,只需事先“订阅”该消息即可,如果不需要该类消息,只需“取消订阅”即可。同样,例如广播和辅助照明接入服务需要获取控制命令信息,只要通过消息服务中间件订阅这些消息即可。通过消息服务中间件,报警联动管理平台软件内部的各个接收和转发模块,就可以彻底的解耦了。同时,消息传输的实时性和可靠性,都获得极大的提高。

3.3 应用框架层

应用框架层是平台的最终用户GUI,提供各类应用及前端呈现,以友好的用户界面进行平台数据的查询和管理。它具有更强的业务性,可以统一监视、控制和管理所有可视、可控的安防设备,并快速可视化定义跨系统的信息交换或设备联动规则。

3.4 平台物理架构

平台的物理架构根据业务系统划分为安防业务、视频业务和通用业务,主要由相关的服务器设备来承载。每个服务器作为负责业务模块的独立单位进行部署。平台物理架构如图2 所示。

4 系统功能架构设计

安防系统主要对多个子系统进行集成,将孤立的系统整合为有机整体,实现信息交互,保证在报警发生时,联动子系统完成突发事件处理。因此将系统功能设计为两种模式：日常模式和报警模式。在日常模式下,主要包含视频调阅、电子地图、辅助照明、广播控制和系统配置等功能。在报警模式下,主要包含报警管理和视频、广播、灯光联动功能。

图2 系统集成平台物理架构示意图

4.1 日常模式

该模式主要为了机场工作人员日常工作时通过检查围界视频图像,判断飞行区周围环境是否正常,是否存在不明人员徘徊,对智能分析系统进行报警区域规划调整。

通过围界广播与现场巡逻以及岗亭工作人员进行指挥和沟通,上报正常或者异常情况。

在现场光照不足时,通过手动开启辅助照明系统对现场环境进行补光,并按照季节变化,进行夜间打开辅助照明,白天关闭辅助照明的自动配置。

在电子地图上查看所有设备的状态和分布,同时能快速的预览每一个摄像头的视频图像。

针对历史的报警信息进行检索、分类、过滤、打印等工作,供机场工作人员分析和预测。

日常模式的功能主要在应用框架层实现,根据视频设备厂家提供的SDK,实现实时视频调阅、历史录像查询、录像播放控制、录像下载、球机控制等功能。

在应用框架层实现辅助照明控制的应用界面,通过调用厂家的SDK,实现辅助照明的开关控制。

在应用框架层实现广播控制的应用界面,通过调用厂家的SDK,实现广播的远程喊话功能和播放警示音功能。

4.2 报警模式

该模式是围界在发生人员进入警戒区域或者触碰攀爬围界时引发的一系列联动操作,在系统的呈现端电子地图上居中显示发生报警的防区以及报警的级别、类型等。

在大屏显示系统中切换发生报警的防区关联的摄像机的视频图像,如果该防区配置了一体化球机,则调用相应的球机预置位指向防区位置,显示清晰的详情信息。

联动围界广播系统,在报警发生的防区播放警示音,同时打通指挥室或者附近岗亭的喊话通道,对前端的报警行为进行劝阻和警示。

联动辅助照明系统,打开报警防区范围的灯光,照亮周围环境,确保工作人员能够清晰了解现场情况。

工作人员处理完毕该防区报警信息后,联动关闭,系统返回到日常模式中。

报警模式的功能主要在服务层实现,由联动服务完成子系统的联动控制功能,联动服务设计为windows 服务的方式,随服务器系统启动。

通过RabbitMQ 注册报警消息,当RabbitMQ队列里收到围界报警消息和视频预警消息时,转发给联动服务,调用预先定义好的联动配置,调用视频的SDK,驱动球机移动到报警点位置。在联动配置中取出报警防区对应的广播功放ID,调用广播系统的SDK,在指定的广播号角播放报警语音。调用辅助照明系统提供的SDK,打开对应照明。

5 系统调试与优化

稳定性调试采用由局部到整体的方案：调试每个微服务模块的稳定性,再整体联调,跟踪平台的稳定性,避免微服务模块出现问题后在系统运行中不断放大。

性能调试采用由整体到局部的方案：将经过稳定性调试完毕的系统根据功能列表逐一检查运行效率,找出性能不足,检查实现该功能的整个环节的性能指标加以完善。

调试时发现,微服务架构隔离了不同模块间的差异,避免了连锁反应,增强了稳定性,但导致日志信息过于分散,无法进行筛选检索。为此,使用日志分析组件,调整代码,将微服务日志都调用日志分析组件的接口,由日志分析组件来接收所有日志信息,并通过其检索筛选工具定位问题。

Redis 数据库改善了检索性能,但设备呈现性能出现了瓶颈,过多设备一次性显示在电子地图上会出现感觉延迟。为此,采用分组显示、延迟加载,将所有设备根据区域不同分成多组,在需要显示设备时,将设备信息在内存中缓存好,当要查看某个区域设备时,只呈现这部分的数据,大幅提升显示速度。

6 结论

基于机场飞行区新旧安防系统并存从而导致管理难度提升的现状,提出解决方案：放弃直观单体架构,采用微服务架构将新旧安防系统从设计上隔离,实现模块间松耦合和高内聚。减少模块间关联程度,在保证独立性的同时为模块更新、部署、问题调试提供便利,降低开发调试工作量与维护成本。采用Redis 内存数据库,缓存大量设备配置、联动配置信息,通过哈希算法快速查询数据,避免频繁访问数据库引起性能瓶颈,加快响应速度。微服务和Redis优缺点并存,需平衡二者结合实践摸索完善,让技术更好地为项目服务。