一鸣观点| 智能汽车平台软件“REDS”发展趋势下的创新之路

汽车电子架构从传统分布式ECU架构向领域集中式E/E架构的转变，体现了汽车从机械化向电子化、智能化的转变。 与传统汽车相比，智能汽车能够为车主创造丰富、可感知的价值和全新的驾驶体验。 随着汽车进入分布式架构的智能化阶段，对平台软件的需求不断涌现。 在软件定义汽车时代，软件成为定义车辆智能功能的关键点，而平台软件是软件架构的核心。 麦肯锡和罗兰贝格的数据显示，2030年全球汽车软件市场规模将达到840亿美元，未来汽车软件价值有望快速增长。

行业初期，重点是算法软件层面，但到了汽车智能化竞争的下半场，随着软件功能开发进入深水区以及跨领域融合的出现解决方案中，域控制器平台成为人们关注的焦点。 平台软件连接域控制器硬件和算法软件。 作为域控制器运行的关键基础，起着至关重要的作用。 同时也体现了硬件需求与软件需求的冲突，以及车辆开发方式与软件开发方式的差异。 冲突。

我们相信，随着汽车底层架构的集中演进和上层算法软件的快速迭代创新，汽车平台软件正在发生新的革命，并将在汽车平台软件的道路上占据重要一席之地。未来的智能汽车革命。

平台软件——智能汽车时代的“新基建”

（驱动领域软件层次分类：系统软件-功能软件-应用软件）

在软件定义汽车时代，平台软件的作用越来越重要。 随着EE架构逐渐趋于中心化，汽车软件系统出现了多种操作系统并存的情况，这也导致系统复杂度和开发成本急剧增加。 为了提高软件的可管理性、可移植性、可剪裁性和质量，需要定义一套架构、方法论和应用接口，通过新的软件实现标准接口、高质量无缝集成、高效开发和管理。模型复杂系统。

平台软件是汽车软件架构的重要基础，是整个软件架构的核心组成部分。 位于硬件之上、应用软件之下，其最重要的功能是对计算平台、传感器等资源进行抽象，对算法、子系统、功能采用模块化管理，为开发提供统一的接口，人员可以集中精力开发无需了解底层细节即可了解自己的业务水平，从而大大提高算法开发的效率。 凌念科技表示：“汽车软件架构越来越复杂，各种恶劣复杂的通信场景对数据传输提出了更高的要求。中间件起到了桥梁的作用，可以实现软硬件解耦和实时性通信调度，保证软件架构的稳定和高效运行，中间件将是高级别自动驾驶实现SOA架构实施不可或缺的一部分。 有了平台软件，所有软件和应用都可以有标准化的接口，硬件功能也被抽象成服务，可供上层应用随时调用；软件开发可以跨配置、跨型号、跨平台、跨平台。硬件；软件开发者可以更加关注软件功能的差异化。

行业初期百花齐放，行业变革需求倒逼底层创新

平台软件的发展与汽车电子架构的变革密切相关

第一阶段（2002-2017）：传统分布式ECU架构

2003年，整车厂和供应商共同建立了汽车开放系统架构AUTOSAR，以降低汽车电子系统软件的开发成本并更加方便有效地进行管理。 在AUTOSAR架构中，对各个功能模块进行封装，并标准化模块之间的接口，从而实现汽车软硬件的解耦。 以经典的AUTOSAR为例，AUTOSAR平台运行在微处理器（MCU）上，将汽车的软件架构抽象为三个部分：基础软件层、运行环境层和应用软件层。

传统汽车ECU软件功能简单，更新迭代频率低。 本阶段的核心重点是引入AUTOSAR标准化RTE接口，实现MCU软硬件解耦。

第二阶段（2017-2022）：领域中心化EE架构

