面向边境等严苛环境下的移动探测系统架构设计

慕容灏鼎， 李 军， 邢 军， 夏成林， 谢雨岑， 谢晋雄

(1. 深圳市检验检疫科学研究院， 广东 深圳 518010； 2. 梅沙海关， 广东 深圳 518083； 3. 深圳市物之源信息技术有限公司， 广东 深圳 518100； 4. 电子科技大学计算机科学与工程学院， 四川 成都 611731)

0 引言

移动探测因具有可探测范围广、 能够就近抵达恶劣条件现场等优点而被广泛应用到各种探测监测工作中， 如核辐射探测、 红外探测、 携带物探测、 生化危险因子探测等. 针对敏感因子的探测监测活动， 既需要保障探测监测数据的有效记录与保存[1]， 也需要在网络条件许可的情况下进行实时的数据、 音视频通讯， 将监测探测数据实时传输到后台(指挥中心、 信息中心等)， 以供后台专家即时会诊并为现场探测监测和应急处理提供快速决策与指导. 在通讯条件优越的区域， 软件系统多采用B/S(浏览器+服务器)架构， 具有现场硬件要求低、 适用性强、 易于维护等特点， 但数据依靠服务器保存， 对网络依存度较高. 而传统的C/S(客户端+服务器)架构， 则支持数据的本地保存， 但对客户端硬件要求较高， 局限于专用终端.

当探测活动进入边境、 森林、 矿区、 山川等地形复杂， 缺乏基础设施条件的严苛环境时， 网络通讯则难以保证， 此时探测活动存在着以下多种通讯困难.

1) 数据保存的有效性. 探测数据属于敏感数据， 所有探测到的数据均须得到有效的保存， 不能丢失.不允许出现因为网络状态不良而无法访问探测系统， 从而导致部分或全部探测数据无法保存的情况.

2) 网络通讯的可用性. 探测数据有于服务器中归集管理的需求， 部分特殊敏感业务还要进行数据、 语音或视频的实时通讯， 以满足后台动态监控、 实时分析和远程指挥等工作需求. 这要求系统需要阅读判断网络状态， 并在条件许可的状态下建立并保持通讯连接.

3) 可用网络的稳定性. 探测数据， 尤其是音视频探测数据的实时传输要求网络状态有一定的稳定性， 网络速率要有保障， 但移动探测活动本身因自身的移动而会在不同的网络状态中切换. 网络信号强度会随着移动而变化， 不利于数据的稳定传输.

4) 多网络信号干扰. 在边境等严苛环境下， 可能存在其他非探测业务网络的信号覆盖， 这些信号可能由其他私人机构甚或其他国家/地区相关机构运营， 往往不具有可控性. 移动探测设备可能受到这些非业务网络信号的干扰， 自动接入无效网络或在有效/无效网络之间来回切换， 导致业务通讯的断续或中断.

考虑到移动探测活动在严苛环境下的应用需要， 针对上述存在的4个难题， 本研究设计了一种基于“B/S+C/S” 架构的软硬件系统， 以兼顾上述需求.

1 设计思路

使用“B/S+C/S”架构进行软硬件系统设计搭建， 使其能同时满足数据有效保存和在网实时通讯的需求. 其中B/S部分允许应用端可以通过有效网络从浏览器直接访问系统以查询和获取数据而不需要额外的安装软件； C/S部分在移动探测平台的主控器上安装探测软件系统的客户端， 以使探测数据可以在本地保存， 并适时接入网络将数据上传至服务器或建立实时通讯[2]. 结合两部分组成“B/S+C/S”的架构[3]， 并通过以下策略， 以解决上述困难.

1) 在移动探测平台的专用控制终端上部署系统客户端， 建立本地数据库， 利用平台本地强大的处理和储存能力形成单兵数据管理体系， 实现数据本地保存与应用.

2) 将系统部署在专用网络服务器中， 同时支持安全的公用网络和专用网络访问， 在探测活动现场分别体现为4G和WiFi无线网络， 增加可用网络的覆盖范围， 以增强业务网络的可用性.

3) 为移动探测平台端设计网络状态识别、 分析的功能， 动态检测所在网络的状态， 包括网络可用性、 通讯速度、 优先级比较等， 以便综合分析选出最优的可用网络进行通讯.

