#01 中小企业为什么对AUTOSAR望而却步？

天下苦于AUTOSAR久矣，苦于Vector久矣！

AUTOSAR从成立至今已20多年，如今AUTOSAR已在汽车开发领域渗透率极高，很多汽车电子企业也都“无脑”运用AUTOSAR，以在产品宣传时能够体现自己的“高大上”，行业内从业者若没接触过AUTOSAR似乎都觉得自己落伍快被行业淘汰一样。然而当今市面AUTOSAR服务商总是给人“价格高、技术门槛高”等诸多印象，主流服务商Vector价格也确实高达几百万、上千万，即使国内AUTOSAR服务商东软睿驰、普华、恒润等价格也得数百万。现实的价格及人力资源投入等因素，使得很多中小企业对于AUTOSAR只能望而却步。

AUTOSAR作为全球标准的软件架构技术，它的作用不仅仅是定义了汽车电子产品中各个模块及接口的设计规范，更多地传递了软件架构设计的思想和理念。本文将利用AUTOSAR软件架构思想，提供小公司简化可实施“AUTOSAR”解决方案。本文呼吁各企业和从业的软件工程师们从软件本质出发、从思想出发，去建立和完善公司的软件产品。

本人接触AUTOSAR时间并不长，将学习AUTOSAR过程中一点心得用于分享，由于本人水平有限，本文仅为个人一己之见，不足之处还望大家批评指正，共同学习，一起成长；

#02 什么是AUTOSAR？

如何使用AUTOSAR，首先需要搞明白AUTOSAR的基本内容，其次设计符合自己公司的软件架构。

2.1 背景

在汽车领域，人们对电子化的要求逐渐变高，汽车电子成本占据整车费用的份额越来越高。随着EE架构逐渐趋于集中化，汽车软件系统出现了多种操作系统并存的局面，导致系统复杂性、开发成本的剧增。为了提高软件的管理性、移植性、裁剪性及质量，需要定义一套架构、方法和应用接口以实现标准的接口、高质量的无缝集成、高效的开发以及通过新的模型来管理复杂的系统。

AUTOSAR（Automotive Open System Architecture）联盟最初是在由9家汽车行业的巨头（宝马、博世、大陆、戴姆勒、福特、通用、PSA、丰田、大众）成立，截至目前行业内已高达300多家企业或组织加入AUTOSAR，共同参与制定了汽车电子系统的合作开发架构，该架构旨在改善汽车电子系统软件的更新与交换，同时更方便有效地管理日趋复杂的汽车电子软件系统。AUTOSAR规范的运用使得不同结构的电子控制单元的接口特征标准化，应用软件具备更好的可扩展性以及可移植性，能够实现对现有软件的重用，大大降低了重复性工作，缩短开发周期。自成立以来，AUTOSAR一直致力于为汽车行业开发和引入开放且标准化的软件架构，尤其在汽车智能化领域，发挥着越来越重要的作用，是目前世界上最具影响力的汽车电子软件全球合作联盟。

2.2 Classic Platform AUTOSAR

AUTOSAR分为Classic Platform AUTOSAR（CP）和Adaptive Platform AUTOSAR（AP）两个平台。经典平台CP是用于众多汽车电子控制单元（ECU）的AUTOSAR架构，目前已广泛应用于传统嵌入式ECU中，如发动机控制器、电机控制器、整车控制器、BMS控制器等等。其次，自适应平台AP是随着近年来汽车信息娱乐系统的发展而兴起的一种AUTOSAR架构。这种架构主要应用在带有高级操作系统（如Linux或QNX）的车载系统级芯片（SoC）上，未来会更多地应用于如ADAS、自动驾驶等需求高计算能力、高带宽通信、分布式部署的下一代汽车应用领域中。这两种分类代表了AUTOSAR软件在汽车工业中的不同应用场景和需求。

本文中主要研究AUTOSAR CP。

AUTOSAR CP架构定义设计了三个软件层：以运行时环境层RTE（Runtime Environment）为界，隔离上层的应用层ASW（Application Layer）与下层的基础软件BSW（Basic Software）。其中BSW进一步定义成为服务层（Service Layer）、ECU抽象层（ECU Abstraction Layer）、微控制器抽象层（MicroController Abstraction Layer，即MCAL）和复杂驱动层（Complex Drivers Layer，即CCD）。

图1 AUTOSAR分层架构

每个软件层可以进一步按照功能分成模块块组，每个模块组都包含相应的模块。如服务层（Service Layer）包含通讯服务组（Communication Services），该组中包含Com、Dcm、PduR等模块。

图2 AUTOSAR模块

2.3 开发方法论

AUTOSAR的出现革新了汽车软件的开发流程，形成了囊括OEM主机厂、Tier1、中间件厂商等在内的开发流程。

图3 图片来源：华泰研究

OEM进行逻辑系统和物理系统的设计（定义EE架构网络结构、总线配置、传输的信息单元，将整车设计的不同功能分配到 ECU上）并生成配置文件ARXML，提供SWC系统模型和通信矩阵，交付给Tier1。

图4 零部件软件开发

