EE架构 | 实现中央计算+区域控制架构所面临的技术挑战
2023-1-14 18:2:40 Author: 谈思实验室(查看原文) 阅读量:17 收藏

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

1. EE架构演进趋势
近年来,汽车智能化、电动化的发展,极大的提升了用户体验,也触发了整车传感器数量和数据的倍增,芯片算力、存储容量、通信带宽和软件功能不断突破新高。
传统分布扁平式的EE架构由于缺乏主导分层融合的主节点,新需求引入的功能升级只能以独立子系统(ECU+传感器+执行器)形式叠加到原有架构,导致富余的硬件资源浪费、线束布置复杂、基础软件难以标准化、上层应用逻辑复杂等问题,这些都会给主机厂带来极大的开发设计、制造成本和售后维护的挑战。
为应对挑战,必须首先升级现有EE架构,通过硬件资源共享、软件标准化,简化整车布置,达到整车轻量化和功能优化整合的目标,从而推进软件定义汽车的落地,以实现丰富且差异化的用户体验。
鉴于此,EE架构的演进趋势纷纷走向中央计算(算力/存储/通信集中),区域控制(传感器/执行器)的架构形态(Zonal EEA);这种新架构形态也体现了类生物特征的设计理念(中央大脑/区域手脚),相信这种理念也更有助于汽车智能化的发展。
联合电子从2017年初便启动了中央计算/区域控制平台的研发工作。Zonal EEA在整车设计、制造成本、快速落地、轻量化等方面已取得一定优势;但同时,Zonal EEA因其系统成熟度、已有架构兼容性和车型配置等多方面的原因,也会经历分阶段的迭代演进,我们把这种迭代演进分为Zonal EEA1.0/2.0/Evolution三个阶段。
1.1  Zonal EEA1.0
Zonal EEA1.0的架构特征,一般以当前域集中架构形成的三域(整车控制、智能驾驶、智能座舱)为基础,打破功能域边界,运用物理分区,逻辑分层的方法论,把整车管理、逻辑运算等核心功能集中放入中央计算平台;把整车配电、硬件I/O、区内通讯、安全隔离和指令执行等功能纵向拆分至车身各区域控制器,形成“3+N”的落地方案,即三个中央计算平台和多个区域控制器。
Zonal EEA1.0的架构由于缺乏大量的借鉴经验和实车论证,智能座舱和智能驾驶的外围摄像头、雷达等传感器,因实时性和区域处理能力的限制,目前传感器大部分采用直接接入中央计算平台的相对保守方案。
1.2  Zonal EEA2.0
随着Zonal EEA1.0架构逐渐得到论证,中央三域计算平台(整车控制、智能驾驶、智能座舱)在Zonal EEA2.0的架构阶段,为了进一步功能融合、资源共享、提升用户体验、以及应对多变的市场需求,不同主机厂根据自身情况,可能会采取不同的融合架构形态;如智控+智舱融合、智控+智驾融合、智驾+智舱融合,Zonal EEA2.0将会是一个多样化的架构形态。
区域控制器方面会根据摄像头、雷达、显示、Telematics(4G/5G/V2X/WIFI/GNSS...)等子系统的实车论证结果,进一步朝着就近接入区域的方向发展,形成区域网关。
1.3 Zonal EEA Evolution
经历多样化的Zonal EEA2.0架构形态后,是否再高度整合为一个中央计算平台,即Zonal EEA Evolution阶段,关键还得取决于主机厂对市场的消费引导和Zonal EEA Evolution带来的用户体验,以及目标市场的车型配置情况。目前已有少量主机厂开始了这方面的研究与尝试。
2. 技术挑战
为了实现Zonal EEA,中央计算平台的设计会面临哪些挑战呢?目前看来,主要有以下几方面:
2.1 跨域整合能力
中央计算平台采用高算力的异构芯片,需要在不同芯片上进行整车功能部署、算力/存储等资源的划分。这需要具备网关车身,动力底盘、辅助驾驶等设计经验,并在此基础上进行良好的系统、硬软件架构设计,便于芯片迭代,模块复用及多方软件集成。
此外,还需要建立持续集成与交付的软件开发体系,实现多方软件的快速迭代。同时还需具备完善的仿真测试能力,以支持各功能域的场景仿真,功能集成与验证与问题定位。
2.2 资源池化
中央计算平台由于整车功能和计算的复杂性,必然存在多组MCU/SOC、存储设备以及各种传感器模块,这些资源如果不通过资源池化共享的方式,充分利用,那么中央计算平台仅仅是硬件的堆叠,而失去了Zonal架构设计的初衷。
中央计算平台的可资源池化的有CPU池、存储池及I/O池等;资源池化的性能发挥取决于通信带宽、通信延时和信号转换效率,犹如大脑内部的通信纤维束板-胼胝体,同步大脑左右半球信息。这些通信指标的实现,受制于通信技术的选择和上层通信协议。
SOC片内多核的CPU算力池,目前最好的方式是通过芯片内高速总线和共享内存/IPC直接互通;多组SOC形成的CPU算力池,大容量存储阵列(如SSD…),以及众多传感器资源则需要依赖外部通信技术来支撑互通;如PCIe、Multi-Gig Ethernet、TSN/DDS等多协议的组合应用是解决中央计算平台通信的首选方案和关键技术。
2.3 开放式平台
开发式平台是中央计算平台必须具备的另一特性,也是软件定义汽车思想的落脚点。所谓的开放式平台特征主要反映在两方面:
1)稳定可扩展的硬件系统
从CPU算力、存储容量、接口形式、机械结构各方面,硬件系统都需要具备非常灵活的可扩展性,具备快速衍生以适配各种车型配置。
VCP-整车中央计算平台
2)开放的软件生态
基础软件层面:提供稳定的操作系统,底层驱动,虚拟化环境;依据芯片架构和硬件特性,优化传感器数据处理、AI算法布署,充分挖掘硬件算力,同时保障整车全生命周期的功能安全及信息安全。
中间件层面:应具备统一的中间件技术和服务接口SOA软件环境、标准化的通信协议以及为上层应用做到严格监控和全方面设防,并向上能给应用层提供良好的通信及同步机制,便于应用布署和移植。

