汽车开放系统架构

什么是AUTOSAR？

AUTOSAR，全称为Automotive Open System Architecture，即汽车开放系统架构。它是由全球各家汽车制造商、零部件供应商以及各种研究、服务机构共同参与的一种汽车电子系统的合作开发框架，并建立了一个开放的汽车控制器（ECU）标准软件架构。

AUTOSAR联盟是在2003年由9家汽车行业的巨头（宝马、博世、大陆、戴姆勒、福特、通用、PSA、丰田、大众）建立的。这9家公司后来也称为AUTOSAR联盟的核心成员。截至2020年3月， AUTOSAR已经拥有了57家高级成员、50家开发成员、142家普通成员以及20家观察员公司及机构，包括全球各大主流整车厂、一级供应商、标准软件供应商、开发工具和服务提供商、半导体供应商、高校和研究机构等。许多中国厂商也是AUTOSAR联盟成员，例如长城、东风、一汽、上汽、吉利、蔚来、拜腾、宁德时代等。

比较特殊的是，目前炙手可热的特斯拉却没有加入AUTOSAR。这意味着他们很可能拥有自己的一套E/E开发流程和控制器软件架构。

为什么需要AUTOSAR?

从上个世纪80年代汽车控制器出现开始，汽车的电子控制系统一直在高速发展，面临的挑战也越来越多，主要体现在以下几个方面：

• 汽车的电气化电子化程度提高，控制器数量增加，网络复杂度增加。
• 软件功能数量急剧增加
• 硬件平台多样化，软件可复用性差
• 软件开发周期缩短
• 软件成本占比增加
• 我们再来看看汽车行业里整车厂和供应商的关系。

汽车行业里有众多的整车厂（OEM）和供应商。一般来说，每一家OEM会生产不止一种车型，每一家OEM对不同子系统和零部件会选择不止一个供应商，每个供应商也会向不止一家OEM供货。减少开发成本最有效的办法就是，尽可能让产品可重复利用，用数量来分摊开发成本。OEM希望可以让同一套系统和部件用在不同的车型上；同一辆车上来自不同供应商的的各个系统和部件可以相互兼容；而供应商希望开发出来的部件和算法可以通过简单的软件调整就供给不同的OEM。

另一方面，各个供应商的开发进度往往是不同步的。人们希望可以在供应商开发的过程中就可以测试该部件能否与整车上的其它系统正确配合。因此需要一种统一的、标准化的系统描述方法。

这便是AUTOSAR的初衷，即通过提升OEM以及供应商之间软件模块的可复用性和可互换性来改进对复杂汽车电子电气架构的管理。

为此，AUTOSAR做了以下3件事情：

• 对应用软件与底层软件之间以及应用软件之间的接口进行标准化
• 给出一个控制器软件参考架构
• 规范分布式开发流程中的交换格式

通过这些手段，AUTOSAR希望可以做到：

• 提高软件的可扩展性和灵活性，方便应用功能的集成和转换，以及控制器网络的优化
• 提升软件的可复用性
• 降低产品和流程的复杂度和风险
• 提升软件的开发和更新速度
• 降低软件开发和维护成本

AUTOSAR提出了一个口号，叫做“Cooperate on standards, compete on implementation”。意思就是汽车行业的整车厂和供应商共同合作开发一套汽车电子系统的软件开发标准，这样大家就可以专注于功能的开发，而无需顾虑目标硬件平台。

打个简单的比方。整车和零部件就好比是电脑和外设的关系，它们之间通过标准的USB接口来连接。无论是联想的电脑，还是戴尔的电脑，无论是100块的鼠标，还是1000块的鼠标，它们都互相可以即插即用。电脑厂家可以专注做自己的电脑，而无需考虑会外接什么样的鼠标键盘；相应的，外设厂可以专注做自己的鼠标键盘，而无需考虑会用在什么样的电脑上。它们之间的接口和交换格式，已经由USB标准规定了。这就是标准化带来的便利。

AUTOSAR怎么做？

在一个汽车控制器中，除了实现具体功能及算法的应用软件，还有许多底层软件来保证控制器的正常运行，比如CAN总线信号的收发、任务进程的调度、Flash数据的读写等等。一方面，不同控制器中这部分底层软件的功能重复度很高；而另一方面这部分底层软件又跟硬件紧密相连，在一个处理器平台上写好的软件，换一个处理器平台就不能用了。去为每一个控制器项目专门写一套底层软件显然是非常低效的，而且也容易出错。

于是人们就想通过标准化应用软件和底层软件之间的接口，来让应用软件开发者可以专注于具体应用功能的开发，而无需考虑控制器底层的运行过程。这样即使更换了处理器硬件，应用软件也无需做太多修改就可以被移植过去。而底层软件的开发则交给专门的公司，他们为每一个处理器硬件写好驱动，并封装成标准化接口提供给上层。这样底层软件就可以被高效地集成到不同项目中。而由于同一套底层软件被大量重复使用，发现bug的概率大大提高，从而可以很快得到修补，并且通过更新对其它项目进行同步修补。

AUTOSAR基本框架

• CP：Classic Platform
  分层软件体系结构描述了AUTOSAR的软件体系结构，以自顶向下的方式描述了AUTOSAR软件的层次结构：
  
  BSW分层架构为：
  
  BSW功能模块划分：
  
• 微控制器（Microcontroller）：即控制器硬件。
• 基础软件层（Basic Software Layer，BSW）:基础软件层，它包含了以下4个部分：
• 微控制器抽象层（Microcontroller Abstraction Layer，MCAL）：是与硬件直接相关的驱动软件，例如对存储器、通信寄存器、IO口的操作等等。
• ECU抽象层（ECU Abstraction Layer，ECUAL）：是对控制器的基础功能和接口进行统一，比如CAN报文内容的解析、网关报文的转发、存储器读写流程的控制等等。
• 服务层（Services Layer）：为应用层提供各种后台服务，比如网络管理、存储器管理、总线通信管理服务以及操作系统等。
• 复杂设备驱动（Complex Device Drivers，CDD）：为用户提供了一个可以自行编写特殊设备驱动软件的可能性。
• 运行环境（Runtime Environment，RTE）：是AUTOSAR的核心，它将应用软件层与基础软件层剥离开来，为应用层软件提供运行环境，如进程时间片调度、应用层模块之间以及应用层与基础软件层之间的数据交换等。
• 应用软件层（Application Software Layer，ASW）：即实现具体应用功能的软件。它可以包含多个软件组件（Software Component，SWC）。

基本概念

Software Component (SW-C)：软件组件
Virtual Functional Bus (VFB)：虚拟功能总线
Runtime Environment (RTE)：运行环境（实时环境）
Basic Software（BSW）:基础软件
Methodology principle：方法论原理
Mode Management：模式管理
Memory Abstraction：存储抽象
Runnables：可运行实体

文档命名规则

EXP: 即Explaination"解释"，详细介绍论题
MMOD: 即Meta Model"元模型",介绍 AUTOSAR元模型
MOD: 即Model"建模",介绍建模的原理
RS: 即Requirement Specification"需求规范", 详细介绍需求
SRS: 即Softeware Requirement Specification"软件需求规范", 描述所有软件模块的规范
SWS: 即Softeware Specification"软件规范", 介绍软件模块设计和实现的规范
TPS: 即Template Specification"模板规范", 详细介绍元模型
TR: 即Technical Specification"技术规范",详细介绍技术规范

链接

汽车开放系统架构（AUTOSAR）是什么
AUTOSAR
规范文档
来来来！我告诉你 AUTOSAR架构深度解析从入门到放弃