随着车辆电子电气架构进一步集中化，汽车行业将逐步展现出通过软件特性来实现品牌差异化竞争的趋势。对于主机厂而言，选择正确的软件技术路线，规划软件快速迭代交付体系，构建开发者生态圈，将决定未来数年内品牌战略成败。具体来说，未来5年将在以下八大领域内展开激烈的竞争，每个细分领域都将涌现出行业的新独角兽解决方案公司。

01.

集中式EEA的设计能力

汽车电子电气架构的集中化是指将汽车的电子和电气系统组织在一个中央控制单元或少数几个控制单元中。传统上，汽车电子电气系统由多个独立的控制单元组成，这些单元分别控制不同的功能，如发动机控制、车身控制、安全气囊等。这种分散式的电子电气系统设计在一定程度上增加了汽车的复杂性，导致成本增加、维护困难和可靠性降低等问题。

相比之下，集中式的电子电气系统设计可以将所有的控制单元整合到一个中央控制单元或少数几个控制单元中，这些控制单元可以集成多个功能，通过统一的数据总线进行通信。这样做可以简化汽车电子电气系统的设计和维护，提高汽车的可靠性、安全性和性能，同时也能够减少成本和重量。

集中化的电子电气系统架构也带来了更强大的车载计算能力。这些计算资源可以支持更多的未来体现品牌差异性的软件特性，因为这些功能需要更复杂的数据处理和通信能力。例如，下一代的空中软件升级（OTA）、智能远程诊断，基于车内大数据分析的电池管理优化等等。

在行业过去的十年之内，巨量的资本涌入自动驾驶、智能座舱的领域。依托于电子电气架构集中化，自驾、座舱软件已经充分展现出了软件平台化的趋势，即为了加快软件的迭代速度和复用程度，大量的计算平台的基础能力都被封装为标准化的中间件和编程平台。这个趋势正在逐渐加速，而且呈现出了跨域融合的需求。

随着EE架构逐渐趋于集中化，汽车软件系统出现了多种操作系统并存的局面，这也导致系统的复杂性和开发成本的剧增。为了提高软件的管理性、移植性、裁剪性和质量，需要定义一套架构（Architecture）、方法学（Methodology）和应用接口（Application Interface），从而实现标准的接口、高质量的无缝集成、高效的开发以及通过新的模型来管理复杂的系统。 

02.

跨域融合与SOA架构的软件开发能力

汽车软件的跨域融合是指在汽车电子系统中，将来自不同领域、不同功能的软件模块进行整合和协同工作的过程。这些软件模块可能包括车身控制、动力总成、安全系统、娱乐系统等等，它们在不同的领域发展出来，并具有不同的编程语言、接口和功能特点。

跨域融合的目的是为了实现汽车电子系统的整体性能优化，使各个软件模块之间能够更好地协同工作。这需要对软件模块进行统一的接口设计和标准化的数据交换方式，从而实现不同领域、不同功能的软件模块之间的无缝协同工作。

为实现跨域融合等中央计算平台的发展，高性能SoC产品和中央集中式E/E架构是实现跨域融合的硬件基础，而面向服务的软件架构（SOA）则是实现跨域融合的软件基础。1996年，SOA概念由Gartner提出，并率先在IT行业被应用推广。SOA并非一类特定的软件产品，而是一种软件架构设计的理念，其核心思想在于“通过将庞大的计算系统按照实际业务拆分为独立部署的大小合适的功能模块，提高功能单元的复用性，降低产品开发的复杂度和成本”。如今，软件定义汽车领域引入SOA，打造“底层硬件、中间层操作系统、上层应用程序”的软件分工模式，实现上层应用软件和底层基础软件的解耦，提升整车OTA功能的实现能力，最终“向用户提供全生命周期的跨域软件服务”。因此，SOA已经成为整车操作系统的代名词。

在汽车软件的领域，最佳实现跨域融合的方式是面向服务的架构（Service-oriented Architecture, SOA）。SOA是一种软件设计方法，其中软件组件被设计为独立的服务，可以通过网络进行通信和交互。

