复杂的混合协议, 将808协议指令和报警文件数据流混合在一起, 给开发者造成了不小的麻烦, 有点烧脑. 同时由于其本身业务的复杂度, 使得开发人员必须要有一定的开发经验, 结合比较好的设计模式才能构建出来性能良好的网

关. 一般需要几个版本的迭代, 必须要在实际的大规模车辆接入, 运营一段时间积累足够多的设备经验, 才能逐步的成熟稳定下来. 没有一定规模的设备接入, 就能做出高性能的网关是不可能的事情.单纯的采用SpringBoot + Netty,

只是一个基础, 后面的代码我们仍然要有扎实良好的设计功底,才能做出一个优秀的主动安全平台. 如需购买苏标或粤标主动安全平台源码,请联系2379423771@qq.com

        作为开发者我们必须要解决一下五个设计挑战:

        1) 高性能的主动安全协议通信网关通信框架设计

        2) 苏标主动安全协议和粤标主动安全协议的兼容性设计;

        3) 大数据量高并发存储设计;

        4) 及时的报警推送和处理;

 1.高性能的主动安全协议通信网关通信框架设计

        Netty框架当然是首选, 这个不用多言, 作为基础框架, 我们一般用SpringBoot2整合Netty4框架, 先为我们的平台打下一个坚实的基础.

       基于Netty4进行协议解析, 我们必须要清楚设备与服务器之间的通信协议, 及通信数据格式. 一个粤标设备一次报警, 可能与平台直接建立三个连接, 一个是指令连接, 两个是数据传输的连接.如下图所示:

2.  苏标主动安全协议和粤标主动安全协议的兼容性设计;

        兼容性设计主要是对于接入设备的报文,由程序自动识别出协议的版本. 并以此来决定后续的报文数据解析和指令下发, 如果是粤标的设备,下发的指令亦应是粤标协议格式. 实际上苏标是采用jt/t 808-2013协议, 粤标是采用jt/t 808-2019协议, 所以就是要区分是2013版本还是2019版本.     

3.大数据量高并发存储设计

        粤标主动安全报警文件上传,本质上就是多个设备同时并发连续上传多个文件,对磁盘的IO操作非常的频繁.磁盘存储的成本也非常的昂贵.在阿里云上面扩容一个100G的硬盘每月的成本需要千元.而这对于海量的主动安全报警文件来说都不够塞牙缝.

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

        而目前的主动安全设备厂商来说芯片算法很多并不掌握, 报警的准确性和误报率非常的高. 如车道偏离报警, 车距过近报警等, 这些误报的报警文件,基本上都是垃圾数据, 却会占用服务器大量的带宽资源和存储成本.

对于平台不存也不行, 万一里面真有一次车辆碰撞事故呢? 为了节省存储成本, 采用云厂商提供的云存储服务, 阿里云,腾讯云,华为云的OSS云存储费用相对较低, 但是存储容量也不能一直增长, 如果一直增长,阿里云也不是活菩萨, 也会有很多收费陷阱. 最好30天的生命周期, 过期数据自动销毁,或者归档.

        所以在设计的时候,要提供和支持本地存储,本地访问,OSS存储和OSS服务.

4.报警消息的及时推送和报警数据的及时展现.

       这里用到及时, 是因为一次主动安全的报警, 我们需要等待所有的报警附件全部上传完毕后, 进行报警消息的推送. 做不到实时的推送, 只能在前端能够及时的展现出来, 这就要求我们不能等待数据存储完毕才进行消息推送, 我们在数据接收完毕后进行消息推送. 这就用到redis框架. 接收到数据后,及时的放入redis当中. 前端展现的时候, 从redis中获取, 而不从存储服务中获取.

(5731)

1.参与单位

