AutoSAR入门：应用背景及简介

1、应用背景

在我们现在的汽车行业里面，汽车电子的发展过程中，我们发现有一些新的趋势汽车电子系统的复杂性不断增长。

我们现在可以看到车辆有越来越多的功能，那么这些功能呢，也在往这个控制器上进行集中，比如说我们现在看到有很多域控制器。那么域控制器本身呢，它可能负责很多的功能，那么这就导致了我们这个电子系统的复杂性不断的增长。同时，软件代码的数量也是急速的上升。

另外一方面的原因是在这个汽车电子发展过程中，我们发现整车寿命往往长于ECU的生命周期，那也就意味着在整车的生命周期里面，可能需要对ECU的软件进行开发和升级。与此同时可以看到有很多不同的硬件平台，比如说英飞凌的嵌入式平台，飞思卡尔的嵌入式平台，这些嵌入式平台的功能也随着电子系统的发展不断的增强，使得系统变得非常复杂，动辄就是几千页的文档。这些五花八门的硬件平台，使得电子开发过程变得非常复杂。如果说要切换硬件平台的话，就需要投入大量的人力去进行平台的学习和平台的切换。

这些嵌入式系统不支持硬件抽象，使得每次在进行新处理器更换的时候，都需要重新去进行底层软件的开发，软件的模块化的过程也是非常有限的，导致了现在汽车电子发展过程中就出现了很多的问题。

2、AutoSAR成员

在这个背景下，有一些主机厂和供应商就提出了这个AutoSAR的概念。AutoSAR是automotive open system architecture的缩写，是汽车开放系统架构的一个缩写。最初AutoSAR架构建立的时候，主要是有一些主机厂和供应商。

到2018年为止已经有55个高级会员和42个发展会员，可以看到有一些中国的企业参与到AutoSAR的标准的开发。除了这些高级会员，发展会员以外，还有外围会员。到目前为止，这个外围会员的数量已经有124家，在所有AutoSAT的组织会成员里面包含了主机商、半导体供应商、软件和工具的供应商。

3、AutoSAR发展历史

AutoSAR是在2003年建立，到现在的话已经发展了20年，经过这20年的发展呢，AutoSAR的最新版本是4.3.1。

在2005年的时候发布了1.0的版本，那在这个1.0版本里面呢，发布了最初的BSW，是一个初始版本。

到2006年和2007年的时候又发布了2.1版本，在2.1版本基本上就已经完成了一个完整的这个BSW。

到2007年2008年的时候发布了3.0的版本，在3.0版本里面体系已经基本上成熟了，在原先的这个2.0的版本上有很多的改进和更正，功能上也有一些增强。

到2013年的时候发布了4.0的版本，4.0版本增加了很多的特性，包括对多核操作系统的支持和对功能安全的支持，需要说明的一点是我们说的这些版本指的都是AutoSAR的classic platform。除了plasticic platform以外，AutoSAR现在还提出adapt platform，adapt platform相比classic platform的主要区别是它是面向服务的，服务可以驻留在本地的这个ECU上也可以在远程的ECU上，通过网络的形式进行服务的调用，今天我们主要介绍内容是classic platform的内容，在这个classic platform里面程序还是驻留在本地的ECU里面。

4、AutoSAR应用场景

classic platform的主要应用场景就是我们常见的传统的汽车ECU的应用，这些应用它有以下这些特点：

首先，它与硬件有很强的交互，需要这个传感器和执行器的支持。

第二方面，是通过车身网络进行连接，车身网络包括这个CAN总线，LIN总线，或者以太网，

第三方面，大部分都是基于16位获得32位的单片机进行开发的，从成本的角度考虑，片上资源相对来说都是比较有限的，因此这些ECU主要都是使用这个实时操作系统，代码也主要是存储在片内或者片外的flash。

classic platform是针对我们传统的以单片机为中心的这种汽车电子控制器，重新定义了他们的一个软件架构和软件开发方法。

5、AutoSAR开发方法

AutoSAR的口号是在这个标准上进行合作，在实现上进行竞争。

