本土化汽车操作系统的发展路径与落地实践 | GAIR Live

随着汽车行业向软件定义的方向发展，操作系统成为驱动汽车智能化发展的重要组成部分。

现代汽车操作系统不仅需要管理底层硬件的驱动程序，还需要提供丰富的功能和服务，如车载娱乐系统、导航系统、安全系统、智能驾驶辅助等。这些功能和服务的复杂性和规模日益增长，给汽车行业带来了前所未有的挑战。

近几年来，随着国内汽车产业的快速发展，本土化汽车操作系统的发展与落地成为行业关注的重要话题。

行业背景

汽车操作系统是一个非常大的概念，不同组织尚未形成统一的认知。

我们首先看一下整个行业的发展，这个图是汽车的架构发展情况，我们关注的E/E架构变革所带来的软件变化情况。

回顾软件的发展历程，要实现软件的高质量和低成本，唯一的路径就是复用。软件复用需要有一套统一的体系，主要是指开发体系，这个其实是靠不同层级来实现。

对于汽车E/E架构而言，传统以嵌入式为主的这种分布式架构，比较难实现高层级的软件复用，大部分都是由供应商来提供整套软硬件，行业也在使用一些统一的软件基础架构，典型代表就是AUTOSAR，它的主要目的就是为了统一的进行软件的底层设计，提供一些通用的软件模块。这个国外发展比较早，国内大概从2016年开始慢慢热起来。

因为供应商提供整套软件，OEM对这一块有比较强的约束，所以AUTOSAR没有达成其它IT行业的统一软件平台概念。

传统的车机系统和车内系统存在割裂，一般车机系统以安卓为主，车内和车机系统交互没那么多。

发展到域控制器架构，POSIX成为新的创新点。我们发现无论针对中央域还是智驾域，都属于POSIX系统，包括有一些好的创新功能，都在这个系统里面来做。

然而在不同的操作系统下做开发和协同，效率不是很高，然后在域控接口中这种跨核的协同要求越来越多，因此行业需要一种更好的开发方式。

那前面说了一些行业背景，这也是一个新的操作系统诞生的时机。 回顾过去，操作系统基本都是在行业变革期出现。举个例子Linux和UNIX，初衷是为了解决在处理器上并行的问题。

由于操作系统会和生态的关系特别紧密，它会形成强者恒强的马太效应。一旦进入行业稳定期后，很难替代成型的操作系统。

目前中国汽车处于产业变革期，大算力芯片给应用开发带来更多的扩展性，传统MCU开发功能特别有限，大算力芯片可以开发更多更好的功能。随着域控制器逐渐成为主流，软件将会发挥越来越重要的作用。

我们讲的开发视图就是与工作台的交互，主要在于通信矩阵，它很少参与具体模块的定义和模块开发，但是它们是和消费者直接接触的，能更好感受消费者的需求。针对这种情况，越来越多的车企会主导软件的设计和开发。

新的应用，新的硬件体系，需要新的开发方法，现在就是一个适合的时间点。

新的操作系统是解决问题的关键

在新的技术变更和行业发展趋势下，汽车原有的开发生态发生颠覆性的改变，传统的开发模式已经不能满足市场对整车开发速度及功能迭代要求。

整体复杂度高，软件复杂度高，同时传统的组织架构 可能对于新架构可能都不是特别适应，包括我们说的一些开发方法都不一样。

针对这种情况，新的平台能够解决这个问题。主要体现在两个方面：承上启下、继往开来。

承上启下

SDV趋势下，底层硬件高速发展，应用需求日新月异。需要中间件层软件做好上下层的衔接。

对上（应用）：提供标准中间层框架，为应用迭代开发提供基础。

对下（硬件）：提供标准设备驱动模型，与硬件互相促进，形成“摩尔定律”。

继往开来

作为基础软件通用标准，AUTOSAR架构提供了稳定的底层平台及开发方法学，但有些跟不上国内SDV高速发展。新的中间层架构要考虑到标准平台的平稳发展，需要做到：

兼容过往：兼容标准AUTOSAR架构，复用现有的大量经过验证的核心控制和应用。

支撑未来： 提供新的功能与特性，支撑新形势下多核异构硬件体系，跨域协同一体化的应用开发需求。

本土操作系统发展策略和挑战

针对本土汽车操作系统，也是有一些策略的。首先构建面向新应用领域的开发架构。在既有成熟体系上，构建承上启下的应用开发框架，同时在解决问题的过程中，发展自己的生态体系。