源:联合电子

码上报名

WISS 2023 第四届世界物联网安全及数据安全治理峰会火热报名中,3月9-10日,上海

码上报名

AutoSec 2023 第七届中国汽车网络安全周暨第四届汽车数据安全展火热报名中

更多文章

智能网联汽车信息安全综述

软件如何「吞噬」汽车?

汽车信息安全 TARA 分析方法实例简介

汽车FOTA信息安全规范及方法研究

联合国WP.29车辆网络安全法规正式发布

滴滴下架,我却看到数据安全的曙光

从特斯拉被约谈到车辆远程升级(OTA)技术的合规

如何通过CAN破解汽

会员权益: (点击可进入)谈思实验室VIP会员

END

微信入群

谈思实验室专注智能汽车信息安全、预期功能安全、自动驾驶、以太网等汽车创新技术,为汽车行业提供最优质的学习交流服务,并依托强大的产业及专家资源,致力于打造汽车产业一流高效的商务平台。

每年谈思实验室举办数十场线上线下品牌活动,拥有数十个智能汽车创新技术的精品专题社群,覆盖BMW、Daimler、PSA、Audi、Volvo、Nissan、广汽、一汽、上汽、蔚来等近百家国内国际领先的汽车厂商专家,已经服务上万名智能汽车行业上下游产业链从业者。专属社群有:信息安全功能安全自动驾驶TARA渗透测试SOTIFWP.29以太网物联网安全等,现专题社群仍然开放,入满即止。

扫描二维码添加微信,根据提示,可以进入有意向的专题交流群,享受最新资讯及与业内专家互动机会。

谈思实验室,为汽车科技赋能,推动产业创新发展!


文章来源: http://mp.weixin.qq.com/s?__biz=MzIzOTc2OTAxMg==&mid=2247517636&idx=1&sn=f7748f2eb3705ba338750d2cd2260fac&chksm=e927c11fde50480991ed9ce5b394c331d6733c40897345a3ac833e383195dbab5a550deabd4a#rd
如有侵权请联系:admin#unsafe.sh