虚拟控制器（vECU）的开发与测试
作者：老榴出品：汽车电子与软件摘要：在过去的二十年中，汽车软件的需求和应用急剧增长，随之复杂性急剧上升，现有技术和框架不足以应对这种复杂性。现在很明显，汽车制造商（OEM）必须重新考虑他们生产车辆的方式 ...
以下为文章全文：(本站微信公共账号:cartech8)
汽车零部件采购、销售通信录 填写你的培训需求，我们帮你找 招募汽车专业培训老师
 作者：老榴 摘要：在过去的二十年中，汽车软件的需求和应用急剧增长，随之复杂性急剧上升，现有技术和框架不足以应对这种复杂性。现在很明显，汽车制造商（OEM）必须重新考虑他们生产车辆的方式以及车辆本身的生命周期。通过将重点放在软件上，OEM可以在车辆整个生命周期中实现许多新的应用用例，并打开一个充满机遇的新世界。 01.软件定义汽车以及虚拟化技术 1.1 软件定义汽车的概念 移动出行时代，汽车已逐渐从纯粹由机械驱动的硬件转变为软件驱动的电子产品。当今不同车厂的产品硬件配置已逐渐趋同，在成本和功能改善空间有限的情况下，传统汽车价值链的重构势在必行。车厂打造差异化的核心要素已转向原先与硬件深度耦合的汽车软件，随着汽车软件在新能源和智能化领域不断取得成功，迈入“软件定义汽车（Software Defined Vehicles，SDV）”时代已成为行业共识。“软件定义汽车”即软件将深度参与到汽车的定义、开发、验证、销售、服务等过程中，并不断改变和优化各个过程，是汽车从基于硬件的产品向软件为中心的电子设备不断转变的结果。 “软件定义汽车” 从表面上看是车内软件（包括电子硬件）的数量、价值超过机械硬件，背后更多的反应了汽车从高度机电一体化的机械终端，逐步转变为一个智能化、可拓展、可持续迭代升级的移动电子终端。为实现这一目标，整车在标准操作程序前便预埋了性能超前的硬件，并通过OTA在生命周期中逐步解锁和释放功能和价值。在该背景下，主机厂的核心能力将从机械硬件转向电子硬件和软件；产业价值链也将从一锤子硬件销售转向持续的软件及服务溢价。 1.2 汽车软件发展的趋势  汽车“新四化”离不开软件和算法随着新四化的深入发展，汽车正加速从从机械设备向高度数字化、信息化的智能终端转变。 首先，软件及汽车电子占整车的研发成本逐步提高，车内软件和电子硬件价值有望超过硬件，成为整车价值的核心。据测算，预计到2030年软件成本占整车BOM（物料清单，Bill Of Material）的比重将从目前不到10%增长到50%。需指出的是，这里的软件除应用程序开发、还包括AI算法、操作系统，以及软硬件一体化程度高的控制器、芯片等电子硬件。 其次，软件及软件更迭所带来的性能和功能变化，将决定未来汽车的差异性。软件的更新维护是未来主机厂提供差异化体验、提升客户满意度最经济、最便捷、最快速的一种方式。前提是由硬件提供冗余，再由软件实现迭代。 最后，包括主机厂、零部件企业等产业链上企业将加强软件能力建设，并围绕“软件定义汽车”开启从产品开发模式、组织架构、人员构成、运营体系等的内部变革。此外，新兴的软件公司将借助软硬件协同能力，兼容产业链上下多方需求，一举跃升为汽车产业链上新的Tier-1企业。1.3 汽车研发面临的困局  首先，分布式电子电气架构无法满足未来更高车载计算能力的需求。驱使EEA架构升级的另一个推动因素来自于更高的通讯效率和更大的带宽容量需求。成本管控黑洞：随着车内ECU、传感器数量增加，整车线束成本和布线难度也跟着大幅提升。 另外，汽车软件的模块化、平台化程度低，导致软件资源无法集中调度、协作性差。主机厂的ECU通常来自于不同的零部件供应商，事实上控制器上许多底层软件的重复性很高，这些代码主要保障控制器的正常运行，例如CAN总线信号的收发、任务进程的调度、Flash数据的读写等等。但碍于每一家供应商的软件编程语言不同、接口标准不同，而且软件又和硬件高度依赖，使得这些底层代码无法被复制和移植，从而造成ECU软件开发的大量重复和资源利用的低效。  基于以上技术架构方面的变化，在软件定义汽车的背景下，汽车研发将由传统的瀑布式开发向敏捷开发的模式转变。 敏捷软件开发（Agile software development）：包括需求发现和解决方案改进。该模式通过自组织和跨职能团队与用户协作，制定适应性计划，进行渐进开发、早期交付、持续改进，灵活应对需求、能力的变化以及对需要解决问题的理解的变化。这是一种以用户需求进化为核心的迭代、循序渐进的开发方法。工程师先将用户最关注的软件原型做出来进行交付，根据用户在实际场景中反馈的问题，快速修改弥补需求中的不足。上述过程不断迭代，直至用户满意。 汽车软件开发将遵循IT行业的发展规律，引入中间件技术、虚拟化技术来实现软件模块化、硬件抽象化和标准化，从而进一步解锁软硬件的耦合关系，满足电子电气架构灵活、可拓展的需求。  那么软件在环SiL有什么应用场景呢？其应用场景通常是在快速变更的功能需求下敏捷开发及快速迭代。要求尽早进行软件验证并发现和纠正代码中的重要错误，特别是涉及安全相关错误。在高频率OTA云端升级软件的情况下自动化持续验证。在以上场景下软件在环SIL测试能够脱离硬件而快速验证控制器的功能代码。  软件在环SiL的最关键的一个核心就是虚拟化：即通过将真实控制器转化为虚拟控制器，部署到PC上集成环境和联合仿真平台，接入CI/CT/CD自动化流水线，并上云端进行大规模测试，从而搭建完整的DevOps的SiL平台。 虚拟化技术使得在Windows PC上对汽车ECU（Electronic Control Unit，电子控制器单元）进行闭环仿真成为可能，能有效改善ECU开发过程。一些开发任务得以从道路、测试平台和HIL（Hardware in the Loop，硬件在环）转移到PC上，缩短开发时间和成本。  02.vECU虚拟控制器集成 2.1 虚拟控制器的介绍 虚拟控制器简称vECU (即Virtual ECU)，表示脱离真实硬件依赖后基于PC独立编译和运行的软件，vECU所包含的内容通常可由ASW,vBSW,vCDD以及RTE这几个部分构成，在集成编译后封装成基于PC的可执行文件。  对于功能测试验证工程师，通常他会拿到一个带有软件的完整ECU控制器，并以硬件在环或实车环境作为测试环境进行测试，整个测试过程可能受硬件和线束的限制，每当遇到软件的失效时首先需要考虑线束或者硬件通信上的问题，长此以往测试效率通常受硬件资源和硬件状态的限制，难以在受限的条件下高效的完成测试。但是如果仅ECU内与硬件无关的功能，只需解耦ECU产品代码并封装成vECU运行在PC上进行测试即可。数据采集和验证过程同真实环境软件测试工具一致，如INCA、Debugger调试器等等。 而对于功能开发工程师来说，验证功能时需要在完整ECU软件上进行集成并验证功能，该集成过程通常由软件集成工程师负责，软件集成该功能同时还需要考虑ECU 平台化升级、底层芯片配置等诸多因素导致迭代效率低下的问题。其实对于其生成的ECU功能代码，依然可以将这一部分代码封装成一个部分功能的vECU并进行仿真测试。并且你可以在任意时间终止仿真并进行Debug，还可以在功能验证过程中根据需要对vECU做预标定从而提前验证预设标定数据。 简而言之，就是将控制器C代码基于PC环境编译后生成FMU格式的可执行文件运行在常规PC仿真环境上，以更早和更快的方式进行测试及调试。2.2 虚拟控制器的分类生成虚拟控制器的方式有两种，一种是通过C源码经过PC的x86编译器后生成可以运行在PC上vECU目标文件，并于PC上进行系统测试和验证后反馈给研发工程师。另一种是将C源码编译成目标芯片的程序（hex文件）后，运行在目标芯片的指令模拟器上来进行系统测试后再将结果反馈给研发工程师。  如上图所示，Type-1 vECU, Type-2 vECU, Type-3 vECU为第一类通过C源码的构建方式生成的vECU，Type-4为第二类通过目标程序运行在目标芯片指令模拟器的方式实现vECU。  FMI的全称叫Functional Mockup Interface 。FMI是为了仿真领域定义的。FMI 定义了二进制的标准格式仿真模型交换。FMU 数学模型的代码实现就是将提供的 C 头文件里面定义的函数都实现，如果需要做到源码保密，则将其封装成动态链接库 .dll 就行。  一般商业化的仿真工具比如 CarSim、CarMaker 、AVL Cruise、Amesim和Simulink 、ASCET等都由官方提供 FMU。在 FMI 官网上列出了目前提供了 FMU 的软件可以在以下路径找到https://fmi-standard.org/2.4 vECU自动化生成流程以ETAS的VECU-BUILDER为例，这是一个基于Python和CMake的Windows工具。  为了创建一套生成PC Target的虚拟控制器FMU 文件，我们需要有一套软件集成和编译工具链：自动化vECU编译工具链。这个工具链需要一旦配置完成后，可实现一键生成虚拟控制器。  初次生成vECU工作流程：  Rebuild生成vECU工作流程：  03.集成环境及联合仿真 下面介绍一下关于FMU的集成环境和联合仿真平台。 3.1 COSYM介绍 COSYM（系统协同仿真）产品是一个仿真和集成平台，作为系统级软件在环的主干，能够方便支持ECU间通信，并使能OEM厂商成为虚拟车辆集成商。一旦OEM厂商开发了自有的构建模块库，将能够方便采用COSYM进行模块集成与连接，使能控制器之间精确地通信。COSYM具有 “时序主控” ，能够协调所集成模块时间同步。 COSYM提供了图形配置界面（GUI）和实时操作环境（CEE），以实现有效的用户交互。旨在为用户提供：►模块导入，集成和部署；►多平台仿真： 基于Windows的自适应时间（ATS），软实时(MiL/SiL)； 基于云端的并行加速运算(MiL/SiL)； 基于Linux的实时仿真(HiL)； ►离散和连续仿真系统的交互操控及结果可视化(CEE)；►高级程序员/用户可以使用ASAM XiL和RestAPI（Python接口等）接 口 与COSYM进行交互。  通用模型集成器主要优势：►通用FMI2.0集成接口，可快速复用被控对象模型，虚拟控制器模型和帧级虚拟总线模型►COSYM提供Rest API，可启动后台运行模式，支持自动化流水线工具接入►可实现基于Windows和Linux*增量编译，提升集成效率联合仿真器主要优势：►支持ASAM-XiL标准接口，调用API即可运行仿真环境►支持基于Windows和Linux*系统下的自动化集成测试►支持基于云原生和容器镜像技术的仿真计算►支持第三方工具交互式测试，例如：测试管理与标定工具和总线仿真与信息安全工具功能3.2 COSYM功能  功能模块集成：►COSYM支持用于联合仿真的功能模型接口标准（FMI）V2.0；►提供了用于虚拟ECU（vECU）集成和仿真的环境；►建模工具ASCET和ASCMO模型；►Labcar系列半物理模型，基于Simulink的 模型编译导入；►支持模板化的C模块；模块间通信连接：  ►大规模云端并行计算及多租户协同工作（降本增效）  ►虚拟整车及产品级代码白盒持续集成与测试（加速迭代）  ►被控对象模型自动参数化（精度提升）  04.云上大规模测试  ETAS 的Cloud Service整体概览  云上仿真测试用例释义4.3 高度安全的云环境Cloud Service 上的仿真应用Model-Simulator已通过ISO/IEC 27000 和 27001认证。达到博世安全等级3(严格保密)。4.4 兼容的适配性Cloud Service 兼容COSYM、VECU Builder、ETAB之外，还兼容其它第三方产品，如ECUTest、AVL、Synopsis、Vector等。4.5 多租户团队协同多个仿真测试团队可同时登录进行仿真测试。各租户之间模型和信号等数据隔离；租户之间仿真任务并行运行互不影响；各云上租户资源可无限扩展。 05.CICT自动化流水线在虚拟控制器生成和虚拟整车平台SIL环境搭建的基础上，通过一系列工具链实现持续集成与持续测试的CICT自动化流水线。  支持构建用户自定义的持续集成及持续测试自动化流水线  流水线步骤举例：►代码变更，保存并推送代码仓库，Jenkins触发CICT Pipeline流水线。►拉取代码变更到本地 PC，生成虚拟控制器FMU并进行校验。►COSYM集成并进行冒烟测试。►持续测试通过，报告生成和查看分析，上传测试通过虚拟ECU文件至JFrog制品仓库。 06.应用案例  客户面临的挑战和困难：►仿真平台能够支持接入第三方的模型（如：ML/SL、GT、AMESim、CarMaker等）。►能够减少车辆标定工作时间，特别是重复性标定（如：工况脉谱图的扫点标定）。使用虚拟化方案实现的成果：►成功通过COSYM仿真平台完成软件在环的闭环工作。►标定软件INCA通过XCP协议与虚拟控制器建立通讯。►自动化标定软件INCA-FLOW通过ASAM-XIL接口与ETAS COSYM进行连接，实现对被控对象（如：运行工况点）的控制，并通过设计好的标定流程自动实施标定工作。6.2 基于模型在环和软件在环的功能测试  客户面临的挑战和困难：►虚拟化实践需要基于目前使用的软件开发工具。►虚拟控制器能够使用优化后的标定参数，并通过DCM文件进行。►虚拟化实践除了在单机上进行，也支持在云端运行。使用虚拟化方案实现的成果：►通过VECU-Builder工具实现了Type-1虚拟控制器的生成，并使用了DCM文件中优化后的标定参数。►成功通过COSYM仿真平台完成软件在环的闭环工作。►单机性能：比实时仿真快2+倍。►通过Cloud Service实现了云端运行的预研评估工作。6.3 持续集成和持续测试 CI/CT  客户面临的挑战和困难： ►有计划、分步骤地进行虚拟化实践。►适用于AUTOSAR架构的和非AUTOSAR架构的软件。►不能因为引入虚拟化实践，大幅增加开发工程师的工作负荷。►虚拟化实践要满足未来软件定义汽车的大趋势。使用虚拟化方案实现的成果：►根据客户的实际情况成功建立起点是源代码，终点为测试报告的自动化Pipeline。►Pipeline中可以自动地生成虚拟控制器，关联被控对象模型，接入仿真平台。并进行虚拟控制器的冒烟测试后，按照设定的测试用例进行软件在环测试，最后生成报告。►Pipeline可以在本地服务器中部署，也可以移植到云端运行。6.4 虚拟标定和云端队列  客户面临的挑战和困难：►需要减少车辆道路测试和标定的人力投入和费用。►最大限度兼容目前使用的工具（INCA、ASCMO和MOCA等）。►提高测试和标定工作的效率。使用虚拟化方案实现的成果：►成功通过VECU-Builder工具实现了Type-1虚拟控制器的生成。►成功通过COSYM仿真平台完成软件在环的闭环工作。►INCA、ASCMO和MOCA等工具能够在虚拟环境中无缝衔接。►标定效率：比实车测试快5+倍。►测试效率：2小时仿真=25,000公里路测。6.5 虚拟标定自动化 客户面临的挑战和困难：►仿真平台能够支持接入第三方的模型（如：ML/SL、GT、AMESim、CarMaker等）。►能够减少车辆标定工作时间，特别是重复性标定（如：工况脉谱图的扫点标定）。使用虚拟化方案实现的成果：►成功通过COSYM仿真平台完成软件在环的闭环工作。►标定软件INCA通过XCP协议与虚拟控制器建立通讯。►自动化标定软件INCA-FLOW通过ASAM-XIL接口与ETAS COSYM进行连接，实现对被控对象（如：运行工况点）的控制，并通过设计好的标定流程自动实施标定工作。 07.总结 |
文章网友提供，仅供学习参考，版权为原作者所有，如侵犯到
你的权益请联系542334618@126.com，我们会及时处理。
会员评价：
共0条 发表评论