在汽车软件中，SOA的应用可以将各种车辆系统，如发动机管理系统、制动系统和娱乐系统等，分解为独立的服务组件，使得这些组件可以更加灵活地进行组合和配置，以满足不同车型和市场的需求。SOA可以提高汽车软件的可靠性、可维护性和可扩展性，使得汽车制造商可以更加容易地开发和维护各种汽车系统。

SOA有助于提高汽车软件的开发效率和质量，通过整合已有的软件模块，可以避免重复开发和测试，同时可以减少软件集成带来的问题和风险，提高软件的可靠性和安全性。

值得注意的是，传统汽车软件开发的中间性工具链并不会被取代，刹车、转向、防爆、车身稳定控制等传统车控软件是由单一ECU控制，并不适用于SOA架构，未来仍会通过基于模型仿真和嵌入式的传统汽车软件开发方式进行开发。但是由于未来新型的车用软件需具备跨域能力，因此无法按照传统单一ECU的开发方式去开发，必须采用SOA架构。

03.

选择未来技术路径的能力

SOA只是一种软件设计方法，而其实现的技术路径可以有多种方式。目前在国内行业中，需要主机厂主流的技术方案是少部分基于国际标准AUTOSAR Adaptive，进行大量的自主研发。然而，在应对将来汽车软件日益复杂的趋势下，这会带来一定问题。

首先，未来智能网联汽车会形成品牌生态。而通过软件定义的汽车品牌需要大量第三方的开发者加入。主机厂通过内部自主研发的平台，尤其基于AUTOSAR Adaptive，往往只适用于某些特定应用的类型，因此它可能不适用于所有汽车应用程序。

其次，学习成本高。内部自主研发的平台和工具链，需要专门的技能和培训，以便工程师能够有效地使用和开发该平台，这可能增加开发成本和时间。而行业内了解AUTOSAR的工程师非常稀缺，更不用提了解主机厂以其为基础的内部自主研发的工程师数量了。

汽车软件运用云原生的概念可以帮助汽车制造商更加灵活、可靠、安全地构建和运行其软件系统。以下是一些常见的汽车软件运用云原生的概念：

1.微服务架构：汽车软件可以采用微服务架构，将复杂的单体应用程序拆分为较小的独立服务，每个服务专注于一项任务。这种方法可以提高软件的可维护性和可扩展性，并使软件更加容易部署和管理。

2.容器化：通过将软件打包成容器，汽车制造商可以更容易地管理和部署软件，并提高软件的可移植性和可伸缩性。

3.自动化部署：采用自动化部署技术，可以帮助汽车制造商更快地部署新版本的软件，从而更快地推出新功能和修复问题。

4.弹性伸缩：云原生应用程序可以根据需要自动扩展或缩减资源，从而满足峰值流量需求并节省成本。

5.安全：采用云原生安全性能，汽车制造商可以更好地保护车辆和软件免受安全漏洞和攻击。

运用云原生的概念充分利用已经发育成熟几十年的IT和互联网的行业生态，注入到汽车行业领域，为主机厂快速构建开发者生态圈打好基础。

04.

整车平台虚拟化能力

未来软件定义汽车软件固然需要引入互联网生态化的开发方式，然而长期来看，传统汽车软件，尤其是核心驾驶控制软件，例如刹车、发动机控制、电池管理等等并不会被SOA和各类互联网技术所取代。相反，在传统V模型开发模式之上引入快速迭代、持续集成的新模式成了重大技术课题。而虚拟化技术是达成整车控制软件持续优化的重要技术能力。

汽车软件开发过程的虚拟化是一种基于仿真技术的软件开发方法，它使用计算机仿真来模拟车辆系统的运行环境和行为，从而使开发人员可以在不使用实际硬件的情况下进行软件开发、测试和验证。

虚拟化技术可以用来模拟车辆的各种传感器、控制单元和执行器，并提供真实的数据输入和输出。开发人员可以使用这些仿真工具来测试和验证软件的功能和性能，以及评估不同软件设计方案的效果。而整车虚拟化是借鉴了航天航空工业的先进实践。商业大飞机从设计到交付过程中，所有实际试飞时间只有一两百小时。能达到交付的质量和安全标准，航天航空业依靠的主要就是虚拟化仿真技术，例如波音的实验室能在五个星期内实现累计45年的有效虚拟试飞时间。

