中国汽车工程师之家--聚集了汽车行业80%专业人士 

论坛口号:知无不言,言无不尽!QQ:542334618 

本站手机访问:直接在浏览器中输入本站域名即可 

搜索附件  
汽车工程师之家 附件中心 结构原理专业知识特区 『自动驾驶-辅助驾驶』 万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w28.jpg
左侧广告
附件中心&附件聚合2.0
For Discuz! X2.5 © hgcad.com

万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w28.jpg

 

万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行:
我们经常看到类似于“L2+”,“L2++”,“L2.9”,“L2.99”的自动驾驶等级的表述,这些功能一般是指可以自主变道、自动上下匝道的NOA、记忆行车、通勤模式等功能。然而,如果按照行业规范的定义,其实这些功能均是标准的“L2”级别功能。

“L2.99”从功能上看起来和“L3”类似,但是其实两者从系统设计的角度,差别巨大。

如果借用郭德纲老师的比喻,“L2.99”和“L3”的区别可做如下类比(略有夸张,仅为了形容差别):



2023年11月17日,四部委(工业和信息化部、公安部、住房和城乡建设部、交通运输部)发布《关于开展智能网联汽车准入和上路通行试点工作的通知》。随后,宝马、奔驰、极狐、智己、阿维塔、长安等纷纷官宣拿到测试牌照。



图片来源:https://new.qq.com/rain/a/20231227A08IT100

L3级自动驾驶,正在成为自动驾驶系统竞争的制高点。

为了帮助大家更好的理解L3自动驾驶系统,特组织本文做一下介绍,也作为上一篇文章《雪岭·自动驾驶(1/10):系统架构》的补充。

本文主要包括如下内容:


    L3的设计需求;

    L3的冗余设计模式;

    L3的工作过程;

    L3的设计方案;


01

L3的设计需求

安全,永远是自动驾驶系统设计的第一要求。

自动驾驶的安全主要是考虑2点:


    当系统没有失效时,如何保证安全,即预期功能安全SOTIF(ISO21448);

    当系统存在失效时,如何保证安全,即功能安全(ISO26262);


L3系统在激活之后(驾驶员未接管前),安全责任将由L3系统承担,因此L3系统的安全设计需求远高于L2。

根据ISO21448的描述,预期功能安全技术通过一系列确认和验证手段,探测和发现系统感知、逻辑决策、功能执行中的非失效不足,通过功能改进,使自动驾驶车辆在预期使用工况下达到合理安全水平的技术。

如下图所示,在L3系统开发的过程中,通过完善的设计和充分的测试,使得“未知不安全”区域尽量小,以达到“合理安全”。



1)如何定义“合理安全”?

那么对于L3来说,具体达到什么程度才算是“合理安全”的水平呢?

参考埃隆马斯克的建议,自动驾驶系统的安全性需要比人类驾驶员安全10倍(数据来源:https://www.thepaper.cn/newsDetail_forward_14545325)。

根据Waymo的统计,人类司机的事故率是每百万英里2.78起事故,即每57.8万公里1起事故。(数据来源:https://zhuanlan.zhihu.com/p/673632392)

所以,如果按照上面逻辑推断,自动驾驶系统需要达到每578万公里1次事故,才达到“合理安全”的水平。

2)2023年DMV接管数据

美国加利福尼亚州交通管理局(DMV)公布的2023年接管数据如下。其中CRUISE、Zoox和奔驰没有发生接管,最高里程是约94万。其他有接管的数据中,平均接管率是每次1410公里。

而每一次接管可能意味着不接管而导致的一次事故,因此该接管率距离578万一次的“合理安全”水平,还相距甚远。



图片来源:Vehicle,https://new.qq.com/rain/a/20240303A08H5500

并且,DMV统计的车辆一般运行在特定区域内,区域内交通状况不太复杂,同时,这些自动驾驶汽车往往是安装了数倍于量产车的感知模块和大算力控制单元,而这些硬件目前是无法应用于量产车的。
根据加州DMV的数据,将近6562次介入中,总结出了305种问题,其中有超过5400多个问题被总结归类为24个,其中出现前十大问题是:


    预测其他交通参与者行为错误导致介入。

    硬件诊断报告故障,提示干预。

    软件诊断报告故障,提示干预。

    车辆存在路上风险,安全员介入。

    地图与实际不符。

    意外刹车或刹车不足。

    车辆在车道位置不理想,安全员介入修正位置。

    靠近前车太近,存在碰撞风险。

    横向控制不足。

    软件故障。


3)目前量产的L2自动驾驶接管水平

