CP AUTOSAR 简介

嵌入式系统不支持硬件抽象，使得我们每次在进行新的处理器更换之后。都需要进行重新进行底层软件的开发。

2003年建立autosar 组织。

autosar官方文档非常长2万多页，从这里可以看出什么？

1、autosar的复杂度

2、AUTOSAR的不成熟，它依然在前进，依然在完善中。

 

AUTOSAR到底是什么？

AUTOSAR说白了，它就是一套标准，

• 标准了我们ECU的开发流程，
• 标准了我们开发流程中的文件交换格式
• 标准了我们ECU内部的代码应该如何去规范，如何书写。
• 
• 考虑系统的可用性和安全性，系统冗余的要求
• 考虑系统在不同的车辆，不同的ECU，不同的平台上可能需要进行裁剪
• 底层软件BSW作为一个标准的内核，来进行提供。
• 功能上需要能够通过网络进行传递，也就是说ECU的功能可以在网络上进行移植，
• 来自不同供应商提供的模块，要能够进行整合
• 考虑在整个产品的生命周期内，对产品的软件进行维护。
• 要尽可能多的使用现成的产品而不是要去单独开发，在汽车生命周期里进行软件更新的
• autosar平台应用的领域要覆盖汽车大部分领域，如车身、安全、底盘、人机界面和娱乐系统等。

使用AUTOSAR软件作为中间件，实现软件和硬件的解耦。

AUTOSAR尝试去统一以前的软件和硬件五花八门的开发平台，从而对开发的过程进行简化。

为了实现这个目的，AUTOSAR把软件平台的标准进行了定义。

同时还提出来一套标准化的开发方法：

方法论包括：

标准化的开发流程

使用AUTOSAR软件平台进行ECU开发的一个流程，并在流程中介绍了，什么样的角色，使用什么样的工具，进行什么样的开发。开发的输入是什么？输出是什么？通过这样一个标准化的开发流程，使得我们的工作可以在OEM和供应商之间进行分割。

同时可以让我们在不同的阶段使用不同的工具来进行标准化的开发。

 

标准化的软件架构

这张图描述了autosar对于ECU内部软件架构的定义。在标准化的软件架构中把ECU软件分为若干层

autosar说白了就是整个汽车电子行业对于IT行业的一次学习，RTE就是把IT行业的中间件拿过来。

Application layer ：ECU要实现的功能的软件。

RTE 层：将本层以下的硬件特征和底层软件进行隐藏。应用层开发软件，不需要关心，使用什么样的底层硬件，或者使用了什么样的底层软件服务。这样就可以实现一个ECU底层软件的抽象。说白了RTE就是负责所有通信行为的转发。

RTE之下就是autosar BSW，它由几个部分组成：

首先是服务层：为所有应用提供各种服务，其中包括操作系统，诊断、通信和内存管理、

ECU抽象层：它的存在是为了屏蔽芯片内部的资源和板上资源的差异性。

什么是最大的抽象？

Linux操作系统就是最大的抽象，用Linux你考虑过芯片是AMD还是Intel的吗？

你考虑过什么是主板吗？什么是声卡显卡吗？

不需要，微软替你搞定，一样autosar替你搞定。

 

微控制器抽象层：MCAL 屏蔽的是不同芯片的资源，它让你感觉不到你使用的飞思卡尔芯片还是英飞凌芯片。这就是MCAL的作用。

复杂驱动层：一直以来它最为神秘的一个层，说白了它什么都不是，复杂驱动这个框，什么都可以往里装，为什么？

因为autosar的目标是标准化，但是真正有工程经验的人都知道，这个世界上是没有办法百分百标准化的，不然工厂里为什么会有个非标部门呢？那么不能标准化的东西怎么办？

我们就放到复杂驱动里面去。典型应用如：发动机领域暴震控制，曲轴转角控制，集气门控制啊。这些都属于复杂设备驱动。

代码从来不是手写的，代码从来都是配置生成的，ECU的软件架构设计工具。

 

---

 

 

交换格式标准化：

AUTOSAR规定了一系列以XML文件为基础的模板，所有的开发都可以基于这些autosar提供的模板来进行软件和硬件的描述。

对系统的描述，也方便了在OEM和供应商之间的信息交换。

基础软件的标准化：