第二、推动基础模块的本土化替换。以前的一些有积累的企业，可能因为没有历史机遇，没有把知识转化为汽车类产品，现在机会来了。所以我们应该推动符合汽车功能安全需求的微内核操作系统的国产化替代。针对上面提到的AUTOSAR架构，我们可以自己定义一些中间件。

第三、与本土芯片企业合作。形成国产操作系统和芯片的组合方案，并实现对新应用框架的良好适配，才能够获得占领市场的机会。

接下来我们看看国产汽车操作系统面临的挑战。

首先从狭义操作系统看，面临的主要问题是生态不足，生态可以分两块，一块是针对芯片的支持。另一个是缺乏与内核配套的开发工具，比如像性能调试工具。

AUTOSAR标准产品方面，标准不一致，产品稳定性不够成熟，功能安全和信息安全支撑能力不足，工具链易用性及完整性急需提高。

中间件方面，目前处于百家争鸣阶段，技术路线不统一，未达成行业共识。没有跨核、跨域协同的中间件产品，缺乏面向域控制器的专用中间件标准组件，缺乏整车视角的开发工具链。

从整个行业看，软件力量比较分散，最近两三年可能会好一些，每个主机厂都会希望自己做一套这种从上到下全能，符合OEM自己的一套系统，这样就造成软件力量的分散。随着行业软件的发展，我们发现分工才能促进各自在不同领域的效率提升。

另一个就是人才不足，我是从前年开始就发现，每一家车企，包括供应商团队人才都是比较缺的。尤其是软件+整车的复合型人才。

芯片问题我们之前讲了，操作系统或者内核，芯片的支撑是非常关键的。如果没有这个支撑，其实它也没法用。虽然中国半导体市场需求旺盛，但是汽车芯片自给率不足5%，国产芯片装车率低。比较好的就是我们在这一块正在逐步加强。

最后就是标准，我们之前使用AUTOSAR的时候，发现国外的标准上投入确实挺多的，但是国内缺乏统一的标准。最近国内的标准也在加强，包含行业的组织，民间的组织也在不断推进标准的建设。

本土汽车操作系统发展关键要素

我们首先看到应用的创新和快速迭代，已经成为我们国内行业的核心竞争力。我们的感受尤其明显，无论是车型的推出速度，还是软件的更新速度，都是越来越快。

我们作为行业参与者，大量从业人员为了应对创新和快速迭代，大家都在一种高负荷的工作状态。

针对这种现状，我们认为“集中式”开发是实现智能汽车核心竞争力的有效方法。

对比传统的多控制器同时开发，“集中式”开发的速度更快，更容易实现一次开发多车型通用，在OTA指标、代码量、开发方式、开发效率等外在表现价值方面来看尤为明显 。
另外就是代码增长趋势，目前智能汽车软件代码已经到1亿行，年均符合增长率约为21%，呈指数级增长，预计到2025年，智能汽车代码量将达到7亿行。

软件如果不是集中式开发，不是在统一的体系中开发，实现软件复用和迭代会很困难，而且后续维护成本完全不可控。所以集中式开发对于整个项目的成本控制，有非常大的提升。

针对前面说的发展需求，一个是创新速度，一个是开发成本，我们是需要长期重点解决的，而多域融合是解决问题必须的需求。

多域融合大概分为以下几个方向:

第一个是整车抽象，当然这个抽象我们提了好久，有的也叫原子服务，有的叫整车功能API化，它就是为了支持SDV的落地。它的核心不在于功能怎么定义，在于承载功能的运行框架，就是你开发者如何进行调用，这是非常关键的。

第二个就是容器化部署，就是应用之间的开发不是强耦合的，可以灵活在异构OS上快速移植运行。

分布式软件实体和基础框架融合，这些都是为集中式开发提供基础。

本土汽车操作系统量产实践

前面我们讲了需要为开发者提供的功能，下面讲讲这一块的实践。

针对标准化组织的引入，我们在AUTOSEMO下面成立了一个工作组，主要是为了解决低功耗下，这种广义操作系统的一些问题，目前大概有30多家企业参与。

除了针对组织外，我们东软睿驰也有针对行业变革的探索产品NeuSAR，我们提供一个广义操作系统，为使用者提供一些基础性的工具，它包含有标准的AUTOSAR、APCP产品，支持传统的ECU开发，同时又对基于域控制器和新E/E架构的软件开发提供丰富的基础软件、跨域中间件和开发工具。

