您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 
 订阅
智能网联汽车多域电子电气架构技术发展研究
 
 
  623  次浏览      17 次
 2023-8-14
 
编辑推荐:

本文聚焦于未来智能网联汽车的多域电子电气架构,并从总体设计、硬件系统、通信系统和软件系统四个方面对现有技术进行了详细的综述,并展望了我国电子电气架构的发展前景。希望对你的学习有帮助。
本文来自于微信公众号焉知汽车,由火龙果软件Linda编辑,推荐。

摘要

随着汽车智能化和网联化技术的快速发展,传统的电子电气架构已经无法满足未来车路云网一体化发展的新需求。本文聚焦于未来智能网联汽车的多域电子电气架构,并从总体设计、硬件系统、通信系统和软件系统四个方面对现有技术进行了详细的综述,并展望了我国电子电气架构的发展前景。

前言

随着车辆电气化与智能化的快速发展,汽车工业与移动计算、泛在车联、人工智能等ICT技术的深度融合加速,引发了汽车数字化以及软件定义汽车的新浪潮,孕育了一种能够实现“人-车-路-云-网”一体化运行的全新智能交通系统,有望极大地提升未来交通系统的运力、能效、安全性和驾乘体验。智能网联汽车(intelligent connected vehicle,ICV)已经成为“人-车-路-云-网”一体化系统中汽车产业升级的必然趋势。ICV配备了智能感知系统、智能决策控制系统和智能执行系统,与通信网络、人工智能紧密结合,可实现车辆与多领域(车辆、道路、行人、云等)间的信息交互。ICV是汽车由传统运输工具向新一代智能终端转型的物理载体,对汽车电子电气架构(electrical/electronic architecture,后文简称E/E架构)的基础设计理论和方法提出了新挑战和新要求,催生了E/E架构技术的新变革。E/E架构技术作为ICV系统设计技术之一,对整车软硬件系统的集成、功能实现、开发成本以及车辆综合性能具有决定性的影响。

汽车E/E架构定义为实现整车功能的汽车电子电气组件的组织结构及其软硬件系统,强调各组件之间以及组件与整车环境之间的相互作用和相互依赖关系,以及指导设计和演变的原则。作为ICV系统本身及功能构成的顶层设计,现有E/E架构面临着一些不足之处,未来的E/E架构设计应该如何满足ICV的复杂需求和适应新技术趋势是汽车领域关注的重要问题。

ICV的E/E架构设计技术面临以下挑战:

(1)在总体架构设计上,现有基于经验的设计流程难以支持全开发周期的高精度设计,需要建立基于模型的设计理论和评估体系,以多元化需求为导向,加强架构软硬综合匹配、功能安全、数据安全和信息安全设计。

(2)在硬件系统设计上,结合车辆功能设计ICV专用的智能控制器,实现高计算能力和低能耗;优化电源系统和线束系统设计理念,降低整车成本和质量。

(3)在通信系统设计上,现有的通信机制难以适应急剧增长的数据传输需求,急需设计高带宽、强实时性和低时延抖动的车载通信机制,加强通信网络的可配置性和多通信协议的可扩展性。

(4)在软件系统设计上,软件功能的差异化和快速迭代将成为核心竞争力。软件定义汽车(software defined vehicle,SDV)和基于服务的软件设计理念成为系统软件设计的基石,设计可解耦、可升级、易配置、高安全性和个性化的软件将成为整车企业竞争的主战场。

上述挑战对E/E架构技术发展提出了重大需求,如何引导E/E架构技术的进一步发展是ICV架构设计亟需解决的重大问题。

本文总体架构设计、硬件系统、通信系统和软件系统四个角度对ICV多域E/E架构研究的关键技术进行了深入分析,并展望了未来的发展趋势。

多域电子电气架构技术现状

根据算力集中程度,本文将E/E架构划分为分布式架构、域集中式架构和中央集中式架构,并详细论述各个架构的特点如下。

1.1 分布式架构

分布式E/E架构根据汽车功能的不同进行划分,每个电子控制单元(electronic control unit,ECU)的设计都基于特定的功能需求展开。在该架构中,各个ECU通过CAN总线进行信息传递,以实现整车的功能。典型的硬件拓扑如图1所示。在这种架构中,每个ECU只负责单一功能的实现,一辆车通常分布着上百个ECU,它们不仅直接驱动执行器和传感器,还承担着复杂的业务功能控制逻辑。这种架构的软硬件紧密耦合,每次扩展一个功能,都需要增加相应的ECU和通信信号。然而,由于ECU的计算能力有限,通信带宽受限,功能升级困难等问题,这种架构存在制约架构升级和影响汽车安全性能的瓶颈效应。此外,随着ECU的增加,车内的线束也会变得更长,增加了整车的质量和成本,同时也给整车的布置和装配带来了很大的困扰。

图1 分布式架构

1.2域集中式架构