底层软件功能的规范标准化（AUTOSAR有很多软件规范，软件要求，里面规定了软件需要实现什么样的功能）

接口的标准化：不用关心软件内部是如何实现的，只需要调用这些标准化的接口就可以实现对应的功能了。

对单片机的抽象化：对不同平台的单片机进行抽象，不需要因为更换单片机而对软件进行完全重新开发。

基于VFB virtual functional BUS 的运行环境：

virtual functional BUS 就是RTE抽象的概念，所有的软件组件都是在 virtual functional BUS 上进行运行的。

 

AUTOSAR的基本概念：

这是一个非常抽象的对ECU功能进行描述的一个视图：

所有的SW-C软件组件，都是通过所谓的port（request port  response port 等）连接到virtual functional BUS

上面。所有的功能组件实际都是对ECU功能的描述，最后在实现过程中，都会生成在ECU上执行的代码。

这些功能组件，本身也是应用层软件，在开发之初不关心它具体在哪一个ECU上，也不关心它们之间是有什么样的方式

进行通讯，都是是有抽象的virtual functional BUS来对它们进行连接，virtual functional BUS可以实现SW-C软件组件之间的数据交换，同时也可以提供SW-C软件组件之间的服务调用。可以表示ECU内部的通讯，（内部总线通讯）也可以表示外部的一些总线通讯，如can总线，LIN总线

virtual functional BUS view下，我们把所有的底层的信息都进行了抽象，使得应用层开发可以完全独立于我们的ECU的映射和ECU的特性，关注应用层软件本身功能的开发，

对软件组件的介绍：

软件组件是AUTOSAR中Atomic component 最小逻辑单元，主要功能是实现算法 Application SWC，

还有一类：Sensor/actuator为Application提供传感器的输入，同时让应用层SWC能够对ECU进行操作。

 

这张图是对AUTOSAR软件和ECU硬件之间对应关系的描述，

SW-C1：是可以对传感器进行读取的应用程序，在它的右边

Sensor Component ：在硬件上对应的就是硬件的传感器，可能是一个开关量，在它的右边

ECU Abstraction ：ECU抽象层对应的就是我们在ECU上的一些硬件设计，在它的右边

MCAL ：单片机抽象层，对单片机的外设进行抽象，单片机输出端口

 

SW-C2：是可以灯光调节的应用程序，在它的右边

Acturator Component：对应的硬件可能就是一个执行器，一个灯光控制器，

SWC内部的运行实体：

就是SWC软件组件里面的函数，可以进行周期性或事件触发调度。也就是这些函数组成了SWC。

可以通过RTE对这些Runables进行定时的调用，把这些Runables通过RTE映射到我们的操作系统中后，就可以

通过RTE进行定时调用。

 

 

 

 

RTE有两方面功能：

1、实现数据的通信

2、实现任务的调度

RTE是VFB总线的实现，会与每个ECU有关系。

 

3 AUTOSAR方法论

 

 

系统约束文件，整车的电子电器架构。 

 

 

需要将runnable 映射到对应的task中去，生成对应的描述文件。

在实际开发中，这是ECU的开发过程，根据这些配置文件，可以使用对应的代码生成工具，可以生成ECU相关的

软件代码。

ECU的实现：根据前面ECU的配置文件和代码生成工具，如：RTE代码生成工具，底层软件生成工具。

这些生成工具，会把配置文件转换成对应的C代码，C代码再配合上autosar的lib库文件，再加上SWC实现的文件，

最后把这些文件进行整合，就可以生成ECU执行的二进制代码了。这就实现了ECU的软件开发的过程。

 

 

4 AUTOSAR 分层软件架构

 

 

 

 

操作系统实际是包含入这个Service Layer里面去的，网络通信服务（CAN总线，LIN总线，以太网），管理服务，内存服务

非易失性存储器保证数据的一致性，如何进行写入，读取都是包含在内存服务里面。诊断服务（包括UDS诊断、错误的记录、

故障读取）、ECUM（管理ECU的状态）、逻辑和时序监控的服务（内部看门狗和外部看门狗）。

应用层可以通过对Service Layer的调用，实现这些服务。

 

5 BSW简介

Handler ：控制一个或者多个客户端对驱动程序的并发访问函数，异步访问函数。