建设虚拟整车，需要构建整个汽车软硬件开发的协作平台，其中包括虚拟控制器开发环境、被控对象模型管理平台以及整车基线管理流程。

在软件定义汽车的趋势下，仿真虚拟化技术会影响哪个核心领域？我们认为车内核心控制软件的开发和测试将进一步走向融合。在传统开发方式下，不同零部件供应商自行独立测试，比如刹车供货企业会在自己的实验室或独立测试环境内，针对刹车控制软件进行隔离测试。但随着电子电气架构的发展，未来的电子控制软件将走向融合，OEM在利用此项技术的过程中也会对供应商的虚拟化能力提出更高要求，来配合完成整车的虚拟化，这就对供应商提出了更高的要求。例如，如今整车的热控制系统既要负责车内驾乘区域的舒适性，并根据电动车的驾控操作情况控制电池处于最佳温度区域，多功能兼顾必然对仿真测试提出更高要求，“融合”就是其中的关键词。

基于此，虚拟整车平台不仅可以打破研发部门之间的壁垒；还可以邀请整个软件供应链上的供应商加入虚拟整车的开发中，共建生态圈。这也是传统整车开发过程中企业经常碰到的痛点：零部件企业希望尽早、更频繁地进行测试，而不是依托云模型，等到接近量产后才能进行整车集成测试，打造未来开发生态系统的整体价值愿景。

05.

自动驾驶通用中间件的构建能力

汽车的智能驾驶化实质上也是汽车的机器人化，我们常说的“感知”、“决策”和“规控”等，其实也是来自于机器人领域。智能网联汽车的功能域控制器划分，电子电气架构的演变都能或多或少看到机器人的影子。甚至有些公司就是借用机器人传统术语来作为传统车企智能化改革的口号和产品蓝图。机器人是多专业知识交叉的学科，通常涉及传感器、驱动程序、多机通信、机械结构、算法等，为了更高效地进行机器人的研究和开发，选择一个通用的开发框架非常必要。而ROS就是最流行的框架之一。

广泛使用的ROS1（一套开源的库和工具集，用于软件架构开发）无法满足实时性、安全性和跨平台互操作性的需求，各大公司都针对ROS1弱点做了很多优化，以让其适用于汽车。而这些研究和改进当然也反馈到ROS组织本身，所以也就有了ROS2。ROS2以及AOS等中间件解决了这些缺点，并实现了面向服务的通信。这些中间件在研究环境中被广泛使用，用于实现软件封装和通信，也在汽车电气/电子架构的背景下得到了应用。现在甚至有经过认证的解决方案，满足电气和/或电子系统的功能安全标准（ISO26262）和必要的汽车安全完整性级别（ASIL），关于ADAS功能和高度连接的车辆背景下的面向服务的架构（SOAs），仍有许多问题有待解决。

但不可否认的是，ROS已经成为自动驾驶开发的基座。究其原因，有这3个重要因素： 

1.活跃的开源社区，丰富的扩展能力

许多智能驾驶需要用到的算法，都能在ROS生态中找到已经成熟的代码。例如建立地图的算法，使用激光雷达或GPS定位算法，沿着地图规划路径算法，避开障碍物的算法，摄像头视觉处理算法等等......这些轮式机器人导航所需的算法在ROS上是现成的，几乎都可以直接适用于智能驾驶汽车。 

2.完善的UI界面，实现拖拉拽编程

ROS自带一套图形工具，可以方便地记录和可视化传感器捕获的数据，并以全面的方式表示车辆的状态。此外，它还提供了一种简单的方法来实现定制化的可视化需求。这在开发控制软件和调试代码时非常有用。如果您曾经在电脑前看过智能驾驶汽车传感器的原始数据，做过调试，相信您会深刻理解一个靠谱的数据可视化工具是有多么重要。 

3.用户学习成本低，吸引更多人加入

在开展一个新领域的时候，没有什么比把东西先做出来更重要了。基于ROS来开发一个智能驾驶汽车项目是比较简单的。例如从一个简单的轮式机器人开始，配备一对轮子、一个摄像头、一个激光扫描仪和ROS导航软件栈，开发者可以在几个小时内就可以完成设置，让小车自主行进避障。这种快速上手也可以帮助新手快速理解整个运作基础和框架，然后再转向更专业更深入的研究。某宝上就有很多基于ROS的智能小车，很多机构也是基于这些套件开展智能驾驶培训的。 