随着车载以太网的广泛应用和高算力芯片的低成本大带宽,域集中架构逐渐摆脱了分布式架构在安全性、可扩展性等方面的困境。域集中架构的基本思路是根据功能将多个电控单元(ECU)的功能进行聚类,整车只部署几个域控制器(DCU)作为主控。典型的基于中央网关的域集中架构如图2所示,各DCU负责完成各个域的数据处理与功能决策,并对该域下属的传感器与执行器进行控制管理。域之间通过中央网关交换所需数据,这种架构不仅保证了域间的通信和互操作性,同时也实现了信息安全和功能安全。

图2 域集中式架构

与传统的ECU相比,DCU具备了强大的硬件计算能力和丰富的软件接口支持,使得更多的核心功能模块集中在DCU内,从而提高了系统的功能集成度。单个ECU的作用被弱化,复杂的数据处理和控制功能被统一安排在DCU中,ECU逐步演变为DCU命令的执行器。在通信方面,以太网成为域间通信的骨干网,从而大大提高了通信速率。得益于软硬件解耦、接口标准化以及信号性能的升级,域集中架构代表了架构设计思想从信号驱动模式转向服务导向架构(SOA)的分水岭。在域集中架构中,软件与硬件具备了分层解耦的可行性,系统的耦合度降低,软件的远程升级(OTA)和硬件部署变得更加便捷,同时标准化的接口也使得传感器和执行器模块无需与具体的ECU相对应,从而支持零部件的标准化生产。

1.3中央集中式架构

为了降低车内结构连接的复杂度、提高算力利用率、降低成本、提高安全性,中央集中式架构进一步将域集中架构中的多个DCU融合为一个或多个拥有更强算力的多核异构SoC芯片和多种操作系统组合的中央计算平台(CCP)。车载传感器和执行器不再按照功能部署,而是按照物理位置划分就近接入区域控制器(ZCU)。中央集中式架构的典型拓扑如图3和图4所示。在这种架构中,各采集和执行节点通过ZCU将原始数据传输到一个或多个CCP中进行处理,所有数据处理和决策都在CCP中完成。ZCU主要负责数据采集、通信协议转化和数据传输等功能。多个ZCU之间通过以太网构成环形网络,进一步提高通信冗余和可靠性。按照区域进行传感器和执行器的就近接入简化了构型布置,缩短了线束长度。如图4所示,该架构将整车控制计算功能全部集中到一个CCP中。然而,从目前的技术能力来看,图3所代表的多CCP架构在硬件设计、软件开发和安全冗余等方面都要求更高,因此单CCP架构是当前主流方案。

图3 多中央计算单元的中央集中式架构

图4 单中央计算单元的中央集中式架构

综合来看,E/E架构从分布式架构到域集中式架构再到中央集中式架构的发展带来以下优势:

(1)算力集中化,提高算力利用率。在实际运行过程中,汽车的大部分时间只有部分芯片在执行计算工作,导致分散的独立功能ECU的计算能力处于闲置状态。采用计算集中架构方式可以在综合情况下最大化利用处理器算力。

(2)统一交互,实现整车功能协同。传统的分布式架构中,执行器、传感器、控制器、软件算法等都是紧耦合设计,导致跨部件和跨ECU级别特性的设计和开发效率低,升级困难等问题。集中式架构为软硬件解耦提供基础,减少ECU数量,实现真正意义上的整车级特性开发,便于快速迭代和上市,大幅降低开发和升级成本。

(3)缩短整车线束长度和质量,降低故障率。传统的分布式ECU导致线束较长、复杂纠结,并引发电磁干扰,故障率较高。集中式架构通过实现执行器、传感器等部件的区域接入,缩短线束长度,降低整车质量。

(4)为软硬件解耦奠定基础,支持软件定义汽车。分布式软硬件紧密耦合,难以解耦,而集中式架构实现了功能和算力的集中,为软硬解耦和软件分层提供了条件。

(5)车辆易于平台化,扩展性增强。集中式架构下,ECU的功能被弱化,传感器和执行器接口实现了标准化和通用化,域控制器和区域控制器可以根据需求进行配置调整,以适应不同的传感器和执行器方案。

多域电子电气架构总体设计技术

2.1 架构总体设计的主要任务

传统汽车电子电气架构设计主要关注元器件的合理布局,以实现最佳性能和最低成本。然而,多域电子电气架构不仅要满足传统目标,还需要成为智能网联汽车软硬件的基础设施,支撑汽车系统的功能和性能。ICV多域电子电气架构设计的主要任务包括:

(1)根据车辆功能需求合理划分各子系统功能,明确功能之间的逻辑连接关系,并实现软硬件映射。

(2)在功能交互、成本和供配电等因素之间进行权衡,设计硬件空间拓扑、连接拓扑和通信拓扑。

(3)形成集成控制器、传感器、处理器、线束、功能软件等软硬件的多维度整车系统设计方案。

(4)最终降低系统的重复性,提高系统的可验证性、高集成性、高安全性和可扩展性。

2.2 架构总体设计与评估方法

