在过去的二十年中，汽车软件的需求和应用急剧增长，随之复杂性急剧上升，现有技术和框架不足以应对这种复杂性。现在很明显，汽车制造商（OEM）必须重新考虑他们生产车辆的方式以及车辆本身的生命周期。通过将重点放在软件上，OEM可以在车辆整个生命周期中实现许多新的应用用例，并打开一个充满机遇的新世界。
01.软件定义汽车以及虚拟化技术
1.1软件定义汽车的概念
移动出行时代，汽车已逐渐从纯粹由机械驱动的硬件转变为软件驱动的电子产品。当今不同车厂的产品硬件配置已逐渐趋同，在成本和功能改善空间有限的情况下，传统汽车价值链的重构势在必行。车厂打造差异化的核心要素已转向原先与硬件深度耦合的汽车软件，随着汽车软件在新能源和智能化领域不断取得成功，迈入“软件定义汽车（SoftwareDefinedVehicles，SDV）”时代已成为行业共识。“软件定义汽车”即软件将深度参与到汽车的定义、开发、验证、销售、服务等过程中，并不断改变和优化各个过程，是汽车从基于硬件的产品向软件为中心的电子设备不断转变的结果。
“软件定义汽车”从表面上看是车内软件（包括电子硬件）的数量、价值超过机械硬件，背后更多的反应了汽车从高度机电一体化的机械终端，逐步转变为一个智能化、可拓展、可持续迭代升级的移动电子终端。为实现这一目标，整车在标准操作程序前便预埋了性能超前的硬件，并通过OTA在生命周期中逐步解锁和释放功能和价值。在该背景下，主机厂的核心能力将从机械硬件转向电子硬件和软件；产业价值链也将从一锤子硬件销售转向持续的软件及服务溢价。
1.2汽车软件发展的趋势
汽车“新四化”离不开软件和算法随着新四化的深入发展，汽车正加速从从机械设备向高度数字化、信息化的智能终端转变。
首先，软件及汽车电子占整车的研发成本逐步提高，车内软件和电子硬件价值有望超过硬件，成为整车价值的核心。据测算，预计到2030年软件成本占整车BOM（物料清单，BillOfMaterial）的比重将从目前不到10%增长到50%。需指出的是，这里的软件除应用程序开发、还包括AI算法、操作系统，以及软硬件一体化程度高的控制器、芯片等电子硬件。
其次，软件及软件更迭所带来的性能和功能变化，将决定未来汽车的差异性。软件的更新维护是未来主机厂提供差异化体验、提升客户满意度最经济、最便捷、最快速的一种方式。前提是由硬件提供冗余，再由软件实现迭代。
最后，包括主机厂、零部件企业等产业链上企业将加强软件能力建设，并围绕“软件定义汽车”开启从产品开发模式、组织架构、人员构成、运营体系等的内部变革。此外，新兴的软件公司将借助软硬件协同能力，兼容产业链上下多方需求，一举跃升为汽车产业链上新的Tier-1企业。
1.3汽车研发面临的困局
首先，分布式电子电气架构无法满足未来更高车载计算能力的需求。驱使EEA架构升级的另一个推动因素来自于更高的通讯效率和更大的带宽容量需求。成本管控黑洞：随着车内ECU、传感器数量增加，整车线束成本和布线难度也跟着大幅提升。
另外，汽车软件的模块化、平台化程度低，导致软件资源无法集中调度、协作性差。主机厂的ECU通常来自于不同的零部件供应商，事实上控制器上许多底层软件的重复性很高，这些代码主要保障控制器的正常运行，例如CAN总线信号的收发、任务进程的调度、Flash数据的读写等等。但碍于每一家供应商的软件编程语言不同、接口标准不同，而且软件又和硬件高度依赖，使得这些底层代码无法被复制和移植，从而造成ECU软件开发的大量重复和资源利用的低效。其次，软硬件高度嵌套、主机厂无法执行大规模、深层次的更新和升级或定制化开发工作。分布式软件架构是一种面向信号的架构，控制器之间通过信号来传递信息，但整个系统是封闭、静态的，在编译阶段就被定义死，因此当发生例如主机厂要修改或增加某个控制器的功能定义，同时该指令还必须调用另一个控制器上的功能时，就不得不把所有需要的控制器都升级，大大延长开发周期、增加开发成本。
1.4研发模式的转变
基于以上技术架构方面的变化，在软件定义汽车的背景下，汽车研发将由传统的瀑布式开发向敏捷开发的模式转变。
1.5虚拟化的价值
软件在环SiL的最关键的一个核心就是虚拟化：即通过将真实控制器转化为虚拟控制器，部署到PC上集成环境和联合仿真平台，接入CI/CT/CD自动化流水线，并上云端进行大规模测试，从而搭建完整的DevOps的SiL平台。
虚拟控制器简称vECU(即VirtualECU)，表示脱离真实硬件依赖后基于PC独立编译和运行的软件，vECU所包含的内容通常可由ASW,vBSW,vCDD以及RTE这几个部分构成，在集成编译后封装成基于PC的可执行文件。
对于功能测试验证工程师，通常他会拿到一个带有软件的完整ECU控制器，并以硬件在环或实车环境作为测试环境进行测试，整个测试过程可能受硬件和线束的限制，每当遇到软件的失效时首先需要考虑线束或者硬件通信上的问题，长此以往测试效率通常受硬件资源和硬件状态的限制，难以在受限的条件下高效的完成测试。但是如果仅ECU内与硬件无关的功能，只需解耦ECU产品代码并封装成vECU运行在PC上进行测试即可。数据采集和验证过程同真实环境软件测试工具一致，如INCA、Debugger调试器等等。
简而言之，就是将控制器C代码基于PC环境编译后生成FMU格式的可执行文件运行在常规PC仿真环境上，以更早和更快的方式进行测试及调试。
2.2虚拟控制器的分类
生成虚拟控制器的方式有两种，一种是通过C源码经过PC的x86编译器后生成可以运行在PC上vECU目标文件，并于PC上进行系统测试和验证后反馈给研发工程师。另一种是将C源码编译成目标芯片的程序（hex文件）后，运行在目标芯片的指令模拟器上来进行系统测试后再将结果反馈给研发工程师。
2.3FMU介绍
FMU是对动态链接库DLL进行的二次封装，它是基于FMI协议进行封装的模型文件。FMI协议是独立于建模软件的标准接口协议，可以用于集成不同的软件建立的不同详细程度的模型，进行MiL/SiL仿真。
2.4vECU自动化生成流程
以ETAS的VECU-BUILDER为例，这是一个基于Python和CMake的Windows工具。
3.1COSYM介绍
模块导入，集成和部署；
多平台仿真：
基于云端的并行加速运算(MiL/SiL)；
基于Linux的实时仿真(HiL)；
离散和连续仿真系统的交互操控及结果可视化(CEE)；
高级程序员/用户可以使用ASAMXiL和RestAPI（Python接口等）接口与COSYM进行交互。
通用模型集成器主要优势：
通用FMI2.0集成接口，可快速复用被控对象模型，虚拟控制器模型和帧级虚拟总线模型
COSYM提供RestAPI，可启动后台运行模式，支持自动化流水线工具接入
可实现基于Windows和Linux*增量编译，提升集成效率
联合仿真器主要优势：
支持ASAM-XiL标准接口，调用API即可运行仿真环境
支持基于Windows和Linux*系统下的自动化集成测试
支持基于云原生和容器镜像技术的仿真计算
支持第三方工具交互式测试，例如：测试管理与标定工具和总线仿真与信息安全工具功能