什么是汽车基础软件？为什么要做汽车基础软件？

什么是汽车基础软件

基础软件（Basic Software）似乎是汽车行业独有的一个软件分类，有时候也叫底层软件（Low Level Software）或者底层技术（Base Tech）。汽车行业分工细致，上下游产业链丰富，很多并非从事基础软件相关工作的汽车工程师对汽车基础软件并不是很了解。本文尝试针对初学者作简单的介绍和探讨，基础软件大佬请自动略过或批评指正。

那究竟什么是汽车基础软件呢？这是很多初接触者经常会问的问题。如果以传统计算机行业术语类比，基础软件应该最接近于计算机中的驱动软件。抽象来看，两者都是硬件或操作系统和应用软件之间的桥梁。举个类比的例子，我们平时电脑上用Word打印文件是一个很简单的操作。

电脑连接一个新的打印机时，我们往往要安装一个新的打印机驱动程序，但是Word软件本身并不需要更改或重新安装。这里的打印机就像是汽车行业中众多的硬件，Word软件就像是汽车行业中丰富的应用软件（Application Software, ASW），而这里的打印机驱动软件就最像是汽车行业中的基础软件，解耦软硬件，让应用软件可以适配不同的硬件。

图1：打印机驱动软件（类似汽车行业基础软件）示意图

而如果要进一步深究基础软件的精确定义，那只能搬出汽车基础软件届大佬组织AUTOSAR中的定义描述： ——“The Basic Software (BSW) provides the infrastructural (schematic dependent and schematic independent) functionalities of an“Electronic Control Unit.” 这个定义似乎也比较抽象和泛化，但这也许正是基础软件的外延。因为在汽车行业，似乎除了功能应用软件，其他软件部分在不同场景下都可以称为基础软件。有些时候基础软件也延伸为基础技术或者平台服务等名字，这时候其往往还包含了一部分传统意义上的应用软件模块。

因为“基础”这个定义本身就是相对的，在不同语境下有不同的内涵。就像很多产业工人会自称基层，很多高级工程师也自称基层，很多高级经理也自称基层。以下图经典AUTOSAR架构为例，狭义的基础软件就是硬件和运行时环境（RTE）之间的这部分软件，但在某些讨论背景下，例如讨论OTA升级功能时，基础软件和基础技术的外延往往会延伸到包括RTE和部分应用软件（对应AUTOSAR中的SWC）。

图2：狭义和广义基础软件示意图

为什么要做汽车基础软件

基础软件往往是从demo走向量产的关键难题，也往往是OEM从企业或者整车层面定义得最多最详尽最复杂的需求。传统外资OEM像大众、宝马、福特、通用等公司都会定义详细的基础软件需求，往往高达上百篇文档，上十万条需求。

基于这些详细的基础软件需求，留给Tier1的空间其实很小，有点像OEM已经把整个设计图纸都定义好了，就是让Tier1“代工”把基础软件实现出来。这背后也是这类强势OEM的一种战略要求：掌握汽车软件的核心技术能力，让车上所有控制器及其软件都按自己的要求标准化、平台化，方便统一调度，也方便切换不同的供应商，进一步加固自己在行业的核心地位。

汽车上的软件越来越多，而这并不仅仅是多了几百万行代码那么简单。这背后实际上是要求汽车具备更丰富而完善的软件基础设施（infrastructure），涵盖从开发到部署到维护的整个过程。将基础软件独立地分离出来一个类别，并集中精力地设计开发，可以带来以下明显的好处：

1.软硬件解耦

这是基础软件最突出的使命和优势。就如开头举的Word软件和打印机的例子，用户需求肯定包括Word软件要适配不同的打印机硬件，而有了驱动程序后，Word应用软件就可以和打印机硬件解耦。设计Word软件的工程师可以专注于应用软件本身，打印机厂家也可以专注于打印机本身的设计，专注各自领域并把事情做好。这对汽车上数百个软硬件复合的用户功能来说也是一样。在“缺芯”时代，正是由于基础软件的存在，才让那么多汽车厂家可以有效地找寻替代料，切换芯片供应商，保障供应。

2.提高鲁棒性

“稳定”、“安全”、“可靠”等特性对于汽车行业来说都具有特殊的意义，对汽车软件尤甚。汽车毕竟事关驾驶员和乘客的生命安全，而且往往会行驶十几年，攀山涉水，环境变量复杂。通过细分基础软件，可以让各个开发方专注领域内的设计开发，完善各自领域内的软件开发规范和流程，保障软件质量。同时，标准化的模块和接口以及其标准化的属性，都可以让产品在顶层设计时就充分考虑到软件的可靠性。

3.提高复用性

汽车基础软件的独立，实质上是带着“高内聚”和“低耦合”的面向对象的思想。标准化的模块和接口可以给基础软件带来很强的复用性。基于这个优势，对成熟的基础软件模块，供应商都是提供相应的配置开发工具，由汽车软件工程师按照不同项目配置不同参数，再由工具自动生成源码。