ICV功能配置的复杂性和多样性引发了电子电气架构设计理论和方法的变革。目前,基于模型驱动系统工程(MBSE)的汽车电子电气架构设计开发方法逐渐受到重视。MBSE从电子电气架构设计的起始阶段就以模型的形式进行表达,对各复杂系统的需求、结构和行为等进行基于图形的无歧义说明、分析和设计,从而在相关设计人员之间建立统一的交流平台。MBSE方法可以解决整车电子电气架构研发过程中的工程数据不一致性、可验证性和可追溯性等问题,降低整车产品开发的难度,尽早发现和避免潜在风险,提高开发效率,降低开发成本和后期维护成本。图5展示了基于MBSE的汽车电子电气架构V字型设计开发流程。

图5 V字型设计开发流程

电子电气架构设计是整车设计的核心任务之一,而电子电气架构评估则是架构方案优化的直接参考依据。综合目前电子电气架构的主流开发设计流程和面向ICV的电子电气架构需求,确定多域电子电气架构总体设计的重点内容主要包括以下5个方面:架构需求定义、架构功能设计、架构拓扑设计、架构系统设计、架构分析评估。

2.2.1 架构需求定义

无论是传统还是多域电子电气架构的开发,都必须从市场需求的角度出发,进行全面的需求分析。基于分析评估,架构需求定义需要确定功能方案实现的目标,制定开发车型的整车需求,明确整车系统和各个子系统的需求,并同时制定出整车验证测试规范。通过需求分析,识别出开发目标和开发约束,是整个架构设计的起点。

2.2.2 架构功能设计

根据架构的需求定义,完成架构的总体功能设计。为了降低电子电气架构的复杂性,需要对总体功能进行细分和切割,并将软硬件进行解耦。常用的功能设计方法是首先将整车功能划分为一级功能域级别,然后对功能域进行详细的二级功能划分,以实现将二级网络中的控制器功能移至域控制器,为后续高级功能的实现提供基础,支持更高级的功能实现。在功能架构设计阶段,需要完成初版网络拓扑、电子电气方案、子系统技术规范和功能方案的设计工作。

2.2.3 架构拓扑设计

根据架构功能,提取架构的基本拓扑结构,包括硬件拓扑架构、连接拓扑架构和通信拓扑架构。通过对拓扑架构的细化优化,输出最优的拓扑方案,为其他设计部门提供软硬件开发的设计规范。硬件拓扑架构主要涉及硬件部件的整车安装布局、内部构成以及对外接口的详细信息,包括部件之间的组合关系和部件的内部细节。连接拓扑架构描述了各部件之间的逻辑连接方式和实现情况,包括具体的导线、线缆连接方式以及保险继电器盒的内部结构等。通信拓扑基于域间/域内不同的通信需求,完成通信网络的组网以及协议的确定。

2.2.4 架构系统设计

根据前面阶段制定的电源分配图、接地点、整车布局以及供应商提供的接口控制文件,架构系统设计需要完成整车原理、接口定义和功能规范的设计,并建立整体架构模型。通过拓扑层信息、已有的开发数据库和经验输入等条件的支持,实现正确的逻辑和算法定义。完成系统级电子电气架构的解决方案制定和系统级验证测试规范制定。最终实现功能的下发,更新到产品部件设计中进行落实和验证。

2.2.5 架构分析评估

传统的车辆电子电气架构很难在装车前实现整车级别的仿真,大多数只能完成部件级别的仿真。但随着RTaW、CANoe和VEOS等商业化架构评估软件的发展,行业已逐步采用更全面的架构仿真评估软件进行功能、通信和安全等方面的迭代验证与优化。在多域车辆电子电气架构的分析评估中,除了传统的硬件成本、开发成本、生产成本、保修成本、车辆性能和燃油经济性等目标外,还需要关注以下新问题:

(1)是否能够满足用户个性化需求以及未来可能的需求变化,尤其是能否满足自动驾驶L3级及以上车辆架构的需求变化;

(2)平台是否具有良好的可沿用性和公用性,能否满足高等级自动驾驶和智能网联的基本技术需求,具备领先的技术先进性。

多域电子电气架构的硬件系统

3.1 功能域控制器及关键技术

为了减少总线长度和ECU数量,以实现减轻电子部件质量和降低整车制造成本的目标,将分散的ECU按照功能进行划分,集成为具有更强运算能力和更丰富接口的功能域控制器(DCU)。现有的技术方案通常将整车划分为车控域、智驾域和座舱域。车控域控制器负责整车动力系统控制、底盘系统控制和车身系统控制。智驾域控制器配置丰富的接口,以满足多种传感器信号的采集,集成高算力异构计算平台来支持复杂的传感器数据融合算法,结合高精度地图和导航等信息进行环境识别和路径规划,并输出整车控制指令,从而实现更高级别的智能驾驶功能。典型的智驾域控制器如图6所示,计算平台上集成了通用计算单元、AI计算单元、实时控制单元和多种接口。

图6 智驾域控制器功能示意图

座舱域控制器通常集成了全液晶仪表、抬头显示器、流媒体后视镜、座舱娱乐系统、车联网和远程信息等功能,并同时充当人机交互接口。智能座舱域控制器需要具备强大的处理能力和复杂的操作系统,由主控芯片、实时微处理器、数字信号处理器、CAN和以太网口等组成,典型功能如图7所示。

图7 智能座舱域控制器功能示意图