所以我们可以看到现在AutoSAR主要组成的文档实际上是由大量的requirement和spake，对于这个具体的实现方法并没有一个明确的规定，所以说我们仍然可以使用不同半导体供应商提供的单片机，使用不同工具商提供的这个软件开发工具，虽然实现方法没有明确的规定，但是他们的接口是统一的，这样做的好处就是在OEM进行开发的时候有更大的一个选择灵活性。

同时也避免了在切换过程中导致的一些问题和额外开销，但是现实的情况是为了满足这样一个目标，AutoSAR的要求还是比较复杂的，可以看到在这个AutoSAR标准设计的过程中，有很多目标，系统的可用性和安全性的要求，系统的冗余的要求，同时还要考虑系统在不同的车辆和不同的ECU和不同的这个平台上面可能需要进行一个裁剪，还要求底层软件也就是BSW作为一个标准的内核来进行提供，同时功能上面需要能够通过网络进行传递，也就是说我们这个ECU的功能要在网络上进行移植，要考虑到来自不同供应商提供模块，要能够进行整合，要考虑在整个产品的生命周期里面产品的软件要进行维护，要尽可能多的使用现成的硬件产品，而不是说要去进行单独的开发，要能够对软件进行在汽车的生命周期里面进行升级和更新，另外一方面AutoSAR平台应用的领域也要能够覆盖汽车的大部分的领域啊，比如说车身安全，以及底盘，还有人机界面和娱乐系统等等，这就使得AutoSAR的标准制定就非常的困难。

6、中间件

针对上述问题AutoSAR提出了一套解决方案，解决方案的核心就是我们使用AutoSAR软件来作为一个中间件。

在过去ECU的硬件和软件，往往是紧密相关的。如果要增加一些功能，或者是要更换控制平器平台，或者是要对这个硬件进行一些修改的话，ECU的开发往往是需要进行推倒重来的，那么在这个使用了中间件以后呢，我们有了模块化和标准化的一个软件平台，就使得很多软件模块，都是可以进行重用的，我们不需要去针对这个新增的功能，或者是ECU的一些变动，完全的对这个软件进行重新开发。从这个角度来讲我们可以说是使用了AutoSAR中间件技术实现了硬件和软件的一个解耦。

在后面的介绍里面，我们还会对这一点有更加深入的认识。

7、AutoSAR方法论

AutoSAR是尝试去统一以前的五花八门的硬件和软件的开发平台。从而对开发的过程进行简化。那么为了实现这个目的他把软件架构进行了标准化定义，同时还提出了一套标准化的开发方法，这个开发方法我们就把它称为AutoSAR的方法论。

方法论里面包括了使用AutoSAR软件平台进行ECU开发的流程。在流程里面介绍了是使用什么样的工具进行的开发？开发的输入是什么？输出是什么？通过标准化的开发流程使得工作可以在OEM和供应商之间进行分割。同时也使得我们在不同的阶段可以使用不同的工具来进行标准化的开发。那么这个在后面章节里面我们还会对这个AutoSAR的方法论再进一步的介绍。

8、AutoSAR软件架构

除了前面提到的标准化的开发流程以外，AutoSAR还提出了标准化的软件架构，在这个软件架构里面，把ECU的软件分割成若干层。在最上层是应用层软件，也就是ECU所要实现功能的软件。在应用软件层以下是我们所谓的runtime environment，也就是RTE。RTE实际上是将它以下的硬件特征和它以下的底层软件进行了隐藏，在这个意义上来讲，应用层开发软件并不需要关心我们使用的是什么样的底层硬件，或者是使用了什么样的底层软件服务，这样呢就可以实现对ECU底层软底层硬件的抽象。

9、AutoSAT标准化

AutoSAR的另外一个解决方案就是标准化，除了标准化的软件架构以外呢，还在另外几个方面对开发进行了规定，比如说我们这个交换格式的标准化。AutoSAR规定了一系列的以XML文件为基础的交换格式，所有的开发都可以基于AutoSAR提供的模板来进行软件和硬件的描述，对系统的描述。在OEM和供应商之间也可以进行这样信息的交换。