正向研发自动驾驶汽车,离不开符合功能安全的软硬件架构
2018-08-06 12:03:40· 来源:车云
7月13日,在由车云、武汉经开投资有限公司、武汉现代制造业创业服务中心联合主办的“智商业·驭未来”第三届中国智能汽车创新发展论坛上,NXP ADAS和自动驾驶技术市场经理武钰发表了名为《符合功能安全的自动驾驶软硬件架构》的演讲。
“ 自动驾驶的软硬件架构,该如何兼顾功能安全和可扩展性?”
7月13日,在由车云、武汉经开投资有限公司、武汉现代制造业创业服务中心联合主办的“智商业·驭未来”第三届中国智能汽车创新发展论坛上,NXP ADAS和自动驾驶技术市场经理武钰发表了名为《符合功能安全的自动驾驶软硬件架构》的演讲。
智能汽车的车身电子架构正在发生变化。传统汽车采用了分布式架构,每个电子单元各自承担计算任务,需要集中处理的数据很少。这种架构可扩展性较强,如果想增加一个新的传感器也非常方便。
但是传统的分布式架构已经无法满足自动驾驶汽车的计算需求。随着自动驾驶需要的传感器越来越多,传感器之间的信息需要更加深度的融合计算,这是就要有一个强大的计算机来完成所有的数据运算。
因此,很多自动驾驶原型车采用了中央式架构——终端电子单元不对数据做修改处理,而是由中央处理器承担所有的计算任务。但是这种架构的缺点在于,假如新功能开发需要增加新传感器,中央处理器的软件就要重新刷写,因此可扩展性非常差。
NXP推荐的是一种混合性拓扑结构的车身电子电气架构,通过在中央处理器和终端电子单元之间设置一个域控制器的方式,把从传感器拿过来的数据放到域控制器里先行处理,再把处理后的有效信息传给中央处理器。这样一方面可以减少数据的传输压力,另一方面也平衡了整个计算平台的计算量。
这种混合性拓扑结构与中央式结构相比,更加便于扩展。例如主机厂已经完成了自动泊车功能,想在此基础上扩展为车辆自己寻找车位的代客泊车。工程师可以不必更改中央处理器的软件,只需要连接上新的传感器,更新域控制器上面的软件就可以实现。
通过增加中间节点的方式,混合性拓扑结构不仅可以根据功能要求灵活的改善硬件结构,而且可以容易地进行软件升级。同时在系统架构上,NXP将硬件配合软件分割成不同的域,来灵活配置不同的安全等级,从而使不同等级的自动驾驶系统整体满足功能安全的要求。
▲NXP ADAS 和自动驾驶技术市场经理 武钰
以下为演讲速记,车云菌在保持原意的基础上做了删减:
大家下午好,我叫武钰,来自NXP技术市场部,主要负责ADAS和自动驾驶。说到自动驾驶安全性是第一位的,现在很多信息向我们铺面而来,但是我们反思一下真正开始做自动驾驶的初衷是什么?是为了安全,保证道路参与者的生命安全。作为车载芯片供应商,NXP一直把功能安全放在第一位。同时我们看到了ADAS自动驾驶软件发展方向,开始做一些硬件上的考量。我们现在要根据自动驾驶的软件结构,来重塑我们的硬件方案。
这张图在座各位都不会太陌生,是SAE自动驾驶6类分级中的后5类。从L1开始,我们的车辆变得智能化,会从纵向的车身控制中选一样来帮助驾驶员。NXP会重视从L2-L5的自动驾驶,因为L1到L2有个重大的变革,我们汽车可以同时做横纵向的控制,把车身的控制权已经从驾驶员分出一部分给汽车本身。一旦涉及到车身控制,我们功能安全考量一下子就要升级了。
从L2开始,我们提供自动泊车,这种自动泊车是指车已经开到停车位,让车通过操控方向盘和油门、刹车来停车,感知方面仍然由驾驶员来做,车辆只是起到横纵向控制。还有自动刹车时同时包括方向盘转动有规避障碍物的行为。从L2-L3,感知模块也会移到汽车上。对泊车来说,车开到一个位置后要自己去寻找可供停车的位置,然后自己操作方向盘来停在这个位置。至于L4和L5,车身开始有自己的大脑,自己会做行为决策,也会做复杂性场景,自己有思维去寻找解决方案。比如说碰到很复杂的交通情况,会用大脑想出解决方案。
对应不同的驾驶等级,传感器选择和数量都会有所不同。随着自动驾驶等级的升级,传感器的数量会越来越多。这样会带来一个问题,传感器是不是越多越好呢?答案是不一定。因为传感器越多,数据量会越大,对于海量数据,车身具体怎么从海量数据进行分析提取有效信息,并且根据这些有效信息形成符合安全驾驶原则的行为,这点也是我们需要考虑的。
比如激光雷达给到的是点云数据,一秒可以达到几个G的数量级。大家想一下,如果一秒是几个G,整个车一天可以达到多大的数据。还有摄像头是几十到几百兆每秒数据,这些海量数据放在面前,车上的芯片怎么办,这样就会带来新的问题。
NXP在分析车上的拓扑结构的时候,结合了行业的发展趋势。
传统分散式结构中,每个传感器的数据都在终端处理,好处在于对车上通信带宽要求不高,真正有效的目标数据才放到车上处理。但是问题在于每个传感器需要同步,无论激光雷达或者毫米波雷达或者摄像头,一旦涉及到同步性,分散式的拓扑结构就没有办法做得很好。
现在自动驾驶的原型车更多是采用右边中心式的结构,它的数据全部是从传感器部分传到中央处理器,中央处理器面对高频海量的数据来进行计算,现在中央处理器一般选用的是IPC或者GPU。但劣势很明显,第一是中央处理器运算量特别大,而且带宽要求很高,第二功耗也是汽车行业需要考量的。
NXP提出来的方案是中间的混合性拓扑结构,我们会在一部分的节点上设置一个域控制器,这个域控制器会把从传感器拿过来的数据作为先行处理,再把有效信息传给中央处理器。一方面平衡了数据传输的要求,另一方面平衡了整个计算平台,在终端处理器和中央处理器中间加了预处理器,这样可以实现更好更平衡。
我们现在要反过来想自动驾驶软件模块,软件层面是怎么搭建的。我列了行业比较标准的结构,从传感器部分拿到原始数据(Raw Data),到感知模块做特征提取和信息提取,再加上车身周围信息建模,再根据高精地图定位,加上高精度地图和GPS信息做自定位,然后生成本地路径。从本地的路径中,我们通过车辆的分析和决策模块,真正达到车辆控制。
作为NXP,我们想的是既然软件可以分成不同模块,那么硬件也应该可以配合软件的要求进行区别对待。
上图是我们硬件的考量,从头开始看的话,从感知到建模的部分,对计算的算力要求特别高,因为要做矩阵运算,而且涉及到计算机视觉。在一个车上传感器不会只有一种,所以激光雷达、毫米波雷达和摄像头其实是互为补充的形态,在这方面我们认为安全等级可以稍微牺牲一点,更多是满足算力要求。
而后面因为涉及到车身控制,我们认为安全等级的要求就完全不能降低,一定要达到ASIL-D的水平。从上面这张图上可以看到,对于前区的感知模块,更多是从人工智能到数据流,以及软件安全的发展方向。在后面的行为决策部分,我们更多想的是软件层面优化,再到底盘的控制,以及硬件安全考量。这两方面,我们要根据软件应用特性来做不同的发展方向规划。
回到芯片上面的框架,我们认为一般来说如果车载芯片很重要的是要做冗余设计,如果出现失效或者错误的时候切换到安全模式,能够有最安全的退出。
针对自动驾驶系统,感知和行为决策部分是分开的话,NXP把感知放在S32V或S32R上面,这边更多是传感器处理器芯片,安全等级会稍微低一点。但是等到涉及到车身控制,会放在S32A,这个是专门的中央计算处理芯片,我们会加上冗余设计和备份。
正常运行的时候,这ECU Primary和ECU Backup都是同时接收各种信号。一旦出现失效或者错误,车身控制连接会完全放弃从Primary拿数据,直接从Backup的芯片拿数据运算,保证了安全退出的模式。
S32是NXP研发的汽车计算平台,也是全球首个可扩展的计算机平台,简而言之做到了四个字——求同存异。这套系统计算平台会有各种各样的芯片,根据车身不同应用会有对应的不同芯片,但整个内核设计部分是一样的,保证我们的软件开发是同一个平台,但是根据芯片具体在车身哪个位置起作用,我们会加上不同的硬件加速器。比如对于S32V专门对视觉做的,我们会加上视觉的硬件处理器,S32R是针对毫米波雷达的,我们会根据毫米波雷达应用做不同的改变。S32A的特色是算力和安全性非常高,所以作为中央处理器的运算。
我们采用这个设计,一方面在感知和规划方面的错误都可以跟踪到,但同时降低了系统功耗和成本,整个系统可以降低100美元。其他芯片和S32相比,如果想做功能安全冗余设计,需要把整个芯片做备份。NXP在车载芯片设计方面有很多年的经验,而且有自己专属的自动驾驶考量,所以基于这个原则我们设计出来的芯片,一方面平衡了高性能低功耗,同时达到了安全等级ASIL-D的水平。
上图是我们给出的低于L2自动驾驶模块的整车模型,跟现在市面上大多数ADAS系统比较相似。在传感器部分,我们采用终端处理器,比如现在的S32R或者S32V,直接在本地做传感器数据处理,处理后通过CAN传给网关,然后网关会发信号到底盘不同区域做控制。
如果升级到L3和L4,就像我刚才说的,我们需要一个域控制器的概念,除了在传感器的终端加上S32R、S32V这种终端处理器,还会有S32A专门做行为决策。
但除了这个,如果你想整个系统达到ASIL-D水平,最后希望的是S32A做冗余设计,对自动驾驶系统起到功能安全的考量。大家想一下,把芯片放在自动驾驶系统里面,本身这个系统很复杂,而且车在自动驾驶模式的话,周围环境也是多元化的,各个方面都会对芯片的功能安全要求变高。我们非常注重这方面,但是也会给客户提供功耗低和低成本的方案。
除了S32A做冗余设计,我们还有一个关注点,即便你拿到了车身控制信息,但是传到底盘的EPS的时候,是通过网关传输的。如果网关不能保证安全的话,对系统来说风险是很大的。所以我们也会在Gateway做冗余设计,出了任何问题也会有预备方案,起码可以保证车身控制是在我们可接受范围内。
这是NXP提供整套安全系统解决方案,绿色模块是硬件功能安全特征,除了MCU硬件方面会加入很多新硬件的功能安全特性。同时,我们还有SVC,这本来是做时钟的东西,但是我们也加入了功能安全的模块。
除了硬件方面,大家可以往上看蓝色的部分,这是NXP给客户提供软件层面的解决方案。如果你的软件设计需要用到自检或者安全退出或者复原的特性,我们会有现成的方案供客户使用。
目前,NXP在ADAS和自动驾驶方面,在上海和重庆有一百多人工程师团队,专门负责软件层面给客户的支持。所以可以看出来,我们芯片业务技术支持在中国本地投入量最大,有任何困难或者软件上需要什么帮助,我们都可以提供。
NXP的硬件系统可以支持多个操作系统,可以根据软件应用的方向,可以自己选择想跑实时的操作系统还是跑Linux系统,Linux系统可能会更加适合计算量比较大的软件硬件,实时操作系统比较适合功能安全的软件应用,可以跑QNX和Autosar,所有传统汽车行业需要的一连串的软件设计,NXP已经有非常成熟的方案了。这两个操作系统跟硬件中间有一个Hypervisor,就是抽象层面,会根据运行系统的设置做调度,然后在硬件上面达到一致。NXP提供功能安全方案,我们是从硬件上面做升级,同时在软件的支持上也做了很多的东西,我们可以根据客户的需求来灵活调用软件和硬件。
S32推出以后,欧洲比较大的整车厂都会偏向S32计算平台,因为非常节省软件开发成本。根据一些调查,整车上面采用统一S32计算平台,软件工作量可以减少80%,跨应用软件研发也会减少40%以上。国内的话,NXP跟百度合作,百度已经把NXP的芯片用到了他们的车上。还有欧洲的大巴公司,他们的L3自动驾驶系统可以放到我们的板上做测试。
7月13日,在由车云、武汉经开投资有限公司、武汉现代制造业创业服务中心联合主办的“智商业·驭未来”第三届中国智能汽车创新发展论坛上,NXP ADAS和自动驾驶技术市场经理武钰发表了名为《符合功能安全的自动驾驶软硬件架构》的演讲。
智能汽车的车身电子架构正在发生变化。传统汽车采用了分布式架构,每个电子单元各自承担计算任务,需要集中处理的数据很少。这种架构可扩展性较强,如果想增加一个新的传感器也非常方便。
但是传统的分布式架构已经无法满足自动驾驶汽车的计算需求。随着自动驾驶需要的传感器越来越多,传感器之间的信息需要更加深度的融合计算,这是就要有一个强大的计算机来完成所有的数据运算。
因此,很多自动驾驶原型车采用了中央式架构——终端电子单元不对数据做修改处理,而是由中央处理器承担所有的计算任务。但是这种架构的缺点在于,假如新功能开发需要增加新传感器,中央处理器的软件就要重新刷写,因此可扩展性非常差。
NXP推荐的是一种混合性拓扑结构的车身电子电气架构,通过在中央处理器和终端电子单元之间设置一个域控制器的方式,把从传感器拿过来的数据放到域控制器里先行处理,再把处理后的有效信息传给中央处理器。这样一方面可以减少数据的传输压力,另一方面也平衡了整个计算平台的计算量。
这种混合性拓扑结构与中央式结构相比,更加便于扩展。例如主机厂已经完成了自动泊车功能,想在此基础上扩展为车辆自己寻找车位的代客泊车。工程师可以不必更改中央处理器的软件,只需要连接上新的传感器,更新域控制器上面的软件就可以实现。
通过增加中间节点的方式,混合性拓扑结构不仅可以根据功能要求灵活的改善硬件结构,而且可以容易地进行软件升级。同时在系统架构上,NXP将硬件配合软件分割成不同的域,来灵活配置不同的安全等级,从而使不同等级的自动驾驶系统整体满足功能安全的要求。
▲NXP ADAS 和自动驾驶技术市场经理 武钰
以下为演讲速记,车云菌在保持原意的基础上做了删减:
大家下午好,我叫武钰,来自NXP技术市场部,主要负责ADAS和自动驾驶。说到自动驾驶安全性是第一位的,现在很多信息向我们铺面而来,但是我们反思一下真正开始做自动驾驶的初衷是什么?是为了安全,保证道路参与者的生命安全。作为车载芯片供应商,NXP一直把功能安全放在第一位。同时我们看到了ADAS自动驾驶软件发展方向,开始做一些硬件上的考量。我们现在要根据自动驾驶的软件结构,来重塑我们的硬件方案。
这张图在座各位都不会太陌生,是SAE自动驾驶6类分级中的后5类。从L1开始,我们的车辆变得智能化,会从纵向的车身控制中选一样来帮助驾驶员。NXP会重视从L2-L5的自动驾驶,因为L1到L2有个重大的变革,我们汽车可以同时做横纵向的控制,把车身的控制权已经从驾驶员分出一部分给汽车本身。一旦涉及到车身控制,我们功能安全考量一下子就要升级了。
从L2开始,我们提供自动泊车,这种自动泊车是指车已经开到停车位,让车通过操控方向盘和油门、刹车来停车,感知方面仍然由驾驶员来做,车辆只是起到横纵向控制。还有自动刹车时同时包括方向盘转动有规避障碍物的行为。从L2-L3,感知模块也会移到汽车上。对泊车来说,车开到一个位置后要自己去寻找可供停车的位置,然后自己操作方向盘来停在这个位置。至于L4和L5,车身开始有自己的大脑,自己会做行为决策,也会做复杂性场景,自己有思维去寻找解决方案。比如说碰到很复杂的交通情况,会用大脑想出解决方案。
对应不同的驾驶等级,传感器选择和数量都会有所不同。随着自动驾驶等级的升级,传感器的数量会越来越多。这样会带来一个问题,传感器是不是越多越好呢?答案是不一定。因为传感器越多,数据量会越大,对于海量数据,车身具体怎么从海量数据进行分析提取有效信息,并且根据这些有效信息形成符合安全驾驶原则的行为,这点也是我们需要考虑的。
比如激光雷达给到的是点云数据,一秒可以达到几个G的数量级。大家想一下,如果一秒是几个G,整个车一天可以达到多大的数据。还有摄像头是几十到几百兆每秒数据,这些海量数据放在面前,车上的芯片怎么办,这样就会带来新的问题。
NXP在分析车上的拓扑结构的时候,结合了行业的发展趋势。
传统分散式结构中,每个传感器的数据都在终端处理,好处在于对车上通信带宽要求不高,真正有效的目标数据才放到车上处理。但是问题在于每个传感器需要同步,无论激光雷达或者毫米波雷达或者摄像头,一旦涉及到同步性,分散式的拓扑结构就没有办法做得很好。
现在自动驾驶的原型车更多是采用右边中心式的结构,它的数据全部是从传感器部分传到中央处理器,中央处理器面对高频海量的数据来进行计算,现在中央处理器一般选用的是IPC或者GPU。但劣势很明显,第一是中央处理器运算量特别大,而且带宽要求很高,第二功耗也是汽车行业需要考量的。
NXP提出来的方案是中间的混合性拓扑结构,我们会在一部分的节点上设置一个域控制器,这个域控制器会把从传感器拿过来的数据作为先行处理,再把有效信息传给中央处理器。一方面平衡了数据传输的要求,另一方面平衡了整个计算平台,在终端处理器和中央处理器中间加了预处理器,这样可以实现更好更平衡。
我们现在要反过来想自动驾驶软件模块,软件层面是怎么搭建的。我列了行业比较标准的结构,从传感器部分拿到原始数据(Raw Data),到感知模块做特征提取和信息提取,再加上车身周围信息建模,再根据高精地图定位,加上高精度地图和GPS信息做自定位,然后生成本地路径。从本地的路径中,我们通过车辆的分析和决策模块,真正达到车辆控制。
作为NXP,我们想的是既然软件可以分成不同模块,那么硬件也应该可以配合软件的要求进行区别对待。
上图是我们硬件的考量,从头开始看的话,从感知到建模的部分,对计算的算力要求特别高,因为要做矩阵运算,而且涉及到计算机视觉。在一个车上传感器不会只有一种,所以激光雷达、毫米波雷达和摄像头其实是互为补充的形态,在这方面我们认为安全等级可以稍微牺牲一点,更多是满足算力要求。
而后面因为涉及到车身控制,我们认为安全等级的要求就完全不能降低,一定要达到ASIL-D的水平。从上面这张图上可以看到,对于前区的感知模块,更多是从人工智能到数据流,以及软件安全的发展方向。在后面的行为决策部分,我们更多想的是软件层面优化,再到底盘的控制,以及硬件安全考量。这两方面,我们要根据软件应用特性来做不同的发展方向规划。
回到芯片上面的框架,我们认为一般来说如果车载芯片很重要的是要做冗余设计,如果出现失效或者错误的时候切换到安全模式,能够有最安全的退出。
针对自动驾驶系统,感知和行为决策部分是分开的话,NXP把感知放在S32V或S32R上面,这边更多是传感器处理器芯片,安全等级会稍微低一点。但是等到涉及到车身控制,会放在S32A,这个是专门的中央计算处理芯片,我们会加上冗余设计和备份。
正常运行的时候,这ECU Primary和ECU Backup都是同时接收各种信号。一旦出现失效或者错误,车身控制连接会完全放弃从Primary拿数据,直接从Backup的芯片拿数据运算,保证了安全退出的模式。
S32是NXP研发的汽车计算平台,也是全球首个可扩展的计算机平台,简而言之做到了四个字——求同存异。这套系统计算平台会有各种各样的芯片,根据车身不同应用会有对应的不同芯片,但整个内核设计部分是一样的,保证我们的软件开发是同一个平台,但是根据芯片具体在车身哪个位置起作用,我们会加上不同的硬件加速器。比如对于S32V专门对视觉做的,我们会加上视觉的硬件处理器,S32R是针对毫米波雷达的,我们会根据毫米波雷达应用做不同的改变。S32A的特色是算力和安全性非常高,所以作为中央处理器的运算。
我们采用这个设计,一方面在感知和规划方面的错误都可以跟踪到,但同时降低了系统功耗和成本,整个系统可以降低100美元。其他芯片和S32相比,如果想做功能安全冗余设计,需要把整个芯片做备份。NXP在车载芯片设计方面有很多年的经验,而且有自己专属的自动驾驶考量,所以基于这个原则我们设计出来的芯片,一方面平衡了高性能低功耗,同时达到了安全等级ASIL-D的水平。
上图是我们给出的低于L2自动驾驶模块的整车模型,跟现在市面上大多数ADAS系统比较相似。在传感器部分,我们采用终端处理器,比如现在的S32R或者S32V,直接在本地做传感器数据处理,处理后通过CAN传给网关,然后网关会发信号到底盘不同区域做控制。
如果升级到L3和L4,就像我刚才说的,我们需要一个域控制器的概念,除了在传感器的终端加上S32R、S32V这种终端处理器,还会有S32A专门做行为决策。
但除了这个,如果你想整个系统达到ASIL-D水平,最后希望的是S32A做冗余设计,对自动驾驶系统起到功能安全的考量。大家想一下,把芯片放在自动驾驶系统里面,本身这个系统很复杂,而且车在自动驾驶模式的话,周围环境也是多元化的,各个方面都会对芯片的功能安全要求变高。我们非常注重这方面,但是也会给客户提供功耗低和低成本的方案。
除了S32A做冗余设计,我们还有一个关注点,即便你拿到了车身控制信息,但是传到底盘的EPS的时候,是通过网关传输的。如果网关不能保证安全的话,对系统来说风险是很大的。所以我们也会在Gateway做冗余设计,出了任何问题也会有预备方案,起码可以保证车身控制是在我们可接受范围内。
这是NXP提供整套安全系统解决方案,绿色模块是硬件功能安全特征,除了MCU硬件方面会加入很多新硬件的功能安全特性。同时,我们还有SVC,这本来是做时钟的东西,但是我们也加入了功能安全的模块。
除了硬件方面,大家可以往上看蓝色的部分,这是NXP给客户提供软件层面的解决方案。如果你的软件设计需要用到自检或者安全退出或者复原的特性,我们会有现成的方案供客户使用。
目前,NXP在ADAS和自动驾驶方面,在上海和重庆有一百多人工程师团队,专门负责软件层面给客户的支持。所以可以看出来,我们芯片业务技术支持在中国本地投入量最大,有任何困难或者软件上需要什么帮助,我们都可以提供。
NXP的硬件系统可以支持多个操作系统,可以根据软件应用的方向,可以自己选择想跑实时的操作系统还是跑Linux系统,Linux系统可能会更加适合计算量比较大的软件硬件,实时操作系统比较适合功能安全的软件应用,可以跑QNX和Autosar,所有传统汽车行业需要的一连串的软件设计,NXP已经有非常成熟的方案了。这两个操作系统跟硬件中间有一个Hypervisor,就是抽象层面,会根据运行系统的设置做调度,然后在硬件上面达到一致。NXP提供功能安全方案,我们是从硬件上面做升级,同时在软件的支持上也做了很多的东西,我们可以根据客户的需求来灵活调用软件和硬件。
S32推出以后,欧洲比较大的整车厂都会偏向S32计算平台,因为非常节省软件开发成本。根据一些调查,整车上面采用统一S32计算平台,软件工作量可以减少80%,跨应用软件研发也会减少40%以上。国内的话,NXP跟百度合作,百度已经把NXP的芯片用到了他们的车上。还有欧洲的大巴公司,他们的L3自动驾驶系统可以放到我们的板上做测试。
最新资讯
-
特朗普宣布胜选,这5个方向可能影响
2024-11-08 20:15
-
京东政企业务出席2024中国汽车流通行
2024-11-08 17:29
-
建立强大且创新的合作伙伴关系,日产
2024-11-08 17:28
-
从数字愿景到创新落地:中国制造及建
2024-11-07 19:32
-
问界M7被鉴定存在“刹车失灵”和“人
2024-11-07 14:46