3.2 区域控制器及关键技术

区域控制器(ZCU)主要包括区域数据中心、区域IO中心和区域配电中心三大功能,如图8所示。作为区域数据中心,ZCU配备了丰富的网络接口,例如ETH、CAN和LIN,扮演区域网关和交换机的角色,实现网络通信和路由。区域IO中心支持各种类型的传感器、执行器和显示器接口。作为区域配电中心,ZCU负责将电力传输到控制器和执行器等用电设备。目前,倾向于使用电子保险丝(eFuse)替代传统的继电器和熔断丝方案,以实现智能管理。同时,ZCU具备吸收区域内其他ECU功能的能力,在服务层面对区域内的功能进行抽象,实现控制I/O的虚拟化。由于涉及到对安全性、实时性和可靠性要求较高的车辆控制功能,ZCU的主控芯片通常配备ASIL-D级别的MCU,未来发展趋势是引入高算力计算单元。

图8 区域控制器功能示意图

3.3 中央计算单元及关键技术

中央计算单元的核心定位是提供充足的算力,以支持智能驾驶和智能座舱相关的业务逻辑。同时,它需要具备高带宽和低时延的通信能力,以支持与区域控制器之间的数据交换,并能够实现车辆的网联功能,连接到车端和云端。在硬件层面上,中央计算单元通常采用多颗异构多核SoC芯片,芯片之间采用高速串行通信或者PCIe进行连接。SoC芯片的架构主要分为硬件隔离式和软件隔离式两种形态,都采用虚拟化方案来同时运行多个操作系统。硬件隔离式在软件设计阶段确定各个核心运行的操作系统,并在硬件上进行隔离,拥有专属的硬件资源。而软件隔离式中,操作系统没有专属的硬件资源,硬件资源由Hypervisor层进行动态调配。

3.4 电源系统及关键技术

随着整车电气负载的增加、电气架构的发展和半导体技术的突破,电源系统的设计已经从电源部件的组合转变为电源网络的系统设计和电源网络的控制设计。传统的车载电源系统通常采用中央电气盒的方案,电路的控制和保护使用继电器和熔断器,但存在继电器烧蚀和熔断器损毁后无法再利用的问题。目前,电源系统的主要技术路线是保护和控制的融合,使用基于MOSFET的eFuse进行配电。单个芯片集成了驱动、电流检测、热保护、过压保护、过流保护、EMC以及开路短路等各种诊断功能。

3.5 线束系统及关键技术

线束对整车电器电子功能的实现起着至关重要的作用,也是架构优化设计的研究热点。在线束布置的总体设计中,需要充分考虑各种相关的边界条件,并充分考虑各个相关组件对线束布置可能产生的影响,并对相关组件的设计提出相应合理的要求。目前,线束系统的设计趋向于成熟化和全面化,基于PREEvision软件展开的多维度、多目标线束建模、设计、评估和优化方法极大地简化了线束系统的设计过程,提高了设计效率,提升了设计效果。

多域电子电气架构的通信系统

4.1 车载通信系统的发展和现状

车辆的电子电气架构依赖于通信系统来实现硬件之间的信息传递。目前主要存在五种通信技术:控制器局域网(CAN)、局域互联网(LIN)、面向多媒体的系统传输(MOST)、FlexRay总线和车载以太网(ETH)。5种通信技术的主要特征如表1所示。

表1 各通信技术特性表

除了这些通信技术之外,还有一些正在试验阶段的新型车载通信技术。例如,第三代CAN通信技术CAN XL,它缩小了CAN与以太网之间传输速度和耦合的差距,能够与以太网共同在基于信号的通信和面向服务的通信之间提供连接。在未来,车载通信系统的安全性和保密性将受到重视,光纤通信具有抗电磁干扰、无辐射、难以窃听等优点,将在车载通信安全、故障诊断和高精度控制等领域具有广泛应用。

随着汽车智能驾驶等级的不断提高,车载元器件数量呈指数级增长,信息数据量不断增多,对车载总线网络的传输速率、实时性、容错率和成本提出了更高的要求。虽然CAN总线受到传输数据量少和时间不同步的限制,但其技术成熟度较高,目前仍然是车载总线技术的支柱。而LIN总线、MOST总线和FlexRay总线通常根据其自身特点作为局域网络接入。以太网凭借其高带宽和低成本的优势,将成为通信系统的骨干网络,在未来引领下一代车载网络的发展。目前来看,要形成一个统一的车载总线协议标准仍需要较长时间。因此,在这之前,车载网络系统仍然需要采用多总线并存的方式来满足不同的传输需求,进一步完善各种车载总线标准的兼容性和互操作性,以实现更好的数据交换和系统集成仍然是多域电子电气架构需要解决的关键问题之一。

4.2 时间敏感网络通信协议的分析和研究

随着高精度传感器的广泛部署和信息娱乐系统功能的不断增强,车内数据量急剧增加,传统的车载网络难以有效支持和处理不断增长的高速率、高带宽通信需求。时间敏感网络(Time Sensitive Network,TSN)被认为是解决以上问题的关键方案,它能够实现数据在以太网中的确定性、实时性、低延迟和高安全传输。

