AUTOSAR简介与开发流程

AUTOSAR简介与开发流程

1. 背景

AUTOSAR的建立初衷是为了解决当前汽车电子电气架构复杂多样性，统一汽车电子电气架构标准。因为软件在汽车中的作用越来越重要，与此同时汽车的功能越来越复杂。汽车渐渐地不再只是一个运输载人工具，而是集生活娱乐、舒适与安全并行、高科技涌现的智能设备。传统的电子电气开发流程存在如下的缺陷：1.软件重用性极差；2.硬件平台各式各样，难以统一、重用；3.软件模块化极其有限；4.嵌入式系统不支持硬件抽象。

因为传统电子电气开发模式的缺陷，新项目很难重用以前的项目，几乎每一个新项目都是从头开始（从硬件开始重新设计、软件重新编写底层驱动程序和应用程序）。这种模式的开发时间需要至少2~3年时间。而汽车更新换代越来越频繁，几乎每年需要更新换代。AUTOSAR因此成立。

基于这样的背景，由汽车主机厂、零部件供应商、半导体厂商、软件服务商、工具提供商以及其他相关的厂商联合成立了AUTOSAR组织。AUTOSAR的出现，将带来如下主要优势：

①有利于提高软件复用度，尤其是跨平台的复用度；

②便于软件的交换与更新；

③软件功能可以进行先期架构级别的定义和验证，从而能减少开发错误；

④减少手工代码量，减轻测试验证负担，提高软件质量；

⑤使用一种标准化的数据交换格式，方便各公司之间的合作交流等。

早期AUTOSAR联盟成员

AUTOSAR官网将AUTOSAR的发展分成了5大阶段：AUTOSAR成立：Initialization（2002-2003），第一阶段：Phase 1（2003-2006），第二阶段：Phase 2（2007-2009）,第三阶段：Phase 3(2010-2012), 2013年开始不断更新完善：AUTOSAR continuous further development(since 2013)，2017年新的AUTOSAR自适应平台成立：AUTOSAR Adaptive Platform（since 2017）。

AUTOSAR发展史

目前，AUTOSAR平台最新版为4.4.0。为了迎合未来汽车智能化、网联化的需求，AUTOSAR联盟推出了一个全新的平台—自适应AUTOSAR平台（AUTOSAR Adaptive Platform，AP），并将现有平台更名为经典AUTOSAR平台（AUTOSAR Classic Platform，CP），我们使用的工具链为CP平台。

1. AUTOSAR的分层架构

AUTOSAR规范主要包括分层架构、方法论和应用接口三部分内 容。其中，分层架构是实现软硬件分离的关键，它使汽车嵌入式系统控 制软件开发者摆脱了以往ECU软件开发与验证时对硬件系统的依赖。

AUTOSAR软件架构

在AUTOSAR的架构中，大体可以分为应用层（App）、实时运行环境(RTE)、基础软件和微控制器（Microcontroller）。其中：

1. 应用层实现控制逻辑；
2. RTE作为应用层与基础软件的“中间人”，提供通信接口；
3. 基础软件主要由半导体厂商撰写的静态代码和AUTOSAR基础软件厂商提供的配置工具产生的动态代码组成；
4. 微控制器即主控MCU及外围芯片。

1. 基础软件概述

AUTOSAR架构下，应用层软件与基础软件是最核心的两部分，前面说过应用层软件主要实现控制逻辑，一般采用图形化编程（simulink/stateflow），相信这部分对于大家来说都是不陌生的。那么基础软件主要做些什么工作呢？

基础软件层

基础软件可以分为服务层、ECU抽象层、微控制器抽象层和复杂驱动。其中：

1. 服务层提供了汽车嵌入式系统软件常用的一些服务，其可分为系统服务、存储器服务以及通信服务三大部分。提供包括网络通信管理、存储管理、ECU模式管理和实时操作系统等服务。除了操作系统外，服务层的软件模块都是与ECU平台无关的。
2. ECU抽象层包括板载设备抽象存储器硬件抽象、通信硬件抽象和I/O硬件抽象。该层将ECU结构进行了抽象，负责提供统一的访问接口，实现对通信、存储器或者I/O的访问，从而不需要考虑这些资源是由微控制器片内提供的，还是由微控制器片外设 备提供的。该层与ECU平台相关，但与微控制器无关，这种无关性正是由微控制器抽象层来实现的。
3. 微控制器抽象层是实现不同硬件接口统一化的特殊层。通过微控制器抽象层可将硬件封装起来，避免上层软件直接对微控制器的寄存器进行操作。微控制器抽象层包括微控制器、存储器驱动、通信驱动以及I/O驱动。

以CAN信号发送为例，讲解一下AUTOSAR架构是怎么实现自上到下的数据传递或者接口调用的：首先服务层给RTE一个通信接口COM模块的通信接口，将数据打包成PDU并转发；PDUR根据全局PDU识别这个数据包协议类型，路由到CANIF；CANIF是CAN通信在ECU抽象层的CAN模块，CANIF紧接着把数据传输到CAN驱动，CAN driver解析这个数据包，根据CAN driver定义的邮箱，发送这个数据，CAN driver外接CAN transiver，通过CAN_low和CAN_high两条线束将CAN信号发出去。

1. 复杂驱动

在AUTOSAR软件架构可以看到，复杂驱动“横穿”整个基础软件，直接与RTE作交互，接下来我尽可能详细的解释一下什么是复杂驱动和为什么需要复杂驱动。

之前我们已经讲过CAN通信在AUTOSAR的实现，对于微控制器要实现的功能或者接口，绝大多数都能像CAN通信那样由AUTOSAR定义的架构自上而下或者自下而上的实现，这里用到绝大多数，那么自然存在不经过这个架构实现的一些接口或功能，这些接口或功能主要分为两类：一类是AUTOSAR架构之外的组件，但是微控制器又具备的，比如uart通信，这个在微控制器还算是比较常见的，但是AUTOSAR并没有这个组件的抽象，因此需要用到uart协议的话，就需要自己写复杂驱动；第二类是AUTOSAR架构不满足现有需求的时候，需要用到复杂驱动，比如电机的三相同步PWM控制，PWM周期要求在20us以内，经过AUTOSAR架构来执行PWM输出，无法达到20us这样的时间精度，因此需要通过复杂驱动来实现。

基础软件详细介绍需要自行了解各个模块的作用与机制，这里作为概述就不展开讲每一个模块，同时基础软件的调试与接口功能实现需要一定的C语言基础。

1. AUTOSAR开发流程

说到AUTOSAR的开发流程，不可避免的要引入嵌入式的一种开发方法-MBD（基于模型开发）。在进行基于AUTOSAR的项目开发时，一般都会使用MBD，但是MBD不一定是AUTOSAR，mathworks为提供了底层软件接口封装的方法，为MBD提供了基础的方法论，用户可以根据需求将底层接口封装到simulink，使得应用软件跟底层软件实现交互，但是这样的软件架构如果没有使用AUTOSAR定义的架构（服务，ECU抽象，MCAL等），是不能称之为AUTOSAR的开发的。

也就是说，AUTOSAR的开发流程，它是基于MBD和AUTOSAR联盟定义的架构的。以我们这一版软硬件来说：

应用层采用simulink/stateflow进行建模；

应用层与基础软件数据交互采用接口封装的形式，实现数据和接口的交互；

基础软件静态代码部分由英飞凌撰写提供；

基础软件动态代码部分由普华基础软件上位机产生；

上述这些资源整合起来，形成我们的软件。