2017年左右开始，汽车智能化趋势加速，汽车分布式架构向集中式演进。 传统汽车ECU在通信速度和计算能力方面难以支撑高性能智能汽车的发展。 2017年，AUTOSAR联盟推出了适配POSIX操作系统接口的AUTOSAR AP。 AUTOSAR AP引入SOA架构设计，主要用于高计算SoC平台，适应POSIX操作系统接口和相对复杂的软件功能。

第三阶段（2023年-未来）：跨域/车集中式EE架构

未来，电气电子架构将进一步向中部地区架构发展和演变。 在这种架构下，所有的计算能力都集中在中央计算机上，它完成了汽车控制、娱乐、驾驶辅助等所有能力的提供，承担了类似“中枢大脑”的角色。 在区域侧，区域控制器充当网关和交换机，完成供电。 确保来自中央计算机的指令向上和向下传达。 随着车载功能域的进一步融合、低层高性能SOC的出现以及上层算法软件的快速迭代，势必会对位于中间层的平台软件提出更高的要求。 传统分布式ECU时代形成的设计软件架构将面临更大的挑战。

汽车平台软件技术解决方案“百家争鸣”

虽然AUTOSAR是目前应用最广泛的车辆电子系统标准规范，但越来越多的主机厂并不想完全使用AUTOSAR来解决智能驾驶操作系统的问题。 目前，平台软件的开发还没有成熟的解决方案，短期内仍会出现多种解决方案并存的情况。

（驱动领域软件层次分类：系统软件-功能软件-应用软件）

1. 传统AUTOSAR CP&AP解决方案

AUTOSAR（汽车开放系统架构）是指汽车开放架构。 它是由全球汽车制造商、零部件供应商以及各类研究和服务机构共同制定的汽车电子系统合作开发框架，建立了开放的汽车架构。 控制器（ECU）标准软件架构规范了车辆操作系统标准和API接口。 AUTOSAR有Classic Platform和Adaptive Platform两大平台，分别对应传统控制车辆电子系统和自动驾驶对应的高性能车辆电子系统：

（AUTOSARCP&AP架构示意图）

1）ClassicPlatform（CP）：ClassicPlatform是AUTOSAR针对传统车辆控制嵌入式系统的解决方案，具有严格的实时性和安全性约束。 从架构上看，经典平台自下而上大致可分为微控制器、基础软件层、运行环境层和应用软件层。

2）自适应平台（AP）：自适应平台是AUTOSAR针对未来自动驾驶、车联网等复杂场景提出的全新汽车电子系统软件架构标准。 Adaptive平台修改了大量Classic平台标准，采用基于POSIX标准的操作系统，以面向对象的思维进行开发，可以使用所有标准POSIX API。 主要目的是满足当前自动驾驶、电动化、互联互通等趋势的需求。

随着汽车EE架构的演进以及汽车控制器开发重点的转移，AUTOSAR CP版本已经无法适应智能汽车的应用，所以后来推出了AUTOSAR AP版本，专门用于领域集中式EE架构。 经过几年的发展，AUTOSAR AP尚未完善标准和实现。 在此期间，出现了复制其他行业的期权； 另一方面，虽然AUTOSAR AP可以支持POSIX系统并提供相应的功能，但它仍然继承了AUTOSAR传统的开发方法和相关工具。 软件定义汽车时代，智能汽车的开发重点发生了变化，传统汽车时代形成的开发方法论未来可能面临持续挑战。

从目前AUTOSAR领域的竞争格局来看，国外企业占据行业领先地位，但国内企业不断推出平台软件解决方案。 对于AUTOSARCP标准的基础软件和工具链，国外主要供应商包括Vector、Etas、EB等。其中，第三方软件公司Vector是龙头企业，而Etas和EB则是博世旗下子公司和大陆航空分别。 同时，国内厂商也在积极实施自主研发。

2. 运动解决方案