Tier1则基于OEM需求进行ECU的设计开发。Tier1可以通过直接购买AUTOSAR方案，只需要通过配置工具按照需求和硬件方案进行相应的配置，包括根据配置开发软件SWC的接口设计，对不同ECU的数据映射，生成RTE、BSW、SWC Template代码，可以极大的缩减软件开发时间，并保障基础软件的质量。Tier1则在生成代码框架基础上将精力花在产品功能开发，调试等。

#03如何设计小公司的“AUTOSAR”？

天下苦于AUTOSAR久矣，苦于Vector久矣，揭开AUTOSAR的面纱，小企业也能轻松使用“AUTOSAR”

AUTOSAR的本质目的即为软件的通用性。

小公司往往涉及产品比较杂，面对的客户较多，各种五花八门的需求都需要应和，且小公司往往容易追求短期利益，在不断降本道路上老是喜欢主芯片切来切去，一发现某家公司推出新的性价比的芯片，就迫不及待的进行切换，此外，芯片国产化也催生了各种各样的芯片在小公司的运用变得非常普遍。那小公司到底应该是什么样的AUTOSAR？

小公司依然需要以软件通用性为设计原则，只要坚持软件通用性为原则的软件，我们即可称为“AUTOSAR”，当然各自公司可以重新自己拟个名称就行了，并非非得都叫“AUTOSAR”，该软件可以无论什么产品、无论客户什么需求、无论芯片怎么换，在本公司内都能够轻松应对，同时兼备很好的便捷性、维护性、迭代性，那一定是非常优秀的软件。

3.1 分层架构设计

图5 分层架构设计

本着简单实用的原则，共设计4层架构：

·APPL：软件功能层面的相关模块处理，与产品功能息息相关，包含信号指令处理、功能逻辑判断等；类似AUTOSAR中的ASW层软件内容。

·MIDL：包含操作系统、诊断、故障等通用功能的处理，与产品功能没有直接关系；类似AUTOSAR中的Services层软件内容。

·LOWL：将底层模块抽象化，与MCU没有直接关系；类似AUTOSAR中的ECU Abstraction Layer层软件内容。

·MCAL：与芯片直接相关的驱动软件部分，该软件往往直接由芯片厂提供。这里指的MCAL并不要求芯片厂商提供的底层代码按照相应的标准软件规范执行，当然对于企业来讲，如果芯片厂商提供的Demo软件无法看，更好的软件质量管控最好底层代码最好还是自己来写。

与AUTOSAR相比，本架构设计从顶层设计上去除了CDD复杂驱动和RTE，因为对于个体公司而言，整个APPL，MIDL，LOWL都为自主研发设计，并无必要严格的区分复杂驱动部分。关于RTE的解释请看下个小节说明。

对公司而言，需要确保APPL、MIDL、LOWL在切换产品、切换芯片、切换需求等等变化中，都能保障软件结构的稳定，软件接口的稳定，那这样的软件即为公司自己的“AUTOSAR”。

3.2 模块设计

小公司在设计软件时，需要更多地考虑轻便和易用，需要结合公司自身实际情况进行模块设计。如下图仅是列出了部分常用的设计模块。

图6 “AUTOSAR”模块

图中APPL模块“XXX”代表公司与产品相关的功能模块，各公司可以自行定义。

3.2.1 通讯功能

这边的通讯模块设计与AUTOSAR中很大的区别是去除了PduR模块，PduR的功能则由Com承担；当然我们很多产品并不需要复杂的消息路由功能，Com收到消息时，仅需判断Id信息，即可再分发给AppCom，Uds或者Nm等；

图7 通讯功能

·CanIf与LinIf：底层的抽象，设计通用的Can与Lin接口

·Com：消息分发，通讯控制，信号解析提供信号接口等

·AppCom：读写消息接口

3.2.2 诊断功能

图8 诊断功能

·CanIf与LinIf：底层的抽象，设计通用的Can与Lin接口

·Com：识别诊断消息，分发给Tp模块

·Tp：诊断消息的拆包与封装处理

·Uds：UDS协议（类似AUTOSAR中Dcm模块）

·Fault：故障处理（类似AUTOSAR中Det模块）

·AppDiag：读写诊断指令接口

3.2.3 模块关系

清晰的架构需要遵守相应的调用关系，然而实际中，我们经常容易看到混乱一大堆的去随意引用头文件，虽然编译器会帮忙处理背后的关系，但是实际是软件架构的紊乱。

本软件设计中，并未像AUTOSAR一样，设计隔离Asw与Bsw的RTE， RTE的思想渗透到每个模块，每个模块都带有<Module>Rte.h，文件，无论是应用层软件还是底层软件。

> 图9 模块与模块之间的调用关系

实际运用时，可以只需要在该Module的Rte头文件中包含必要的<Module>.h文件，及使用extern关键词引用相应的接口函数或者配置即可。这样可以极大避免模块之间的紊乱的调用关系。

此外本架构中，仅设计了一个Cfg.h和Cfg.c文件，没有像AUTOSAR中区分了Pre-compile、Link和Post-build三种类型的配置形式，这样也极大简化了模块设计复杂度。

图11 子模块之间的调用关系