搞一下CP AUTOSAR 入门 | 01 CP AUTOSAR Overview

前言

在汽车电子开发领域，如果你是一名软件开发工程师，你肯定知道AUTOSAR，最近十几年的时间最火的汽车电子软件开放架构标准，从2003年左右最早的AUTOSAR标准（一开始没有AP的概念，AP的概念最早是在17年正式出现的）诞生到今天已经更新到了R20-11版本了，无论是国内做AUTOSAR工具的服务商还是国外的都在不断更新自己的方案。相信网上也有很多文章来介绍CP AUTOSAR，这里进行一个简单的梳理。
 

本系列希望结合本人对CP AUTOSAR的一些见解和在AUTOSAR使用的经验，和大家一起交流探讨，一起进步，一起做好汽车电子软件。
 

全系内容可在《搞一下汽车电子》后台回复 "系列"，或进入菜单栏 "下载分享" --> "系列"

一、What (CP) AUTOSAR？

汽车电子开发不像其他产品的开发，有着自己一套严格的规范和流程，在汽车行业主要是V模型，它定义了汽车电子产品开发一套从需求到软硬件设计开发到最终测试交付的完整体系。

AUTOSAR的全称是：AUTOmotive Open System ARchitecture中文名称：汽车开放系统架构
 

AUTOSAR是主流汽车OEM和主流供应商、芯片企业等制定的一套软硬件可以分离复用、应用算法与底层驱动分离、下层的芯片企业与上层OEM或者ECU供应商基于同样的规范独立并行开发的软件开发体系。
 

AUTOSAR的标准严格遵循了V模型的软件开发流程，在AUTOSAR标准中定义了从软件需求（通用全面的需求）到架构设计完整体系，根据AUTOSAR规范就可以开发满足这些规范的代码程序。
 

下图展示了CP AUTOSAR的思想和方法论，在实现软硬件隔离同时，制定统一、标准的软件开发架构规范，实现汽车电子软件标准的协同，在功能实现层面各个OEM、供应商的竞争。

二、CP AUTOSAR整体架构概述

AUTOSAR作为一种汽车开放架构，对于汽车电子软件开发在架构设计上做了很好的分层处理，对于熟悉CP AUTOSAR规范的人而言，下图基本涵盖了CP AUTOSAR整体架构的分层思想。

 

 

在CP AUTOSAR架构（软件）里，主要分为三层： Application Layer、AUTOSAR Runtime Environment (RTE)、Basic Software (BSW)

1、APP 层

在CP AUTOSAR中APP层主要是实现特定ECU功能的逻辑算法，这一层也是CP AUTOSAR架构里定义的各个OEM和供应商在实现上存在竞争一层。
一般在APP层会设计出ECU中各个软件单元模块的上层应用架构，而这部分架构并不是一个统一的CP AUTOSAR架构，OEM和供应商可以根据自己的应用层逻辑去设计自己上层应用的需要的SWC数目、各个SWC模块之间的数据流和控制流。而在CP AUTOSAR架构中，各个APP的调度、数据交互等通过RTE实现。

2、RTE层

RTE提供基础的通信服务，支持SWC之间（Interface2与Interface3）和 SWC到BSW的通信（Interface1，包括ECU内部的程序调用、 ECU外部的总线通信等情况）。
RTE同时实现对APP层SWC的函数调度。RTE使应用层的软件架构完全脱离于具体的单个ECU和BSW。

 

3、BSW层

BSW层是整个CP AUTOSAR的核心，内部按照架构上的分层而言主要分为微控制器抽象、复杂驱动层、ECU抽象层、服务层四大部分。
 

微控制器抽象层(Microcontroller AbstractionLayer)是在BSW的最底层，它包含了访问微控制器的驱动。微控制器抽象层使上层软件与微控制器相分离，以便应用的移植。
复杂驱动（Complex Drivers）可以实现应用层通过RTE直接访问硬件。也可以利用复杂驱动封装已有的非分层的软件，以实现向CP AUTOSAR 软件架构逐步实施。
 

ECU抽象层封装了微控制器层以及外围设备的驱动。将微控制器内外设的访问进行了统一，使上层软件应用与ECU硬件相剥离。主要包括Onboard Device Abstraction、Memory Hardware Abstraction、Communication Hardware Abstraction。    
 

服务层（Service Layer）位于BSW的最上面，将各种基础软件功能以服务的形式封装起来，供应用层调用。服务层包括了RTOS、通信与网络管理、内存管理、诊断服务、状态 管理、程序监控等服务。
 

