关于软件定义汽车技术体系的思考与思考结构
发表时间:2023-11-28 16:02:15
文章来源:炫佑科技
浏览次数:181
菏泽炫佑科技
关于软件定义汽车技术体系的思考与思考结构
车辆架构正在向基于通用计算平台的面向服务的架构发展。 未来,车辆的差异化将更多地体现在软件和先进电子技术赋能的用户交互界面和体验水平上。 软件将推动汽车技术创新并引领产品差异化。 软件定义汽车(SDV)是大势所趋。
软件定义汽车特指以人工智能为核心的软件技术决定车辆功能,以模块化、通用化硬件平台为支撑的未来汽车。
软件定义汽车功能的增加和升级可以通过软件的远程部署和更新来实现。 汽车硬件将成为模块化、通用化的平台和资源库,支持车载软件的多元化开发和部署。
软件定义汽车受到了行业内外的广泛关注,但目前尚未有文献提出软件定义汽车的车辆开发、车辆物理结构、车辆信息结构,也没有明确的软件定义汽车架构技术体系。 本文提出软件定义车辆开发、车辆物理结构、车辆信息结构,总结提出软件定义车辆技术体系。
本文的结构如下:**章讨论软件定义车辆的发展; 第2章讨论软件定义车辆的物理结构; 第3章讨论软件定义车辆的信息结构; 第4章提出软件定义车辆技术体系; 第五章结束。
1. 整车开发
1.1 车辆开发流程
1.1.1 传统车辆开发流程
传统车辆开发流程车辆开发流程定义了车辆从概念设计到产品设计、工程设计、制造直至*终转化为产品的整个过程中各业务部门的职责和活动。 它是构建汽车研发体系的核心。
传统汽车开发流程一般包括规划阶段、概念设计阶段、工程设计阶段、样车测试阶段和量产阶段。 目前,国际汽车厂商的研发流程已有成熟的模板。 图1显示了通用汽车全球汽车开发流程。
图1 永汽汽车全球整车发展历程
1.1.2 软件定义车辆开发流程
软件定义汽车的整体车辆开发流程仍然包括上述五个阶段,但有以下显着差异。 软件开发比重将大幅提升。 据摩根士丹利预计,未来软件价值可能占比60%左右。 此外,大众汽车表示,到2030年,软件开发成本将占到汽车开发成本的一半左右。
软件和硬件开发解耦但持续协作,如图2所示。软件定义汽车通过软硬件开发的有效解耦和持续协作,使软件的开发、验证和交付独立于车辆硬件开发进度,软件产品可以在开发的各个阶段立即发布。
图2 硬件解耦、持续协作
硬件开发正朝着架构化、模块化、工具箱化战略发展,如图3所示。目前国内外各大车企在整车开发中都注重平台化发展,实现不同产品子系统和零部件的通用化。 架构和模块化的概念基于平台化。 当平台太多时,就会导致冗余和浪费。 通过研究平台之间的关系,可以形成统一的架构来集成各个平台。 平台化的概念侧重于物理通用部件,而架构的概念侧重于设计过程的同质化和制造过程的模块化。 工具箱策略是指无论车辆尺寸和性能如何,都可以通过现有车辆开发工具箱中的模块集成来组装和组装各种车型。
图3 大众平台模块化策略(图片来自大众)
从发展战略与汽车等级的关系来看,平台化是单一汽车等级的协同作用。 共享底盘部件等策略仅适用于特定汽车等级的开发。 架构化、模块化,适合多车级发展。 ,工具箱策略涵盖了汽车各个层面的发展需求。
以用户需求为导向的定制开发。 软件定义汽车将从单一的交通工具转变为用户的第三生活空间,车辆开发将更加关注用户需求,以用户为导向。
软件定义车辆的开发流程形成双闭环。 **个闭环是指交互评价数据的收集和用户画像的构建来指导新车的开发。 另一个闭环是指利用OTA技术实现用户使用阶段的软件持续更新和迭代。 在车辆的整个生命周期中,软件迭代过程不断进行,因此整车的开发成为一个至关重要的、持续不断的开发过程,直至车辆报废。
总体来说,软件定义车辆的开发流程是一个双闭环的开发流程,包括车辆开发和软件迭代,如图4所示。车辆开发主要指新车的开发阶段,一般包括规划阶段、概念设计阶段、工程设计阶段、样机测试阶段、量产阶段等; 软件迭代主要是指用户使用阶段,通过交互评价数据收集、用户画像构建指导软件开发,并利用OTA远程升级等技术进行远程软件更新迭代。
图4 部分定义汽车双闭环整车开发流程
1.2 整车开发模型
1.2.1 传统车辆开发模式
传统的整车开发模型是V型开发模型,如图5所示。V型左边是需求分析,右边是模块测试。 可以在软硬件模型完整构建之前完成集成测试方案设计,有效保证测试方法与相应模块的兼容性,高效定位测试问题。 但传统V型开发模式中“整车-系统-子系统-软硬件”的开发设计顺序仅限于需求导向明确的整车开发,难以适应快速迭代的需求软件定义的汽车功能。
图5 传统汽车整车开发模型
1.2.2 软件定义车辆开发模型
软件开发在软件定义车辆开发模型的构建中发挥着重要作用。 在传统的迭代软件开发模型下,每次迭代都会遍历需求分析、分析设计、测试等过程,并产生*终产品的子集。 多周期的持续迭代让产品更能适应不断变化的需求。 此外,敏捷开发、螺旋式开发等软件开发模式也可以提高软件产品的开发效率。
软件定义车辆开发模型如图6所示,它将结合传统软件开发和车辆V型开发模型的优点,具有快速迭代、持续集成、并行开发、多平台应用和用户个性化。
图 6 零件定义车辆开发模型
在软件定义汽车开发模型中,首先进行系统解耦分析,将整车解耦为子系统进行需求分析。 然后进入持续集成开发阶段,以“设计-开发-测试-发布”的重复循环进行,不断集成软件。 硬件集成到系统主干并*终发布。 在持续集成开发阶段,各种开发工具平台如CARLA等的适用性可以大大提高车辆开发的效率。
车辆投入使用后,根据用户反馈进行快速迭代,再次遍历“系统需求分析-持续集成”流程,通过OTA技术完成功能发布。
软件定义车辆开发模式继承了传统软件开发模式的优点。 通过并行开发、持续集成,高效利用多种开发工具平台的优势,可以大幅提高整车系统的开发和测试效率。 同时,采用快速迭代的软件开发模式可以*大程度地满足用户的个性化需求,让车辆开发贯穿整个产品生命周期。
2.车辆物理结构
车辆物理结构具体指车辆的物理硬件和机械结构,包括动力系统硬件、底盘硬件、传感器、控制器、执行器、车身和座舱等。
2.1 传统汽车的物理结构
传统汽车的物理结构主要由发动机、底盘、电气设备、车身四部分组成,如图7所示。发动机是传统汽车的心脏,为汽车提供动力。
图7 系统化车辆硬件架构组成
底盘负责支撑和安装发动机及其零部件、总成,形成汽车的整体造型,承受发动机的动力,保证正常行驶。 电气设备负责起动控制、点火控制、照明和信号系统、电气辅助控制等,主要包括蓄电池、发电机、起动系统、照明和信号系统、信息显示系统、辅助电气系统、电控系统等车身包括车窗、车门、驾驶舱、乘客舱、发动机舱、行李舱等。
2.2 软件定义了整车的物理结构
软件定义车辆的物理结构主要包括动力系统、环境感知系统、决策规划系统、控制系统、智能座舱等。
值得注意的是,软件定义车辆的物理结构具有可定义性和可定义级别。 软件定义车辆的物理结构作为通用硬件资源池,支持各种软件功能的实现。 软件定义根据软件功能的类型和复杂程度有不同的层次,从而对车辆的物理结构有不同的要求。 因此,车辆的物理结构可以通过软件来定义。 车辆物理结构的可定义级别越高,车辆能够支持的软件功能就越多、越复杂。 从车辆开发的角度来看,车辆物理结构的可定义级别将成为一种开发选择,可以针对不同需求的用户群体进行专门开发,促进车辆硬件开发的定制化。
下面简要概述软件定义车辆物理结构的主要组成部分。
(1)电源系统
近年来,多国相继出台禁售燃油车或支持新能源汽车的政策。 电气化具有促进能源多元化、提高能源转换效率、具有较大减排潜力等优点。 是汽车动力系统未来的发展趋势。 在我国,新能源汽车包括纯电动汽车、插电式混合动力汽车和燃料电池汽车。 与传统汽车基于发动机的动力系统相比,未来的软件定义汽车将基于上述电气化动力系统。
(2)环境感知系统
自动驾驶技术是车辆智能化的核心体现,主要包括环境感知、决策规划和车辆控制三个部分。 软件定义车辆的物理结构将涵盖环境感知系统、决策规划系统和控制系统。
环境感知系统主要包括车身状态感知、交通状态感知、车辆对所有交通参与者(V2X)网络通信等。
车身状态感知主要包括车速、角度传感器、组合导航系统等,通过传感器获取车辆的实时运行状态,并作为输入信息提供给后续模块。
交通状态感知主要包括各种环境感知传感器,如摄像头、激光雷达、毫米波雷达、超声波雷达等。多个传感器可以通过数据融合技术克服单个传感器的缺点,提高感知的整体性能。
V2X网络通信使车辆能够与外部车辆(车对车通信,V2V)、道路设施(车对路通信,V2I)和行人(车对行人通信软件开发,V2P)进行通信。 V2X网络通信强调车辆、道路和用户之间的连接,通过实时获取交通信息来提高安全性和效率。
(3)决策规划系统
决策规划系统硬件主要是高性能计算单元,如CPU、GPU、FPGA、ASIC等。在车辆行驶过程中,计算单元负责处理实时传感器采集的数据。
在自动驾驶算法的前期研究阶段,可以采用工业计算机进行集中计算。 其集中式计算架构有利于初期算法开发,但其体积大、功耗高、不适合量产的缺点也限制了进一步的应用。
嵌入式域控制器适合算法更加成熟后的自动驾驶计算解决方案。 软件定义汽车的内部计算量显着增加。 通过将汽车划分为功能域,每个域包含一个域控制器,负责该域内的计算,可以减少模块和功能之间的相互干扰,提高安全性。
此外,融合固化算法生产专用芯片,可以有效集成传感器和算法,直接处理原始数据,从而减轻后端计算平台的计算负载,降低芯片功耗。
(4)控制系统
控制系统负责控制车辆的速度和转向,使车辆遵循预先规划的速度曲线和期望的路径。 传统的控制方法包括PID控制、滑模控制、模糊控制、模型预测控制、自适应控制、鲁棒控制等。
与传统车辆相比,线控技术将更多地用于控制车辆转向、制动、油门等,其主要特点是执行机构与操作机构之间没有直接的机械连接,由驾驶员的驾驶意图决定。将直接转换成相应的电信号驱动执行器的精确运动。 线控系统技术需要对底盘进行线控改造。 目前具备自适应巡航控制、紧急制动、自动驻车等功能的车辆可以借用原有系统,无需过多修改,并可通过车辆网络进行控制。
(5)智能座舱
未来,汽车驾驶舱有巨大潜力成为用户的第三生活空间。 新一代通信技术、人工智能、大数据、人机交互、汽车芯片和操作系统等技术进步将推动智能座舱不断发展,成为软件定义汽车物理结构的重要组成部分。
3、车辆信息结构
车辆信息结构具体是指车内涉及车辆内外信息通信、软件功能等的结构,包括车辆电子电气架构、车载网络、软件架构、车联网等。
软件定义的车辆信息结构自下而上可分为三层:车辆电子电气架构与车辆网络、软件架构与车联网,如图8所示。车联网支撑车内信息通信,软件架构实现特定的软件功能,车联网实现车内网络、车间网络、车内移动互联网的融合。
图8 软件定义车辆信息结构3层架构
3.1 车辆电子电气架构及车载网络
3.1.1 传统汽车电子电气架构及车载网络
传统汽车电子电气架构的发展主要经历了三个阶段,如图9所示。
图9 传统汽车电子电气架构发展史
**代分布式电子电气架构采用点对点链接。 第二代分布式电子电气架构,实现功能模块化。 第三代分布式电子电气架构增加了中央网关,以实现更广泛的不同功能子系统。 通信,如图10所示。
图10 第三代分布式电子电气架构
车载网络与电子电气架构的发展密切相关。 现有的主要车载网络类型如表1所示。
表1 主要车载网络
控制器局域网络(CAN)是一种汽车专用总线标准,主要用于控制数据传输。 它是目前汽车行业使用*广泛的标准。 本地互联网(LIN)是一种低成本通用串行总线,主要用于车门、天窗等控制。 面向媒体的系统传输总线(MOST)主要用于多媒体流数据传输。 车载网络主要用于底盘系统应用,例如容错环境中的线控制动。
分布式电子电气架构给汽车行业带来了巨大的变化,但这种架构的缺点和局限性也越来越明显,比如底层ECU代码兼容性差、代码冗余、代码复用性差、维护困难等。和更新。 此外,软件定义汽车对高带宽、低时延的需求大幅增长,目前的总线网络已经不能满足需求。
3.1.2 软件定义汽车电子电气架构及车载网络
目前正在开发的新一代电子电气架构是基于域控制器和以太网通信网络的集中式电子电气架构,如图11所示。该架构可以改善传统电子电气架构和车载网络的问题,适应软件定义车辆要求。
图11 集中式电子电气架构
集中式电子电气架构仍然分为功能域。 每个功能域都包含一个功能强大的域控制器(DCU)。 域控制器集成了复杂且相对集中的功能,并集成了网关功能。 域控制器的核心优势在于其芯片计算能力的大幅提升。 强大的计算能力使得域控制器能够接管域内ECU的信息计算和处理功能,集中汇总和统一处理ECU的数据信息,并对处理后的数据进行处理。 这些信息被发送回ECU执行,这也将促进ECU集成度的提高。
基于域控制器的集中式电子电气架构,采用以太网作为骨干通信网络。 CAN、LIN等传统车联网以太网可以保留在域控制器下,以节省成本。
以太网具有高带宽,采用灵活的星形连接拓扑结构。 每条链路可独享100Mb/s及以上带宽。 以太网标准开放、简单,适应未来汽车与外界海量通信和网络连接的发展趋势。 以太网灵活且带宽可扩展,适合连接各个子系统,促进车辆系统的网络化运行和管理。 以太网可以减少时间、生产和服务成本并促进工业实施。
基于域控制器的集中式电子电气架构和基于车载以太网的车载网络,可以满足软件定义汽车对信息处理计算能力和网络带宽的新需求,实现高计算能力,支持持续升级软件应用,增强与云的融合。 协调的分布式计算能力。 因此,基于域控制器的集中式电子电气架构和基于车载以太网的车载网络非常适合成为软件定义汽车的电子电气架构和车载网络。
3.2 软件架构
3.2.1 传统汽车软件架构及发展趋势
传统汽车电子系统软硬件耦合在一起,ECU软件的开发和测试依赖于硬件,开发和测试难度大,灵活性差。
基于此,人们提出了标准来满足日益复杂的汽车软件需求,在不同的硬件平台上使用类似的软件解决方案并共享软件组件。
采用分层架构,微控制器层分为三层,即应用软件层、中间件RTE和基础软件层,如图12所示。
图12 系统架构
分层架构实现了软硬件模块的独立。 中间运行环境RTE有效隔离上下层软硬件,提高软件开发和测试效率。
自动驾驶技术的电子电气架构需要具有高性能计算能力的控制器。 当前控制器的计算能力和通信带宽需要巨大的升级。 高性能计算能力(高吞吐量、高通信带宽)不仅需要异构多核处理器、GPU加速等硬件架构支持,还需要适配新的软件架构,支持跨平台计算处理能力和高性能微处理器。 控制器计算、远程诊断等。此外,V2X通信应用涉及大量数据的动态通信和有效分发,需要软件架构支持云交互和非系统集成。
它无法适应这些新的需求,所以它就在它的基础上出现了。 基本架构如图13所示,主要包括应用层、操作层和基础服务层。
图13 系统架构
对于高性能计算处理器架构来说,其硬件层具有更高的计算能力和更高的吞吐量。 在保证安全级别、降低少量实时性的同时,可以满足非实时架构系统软件需求,大幅提升高性能计算处理能力,支持大数据并行处理和智能互联应用功能。
并且架构可以实现不同应用场景的共存和协作。 未来的汽车很可能采用异构软件架构,包括 和 。
3.2.2 软件定义汽车软件架构
软件定义汽车软件架构如图14所示。软件定义汽车软件架构将继承AV和AI的优势,不仅支持高安全性、高实时性的应用场景,还支持大数据并行处理和高实时性的应用场景。 -性能计算应用场景。 在结构上延续软件分层架构,根据不同的解决方案设置和软件开发需求设置不同的概念层。
图14 软件定义汽车软件架构
软件定义汽车的中间件将促进应用与硬件分离,承担车辆改造、软件安装和升级的功能,促进软件抽象和虚拟化,推动汽车向服务化架构转变。
软件定义汽车的底层操作系统对于车企来说具有重要的战略地位。 未来,缺乏自己操作系统的车企可能只能成为代工企业。
3.3 车联网
软件定义汽车将向汽车侧完全自主的智能网联汽车发展。 如图15所示,智能网联汽车属于智能汽车和车联网的交叉点,因此车联网将成为软件定义汽车车辆信息结构的重要组成部分。
图15 智能汽车、智能网联汽车、车联网等关系
车联网是指车联网,是物联网技术在智能交通领域应用的产物。 车联网可以实现车与车、车与路、车与人、车与服务平台的全方位网络连接,全面提升汽车智能化水平。
4、软件定义汽车技术体系
本节提出软件定义汽车技术体系,如图16所示。软件定义汽车技术体系一般包括车辆物理结构、车辆信息结构、车辆功能层、软件开发、硬件开发、评价体系等。
图16 软件定义汽车技术体系
车辆物理结构层主要包括电子硬件,车辆硬件等。车辆物理结构层用作模块化和通用平台和资源池,可为车辆信息结构和车辆功能层提供基础支持。 软件开发过程侧重于用户分析,敏捷开发,定制开发等,主要使用OTA和其他技术进行远程软件部署和更新。 车辆信息结构包括车辆互联网,软件架构,车辆电子和电气架构以及车辆网络。 软件体系结构是一个分层体系结构,包括应用程序软件层,中间件,基本软件层等。车辆功能层包括特定的车辆功能,例如信息娱乐功能,智能的人类计算机交互,自主驾驶功能,系统更新和升级,系统更新,系统更新,系统更新,系统更新,系统更新,系统更新,系统更新和等等。在用户使用期间,可以通过评估系统评估车辆功能,包括主观评估和客观评估。 通过用户分析和评估数据反馈,结合了人工智能和大数据分析等技术,构建了用户肖像,以进一步指导软件开发。
软件和硬件在结构和开发中有效地分解。 在整个过程中,车辆功能的定义和实现主要由软件驱动。 车辆的物理结构不再集成并绑定到特定功能,而是将软件和服务共享的资源池抽象,从而使车辆由软件定义。
通常,软件定义的汽车技术系统具有以下关键特征:车辆的软件和硬件的解耦,车辆物理结构的普遍支持,车辆的物理结构的确定性,车辆功能的软件可确定性以及车辆可以远程迭代升级软件,并可以收集交互的数据和评估。
车辆软件和硬件的解耦是指在结构和开发级别上的软件和硬件的解耦,从而释放软件并提高软件开发效率。
车辆物理结构的普遍支持性意味着车辆的物理结构成为模块化的通用平台和资源池,并能够支持多样化的车辆软件开发和部署。
车辆物理结构的确定性使车辆的物理结构根据其软件定义的程度不同。 可确定的水平成为开发选择,使车辆的物理结构灵活且可自定义,以满足各种需求。 。
车辆功能的软件定义意味着车辆功能将主要由软件定义和实现,这是软件定义的汽车的基本含义和目标。
车辆软件的远程迭代升级意味着该软件可以通过OTA和其他技术进行远程迭代升级,从而更改了产品使用模型和车辆开发模型,从而使车辆具有全循环的活力。
互动和评估的数据可采性是指收集用户交互和评估系统数据以实现用户分析并满足个性化自定义需求的能力。
软件定义的汽车是一般趋势。 本文分析并提出了软件定义的汽车开发,车辆物理结构和车辆信息结构关于软件定义汽车技术体系的思考与思考结构,并总结并提出了软件定义的汽车技术系统。
在软件定义的汽车技术系统中,软件定义的汽车双关环开发过程和并行开发模型深入渗透到软件和硬件开发中,使汽车成为可行的产品,使车辆可以在整个车辆中迭代地延续生命周期和车辆的物理结构有效地与车辆信息结构分离。 车辆功能的定义和实现主要由软件驱动。 车辆的物理结构不再绑定到特定功能,而是将软件和服务可以共享的资源池抽象。 支持多元化的软件开发和部署,以实现由软件定义的汽车。
炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等