主动安全平台所基于的协议是苏标协议, 而苏标协议是基于部标808协议和部标1078协议的基础之上的构建的,  在这里不对部标808协议和1078协议的平台功能做过多阐述, 需要了解的可以参见文章:

• 基于部标1078视频协议和苏标Adas协议构建主动安全平台

主动安全服务端需要解决两个核心问题:

1.及时的报警投递

由于报警和报警产生的短视频等附件数据是由设备主动推送到平台上面, 做平台在消息的及时投递方面面临着一定的挑战. 由于涉及到安全等级较高的报警,比如前车碰撞, 车距过近, 司机抽烟打哈欠打电话等报警, 需要平台能够及时投递到监控用户端, 提醒监控人员第一时间处理. 

采用ActiveMQ + SignalR 的分布式架构来投递报警消息.采用阿里云的OSS的云存储服务来解决存储成本和流量成本的问题.

其中ActiveMQ主要用于后台不同服务端之间的消息发布和订阅通知功能, SignalR则用于web平台对当前在线注册用户消息投送.

采用Signal后,页面的工作就非常清爽了, 不再需要调用后台接口轮询数据了,直接通过SignalR的回调接口, 接收到基于Json的报警数据, 直接弹窗处理了.

如下图所示, 弹窗显示主动安全报警的视频图像及文字信息内容.

2.报警附件数据存储

报警附件数据存储是一个苏标主动安全平台的一个非常大的挑战, 从成本和IO性能上都是一个挑战.

一个苏标主动安全二级报警, 少的四个文件,多的7个文件,如果同步处理,有可能同一个车,一次报警附件文件还没处理完, 又一个报警附件文件数据又接踵而至.

为了加快报警附件数据的接收, 必须要提高服务的并发能力, 采用线程池, 每次一个报警数据的上传连接, 开辟一个单独的线程, 完成文件数据的IO写入处理和消息发布的工作,随后退出线程归还线程池.

存储对磁盘容量的需求是非常大的, 一次报警如果平均是4个文件,1M大小,则如果在线有1000台车, 则每天平均报警一次, 将会上传1G的文件. 如果每个车平均上报10次, 则每日有10G的存储需求. 如果有1万台车, 就自己算去吧.

实际运营的时候, 由于设备性能原因, 往往有大量的误报, 如车道偏离报警, 车距过近报警等, 这些误报的报警文件,基本上都是垃圾数据, 却会占用服务器大量的带宽资源和存储成本. 

为了节省存储成本, 采用云存储方式, 阿里云的云存储费用相对较低, 但是存储容量也不能一直增长, 如果一直增长,阿里云也不是活菩萨, 也会有很多收费陷阱. 最好30天的生命周期, 过期数据自动销毁,或者归档. 

如下图所示,在代码中根据参数配置, 设置数据的生命周期规则.

(15566)