TSN能够实现低成本大带宽传输,传输速率可达10 Mb/s至10 Gb/s,并且使用非屏蔽双绞线实现全双工通信,相比传统的屏蔽线缆成本降低了80%,质量减轻了30%。此外,TSN还具有良好的扩展性和通用性,能够支持多种构型的车载网络拓扑结构,实现不同应用数据的传输。

对车载通信具有重要影响的TSN协议可以分为四种类型:时间同步、流量控制、可靠性和资源管理。接下来将对这些协议进行详细介绍。

4.2.1 时间同步类协议

在部署了TSN的多域电子电气架构的通信系统中,需要有一个统一的时间标度来保证时间同步的精度。TSN的IEEE 802.1AS-2020协议对TSN流的时间同步方法和过程进行了定义和解释。通过时间戳机制,所有组件受同一全局时钟控制,同时允许网络中存在不同时域。对该协议的研究主要包括同步精度的影响因素、本地时钟校正和同步质量评估等。

在多域电子电气架构中,时钟同步精度是保证各个传感器实现高精度响应和定位外部环境的基础。虽然目前有大量研究针对工业TSN的时钟同步,但缺乏专门针对车内TSN时钟同步特性的研究。车内通信环境与工业自动化系统有很大差异,车辆的振动、温度变化、电磁干扰等因素会对时钟同步的精度造成干扰。因此,需要进一步研究车内TSN时钟同步精度的影响因素,以确保实现车内通信系统的高可靠性和高效性。

4.2.2 流量控制类协议

流量控制是实现TSN低时延传输和流确定性的关键技术之一。TSN的流量控制过程包括流量分类、流量整形、流量调度和流量抢占,对应的TSN协议如表2所示。

表2 流量控制类协议表

目前流量控制类协议的研究热点领域主要包括:各类流量最大端到端时延分析,TSN流量整形方法研究和时间关键流的流量调度方法研究。目前的研究主要集中在单一协议,下一阶段需要围绕协议间的协同作用机制以及协议在实际车载网络场景下的应用开展。

4.2.3 可靠性协议

TSN的可靠性指的是网络对故障的预防和恢复能力,主要包括IEEE802.1CB和IEEE802.1Qci协议。IEEE802.1CB设置了帧的复制和消除(FRER)机制,降低了流传输时帧拥堵或故障带来的影响。主要针对控制类帧,严格限制丢包率,保证传输的可靠性。IEEE802.1Qci设置了帧的过滤与报错(PSFP)机制,针对网络出现故障时流的处理问题,避免了流量的过载和错误交付,提高了系统的鲁棒性。TSN可靠性问题的研究主要包括冗余机制、故障检测以及同步故障下的可靠性。后续研究应重点关注车辆TSN网络在各种故障情况下的可靠性,确保车辆在行驶过程中的安全性和稳定性。

4.2.4 资源管理类协议

资源管理的主要功能包括对网络资源进行管理和配置,以及对性能数据进行监测和分析等。IEEE802.1Qat流预留协议解决了流的注册与预留问题,是进行整形、调度和传输等过程的前提。IEEE802.1Qcc协议解决了TSN网络的集中管控问题,提出了分布式、集中式和集中网络分布用户式3种TSN网络管控模型。目前的研究主要围绕架构模型的实现和部署方案展开。这些研究成果为车辆TSN网络资源管理的实现提供了重要的技术支持和借鉴。后续研究应重点关注如何实现车载TSN的管理与配置,重点突破事件触发流等随机流的管理、车-云安全交互管理等关键难题。

TSN作为多域E/E架构的重要组成部分已经受到了充分的重视。然而,目前对TSN的研究主要集中在工业互联网领域,车载TSN网络的研究还不够深入。在技术迁移过程中,存在几个亟待解决的难点:

(1)场景构建问题:大数据和多种类的车载TSN网络模型构建较为复杂,难以对事件触发的随机信号流进行建模。

(2)功能匹配问题:如何设计软件来实现TSN的相关标准,以及TSN协议在车载场景下的执行情况和效果如何,需要进行实验验证。

(3)硬件支持问题:目前支持TSN以太网的芯片相对较少,也没有针对车载TSN的专业测试设备,搭建硬件实验平台较为困难。尽管面临重重困难,但无法否定TSN在车载实时通信应用方面的潜力。未来,TSN的带宽优势有望进一步提高;车载TSN与IP协议的结合将使更多更复杂的车载安全和多媒体应用成为可能;随着自动驾驶等级的提升,TSN的可靠性将随着车载网络信息安全性的提高而得到进一步提升;TSN协议的开放性也为学术研究和工业部署提供了更广阔的空间。

4.3 基于服务的软件定义网络

