• [技术干货] SOA,落地路上二三事【转载】
    以下文章来源于十一号组织 ,作者黄百万业界普遍认为,没有SOA的下一代电子电气架构是没有灵魂的。在这样的价值观驱动下,汽车行业开始了轰轰烈烈的SOA运动。而伴随着车载以太网的量产,SOME/IP、DDS等通讯协议的成熟,Adaptive AUTOSAR、ROS等操作系统中间件的不断优化,SOA在汽车行业落地的土壤也已具备,SOA也由雷声大的口号阶段进入到雨点小的落地阶段。SOA虽已是互联网行业中的一位成名英雄,但在汽车行业却是一个比较新的概念,目前并没有一个放诸四海而皆准的指导思想。从各家公布的资料来看,SOA被做成马的也有,被做成骡子的也有,真可谓是千娇百媚。但是正如教员所说:实践是检验真理的唯一标准,基于不同的方法、思想实践出来的结果,如涓涓细流,终将汇成大一统的SOA指导思想。前文《SOA,得服务者得天下?》已对SOA基础知识有过介绍,本文在此基础上,继续闲聊一下SOA在落地路上的二三事。SOA设计原则SOA在其成名领域——互联网,用的是客户端——服务器的架构。客户端通过网络向服务器发送请求,服务器响应请求,这是客户端——服务器架构背后的主要逻辑,毫无疑问这也是互联网有史以来发布最成功的网络技术之一。客户端——服务器架构之上的进一步抽象是面向服务的范式,这是将服务器中的信息组织成服务的模式,这个服务可以被发现、进行交互或用作已知的语义。这也就意味着该服务具有确定的行为,在给定相同的条件时,总会产生同样的结果。这就好比你去麦当劳点餐,麦当劳提供了从“穷鬼”到“地主”级别的不同套餐,这些套餐就是这家麦当劳门店所能提供的服务,然后你为选择的服务支付费用。麦当劳生产这个订单后,员工会按照麦当劳定义好的流程,一个负责炸薯条,另一个负责制作汉堡,有条不紊地做着自己该做的事情。无论是谁、无论何时点的套餐,顾客最终都会得到他想要的食物。麦当劳的这些服务都是具有预先确定的行为和已知的术语,并且会产生可预知的结果。上述例子可以让我们对SOA的实现窥探一二,也可以让我们试着总结SOA在设计时应尽可能遵循的原则。一、抽象化抽象化是SOA非常重要的一个设计原则,是指使用抽象层来隐藏网络拓扑、通信和实现的复杂性。如果不利用抽象化,而让客户端知道实现该服务的所有细节,那客户端使用该服务的方式将会严重制约服务的演化。对于顾客而言,他们并不需要知道麦当劳内部是什么样的流程机制,里面的员工是如何进行合作分工。他们仅仅需要关心麦当劳能提供什么服务,以及对应的服务结果是什么。换言之,我们定义服务的接口时(相当于菜单),也仅仅需要把服务接口实现方式(顾客消费方式)和接口调用的结果(食物照片)定义清楚。为了确保遵循该原则,服务的公开状态应该尽可能地少。此外,只应规定服务行为的外在表现。二、正式合约一个服务之所以被称为服务,是因为其给公开的功能以及如何实现提供了正规的描述,即正式合约。这其实就是我们做SOA设计时定义的服务接口,每一个接口都应该有明确的定义以及实现方式。三、低耦合在面向对象的软件中,单独的系统组件指的是被设计成无边界效应的独立对象。那些发生在组件之间的相互作用可以被明确地定义和测试。将依赖关系减小到最小程度,也就是低耦合,使修改服务的实现方式时不会带来意想不到的边界效应,从而降低风险。而对于SOA低耦合的设计原则,主要包括两个方面:(1)一是服务的实现方式和正式合约应该分离开来。服务的正式合约只要不变或者修改,那不管实现方式如何变化,这都不影响。就像去麦当劳点了一个套餐,只要套餐内容不变,不管麦当劳内部人员怎么分工,是一个人炸薯条再做汉堡,还是分不同的人分别去炸薯条和做汉堡,对于服务使用方来说结果都是一样的,他并不关心服务是怎么实现。(2)二是服务的实现过程不要依赖另一个服务的结果。就比如麦当劳A客户点了套餐A,B客户点了套餐B,就算套餐B不能完成,那也不会影响套餐A的制作。四、可复用性可复用性其实是SOA设计所期望的设计目标。真正的可复用性是让服务适用于多种不同应用的能力。进行一项服务的设计时,如果没有进行认真地思考,它可能仅能满足某种特定的应用。而经过思考的良好设计,服务可以与具体的实现过程相独立,这就意味着该服务可以在其它的应用中快速地复制。五、独立性每一个服务与客户端的状态应该是相互独立的,它应该有它内部既有的工作流程,而不依赖于客户端的状态。这样做的目的是剥离客户端与服务端的状态交互,这样做的目的是无论客户端来自哪里,在任何时间、任何地点请求同样的服务,服务端都以同样的方式响应,从而得到相同的结果。就像当顾客点了一个汉堡时,麦当劳门店只要按照既有流程去制作就行,期间不用关心该用户是谁、来自哪里。六、可组合性我们在进行服务的设计时,为了低耦合,我们往往把服务设计得小而精。然而在进行汽车的服务架构开发时,整车的系统往往是复杂的。经常会有不同的用户使用场景,针对不同的使用场景,利用现有的服务,鼓励可以聚合大的服务,以实现更高级别的应用。比如说汉堡、炸鸡、薯条、可乐这些都是属于小的服务,门店可以自由搭配组合形成新的不同套餐,在价格中形成一定的优惠,以供客户选择。应用到车上,氛围灯、座椅、空调、音乐等属于小的服务,车企可以根据不同的组合,形成不同的用户场景,比如休憩模式关闭所有灯光、音乐,座椅和空调调整到舒适位置。七、可发现性可发现性指的是用户可以通过某种特定的方式查询到该服务,而不是通过静态编程的方式。例如在高德地图中输入麦当劳,你就可以得到附近的门店的位置,而不用在手机中把每个门店的地址记下来。SOA设计举例上文简单介绍了SOA设计时的七个指导原则,但在真正进行某个子系统的SOA设计时,其实会面临更多的问题。每一个系统工程师对方案的理解不一样,都将导致设计出来的架构不一致。当然这个没有对错之分,毕竟通往珠峰的道路也不是只有一条。下面以控制空调的开和关为例,比较SOA两种设计方案。一、方案一服务端(空调模块)提供开和关的接口,客户端(娱乐主机)调用这个服务接口来请求空调的开和关,服务端根据自身的控制逻辑执行空调的开和关。服务接口描述:HVAC ON/OFF_Req:客户端可通过调用这个接口来打开或者关闭空调。HVAC ON/OFF_Resp:服务端根据自身的逻辑,收到请求后反馈给客户端执行结果,如果正常执行就反馈“执行成功”。如果不执行,就反馈“执行失败”且会携带失败的原因,比如“执行失败,整车未上高压或者发动机未启动”。二、方案二服务端(娱乐主机)发布空调开和关的请求事件,客户端(空调模块)订阅这个事件接口,当该接口为空调开或者关请求时,用户根据自身的控制逻辑执行空调的开和关。三、方案比较从结果上分析,两种方案对用户的体验实际上是一样的,都能实现对空调的开和关,但是细究下来还是有不少差异的。方案一的优势是服务端提供统一的接口,客户端可以根据自身的需求调用。服务端可以不关注客户端是谁,只要根据自身的内部逻辑进行空调的状态跳转。方案二其实细看就像上一代面向信号的架构,只是把之前的信号重新包装成服务的形式在以太网上传输,相当于脱裤子放屁。基本可以用现有的软件架构,把接口名字改改就可以上车,开发的代价最小,但是没有任何扩展性可言。如果有其他的APP想控制空调,那就需要重新发布一个接口,客户端(空调模块)需要重新订阅该新的接口,从而实现另一种控制方式。从短期来看,方案二是实现所谓的SOA代价最小的方案。但是作为要面向下一个十年甚至二十年的架构设计来说,方案一才是主流的方案。虽说在开发过程中还会遇到其他问题,但是总体的架构思路和方向是对的。SOA功能分配上面介绍的是SOA某个服务的架构设计方案,在进行系统的详细设计时,比如说具体到SOA的功能分配,就又面临另一个问题。还是上文空调控制举例,比如在进行空调的控制时,需要判断车辆状态,当整车处于高压或者发动机启动时才能开启空调。方案一中如果把对车辆状态的判断放在客户端,那么意味着每一个客户在控制空调时,都要先获取车辆的状态,只有满足车辆处于高压或者发动机启动时,才能调用空调的控制接口。服务端收到空调的控制器指令,执行相应的动作。这么做的好处是服务端提供的接口内部逻辑可以做的很简单,不会随着前置条件的变化而变化,把控制的前置条件判断上移到客户端。坏处是对每个客户端提出了更严苛的调用条件,如果该服务仅仅针对内部软件的团队进行开发,那相对来说是可控的,可以通过设计文档审核以及测试进行把控,不会出现客户端在前置条件不满足时就调用服务端的空调控制接口的情况。然而如果这个接口开源的,那显然这样的设计方案不合理,因为对于开源的接口,不可能要求每个开发者严格按照规则去做,一旦有某位开发者开发的APP没有判断前置条件就直接调用空调的控制接口,那有极大的概率出现小电池被耗尽电的问题,除非有智能补电功能。方案一中如果把对车辆的状态判断放在服务端,对于客户端来说,就可以很简单,只要想控制空调,那就调用服务端的接口,至于能不能开启,服务端会根据车辆的状态反馈给客户端。这仅仅是针对单一车型,对于不同的车型以及应用场景,可能开启空调的前提条件不同,所以在进行服务的接口定义时,先定义和开放适用于大部分应用场景的接口,至于特殊的需求,经过评估后再确认是否需要定义新的接口。这里要阐述一个观点,服务并不是一成不变,且不要想着一个服务接口就可以覆盖用户所有的使用场景。写在最后SOA在互联网行业的成熟经验可参考,但也仅供参考,如果是拿来主义,那注定是不会成功。要想把这个概念用到汽车行业,且用得好,无论是使得软件复杂度减少,亦或者为将来的功能拓展带来便利性,这些都需要进行深刻的理论分析以及实践应用。SOA的系统设计也是这几年刚刚兴起,每一家的架构以及系统方案都不一样,但从笔者的拙见来看,SOA目前的收益其实并没有宣传的那么大,投入产出比严重不平衡。SOA的开发不能一蹴而就,在各家不断的开发实践中,不断地优化现有的架构以及系统设计方案,直至诞生汽车行业大一统的指导思想及设计原则。作者 | 黄百万初心 | 记录生而为人的证据,分享工农阶层原创作品,聚焦智能网联与人情冷暖。声明 | 本文部分文字及图片资料取自网络,如有侵权,请联系平台进行修改或删除;文章属于作者本人,仅代表个人观点,不代表平台立场,如有不妥,也请联系平台修改或删除;本文不作任何商业用途。转载于汽车电子与软件微信公众号
  • [技术干货] 基于功能安全的车载计算平台开发:软件层面【转载】
    以下文章来源于智车Robot ,作者Bruce Jiang车载智能计算平台作为智能汽车的安全关键系统,软件层面的安全性至关重要。由于车载智能计算平台功能丰富,应用场景复杂,对软件的实时性、安全性、可靠性要求极高,应通过技术和流程两个方面保障软件的功能安全。技术上确保软件层级的每个功能安全相关软件节点都有相应的故障监测和处理机制,流程上按照软件安全生命周期模型规范软件开发过程。基于参考阶段模型,为软件层面产品开发进行生命周期的剪裁。01 软件安全要求车载智能计算平台软件安全要求是对软件安全相关的功能和性能的具体要求,主要是通过技术安全要求在软件层面的分配得到,并通过继承或分配得到相应的ASIL等级。另外,在软件架构阶段执行的软件安全分析也可能会识别出额外的软件安全要求。采用专业的需求管理工具来实现需求的编写、评审、管理以及双向追溯性检查可大幅降低软件层面的系统性安全风险。02 软件架构设计软件架构设计是对软件需求的设计与实现,用来描述软件的框架要素和软件各分层结构之间的相互作用,其范围层面应到能够识别所有软件单元的程度。软件架构设计不仅需满足相应ASIL等级的软件安全要求,还应满足软件其他非安全要求。在软件架构层面,软件安全要求会分层次地分配给软件组件直到软件单元,每个软件组件应按照分配给它的安全要求中最高的ASIL等级来开发。车载智能计算平台应在软件架构设计阶段进行软件安全分析和相关失效分析,完善错误探测和错误处理的安全机制,以便识别或确认软件安全相关部分,证明软件的安全相关的功能和性能满足相应的ASIL要求,支持安全措施的定义及其有效性。车载智能计算平台软件架构设计完成后,应对其开展验证活动,输出软件验证报告,证明软件架构设计严格遵守设计规则,兼容目标环境,满足相应ASIL等级的需求,并且相关评审证据充足。软件安全设计依然可以从E-Gas三层架构中提取关键设计理念。E-Gas针对的典型系统,基本的思想是外围系统—内部系统,内部系统分为传感器、控制器和执行器。在这个系统概念里,传感器是加速踏板传感器,控制器是ECU(Engine Control Unit),执行器是节气门。展开安全架构设计的时候,需要时刻关注将系统解耦和模块化,这对于软件的安全设计是非常重要的。E-Gas典型系统组成及边界关于E-Gas安全架构的核心理念和设计,这里再回顾一下,整体设计分为Level1、Level2和Level3,其定义如下:(1)Level1:功能层,包括扭矩的解析、功能的诊断等,最直接的理解就是能够实现设计基本功能的软件及相关硬件资源的组合。(2)Level2:功能监控层,负责监控功能层的输出结论,简单理解来看,就是软件的冗余校验,但是,由于不想消耗太多资源及避免算法共因,所以基于功能结果的监控。(3)Level3:硬件监控层,负责确保Level1和Level2的运行的硬件环境是正常工作的,异常的运行环境会导致Level2的设计起不到很好效果,因此,Level3在整体的监控架构中作用是不可替代的。下图是Level2算法架构的一个示例(汽油歧管喷射),其整体思想是计算实际系统输出的扭矩和此刻系统允许输出的安全现值之间的差值,当差值大于一定数值及一定时间时,采用相应的故障动作。同时,方案为了避免出现误报或者漏报的情况,每一项用于计算的信号或者相应的传感器都应该具有相应的诊断及故障动作,这也是软件开展功能安全设计很关键的理念,输入信号是需要高完整性和准确性的。针对Level3的硬件监控层,需要涉及软件和硬件的交互,监控的机制可以通过软件实现,也可以通过硬件实现。这里罗列了E-Gas中涉及软件方面的问题:(1)ROM检查:针对ROM的检查,主要是涉及数据翻转、错误的刷写、错误的数据等,软件在其中扮演着检测对比算法的角色,当然,ROM的检查通过硬件也可以实现。(2)应答机制检查:软件需要在设定时间窗口内正确回答独立硬件监控单元的问题,如果超时或者回答错误一定次数,都会触发重置或者下电。(3)指令集检查:指令集是处理器核心的计算最基本单元,也是Level2监控算法正确执行的基础,确保指令集的正确可以采用软件辅助计算应答方法,或者采用目前诊断覆盖率更高的锁步核机制冗余校验(Lockstep-Core)。(4)程序流检查:监控算法、诊断算法等都是周期性按顺序执行的,因此,执行时序也需要进行检查。通过E-Gas的三层经典架构,我们可以分析出软件层级的功能安全设计需要考虑的软件包括Level1的功能层软件、Level2的监控层软件以及Level3的部分支持硬件监控层软件。对于Level1功能软件,它本身的失效在整体架构中并不会违反安全目标,理应可以按照QM来开发,但考虑到软件本身的可靠性,建议依照ASIL-A或者ASPICE CL2级进行开发,毕竟,一个产品只确保安全但可靠性很差是没有办法交付给客户的;对于Level2和Level3的软件,按照安全分析,需要依靠系统的最高ASIL等级开发。当然,并不是说非三层架构设计软件无法实现功能安全开发或者产品无法符合功能安全要求。E-Gas三层架构能够很清晰地实现层级递进式的监控设计,尤其适用于功能软件复杂的产品。如果功能软件相对复杂,高ASIL等级的产品在导致软件开发的工作量大量增加的同时安全性也很难兼顾。对于功能安全软件设计而言,软件架构设计一个重要的目标是使软件需求的实现过程以一种完整的、正确的同时尽可能简单、可理解和可验证的方式展现,从而在软件需求实现过程中,尽可能降低由于设计错误造成违反功能安全需求的可能性。功能安全要求软件架构的设计具备以下属性:可理解性,一致性,简单性,可验证,模块化,层次化,按层逐步细化、封装,低耦合性,可维护性。对于可理解性,ISO 26262中按照不同的ASIL等级规定了不同的软件架构设计的表示方式。常见的几种软件架构安全分析方法包括SW-FMEA、SW-FTA及SW-DFA。1、SW-FMEASW-FMEA以硬件组件和软件模块之间的接口或软件模块和软件模块之间的接口为分析对象,列举硬件组件接口或软件模块的失效模式,分析失效模式对后续软件模块或者软件需求的影响,尤其是与功能安全相关的影响。在明确失效模式和失效后果的基础上,去寻找造成硬件组件接口或软件模块的原因,并且对原因施加控制措施。2.SW-FTASW-FTA探究的重点是软件架构中多点错的发生对软件功能安全需求的影响。SW-FTA分析过程从软件功能安全需求出发,从软件架构设计中所有软件模块和软件接口的失效模式中去寻找和当前软件功能安全需求相关的失效模式,并且识别出这些失效模式和当前软件功能安全需求的相关性(单点失效还是多点失效)。3.SW-DFASW-DFA在标准中定义的从属故障(Dependent failure)包括级联故障(Cascading failure)和共因故障(Common cause failure)。通常可以从以下几个方面来考虑Dependent failure 中Cascading failure的部分:时间和调度问题造成Cascading failure。比如,由于其他模块运行时间过长导致目标模块无法运行,死锁、活锁、饥饿等现象导致模块运行停滞或者延迟,软件模块之间的同步性问题或者优先级问题导致调度次序出现问题。存储空间问题造成Cascading failure。比如,目标存储区域被其他软件模块误篡改,软件模块之间对于同一存储空间的读写操作配合问题导致数据不一致(读数据的同时允许写数据),栈溢出等问题。软件模块之间的通信( 尤其是ECU 间的通信) 问题造成Cascading failure。时间和调度问题造成Cascading failure。随着ASIL等级的提升,ISO 26262从语法和语义两个维度出发,从最低要求的自然语言描述到半正式的表述方式,逐步加强对表述方式的理解一致性的要求。为了避免系统性失效,ISO 26262对软件架构设计提出了一些设计原则。03 软件单元设计与实现在软件单元设计与实现阶段,基于软件架构设计对车载智能计算平台的软件单元进行详细设计。软件单元设计应满足其所分配的ASIL等级要求,与软件架构设计和软硬件接口设计相关内容保持一致。为了避免系统性失效,应确保软件单元设计的一致性、可理解性、可维护性和可验证性,采用自然语言与半形式化方法相结合的方式进行描述。说明书应描述实施细节层面的功能行为和内部设计,包括数据存储和寄存器的使用限制。在源代码层面的设计与实施应使得软件单元设计简单易懂,软件修改适宜,具有可验证性和鲁棒性,确保软件单元中子程序或函数执行的正确次序,软件单元之间接口的一致性,软件单元内部及软件单元之间数据流和控制流的正确性。车载智能计算平台软件包含数百个软件单元,软件单元的标准化、单元间解耦是高效实现软件功能安全的基础。车载智能计算平台中不同安全等级的软件可以采用硬件虚拟化、容器、内存隔离等技术进行隔离,防止软件单元之间的级联失效。软件代码设计过程中应遵守成熟的代码设计规范,例如MISRA C。MISRA C是由汽车产业软件可靠性协会(MISRA)提出的C语言开发标准。其目的是在增进嵌入式系统的安全性及可移植性,针对C++语言也有对应的标准MISRA C++。MISRA C一开始主要是针对汽车产业,不过其他产业也逐渐开始使用MISRA C:包括航天、电信、国防、医疗设备、铁路等领域中都已有厂商使用MISRA C。MISRA C的第一版《Guidelines for the use of the C language in vehicle based software》是在1998年发行,一般称为MISRA-C:1998.。MISRA-C:1998有127项规则,规则从1号编号到127号,其中有93项是强制要求,其余的34项是推荐使用的规则。在2004年时发行了第二版的MISRA C的第一版《Guidelines for the use of the C language in critical systems》(或称作MISRA-C:2004),其中有许多重要建议事项的变更,其规则也重新编号。MISRA-C:2004有141项规则,其中121项是强制要求,其余的20项是推荐使用的规则。规则分为21类,从“开发环境”到“运行期错误”。2012年发布第三版,为当前最新有效的C语言规范版本,称为MISRA C:2012。企业可以基于MISRAC建立一套满足车载智能计算平台安全编码要求的内部编码规范,并严格执行。04 软件单元验证软件单元验证是通过评审、分析和测试的方法对功能安全相关的软件单元设计与实现进行验证,证明软件相关安全措施已经在设计与实现中全部落实。软件单元设计满足相应的ASIL等级的软件需求和软硬件接口规范要求,软件源代码的实现与单元设计一致,不存在非期望的功能和性能,且支持功能和性能实现的相关资源充足。车载智能计算平台的软件单元验证可参考下表,通过需求分析、等价类的生成与分析、边界值分析和错误推测相结合的方法合理设计测试用例,确保对软件单元进行充分验证。为了评估软件单元验证的完整性,为单元测试的充分性提供证据,应确定在软件单元层面的需求覆盖率,同时对结构覆盖率进行测定。车载智能计算平台软件单元测试的结构覆盖率目标为100%,如果已实现结构覆盖率不能达到目标,可以定义额外的测试用例并提供接受理由。车载智能计算平台软件单元的结构覆盖率测试应采用满足相关安全要求的测试工具,确保在测试过程中测试工具和检测代码不会对测试结果产生影响。车载智能计算平台软件单元测试应根据测试范围,选用适当的测试环境。测试环境应适合完成测试目标,尽可能接近目标环境,如果不是在目标环境执行,应分析源代码与目标代码的差异、测试环境和目标环境之间的差异,以便在后续测试阶段的目标环境中,定义额外的测试。05 软件集成验证软件集成验证需要根据软件验证计划、接口规范、软件架构设计规范、软件验证规范等对软件架构中所描述的集成层次、接口、功能等进行持续测试,以验证其与设计的符合性。由于车载智能计算平台软件的复杂性,实时性、可靠性、安全性既是设计目标也是基础性能,集成测试设计阶段应对其功能、逻辑、性能、边界、接口进行详细分析。车载智能计算平台的软件集成验证参考下表,不仅需涵盖所有应用软件、功能软件、系统软件以及与硬件之间的接口,并且应涵盖软件单元之间的接口。测试用例在测试工作中至关重要,其输出需要考虑功能需求、性能需求、边界值、接口、逻辑关系等。06 嵌入式软件测试车载智能计算平台嵌入式软件测试主要是基于软件安全要求的测试可参考下表,针对软件安全要求进行充分的故障注入测试,最终确保软件安全要求的正确实现。为了验证车载智能计算平台软件在目标环境下是否满足软件安全要求,应进行硬件在环测试、车辆电控系统和网络通信环境下的测试以及实车测试。硬件在环测试是将车载智能计算平台软件烧写到目标芯片中,在目标芯片的硬件异构平台环境下验证软件的安全要求。然后,将车载智能计算平台与部分或全部的车辆电子电气设备进行网络通信,在车辆电控系统和网络环境下验证软件的安全要求。最后,将车载智能计算平台安装到实际车辆中,进行软件安全要求的验证与确认。07 人工智能通过实施完善的开发流程可降低车载智能计算平台人工智能的系统性安全风险。车载智能计算平台人工智能的开发包含需求分析、算法设计、数据采集和标注、模型训练、测试验证以及运行等流程。人工智能的需求分析应包含算法的基本功能需求和功能安全要求(如算法精度目标、算法Fail-Operational等)。算法设计阶段应考虑采用多算法、多模型、多帧数据、多传感器等多种冗余机制的组合以提升安全性。数据采集和标注阶段应确保数据标注精度、数据场景分布,并避免数据错标和漏标,从而确保模型训练不受影响。模型训练阶段采用业界成熟、文档全面的人工智能框架。测试验证阶段对所有需求进行闭环的测试,同时全面考虑各种潜在应用场景及环境影响因素,进行长距离的实车试验。根据测试结果不断重复进行数据的采集、标注、模型训练和测试验证的阶段,通过迭代的方式逐步提高人工智能的安全性。在运行阶段,应持续地对实际运行数据和人工智能的安全性进行监控,通过分析实际运行数据对人工智能算法和模型不断优化。08 软件阶段常用工具介绍a、PolyspacePolyspace Bug Finder可以识别嵌入式软件C和C++代码中的运行时错误、并发问题、安全漏洞和其他缺陷。使用静态分析(包括语义分析),Polyspace Bug Finder可分析软件控制流、数据流和进程间行为。通过在检测到缺陷之后立即高亮显示缺陷,可在开发过程的早期阶段鉴别和修复错误。Polyspace Bug Finder可检查是否符合编码规范,如MISRA C、MISRA C++、JSF++、CERT C、CERT C++和自定义命名规范。它可以生成报告,其中包括发现的错误、代码违规和代码质量指标,如圈复杂度。Polyspac eBug Finder可与Eclipse IDE配合使用进行代码分析。b、TessyTessy软件源自戴姆勒—奔驰公司的软件技术实验室,由德国Hitex公司负责全球销售及技术支持服务,是一款专门针对嵌入式软件动态测试的工具。它可以对C/C++代码进行单元、集成测试,可以自动化搭建测试环境、执行测试、评估测试结果并生成测试报告等。多样化的测试用例导入生成方式和与测试需求关联的特色,使Tessy在测试组织和测试管理上也发挥了良好的作用,目前,Tessy广泛应用汽车电子主流客户中。Tessy满足各类标准(如ISO 26262、IEC61508)对测试的需求,比如Tessy可以满足ISO 26262中各个测试等级对模块测试的要求,当然,Tessy本身也通过了TÜV的认证,证明该软件是安全可靠的,可以在安全相关的软件研发过程中使用。c、Helix QACHelix QAC是静态代码分析工具,依据C和C++编码规则自动扫描代码对规则的违背。在开发过程的早期就可以用它来检测缺陷,因为此时修改代码是最方便也最经济的。Helix QAC自动化强制实施代码编程标准,比如,MISRA保证代码的合规性。Helix QAC识别必须修改的缺陷,提供详细的指导,帮助开发人员修改问题。这是不需要运行程序的。开发人员既然获得了即时的上下文反馈,他们将因此从错误中获得学习,下一次编写新的代码(或者评审代码)时,能力将得到提升。Helix QAC自动审查代码,确保它们符合用户选择的编码标准。合规性报告可视化地提醒用户哪些代码需要多加留意。Helix QAC支持多种C和C++编码标准,提供相应的合规性模块,也支持标准的客户化定制。转载于汽车电子与软件微信公众号
  • [技术干货] AUTOSAR 信息安全框架和关键技术分析
    导读:本文节选自《中国汽车基础软件信息安全研究报告1.0》。智能汽车安全的底座是汽车基础软件信息安全,其所涉及的技术面非常广,需要不同领域的专家来共同研究与探讨。为此,AUTOSEMO组织了一个由21家企业与院校组成的编委会,把各家最新的研究成果和最佳实践提炼、总结、分享出来,通过撰写本《汽车基础软件信息安全研究报告》,以共同推动汽车基础软件信息安全的技术研发、标准建立、应用落地及产业化发展。随着汽车网联化和智能化,汽车不再孤立,越来越多地融入到互联网中。在这同时,汽车也慢慢成为潜在的网络攻击目标,汽车的网络安全已成为汽车安全的基础,受到越来越多的关注和重视。AUTOSAR作为目前全球范围普遍认可的汽车嵌入式软件架构,已经集成的相关信息安全模块对实现信息安全需求有着充分的支持,例如保护车内通信或保护机密数据。由于CP AUTOSAR 和AP AUTOSAR 的体系结构不同,目前信息安全模块的相关技术实现也存在差异。1. SecOC在车载网络中,CAN 总线作为常用的通讯总线之一,其大部分数据是以明文方式广播发送且无认证接收,这种方案具有低成本、高性能的优势。但是随着汽车网联化、智能化的业务需要,数据安全性越来越被重视。传统的针对报文添加RollingCounter 和 Checksum 信息的方法,实现的安全性十分有限,也容易被逆向破解,进而可以伪造报文控制车辆。SecOC 是在AUTOSAR 软件包中添加的信息安全组件,主要增加了加解密运算、密钥管理、新鲜值管理和分发等一系列的功能和新要求。该模块的主要作用是为总线上传输的数据提供身份验证,它可以有效地检测出数据回放、欺骗以及篡改等攻击在SecOC 标准中,AUTOSAR 主要基于MAC 的身份验证和Freshness 的防重放攻击,来实现数据的真实性和完整性校验。首先MAC(Message Authentication Code)是保障信息完整性和认证的密码学方法之一,其中CMAC(Cipher based MAC)一般用于对称加密,整车厂可在车辆下线刷写程序时静态分配密钥,也可选择使用云端服务器动态地给车辆分配密钥)是车载总线加密认证常用方案。MAC 的作用不是防止有效数据被泄露,而是为了保护数据不会被攻击方篡改,即完成数据来源的认证。如需保护通信数据不被攻击方监听,则报文的有效数据还需要进行额外的加密。为了降低重复攻击的风险,则需要在Secured I-PDU 中加入新鲜度值,Freshness Value 是一个根据一定逻辑不断更新的数值,Freshness Value 的更新方法多种多样,AUTOSAR 标准将基于计数器或基于时间的新鲜度值作为典型选项。在CP AUTOSAR 平台,SecOC 模块依赖于PduR 的API 和功能,提供了PDU Router 所需的上下两层API(upper and lower layer API)功能。依赖于由CSM 模块在AUTOSAR 中提供的加密算法。SecOC 模块需要API 函数来生成和验证加密签名(Cryptographic Signatures)或消息验证码(Message Authentication Codes)。为RTE 提供具有管理功能的API 作为服务接口进行调用。SecOC 通信协议特性同样适用于AP AUTOSAR 平台标准中,其主要目标是实现与CP AUTOSAR平台SecOC 功能互操作性,尤其适用于使用 UDP 多播的消息场景(SecOC 是目前唯一支持的协议)和与CP AUTOSAR 之间基于信号的网络绑定的安全通信场景。为了实现与CP AUTOSAR 平台的互操作性,SecOC 同样应用于Adaptive CM 中。认证信息包括认证器(例如,消息认证码)和可选的新鲜度值。为了保持与CP AUTOSAR 平台的互操作性并提供可选的新鲜度值管理功能,AP AUTOSAR CM 将依赖于可插入的新鲜度值管理库。该库将提供新鲜度值管理相关的API,包含CP AUTOSAR 平台关于Freshness Management 客户端、服务端接口的副本以及调用定义的相关功能。SecOC 的核心思想在于通信认证,但是不涉及报文加密。虽然伪造报文的难度已经大大提升了,但是在通信过程中采用明文传输,依旧有一定的风险;认证信息的强度和信息长度相关,通信认证方案会加大报文负载(传统CAN 报文的负载只用8-64 个字节),从而导致负载率提升,通信实时性下降,可能使得正常功能受到影响,应考虑信息安全强度与通信实时性的相互平衡;MAC 技术应考虑对称密钥的管理和共享的问题,目前大部分MCU 是没有安全功能的,对称密钥也是明文保存在系统或者内存中。共享该密钥时采用明文通信,这是非常不安全的。但MCU 的计算能力和存储空间是有限的,采用了安全机制以后,必然占用很大的资源消耗,应充分考虑系统的稳定性,以保障业务与安全机制能够正常运行;SecOC 用于保证安全通信,必然涉及密钥(key)的管理,应考虑灌装、更新和维护该key, 同时还需考虑换件后key 的一致性。2. TLSTLS(Transport Layer Security)作为传输层的中坚力量,可以支撑上层的SOME/IP、MQTT 和HTTP 等协议。不但可以用于V2X 的安全通讯,也可以用于车内通讯节点之间的安全通讯。当然像T-BOX等可以与车外节点通讯的节点来说,其安全性要求更高,可以应用更加完整的广义TLS,既安全,又灵活。而车内之间一般IP 地址、端口、服务接口等都固定,安全性要求也不如T-BOX 高,则可以应用广义TLS中的预共享密钥(TLS_PSK)等套件,既高效,又稳定。TLS 属于工作在传输层的协议,它介于传输层底层协议和上层应用协议之间。而以太网的传输层主要有两大底层协议:TCP(Transmission Control Protocol)和UDP(User Datagram Protocol)。二者各有特点,互为补充。不管在传统互联网上,还是车载以太网上,两者都是常见的传输层底层协议。不同的传输层底层协议实际上对应着不同的传输层安全保护协议,采用TCP 传输的,就用TLS 保护。采用UDP 传输的,就用DTLS 保护。DTLS 的全称是Datagram Transport Layer Security,比TLS 多出来的“D” ,指的就是UDP 中的“D” 。TLS 和DTLS 各有不同的版本,目前主流支持的还是1.2 和1.3版本。AUTOSAR 标准基于Ethernet 架构同时提供了ISO DoIP 的解决方案。DoIP 全称是Diagnostic Over IP,顾名思义就是基于IP 的诊断。DoIP 具有处理大量数据、节省重编程时间、方便接入IT 设施、标准通信灵活使用等优势。普通的DoIP 是基于TCP 进行诊断通信,在ISO 13400-2 2019 版本中定义了安全的DoIP 会话,即基于TLS 进行诊断通信。DoIP server 协议栈会根据DoIP client 实体的请求,确定使用TCP 还是TLS 进行诊断信息的传输。TLS 允许在Client DoIP 实体和Server DoIP 实体之间建立经过身份认证和加密的通信通道,Client DoIP实体身份的验证可以在诊断应用层中实现,例如ISO 14229 中定义的0x29 服务。TLS 技术仍有自身的技术局限性。大部分控制器都是采用了MCU,计算能力和存储空间都是有限的,采用了安全机制,例如加解密算法、消息摘要算法、签名验签算法等,必然占用很大的资源消耗,应考虑在不影响正常功能的情况下安全策略能够正常实施。SSL/TLS 采用安全认证的方式来识别对方身份,需要提前灌装安全证书,如果控制器进行换件,应保证证书的一致性,让新的控制器能够进行身份的合法验证,从而正常通信。在实际应用场景中,大部分控制器可能没有安全存储环境(SE 或者HSM 等),应考虑保证证书和私钥的安全存储。在采用TLS 进行安全认证通信中,必然会降低通信的效率,应考虑通信的实时性。安全技术应用的同时会带来一些资源消耗,产生一定的局限性。应当在满足汽车信息安全相关法规标准的原则下,技术手段在不影响控制器正常运行的前提下,进行方案选型完成集成部署,如果内部安全通信技术手段消耗过多的控制器资源并影响了正常业务运行,应适当降低安全等级,必须同时兼顾控制器运行和内部安全通信。随着汽车网联化的发展,以太网通讯已经在车内通讯及车联网普及,TLS 和DTLS 也更多地出现在汽车行业的视野里。AUTOSAR 在CP 和AP 中也加入了TLS 和DTLS 的规范。从AUTOSAR CP 4.4 标准开始就明确了支持1.2 和1.3 版本,优先选择1.3 版本。AP R21-11 中只描述了1.2 版本,但相信将来版本也会加上1.3 版本。3. IPsecIPsec(Internet Protocol Security)是网络安全协议,运行在OSI 模型的第三层(Internet Protocol,IP 层),在VPN(Virtual Private Network)应用很广泛。IPsec 在IP 层对报文提供数据机密性、数据完整性、数据来源认证、防重放等安全服务,定义了如何在IP 数据包中增加字段来保证IP 包的完整性、私有性和真实性,以及如何加密数据包。IPsec 提供了两种安全机制:认证和加密。认证机制使IP 通信的数据接收方能够确认数据发送方的真实身份以及数据在传输过程中是否遭篡改。加密机制通过对数据进行加密运算来保证数据的机密性,以防数据在传输过程中被窃听。IPsec 的安全体系由验证头协议(Authentication Header,AH)、安全封装协议(Encapsulating Security Payload ,ESP)及安全联盟(Security Association,SA)三部分组成。AH 是认证头协议(IP 协议号为51),主要提供的功能有数据源验证、数据完整性校验和防报文重放功能,可选择的散列算法有MD5(Message Digest ),SHA1(Secure Hash Algorithm)等。ESP 是报文安全封装协议(IP 协议号为50),ESP 将需要保护的用户数据进行加密后再封装到IP 包中,验证数据的完整性、真实性和私有性。可选择的加密算法有DES,3DES,AES 等。SA(Security Association)是IPsec 的基础,也是IPsec的本质,IPsec 对数据流提供的安全服务通过SA 来实现,它包括协议、算法、密钥等内容。IPsec 有隧道(tunnel)和传输(transport)两种运行模式,运行模式和安全体系中的AH 及ESP 组合形成4 种情况:隧道模式+AH、隧道模式+ESP、传输模式+AH 以及传输模式+ESP。AUTOSAR CP R19-11 标准在TCP/IP 模块加入IPsec 相关功能介绍,并对功能实现进行了条件约束,目前只支持IPsec 运输运行模式,隧道运行模式、IPv6 和多点传播都暂不支持。并规定了其他模块可执行的操作内容,KeyM 模块可为IPsec 子模块提供证书处理,CSM 允许执行IPsec 子模块所使用的加密作业和密钥操作。AUTOSAR AP 中IPsec 协议实施的目标是在车载IP 网络中提供安全的通信通道。在 AUTOSAR 自适应平台中实施IPsec 将为网络节点之间的通信提供保密性、完整性或两者兼备的选项。IPsec 作为标准网络安全协议提供了安全通信的手段,同时支持多供应商堆栈互操作性。自适应平台没有为电子控制单元指定任何操作系统,因此是IPsec 功能最好的实践方式。4. Crypto Stack为了汽车软件提供统一的安全加密/ 解密接口,AUTOSAR 在4.3 版本推出Crypto Stack 模块。Crypto Stack 是AUTOSAR 架构体系中负责数据加密保护和密钥管理的模块,由Crypto Service Manager,Crypto Interface, Crypto Driver 三个部分组成,为应用程序和系统服务提供了标准化的密码服务接口。密码服务可以是哈希计算,非对称签名验证,对称加密等。其主要应用于ECU 通信加密、SecurityAccess 流程保护和KEY 的管理等使用场景。CSM(Crypto Service Manager)是加密服务管理器,位于AUTOSAR 的SYS 模块最高层的服务层。服务层是基础软件的最高层,它的任务是为应用软件和基本软件模块提供基本服务,即为应用软件和基本软件模块提供最相关的功能。CSM 基于一个依赖于软件库或硬件模块的加密驱动程序来提供加密功能的服务,也可以使用多个加密驱动程序的混合设置。CSM 通过CryIf(Crypto Interface)访问不同的加密驱动程序。CSM 作为服务层,为SWC 或BSW 提供加密操作的接口。CSM 的主要任务是对服务进行调度和排序,并调用加密接口(CryIf)进行进一步操作。CryIf 将请求调度到加密驱动程序及其静态分配给该服务的加密驱动程序对象。CSM 使用基元(CsmPrimitives,已配置加密算法的实例)的静态配置来定义加密操作。然后将这样的基元分配给Job(Job 是配置过的CsmJob,指的是密钥、密码原语和参考信道),该配置决定进一步的属性,如优先级、异步或同步执行以及程序执行中应使用的密钥。需要注意的是,密钥总是位于加密驱动程序本身中,CSM 只使用对它的引用。密钥和基元的分离允许加密操作和密钥管理API 分离。这使得应用程序可以专注于所需的加密操作,如MAC 计算和验证,而密钥管理器则在配置设置期间提供密钥。CSM的API大致可以分为两类:直接AP(I 主要用于密钥管理)和基于Job的AP(I 主要用于加密操作)(见下图)直接API 与CryIf 和Crypto Driver 中的函数有直接对应关系,这些函数只能同步调用,CSM将把参数从应用程序直接传递给函数调用。基于Job 的API 使用一个Job 结构,即Crypto_JobType,它包含静态和动态参数以及对结构的引用,为执行该Job 的加密驱动程序提供所有必要的信息,使用Job 的每个服务都将使用此结构。服务的所有必要参数将由CSM 打包到结构的元素中,然后调用CryIf,然后调用配置好的Crypto Driver。Job 可以同步运行,也可以异步运行,这取决于静态配置。加密服务信息、加密算法族和模式的参数决定了加密驱动程序中要执行的确切的加密算法。CryIf(Crypto Interface)是加密接口模块,位于BSW(Basic SoftWare)的抽象层。CryIf 模块提供了唯一的接口来管理不同的加密硬件和软件解决方案,如 HSM、SHE 或基于软件的 CDD。CryDrv 有如下两种实现方式:1. Crypto(HW based):硬件加密模块的驱动程序,用于控制HSM(Hardware Security Module)或SHE(Security Hardware Extensions),和具体芯片有关。2. Crypto(SW based):基于软件的CDDs(Complex Device Drivers) 实现的加密算法, 如AES-128 等算法。基于以上两种不同的实现方式,CryIf 模块提供了唯一的接口来管理不同的加密硬件和软件解决方案。因此,基于 CryIf 维护的映射方案,CSM 模块可以使用多个底层的Crypto HW 以及 Crypto SW 解决方案。此外,CryIf 还确保了对加密服务的并发访问,从而能够同时处理多个加密任务。与CP AUTOSAR 不同,AUTOSAR 自适应平台支持用于通用加密操作和安全密钥管理的API。该API 支持在运行时动态生成密钥和加密作业,以及对数据流进行操作。API 实现可以引用一个中央单元(加密服务管理器)来实现平台级任务,例如跨应用程序一致地进行访问控制和证书存储。该实现还可以使用加密服务管理器来协调功能到加密驱动程序的卸载,例如硬件安全模块(HSM)。为了在潜在的应用程序受损的情况下支持密钥的安全远程管理,Crypto Stack 集成了密钥管理体系结构,其中密钥和相关数据以端到端的保护形式进行管理。密钥可以基于现有的供应密钥以受信任的方式引入系统,也可以通过本地密钥生成以不受信任的方式引入系统。5. IAM车内信息娱乐应用程序由于与外界互联网相连,因此被入侵的风险很高,像这类应用程序在设计时一定是不被允许使用车身控制相关服务的。例如信息娱乐系统被外界攻击,然后被远程控制去使用制动服务,为了保障安全,必须要阻止这种信息娱乐应用程序对制动服务访问的任何尝试。日益增长的信息安全需求驱动了身份和访问管理(IAM)的概念,因为AUTOSAR Adaptive 平台需要和应用程序建立健壮和良好定义的信任关系。IAM 为Adaptive 应用程序引入了特权分离,并针对攻击时的特权升级提供了保护。另外,在部署期间,IAM 能够使集成者提前验证Adaptive 应用程序要求的资源访问权限。IAM 为来自适应应用程序对服务接口,Adaptive 平台基础功能簇和相关模型资源的的请求提供了访问控制框架。IAM 框架为AUTOSAR Adaptive 平台堆栈和Adaptive 应用程序的开发人员提供了一种机制,这种机制用于对每个应用程序的意图进行建模,根据访问请求提供访问控制决策,并执行控制访问。IAM 侧重于提供方法来限制Adaptive 应用程序对Adaptive 平台基础接口、服务接口与功能集群相关的明确资源接口( 例如KeySlots) 的访问。特别对系统资源( 如CPU 或RAM) 的强制配额不包括在IAM 中。在运行期间,IAM 的进程对Adptive 应用程序是透明的,除非请求被拒绝并发出通知。远程Adaptive平台提供的服务实例请求由IAM 覆盖的,传入请求的PDPs 必须由Adaptive 应用程序实现。该框架旨在运行期间执行对AUTOSAR 资源的访问控制。假设Adaptive 应用程序将在启动时进行身份验证,并且现有受保护的运行时环境确保Adaptive 应用程序被正确隔离,并且防止它们的特权升级( 例如绕过访问控制)。考虑一个简单的应用场景,对于访问权限的描述,通常可以用一个访问权限矩阵来表示,访问权限矩阵显示的是访问主体和访问客体之间的访问权限。所谓访问主体,是指一个想要获得其他服务访问权限的对象,通常是指系统中的一个进程;所谓访问客体,是指应当授权被访问的对象,通常它可以是指系统中的一个进程也可以是系统中的其他资源。访问权限相关的信息需要以清单文件的形式部署在系统中。对于这份清单文件,有两种组成形式:第一种,针对每一个服务和应用,从访问权限主体的角度,列举每个访问主体的访问意图,也就是每个访问主体拥有的其他服务或应用程序(访问客体)的访问权限;第二种,针对每一个服务和应用,从被访问的客体角度,列举出它支持被哪些其他服务和应用(访问主体)访问。对于访问主体,通常情况下它可访问的客体清单文件是不会随着时间推移而改变;但是对于一个访问客体,它的被访问清单会随着部署了新的应用而更新。6. KeyM在一个加密功能中,密钥和证书的功能比重很大。首先,密钥是一种参数,它是在明文转换为密文或将密文转换为明文的算法中输入的参数。许多加密算法需要使用到密钥,因此,就需要KeyM 模块来管理密钥,而KeyM 对于密钥的管理主要体现在更新和生成密钥方面。而证书以加密或解密的形式保障了用户网络交流中的信息和数据的完整性和安全性。KeyM 模块可以实现证书链的配置保存与验证,这使得网络中的信息和数据的安全性更高。AUTOSAR KeyM 模块由两个子模块组成:密钥子模块和证书子模块。密钥子模块用于初始化、更新和维护的密钥材料;证书子模块允许定义和配置证书,以便在生产时存储它们,并进一步用于多种用途。密钥子模块提供了一个API 和配置项,用于引入或更新预定义的加密密钥材料。它充当一个关键客户端,解释从一个关键服务器提供的数据,并创建相应的关键材料,这些密钥被提供给加密服务管理器。成功安装密钥材料后,应用程序就能够进行加密操作。证书子模块提供了对证书进行操作的API 和配置。允许配置证书链,在配置中将证书的属性和关系设置好,上层应用通过 API 将证书数据传给KeyM 后,证书子模块将根据配置内容及HSM 按照标准结构解析的证书存储配置的位置(NVM、CSM 或 RAM)。此外,证书子模块允许BSW 模块和SWC 在AUTOSAR 软件架构的中心点上更有效地使用证书进行操作。此类操作的示例包括验证完整的证书链或从运行时提供并验证的证书中检索元素。所需的加密操作(如验证证书签名)仍然由加密服务管理器中定义的相关加密作业执行。与CP AUTOSAR 不同,AP AUTOSAR 平台的更新和配置、通信、持久性或诊断等服务,也需要加密服务作为其功能的一部分。因为架构差异的原因,AP AUTOSAR 平台会将需要用户自定义、差异性的功能在应用层去实现,所以应用程序可以定义所需的密钥插槽、加密提供程序和证书。当需要关键材料时,必须由自适应应用程序(例如OEM key manager)配置,平台应指定槽型机器的关键槽。为了管理关键材料,一个专用的自适应应用程序(密钥管理器)可以指定相同的密钥插槽(即相同的参数和插槽型机器)。7. IdsM车辆中的许多新功能建立在车载和后台服务之上,需要面对保护车辆免受网络攻击的挑战。为车辆的E/E 架构配置了安全机制,更新签名软件、安全启动和安全车载通信系统正在逐步建立。目前,IDS 作为一种额外的安全机制正在引起OEM 和供应商的关注。入侵检测系统管理器(IdsM)是一个基础软件模块(适用于Classic AUTOSAR)或平台服务(适用于Adaptive AUTOSAR),用于收集和集中聚合可能由车辆软件、通信或电子系统受到恶意攻击而导致的安全事件。软件组件IdsM 提供了接收板载安全事件SEv 通知的标准化接口。SEv 可以通过BSW (Basic Software Modules)和SW-C (application Software Components)实现的安全传感器上报。此外,可以用可选的上下文数据(如事件类型和可疑数据)报告SEv,这些数据对于在后端执行的安全取证来说是有用的信息。除了收集,IdsM 还可以根据可配置的规则对SEv 进行筛选。IdsM 将上报的SEv 过滤并转换为合格的机载安全事件(QSEv),IdsM 进一步处理QSEv,用于存储或转发。根据总体安全概念的不同,QSEv可以通过安全事件内存(Sem)在本地持久化,也可以传播到已配置的接收器,或者两者兼有。可用的接收器是诊断事件管理器(Dem)模块和IDS 报告器模块(IdsR),它们可以将QSEv 数据传递给后端中的安全操作中心(SOC)。在车辆内的每个安全相关或机器中,IdsM 模块或服务的实例会收集和过滤安全事件(可选地包括附加数据),以便将它们存储在本地安全事件内存(Sem)和/ 或通过车辆网络将它们转发到中央入侵检测系统报告器(IdsR)。例如,该IdsR 可能位于远程信息处理单元内,使其能够通过蜂窝网络向OEM 的安全操作中心(SOC)发送安全报告和相关数据。然后,安全事件管理(SIEM)分析这些信息,并在必要时用于制定和决定适当的防御或缓解措施以应对攻击。AUTOSAR 标准指出BSW 模块、CDD 和SWC 都可以充当安全传感器,安全传感器将安全事件(SEv)报告给IdsM,AUTOSAR 标准化可以由AUTOSAR BSW 报告的安全事件类型的子集。每个BSW 的规格里列出了自己产生的安全事件类型,这些事件由相应模块报告,业务组件也可以报告在AUTOSAR 中未标准化的自定义安全事件类型,可以使用安全性摘要(SecXT)指定由特定ECU 报告的安全性事件类型的属性。AUTOSAR 入侵检测系统管理器是通用的、提供灵活的配置。它独立于底层通信系统,在上述限制和假设条件下可以应用于任何汽车领域。AUTOSEMO背景鉴于中国汽车基础软件发展的重要性,应国内主要汽车企业的要求,并经主管部门认可,中国汽车工业协会(以下简称:中汽协),于2019年12月决定组建中国汽车基础软件生态委员会(英文China Automotive Basic Software Ecosystem Committee,简称AUTOSEMO)。旨在联合汽车及软件产业内的成员,形成由本土企业主导的共同规划和创建适应新需求的软件架构和接口规范,做强本土基础软件,推动行业开放和协作,促进产业向更智能化的方向发展。在当前复杂多变的国际产业竞争趋势下,设立AUTOSEMO具有十分重要的战略意义和现实意义。转载于汽车电子与软件微信公众号
  • [技术干货] PCIE,中央计算平台片内通信的“骨干”【转载】
    以下文章来源于十一号组织 ,作者11号线人近日,中央计算架构委员会组织了一次年中团建,邀请各分委会的兄弟们来火焰山避暑,顺便聊聊汽车下一代中央计算架构的实施进展。首先登场的是趾高气扬的SOC兄弟,还没等进门,就开始喊道:外面传感器是越来越多,数据量也是越来越大,还都想把原始数据送过来;我把拜把子兄弟都喊过来帮忙了,可高达Gbps级别的数据,我该如何与拜把子兄弟们实时交互信息呢?接着登场的是大腹便便的存储兄弟,好不容易坐稳,一脸愁容的说道:各位看我体型也能猜出我甜蜜的烦恼了吧,什么高精地图数据,外部传感器数据,内部智能座舱数据全都需要我存储,存慢了就背锅,谁有什么好方法让SOC给我的数据传的快点呀。其他小弟默默无语,两位大佬的问题不解决,中央计算架构似乎很难有所进展,而两位大佬问题的共同点就是:如何解决下一代中央计算架构下的片内高速实时通信需求。业内给出的一种解决方案就是PCIE。PCIE简介2001年初,Intel提出要采用新一代的总线技术来连接内部多种芯片,并取代当时使用的PCI总线,并称之为第三代输入输出技术(3GIO技术)。2001底,雷厉风行的Intel就联合AMD、DELL、IBM等20多家业内主导公司开始起草新技术的规范,并于2002年完成,这种新的总线标准对外正式命名为PCI Express(PCIE/PCI-E)。PCIE(Peripheral Component Interconnect Express)是一种全双工、端到端、串行、高速可扩展通信总线标准。全双工,是指允许设备在同一时刻,既可以发送数据也可以接收数据。这就好比一条双向车道,南来的北往的互不干扰。而实现总线上数据发送或接收的物理介质是一对差分线,接收端通过比较两根线上信号的差值,来判断发送端发送的是“逻辑0”还是“逻辑1”。采用差分信号传输,可以极大提高抗干扰能力,从而大幅提升传输频率。而这样的两对发送和接收组成的一个差分回路(总共4条线),被称为1xLane。端到端,指的是一条PCIE链路(Link)两端只能各连接一个设备,这两个设备互为数据的发送端和接收端,如图2的设备A和设备B。而一条Link可以由多条上文介绍的Lane组成,这就好比双向道路中,每一向道路中又可以包含多条车道。常见的Lane有x1,x2,x4,x8,x16,x32等。串行,数据一位一位的依次传输,每一位占据一个固定的时间长度。有点电子学基础的朋友可能要问,为什么不采用并行方式呢,一个固定时间长度,能同时传输8/16/32bit…,传输速率不是更快吗?巧了,PCIE的众多总线前辈们采用的也的确是并行方式。采用并行的方式,数据通常在公共时钟周期的第一个上升沿将数据发送出去,数据通过传输介质到达接收端,接收端在公共时钟周期的第二个上升沿对数据进行采集,发送和接收正好经历一个公共时钟周期。也就说在这一个公共时钟周期内,发送端的发送数据必须保持不变,以保证接收端可以正确的采样。在并行方式下,公共时钟周期必须大于数据在传输介质中的传输时间(数据从发送端到接收端的时间),否则也将无法正确采样。而并行方式中有几十根数据线,要遵循木桶原理,即保证数据传输最慢的那根数据线满足公共时钟周期,这也是为什么高速并行总线需要做等长处理。所以并行方式要想提高传输速率,必须不断提高时钟频率。但是受限于传输时间,时钟频率不可能非常高。同时随着频率越来越高,并行的连线相互干扰异常严重,已经到了不可跨越的程度。再加上时钟相位偏移等因素,导致采用并行方式并不能满足越来越高的数据传输速率要求。而采用串行的方式便可完美解决上述问题,时钟信号和数据信号一同编码在同一数据流中,数据流一位一位的传输,接收端从数据流中恢复时钟信息。由于没有时钟线,也就不存在时钟相位偏移。再加上数据包分解、标记和重组技术的进步,使得串行传输数据的速度可以越来越快。高速,PCIE目前已经正式发布6个标准版本,最新的为PCIE 6.0,其传输速率基本上遵循了下一代比上一代翻倍的定律。我们首先以PCIE 1.0来举例介绍下传输速率与我们更常用的带宽单位之间的关系。PCIE标准中用GT/s(GigaTransfers per second,一秒内电位变化的次数)表示传输速率,而一次电位变化从数据角度来说就相当于传输了一个Bit。但是PCIE的电位变化并不全都用来传输有效数据,里面还包含了时钟信号。PICE 1.0采用的8/10b编码,就包含了2位时钟信号,这意味着传输8位有效数据要经历10次电位变化。(注:PCIE 3.0以前使用8/10b编码,PCIE 3.0及以后版本使用120/130b编码。)PCIE 1.0标准中Lanex1的传输速率为2.5GT/s,换算成GBps为2GBps(2.5x8/10),换算成MB/s为250MB/s(2/8x1000),x2,x4,x8,x16依次类推。表1给出了PCIE 1.0到6.0不同Lane下的带宽数据。PCIE 6.0在Lanex16时可以提供高达126GB/s的带宽,这不就是汽车直男的心动女生吗。而在2022年PCI-SIG开发者大会上,PCIE接口标准委员会PCI-SIG就公布了PCIE 7.0的规范目标,称其数据速率高达128 GT/s,并在2025年向其成员发布。这相当于在编码开销之前,通过16通道 (x16) 连接能实现512 GB/s的双向吞吐量。PCIE拓扑结构一、基于x86计算机系统PCIE总线在x86计算机系统中作为局部总线,主要用来连接处理器系统中的外部设备。在x86计算机系统中,PCIE设备主要包括根复合体(Root Complex,RC),交换机(Switch),终端设备(Endpoingt),PCIE到PCI/PCI-X的桥(Bridge)等。RC将PCIE总线端口、存储器等一系列与外部设备有关的接口都集成在一起。CPU平时比价忙,便会把很多事情交给RC去做,比如访问内存,通过内部PCIE总线及外部Bridge拓展出若干个其他的PCIE端口。Endpoint作为终端设备,可以是PCIE SSD、PCIE网卡等,既可以挂载到RC上,也可以挂载到Switch上。Switch扩展了PCIE端口,可以将数据由一个端口路由到另一个端口,从而实现多设备的互联,具体的路由方法包括ID路由,地址路由,隐含路由。靠近RC的端口称为上游端口,扩展出来的端口称为下游端口。下游端口可以挂载其他Switch或者Endpoint,并且对他们进行管理。从上游过来的数据,它需要鉴定:(1)否是是传给自己的数据,如果是便接收;(2)是不是自己下游端口的数据,如果是便转发;(3)如果都不是,便拒绝。从下游端口挂载的Endpoint传给RC的数据,Switch会进行相应的仲裁,确定数据的优先级,并将优先级高的数据传送到上游端口中去。Bridge则是用来实现PCIE设备与PCI/PCI-X设备之间的连接,实现两种不同协议之间的相互转换。二、基于汽车汽车电子电气架构的多样性,导致很难有像x86一样的统一架构。而基于中央计算架构,Mircochip曾给出过一种架构方案,在此架构中,PCIE Switch串联起整个片内通信。中央计算单元中的不同SOC,Ethernet Switch等均挂载其上面。外部传感器通过Zonal ECU的Ethernet Switch串联在一起。PCIE分层体系在PCIE总线中,数据报文在接收和发送过程中,需要经历三层蹂躏,包括事务层(Transaction Layer)、数据链路层(Data Link Layer)和物理层(Physical Layer)。各层又都包含发送和接收两块功能。这种分层的体系结构和网络的经典七层模型有异曲同工之妙,但不同的是,PCIE总线中每一层都是使用硬件逻辑实现的。工作流程如图5所示,数据报文首先在设备A的核心层中产生,然后再经过该设备的事务层、数据链路层和物理层,最终发送出去。而接收端的数据也需要通过物理层、数据链路层和事务层,并最终到达设备B的核心层。一、事务层。事务层位于PCIE分层体系的最高层,一方面接收设备核心层的数据请求,封装为TLP(Transaction Layer Packet)并在TLP头中定义好总线事务后,发送给数据链路层。另一方面,从数据链路层中接收数据报文,掐头去尾保留有效数据后转发至PCIE设备核心层。PCIE中定义的总线事务有存储器读写、I/O 读写、配置读写、Message总线事务和原子操作等总线事务。这些总线事务可以通过Switch等设备传送到其他PCIE设备或者RC。RC也可以使用这些总线事务访问PCIE设备。以存储器读为例,网络中某个有需求的Endpoint初始化该请求后发送出去,请求经过Switch之后到达RC,RC收到存储器读请求后在系统缓存中抓取数据并回传完成报告。完成报告同样经过Switch后到达Endpoint,Endpoint收到完成报告后结束此次事务请求。事务层还使用流量控制机制来保证PCIE链路的使用效率。二、数据链路层数据链路层在PCIE总线中发挥着承上启下的作用。来自事务层的报文在通过数据链路层时,将被添加Sequence Number前缀和CRC后缀,并使用ACK/NAK协议保证来自发送端事务层的报文可以可靠、完整地发送到接收端的数据链路层。来自物理层的报文在经过数据链路层时,会被剥离Sequence Number前缀和CRC后缀再被发送到事件层。PCIE总线的数据链路层还定义了多种DLLP(Data Link Layer Packet),DLLP产生于数据链路层,终止于数据链路层。值得注意的是,TLP与DLLP并不相同,DLLP并不是由TLP加上Sequence Number前缀和CRC后缀组成的。三、物理层物理层是PCIE总线的最底层,将PCIE设备连接在一起。PCIE总线的物理电气特性决定了PCIE链路只能使用端到端的连接方式。PCIE总线的物理层为PCIE设备间的数据通信提供传送介质,为数据传送提供可靠的物理环境。物理层是PCIE体系结构最重要,也是最难以实现的组成部分。PCIE总线的物理层定义了LTSSM(Link Training and Status State Machine)状态机,PCIE链路使用该状态机管理链路状态,并进行链路训练、链路恢复和电源管理。PCIE总线的物理层还定义了一些专门的“序列”,有的书籍将物理层这些“序列”称为PLP(Phsical Layer Packer),这些序列用于同步PCIE链路,并进行链路管理。值得注意的是PCIE设备发送PLP与发送TLP的过程有所不同。对于系统软件而言,物理层几乎不可见,但是系统程序员仍有必要较为深入地理解物理层的工作原理。汽车领域应用案例一、理想从网络上公开资料获悉,理想2023年要上市的新车,除了采用800V纯电平台,还将采用其最新的第三代架构LEEA3.0,如图6所示。LEEA3.0为中央计算平台+区域控制架构,中央计算平台很有可能采用类似工控机的模块化方案,将实现智能车控、自动驾驶和智能座舱功能的三块板子通过高性能交换机连接在一起,并设计到一套壳体中,有点类似特斯拉HW3.0的松耦合方案。而高性能交换机的方案有两种,一种是PCIE Switch,一种是TSN Switch。PCIE Switch主要充当算力芯片之间“话事人”,通过提供20Gb/s以上的端到端的数据传输带宽,可以解决高带宽、低延时的痛点需求。同时通过物理隔离,单点失效将不会影响系统失效。TSN Switch主要充当与安全芯片及区域控制器的通信,提供时间确定性的数据流转发和数据交换。二、Mircochip2020年9月,Microchip在一期《Inter-Processor Connectivity for Future Centralized Vehicle Computer Platforms》分享中,共享了其对下一代中央计算平台的一些观点。什么区域配合计算中心、SOA、以太网,都是写老掉牙的话题,没什么新意。但在提到下一代架构以太网带宽的挑战时,预测中央计算平台中送入的数据量将达到200Gbps(说实话我愣是没估算出来,大家看下面图自己领悟吧中央计算单元为了解决这么大数据的涌入问题,必须采用PCIE,基于以上需求,2022年2月,Mircochip宣布推出市场上首款通过汽车级认证的第四代PCIE交换机,提供了一种面向分布式异构计算系统的高速、低延迟连接解决方案,主要用于提供连接ADAS内CPU和加速器所需的最低延迟和高带宽性能。写在最后支撑中央计算架构演进的路上还需要很多像PCIE这样的关键人物,而这些又是我们随时可能被大洋彼岸列强卡脖子的关键。如何在这些硬科技领域实现突破,是吾辈这一生的使命。参考资料:理想汽车的电子电气架构迭代https://mp.weixin.qq.com/s/eTb8XxxvJKwgL7Ls3s5qmwSOC设计之PCIe总线https://mp.weixin.qq.com/s/G3GVjp3hs5h81_I18biuuwMicrochip:Inter-processor Connectivity for Future Centralized Compute Platforms转载于汽车电子于软件微信公众号
  • [技术干货] 自动驾驶SOTIF落地的思考与展望【转载】
    以下文章来源于sasetech ,作者隋玉磊引言自动驾驶SOTIF落地的思考与展望随着汽车“新四化”的演进,上半场“电动化”已经初具格局,下半场“智能化”正火热进行,智能汽车的安全嫣然成为智能化的核心竞争力之一,随着《关于开展智能网联汽车准入和上路通行试点工作的通知(征求意见稿)》的发布,对L3&L4的安全要求提出了框架指示,未来、谁能掌握安全的制高点,那么谁在智能化竞争中胜算就会更大,而耳熟能详的ISO 26262已经无法覆盖EE系统安全问题,随着ISO 21448的发布,貌似给自动驾驶企业带来一丝丝曙光,那么21448在企业如何落地呢?笔者聊聊个人浅见。➡本文主要内容分为6个部分(约5500字,18钟阅读)01小科普(老手略过)ISO 26262是为了解决电子电气系统失效导致的不合理的风险,且假定预期功能是安全的(预期功能不安全属于SOTIF范畴)。功能安全是对EE失效的研究,确切的说是对“EE白盒失效”的分析然后对失效进行避免或者控制,将风险降低到合理可接受程度,而随着技术发展,自动驾驶涉及的各个要素的失效原因,甚至失效模式不再是“白盒”,传统的功能安全已经不能cover相关安全风险,EE系统在没有故障的情况下,由于功能不足(规范不足和性能不足)、人员误用仍会导致风险,基于此背景ISO 21448标准立项成立,正式版标准于2022年6月发布。02标准适用范围 (老手略过)车型:乘用车、商用车(含低速物流小车)功能:适用于依靠复杂传感器和处理算法进行态势感知且感知的正确性会对安全产生重要影响的预期功能,特别是驾驶自动化等级为 L0~L5级的相关功能。补充几句:SOTIF同样适用于非ADAS的EE功能,如:假设电动车窗防夹力设计200N,当车窗开关被儿童误触发(直接误用)导致夹伤肢体,防夹参数本身的不安全,属于SOTIF范围的“规范的不足”。03SOTIF开发模式的思考先回顾一下功能安全,功能安全的现状是OEM提出功能安全需求,由Tier1承接并转化为技术安全需求,最后把需求传递给Tier2,细化成软硬件安全需求(当然,由于产业链重塑,出现了T0.5/T1.5/全栈自研等角色,但是FUSA需求传递理念是不变的),由于功能安全算是一个历史悠久的标准,且整车安全目标已经趋于统一,供应商早已基于行业经验或者SEOOC开发一个带有ASIL属性的产品(传感器、控制器、执行器、操作系统、芯片等)。先看一看SOTIF的SEOOC可行吗?关于SOTIF的发展,个人预测它不会像功能安全一样多点开花,受以下因素制约:其一、整车车型不同,车身轴距、重量不同(影响DDT参数标定)其二、硬件方案不同,如传感器的数量、冗余类型,安装位置有差异;其三、软件算法不同,感知融合算法类型/参数不同、规控算法差异;其四、ODC不同,导致整车层级安全策略、驾驶策略、MRM策略,人机交互策略不尽相同。以上原因导致整车层级,系统层级,部件层级的SOTIF需求差异化严重,供应商的同一款产品搭载到不同公司、不同平台车型的SOTIF需求短时间无法统一。面对以上众多“车端”SOTIF需求的不确定性,导致SEOOC的逆向开发模式异常困难,基于此现状笔者认为SOTIF的开发将以OEM(或者系统供应商)为主导地位。04工程落地的思考结合对自动驾驶发展趋势的判断及个人一些浅见,笔者认为SOTIF的落地大致会经历三个阶段:初学乍练,渐入佳境,登堂入室(这要是放在古代,笔者还真是文人墨客,迁客骚人)初学乍练“二八原则”是关键为什么说“二八原则”,什么是SOTIF的“二八原则”?回答这个问题前,我想还是从功能不足和触发条件的识别说起吧,不论是FUSA还是SOTIF,其本质都在降低风险到一个可接受的程度(这是一种“想对安全”的理念,还不是“本质安全”),识别故障和不足是前置条件,对于26262而言,通过安全分析FMEA、FTA等方法识别故障,然后设计安全机制,但是SOTIF面对的是人-车-环境交互的复杂体,其“系统”已经不局限于车,随机性的场景对智能驾驶的潜在影响也不是一两句话能解释清楚,传统的安全分析用在SOTIF上明显乏力,安全分析的“完整性”一词也不再适用于SOTIF。目前的窘境是,大部分公司的SOTIF都是功能安全负责人带头干,初衷是好的,但是心有余而力不足,你能识别出的功能不足和触发条件,人家系统工程,算法工程师或许早就知道,兴许人家的know how比你还要多的多,你能分析到的仅仅是你能知道的,那还做什么SOTIF? 直接去测试,不断发现问题,解决问题就好了,其实这也是Waymo case by case的做法,实践下来取得的效果也不错,Waymo在2021年之前感知模块问题占比较大,2021之后规控问题占比上升(并不是说规控问题发生次数多了,而是感知问题占比降低,导致规控问题占比升高)。再回到SOTIF本身,此阶段不意味着躺平,企业需要引入SOTIF理念,建立SOTIF流程,智能驾驶开发人员具备SOTIF全流程的认知,埋下SOTIF文化的种子,但不必期望SOTIF这件事情能立刻开花结果,更没有必要急功近利的撰写大量的“纸面无用功夫”,笔者认为20%的精力用于SOTIF V流程左侧就够了,80%精力用于V右侧的测试、确认以及真实数据池的建立。积累数据,用数据回放的形式来打磨算法也好,还是用IDM(Intelligent driver model)等手段来训练规控也好,总之、真实数据收集是关键。小结:本阶段,搭建流程是基础,用测试手段去闭环功能不足和积累触发条件是核心,这个阶段还没有到数据驱动,仍然是靠人在驱动闭环流程。进入佳境随着行业的摸索,自动驾驶的功能架构、系统架构差异化逐渐缩小,硬件方案(传感器数量、安装位置甚至冗余思路)趋同,差异化集中在软件本身。基于上述假设,从安全角度势必会出现通用的自动驾驶的感知、预测、决策、规划、控制模块的“顶层安全准则”,其实这些“顶层安全准则”已经在UL 4600的第8&9章节对应的required小章节有所体现,但是采用何种技术手段去实现这些模块的“顶层安全准则”标准并没有提及,也不会提及,这将是每家企业的智驾产品在安全维度的核心竞争力所在。说了这么多,读者会问SOTIF在感知、预测、决策、规划 、控制模块到底要做什么?笔者认为这个答案并不在问题本身这个层面,要跳出问题本身来思考,原因在于笔者看好AI在智能驾驶上的应用,推断“预测”、“决策”、 “规划”几大模块的算法会逐渐AI化才能真正实现自动驾驶,从安全维度刻意区分是FUSA的问题还是SOTIF的问题并没有太大意义(不考虑几大模块运行载体的失效,如SOC/MCU硬件故障)。感知、预测、决策、规划 、控制模块SOTIF需求的导出SOTIF的顶层目标是接受准则,接受准则是量化指标,那么它必定会和感知、预测、决策、规划 、控制模块从量化需求上产生某种函数关系,对于ADS子模块的量化指标,本质上就是SOTIF需求,这是正向导出需求的大体思路。但是、正向操作非常困难,基于此背景,先摸底各个模块的性能,由各个模块负责人去论证其模块承担的功能的安全维度可接受性,在执行validation活动中继续识别模块的不足,反复优化模块性能,直到接受准则被论证实现,最终每个模块形成该模块功能各个维度的量化参数,作为基线版本,这或许是现阶段可落地的方案之一。至于接受准则要执行多少公里/时长,是否能执行下去,以及如何执行,另当别论。读者可能问“如果接受准则是定性的,怎么办?”从定性角度论证接受准则的达成,笔者认为这将是一件众口难调的事情,尤其是L3及以上最好不要这么搞。定性的接受准则需要写一篇“议论文”,中心论点是系统在safety measures的加持下所有潜在危险场景下C=0,得到S*C=0,无SOTIF风险。但是、这将引出若干个伪命题,如“所有潜在危险场景”的完整性、覆盖率如何通过“纸上”论证呢?有报警但是驾驶员不接管的话,C=0?还是论证M值呢?以上仅抛出一些开放式的问题。另外、补充一下,SOTIF不仅关注ADS系统内的模块的性能,还涉及诸多规范层面的不足,笔者认为在执行上述活动过程中,规范的不足的识别和修改反而是水到渠成的事情。小结:本阶段研发团队搭建数据驱动和闭环的流程是核心,同步创建功能Use case库、SOTIF场景库;测试团队拉通“多支柱法”测试和研发团队形成良性循环,不是为了测试去测试,而是为了发现、弥补设计的不足,这“任督二脉”的打通是SOTIF成败的关键。登堂入室软件定义汽车时代,数据、算法和算力是自动驾驶开发的核心三要素,企业能够持续地低成本、高效率、高效能收集和处理数据,并通过数据迭代算法,最终形成数据闭环是自动驾驶企业可持续发展的关键所在,那么数据到底驱动了啥?闭环了啥?和SOTIF又有啥关系?从2021年开始,走“渐进式”路线的企业陆续实现L2+级别车辆规模化量产,数据闭环模式逐渐打通,众包收集场景,进行数据挖掘,反复迭代优化算法,逐级攻克L3&L4场景问题,这是业界常规做法,而SOTIF的运行阶段活动核心不就是需要打造这么一个闭环流程吗。那么对于SOTIF而言数据驱动更关心什么?应该干点啥?怎么干?笔者认为最重要的是建立获取边界数据的有效触发机制,获取更多边界数据,数据闭环的触发机制包含功能触发、功能误触发/漏触发、驾驶员行为触发等,而SOTIF恰好可以利用这些触发机制提取“危险行为”,完善上文所说的SOTIF场景库,然后对数据泛化加工、测试和更新软件,得到特定场景的DDT安全策略也不是不可能,形成感知、预测、决策、规划 、控制模块的最佳安全模型也不是不可能,关键在于SOTIF如何和数据驱动有机结合!但是问题来了,众包采集的原始车辆的传感器配置可能较低,会漏掉一些目标特征信息,这对于SOTIF是否有影响?影响有多大?如何减小影响?行业内是否有相关技术能攻克这一难题?BEV技术不强依赖目标特征,或许是解决方案之一吧。小结:笔者认为SOTIF的终极形态是没有专门的SOTIF工作,而是将其融入现有自动驾驶开发流程,由各模块负责人去兼容,这是最靠谱的模式。世上本来不存在SOTIF,标准成立了,也就有SOTIF了。你品,你细品!05建立用户对“自动驾驶”的渐进式成长的认知想一想还是应该补充这一段内容。市场上L2+产品事故已发生多起,从SOTIF角度分析,大部分事故原因是人员误用(分心)+功能不足导致(感知的漏检居多),人员误用属于驾驶员的责任,功能不足属于车企的责任。“用户教育”对于SOTIF要求的避免合理可预见的人员误用大有裨益。(至于为什么不解决车端的功能不足,而去约束驾驶员的误用,相信不需要解释了)不论是L2.5还是L2.9,都是L2,OEDR主体仍是驾驶员,企业应建立用户告知机制,确保用户充分掌握智能网联汽车与传统汽车在操作、 使用等方面的差异,告知自动驾驶功能产品功能及性能限制、 车内安全员职责、 人机交互设备指示信息、 系统操作说明、 功能激活及退出条件和方法、 最小风险策略、系统潜在风险说明、人工接管预留时间、不可避免碰撞的响应策略等信息。告知信息应明确写入产品使用说明书。(摘自:关于开展智能网联汽车准入和上路通行试点工作的通知(征求意见稿))其次、在上述要求基础上,增加“用户培训”机制,如:电子考试,考试通过后方可开启智驾功能,这也是不错的防误用手段。06Tier1该干点啥呢?前段时间和某Lidar公司同仁聊天,谈到Lidar如何做SOTIF的话题,有几点体会和大家分享一下,尤其对于传感器而言,如lidar这种精密器件,它的失效原因可以识别、但是失效模式、失效影响可能都很难评估,比如盲线和瞎线对整个lidar输出到底有多大影响,目前还是说不清楚的,产品还不能按照最差失效模式、失效影响处理,这样会导致产品性能的提升和成本的投入不成正比。上文中,笔者陈述了SOTIF将是以OEM(或者系统供应商)开发为主导,原因不再赘述,面对SOTIF,笔者认为传感器供应商当前能做的工作不多,能了解SOTIF概念,能和OEM在SOTIF话题上有共同语言就行了。躺平也不行,干点啥?Tier1应该清晰的知悉自身产品性能边界,比如对某传感器而言,其准确率和召回率是SOTIF强相关的,做到100%肯定不可能,那么做到XX%才算符合OEM的需求呢,多说几句,这里会引出两大类问题:第一、从整车级如何导出对融合算法的量化需求?以及融合算法连续几帧错误输出才会产生危险行为?第二、从融合算法又如何向输入端(传感器)导出量化需求?如果现阶段无法从正向导出量化需求,逆向操作是否可行?先依据已知的感知性能参数,通过实车validation,符合了确认目标,论证接受准则被实现是否可行呢?进而确定某传感器的准确率和召回率分别是XX%,在基于某传感器架构方案下,某融合算法方案前提下,才符合了SOTIF要求,笔者认为迫于现状,大概率先这样做。在不同架构、不同融合算法下,同一个传感器发挥的能力是不同的,其单一传感器的weakness对感知融合的输出影响也不同,传感器自身性能提升的可能性不大,还是在ADS感知融合模块做文章,更大程度上容忍单一传感器的信息偏差,剧情大致是这么一个走向。限于公司要求及作者能力,本文还有很多“坑”没有填,许多开放式的问题需行业同仁共同努力…隋玉磊 / 作者转载于汽车电子与软件微信公众号
  • [问题求助] MDS 中编译ADSFI 示例报错
    Build Start Project: lidar_slam, Type: Debug. /usr/bin/cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=/home/ww/MDC300F/MMC1/ADSFI_Sample/modules/lidar_slam/cmake/toolchain.cmake -DCMAKE_MAKE_PROGRAM=/usr/bin/make -DCMAKE_BUILD_TYPE=Debug /home/ww/MDC300F/MMC1/ADSFI_Sample/modules/lidar_slam Cannot run program "/usr/bin/cmake" (in directory "/home/ww/MDC300F/MMC1/ADSFI_Sample/modules/lidar_slam/build/cmake-build-debug-default_toolchain/gcc-linux-aarch64"): error=2, 没有那个文件或目录 Execute generation command failure. 
  • failed to get mdc version
    在mds上执行launch时,首先报failed to get mdc version的错误,随后执行起来就会非常的缓慢,不知道该如何解决?
  • [技术干货] 【论文分享】面向车联网的智能数据传输新方法
    面向车联网的智能数据传输新方法张德干1,2, 赵彭真1,2, 高瑾馨1,2, 张婷1,2, 龚倡乐1,21 天津理工大学计算机视觉与系统教育部重点实验室,天津 3003842 天津理工大学天津市智能计算及软件新技术重点实验室,天津 300384摘要车联网(IoV,Internet of vehicle)技术是智能交通中的热点研究课题,智能数据传输新方法的研究是IoV的重要技术之一。针对IoV的智能数据传输问题,考虑了车辆密度、车辆速度、数据传输速率和数据传输时延等重要参数,构建了IoV网络模型和时延函数,提出了基于马尔可夫决策理论的数据传输最优路由方法。通过同类方法的对比分析,验证了本路由策略具有数据传输速率更高和数据传输时延更短的性能,对基于IoV的智能交通中的动态远程监控等多种应用具有重要的理论意义和实用价值。关键词: IoV ; 智能交通 ; 马尔可夫决策理论 ; 数据传输 ; 时延1 引言在 IoV 中,车辆使用车辆到车辆(V2V, vehicle-to-vehicle)或车辆到基础设施(V2I, vehicle-to-infrastructure)的无线通信技术发送遥感数据到智能交通指挥监测中心,不同于传统覆盖范围有限的固定传感器的传感系统,IoV 可以监控车辆能够到达的任何地方[1,2,3,4,5,6,7,8]IoV中一个最重要的问题是保证感知数据从观测点到监测中心的及时交付,因为许多IoV应用需要频繁更新来自整个城区的感知信息,如智能交通系统[9,10,11,12]。IoV 的数据传输链路取决于车辆的移动性,因此,保证IoV中数据传递的时间和空间覆盖相当具有挑战性。在具有间歇性连接的网络中,车辆有时必须在远离目的地时携带数据。事实上,时延容忍网络(DTN,delay tolerant network)同样会出现到达目的地的间歇路由问题[13,14,15,16,17,18,19]。由于相似性, DTN 的分组路由策略也可以用于 IoV。然而,IoV在如下3个方面与一般的DTN不同。1) IoV中的车辆仅沿道路行驶,而 DTN 中的移动节点通常被假定为能够任意移动;2) IoV通常采用具有多个目的地的任意播,而DTN中的工作假定为单播;3) 存在具有预定未来轨迹的车辆(如公交车),而在一般的 DTN 中,很难预测移动节点的移动。因此, DTN 的分组路由策略不能直接适用于 IoV 或无法充分利用IoV特性。具有最小时延的分组路由策略是 IoV 中智能数据传输方法研究的主要技术[20,21,22,23]。首先,由于车辆只能沿道路行驶,所以不同道路的车辆密度存在差异。显然,高密度的道路可以提供更多无线多跳转播机会,从而减少路上的交付时延。IoV中影响时延性能的重要因素,由于B1的移动不确定性,要传输的数据转发到B1时,可能无法将分组传递到目标AP(即AP1)。然而,由于在B2的方向(即AP2、AP3和AP4)上存在许多替代AP,因此要传输的数据转发到B2可能是减少时延更好的选择,具有已知轨道的车辆可以帮助进一步减少时延,如公交车等。目前,IoV 中数据传输方法的分组路由策略大体有如下两种方案[24,25,26,27,28,29,30]。在参考文献[24]中,采用随机有向路网图表示该路径图模拟道路地图结构和交通流量统计信息,如道路上的车辆密度和速度,并且路由算法的开发优于其他现有算法。基于道路网络模型,参考文献[13]提出了一种利用车辆轨迹信息的分组路由方案。本文将研究IoV中智能数据传输新方法,涉及路由策略中通过考虑所给定的3 个因素来最小化分组传输时延。扩展参考文献[24]中的有向路网图模型以说明预定的车辆轨迹,该模型能够将路由问题表述为简单的马尔可夫决策理论(MDT,Markov decision theory),该决策过程试图将分组的预期时延最小化,通过解决马尔可夫决策过程,设计了一个最优的数据传输分组路由算法。本文的创新点如下:构建了一种新的有向路网图模型,该模型能够智能捕捉具有预定轨迹车辆(如公交车)的影响,并且能够动态制定路线;设计了一个时延最小的数据传输路由算法,该算法可智能地统计车辆数量、选播路由和选定最优车辆行车路线。2 结束语针对IoV的智能数据传输问题,考虑了车辆密度、车辆速度、数据传输速率和数据传输时延等重要参数,基于网络模型和时延函数,提出了基于MDT 的数据传输最优路由方法。使用天津市部分出租车和公交车的实际数据,在GloMoSim模拟器上进行大量模拟,验证了本路由策略具有更好的数据传输速率和显著缩短数据传输时延的性能。研究结果表明,智能数据传输分组路由方法可以极大地提高IoV的时延性能,该研究对基于IoV的智能交通应用具有重要的理论意义和实用价值。The authors have declared that no competing interests exist.作者已声明无竞争性利益关系。3 原文链接http://www.infocomm-journal.com/wlw/article/2019/2096-3750/2096-3750-3-2-00089.shtml
  • [技术干货] 【论文分享】基于区块链的安全车联网数字取证系统
    基于区块链的安全车联网数字取证系统李萌1, 司成祥2, 祝烈煌31 合肥工业大学,安徽 合肥 2306012 国家计算机网络应急技术处理协调中心,北京 1000293 北京理工大学,北京 100081摘要车联网大数据的出现对更好地理解车联网特点、掌握车联网用户需求和提升车联网服务质量具有极大的推动作用,然而恶意用户甚至不法分子利用车联网进行非法行为,造成车联网服务质量下降以及车联网事故难以定责。同时,在车联网数字取证过程中,还存在一些安全和隐私问题,如数据提供者的身份隐私和数据访问者的请求权限问题。因此,提出了一种基于区块链的安全车联网数字取证方案。首先数据请求者在一个证书中心注册后获得匿名证书,用于后续的数据上传。然后数据访问者注册后获得公私钥对和用户密钥,分别用于数据请求和数据解密,只有其属性满足特定要求才能解密得到正确证据。接下来可信度较高的若干个机构联合建立一个区块链,记录车联网取证过程中所有的数据上传交易和数据访问交易。最后,对方案的安全和隐私进行分析,并在以太坊平台上对其性能进行实验分析。关键词: 车联网 ; 数字取证 ; 区块链 ; 安全 ; 隐私1 引言近年来,随着车联网的发展,车辆内各种传感器和通信方式的更新换代使得车联网底层数据的实时获取和收集已不是难事[1]。同时,数据也推动了各类车联网服务的出现,如网约车服务[2]、路况监测[3]、停车位查找[4]和广告分发[5]等,这些服务巩固了车联网中数字世界与物理世界的纽带,也极大地提升了车联网用户的驾驶体验。诸多车联网服务发展的同时,也催生了大规模且有价值的车联网数据。据报道[6],预计在2030年仅司机数据就将成为万亿级工业的核心驱动力量,因为大数据清晰地展示了司机的驾驶行为,为广告商和保险公司带来了潜在价值,这些数据对研究人员更好地理解车联网特点、掌握车联网用户需求和提升车联网服务质量具有极大的推动作用。尽管车联网的发展给人们的出行带来了许多便捷,但是也不乏恶意用户甚至不法分子利用车联网的优势进行恶意行为或非法行为[7,8]。如在发生肇事类的交通事故时,非诚实的肇事司机会因为没有监控而逃脱法律责任;在汽车发生故障时,保险公司因司机未能给出由于汽车本身原因引起故障的证据,而无法对其进行赔偿;在网约车服务过程中,有恶意司机发动错误位置攻击,以欺骗网约车服务提供商,从而骗取更多订单[2];还有恶意司机会向路况监测服务中的路侧单元(RSU,road side unit)发送错误的驾驶信息,以干扰智能信号灯的正常规划[3]。近年来,有些不法分子利用汽车运输非法物品或者驱车逃离犯罪现场。国际刑事警察组织的官方定义指出,汽车犯罪指的是汽车盗窃与非法汽车交易以及汽车备用零件的非法交易。上述行为在全世界范围内对个人财产、商业活动、金融和公共安全都造成了负面影响[9]。为了解决以上问题,车联网数字取证(VDF,vehicular digital forensics)[10,11]的作用变得越来越重要,逐渐成为学术界及工业界重点关注的研究课题之一。VDF通过收集和分析车联网数据(如车速、转向、刹车、行车记录仪的视频等),帮助执法机构等相关部门及时确定相应的问题(如司机驾驶误操作、刹车片老化、车尾停车感应器失灵等)来源,对车联网中潜在的恶意行为和用户进行定位与追踪,降低了车联网的安全风险和用户损失。概括来说,将 VDF 分为 4 个步骤,即收集、检查、分析和汇报[12]。数据提供者上传数据的过程即数据收集过程,数据访问者对数据进行访问后需检查数据的真实性以及哪些数据与案件相关,并做深入分析,最终得出结论并进行汇报。此外,在 VDF 中,还存在一些安全和隐私问题。首先,基于集中式的取证模型面临恶意数据提供者或数据访问者篡改数据的风险,并且非法的数据访问者不能对取证数据进行访问。其次,数据提供者在上传数据(如录音或证词)时,不希望其真实身份被泄露,从而保护自身安全。最后,数据访问者在请求数据时,其访问权限必须被限制在一定的数据范围内,即数据访问者不能请求获得其访问权限以外的取证数据,实现数据隐私的进一步保护。本文工作的挑战来自两个方面:1) 如何利用区块链保障车联网证据的安全管理;2) 如何保障数据提供者和数据访问者的隐私与访问控制。为了解决上述两个问题,本文提出一种基于区块链的安全车联网数字取证(SVDF,secure vehicular digital forensics)方案。在SVDF方案中,数据提供者向一个证书中心(CA,certificate authority)注册后获得匿名证书,用于后续的数据上传;数据访问者注册后获得公私钥对和用户密钥,分别用于数据请求和数据解密,只有其属性满足特定要求才能解密得到正确的证据。可信度较高的若干个机构联合建立一个区块链,记录车联网取证过程中所有的数据上传交易和数据访问交易。同时,SVDF 方案将数据密文存储于分布式存储系统中,本文的贡献包括以下3个方面。1) 为VDF设计了一种系统模型,分别由底层的用户、中层的 RSU 和上层的组织机构组成,并建立了相应的敌手模型,假设存在恶意数据篡改者和恶意数据访问者。2) 在上述系统模型和安全模型的基础上,提出了SVDF方案。具体来说,借助匿名认证的方法[13]对数据提供者的真实身份进行条件隐私式验证,使用基于属性加密算法[14]对数据访问者的数据请求进行访问控制,再通过搭建联盟区块链[12]提供数据记录的可验证性和防篡改性。3) 对 SVDF 方案进行严格的安全与隐私证明,并通过以太坊测试网络对SVDF方案进行性能测试。2 相关工作区块链在车联网中已经有了初步应用和实践,本节主要分析区块链在 VDF 中的应用以及区块链在车联网其他场景中的应用。2.1 区块链在VDF中的应用Cebe等[12]指出,智能网联汽车服务将为汽车厂商、汽车维修公司、司机和保险公司提供有价值的数据,这些数据对于VDF具有重要作用。文献[12]中将VDF系统的数据处理模型划分为收集、检查、分析和汇报4个环节,为车联网数据管理提出了一种基于许可链的架构,结合了车联网公钥基础设施和区块链,用以实现车联网用户的身份管理和隐私保护。其中,许可区块链中有 4 种角色,即队长(leader)、验证者(validator)、监测者(monitor unit)和用户(client)。验证者在每个时间段内选出一个队长,根据拜占庭共识机制创建新的区块。用户使用IEEE 1609.2标准中的匿名机制,在不同时间段内使用不同匿名来汇报数据。然而,此方案并没有考虑访问控制问题,即不同的数据访问者可以访问的数据是不同的。2.2 区块链在车联网其他场景中的应用边缘计算已经被应用于车联网中,Kang 等[15]指出,边缘节点在车联网中扮演着重要的角色,但是其半可信的安全假设会导致潜在的安全与隐私问题。文献[15]中利用联盟区块链和智能合约设计了一种面向车联网数据的安全点对点数据共享方案,边缘节点根据存储证明(proof-of-storage)共识机制更新区块链。车联网中的广告分发服务帮助厂商和用户在车联网中及时地推广和获得最新的商品信息,Li等[5]为了解决广告分发过程中因恶意司机合谋攻击骗取奖励而引发的公平性问题以及司机参与广告分发活动的隐私泄露问题,提出了一种基于区块链的公平与匿名广告分发方案。通过使用Merkle哈希树和智能合约技术,实现了验证司机是否收到广告的“广告接收证明”机制和检测司机多次索取广告转发费的机制,RSU根据权益证明(proof-of-stake)共识机制维护区块链。智能停车是一种常见的车联网服务,Wang等[16]在利用私家停车位的智能停车服务[4]的基础上,提出了一种基于区块链的匿名智能停车方案。该方案使用分布式匿名证书机制对私家停车位所属人和司机的身份进行匿名认证,在一个停车位信息交换池中完成用户之间的停车位匹配后,借助门罗币的变种实现匿名支付,并在 RSU 节点之间实现区块链的更新和维护。与现有方案相比,本文提出的SVDF系统提供了一种面向车联网的安全证据管理系统,并充分考虑了数据利益方的隐私问题。3 结束语本文提出了一种基于区块链的SVDF方案,该方案可以实现车联网数据上传者的匿名身份认证和针对数据访问者的访问控制,并借助区块链记录所有数据上传和访问的记录,保证记录的公开可验证性和不可篡改性。同时,SVDF 还可以抵抗恶意数据上传者的篡改攻击和恶意数据访问者的非法请求。最后,对SVDF的安全属性与系统性能进行分析。在未来的工作中,将结合现有实际案例继续挖掘基于区块链的 VDF 中潜在的安全与隐私问题,并设计相应的保护措施。此外,区块链只能提供证据上链之后的不可篡改性,而暂时无法充分保证证据上链之前的真实性[24],所以接下来将在这方面做进一步的研究。The authors have declared that no competing interests exist.作者已声明无竞争性利益关系。4 原文链接http://www.infocomm-journal.com/wlw/article/2020/2096-3750/2096-3750-4-2-00049.shtml
  • [技术干货] 【论文分享】动态时空数据驱动的认知车联网频谱感知与共享技术研究
    动态时空数据驱动的认知车联网频谱感知与共享技术研究郭彩丽1,2, 陈九九1, 宣一荻1, 张荷11 北京邮电大学,北京 1008762 先进信息网络北京实验室,北京 100876摘要随着全球汽车产业智能化和网联化的爆发式发展,作为车联网重要支撑的通信技术面临着频谱资源紧缺的难题。除了提供安全服务以外,车联网服务需求的多样性使得引入认知无线电技术成为有效的解决途径,可以实现与授权用户共享sub-6 GHz和毫米波的异质频谱资源,但车联网复杂动态变化环境的影响使得频谱利用率性能的提升受限。提出了充分利用潜在的多源动态时空数据挖掘和学习车辆轨迹、交通流的变化规律的方法,并利用其规律指导频谱的感知和共享。通过搭建系统级仿真平台进行仿真分析,结果表明所提方案的频谱效率得到有效提升。关键词: 车联网 ; 动态时空数据 ; 异质频谱共享 ; 多服务的服务质量要求1 引言随着通信技术、信息技术和汽车工业的发展,以智能化和网联化为特征的智能网联汽车已成为汽车产业发展的必然方向,作为网联化代表的车联网是实现智能网联汽车的支撑技术。特斯拉发生交通事故表明,在相当长时期内,车辆的智能化难以做到完全替代人的决策,需要基础设施的配合,尤其需要车联网的必要技术帮助实现车—车(V2V,vehicle to vehicle)、车—路、车—人、车—云之间的通信和信息交换。据咨询公司埃森哲预测,在2025 年全球新车市场中,网联汽车的渗透率将从2015年的35%增至100%,即所有新车都将具备联网功能。由此可见,车联网将逐渐成为全球研究和关注的热点。通信技术是车联网的关键技术,决定了车联网信息传输的实时性和有效性,是车联网的“命脉”。目前,世界上用于车联网通信的主流技术包括专用短程通信(DSRC,dedicated short range communication)技术和基于蜂窝移动通信系统的 C-V2X (cellular-vehicle to everything)技术,其中,C-V2X技术包括LTE-V2X和5G NR-V2X。无线电频谱资源归国家所有,是具有重要战略意义的稀缺资源,实现智能网联汽车通信的前提条件之一就是要有充足的频谱资源作为支撑。但目前分配给DSRC技术和 C-V2X 技术的专用频谱资源均有限,如美国联邦通信委员会(FCC,Federal Communications Commission)分配给DSRC技术的频段仅为75 MHz (5.850~5.925 GHz);我国将20 MHz(5.905~5.925 GHz)的频段作为基于LTE-V2X技术的车联网直连通信的工作频段。为车联网分配专用频谱资源的主要目的是满足辅助驾驶、防碰撞、车道偏离预警、驾驶员疲劳检测等安全类服务的高可靠、低时延通信需求。随着以自动驾驶为代表的汽车产业的兴起,人们对智能网联服务的需求呈现多样化特点,包括交通效率类(如事故、路障和拥堵提醒等服务)、车辆信息类(如智能汽车支付、车辆诊断等服务)和车载娱乐类(如多媒体音/视频等服务)等各种非安全类服务[1]。随着上述非安全类服务的爆发式增长,对频谱的需求量迅速增加。鉴于大部分非安全类服务对通信可靠性和时延的要求比安全类业务要求低的客观事实,已有研究[2,3,4,5]指出,在车联网中采用认知无线电技术,即组建认知车联网,通过感知授权用户的空闲频段并与用户共享此频段,为解决车联网中的频谱资源不足问题提供了有效的解决途径。因此,车联网中服务的多样性使得采用认知无线电技术进行频谱感知和共享成为可能。随着辅助驾驶技术的发展,尤其是自动驾驶时代的到来,为了更好地满足多种服务的需求,车辆将配备大量高清摄像头和激光雷达等高精度传感器,这些传感器通常需要将收集的大量数据上传至数据处理中心进行处理。据预测,每辆自动驾驶模式的汽车消耗数据流量的速度为5 Tbit/h,数据平均传输速度为1.4 Gbit/s。日益紧缺的频谱资源已不能满足多种服务对带宽的需求,频谱供求矛盾更尖锐。为了缓解上述矛盾,现有研究考虑在共享传统sub-6 GHz 频段的基础上,将具有丰富资源并且传输性能高的毫米波频段引入认知车联网通信[6,7],传统sub-6 GHz 频段有广播电视白频段(TVWS,TV white spectrum)、DSRC 频段、蜂窝频段等。通过上述研究, sub-6 GHz和毫米波等多个异质频段均可以实现共享,为自动驾驶时代的认知车联网提供了充足的通信保障。综上所述,为了缓解车联网频谱资源紧缺导致的供求矛盾,车联网服务需求的多样性使得引入认知无线电技术成为解决车联网频谱资源紧缺问题的有效途径,可以实现与授权用户共享sub-6 GHz和毫米波的异质频谱资源。认知车联网通信示意图中,V2X通信可复用传统蜂窝频段和毫米波频段。车辆或路边单元执行具有不同用户服务质量(QoS,quality of service)要求的业务,如车辆间转向、变道信息共享的协作碰撞避免信息传输业务(CAITS,collision avoidance information transmission service),车辆行驶轨迹、驾驶意图、传感器数据交互的自动驾驶信息传输业务(ADITS,automatic driving information transmission service)等。其中, CAITS 关注信息传输的实时性和可靠性,ADITS 数据量大,在一定的时延容忍范围内更关注吞吐量。2 结束语本文针对认知车联网面临的高时空动态变化环境挑战,提出了利用车辆轨迹和交通流的预测结果,设计支持异质频谱和多样性服务的频谱感知和共享算法。仿真结果表明,车辆轨迹和交通流的预测以及基于预测结果的异质频谱的感知和共享可有效提升频谱效率,并能够满足多业务的 QoS 需求。后续工作将主要研究基于车辆轨迹数据和交通流数据统一表示的轨迹和交通流预测方法以及自适应 QoS 的频谱感知模型和算法。The authors have declared that no competing interests exist.作者已声明无竞争性利益关系。3 原文链接http://www.infocomm-journal.com/wlw/article/2020/2096-3750/2096-3750-4-3-00096.shtml
  • [技术干货] 【论文分享】车联网中安全认证技术的分析与研究
    车联网中安全认证技术的分析与研究王曼竹1, 李梓琦1,2, 陈翌飞1, 洪高风1, 苏伟11 北京交通大学电子信息工程学院,北京 1000442 北京工业大学城市建设学部城市交通学院,北京 100124摘要目前,车联网安全认证技术并不能很好地抵御车联网环境下的各种攻击,且在平衡安全和性能方面也存在缺陷。在深入分析车联网研究现状和安全威胁的基础上,提出了基于层次化的车辆—车辆(V2V, vehicle-to-vehicle)安全认证方案,并进一步提出了基于多个可信第三方的 L 型安全认证方案。所提方案更适合用于车联网环境,旨在保障汽车通信过程的信息安全,防止通信数据被不法分子窃取和篡改等。关键词: 车联网 ; 安全认证 ; V2V安全认证方案 ; L型安全认证方案1 引言随着物联网技术的发展和人们对无人驾驶领域的不断探索,车联网(IoV, Internet of vehicles)已成为当前热点话题之一。车联网即V2X(vehicle to everything)系统,是车辆—车辆(V2V, vehicle-to-vehicle)、车辆—基础设施(V2I, vehicle-to-infrastructure)、车辆—网络(V2N, vehicle-to-network)和 车 辆 — 行 人(V2P, vehicle-to-pedestrian)通信的统称。车联网主要由车载单元(OBU, on board unit)和路侧单元(RSU, road side unit)两部分组成,两者都具有较强大的运算性能。OBU 是装载在车辆上的无线计算单元;RSU是安装在城市道路两边的通信及计算机设备,其功能是与 OBU 共同完成实时的高速通信,并通过有线设备连接在骨干网络上。在许多交通场景中, V2V和V2I这2种模型经常组合使用,主要采用专用短程通信(DSRC, dedicated short range communication)技术。DSRC是一种可以实现双向无线传输的高效通信技术,通过V2V和V2X的连接,可以在小范围内实时、准确且可靠地传输图像、语音和数据[1]。近年来,车联网在世界各国呈现快速发展态势。2018年美国5G白皮书《面向5G的蜂窝式V2X通信》指出,随着电子技术、传感技术和计算机技术的飞速发展,车辆V2X通信正在逐步成为现实[2]。中国通信学会的《车联网安全技术与标准发展态势前沿报告(2019)》[3]对车联网安全技术在我国以及全球的发展态势做出了分析,报告认为车联网产业已上升至国家战略高度。为了顺应“互联网+智能交通”的发展,我国车联网技术也正在与“北斗 +5G”等自主关键技术进行创新融合[4]。同时,针对车联网技术的快速发展,各国也相继出台了各类标准和政策,如2006年,美国发布了IEEE 1609.2标准,专注于 V2V 安全应用和单跳 V2I 通信;欧洲电信标准协会开发了 V2X 的欧洲规范;新加坡、日本等国家也在开发V2X智能交通系统规范[5]。车联网在未来交通中有至关重要的作用,如何保障车联网的安全性非常关键。中国通信学会的《车联网安全技术与标准发展态势前沿报告(2019)》指出,我国车联网未来可能出现的集中式管理架构和分布式管理架构都需要保证极高的安全性。目前,当车辆通过DSRC或5G接收来自RSU或者基站的控制信息时,对信息的认证工作还不够完善。非法入侵者极有可能影响车辆的智能驾驶,产生安全问题。针对此问题,国内外学者从不同角度提出了安全认证方案。Vijayakumar 等[6-7]提出了双重认证和密钥管理技术,用于在车联网中安全传输数据;Boneh 等[8]利用椭圆曲线上的双线性建立了高效的基于身份标识号(ID, identity document)的加密方案;Lu 等[9]提出了一个基于身份的在线/离线签名认证框架;谭杰等[10]在离散对数的知识签名技术理论基础上提出了基于知识签名的快速身份认证协议;陈葳葳等[11]利用区块链技术的防篡改和分布式特性,基于公钥基础设施(PKI, public key infrastructure)体制提出了基于区块链的快速匿名身份认证方案。然而,上述安全认证方案存在各自的问题。如集中式的经典PKI证书管理方案虽能实现匿名认证,但车辆数量增加后会产生较长的处理时延;基于知识签名的快速身份认证协议能使载有OBU的车辆通过RSU快速加入车联网,但同一区域OBU数量激增会影响RSU对OBU的准确认证,甚至使系统瘫痪,在提高认证速率的同时没有考虑安全性;基于区块链的快速匿名身份认证方案能有效利用区块链技术的防篡改、分布式特性实现高效的安全认证,但其安全性过度依赖存入同一区块链的车辆身份信息,没有考虑未来不同品牌车辆可能会有不同的区块链,没有加入更多的可信第三方。上述问题使现有安全认证技术不能更好地适用于车联网环境。本文对车联网环境中存在的安全威胁进行分析,着眼于信息安全与隐私保障策略,提出了基于层次化的 V2V 安全认证方案,并进一步提出了基于多可信第三方的L型安全认证方案。基于层次化的安全认证模型是一种更高效的认证体系,有可信第三方参与的双向安全认证可以更好地保障车辆通信安全;L型安全认证方案则拥有多个可信第三方,进一步提升了安全性。2 结束语车联网作为具有广阔发展前景的一种移动自组织网络,保障通信过程的安全性及可靠性是至关重要的。在通信过程中,需要对通信双方的身份进行认证,并对传输过程进行加密。通过可信第三方对身份进行认证,车辆可任意选择通信对象,在与其建立连接前要确定对方的合法身份,并基于非对称密码体系进行保密通信。由于车辆位置分布较广泛,对可信第三方的管理可基于层次化结构。考虑日益增长的车联网用户数量,若进一步提升安全性,可将唯一可信第三方更改为双可信第三方,通过对 L型安全认证方案的应用来保障通信过程的安全。3 原文链接http://www.infocomm-journal.com/wlw/article/2021/2096-3750/2096-3750-5-3-00106.shtml
  • [技术干货] 【论文分享】结合聚类与CMAB的群智感知车联网任务分配方法
    结合聚类与CMAB的群智感知车联网任务分配方法冯心欣, 郭丹颖, 柳泽烽, 郑海峰福州大学物理与信息工程学院,福建 福州 350108摘要基于车联网(IoV, Internet of vehicles)用户的群智感知网络具有节点覆盖广泛、数据全面及时等优点。该技术实现的一大难点在于,如何通过充分挖掘和利用车联网用户的信息(如用户地理位置等)来选择合适的感知任务参与者,以合理地进行任务分配,进而提高感知任务的完成质量和任务发布者收益。为此提出了一种结合车辆用户轨迹特征与组合多臂赌博机(CMAB, combinatorial multi-armed bandits)算法的群智感知用户任务分配机制。首先,基于用户历史行车轨迹的相似程度,将用户聚类。然后,利用 CMAB 模型,将轨迹聚类信息作为用户任务分配的依据,求解最佳工作者组合。最后,利用真实出租车轨迹数据集对上述算法进行了验证。实验结果表明,考虑轨迹特征信息的任务分配算法具有更高的准确率,并能使任务发布者获得高收益。同时,所选出的工作者集合有相近的行车轨迹,对于同一地点的任务具有高的完成质量,能有效提高感知数据质量和任务发布者收益,适用于实际应用场景。关键词: 群智感知 ; 车联网 ; 组合多臂赌博机模型 ; 轨迹聚类 ; 任务分配1 引言随着嵌入式设备的更新和互联网覆盖范围的扩大,智能城市[1]的社会感知活动已成为信息和通信领域的研究热点。群智感知技术代替了传统传感网络,规避其缺陷,使传感更实时、便捷和低成本[2-3]。在与群智感知相关的研究中,任务分配是目前国内外学者研究的核心问题之一,该方面的研究主要分为任务自主选择和任务协调分配两类[4-5],易存在参与感知任务的用户技能水平不高、感知数据质量差的问题。因此,在任务分配环节引入合适的算法进行工作者技能水平筛选,并根据筛选结果进行感知任务分配,可以大大提高感知数据的质量。作为一种新型的动态随机控制模型,具有强大的学习能力的多臂赌博机(MAB, multi-armed bandit)是解决上述问题的方案之一[6]。但是,经典的MAB框架中存在从某些臂观察到的信息被丢弃的问题,导致效率降低。为解决上述问题,进一步提出了CMAB框架,以解决在随机环境中的组合在线学习问题[7]。群智感知车联网(IoV, Internet of vehicles)系统,是群智感知技术在车联网领域的一个典型应用。通过多领域技术协同工作,利用车辆用户携带的移动终端设备,完成交通数据收集等感知任务,进而达到数据预测、监测车辆和交通状况等目的[8-9]。与传统群智感知网络相比,群智感知车联网具有如下特点:(1)其典型任务往往与地理位置紧密相关[10],比如进行特定位置交通拥堵状态预测、特定区域地图绘制等。(2)车辆用户具有移动性和一定随机性,故任务分配者通常无法提前获得用户相关的先验知识,如用户类型、用户能力、用户忠诚度等,导致传统任务分配方法失效。因此,在IoV系统中进行任务分配,需要兼顾车辆用户的地理位置以及任务要求的地点、完成时间等多方面的因素,并设法深入挖掘用户信息进行感知用户筛选。利用IoV中的海量轨迹数据挖掘车辆行驶的潜在规律,如对具有相似行车轨迹的用户进行聚类,并将其结果应用于用户筛选中,可以在保证感知精度的同时,大大降低感知成本。本文提出了一种结合车辆轨迹特征与 CMAB算法的群智感知用户任务分配机制,通过挖掘群智感知车联网用户的历史轨迹信息,将具有相同或相似轨迹的用户聚集在同一个簇类中,并基于此轨迹特征结合 CMAB 算法设计任务分配机制,以达到提高感知数据质量和任务发布者收益的目的。2 结束语本文针对群智感知车联网任务分配问题,考虑用户轨迹信息,提出了一种结合轨迹特征与CMAB模型的群智感知用户任务分配机制。并基于真实出租车轨迹数据集对该机制进行验证。由实验结果可知,结合轨迹特征和 CMAB 模型的任务分配算法所选出的工作者集合具有相同或相似程度高的历史轨迹,对于同一地点的任务具有较高的完成质量,适用于实际应用场景。仿真结果表明,考虑轨迹特征的任务分配策略相对于没有考虑轨迹特征的任务分配策略其后悔值有所降低,准确率有所提高,并更早、更快地趋向于稳定,从而实现提高感知数据质量以及任务发布者收益的目的。但是本文研究的基于 CMAB 理论的群智感知任务分配算法仍然存在一定的改进空间,下一步的研究工作是引入任务发布者预算等实际影响因素,将其纳入数学模型进行最优工作者组合求解。同时,考虑进一步降低算法的复杂度并将本文算法运用于其他场景中,以提高其应用价值。3 原文链接http://www.infocomm-journal.com/wlw/article/2021/2096-3750/2096-3750-5-3-00086.shtml
  • [技术干货] 【论文分享】面向车联网的认知雷达通信复合波形设计
    面向车联网的认知雷达通信复合波形设计姚誉1, 李妍洁1, 吴乐南2, 苗圃3, 唐小渝11 华东交通大学信息工程学院,江西 南昌 3300312 东南大学信息科学与工程学院,江苏 南京 2100963 青岛大学,山东 青岛 266000摘要介绍了认知雷达通信(CRC)收发器的系统架构,提出了一种认知雷达通信复合波形的设计方法。此方法旨在从雷达场景中估计目标散射系数(TSC),同时实现高速率数据通信。为了降低TSC的均方误差(MSE),建立了在实际雷达系统多约束条件下的认知复合波形优化模型。通过基于卡尔曼滤波的方法设计超宽带(UWB)传输脉冲集,并利用多元位置相移键控调制技术(MPPSK)将信息数据嵌入其中,从而实现峰均功率比(PAPR)约束的最佳解决方案。实验结果证明,随着迭代次数的增加,TSC 估计和目标检测概率均有所提高。同时,在CRC收发系统之间仍能够以低误码率和速率为几Mbit/s的范围内传输数据。关键词: 雷达通信网 ; 目标检测 ; 超宽带 ; 车联网 ; 认知波形设计1 引言随着无线通信技术、车载雷达技术和汽车工业的发展,以智能化和网联化为特征的智能网联汽车已成为汽车产业发展的必然趋势,作为网联化代表的车联网是实现智能网联汽车的支撑技术。与此同时,雷达和无线通信技术中的射频前端架构变得越来越相似,可以很容易地用于通信和雷达应用的联合射频硬件平台,雷达任务和通信应用之类的多功能集成引起了研究者们极大的兴趣,从而引出了一系列研究方案[1,2,3,4],雷达和通信一体化的研究方案为车联网发展提供了一种新的设计思路,特别是要求同时实现车联网通信和环境感知的智能交通应用领域[5]。合适的系统平台能够让道路上的所有车辆都可以在协作雷达传感器网络中交互,提供独特的安全功能和智能交通路线。雷达通信一体化系统要比只有车-车通信功能的系统更容易引入市场。由于车-车通信系统只能在通信对象在场时传输信息,因此在市场引入时,客户可能不会有太多的意愿配备只有车-车通信功能的系统。然而,雷达通信一体化系统由于其雷达传感功能,不受太阳光、雨、雪、雾等复杂天气的影响,对交通环境进行全天时、全天候的测量感知,被誉为智能汽车的“火眼金睛和顺风耳”。此外,雷达通信一体化系统中两个应用也能互相从共享信息中获益。例如,雷达应用可以利用分布在通信网上的信息提高其检测概率和测距精度。当下雷达通信一体化研究的主要挑战在于找到可同时用于信息传输和雷达感知的复合发射波形,通过复合波形的设计,频谱将得到非常有效的利用,有助于克服频谱资源有限的问题。当前,雷达通信复合波形的设计可以分为两大类。一类是基于复用技术的设计,包括空分复用(SDM, space division multiplexing)[6]、时分复用(TDM, time division multiplexing)[7]、频分复用(FDM, frequency division multiplexing)[8]和码分复用(CDM, code division multiplexing)[9],但这类设计都有共同的缺点,即雷达和通信不能在某个领域同时工作。如时分复用技术,雷达和通信无法在同一时隙工作。另一类则是基于波形共享的设计,此类设计分两种情况:一种是通信信息被隐藏在传统雷达波形中[10],另一种是普遍使用的通信波形有轻微变化或者没有变化[11]。在通信中,传统的正交频分复用(OFDM, orthogonal frequency division multiplexing)波形一般是连续的[12,13,14],而脉冲雷达恰恰相反。此外,雷达中大多数采用的OFDM波形由OFDM脉冲序列组成,这种序列是通信中必不可少的,其中一个脉冲只包含一个OFDM符号。若集成的雷达和通信系统采用连续OFDM波形,则需要接收与发送天线远远分离,这在实际中很难实现,尤其是在收发天线彼此靠近的情况下。如果系统采用的OFDM波形是脉冲,则可以共享收发天线,天线的数量将减少一半,收发天线间的隔离问题也迎刃而解。然而,对通信应用而言,在雷达占空比为10%时,通信的作用时间变为原来的10%的情况下,通信数据速率将会下降。这些集成的雷达和通信系统采用了与超宽带(UWB, ultra wide band)技术相结合的OFDM技术,实现了通信雷达一体化设计。但这也产生一些实现上的问题,例如对信号处理能力的要求过高以及对高速模数转换电路、多模式操作射频前端的过度需求。此外,采用 UWB-OFDM 技术定位的系统[13-14]利用相同的波形簇来设计雷达通信复合信号。由于 UWB-OFDM 信号的自相关性取决于陷波的位置和OFDM信号的带宽,这些方法都有共同的缺点。尽管雷达目标距离估计不受OFDM信号的影响,但其距离分辨率取决于嵌入OFDM 信号的陷波带宽。文献[15]提出了采用UWB脉冲位置调制(PPM, pulse-position modulation)设计通信雷达复合信号的系统,但与传统OFDM系统相比,传统系统误码率(BER, bit error ratio)性能相对较差[16-17]。认知雷达(CR, cognitive radar)系统可以根据目标和环境的先验知识来自适应地调整其发射波形和接收滤波器,因此,在增强对扩展目标的检测和识别性能方面,该系统有很大的潜力[18]。在CR[19]系统中,认知在反馈回路中起着重要作用,认知包括长期记忆,如地理地图、海拔模型以及接收器在线开发的短期记忆。通过使用先验信息,CR 系统可以优化CR的工作模式、发射波形和信号处理方法,由此可以获得更好的性能。宽带认知雷达对主动和被动干扰不敏感[20],但在实际驾驶场景中也存在由自身发射信号引起的相关杂波干扰、邻近车载雷达产生的信号干扰和两者的混合干扰,传统雷达波形优化方法尚未考虑智能交通应用场景下的干扰。在宽带认知雷达系统中,扩展目标经过系统会产生复杂的目标冲击响应(TIR, target impulse response)[21],这就是频域中的目标散射系数(TSC, target scattering coefficient)[22]。在最近的雷达系统研究中,TSC的估计受到了广泛关注[23,24,25]。文献[23]将扩展目标建模为时不变TIR函数模型,文献[26]考虑目标视角的变化及在脉冲间隔内 TSC 的强相关性,将扩展目标建模为广义平稳不相关散射TIR模型。其中,干扰可能包括杂波和噪声,杂波是与信号相关的,如多余的地面回波和环境杂波,而噪声则是与信号不相关的[27]。另外,周围环境的雷达反射特性是不变的。为了获得高功率的传输,有学者提出了恒包络的认知波形设计方案。文献[28]提出了在恒定包络约束下的OFDM优化波形设计方法,但是恒定包络条件在OFDM波形设计中过于严格。在峰均功率比(PAPR, peak to average power ratio)约束下的OFDM雷达系统中,PAPR以松弛形式给出[12]。如果发送信号功率很小,估计精度可能会急剧下降,无法估计目标 TIR 的功率谱密度(PSD),这是文献[29]中的算法不能直接用于 CR 波形设计的主要原因。为了解决此问题,应在CR传输波形中考虑TSC估计的性能,由此研究了一种用于估计和检测CR 波形设计的新算法。在一个较长的时间段内,可以在波形设计中得到杂波的先验知识[30]。在脉冲持续时间内,可以近似地认为具有文献[31]中的时不变性,但TIR在实际工程中会逐渐变化,且TSC随雷达和目标之间的相对运动而变化,因此需要TSC估计更新作为反馈信息。Dai 等[32]提出了一种基于卡尔曼滤波(KF, Kalman filtering)的迭代方法估计单个目标的TIR。文献[33]对传输波形进行了优化以改善估计性能,然而在时间相关的认知雷达系统(CRS, cognitive radar system)中,波形设计的直接优化问题是非凸的,且此问题无法有效解决。考虑多目标场景,文献[34-35]提出了一种多波形设计算法,该算法的基本思想为基于目标的TIR与雷达波形的互信息最大化。文献[36,37,38]提出了多输入多输出(MIMO,multiple-input multiple-output)雷达系统波形设计的相关内容,论述了最大化互信息和最小化均方估计误差(MSE, mean square error)之间的等效性。就目前而言,只有基于注水原理的方法可以优化单个目标发射波形的功率谱密度[13],现有的研究并没有在时间相关的 CRS 中对多个扩展目标的发射波形进行直接优化。综上所述,现有的雷达通信复合波形设计方法尚未考虑车载平台和车联网环境的特点,对于通信功能而言,无法同时保证高传输速率和良好的抗多径衰落性能。此外,考虑实际雷达系统对算法复杂度和多种因素的要求,如发射功率、PAPR、信干噪比等,传统认知雷达波形优化方法的目标检测和估计性能难以获得有效提升。因此,本文将文献[22]中提到的时间相关认知算法与多元位置相移键控调制(MPPSK, multiple position phase shift keying)技术[26]结合,提出了一种基于MPPSK的雷达通信复合波形设计方案,此复合波形能使认知雷达通信(CRC, cognitive radar-communication)收发器获得优越的雷达性能和高速率通信能力。雷达和通信信号可以通过共享相同的频带而共存。在此基础上,提出一种基于 KF的TSC估计方法和复合发射波形优化方法,在不影响通信性能的前提下,进一步提高系统的交通环境感知能力。同时,雷达目标参数估计性能也不受通信信号参数设计的影响。本文所提出的复合波形设计和优化方法解决了雷达通信一体化技术应用于车联网场景中的关键问题。2 结束语本文研究了 CRC 收发系统的复合波形设计概念,该系统允许同时进行无线通信和雷达目标检测。针对复合波形设计,提出了一种新的UWB-MPPSK调制方案。为了提高目标估计性能,提出了一种基于KF的波形优化方法。该方法通过不断学习探测环境,调整传输波形适应动态变化的目标场景。这种实现方式在雷达应用方面有许多优势,尤其是具有更好的TSC估计性能,还可以保证传输时用户数据的独立性。该方法还为通信应用提供了较高的数据传输速率。本文讨论的复合波形设计概念为未来智能交通系统中传感器设备的实现提供了独特的视角。3 原文链接http://www.infocomm-journal.com/wlw/article/2021/2096-3750/2096-3750-5-4-00071.shtml
  • [行业资讯] 车联网、物联网、RFID等知识普及
    汽车数字化标准信源技术是基于RFID开发的涉车信息资源的应用技术,该项目是由国家公安部组织研发,经国家科技部认证后列为2007年“国家科技支撑计划”重点专项中进行的应用示范工程(项目编号为2008BAF31B00)。汽车数字化标准信源技术的开发将推进“车联网”和RFID产业化进程。车联网分析 车联网(IOV:Internet ofVehicle)是物联网在汽车领域的一个细分应用,是移动互联网、物联网向业务实质和纵深发展的必经之路,是未来信息通信、环保、节能、安全等发展的融合性技术。车联网(IOV:Internetof Vehicle)是指车与车、车与路、车与人、车与传感设备等交互,实现车辆与公众网络通信的动态移动通信系统。它可以通过车与车、车与人、车与路互联互通实现信息共享,收集车辆、道路和环境的信息,并在信息网络平台上对多源采集的信息进行加工、计算、共享和安全发布,根据不同的功能需求对车辆进行有效的引导与监管,以及提供专业的多媒体与移动互联网应用服务。从网络上看,IOV系统是一个“端管云”三层体系。第一层(端系统):端系统是汽车的智能传感器,负责采集与获取车辆的智能信息,感知行车状态与环境;是具有车内通信、车间通信、车网通信的泛在通信终端;同时还是让汽车具备IOV寻址和网络可信标识等能力的设备。第二层(管系统):解决车与车(V2V)、车与路(V2R)、车与网(V2I)、车与人(V2H)等的互联互通,实现车辆自组网及多种异构网络之间的通信与漫游,在功能和性能上保障实时性、可服务性与网络泛在性,同时它是公网与专网的统一体。第三层(云系统):车联网是一个云架构的车辆运行信息平台,它的生态链包含了ITS、物流、客货运、危特车辆、汽修汽配、汽车租赁、企事业车辆管理、汽车制造商、4S店、车管、保险、紧急救援、移动互联网等,是多源海量信息的汇聚,因此需要虚拟化、安全认证、实时交互、海量存储等云计算功能,其应用系统也是围绕车辆的数据汇聚、计算、调度、监控、管理与应用的复合体系。值得注意的是,目前GPS+GPRS并不是真正意义上的车联网,也不是物联网,只是一种技术的组合应用,目前国内大多数ITS试验和IOV概念都是基于这种技术实现的。车联网概念 车联网系统,是指是利用先进传感技术、网络技术、计算技术、控制技术、智能技术,对道路和交通进行全面感知,实现多个系统间大范围、大容量数据的交互,对每一辆汽车进行交通全程控制,对每一条道路进行交通全时空控制,以提供交通效率和交通安全为主的网络与应用。ITS即智能交通。是将先进的传感器技术、通信技术、数据处理技术、网络技术、自动控制技术、信息发布技术等有机地运用于整个交通运输管理体系而建立起的一种实时的、准确的、高效的交通运输综合管理和控制系统。RFIDRFID,是Radio Frequency IdenTIficaTIon的缩写,即射频识别。它通过射频信号自动识别目标对象并获取相关数据,识别工作无须人工干预,可工作于各种恶劣环境。RFID技术可识别高速运动物体并可同时识别多个标签,操作快捷方便。基本的RFID系统由标签(Tag)、阅读器(Reader)、天线(Antenna)。RFID技术有着广阔的应用前景,物流仓储、零售、制造业、医疗等领域都是RFID的潜在应用领域,另外,RFID由于其快速读取与难以伪造的特性,一些国家正在开展的电子护照项目都采用了RFID技术。RFID具有车辆通信、自动识别、定位、远距离监控等功能,在移动车辆的识别和管理系统方面有着非常广泛的应用。
  • [行业资讯] 上平台!车联网智能化晋级高段位!
    随着物联网的快速发展,车联网产业不断创新和突破,智能化与网联化升级增速。车联网的数据融合、数据价值、数据安全等智能场景都建立在数据采集的基础之上,如何对上千万机动车的数据进行多个维度的准确采集,如何使数据互通赋能业务应用成为车联网晋级智能化高阶段位的刚需。理想很丰满,现实很骨感,行业痛点愈加明显当前,车联网商业智能化应用的成熟度还不够,暴露出几大行业痛点:1、大部分传统车联网应用平台架构不同,基础设施滞后,升级维护困难,导致汽车故障时常发生。2、各厂商品牌各自为营,平台分散,软硬件没有统一标准,无法集成,导致产品难以互通互联。3、数据量过大时,应用响应速度异常缓慢,没有一个综合的应用平台,就连数据采集分析也成了挑战。4、由于汽车智能达不到预期效果,在用户体验上并没有达到理想的车联网状态。一套综合性智能化的车联网管理平台成为提速车联网智能化发展的引擎。以AIRIOT物联网低代码平台做技术和产品支撑的“航天智慧车联网综合服务云平台” 腾空问世!“航天智慧车联网综合服务云平台”提速车联网智能化发展航天智慧车联网综合服务云平台通过多个应用服务,完善配套整个车辆管理的全过程,实现全面监控,提升应用系统的响应效率,灵活部署的效率,实现一个平台多方数据的集成管理,保证车辆的精准监控,警报提示,增加了车辆的安全性。GIS实时显示车辆信息:GIS的综合信息服务平台左侧以公司为一级目录,显示平台中的车辆数,点击相应的车辆,右侧GIS模块实时显示车辆的位置、行驶轨迹信息,可以在地图上设置电子围栏,保证车辆行驶的可控性,通过点击车辆图表,可以查看该车辆的具体信息,包括车牌号、终端ID、行驶速度、车组名称等。自定义报表:以AIRIOT物联网低代码平台实现用户自定义报表功能,数据的展现不需要代码编辑,只需要通过选择即可,同时报表编辑时,支持用户进行公式编辑,满足了用户对于数据报表的要求,可高效完成报表编辑,节约了大量时间成本与人力成本。以AIRIOT物联网低代码平台作为底层技术构建的“航天智慧车联网综合服务云平台” 被某部委认定为全国首批符合部颁标准的省级政府监管平台之一,在全国31个省级平台中第一个接入全国重点营运车辆联网联控系统,也是全国第一个入网北斗终端数量过万的平台与通过省级科技成果鉴定的北斗平台。目前接入北斗车载终端超过26万台,是国内最大的北斗车联网平台之一,为政府部门执法取证和运输企业安全高效运营提供了大数据支持,有力保障了道路运输安全。