BSW层从上到下可以实现一个完整的协议栈功能，按照具体的实现服务功能分可以分为系Onboard Device、Memory、Communication三大服务功能以及复杂驱动。下面分别简单介绍Onboard Device、Memory、Communication三大协议栈服务功能。

Onboard Device服务功能

Onboard Device功能主要是对ECU的非传感器和执行器的进行操作，直接去调用MCAL中的微控制Driver进行操作，最常见的就是对Watchdog的操作。
 

在使用WDGM服务层的接口去进行喂狗操作，监控MCU是否正常运行。常见的控制如下，WDGM接收到周期的定时触发喂狗函数，去调用IF层的接口，如果操作内狗，直接调用MCAL的WDG Driver进行喂狗操作，如果IF层被WDGM层所调用的是外狗的操作函数，直接去操作CDD的特定的外部SBC芯片驱动代码，调用MCAL与外部SBC芯片的通信接口（如SPI）进行外部SBC喂狗操作。

Memory服务功能

在CP AUTOSAR中关于对Memory的操作主要包括两大类，分别是MCU内部的DFLASH和外部的EEPROM芯片。NVM模块会定义操作NVM的服务函数，IF层实现对外部和内部存储的路由划分。
 

对于操作外部EEPROM的，一般包括EA和EEP，EA是抽象，EEP是外部EEPROM的驱动模块，通过EA调用EEP驱动，然后调用外部EEPROM与MCU通信协议接口（如SPI）实现对外部EEPROM的操作。
 

对于内部数据存储操作，在IF层直接调用抽象层的FEE模块，FEE会调用MCAL的FLASH进行DFLASH的操作。

Communication服务功能

CP AUTOSAR 中基本的最常用的车载网络通信进行了架构设计和分层定义。主要包含MCAL的驱动、TRCV层的封装、IF层的节点路由分配、PDU层的路由分配、特殊的通信协议、通信的状态管理、网络管理模块的集成封装、信号的解析与封装、整个通信的服务管理以及与RTE上层模块的交互。
 

下图展示了整个通信的分层架构关系，其中标记为橘黄色箭头连线的数据传递主要是模式和状态的控制，黑色的箭头连线主要为通信数据的数据流。

 

以CAN为例，在IF层会根据使用的TRCV不同选择不同的TRCV控制模块，路由CAN的节点模块，而PDUR层主要对某个CAN节点的PDU进行路由，根据该CAN节点的功能进行PDU的分配（PDU为XCP的走XCP模块；PDU为NM的走CANNM模块；PDU为TP的走CANTP模块；J1939的PDU为J1939模块，普通的直接传输到COM等）。
CANSM会对整个CAN的状态进行管理，然后根据CANNM以及COMM的相关请求和状态去控制CANIF进而控制TRCV的状态，从而实现对CAN通信的管理。

如何开发集成CP AUTOSAR工程

在正向的CP AUTOSAR开发过程中，一般会从OEM获得必须的系统描述文件和通信、诊断矩阵文件以及OEM定义好的APP层的一些借口文件，然后将这些文件导入到CP AUTOSAR工具链中（比如Vector的Davinci系统、AB的AUBIST等），同时供应商自己在架构设计工具中创建的SWC等.xml文件也导入到CP AUTOSAR工具开发链中。
 

在CP AUTOSAR的工具链中根据需要完成BSW、RTE、APP层的设计和实现，然后基于工具的代码生成器生成对应的.h和.c代码，对于RTE和BSW的代码是可以直接集成的，但是对于APP层，只能生成对应的模块代码模板，主要包括了调度函数以及APP的交互接口等。
 

内部的代码逻辑需要自己手动添加，也可以在CP AUTOSAR工具链中做好的APP层的SWC的描述文件.xml（一般包括了SWC之间的接口、全局变量、调度函数等）导入到MBD工具中进行建模生成代码，最后将所有的BSW、RTE、APP生成的代码，以及购买工具自带的静态代码一起集成到工程中进行编译调式。

 

以上就是本人对CP AUTOSAR简单的理解，欢迎大家一起交流学习，如果有不合理的地方也请大家指正，愿和大家一起学习进步，一步步做好汽车电子软件开发。后期将会对CP AUTOSAR各个层级、各个模块进行介绍，欢迎大家关注。

作者：搞一下汽车电子
文章来源：上汽零束SOA开发者论坛 
原文链接：https://bbs.z-onesoft.com/omp/community/front/api/page/mainTz?articleId=7539