MotionWise基于经过量产验证的高性能自动驾驶软件平台。 MotionWise于2017年7月在奥迪zFAS首个量产项目A8上推出，是经过系列验证的自动驾驶安全软件平台。 MotionWise已通过基于ISO26262的安全认证，满足ASIL-D安全级别应用要求，支持Linux/QNX操作系统。 MotionWise凭借其智能架构设计和周边工具，帮助释放自动驾驶解决方案的能力，同时提供面向多场景的服务能力，例如具有故障操作性能的实时功能、设计安全性、服务保障、前沿功能等。开放集成平台等

Motionwise是奥地利TTTech公司的核心产品。 TTTech于1998年成立于奥地利维也纳，是最早发布汽车平台软件产品的制造商之一。 2012年，TTTech参与奥迪zFAS项目，负责硬件设计和平台软件开发。 2017年，TTTech正式发布平台软件产品MotionWise，安装在奥迪A8车型上。 此后，TTTECH推出的智能驾驶平台软件也获得了大众、宝马、戴姆勒、现代等主机厂以及大陆、瑞萨等公司的量产订单。

近年来，Motionwise解决方案在国内市场的实施遇到了很大的挑战。 TTTech整体开发流程长，开发节奏慢，后续更新维护周期长且成本高。 难以满足国内整车厂智能驾驶功能频繁更新的需求。

3.DDS方案

DDS（DataDistribution Service）指数据分发服务，是OMG发布的分布式通信规范。 OMG（Object Management Group）成立于1989年，是一个国际性、开放性、非营利性的技术标准联盟，由供应商、最终用户、学术机构和政府机构推动。 已有30多年的历史。 OMG 工作组为各种技术和行业定义企业集成标准，并开发为数千个垂直行业提供实际价值的技术标准。 DDS首先应用于美国海军系统，解决军舰系统复杂网络环境下大量软件升级的兼容性问题。 随着ROS 2和AUTOSAR引入DDS，DDS已广泛应用于航空、航天、船舶、国防、金融、通信、汽车等领域。

DDS是工业级强实时通信标准。 它对场景的适应性很强，但其最初的设计并不是针对自动驾驶和汽车领域。 对于汽车场景应用来说更加“重”。

RTI（Real-Time Innovations）是DDS领域的典型代表公司，也是最大的供应商，拥有80%的市场份额。 RTI于1991年在美国成立，作为OMG董事会成员，主导了DDS标准的制定。 自2004年起，它一直负责主办DDS工作组。 已成为该行业的领导者，对DDS标准拥有足够的权威。 。 国内厂商中，华宇通软件成立于2020年，公司首款产品是基于DDS标准的通信平台软件“Swift”。

4.ROS/ROS2方案

ROS（Robot Operating System）指的是机器人操作系统。 它起源于2007年斯坦福大学的人工智能项目，经历了多个版本。 ROS集成了通信机制、开发工具、应用功能和生态系统，形成了一套完整的项目开发流程。 其主要目标是为开发提供代码重用支持。 推出后，已广泛应用于工业领域，包括科研机器人、工业机器人、轮式机器人、自动驾驶汽车甚至航天无人设备等。 ROS2是在ROS还不完善、发现许多已知无法修复的问题的情况下，从底层重新开发的新一代机器人操作系统。 此外，ROS2引入了QoS策略来配置节点间通信，提高了ROS2适应不同应用场景的灵活性，可应用于汽车自动驾驶场景。

ROS的初衷是为科研机器人提供开发环境和相应的工具。 由于开源生态丰富，很多算法团队都会基于ROS进行早期开发。 在成熟度和实时性方面还存在不足，在自动驾驶量产车上的应用较少。

ROS2的量产应用较少，典型代表企业是APEX。 Apex.AI于2017年成立于美国加州，公司CEO兼联合创始人Jan Becker早期曾在博世工作，后来参与了Darpa自动驾驶挑战赛获胜团队的系统开发。 起初，Apex.AI开发了基于ROS的自动驾驶平台软件。 在遇到一些问题后，它在 ROS 2 的基础上做了一些改进——包括产品代码质量、硬实时支持、流程级安全、对汽车 ECU 和传感器的支持，以及最重要的功能安全认证。 2021年12月，Apex.AI获得丰田、大陆、采埃孚等汽车行业巨头战略投资。