传统的车载网络存在以下问题:流量负载分布不均衡、报文发送延迟大、网络吞吐量低、网络模块兼容性差和开放性低。这些问题不利于进一步的开发和创新,也不利于未来各车型智能车载系统的互联互通。为了解决这个问题,提出了软件定义车载网(SDVN)的概念。SDVN将软件定义网络技术(SDN)应用到车载网络中,用软件定义网络的思想改造车载网络的体系结构。首先,SDVN将车载网络设备中的数据转发平面与控制平面分离开来,然后将所有的控制平面集中到一个逻辑上集中的控制器中,最后利用这个集中的控制器控制车载网络中所有数据转发平面报文的转发行为。SDVN能够有效提高网络性能、降低网络服务更新的代价、简化网络管理、加速网络创新。目前,基于服务的SDVN还处于起步阶段,在安全性、移动性、服务效率、部署和标准化等方面还有许多亟待解决的关键技术问题。但SDVN作为一种可编程和高灵活的网络架构仍具有很好的发展前景,可被应用于高效带宽分配、车-路-云弹性算力分配等多种场景。

综合上述,未来车载通信网络将具有以下特点:

(1)未来车载的通信协议将向着大带宽、低成本、高安全的方向发展,车载TSN将成为骨干网络,提供确定性、高带宽和高安全的连接,现有总线形式在某些特定场景仍将保留。

(2)为应对智能驾驶带来的挑战,车载网络将实现更多的安全功能,SDVN的应用将进一步提高网络的可配置性和灵活性。

(3)不同通信软件组件之间的接口将进一步标准化,软件的互换性将显著提高。

多域电子电气架构的软件系统

5.1 软件定义汽车

5.1.1 SDV的基本理念

随着功能的不断增加,车辆设计的核心逐渐从硬件设计转移到软件开发。软件成为塑造整车厂竞争力的核心要素。SDV的概念已成为产业界的共识,软件的开发和升级将成为贯穿设计、销售和服务的车辆全生命周期的关键组件。基于SDV的汽车整车开发流程将形成用户交互评价信息指导新车开发、OTA技术实现软件持续更新迭代的双闭环模式。基于服务的软件架构如图9所示。该软件架构一般被分为4层。

图9 基于服务软件架构

SDV的重要优势在于减少了硬件差异对软件的影响,从设备抽象层与原子服务层的软件设计追求多车复用与减少差异化。通过API标准化接口,减少重复劳动,降低软件的复杂度,提高软件的设计开发效率。在应用层的设计则重点打造差异化与定制化功能,最终实现软件组件的高附加值与个性化服务。同时,SDV和OTA技术的出现对汽车整车开发流程也带来了新的变革。

5.1.2 软硬件解耦与映射

SDV实现的重要前提是软硬件解耦,它是指软件系统的设计完全独立于硬件,在软件框架中通过对硬件接口进行抽象化处理来兼容不同硬件设备。软硬件解耦的关键在于接口定义的标准化,这需要整个汽车产业合理分工,通力配合,形成统一的软硬件接口定义技术规范。实现软硬件解耦对未来汽车开发、验证和售后都将产生重要影响。首先,软硬件的解耦使得数据被从一个个子系统中解放出来,整车厂对功能实现的控制能力增强,这将对产业分工产生重要影响。其次,软件可以脱离硬件进行独立验证,原本需要通过硬件在环测试的功能可以通过集成硬件环境的软件在环测试进行验证,这将极大地加快整车开发与测试速度,降低验证成本。另外,汽车全生命周期的可升级将有效提高汽车售后的可维护性和安全性,通过远程升级(OTA)软件可以逐步解放功能,有效增强用户体验和提高汽车保值能力。然而,目前受到传统研发模式、企业转型困难以及产业分工矛盾的影响,软硬件的解耦仍然与理想状态相去甚远。

伴随着软硬件解耦而来的是软硬件映射问题,由于DCU和CCP需要集成包括传感器数据处理、智能人机交互和高精度控制决策等众多功能于一体,数据处理的复杂度骤增。如何将不同数据运算特点的功能软件映射到匹配的处理器,实现软硬件的协同最优是软硬件映射需要解决的核心问题。多域E/E架构引入了多种微处理器、大量异构计算资源与通信链路组合,使得需要考虑的因素进一步复杂。早期的研究通常根据任务通信关系和属性,考虑时间、成本以及功耗等因素对单核异构系统进行软硬件映射。随着多核嵌入式芯片的发展,大量研究针对多核分布式异构系统软硬件映射问题提出优化设计方法,优化目标包括能耗优化和硬件成本优化等。车载多核异构芯片对于成本、功耗、安全、算力和实时性等因素极其敏感,如何综合考虑以上因素,根据功能设计专有芯片结构,并实现易于解耦的软硬件映射是未来车载主控芯片设计需要突破的关键难题。

5.2 面向服务的软件设计

面向服务的体系架构(SOA)是汽车产业从IT产业引入的先进理念,以其可重用、易升级、易部署和松耦合的特点,被认为是ICV汽车软件发展的重要方向。SOA的理念是通过灵活的接口使服务不再局限于特定的功能环境,实现服务共享。在这一理念中,接口的定义需要遵循SOA标准,独立于操作系统与硬件平台。这与之前提到的SDV原子服务层和设备抽象层的概念相辅相成。SOA的引入打破了传统汽车软件固化、封闭的生态,使之逐渐开放、开源。