2023年,懂车帝对于主流智能汽车的高速NOA接管次数进行了统计,如下图所示。

从这次的测试数据中,仅考虑高速场景,并且是正常天气,接管数据最好的阿维塔11,百公里接管0.09次,即大约1100公里接管1次。而每一次接管就意味着不接管很有可能导致一次事故,因此该接管率做到了“合理安全”水平的1100/578万=0.019%。



图片来源:懂车帝

4)L3如何满足“合理安全”?

可以看到,对于面向量产的L3自动驾驶系统,如果要满足“合理安全”的水平,目前的自动驾驶能力还差距较大。

为了使得L3系统可用,通常一般考虑两个方向:


    大幅增加感知、控制和执行器的性能,以及设计合理的冗余架构,提升系统整体性能和安全特性。由于感知、控制和执行器的器件限制,无法短期内大幅提升,因此L3系统主要在冗余架构上做文章。

    严格控制L3激活的ODD范围。使得在可控的较小范围内,将L3自动驾驶的“接管率”指标,控制在可接受的范围内。例如奔驰和宝马的L3系统普遍都要求低于60kph,必须是晴天,并且不支持换道。


5)L3系统需求

L3的关键系统需求如下:


    准确识别环境,尤其是准确识别系统无法应对的环境,包括:


      所有影响车辆安全的道路目标,例如近距离Cut-In的车辆、锥桶、水马以及其他通用障碍物、VRU、静止车辆、路面上的动物等。

      所有影响车辆安全的车辆路面,例如坏路,塌陷等。

      所有影响车辆安全的天气情况,例如雨雪,沙尘等。

    准确识别系统自身工作状态。包括可能造成工作异常的故障或者状态,例如感知/控制/执行系统故障,车辆电池电量低等。

    准确识别驾驶员状态。例如,检测驾驶员是否在驾驶位置或者是否在睡觉。

    在L3系统正常工作时,L3系统需要自主完成全部自动驾驶任务,包括紧急换道,对潜在碰撞目标的刹停避撞或者换道避让。

    在L3系统遇到无法应对的状况时,L3系统需要进行紧急操作或者请求接管,并且在请求接管的时间内,仍然要保证行车安全。

    系统功能需要达到ASIL-D功能安全等级。对L3系统通常的功能安全目标如下表所示,安全状态是安全停车或者驾驶员接管。



02

L3的冗余设计模式

1)对失效的应对模式

系统失效后主要有3种应对模式:


    Fail Safe:当组件失效时,关断相关的控制回路,使得系统不会造成人员或其他设备的伤害(或者将伤害最小化)。例如,关断转向、驱动力矩,车辆停车。

    Fail Degraded:当组件失效时,系统降级运行相关功能。例如,最高行驶速度由120kph降低到60kph,驱动力矩降低50%等等。

    Fail Operational:当组件失效时,系统依然保持100%的工作性能。例如飞机的电控系统。


不同级别的自动驾驶系统,对于如何处理失效,差别较大:





    L0、L1和L2:要求Fail Safe。系统只需要在失效发生时,不发生危害事件,例如不异常加速或者异常转向,自动驾驶系统可以立刻退出,不要求继续控制车辆执行自动驾驶任务。此时要求司机时刻监控环境,识别危险并随时接管;

    L3:要求Fail Degraded/Fail Safe。系统自己判断危险,并提前一段时间预警,提示用户接管。驾驶员无需一直对系统进行监视,当驾驶员没有接管时,L3系统自动执行最小风险策略MRM(下文详细介绍)。

    L4:要求Fail Degraded/Fail Operational。在系统正常时,L4和L3没有明显的功能差异,主要差异在于系统异常后的行为。系统异常后,L3要求驾驶员作为fallback,而L4的fallback依旧是系统,因此L4要具备更强大的fallback能力。L4系统在Fail Degraded时,可以继续保持车辆行驶,在有能力的情况下,以降级的方式完成全程。

    L5:要求Fail Operational。即便是在失效的情况下,系统也需要持续运行,直到完成整个驾驶任务。