NeuSAR SF(Service Framework)主要解决跨域融合的问题，兼容ASF标准的SOA中间件，并提供多于ASF标准的功能，支持基础服务的同时，把开发视图从域控制器层面扩展到了整车层面，是支撑整车SOA的关键组件与落地架构。比如说诊断，诊断在外部看是一个节点，但是从内部看有A还有M系数，不同的诊断路径就需要一个协调统一的中台。另外像域控制器的时钟服务、日志融合等都需要这种中间件。

整车层面也需要这些基础的服务， 比如日志系统，收集整车日志放到云端进行分析，云端会根据结果下发一些控制指令。

这些都是我们国内开发者需求比较多的，也是创新点比较多的地方。我们认为这套组件可以抽象成标准的基础服务，对开发者的效率有很大的提升。

最后就是基于NeuSAR相关的工具链，第一个叫NeuSAR Creator，我们发现好多功能需要A核和MCU一起开发，如果是传统的开发方式，需要使用两个工具，分别配置，分别生成代码，也可能需要双关系代码框架，需要换一种工具进行编辑，换另外一种工具进行编译。在工具的切换上花费大量时间，而我们将这些功能都放在一个开发视图，不用频繁切换工具，节省时间提高效率。

第二个就是调试与测试工具，典型的就是针对以太网的调试，这类工具不是特别多，而且价格特别贵。

最后就是仿真工具，特别是在自动驾驶领域，特别需要总线级的数据记录或者回放功能。在不同的车型、不同的硬件下，目前还没有统一的一套仿真系统。基于我们自己的这套仿真系统，只要总线支持不同系统，支持不同芯片，包括不同的物理通信总线，它在可以提供一套统一的语义来进行数据的录制和回放。

最后NeuSAR是我们的一个基础产品，到去年已经更新到第四个版本，也是得益于国内行业发展，给我们提供了好多机会，从最开始只做AUTOSAR AP产品，发展到整车级。这里也要感谢给我们提供需求、提供锻炼环境的车企，还有好多合作伙伴，给我们提供支持。

以上就是今天分享的内容，谢谢大家！

问答环节

Q：基础软件对于广义和狭义操作系统而言，有什么区别？

可以这样理解，狭义单指操作系统的内核。然后基础软件这个概念，在头几年专门指AUTOSAR这种CP产品。新形式下，基础软件会和狭义操作系统构成广义操作系统。

Q：为什么一定要用AUTOSAR的体系，SOMEIP、DDS这样的协议直接用于实现部分域功能，甚至整车SOA，有什么问题？

那个首先回答一下为什么使用AUTOSAR，因为 AUTOSAR 这个体系已经提供了大量的、成型的功能，它提供的基础层是比较充分的，大量的应用也是基于AUTOSAR CP开发的。它也是占了一个先机，已经成为了事实上的行业操作系统，已经有大量的生态，想要替换非常困难。

另外就是SOMEIP、DDS用于整个SOA的问题，首先SOMEIP、DDS基于以太网来做会更短一些，针对总线而言，支持不是特别多。另外就是DDS挺“重”，它在M系统上跑起来挺难的。SOMEIP比较死板，所有的东西都是先配置，这种对于传统开发接受程度高，但是对于自动驾驶这种开发需求而言，接受度特别低，喜欢比较灵活的和简单的接口。我们也是考虑到不同的开发者需求，提供兼容SOMEIP和AUTOSAR的接口，能够兼容不同的系统，支持bu一些开发需求。咱们前面提了，叫继往开来。

Q：老师能解释一下NeuSAR SF的功能吗？

简单来说它就是解决跨域融合问题，针对不同域控制器之间的统一开发。这个主要是为了解放开发者，让他们不用把大量时间精力花在底层硬件适配上，让他们把精力换在能直接创造用户使用价值的应用上。

Q：老师能介绍一下车载操作系统的OTA模块？

OTA其实不是一个新技术，随着域控制器发展，目前都叫整个OTA，就是说整个所有的控制器都可以用它升级。这里的难点就是前面提到的集中式开发。

很多时候我们发现难点不在于OTA本身用什么协议，升级链路等等，这些都是可以穷举的。真正的难点在于整车软件的统一版本控制。这就需要集中式开发，集中式就相当于有统一的开发视图。回到OTA本身，它只是提供了升级的路径，但是OTA方面得提供针对版本的统一管理。随着车型的增多，可能每个车型上的软件也存在版本差异，比如控制车门的算法可能都不一样，这需要OTA提供版本管理功能。

Q：老师可以讲讲车载以太网架构吗？

车载以太网主要差别就在于二层，三层以上的协议和IT行业基本一样，这些差别用户感知不多。这一块可以去看经典书籍，像《TCP/IP详解》。