随着EE架构逐渐趋于集中化，汽车软件系统出现了多种操作系统并存的局面，这也导致系统的复杂性和开发成本的剧增。为了提高软件的管理性、移植性、裁剪性和质量，需要定义一套架构（Architecture）、方法学（Methodology）和应用接口（Application Interface），从而实现标准的接口、高质量的无缝集成、高效的开发以及通过新的模型来管理复杂的系统。
02.
跨域融合与SOA架构的软件开发能力
汽车软件的跨域融合是指在汽车电子系统中，将来自不同领域、不同功能的软件模块进行整合和协同工作的过程。这些软件模块可能包括车身控制、动力总成、安全系统、娱乐系统等等，它们在不同的领域发展出来，并具有不同的编程语言、接口和功能特点。
在汽车软件的领域，最佳实现跨域融合的方式是面向服务的架构（Service-oriented Architecture, SOA）。SOA是一种软件设计方法，其中软件组件被设计为独立的服务，可以通过网络进行通信和交互。
03.
选择未来技术路径的能力
SOA只是一种软件设计方法，而其实现的技术路径可以有多种方式。目前在国内行业中，需要主机厂主流的技术方案是少部分基于国际标准AUTOSAR Adaptive，进行大量的自主研发。然而，在应对将来汽车软件日益复杂的趋势下，这会带来一定问题。
5.安全：采用云原生安全性能，汽车制造商可以更好地保护车辆和软件免受安全漏洞和攻击。
建设虚拟整车，需要构建整个汽车软硬件开发的协作平台，其中包括虚拟控制器开发环境、被控对象模型管理平台以及整车基线管理流程。
广泛使用的ROS1（一套开源的库和工具集，用于软件架构开发）无法满足实时性、安全性和跨平台互操作性的需求，各大公司都针对ROS1弱点做了很多优化，以让其适用于汽车。而这些研究和改进当然也反馈到ROS组织本身，所以也就有了ROS2。ROS2以及AOS等中间件解决了这些缺点，并实现了面向服务的通信。这些中间件在研究环境中被广泛使用，用于实现软件封装和通信，也在汽车电气/电子架构的背景下得到了应用。现在甚至有经过认证的解决方案，满足电气和/或电子系统的功能安全标准（ISO26262）和必要的汽车安全完整性级别（ASIL），关于ADAS功能和高度连接的车辆背景下的面向服务的架构（SOAs），仍有许多问题有待解决。
软件复杂性的提高，车辆功能的日益增长，严格的法规约束以及广泛的诊断要求，导致在标定和验证过程中的工作越来越多。同时，产品和创新周期的越来越短，为提高任务效率，OEM和Tier1面对着大量的时间、成本和质量压力。在软件定义汽车的背景下，部分汽车研发模式将由传统的瀑布式转向敏捷开发模式。
与传统软件开发模式系相比，DevOps打破了开发和运维之间的壁垒，通过自动化“软件交付”和“架构变更”的流程，使得软件的构建、测试和发布能更加快捷、频繁和可靠，从而帮助团队更快地发展和改进产品、服务客户、高效参与市场竞争。
为应对流程转变上的挑战，开发团队可考虑将软硬件解耦后，硬件和软件部分各自按照独立时间线来开发，并在进行软件更改后无需对整个车辆进行重新验证，纯软件的开发和验证过程从原型车或者硬件在环测试过渡到软件在环（SiL）的测试和验证。这种软硬解耦的方式同时也迎合了当下将ECU功能整合到中央计算单元或域控制器的趋势，在多合一控制器融合的过程中发挥作用，软硬件模块可以在不同的硬件平台运行，并在车辆整个生命周期内更新。那么软件在环SiL有什么应用场景呢？其应用场景通常是在快速变更的功能需求下敏捷开发及快速迭代。要求尽早进行软件验证并发现和纠正代码中的重要错误，特别是涉及安全相关错误。在高频率OTA云端升级软件的情况下自动化持续验证。在以上场景下软件在环SIL测试能够脱离硬件而快速验证控制器的功能代码。
四项汽车信息安全相关的国家标准《汽车信息安全通用技术要求》、《车载信息交互系统信息安全技术要求及试验方法》、《汽车网关信息安全技术要求及试验方法》、《电动汽车远程服务与管理系统信息安全技术要求及试验方法》以及汽车远程升级（OTA）技术召回监管、监管备案的相关内容。
1.新能源汽车EEA的集中化
2.网联化（攻击面）
3.法律法规（强标监管）
4.SDV：车内/车外边界消除及现有汽车软件的假设打破
-end-
本文作者：Kenneth Cheng，汽车软件产品经理
最前沿的电子设计资讯