2)MooN(D)冗余模式

IEC 61508给出了几种冗余设计的参考架构,这些架构使用MooN(D)来表示,其中:M表示输出,oo表示out of,N表示通道个数,D代表诊断。
例如:


    MooN:M out of N channel architecture。例如,1oo2是2选1架构,2oo3是3选2架构。

    MooND:M out of N channel architecture with Diagnostics。例如,1oo2D是2选1带诊断架构。


IEC61508中定义的MooN(D)冗余模式是工业领域冗余设计的重要指导,本小结做一下简要介绍。

MooN架构

1oo1

1oo1是单通道架构,系统没有冗余也没有保护,任何系统要素失效,既可导致安全失效或者危险失效。

1oo1安全性较低,只能用于系统基本功能的实现,不满足Fail Safe。其架构模型如下:



1oo2

1oo2是2通道串联架构,任一通道发生开路失效时,系统处于常开状态。


    如果系统的安全状态为断开输出回路(例如高压电池继电器),系统可以满足Fail Safe。

    如果系统的安全状态为闭合输出回路(例如冷却水泵),系统不满足Fail Safe。



2oo2

2oo2是2通道并联架构,当任一通道发生闭路失效时,系统处于常闭状态。


    如果系统的安全状态为断开输出回路(例如高压电池继电器),系统不满足Fail Safe。

    如果系统的安全状态为闭合输出回路(例如冷却水泵),系统满足Fail Safe。

其架构模型如下:



2oo3

2oo3是3通道串并联结构,该架构采用多数表决机制,如果其中1个通道失效,输出仍然可以保持正确,即只要系统中有2个通道正常,系统就能正常运行。

2oo3架构可以实现Fail Operational,但是由于成本高,一般用于航空航天领域,在汽车领域应用很少。

其架构模型如下:



MooND架构

1oo1D

1oo1D架构是由功能链路与诊断链路形成的双通道串联系统,该系统可实现Fail Safe,成本较低,应用广泛。

其架构模型如下:



1oo2D

1oo2D架构由并联的2个通道构成,每个通道又由功能链路与诊断链路串联,并且2个通道可以相互诊断,1个通道的诊断链路可以关断另一个通道的输出。1oo2D可实现Fail Operational。

其架构模型如下:



2oo2D

2oo2D架构同样由并联的2个通道构成,每个通道又由功能链路与诊断链路串联。2oo2D架构可以实现Fail Operational。相对于1oo2D架构,2oo2D架构中每个通道的诊断链路只能关断自己的通道,而1oo2D的诊断链路可以关断另外一个失效的控制器。

其架构模型如下:



3)L3自动驾驶设计模式

在《Safe Automated Driving: Requirements and Architectures》的报告中,针对自动驾驶系统应用场景,提出了4种常见的冗余架构模式,在工程化中得到了广泛的应用,如下所示:



图片来源:Safe Automated Driving: Requirements and Architectures

模式1:仲裁/表决。该模式采用类似2oo3架构,对于来自多个子系统(同构或者异构)的输入,每个子系统都实现完整的感知和控制功能,使用“仲裁器”进行最终决策。最简单的仲裁做法是比较各个子系统的输入,例如下表的仲裁方案:



图片来源:Safe Automated Driving: Requirements and Architectures
该模式的主要问题是:


    成本较高。

    如果每个通道产生的结果均差异较大,则仲裁器将很难做出决策。

    简单的问题可能只有一个“最佳/正确”的答案,而复杂的问题可能有多个彼此不同的,但都是“好”的解决方案,例如,有些情况下,自动驾驶汽车向左变道或者向右变道都是可行的解决方案。因此,该方案更适合应用在航空领域中“简单的”空旷天空,而不是汽车领域“复杂的”十字路口。