06.

开发工具链及流程体系的创新能力

软件复杂性的提高，车辆功能的日益增长，严格的法规约束以及广泛的诊断要求，导致在标定和验证过程中的工作越来越多。同时，产品和创新周期的越来越短，为提高任务效率，OEM和Tier1面对着大量的时间、成本和质量压力。在软件定义汽车的背景下，部分汽车研发模式将由传统的瀑布式转向敏捷开发模式。

敏捷软件开发（Agile software development）：包括需求发现和解决方案改进。该模式通过自组织和跨职能团队与用户协作，制定适应性计划，进行渐进开发、早期交付、持续改进，灵活应对需求、能力的变化以及对需要解决问题的理解的变化。这是一种以用户需求进化为核心的迭代、循序渐进的开发方法。工程师先将用户最关注的软件原型做出来进行交付，根据用户在实际场景中反馈的问题，快速修改弥补需求中的不足。上述过程不断迭代，直至用户满意。

DevOps是一组过程、方法和系统的统称，集文化理念、实践、工具于一身，重视开发（Dev）和运维（Ops）和质量（QA）部门之间的沟通合作。

与传统软件开发模式系相比，DevOps打破了开发和运维之间的壁垒，通过自动化“软件交付”和“架构变更”的流程，使得软件的构建、测试和发布能更加快捷、频繁和可靠，从而帮助团队更快地发展和改进产品、服务客户、高效参与市场竞争。

汽车软件开发将遵循IT行业的发展规律，引入中间件技术、虚拟化技术来实现软件模块化、硬件抽象化和标准化，从而进一步解锁软硬件的耦合关系，满足电子电气架构灵活、可拓展的需求。

为应对流程转变上的挑战，开发团队可考虑将软硬件解耦后，硬件和软件部分各自按照独立时间线来开发，并在进行软件更改后无需对整个车辆进行重新验证，纯软件的开发和验证过程从原型车或者硬件在环测试过渡到软件在环（SiL）的测试和验证。这种软硬解耦的方式同时也迎合了当下将ECU功能整合到中央计算单元或域控制器的趋势，在多合一控制器融合的过程中发挥作用，软硬件模块可以在不同的硬件平台运行，并在车辆整个生命周期内更新。那么软件在环SiL有什么应用场景呢？其应用场景通常是在快速变更的功能需求下敏捷开发及快速迭代。要求尽早进行软件验证并发现和纠正代码中的重要错误，特别是涉及安全相关错误。在高频率OTA云端升级软件的情况下自动化持续验证。在以上场景下软件在环SIL测试能够脱离硬件而快速验证控制器的功能代码。

软件在环SiL的最关键的一个核心就是虚拟化：即通过将真实控制器转化为虚拟控制器，部署到PC上集成环境和联合仿真平台，接入CI/CT/CD自动化流水线，并上云端进行大规模测试，从而搭建完整的DevOps的SiL平台。

07.

OTA能力

Software OTA (SOTA)

回顾百年汽车史，汽车产业的发展经历了从「机械时代」到「电子时代」到如今的「软件定义汽车（Software Defined Vehicles, SDV）时代」。相应的，汽车制造的技术壁垒也由传统三大件+零部件的集成能力，转变为软件服务的能力，而OTA就是其中的支撑性技术。OTA（Over-the-Air Technology），行业内称之为“空中升级”，是一种通过移动通信的空中接口实现对移动终端设备及SIM卡数据进行远程管理的技术。

OTA技术最早应用于PC；后来在智能手机上普及，终结了手机软件升级需要“连接电脑-下载软件-再安装更新”的麻烦操作；直到2012年，特斯拉开创了汽车OTA的先河，OTA也奠定了特斯拉“元老级”的位置。

整车OTA一直是评价汽车主机厂研发实力和智能科技水平的重要指标。首先，汽车涉及由电子控制单元 (ECU) 控制的多个运动部件，极其复杂，如今一辆汽车多达150个车载控制器和约1亿行软件代码，远高于Facebook、战斗机、人造卫星等高科技产品的代码量；其次，每辆车的生命周期约为6-10年，如果没有OTA，车子的能力就完全跟不上时代；此外，汽车的属性，决定了其在安全性和可靠性方面要求更严格，OTA是重中之重。可以预见，未来3-5年，谁先做好布局OTA，谁就有机会以最快速度抢占风口，吃下一波红利。