目前,汽车产业已经进行了与SOA软件设计相关的实践,并提出了基于SOA的软件开发模式,验证了SOA可以显著降低系统复杂度,简化不同代汽车之间的软件组件的重复使用。

为了保证各系统服务之间的信息互通和组合形式的扩展,各服务模块之间通过基于服务的中间件进行通信,从而改变了车内通信方式。传统的基于信号的通信方式在车辆设计时就完成了通信矩阵的定义,信号的数据量、发送周期和路由路径都是固化且静态的。而基于服务的中间件则通过在应用程序和网络之间进行一定的抽象,建立起服务与应用之间的网络连接。这种通信过程通常是动态的,在运行时可以进行配置,而不需要在设计时进行固化。

目前主流的面向服务的中间件主要包括DDS(data distribution service)和SOME/IP(scalable service-oriented middleware over IP)。它们在AutoSAR中都被集成为标准化模块,因此被行业视为一流的解决方案。下表3对比了SOME/IP、DDS和基于信号驱动的通信机制。

表3 通信机制对比

5.3 车用操作系统

车用操作系统是车内系统程序的集合,其主要功能包括管理硬件资源、隐藏内部逻辑以提供软件平台、提供用户程序与系统交互接口以及为上层应用提供基础服务等。它包括车控操作系统和车载操作系统两大类。

5.3.1 车控操作系统

车控操作系统主要分为安全车控和智能驾驶两个子类操作系统,其基本架构如图10所示。安全车控操作系统主要面向传统车辆底盘、动力、车身等功能领域,具有极高的实时性要求和ASIL-D级别的安全性要求。目前主流的安全车控操作系统大多兼容OSEK和AUTOSAR Classic Platform(AUTOSAR CP)标准软件架构,相关技术已相对成熟。基于AUTOSAR CP的操作系统软件开发相较传统方式,实现了应用层和底层软件以及软件和硬件的解耦,从而在一定程度上增强了软件的移植、复用、扩展、升级、安全和维护等能力,对于减少软件开发周期和降低成本起到了有益作用。

图10 车控操作系统基本架构

智能驾驶操作系统则面向新一代集中式E/E架构升级背景下,对高算力、高性能、高安全性和高可靠性的智能驾驶功能提出要求。此类操作系统目前正处于发展机遇期,各国都在初步探索阶段。由于AUTOSAR CP难以完全适应智能驾驶操作系统的需求,基于此,AUTOSAR组织在2017年发布了基于POSIX PSE51子集的操作系统与应用程序之间标准编程接口规范的面向服务架构的AUTOSAR Adaptive Platform(AUTOSAR AP)以应对异构芯片平台上车辆智能驾驶服务的需求。

在车控操作系统领域,国内外的大部分企业都基于AUTOSAR开发自己的系统,可以说AUTOSAR软件架构标准在车控操作系统领域起到了关键的引领和参考作用,是目前国际上主流的汽车标准软件架构。基于AUTOSAR标准的软件架构实现离不开相应配置工具链解决方案的支持。目前主流的工具链包括德国Vector公司的面向AUTOSAR CP的DaVinci系列工具和面向AP的MICROSAR Adaptive;Bosch旗下子公司ETAS的面向CP和AP的RTACAR和RTA-VRTE。此外,还有ElektroBit公司的EB tresos、EB corbos系列CP和AP配置工具;Siemens的Capital VSTAR,KPIT的KSAR Classic、KSAR Adaptive等。国内也积极布局AUTOSAR,普华基础软件、东软睿驰等相继推出各自的AUTOSAR解决方案,助力国产化工具链的实践落地。

5.3.2 车用操作系统

车用操作系统主要应用于车辆中的信息娱乐功能,对安全性和实时性要求相对较低,因此在这个领域的发展非常迅速。当前主流的车用操作系统在实时性、安全性和应用场景等方面进行了比较,如表4所示。

表4 各类车载操作系统功能属性对比

随着智能化和互联化的不断深入发展,单一的车用操作系统已经无法满足不断丰富的车内信息娱乐功能需求,因此车用操作系统逐渐向多操作系统架构过渡。多操作系统架构主要有两种实现方式,一种是基于硬件隔离的架构,另一种是基于虚拟化管理技术(Hypervisor)的架构。硬件隔离架构通过在物理层面上进行硬件分区,简化了相应的资源分配管理问题,易于开发。然而,固定的硬件分区可能导致灵活性较差,并且可能造成一定程度的资源浪费。而基于Hypervisor进行多操作系统隔离和管理可以避免系统资源的固定分配,提高资源利用率。此外,它利用主机内存作为数据交互媒介,显著提高了数据共享能力。但是,同时也增加了系统开发的复杂性和安全风险。

研究展望

当前,关于智能网联汽车(ICV)的多域电子/电气(E/E)架构研究正日益增多。各国学术界和工业界都在进行大量的研究,并且一些大型汽车制造商已经在先进车型上进行了初步部署。然而,由于E/E架构涉及的要素综合性和复杂性,目前还没有形成一套完备的E/E架构设计理论、工程方法以及工具软件。因此,建议进一步加强以下研究方向。

(1)加强架构总体设计理论和方法的研究