模式2:协商。各子系统之间相互作用以达成决策,而不需要仲裁组件。虽然省掉了仲裁组件,但是协商协议制定可能更为复杂,并且同样存在和模式1类似的问题。

模式3:Doer/Checker。该模式是1oo1D架构,“Doer”实现系统完整功能,“Checker”监视“Doer”的工作状态。“Checker”比“Doer”有更高的功能安全等级和更低的复杂性。为了实现高可靠性和可用性,“Doer”和“Checker”一般需要不同的系统方案,相互独立的硬件和软件进行实现。当“Doer”失效时,该系统无法实现正常功能,因此,基本的“Doer/Checker”系统仅能实现Fail-Safe。

模式4:热备份。该模式是1oo2D架构。两个同构或异构子系统并行运行,而在任何给定时间只有其中一个是活动的,故障检测机制充当子系统之间的切换器。

03

L3的工作过程

1)TOR、MRM和MRC

这几个概念含义如下:


    TOR(Take Over Request,接管请求),当系统无法应对当前工况,需要驾驶员接管时,发出的接管请求,一般是通过声、光或者触觉方式进行提示。

    MRC(Minimal Risk Condition,最小风险状态),当车辆无法完成预定的行程时,由用户或驾驶自动化系统执行,并最终使车辆事故风险达到可接受的状态。

    MRM(Minimal Risk Maneuver,最小风险操作),在驾驶自动化系统或用户无法执行动态驾驶任务或动态驾驶任务接管时,驾驶自动化系统所采取的降低风险的措施。(源于功能安全标准ISO-26262)


当用户无法及时响应自动驾驶系统发出的接管请求(Take Over Request,TOR)时,自动驾驶系统应执行最小风险策略MRM(Minimal Risk Maneuver,最小风险操作),以保证车辆运行安全。这里的“保证车辆运行安全”是指车辆进入了最小风险状态MRC。

在自动驾驶系统功能设计中,为适应不同的需求,通常可以定义多种不同的最小风险策略MRM,常见的MRM见下表。



图片来源:自动驾驶安全第一白皮书

一般情况下,靠边停车(如下图a)是L3最理想的MRM,也是在设计中应当最优先考虑的。

不过由于受到具体环境和系统性能所限(例如缺乏侧向感知单元),有些情况下,也不得不采用当前车道停车(如下图b)。



图片来源:BMW

MRM的设计会影响自动驾驶系统的使用体验,甚至安全性。因此在自动驾驶系统开发过程中,需要针对自动驾驶系统需求,结合自动驾驶系统的感知和控制方案,通过失效分析,定制合适的MRM策略。

常见的几种最小风险状态MRC定义见下表:



图片来源:自动驾驶安全第一白皮书
上面三种最小风险状态MRC可分为两类:


    一类是结束运行,代表车辆已经刹停,且自动驾驶系统退出,属于最终MRC;

    另一类是驾驶员接管和降级运行,此类MRC下,车辆仍保持运行,并未刹停,且可能进一步转换到结束运行状态(最终MRC)。


MRM的目标是使车辆达到MRC,当车辆定义有多个MRC时,也需要定义相应的不同MRM,以实现车辆从正常状态(标称运行)向不同MRC,或不同MRC之间的状态转换。



图片来源:自动驾驶安全第一白皮书
2)L3的基本工作过程

L3的基本工作过程如下:



对于“最紧急情况”和“紧急情况”,一般难以保证用户有足够的接管时间,因此,此时L3直接进行紧急操作或者MRM。
“最紧急情况”一般是指:前方突然出现障碍物需要紧急制动或者转向,例如鬼探头、前方掉落物体等。“紧急情况”一般是指:转向系统失效,或者多个传感器同时失效等。


对于“非紧急情况”,系统应尽早向用户发出接管请求,以保证用户有足够的时间完成接管动作。如果用户在TOR时间后仍未接管车辆,此时L3系统进入最小风险控制MRM,进而进入到MRC安全状态。

“非紧急情况”一般是指:即将驶出ODD范围等可预期时间,或者较为轻微的系统失效,某个摄像头被遮挡等。