4) 加入网络白名单功能， 仅将被认可的网络列入可选用范围， 避免其他非业务用网的干扰.

2 硬件架构

2.1 整体架构

图1 双网络移动探测系统硬件部署架构图Fig.1 Hardware deployment framework of the mobile detecting system in dual network

图1是搭建的“4G+WiFi”双网络通讯移动探测系统硬件架构. 如图1所示， 因应移动探测活动的需要， 后台服务器端及移动探测平台之间通过无线网路连接； 而两者各自内部的网络则基于数据传输稳定性出发， 尽可能使用有线连接.

2.2 后台及现场的硬件部署

将系统部署在专用网络服务器中， 同时支持安全的公用网络和专用网络访问， 并共用同一数据库， 以使在双网中数据都是可读写的. 为满足多个客户端口的同时访问以及庞大的探测数据储存量， 本设计中后台使用了高性能的服务器， 配备大容量储存单元， 并使用了raid1阵列备份以保障数据安全. 后台与具备施工条件的探测活动现场之间使用光纤铺设网络. 在现场分点布设多个无线AP， 以将专网覆盖到主要探测活动开展区域. 所使用的AP选用定向覆盖型， 以保证信号增益， 尽可能保障通讯速率和质量.

2.3 移动探测平台的硬件布局

移动端选用支持“4G+WiFi”双网通讯的交换机， 搭建移动探测平台上各个设备与现场无线网络之间的连接桥梁. 外引交换机的天线， 避免移动探测平台本体的外壳包裹对无线网络信号造成屏蔽影响.

各外设选用具备标准网络接口的设备， 接入交换机提供的平台自身的局域网中， 获取固定或相对固定的IP以受控， 避免使用RS232等传统接口以减少电信号干扰. 外设接入交换机而不直接接入主控器也便于多控制器对其进行同时访问.

2.4 网络视频采集卡设计

图2 网络视频采集卡内部布局方框图 Fig.2 Internal layout block of network video acquisition card

鉴于目前越来越多的专业探测趋向于探测现场画面的可视化传输， 此处专门设计网络视频采集卡收集移动探测平台上经过主控器处理后的音视频数据， 并将其编码成主流H.264或H.265码流进行传输， 提供在网实时音视频同步远程显示的服务， 可充分减轻主控器的图形处理压力， 以使其能更专注于探测业务数据的处理.

本设计所研制的网络视频采集卡使用HDMI接口采集主控器的音视频输出， 通过网络标准接口连接到平台上的交换机， 也支持与现场无线网络的直连. 在采集卡的固件中加入网络管理功能以使其能接入探测系统中， 并为系统服务器所识别. 图2为本设计所使用网络视频采集卡的内部布局方框图.

3 软件系统运作模型

3.1 软件整体架构

为使移动探测系统满足应用所需， 发挥“B/S+C/S”架构的特定功用， 设计相应的软件系统， 主要包括前端外设上的固件、 探测软件系统的客户端、 服务器端和网页端. 该软件的客户端使用C#语言进行开发， 服务器端使用PHP， 基于Laravel框架， 数据库使用的是MySQL. 整体的软件结构如图3所示. 其中， 探测软件系统的客户端安装在移动平台的本地主控器上； 探测软件系统的服务器端部署在后台指挥中心； 网页端可在任意支持浏览器应用的设备中登录访问.

图3中， 通讯链路1是保障连通的， 由移动探测平台上的网络架构实现， 是独立的局域网； 通讯链路2是移动探测平台与后台之间的网络连接， 依赖于现场的网络情况， 客户端根据网络状况分析判断工作模式， 实现数据的本地保存和传输功能； 通讯链路3由外部网络提供， 可根据具体应用需求布设.

图3 B/S+C/S软件架构示意图Fig.3 B/S+C/S software framework

3.2 监测数据的流向

图4为B/S+C/S移动监测系统应用模型. 如图4所示， 搭载软件客户端C的监测平台P在场域中移动， 在严苛环境中网络状态具有不确定性， 移动过程中可能在不同的通讯状态中切换.

