蘇標主動安全智能防控平台是基於江蘇省地方標准《道路運輸車輛主動安全智能防控系統技術規范》（以下簡稱《規范》）經省市場監督管理局正式批准發布。該《規范》作為團體標准的升級，對主動安全智能防控系統現有的技術和功能做了進一步完善，更加貼合重點營運車輛實際和企業安全管理需求。
主動安全平台所基於的協議是蘇標協議, 而蘇標協議是基於部標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天的生命周期, 過期數據自動銷毀,或者歸檔.
如下圖所示,在代碼中根據參數配置, 設置數據的生命周期規則.