04

L3系统设计方案

1)1oo2D交叉检验架构

目前较为主流的L3系统方案是采用1oo2D架构,同时,在每个通道中采用Doer/Checker设计思路。

该架构方案可以在成本可控的情况下,实现Fail Degraded, 甚至Fail Operational,能够满足L3和未来L4的架构需求。

在1oo2D交叉检验架构中,2个通道分别进行输入信息的处理及输出,并各自对对方的状态进行实时诊断,一旦对方失效,对失效的通道进行输出无效化,从而达到L3级自动驾驶系统所要求的冗余设计要求。

如下图所示:



图片来源:网络

功能正常时,2个通道共同生成感知规划结果,并在主通道MCU安全仲裁后,将控制指令发给执行器。在某一通道Fail之后,另一通道执行MRM,支持实现安全的Fail Degraded特征。

具体实现的一些案例,可以参考《雪岭·自动驾驶(1/10):系统架构》一文。

2)通信冗余

为了保证通信冗余,在L3系统中一般会设置多个CAN和ETH通道。



可以通过一些专用的可靠性通信协议,提升冗余通信性能。例如,时间敏感网络(TSN)的IEEE 802.1CB协议,该协议为以太网提供双链冗余特性,当发生网桥节点失效、线路断路和外部攻击导致线路阻塞等问题时,可以保证通信的正常。

IEEE 802.1CB协议通过在网络的源端系统和中继系统中对每个数据帧进行序列编号和复制,保证每一份数据在链路中至少有2份相同的数据进行传输,同时,在目标端系统和其他中继系统中消除这些复制帧,确保仅有一份数据帧被接收。当其中1份数据发生丢失或者阻塞,其他的数据可以不受影响的传输到目标地址。



图片来源:怿星科技



图片来源:怿星科技
3)电源冗余

电源是任何电控系统的关键组成部分,L3级自动驾驶更是需要足够安全稳定的供电。

一般情况下,L3自动驾驶系统需要配备至少两个低压电源,用于系统内控制器的供电。供电功能的安全等级一般需要达到ASIL-D,两路电源的容量均需要能够独立支持MRM。

根据组件不同的功能和成本考虑,有些控制器(例如域控制器、关键执行器)需要同时接2个电源,有些控制器(例如已经冗余设计的感知单元)只需要接其中1个电源。一般情况下,不同安全等级的负载(例如安全负载和常规负载)需要接入不同的电源网络,以提升安全性能。

电源冗余有几个不同的方案:
方案1:双DCDC+双蓄电池

该方案包含两个完全独立的供电系统,可以做到相互冗余,不过成本较高,零件的布置难度较大。



方案2:单DCDC+双蓄电池+电源隔离模块

电源隔离模块可以理解为是一个“智能隔离开关”,正常情况下,电源隔离模块将2个电源回路接通,使得DCDC可以可以同时给两个蓄电池充电。当其中一路电源发生故障时(例如短路),切断开关,使得另外一路供电不受影响。

该方案成本相对较低,不过电源隔离模块需要快速识别和响应电源故障,开发难度较高。



方案3:单DCDC+单蓄电池+智能配电单元

该方案采用专用的智能配电单元,使用芯片化的方式进行配电,可以做到多路隔离供电,例如大负载采用MOSFET,小负载采用HSD。

该方案灵活度较高,布置方便,不过智能配电单元开发较为复杂,对于电流要求更大的负载很难采用芯片化的方案(目前芯片的最大配电电流一般不超过30A),因此应用场景有一定限制。



采用该方案的典型代表是TESLA,如下图所示。其中的VCFront就是智能电子配电单元:



图片来源:网络
4)感知冗余

为了实现功能安全和降低同源失效概率,理论上每个涉及行车安全的感知区域,需要至少有2种异构的感知单元进行覆盖(摄像头、毫米波雷达、激光雷达和超声波雷达)。