监测数据在生成后保存在C本地； 通讯许可情况下， C主动将监测数据通过无线网络上传至系统服务器S中[4]； C和网页端B均可向S请求查询监测数据， S向C和B返回查询结果. 监测数据全部来源于C端， B端仅可查询监测数据.

相较于C， B的地理位置和网络位置更为固定， B与S之间的通讯连接相对更有保障， 而C与S之间的通讯连接则需通过以下的程序运作获得可靠性.

3.3 软件程序运作机理

监测数据采集与上传的总体流程如图5所示， 包括3个主要步骤： 数据采集与保存、 网络侦检和数据传输.

图4 B/S+C/S移动监测系统应用模型 Fig.4 Application model of B/S+C/S mobile monitoring system

图5 探测数据保存及传输作业流程图 Fig.5 Flow chat of the detecting data saving and transmission

3.3.1数据采集与保存

依赖于所搭载的C， 在监测环节P可以实现单兵工作： 移动监测过程中， P采集到探测数据经初步处理后， 完整保存在C中. C中的本地数据更新后， 将激发更新数据上传至S的需求， 进入网络侦检步骤.

3.3.2网络侦检

当C更新了所保存的数据而导致有向服务器数据库上传更新的需求， 或有由探测工作人员激发的实时通讯需求时， 系统提出网络连接请求[5]， 启动并保持动态的网络侦检程序(network detecting program, NDP)， 依次进行.

1) 查询可用网络. 系统查询所在区域中的各个无线网络信号， 将未达到信号强度阈值(如>-70 dbm)的网络信号忽略掉， 剩下信号强度较好的可用网络列表(available list, AL).

随后， 系统以网络名为校验字段， 逐一查询列表中各个网络是否在监测作业的通讯网络白名单中， 保留在该白名单列表中的网络为可选网络， 组成可选网络列表(optional list, OL).

此处的通讯网络白名单仅包含监测实施单位认可的业务网络， 可以是专用网络或公用网络. 系统通过白名单排除非业务网络对监测工作开展的干扰.

2) 可选网络测速. 第二步对OL中的各个网络逐一进行测速， 先比较测速结果与用户设定的网速阈值(一个根据数据类型而设定的保障通讯效果的速度值， 如4 Mbit·s-1的上行速率)， 舍弃不达标的网络， 剩下符合要求的网络按速率依次排序.

如经过测速后， 没有任何网络符合网速要求， NDP终止系统建立网络连接的请求.

3) 可选网络的优先级选择. 经过上述两步的筛选， 剩余可用于建立连接的网络一般数量极少， 甚至是仅有一个. 在存在不止一个可选网络的情况下， 系统按照用户设定的优先级原则依次选用. 优先级判断所考虑的因素主要包括： 网络安全性、 软件在网络中的使用普遍性、 通讯速度等， 根据用户需求可以对单项因素考虑或按照各因素进行加权综合考虑.

选出唯一最适网络后， 通过TCP/IP协议， P与系统服务器S所在的该网络建立并保持网络连接， C随即向S申请上传数据.

4) 通讯状态的循环检测. P在场域中移动， 不可避免地导致所在的网络环境发生变化， 已建立通讯连接的网络状态可能会变得不适用于继续通讯. C根据系统中设定的周期或通讯故障原因(数据传输校验不通过或人工重建连接请求)触发， 对通讯状态进行检测. 当所连接网络的状态不符合通讯要求(如信号强度或网速不达标)时， 断开相应的网络连接， NDP进行下一轮的网络侦检.

整个网络侦检动作判定了探测系统的网络可用性， 在网络不可用时终止网络通迅请求， 避免本地运算资源的空载浪费； 在网络可用时仅选最优的通路进行通讯， 避免重复通讯的资源浪费.

3.3.3数据传输

在网络通讯有效建立之后， 系统对需要更新或需要实时传输的数据加密然后进行传输. 鉴于探测活动数据对探测工作及其后续处置等工作的开展具有极其重要的指导意义， 必须保证其完整性， 因此增加通讯数据的校验程序， 确保数据获得完整传输[6].

通过TCP/IP协议的保障， 数据传输进行循环冗余校验(cyclic redundancy check, CRC). C在所有数据包通过传输校验后将本地数据更新为已上传状态， 终止数据上传程序. 如传输校验未通过则C要求重传， 同一数据包重传申请次数达到相应次数阈值后， 确认为通讯故障并触发前述的通讯状态检测.