参与单位主要有:广东省道路运输协会、广东粤运交通股份有限公司、深圳市赤湾东方物流有 限公司、杭州海康威视数字技术股份有限公司、径卫视觉科技（上海）有限公司、深圳市锐明技术股 份有限公司、广州鹰瞰信息科技有限公司、深圳市有为信息技术发展有限公司、深圳前海车米云图 科技有限公司、深圳市华宝电子科技有限公司、深圳市首航电子有限公司、深圳腾视科技有限公司、 珠海骏驰科技有限公司、惠州市博实结科技有限公司、初速度（苏州）科技有限公司、江苏中天安驰 科技有限公司、上海通立信息科技有限公司、浙江大华汽车技术有限公司、浙江鼎奕科技发展有限 公司、交通运输通信信息工程质量检测中心、国家通信导航与北斗卫星应用产品质量监督检验中心、 重庆车辆检测研究院有限公司、中汽研汽车检验中心（广州）有限公司、工业和信息化部电子第五研 究所。

  首先从参与单位可以看出, 参与的多为深圳的硬件厂商和交通部的几家检测机构, 国内主流的运营平台几乎都没有被邀请参与, 忽略运营经验, 标准迭代的动力就不是很充足. 协议如果只是站在硬件厂商的角度, 只能是被硬件厂商利益驱动的一个东西,  只有运营平台方充分参与, 才能从行业用户的角度去思考和解决行业问题,才能真正为行业用户带来想要的东西.所以驱动的方向就是错误的, 应该是市场和行业用户驱动生产制造, 而不是生产制造自己围成一堆玩.硬件厂商怎么可能自己改变自己. 

2.采用部标808-2019标准作为基础指令集

由于部标2019标准已经颁布了, 所以没有办法, 新的协议标准只能从协议的通讯方式、数据类型、传输规则和消息组成按照 JT/T 808-2019 中 4 的要求。对于视频1078标准, 也不得不做改造, 将视频RTP协议中的Sim卡号由12位扩展到20位长度.

协议中报文分类参照 JT/T 1078-2016 中 4.3 分类方式。 协议中信令数据报文的通信连接按照 JT/T 808-2019 中 5 的要求。 协议中信令数据报文的消息处理机制按照 JT/T 808-2019 中 6 的要求。 协议中信令数据报文的加密机制按照 JT/T 808-2019 中 4.4.3.3 的要求。 协议中对平台和终端通信各方，应符合以下要求： ——除明确约定外，所有消息均应给予应答； ——对未明确指定专用应答消息的，应采用通用应答回复； ——对于存在分包的消息，应答方应对每一个分包消息进行逐包应答。 

3.与苏标的兼容性

苏标是基于部标808 2013标准, 所以粤标与苏标是不兼容的. 平台开发者要做大量的兼容性处理和判断.我对标准进行了对比分析, 并严格按照要求对现有的主动安全平台做了开发和兼容性处理.

 如需购买源码, 可以联系2379423771. 技术架构设计参见:Netty4 + SpringBoot2 + RabbitMq + Redis + AliOSS 构建高性能粤标主动安全平台

• 部标1077视频平台过检和压力测试经验分享
• 基于JT/T 1078协议设计和开发部标视频服务器
• 基于spring4+springMVC4+mybatis3+Hibernate4+junit4框架构建高性能企业级的部标1077视频监控平台
• 基于部标1078视频协议和苏标Adas协议构建主动安全平台

4.主动安全报警中苏标和粤标的区别

粤标中新增加了 实线变道和车厢过道行人检测报警;对于驾驶员的报警更多, 意味着监管更加严厉;增加了不目视前方报警, 探头遮挡报警; 超时驾驶报警; 未系安全带报警; 双脱把报警; 玩手机报警;其中玩手机报警和苏标的拨打电话报警在算法上是有重大区别的. 

5.升级协议的区别

  粤标的升级协议做了重大改变, 没有采用808-2019标准中的0×8108的升级协议, 而是另辟道路, 通过 JT/T 808-2019 中的 8.16 终端控制 0×8105 指令, 强行改造, 增加命令字来完成对终端进行升级，因此它需要对 JT/T 808-2019 表 19 终 端控制命令字进行扩展, 扩展的字段又是参考了0×8108升级指令中的一些字段, 也是比较梦幻. 升级协议的亮点是增加了终端升级进度的报告, 终端可以定时上报升级的进度, 这也是弥补这个升级指令的缺陷, 改进升级时的平台用户体验.

6.粤标主动安全检测

主动安全的设备检测和平台检测主要是通过交通运输通信信息工程质量检测中心、国家通信导航与北斗卫星应用产品质量监督检验中心两家来进行检测.

(12137)