所以汽车基础软件往往是第一次实现的时候需要很多人力物力，例如某新势力供应商第一次获得传统OEM的项目定点时。但是该供应商如果再做该OEM的后续项目时，哪怕是开发全新的应用功能，也可以很轻松地复用之前项目的大部分基础软件代码。

但是汽车基础软件也有其面临的挑战，一个是上文提到的第一次实现时需要大量人力物力投入，另一个是分层思想和软硬件解耦带来的效率损失。

前者的一个现实体现就是很多汽车新势力公司都不愿意投入巨量资源到基础软件的开发中，相比之下快速交付产品更为重要。后者则更多是产品设计理念的取舍。例如按网络披露的消息，特斯拉在自研FSD芯片的基础上，就采用了很多软硬件一体化的设计思想，并没有过多地开发层次化、标准化的基础软件，以提高硬件利用率和减少软件时延。

这种选择，在我看来就有点像选用瑞士军刀还是选用完备的刀具套装：各有利弊，得根据具体情况选择，没有必然结论。按行业观察，基础软件对于新势力来说很多时候是一种“技术羁绊”，而对很多传统汽车豪强来说则是他们的“技术积累”。

怎么做汽车基础软件

既然汽车基础软件事实上大量存在于汽车行业的软件开发项目中，那么实际上大家都是怎么开发的呢？ 谈到怎么实施的问题，就不得不提到AUTOSAR（Automotive Open System Architecture），它定义的主要范围就是基础软件。AUTOSAR汇聚了众多汽车行业顶尖软件大牛的智慧，是基于行业最佳实践而总结提炼的精华，并且应用了大量层次结构和面向对象的思想理念，也是汽车行业基础软件的事实标准。它在行业内的统治地位，通过下图所示的组织成员就可见一斑。

目前AUTOSAR分为Classic Platform AUTOSAR（CP）和Adaptive Platform AUTOSAR（AP）两个平台。CP是面向功能的FOA架构（Function-Oriented Architecture），目前广泛应用于传统嵌入式处理器中，如发动机控制器、电机控制器、ADAS域控制器中的MCU等。而AP则是面向服务的SOA架构（Servic-Oriented Architecture），应用于针对高计算能力、高带宽通信、分布式部署的智能驾驶域控制器和座舱控制器的SOC上。

下图是AUTOSAR通信协议栈的示意图。接下来我们以它为例子，看一下通信的具体实施。我们先从上往下看一下信号从应用层软件产生到发送到物理总线的过程。信号由应用层软件创建后，通过RTE发送至COM模块，它下面的软件不能区分信号，只能理解PDU。因此COM将信号打包成PDU，进一步传输给PDU Router。

PDU Router按照不同的传输协议将其传输给下游。如果PDU长度过大，则会先传给CAN TP或者FlexRay TP，将一条长的PDU分割成若干条满足协议要求的PDU。以CAN为例，CAN TP分割完PDU后会将其传给CAN Interface（CAN If）模块。

CAN If是ECU抽象层中的一个模块，它负责传输请求、传输确认和PDU模式控制等服务。CAN If往上的软件和接口都是对具体的CAN收发器硬件不感知的。然后CAN If会调用底层的CAN Driver模块，以控制和访问实际的CAN收发器硬件。CAN Driver为它上层的软件提供了硬件访问接口，亦即硬件抽象。FlexRay和LIN的数据下行也是同理。而当数据从物理总线接收再反馈到应用软件则是同理的逆向过程。

图5：AUTOSAR通信协议栈示意图

这个通信分层的架构，可以让各层软件各司其职，让应用层等软件屏蔽底层软硬件实现。例如不管是CAN、FlexRay、LIN还是以太网传输上来的PDU，都会汇总到PDU Router，再到COM，统一管理内存，这样应用层软件获取信号就可以只关注其端口号，而无需考虑它究竟从哪类总线传上来的，因为这对应用软件来说也没有意义。

而在实际操作层面，AUTOSAR基础软件标准化带来了高度的可复用性，成熟的工具链也往往可以让汽车软件工程师不用埋头写基础代码，而是通过配置来高效地生成可靠的软件代码。通过AUTOSAR的标准接口文件（*.arxml）可以很方便地在不同工具之间交互配置数据。

以下图的Vector工具链为例，OEM可以通过PREEvision设计整车EE架构，定义通信数据等，然后导出基于ECU抽象的*.arxml文件提供给供应商。通过DaVinci Developer等工具可以导出应用层SWC的*.arxml文件。基于模型的应用层软件工具（例如Matlab）可以利用该应用层接口文件生成满足AUTOSAR标准的应用层源码（*.c和*.h文件）。

而基础软件部分则可以通过导入ECU抽象的*.arxml文件和ODX诊断数据库等文件，在DaVinci Configurator中进行详细配置，生成RTE和各个BSW模块的源码（*.c和*.h文件）。基础软件、RTE和应用软件的源码合在同一个工程项目中后，就可以通过编译器生成可以刷写到ECU上的可执行代码（如*.hex或*.elf）。这个高效配置的工作流，既可以让开发者专注关键功能设计，又能保障生成的源码质量，是汽车基础软件优势的一个实践体现。

图6：Vector的AUTOSAR基础软件配置工作流示意图