根据目前L3的主流方案,感知单元的布置情况如下:


    摄像头:一般布置前向2颗,侧向4颗,环视4颗,后视1颗。前向摄像头一般像素在8M以上。

    毫米波雷达:一般布置前向1颗,前角2颗,后角2颗,有时后向也增加1颗。L3的毫米波雷达倾向于采用4D成像毫米波雷达。

    激光雷达:一般布置前向1颗,侧向2颗,有时后向也增加1颗。激光雷达一般要求分辨率较高,目前主推的是角分辨率在0.05°*0.05°的高分辨率激光雷达。

    超声波雷达:一般是4个APA+8个UPA。

5)控制器冗余

控制器是L3系统的控制核心,一般需要2个独立控制器,或者集成在1个盒子的2块控制板(One Box)。一般不会采用一块控制板(One Board),甚至一个芯片(One Chip)方案,因为集成度过高,将很难实现独立和冗余。

具体实现的一些案例,可以参考《雪岭·自动驾驶(1/10):系统架构》。

6)执行器冗余

执行器主要包括驱动、制动、转向、悬架和HMI。


    驱动冗余:通过两个驱动单元实现,例如纯电动汽车上前后两个驱动电机,混动汽车上的发动机和电机(需要设计解耦机构,防止1个驱动单元失效导致另外1个无法独立驱动)。

    制动冗余:制动冗余需要使用两个独立的制动单元,例如纯电动汽车上的IBS和“冗余制动模块”。同时,如果制动系统无法支持驻车制动,还需要设计冗余的驻车制动单元。

    转向冗余:一般是两套相互冗余的EPS控制单元和2个独立EPS电机。有时为了降低成本,可以使用1个多绕组EPS电机,但是使用2个控制单元进行独立控制。

    悬架由于主要影响舒适性,因此一般不做冗余考虑。

    HMI用于提升驾驶员和外部交通参与者,也具备较高的功能安全等级,也需要进行一定的冗余设计。


05

结语

以目前的自动驾驶技术水平,如果要实现安全、覆盖度广、可用性强的L3自动驾驶系统,难度还非常高。

下图中,左边是L3期望的工作状态,而右图是当前面临的实际情况:



很多时候,不怕“系统不行”,而是怕“系统不知道自己不行”。

为了使得L3系统尽量安全,很多时候不得不将L3可激活区域做非常严格的限制,例如仅在下面绿色圆圈的范围,才能激活L3。



不过随着性能越来越好的感知单元、算力越来越高的芯片,以及越来越强大的人工智能算法的部署,相信自动驾驶系统能力会继续不断提升,使得L3系统的可用范围越来越大。


本文内容仅代表个人观点,和真实情况有可能有偏差,仅供参考。如需要相关内容更详细的技术信息,欢迎添加“雪岭飞花”微信(maxhnnl)进一步交流,感谢。

参考资料



    工业和信息化部 公安部 住房和城乡建设部 交通运输部关于开展智能网联汽车准入和上路通行试点工作的通知,
    https://www.gov.cn/zhengce/zhengceku/202311/content_6915788.htm

    ADAS/AD系统开发12- 安全冗余设计简介,
    https://zhuanlan.zhihu.com/p/55683142

    两万字详解L3自动驾驶系统设计,
    https://zhuanlan.zhihu.com/p/658160119

    探秘美国加州自动驾驶路试:豪横竞逐、勤奋探索与技术挑战,https://new.qq.com/rain/a/20240303A08H5500
万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w28.jpg
         同一主题附件:
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w2.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w3.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w4.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w5.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w6.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w7.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w8.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w9.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w10.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w11.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w12.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w13.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w14.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w15.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w16.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w17.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w18.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w19.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w20.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w21.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w22.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w23.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w24.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w25.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w26.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w27.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w28.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w29.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w30.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w31.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w32.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w33.jpg
    万字解析:L3自动驾驶冗余模式和设计纲要——“不怕系统不行,就怕系统不知道自己不行”(雪岭系列)w34.jpg

QQ|手机版|小黑屋|Archiver|汽车工程师之家 ( 渝ICP备18012993号-1 )

GMT+8, 28-6-2024 18:30 , Processed in 0.165646 second(s), 20 queries .

Powered by Discuz! X3.5

© 2001-2013 Comsenz Inc.