目前，域控制器平台软件市场仍处于早期阶段，技术方案的竞争与国内外厂商的竞争同时存在。 首先，市场上没有成熟统一的解决方案，不同客户的选择和做法差异较大，解决方案各有优势，面临不同的问题。 从国内近年来的发展趋势来看，遵循传统汽车软件开发方式的AUTOSAR AP和Motionwise在智能汽车最关键的智能驾驶领域进展有限。 遵循其他行业开发方式的DDS和ROS/ROS2能否支持汽车场景？ 对于未来的长期需求也存在很大的疑问。 一位OEM专家也表示，很多算法团队习惯使用ROS来构建早期功能，但这种方式实际上会给未来埋下很大的隐患，而如果使用Motionwise或AUTOSAR AP解决方案，早期的功能构建将无法实现。放慢速度。 很少。 从客户的角度来看，现有的解决方案都不具备绝对的优势。

虽然目前国外厂商的平台软件解决方案市场份额较大，但国内平台软件供应商正在迎来新的机遇。 主机厂与国外厂商的合作难免会面临“卡脖子”的问题，因为核心技术由国外厂商掌握，应用于一些关键业务场景时可能存在隐患； 另一方面，国外的平台软件基本上是基于军工、工业互联网等应用场景开发的，并不是针对智能驾驶领域的。 AUTOSAR 是近几年才慢慢引入的。 因此，对于主机厂来说，开发国外智能驾驶场景产品的难度和成本相对较高； 同时，国外厂商缺乏本地化的服务支持，无法在激烈的竞争中满足整车厂的需求。 汽车智能化竞争下功能快速迭代的需求。

考虑到当前的行业发展阶段和市场技术方案，主机厂逐渐涌现出对从底层架构创新技术解决方案的迫切需求，以满足汽车智能化竞争下自身的功能开发需求。 基于主机厂和业内专家对平台软件的观点，我们有理由相信，只有能够看到行业未来发展趋势、满足客户长期需求的技术方案，才能在平台软件上“慢慢流动”。智能汽车之路。

“REDS”发展趋势下，行业格局或面临洗牌

在国产化大趋势下，未来国内供应商份额逐步提升的趋势是比较确定的。 就目前多种解决方案竞争的现状来看，未来平台软件的发展方向仍然存在较大的变化。 该领域的新兴公司攀易科技表示，平台软件解决方案的评估维度相对复杂，每种解决方案都有自己的优点和缺点。 但从长远来看，未来平台软件的评价标准和发展趋势必然会跟随车辆需求的发展趋势。 平台软件解决方案的规划应考虑主机厂现阶段最关心的问题和最重要的需求，以及未来的变化趋势。

我们可以看到，在软件定义汽车时代，主机厂在智能化层面的长期关键需求如下：

1. 快速迭代

未来，智能汽车将从一种交通工具转变为智能出行的空间。 对于整车厂来说，整车厂的研发重点将从零部件转向软件/系统功能。 定制化的需求将成为功能开发的重点考虑因素。 因此，主机厂希望在保证底层系统的稳定性的同时，投入更多的研发精力来开发能够体现功能差异化的上层应用，通过后续功能的不断迭代，为消费者带来优质的智能体验。

随着主机厂新车迭代周期的缩短以及对供应商响应速度要求的提高，平台软件解决方案如何保证主机厂功能需求的稳定快速迭代是重中之重。

2、控制单车成本（Expenditure Reduction）

2022年，大部分国内车企经营状况并不乐观，利润率仅为个位数； 尤其是在新能源汽车领域，大部分新能源车企都处于亏损甚至大幅亏损的状态。 进入2023年之后，随着新能源汽车补贴退坡，整个行业迎来了一波降价潮，以促进汽车销量。 整车厂陷入新一轮激烈的价格战，降低成本的需求十分迫切。 长期来看，单车成本也将是未来整车厂竞争的焦点。