目前业界的架构开发仍然主要依赖于工程经验,但随着功能的复杂化、需求的多元化和迭代的快速化,仅凭经验很难得到最优的设计效果。因此,需要尽快形成完整的设计理论和方法,从总体设计理论到工程实践应用,为架构总体设计提供指导。未来的研究应该从ICV的E/E架构设计问题的本质出发,研究实现安全性、经济性和可扩展性的设计机理。通过理论分析和试验验证,可以梳理汽车功能需求、安全需求与架构设计之间的内在联系,完成需求的规范化建模和功能的准确分割。基于现有的主流架构和技术水平,可以开展架构建模、系统优化和分析的研究,形成架构设计的理论和方法。

(2)构建软件、硬件和通信接口的标准体系

架构设计涉及到车内的软件、硬件和通信系统,以及与车外的车端、路端和云端的互通。各类接口复杂多样,单一厂商很难完成所有接口的端到端设计。只有形成软件、硬件和通信接口的标准体系,才能让产业链各方充分发挥自身优势,使整车厂能够根据架构总体设计框架进行集成和灵活配置,推动ICV的快速落地。在自顶向下的服务设计上,标准化接口应使应用层和通信层开发专注于业务逻辑,不受限于硬件实现;在自底向上的抽象设计上,应使底层硬件设备能够关注不同车型差异,具备通过对配置的灵活更改以减小代码差异的能力。

(3)开发E/E架构的仿真测试验证体系

E/E架构的仿真评估技术是验证设计合理性和实现快速迭代更新的基础。因此,需要建立多层级、一体化、虚实结合的E/E架构测试验证体系。可以开展融合虚拟仿真、封闭场景和开放道路测试的多环境交互技术研究,研发适用于失效分析和风险评估的E/E仿真场景库挖掘和重构技术,开发实时性评估仿真分析平台,实现架构评估和仿真测试的平台化和标准化。同时,还需要针对硬件在环和实车在环测试的物理信号高保真和实时模拟技术,开发网联场景下的通信信号模拟装置,逐步建设多层级的E/E架构测试验证体系,形成部件级、系统级和整车级多层次的测试评价方法,实现E/E架构测试验证体系的一体化设计。

(4)加强多维度冗余架构体系设计与信息安全纵深防护技术研究

为了应对ICV架构失效的隐蔽性和突发性难题,需要针对冗余架构体系下的传感器、控制器和执行器层面进行故障检测方法和主动重构控制理论的研究,探索高效精准的故障检测方法,建立完善的主动重构控制机制,确保在一定故障下ICV仍具备正常行驶能力。为了确保高级别自动驾驶系统的网络安全、数据安全和信息安全,需要从外部网联安全、域间控制安全、车载网络通信安全和控制器本体安全等多个维度出发,构建多层纵深防御体系,构建纵深防护技术理论,既保证系统安全,又降低冗余度和系统复杂性。

(5)加速ICV核心部件产业链的国产化进程

我国在ICV领域已经具备了先发优势,但在高算力芯片、车用操作系统和架构设计工具软件等方面,与欧美等发达国家相比仍存在一定差距。虽然出现了大量国产化方案,但其功能完整度和产业支持配套相对较弱,尚未形成完整的国产化产业链。因此,当前我国需要进一步加快关键技术的国产化研发,将先发优势转化为领跑实力,努力发展具有独立自主特色的中国汽车产业,提高自主品牌的竞争力,推动我国汽车产业向高质量发展迈进。

总结

多领域电子/电气(E/E)架构对于智能连接车辆(ICV)的普及和实现其预期功能具有重要意义。然而,在目前阶段,该领域仍然缺乏完善的方法论、技术理论体系和工具链,行业仍处于摸索和研究阶段,需要进行大量的研究和实践。

 

 

 

 
   
623 次浏览       17
相关文章

手机软件测试用例设计实践
手机客户端UI测试分析
iPhone消息推送机制实现与探讨
Android手机开发(一)
相关文档

Android_UI官方设计教程
手机开发平台介绍
android拍照及上传功能
Android讲义智能手机开发
相关课程

Android高级移动应用程序
Android系统开发
Android应用开发
手机软件测试

最新活动计划
MBSE(基于模型的系统工程)4-18[北京]
自然语言处理(NLP) 4-25[北京]
基于 UML 和EA进行分析设计 4-29[北京]
以用户为中心的软件界面设计 5-16[北京]
DoDAF规范、模型与实例 5-23[北京]
信息架构建模(基于UML+EA)5-29[北京]
 
 
最新文章
简述Matplotlib
Python三维绘图--Matplotlib
Python数据清洗实践
PyTorch实战指南
Python爬虫与数据可视化
最新课程
Python应用开发最佳实践
Python+数据分析+tensorflow
Python 编程方法和应用开发
人工智能+Python+大数据
Python及数据分析
更多...   
成功案例
某通信设备企业 Python数据分析与挖掘
某银行 人工智能+Python+大数据
某领先数字地图提供商 Python数据分析与机器学习
北京 Python及数据分析
某金融公司 Python编程方法与实践培训
更多...