当一辆车开始OTA，车主碰到车辆维修和软件更新，就不用辗转4S店或汽车被召回，“隔空”升级汽车；车企也可以“隔空”升级产品或查漏补缺；更关键的是，如果OTA大规模铺开，将会带来一种全新的「车辆增值模式」，比如“订阅付费”。

OTA分为两类:SOTA(Software OTA)和FOTA(Fireware OTA)，SOTA通俗的说就是你只对 APP软件进行升级而FOTA升级的更彻底，它是对整个底层FLASH软件进行升级。如对整个车机大屏操作系统、仪表等底层软件进行升级就是FOTA，对车机大屏上的导航、音乐等应用进行升级就是 SOTA，从难度上说FOTA难度要远高于SOTA，所以真正的OTA就要既要支持SOTA又要支持FOTA。

和我们更新电脑、手机软件一样，其实严格意义上讲OTA就是给汽车系统升级，给车辆运行的底层逻辑优化、升级。现阶段普遍汽车上的处理器单元多达50-60个，部分车型的处理器数量已经超过百个了。这就意味着汽车是一个庞大的控制系统集合，OTA这种方式能够控制车辆更多方面，更多程度上的内容了。

汽车软件监管的大幕已经拉开

正如上文所述，OTA其实最核心的功能就是补漏和升级。但是坦白来说，现在更多的OTA都是补漏，起码是跟大家承诺的在后续才弥补上。随着车载软件能力的逐渐增强，对车辆软件做国家层面的监管一直以来都在被研讨和调研，国家相关部门的监管政策也陆续落地生根。

四项汽车信息安全相关的国家标准《汽车信息安全通用技术要求》、《车载信息交互系统信息安全技术要求及试验方法》、《汽车网关信息安全技术要求及试验方法》、《电动汽车远程服务与管理系统信息安全技术要求及试验方法》以及汽车远程升级（OTA）技术召回监管、监管备案的相关内容。

08.

应对信息安全的能力

汽车智能化与网联化的发展驱使着软硬件不断升级，电子电气架构朝着域集中式和中央计算式架构 不断演进，汽车软件系统也变得更加复杂与开放。与此同时，汽车基础软件介于硬件与应用软件之间， 用于屏蔽硬件差异并支撑上层应用，实现软硬件解耦，并提供可靠服务。在上述趋势下，汽车基础软件 面临的信息安全问题日益突出。

当前软件定义汽车利用并依赖于车外功能，即汽车云计算。与智能手机的交互、后端的数据处理都将直接影响汽车的行驶方向以及与驾驶员、乘客和道路使用者的交互。车外安全问题可能会对车内产生影响。从安全角度来看，这消除了车内与车外的边界：汽车公司以及IT系统供应商和运营商须确保汽车生态系统的安全，保护软件定义汽车和道路使用者的安全。 在今天软件定义汽车和汽车EEA集中化，网联化，智能化，以及法律法规的强制监管下，也对车辆网络安全的生命周期开发和维护提出更高要求并衍生出新的挑战。挑战主要体现在以下五个方面： 

1.新能源汽车EEA的集中化 

2.网联化（攻击面）

3.法律法规（强标监管） 

4.SDV：车内/车外边界消除及现有汽车软件的假设打破

5.全生命周期开发运维 :DEVOPS在汽车行业应用

汽车新四化的浪潮下，汽车基础软件相关产业整体发展较快，产品迭代、技术更新发展势头迅猛。从国产化水平来看，目前已经能在相关产品上看到一些国内厂商的身影。然而，从发展水平来看，仍然存在较大的短板。汽车基础软件介于硬件和软件之间，国内相关行业发展并不平衡，国内仍较多关注于基础软件向上层提供服务，例如入侵检测等应用，对于芯片、操作系统等偏下层的产业化仍与国际先进水平有差距。随着我国近年来对汽车芯片、操作系统、信息安全等方面的持续投入，相信很快会迎来汽车基础软件信息安全的快速发展。