Author:
Lao Liu
Produced by:
Automotive Electronics and Software
Abstract:
Over the past two decades, the demand and application of automotive software have grown dramatically, and with it the complexity has risen dramatically. Existing technologies and frameworks are insufficient to cope with this complexity. It is now clear that automobile manufacturers (
OEMs
) must rethink the way they produce vehicles and the life cycle of the vehicles themselves. By focusing on software,
OEMs
can enable many new application use cases throughout the vehicle lifecycle and open up a new world of opportunities.
01.
Software-defined cars and virtualization technology
1.1 The concept of software-defined cars
In the era of mobile travel, cars have gradually transformed from purely mechanically driven hardware to software-driven electronic products. Today, the product hardware configurations of different car manufacturers have gradually converged. With limited space for cost and functional improvement, the reconstruction of the traditional automotive value chain is imperative. The core element for car manufacturers to create differentiation has turned to automotive software, which was originally deeply coupled with hardware. As automotive software continues to succeed in the fields of new energy and intelligence, entering
the era of
"
Software Defined Vehicles
(
SDV
)
"
has
become Industry consensus.
"
Software-defined cars
"
means that software will be deeply involved in the definition, development, verification, sales, service and other processes of cars, and will constantly change and optimize each process. It is the continuous transformation of cars from hardware-based products to software-centered electronic devices. the result of.
On the surface, "
software-defined cars
"
means that the quantity and value of in-car software (including electronic hardware) exceeds that of mechanical hardware. Behind the scenes, it reflects the car's gradual transformation from a highly mechanical and electrically integrated mechanical terminal to
an intelligent, capable A mobile electronic terminal that expands and sustains iterative upgrades. In order to achieve this goal, the vehicle has advanced performance hardware embedded in the standard operating procedures, and functions and values are gradually unlocked and released through
OTA
during the life cycle. In this context, the core capabilities of OEMs will shift from mechanical hardware to electronic hardware and software; the industrial value chain will also shift from one-shot hardware sales to sustained software and service premiums.
1.2 Development Trend of Automotive Software
The "
New Four Modernizations
"
of automobiles
are inseparable from software and algorithms. With the in-depth development of the New Four Modernizations, automobiles are accelerating the transformation from mechanical equipment to highly digital and information-based intelligent terminals.
First of all, software and automotive electronics account for a gradual increase in the research and development costs of the entire vehicle. The value of in-car software and electronic hardware is expected to exceed that of hardware and become the core of the value of the entire vehicle. According to estimates,
software costs
are expected to
account
for
50%
of the vehicle
BOM
(
Bill Of Material
) by
2030
, from less than
10%
currently
. It should be pointed out that in addition to application development, the software here also includes
AI
algorithms, operating systems, and electronic hardware such as controllers and chips with a high degree of software and hardware integration.
Secondly, the performance and functional changes brought about by software and software changes will determine the differences of future cars. Software update and maintenance is the most economical, convenient and fastest way for OEMs to provide differentiated experience and improve customer satisfaction in the future. The premise is that hardware provides redundancy, and then software implements iteration.
Finally, companies in the industry chain, including OEMs and parts companies, will strengthen software capability building and
initiate internal changes in product development models, organizational structures, personnel composition, and operating systems around
"
software-defined cars
.
"
In addition, emerging software companies will rely on software and hardware synergy capabilities to be compatible with the needs of multiple parties up and down the industry chain, and become a new
Tier-1
enterprise in the automotive industry chain in one fell swoop.
1.3 Dilemmas faced by automobile research and development
First, the distributed electronic and electrical architecture cannot meet the future demand for higher on-board computing capabilities. Another driving factor driving
the upgrade of the
EEA
architecture comes from higher communication efficiency and greater bandwidth capacity requirements. Cost control black hole: As
the number of
ECUs
and sensors in the car increases, the cost and wiring difficulty of the vehicle wiring harness also increase significantly.
In addition, the degree of modularization and platformization of automotive software is low, resulting in the inability to centrally schedule software resources and poor collaboration.
The ECUs
of OEMs
usually come from different parts suppliers. In fact, many underlying software on the controller are highly repetitive. These codes mainly ensure the normal operation of the controller, such as
the sending and receiving of
CAN
bus signals, the scheduling of task processes,
Reading and writing of
Flash
data, etc. However, due to the different software programming languages and interface standards of each supplier, and the software is highly dependent on the hardware, these underlying codes cannot be copied and transplanted, resulting in
a large amount of duplication of
ECU
software development and inefficient resource utilization.
Secondly, software and hardware are highly nested, and OEMs are unable to perform large-scale, in-depth updates and upgrades or customized development work. Distributed software architecture is a signal-oriented architecture. Controllers transmit information through signals. However, the entire system is closed, static, and is defined during the compilation stage. Therefore, when something happens, for example, the OEM wants to modify or add something, When the function definition of a controller must also call a function on another controller, all required controllers have to be upgraded, which greatly extends the development cycle and increases development costs.
1.4 Changes in R&D models
基于以上技术架构方面的变化，在软件定义汽车的背景下，汽车研发将由传统的瀑布式开发向敏捷开发的模式转变。
敏捷软件开发（
Agile software development
）：包括需求发现和解决方案改进。该模式通过自组织和跨职能团队与用户协作，制定适应性计划，进行渐进开发、早期交付、持续改进，灵活应对需求、能力的变化以及对需要解决问题的理解的变化。这是一种以用户需求进化为核心的迭代、循序渐进的开发方法。工程师先将用户最关注的软件原型做出来进行交付，根据用户在实际场景中反馈的问题，快速修改弥补需求中的不足。上述过程不断迭代，直至用户满意。
DevOps
是一组过程、方法和系统的统称，集文化理念、实践、工具于一身，重视开发（
Dev
）和运维（
Ops
）和质量（
QA
）部门之间的沟通合作。
与传统软件开发模式系相比，
DevOps
打破了开发和运维之间的壁垒，通过自动化
“
软件交付
”
和
“
架构变更
”
的流程，使得软件的构建、测试和发布能更加快捷、频繁和可靠，从而帮助团队更快地发展和改进产品、服务客户、高效参与市场竞争。
1.5 虚拟化的价值
汽车软件开发将遵循
IT
行业的发展规律，引入中间件技术、虚拟化技术来实现软件模块化、硬件抽象化和标准化，从而进一步解锁软硬件的耦合关系，满足电子电气架构灵活、可拓展的需求。
为应对流程转变上的挑战，开发团队可考虑将软硬件解耦后，硬件和软件部分各自按照独立时间线来开发，并在进行软件更改后无需对整个车辆进行重新验证，纯软件的开发和验证过程从原型车或者硬件在环测试过渡到软件在环（
SiL
）的测试和验证。这种软硬解耦的方式同时也迎合了当下将
ECU
功能整合到中央计算单元或域控制器的趋势，在多合一控制器融合的过程中发挥作用，软硬件模块可以在不同的硬件平台运行，并在车辆整个生命周期内更新。
那么软件在环
SiL
有什么应用场景呢？其应用场景通常是在快速变更的功能需求下敏捷开发及快速迭代。要求尽早进行软件验证并发现和纠正代码中的重要错误，特别是涉及安全相关错误。在高频率
OTA
云端升级软件的情况下自动化持续验证。在以上场景下软件在环
SIL
测试能够脱离硬件而快速验证控制器的功能代码。
软件在环
SiL
的最关键的一个核心就是虚拟化：即通过将真实控制器转化为虚拟控制器，部署到
PC
上集成环境和联合仿真平台，接入
CI/CT/CD
自动化流水线，并上云端进行大规模测试，从而搭建完整的
DevOps
的
SiL
平台。
虚拟化技术
使得在
Windows PC
上对汽车
ECU
（
Electronic Control Unit
，电子控制器单元）进行闭环仿真成为可能，能有效改善
ECU
开发过程。一些开发任务得以从道路、测试平台和
HIL
（
Hardware in the Loop
，硬件在环）转移到
PC
上，缩短开发时间和成本。
从
OEM
的视角来看虚拟化，可以将软件测试前移到早期开发阶段闭环，既减少了项目初期昂贵的
BOM
成本，又降低了软件开发成本和时间，在实现软件
CICT
闭环自动化的同时，可以建立供应商之间的发展生态系统，进行多团队多租户并行工作。
从工程师的视角来看虚拟化，传统汽车软件开发的流程一般为：功能开发团队使用基于模型的工具链开发
ECU
模型，生成
C
代码，然后针对目标处理器进行代码编译，并使用测试平台，
HiL
系统和道路测试来测试和验证生成的
ECU
，进而将结果反馈至开发人员，结束开发周期。该过程存在的主要缺点有：迭代时间长，受原型车和测试设备的限制
—
硬件资源昂贵且稀缺。
为开发团队提供虚拟
ECU
可解决上述问题：开发人员可在
PC
机上对软件进行模拟、校准和测量，缩短开发周期，减少对稀缺资源和实际硬件的严重依赖；同时，通过虚拟
ECU
，开发人员可随时观察和修改内存变量甚至硬件状态，极大提升工作效率。
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
。
Type-4 vECU
虽然可执行的是同一个目标
hex
文件，但缓慢的运行效率及芯片迭代所带来大量工程服务来屏蔽当前
ECU
项目的部分二进制控制指令，当前大部分用户仍会采用基于
PC
编译器
Type1 Type2
和
Type3
的方式。基于
PC
编译器编译控制器
C
代码的诸多优势，比如：
vECU
的更快的运行效率、仿真时的在线
Debug
、解耦真实硬件以及对实验结果更快的反馈时间。
虽然采用
vECU
来验证有诸多优势，但用其进行测试和仿真时仍有一定限制，比如无法评估和分析诸如软件上的时间表现、
CPU
负载、内存资源的消耗以及模拟硬件中断等特性。
2.3 FMU介绍
FMU
是对动态链接库
DLL
进行的二次封装，它是基于
FMI
协议进行封装的模型文件。
FMI
协议是独立于
建模
软件的标准接口协议，可以用于集成不同的软件建立的不同详细程度的模型，进行
MiL/SiL
仿真。
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
模块；
模块间通信连接：
COSYM
提供了基于
CAN/CANFD,
车载以太网，
FlexRay, LIN
的的汽车总线虚拟仿真技术。
基于共享内存，该虚拟总线仿真为被动和分散式，分布式系统因此可以由任意数量的模块构建。不需要真实的网络接口，可在虚拟
vNet
接口上捕获网络流量并将其转发到真实的网络接口。虚拟
CAN
和车载以太网支持在
ISO / OSI
第二层级及以上的逻辑总线行为模拟，模拟可到帧的传输而非电压电平。
COSYM
可提供
vPIN
级别的
vECU
信号互连插件
-
虚拟电器层（
vEL
），以实现例如故障存储器，
EEPROM
，通讯堆栈和输入
/
输出的测试验证；相比真实硬件，该插件简化或删除了部分特定硬件和复杂驱动程序相关的仿真。
3.3 COSYM应用场景
►
虚拟控制器自动寻优标定（节能减排）
►
大规模云端并行计算及多租户协同工作（降本增效）
►
虚拟整车及产品级代码白盒持续集成与测试（加速迭代）
►
被控对象模型自动参数化（精度提升）
04.
云上大规模测试
ETAS 的Cloud Service整体概览
从
ECU
到
VECU
实现了控制器硬件的虚拟化；从物理控制器测试联调到联合仿真平台实现了测试环境的虚拟化；前序两阶段的虚拟化为云上大规模测试仿真提供了可能。
4.1 快速的基础设施扩展
依托于云供应商（
AWS
、
Ali Cloud
）的弹性伸缩服务，秒级创建用于大规模测试仿真所需的计算资源。应对复杂被控对象模型和海量信号数据输入也能够实现即时处理；仿真任务完成后资源即刻销毁。相较于传统本地仿真运行，能够有效避免由于硬件计算资源不足导致的运行崩溃，仿真等待时间长，从成本上看按量付费模式可减少基础设施建设投入，减少计算资源闲置。
4.2 并行测试仿真
基于容器云的编排能力和云供应商容器服务
（
AWS: EKS
、
Lambda, Ali Cloud: ACK
、
FC
）能够完成大规模并行仿真任务，并行测试执行。能够对车辆网络等复杂系统进行仿真，包括虚拟车辆控制单元、车辆总线和仿真模型。每次仿真运行可测量
1000
个信号，输出报告支持用户自定义格式。相较于本地运行仿真时的垂直扩展方式，
Cloud Service
能够以分布式架构水平扩展计算节点，完成各节点间仿真任务的数据同步，最大可支持
1000
个仿真任务并行执行。
云上仿真测试用例释义
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
自动化流水线。
CICT
方案为客户带来的显著收益：
►
开发与测试环节的全面加速
►
尽早发现错误并有效反馈
►
可重复使用现有工具
►
数据安全保障
►
使员工可以专注于价值创造，而非工具与工具链
►
多方工程协作的支持
支持构建用户自定义的持续集成及持续测试自动化流水线
流水线步骤举例：
►
代码变更，保存并推送代码仓库，
Jenkins
触发
CICT Pipeline
流水线。
►
拉取代码变更到本地
PC
，生成虚拟控制器
FMU
并进行校验。
►
COSYM
集成并进行冒烟测试。
►
持续测试通过
，报告生成和查看分析，上传测试通过虚拟ECU文件至JFrog制品仓库。
06.
应用案例
以下是基于ETAS虚拟化开发工具链，列举一些应用案例。
6.1 虚拟标定和虚拟总线应用，虚拟整车POC
客户面临的挑战和困难：
►
仿真平台能够支持接入第三方的模型（如：
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
等）。
►
提高测试和标定工作的效率。
使用
虚拟化方案实现的成果：
►Successfully
realized
the generation of
Type-1
virtual controller
through
the
VECU-Builder
tool.
►Successfully
completed software-in-the-loop closed-loop work
through
the
COSYM
simulation platform.
►
Tools such as
INCA
,
ASCMO
and
MOCA
can be used seamlessly in virtual environments.
►Calibration
efficiency:
5+
times faster than actual vehicle testing.
►Testing
efficiency:
2
hours of simulation
= 25,000
kilometers of road test.
6.5 Virtual calibration automation
Challenges and difficulties faced by customers:
►The
simulation platform can support access to third-party models (such as
ML/SL
,
GT
,
AMESim
,
CarMaker
, etc.).
►It
can reduce vehicle calibration work time, especially repetitive calibration (such as scanning point calibration of working condition map).
Achievements achieved using
virtualization solutions:
►Successfully
completed software-in-the-loop closed-loop work
through
the
COSYM
simulation platform.
►The
calibration software
INCA
establishes communication with the virtual controller
through
the XCP
protocol.
►The
automated calibration software
INCA-FLOW
is connected to
ETAS COSYM
through
the
ASAM-XIL
interface
to control the controlled objects (such as operating condition points) and automatically implement the calibration work through the designed calibration process.
07.
Summarize
7.1 Application areas
►For
functional development and integration test engineers,
SIL
simulation testing
can be completed during the application layer code development stage
►For
calibration and testing engineers can
perform joint virtual calibration of multiple controllers in the
SIL
simulation environment
►Real
vehicle data and virtual vehicle promote each other
►Create
an R&D ecosystem for agile software development
►
Help car companies create software-defined cars and vehicle digital twin application cases
►Construction
, integration and accuracy improvement of vehicle physical model
►Tool
compatibility supports low cost and cross-model versatility
7.2 Features
►Supports
cross-software architecture and operating platforms to generate different types of virtual controller vECU, with a simple and mature operation process
►The
joint simulation platform supports standard
FMU
integration and cross-platform joint simulation, with high flexibility and compatibility.
►Supports
joint virtual calibration of three-party tools and multiple controllers
►Supports
building user-defined continuous integration and continuous testing automated pipelines
►
Various frame-level virtual bus standard plug-ins. Including
CAN
,
CANFD
,
LIN
, Ethernet and other virtual buses
►Can
be deployed based on domestic cloud
7.3 Revenue advantages
►Virtual
controller can be flexibly used in the early, middle and late stages of software development to improve development efficiency
►Standardized
simulation platform, compatible with various virtual controllers and controlled object models, enabling software-in-the-loop testing with high simulation speed
►Reduce
developers’ repetitive work and accelerate the iteration process
by establishing continuous integration and continuous testing
Pipeline
►Supports
frame-level virtual bus and domestic cloud deployment to better assist development departments in digital transformation
►
Reduce investment in hardware test benches and speed up vehicle development, testing and launch cycles
►Establish
an ecosystem for collaborative software development among multiple teams
-end-
This column is
a neutral technology popularization column created
by
Automotive Electronics and Software
. It will systematically explain the key challenges and engineering practices under software-defined cars.
Welcome to subscribe to this column!
京公网安备 11010802033920号