1.引言
Classic AUTOSAR是经过验证并在全球广泛应用的行业标准,过去二十年来一直是车载软件开发的重要基础。该标准从针对特定微控制器的标准化嵌入式软件组件的理念发展而来,目前几乎100%的车辆都采用了该标准。Classic AUTOSAR标准涵盖广泛的应用领域,从控制简单的车内温度传感器到对安全至关重要的线控转向系统,再到具有实时处理功能的复杂驾驶员辅助软件,是汽车中间件的首选。
随着软件定义汽车 (SDV) 概念的兴起,汽车软件的开发方式正在发生转变。从以往依赖嵌入式开发和V模型的传统流程,逐步迈向持续集成、持续部署、持续测试 (CI/CD/CT) 以及更加灵活高效的敏捷开发方式。在整个生命周期中,现代汽车需要不断接收软件更新、新功能、错误修复和安全补丁。所有这些都需要经过测试,才能最终推广到车队。与此同时,现代数字化车辆所需的软件数量不断增长,而所有软件的开发都必须在预算范围内按时完成。
“左移”理念[1]描述了这一变革趋势——将大量测试环节向软件在环 (SiL) 测试迁移,以减少对复杂、昂贵且资源有限的硬件在环 (HiL) 测试的依赖。通过虚拟方式完成数百万公里的测试(而非使用昂贵的测试车队),并在开发早期发现车载软件问题,能够显著缩短产品上市时间并大幅降低开发成本。
“左移”解决了汽车软件面临的主要挑战:
软件数量和复杂性不断增加
软件开发高度依赖硬件
多供应商协同开发的需求
ECU虚拟化和软件在环测试正在成为汽车行业掌握车载软件的关键能力。汽车制造商对整个供应链日益增长的需求印证了这一趋势,供应商在交付真实ECU的同时提供虚拟ECU已成为新常态,且该趋势正在向更深层次发展。全新的电子/电气架构开发早在硬件或芯片可用之前就已启动,利用即将推出的芯片组和架构的完全虚拟化模型,最终实现硬件与软件的解耦,以充分利用软件定义汽车的优势。
Elektrobit是AUTOSAR软件的领先供应商,与Molex(汽车行业公认的应用、软件和硬件供应商)和 Synopsys(仿真工具的行业领导者)共同开发了完全虚拟化的软件开发和测试工作流程。 将“左移”理念应用于Molex商业无线充电软件平台可加快开发时间,提高测试代码覆盖率,并显著提升开发人员的体验。
Molex无线充电平台
Molex开发并生产了一款车载手机互联应用平台,包括无线充电、NFC通信和以及手机与车载天线的耦合功能。 该平台支持CAN FD、诊断和电源管理器等汽车接口,可根据汽车制造商的特定需求进行定制。
Molex平台符合Classic AUTOSAR标准,使用Elektrobit的EB tresos AutoCore作为底层汽车中间件。 在Classic AUTOSAR术语中,Molex平台被称为软件组件 (SWC),而EB tresos AutoCore则是基础软件 (BSW),二者共同构成运行在手机互联ECU中央处理器上的固件包。
图1.无线充电ECU的软件架构
Elektrobit “EB tresos AutoCore” 中间件
EB tresos AutoCore Generic (ACG) 是EB tresos系列产品之一。EB tresos产品系列为ECU开发提供高效、可扩展且符合AUTOSAR标准和OSEK/VDX标准的产品。EB tresos包含ECU基础软件 (BSW)、单核/多核操作系统、功能安全和信息安全解决方案以及配置工具。
Elektrobit提供的ACG基于兼容AUTOSAR分层架构,且包含与硬件无关的基础软件模块和运行时环境 (RTE)。ACG与包含MCAL和操作系统等硬件专用模块的板级支持包 (BSP) 相结合,构成了实时ECU基础软件的完整解决方案。
Synopsys Silver
Synopsys Silver是一个虚拟ECU平台,使开发人员能在个人电脑上完成ECU软件测试等开发任务,而以前这需要测试平台或测试车辆才能进行 [2]。在Silver仿真环境中运行的虚拟ECU是针对主机电脑编译的,从而能够实现高效且易用的开发与调试。该平台兼容MATLAB/Simulink等常用仿真工具及标准,并提供汽车网络仿真层。为了实现基于AUTOSAR的软件架构的无缝切换,Silver还集成了丰富的AUTOSAR MCAL及AUTOSAR实时操作系统仿真环境。
2.Molex ECU平台
Molex正在将无线充电平台引入其他芯片组。尽管AUTOSAR在设计上遵循硬件无关标准,但在实际项目中仍存在部分硬件依赖性。比如特定芯片组的硬件特定功能需要用到复杂的设备驱动 (CDD),操作系统里也可能包含一些硬件相关的功能。因此,迁移会影响整个软件栈,包括Molex应用程序以及Elektrobit的底层汽车中间件 (Classic AUTOSAR)。
Molex在此迁移项目中面临五大挑战:
尚无可用硬件
硬件测试装置昂贵且不可扩展
基础软件配置难以测试
测试覆盖范围有限
测试速度仅限于实时
尚无可用硬件
硬件可用性方面存在多重限制因素,一种是微控制器本身不可用,另一种是包括外设在内的ECU电子设备不可用。二者都可能成为开发项目的限制因素。新设计通常采用最新一代芯片来实现最新功能,并尽可能延长集成电路的可用时间。最初这些组件仅作为工程样品提供,且数量非常有限。ECU的电子板本身也需要经历开发过程,包括原型硬件和不同样品阶段,在整个开发过程中生产的数量同样非常有限。
在本项目中,Molex平台将改用新一代微控制器。可用的评估板数量有限。新ECU的电子设计进度更为滞后,因为它仍处于硬件设计阶段。硬件可用性显然是这一平台迁移项目的瓶颈。
硬件测试装置昂贵且不可扩展
专用实验室测试装置需要昂贵的硬件和软件组件,如逻辑分析仪、调试器、可控电源等。这些测试台需要专门设置和维护,而且由于其原型特性,容易出错。通常这些设备仅在特定地理位置提供,且数量极为有限。并不是每位开发人员都能使用这些测试平台,或者需要提前很长时间预约才能使用该设备。当与合作伙伴共同开展项目时,这一可扩展性问题会变得更加严重,因为测试装置涉及需要在不同公司之间共享的A、B 或C样品。
基础软件配置难以测试
该项目的基础软件配置使用了4万多个参数,运行环境承载了38个互联的软件组件,这些组件还与其他ECU上运行的组件进行通信。这导致平台团队需要投入大量精力来维护汽车制造商规格和变体的基础软件配置。因此,团队经常会遇到因配置参数设置错误、任务优先级问题或启动和集成代码问题而导致的问题。由于目前没有支持基础软件 (BSW) 与应用层软件 (SWC) 独立测试的配置,因此很难重现错误条件,且无法测试基础软件所有必要的内部状态。
测试覆盖范围有限
由于软件测试采用以硬件为中心的方法,且测试装置的可用性有限,因此在每次分支集成时只能执行较低比例的测试。 在这种情况下,回归错误可能无法被发现,而验证团队往往要到流程后期的主线完整测试运行时才能检测到这些问题。开发团队希望更早地获得反馈,并在分支合并回主分支之前运行更高比例的测试。
图2. 平台软件开发人员的测试装置
Molex平台开发团队的目标是将这些由变更引起的回归减少到接近零,使每个开发人员始终能够自行运行完整的测试套件,从而在开发过程中节省大量成本和时间。
测试速度仅限于实时
硬件装置上的测试必须实时运行;通常需要在多个装置上通宵运行,才能在第二天早上获得测试结果。然而,随着测试用例数量不断增加,有时甚至一个晚上也无法完成一轮完整的测试。这就形成了一个盲区——即在测试结果尚未出炉时,新的软件开发工作却已展开。
Molex与Elektrobit和Synopsys共同启动了ECU虚拟化项目,以支持其无线充电平台向新芯片组的迁移,应对传统开发流程的挑战,并充分发挥虚拟化的核心价值优势。
3.Classic AUTOSAR的ECU虚拟化原理
虚拟ECU是ECU的模型,可以用来在仿真环境中测试其软件。虚拟ECU的优势在于其易于设置、可扩展性强,并可在故障注入场景中提供开箱即用的支持。虚拟ECU是软件在环测试工作流程的基础。根据虚拟ECU所需的保真度和测试覆盖范围,用户可以选择四种不同的虚拟化级别,如图3所示。
图3. ECU虚拟化级别
本案例研究采用三级虚拟化技术[3],基于Synopsys Silver虚拟ECU平台实现。该平台采用主机编译方式,将软件编译为能在仿真环境中本地运行的程序,极大降低了运行时资源消耗,从而提高了执行效率。三级虚拟化涵盖了与硬件无关的基础软件和应用程序的正式代码。根据测试需要,微控制器抽象层、复杂设备驱动程序和操作系统等硬件专用模块将被仿真等效模块或或桩模块替代。应用程序组件则由测试桩替代。
三级ECU虚拟化特别适用于加速基础软件中硬件无关功能的测试周期,例如诊断通信、基于信号的CAN通信和模式管理。
4. 在Molex平台项目中部署虚拟ECU
由于AUTOSAR基础软件采用分层架构,除MCAL和操作系统外的所有模块都与硬件无关,无需任何改动即可在虚拟ECU中重复使用。工作流程包括以下部分:
虚拟化基础软件栈
应用程序与复杂设备驱动的桩模块化
创建虚拟ECU构建环境
基础软件虚拟化流程如图4所示。无线充电ECU的起点是目标硬件(即32位微控制器)的配置项目。集成商使用EB tresos Studio为其配置和生成代码。为了支持虚拟ECU,需额外安装一个板级支持包(含适用于Synopsys Silver的MCAL与操作系统插件,如紫色框所示)。现在,用户可以将配置项目迁移到Synopsys Silver,形成图右侧所示的项目设置。
图4. 基础软件虚拟化工作流程
如图5所示,EB tresos Studio的项目资源管理器中现在显示两个ECU配置项目可用。 第一个项目(tresos-project-nextgen)包含微控制器的目标项目,而tresos-pro-ject-nextgen-vecu则包含通过迁移步骤从前者衍生而来的虚拟项目。对于所有与硬件无关的模块,两个项目中的模块及其配置完全相同。 而MCAL模块(如下面截图中的CAN)则有所不同。不过,配置已从目标项目导入到虚拟项目。
图5. EB tresos Studio中的目标和虚拟项目
完成第一步后,所有带有AUTOSAR接口的应用软件组件都将被桩模块替代,测试框架可以轻松控制这些桩模块,以确保软件正常启动,并触发测试所需的测试边界情况。
最后一步,即构建配置,需要调整多个Make文件,以便使用具有适当设置的本机编译器进行构建,确保虚拟ECU中重复使用正确的文件。
5. 使用ECU虚拟化
引言中强调了ECU和嵌入式软件开发项目中常见的五大挑战:
尚无可用硬件
硬件测试装置昂贵且不可扩展
基础软件配置难以测试
测试覆盖范围有限
测试速度仅限于实时
通过这个参考项目,Molex、Elektrobit和Synopsys将ECU虚拟化确立为核心技术,并引入全新开发流程来应对这些挑战。
可扩展的虚拟测试台(带加速功能)
Molex虚拟ECU现已投入使用,实现了“从硬件在环 (HiL) 到软件在环 (SiL)”的迁移。图6展示了测试装置以及通过添加虚拟ECU作为被测设备对现有Molex测试装置的扩展。虚拟测试台可提供ECU的数字与模拟输入/输出信号,这些信号以虚拟ECU信号形式呈现,并能像变量一样被访问。SiL仿真可选择连接到一个或多个真实ECU,以运行混合测试台。当需要验证部分仍处于早期设计阶段的系统时,此类混合配置尤为实用。
图6. 测试框架可通过切换配置从虚拟ECU切换到真实ECU
在纯虚拟执行模式下,虚拟测试台中的每个参与组件都与Synopsys Silver生成的仿真时间同步,Synopsys Silver将仿真分割成可配置时长(通常为毫秒级)的宏步骤。这样,在仿真复杂到主机无法以实时速度执行的情况下,就能以加速因子执行仿真,缩短测试运行时间,并确保行为的一致性。
升级后的设置可通过Synopsys虚拟CAN总线及虚拟传感器/执行器信号,复用现有Molex测试框架与测试用例,完成无线充电ECU的验证。
图7所示为Synopsys Silver的图形用户界面。左侧项目区域为仿真中所有模块的列表。 右中部的主SiL区域为可用于显示和修改仿真中的信号和数值(本例中为诊断请求内容和车速)的部件。 右下角区域为用于配置模块和仿真的选项卡列表。在下面的截图中,我们可以看到仿真的性能指标,如当前的加速因子。
图7. Synopsys Silver中的仿真
由于接口开放,Synopsys Silver具备高度可扩展性,可兼容多种行业标准工具。例如,如图8所示,其总线监控模块支持通过Wireshark捕获虚拟网络流量。利用这些功能,用户能够监测虚拟网络的流量,并分析各参与组件的行为。
图8. Wireshark中的CAN FD流量
由于虚拟ECU是本地Windows二进制程序,因此可以使用gdb和Visual Studio Code等标准工具进行调试、跟踪和覆盖范围检测,就像其他Windows应用程序一样。堆栈跟踪和观察点等功能开箱即用,且无需额外成本。
提高测试深度和频率
通过该虚拟ECU测试环境,平台团队现在能够不依赖硬件验证车辆软件,且无需更改任何测试代码。这在以前是无法实现的。只需调整测试配置,现有的测试用例就能与虚拟ECU而非实际ECU进行交互。 这显著节省了开发时间,因为同一套测试用例现在可同时适用于虚拟ECU和真实ECU。虚拟测试装置可供所有开发人员使用,并可根据需要在环境中进行设置。 在开发电脑上进行本地设置与集成到自动化CI/CD/CT管道和其他基础设施中一样简单。为项目添加新成员不再需要漫长的购买和硬件设置过程。
通过将虚拟ECU集成到持续构建和持续测试管道中,平台团队现在能够在每次合并验证时执行测试,使他们能够切换到稳定分支工作流程。这是持续交付工作流程的先决条件。
总之,虚拟ECU和SiL测试的引入意味着开发人员可以在几分钟内验证新功能。团队现在可以用更少的资源、更快的速度开发出有价值的功能和错误修复。全栈测试(包括闪烁和性能评估)仍然需要在HiL环境中进行验证。不过,与以前相比,系统集成团队在HiL环境中修复错误的时间节省了50%以上。新的SiL工作流程有助于Molex确保软件在更早的时间点达到更高的成熟度,从而加快产品上市时间,同时降低开发成本。
6. 虚拟化技术解锁软件定义汽车
要满足汽车行业客户的需求,提高创新速度和加快产品开发至关重要。在嵌入式软件开发过程中利用虚拟化技术,是实现软硬件解耦的关键,这不仅可以在芯片流片前阶段就开始软件开发,还可以使整个组织和全球各地的所有开发人员和部门都能使用测试装置。
对Molex平台实施ECU虚拟化(目前已投入使用的商业解决方案),为了解汽车行业对虚拟化的期望和要求以及日常使用中的实际经验提供了宝贵的洞察。
该项目历时4周,团队仅专注于Classic AUTOSAR的三级虚拟化,以生成Molex解决方案的主机编译虚拟ECU。 Synopsys Silver被用作虚拟ECU仿真工具,并用作与目前用于测试真实目标的现有Molex测试框架连接的接口。虚拟ECU构建工作流程与真实目标硬件的构建工作流程无缝集成,以简化工作流程的维护,并使开发人员能够轻松利用虚拟ECU的优势。所需的主要工作包括对现有Molex平台的分析,以及虚拟ECU的初始构建,该构建需要替换MCAL(微控制器抽象层)并对CDD(复杂驱动器)进行桩模块化处理。
本案例研究展示了虚拟化概念与现有Classic AUTOSAR平台的成功集成,建立了统一的工作流程来构建真实和虚拟目标,并将其无缝集成到单一测试框架中。通过在软件开发工具箱中添加三级虚拟ECU,Molex无线充电项目可以更快地让新开发人员上手,在本地电脑上执行AUTOSAR基础软件配置测试,并且能够脱离稀缺的开发硬件独立开展工作。该团队拥有更便捷的汽车软件开发体验,就像本地Windows或Linux应用程序开发一样,无需昂贵的硬件即可实现更强大的调试和跟踪功能。通过全虚拟装置,调试变得更加容易;设置断点时会暂停整个测试台,使开发人员能够分析仿真中每个节点的状态。软件功能现在可以在虚拟环境中进行验证,甚至可以在系统层面进行验证。
虚拟ECU与真实ECU配置比较:
表1. 虚拟ECU与真实ECU测试对比A
只有有效控制汽车电子电气架构固有的复杂性,才能实现将软件打造为核心竞争力的软件定义汽车。实践证明,虚拟ECU在汽车软件开发的加速、自动化和规模化方面发挥着至关重要的作用。 充分运用“左移”理念,有助于大幅提升嵌入式系统软件开发的效率与现代化水平,为实现软件定义汽车奠定坚实基础。
关于作者
Wolfgang Thieme
系统与云解决方案产品管理总监
Elektobit Automotive GmbH
Simon Durr
虚拟化首席架构师
Elektrobit Automotive GmbH
Marcus Schäfer
运输创新解决方案部工程师
Molex GmbH
Stefan Thiel
嵌入式软件和系统首席产品经理
Synopsys Inc.
-
AUTOSAR
+关注
关注
10文章
382浏览量
22824 -
ecu
+关注
关注
14文章
940浏览量
56041 -
汽车软件
+关注
关注
1文章
133浏览量
3515 -
Elektrobit
+关注
关注
0文章
34浏览量
3846
原文标题:白皮书 | 基于Classic AUTOSAR的ECU平台虚拟化技术洞察&案例研究
文章出处:【微信号:Elektrobit官方,微信公众号:Elektrobit】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
Autosar软件开发技术概述
一款基于FPGA的汽车ECU设计
AUTOSAR架构深度解析 精选资料推荐
为什么使用AUTOSAR呢
基于AUTOSAR规范的汽车ECU软件开发方法

基于CANoe和Visual Studio实现Classic和Adaptive AUTOSAR应用层调试
Classic AUTOSAR的软件架构和方法论
基于Classic AutoSAR平台进行SOA和以太网的设计
一文读懂DDS和AUTOSAR Adaptive的集成
映射DDS和AUTOSAR类型系统实现
为什么选择自适应AUTOSAR平台?
Vector和HighTec推出基于Rust和AUTOSAR Classic实现安全应用的解决方案

评论