C与S之间建立“心跳检测”机制， 通过定期的应答确认通讯状态， 在心跳应答中断时S断开对应C的连接， 避免S的资源占用.

4 实现效果

基于上述“B/S+C/S”系统架构的设计， 研制出在深圳口岸区域开展移动核辐射监测的车载平台及系统， 并于2018年6—12月间试用. 该业务作业时需要对探测到的可见光图像和辐射方位数据进行图像融合， 所有数据保存在车辆本地， 并于口岸现场监控中心实时查看车辆的探测画面及数据， 同时由监控中心向车辆反馈相应的指挥指令等. 在深圳口岸主要区域部署了专用网络， 也有4 G公用网络覆盖， 但部分区域仅有专网或4 G公网其一覆盖， 另有部分区域跟香港的电讯网络存在着交叉， 容易受其信号干扰.

B/S+C/S移动监测系统测试如图6所示， 测试过程中， 监测平台从指挥中心附近逐渐远离， 分别经过3个网络信号状态不同的区域X、Y、Z， 然后再逐渐返回指挥中心附近， 全程进行移动监测.

区域X中， 专用网络BN的网速比公用网络PN高， 系统连接BN进行监测数据实时上传. 随着远离指挥中心， 通讯速率开始下降. 在接近X、Y两区之间的位置， BN的信号强度已下降至-75 dbm， 系统切换连接至PN， 通讯速率维持在阈值1 Mbit·s-1之上. 继续远离， PN信号强度逐渐下降， 通讯速率也逐渐降低， 进入区域Z后， PN信下降至-75 dbm以下， 外部网络EN并不在通讯网络白名单中， 系统断开了网络连接， C提示数据更新已保存至本地但未上传.

返回过程中， 进入区域Y后， 系统接入PN， 通讯恢复， 原已保存在C中的更新数据开始上传至S. 进入X区域初段， 通讯速度一直保持在1.4 Mbit·s-1良好状态， 系统并未立即切换至BN连接， 而是当C进入周期性NDP时， 方才切换至速率达到2.2 Mbit·s-1的BN连接.

测试过程的网速变化走势如图7所示. 其中， 第一个波谷为从BN切换至PN时系统尝试重连BN耗费的短时无通讯阶段， 第二个波谷为在区域Z期间的无可用网络状态.

图6 B/S+C/S移动监测系统测试场景Fig.6 Test scenario of B/S+C/S mobile monitoring system

图7 系统测试过程中通讯效果走势Fig.7 Communication effect trend in testing process

经过验证， 基于本设计研制的系统能自动识别深圳口岸现场的各个可用无线网络， 通过白名单排除非业务网络后， 自动选用效率最高的网络进行通讯， 全程平均通讯速率达到1.2 Mbit·s-1， 始终保持在满足用户需求的网速之上.

图8 车载客户端保存数据列表截图Fig.8 List of the data saved in the onboard client

作业时， 系统会即时保存有效探测数据在本地工控机中， 图8为该车载平台本地客户端保存的数据列表截图. 该车载平台在联网状态下自动向服务器端上传更新数据. 图9为从浏览器中查询到软件服务器端上保存的来自车载平台上传的探测数据列表.

在该车载平台常规的探测活动区域范围内， 该车能与相距超过3 km的后台指挥中心进行实时通讯. 图10为后台服务器端实时查看该车载平台探测活动的效果.

根据该车载平台半年来的使用情况反馈， 无论是脱网状态下的单机作业还是在网状态下的联网作业， 均能满足探测活动开展的应用需求.

图9 服务器保存的上传数据列表Fig.9 List of the uploaded data saved in the server

图10 指挥中心实时查看车辆探测画面Fig.10 Real-time detecting sight at the command centre

5 结语

探测系统“B/S+C/S”架构的设计方案， 满足了移动探测活动中既要求对探测数据进行本地保存、 也要求适时与系统后台进行数据通讯的需求， 适用于边境、 森林、 矿区、 山川等难以保证通讯条件的严苛环境中的移动探测活动.