对于平台软件供应商来说，一方面，平台软件开发和测试的降本增效可以降低整车厂的采购成本； 另一方面，在技术层面，通过硬件资源的优化和合理配置，降低解决方案的成本，从而降低主机厂的整体解决方案成本，更好地控制单车成本。

3. 数据的高效获取和利用（Data Utilization）

数据成为新时代的“石油”。 对于主机厂来说，数据从根本上决定了智能汽车的功能迭代和效果体验。 主机厂软件算法的迭代需要数据支撑。 数据量大，如何高效利用数据，需要平台软件的功能支持。 同时，连接车端、路段、云端的数据也非常重要。 开放底层数据平台交互有助于提高开发效率，形成行业生态。

对于供应商来说，一方面需要保证边缘高价值数据的获取，为智能应用和算法模型提供最有价值的数据； 带来的效率和复杂度问题极大提高了算法模型的迭代效率，帮助车企通过海量量产数据不断优化算法模型。 通过数据不断迭代产品功能，将更有效地帮助主机厂打造真正智能化的产品体验。

4. 平台可扩展设计（Scalable Design）

在软件定义汽车时代的趋势下，未来平台软件的可扩展性设计将体现在三个层面：1）不同领域之间的可扩展性。 硬件层面的跨领域融合和中央计算平台的解决方案逐渐出现。 随着不同领域之间融合的深入，上层应用的差异化需求将为平台软件带来新的挑战。 不同硬件方案下，底层传感器数据复用、不同领域之间的兼容性、性能冲突等都需要提前设计平台软件以实现可扩展性； 2）不同模块之间的可扩展性。 由于平台软件本身的不断发展以及客户需求的差异，平台软件需要进行模块的可扩展设计，以满足新业务市场化的需求； 3）第三方可扩展。 未来智能汽车生态需要更多第三方参与，平台软件应更好地支持第三方在某些领域联合开发、共建生态。

总结

汽车平台软件作为汽车智能化的“新基​​础设施”，可以帮助主机厂降低开发上层软件的难度，提高开发效率。 同时，平台软件技术更加底层。 对于消费者来说，他们并不关心背后的底层技术，更关注应用层的功能体验； 所以对于整车厂来说，他们应该更多地关注那些能够向消费者展示功能差异化的关键点。 另一方面，车企开发自己的平台软件难度更大、成本更高。 因此，供应商提供平台软件解决方案或与供应商共同开发平台软件更具成本效益。 提高底层基础软件和平台软件的复用率，投入有限的研发来打造功能差异化的体验，是汽车行业软件发展的必然趋势。

汽车智能化、汽车电子电气架构变革、汽车平台软件开发之间存在着相互促进的关系。 汽车智能化的发展需要更新的架构作为支撑。 架构的转变促成了平台软件的出现，并有望进一步推动平台软件功能的丰富。 在当前汽车电子电气架构下，汽车平台软件的存在，一方面实现了不同领域之间的沟通与协作，另一方面也提高了智能应用开发的效率，有助于进一步推动汽车的智能化。汽车。

参考：

[1]2022.02，东方证券，《智能汽车深度系列一：汽车软件星辰大海》

[2]2022.03，九章志嘉，《自动驾驶中间件第三部分》

[3]2022.04，东方证券，《智能汽车深度系列二：车载操作系统和中间件带来的机遇》

[4]2022.06，华泰证券，《汽车中间件迎来发展机遇》

[5]2022.08，浙商证券，《智能驾驶系列报告三：智能驾驶软件领跑，座舱软件紧随其后》

[6]2022.08，红色星际，《从AutoSAR到SOA，中间件的问题仍未解决》

[7]2022.12，浙商证券，《域控制器，汽车智能化成功的关键》

[8]2023.02，智车科技，《自动驾驶中间件：量产落地关键技术》