【小猫爪】AUTOSAR学习笔记01-AUTOSAR架构简介

• 前言
• 1 背景介绍
• 2 基本概念
• 3 方法论
• 4 分层软件架构
• • 4.1 Application Layer（APP）
  • 4.2 Basic Software（BSW）
  • 4.3 Runtime Environment（RTE）
  • 5 BSW模块简介
  • • 5.1 Microcontroller Abstraction Layer
    • 5.2 ECU Abstraction Layer
    • 5.3 Services Layer
    • 5.4 Complex Drivers
    • 6 功能安全
    • END

      前言

        这一章来看看AUTOSAR的简介，来大略了解一下AUTOSAR，它究竟是一个什么东西啊。

      1 背景介绍

        首先来说说AUTOSAR这个玩意诞生的背景，相信有很多懂行的朋友都看到过下面的一段话：

      

        这确实是AUTOSAR诞生的主要原因，但是我觉得这其中还有一条非常重要的原因，就是那些车厂大牛想搞钱，搞门槛，都是资本的力量，你懂的。

        一开始几个车厂大牛在一起商量，想要迫切的去搞钱，哦不对，想要迫切的去解决当时汽车复杂的电子系统所面临的问题，于是就成立了AUTOSAR联盟，率先提出了AUTOSAR，迫于形势，后面慢慢的其他车厂，汽车电子供应商，研发商等待汽车电子市场周边都陆陆续续加入进来了，AUTOSAR飞速发展，从2003年联盟成立，到2008年AUTOSAR3.0发布，短短5年，一个属于AUTOSAR的时代正在逐渐头角峥嵘。直到如今的2023年，AUTOSAR已然变成庞然大物，吃相难看啊。

      

      2 基本概念

        AUTOSAR的提出就是为了解决上述问题，那么AUTOSAR到底是一个什么样的存在呢？AUTOSAR是automotive open system architecture的简称，粗略的翻译一下就是汽车开放式系统架构，但是作为一名嵌入式软件工程师，我觉得这玩意其实就是一个软件架构，它给你一个很大很大的软件架构然后再把一些细节全部给你定义好（细到什么程度呢，细到连函数名称都给你定义好了，就离谱），告诉你这个软件应该这么设计，应该这么写。所以对于基于AUTOSAR的软件研发一般都是第三方软件供应商会根据AUTOSAR架构把基础软件全部写好了，并且提供一系列代码配置工具，然后车厂或者Tier1直接把这一套软件买过来，根据自己的需求在工具上点一点，配一配，然后一键生成代码，这样基础软件就搞定了，然后再在matlab上完成应用层软件的开发，然后再对接起来。这样的话省事是省事，快也是真的快，但是只能说这其实就是一个“巨婴”养成计划，本人有幸做过一段时间的FAE，发现现在很多工程师被妥妥的养猪了，哎，一言难尽。

        经过处理器和汽车电子的飞速发展，AUTOSAR也在飞速的适应着时代，现在根据不同的应用场景分裂出了两种SAR，分别是Classic Platform（CP）和Adaptive Platform（AP），在这里我只能简单的说一下，CP一般用在MCU上，而AP一般用在MPU上。想搞懂这两者的具体区别的朋友可以参考这篇文章：《【AutoSAR】 CP 和 AP》。接下来的所有关于AutoSAR的介绍都是基于CP的，我这里就简称AUTOSAR了。

        CP AUTOSAR针对的的一般汽车ECU应用场景如下：

      

        CP AUTOSAR针对这一类的应用场景，指定了非常丰富且完整的软件分层结构来实现。这些后面会详细细说。

      3 方法论

        AUTOSAR还有另外一个不得不说的玩意叫做AUTOSAR的方法论，这个玩意是什么呢？Vector的培训材料里亲切的将其称为菜谱，花里胡哨的。其实这玩意说白了就是开发说明书，它就是想告诉你，要想把基于AUTOSAR完成一个项目，你就得先学这个，然后做那个，再搞这个，有着一套标准流程，等你安装它定义的标准流程把所有的东西都搞定了，最后，啪，一整合，妈的，一大堆bug，然后再去找bug，解决掉bug还有掩藏的bug，几次循环后最后就能基于AUTOSAR把这个项目给做好了，so easy。

        其中贯穿整个AUTOSAR开发流程有一个非常重要的文件叫做ARXML文件，它是开发过程中的输入输出文件，打个比方，当你需要完成一个功能的时候，你必须要先使用配置工具根据功能需求生成ARXML，然后就可以通过这个ARXML文件再生成代码，这样的话，开发者只需要将注意力放在系统应用上的设计，而不去过多去关心底层软件的实现。

        对于方法伦的具体介绍，我这里就不多作介绍了，我只能说方法伦的理论对于我们这种软件开发来说，并没有什么大用，我们只需要知道怎么开发就行了，感兴趣的朋友可参考这篇文章自行学习：《详解AUTOSAR：AUTOSAR方法论》。

      4 分层软件架构

        接下来来看看AutoSAR的最关键部分，分层软件架构，前面提到了如果基于AutoSAR做项目，会涉及到软件拼接，这就意味着一个项目的软件代码是两家甚至是三家的，为了顺利得让代码拼接成功，那么AutoSAR要求整个软件有着严格得分层。AutoSAR分层软件架构如下：

      

        显而易见，AutoSAR软件架构自上而下分成了APP， RTE, BSW三层，至于那个Microcontroller指的是芯片MCU硬件，不属于软件。

      4.1 Application Layer（APP）

        这一个层就是大家常说的APP了，属于控制策略层，实现算法。这一部分的开发，都是在Matlab中去实现的，里面牵扯到一些SWC， Ports，Runnables等一些概念，在这里我也不多说了，毕竟我在这里不是专业，感兴趣的朋友可以自行百度谷歌，网上一大堆说明资料。

      4.2 Basic Software（BSW）

        这一层叫做基础软件层，它最大的功能就是隔绝APP和控制器的关系，并且为APP提供一系列服务。是整个软件架构中占比最大的一部分，大部分代码都是通过工具链配置生成的，只有一些特殊的一小部分需要自行实现，这一部分被称为Complex Driver，后面会细说。

      4.3 Runtime Environment（RTE）

        这一层就是起到承上启下的作用，作为一个接口无缝连接APP和RTE，并且还要为APP层SWC之间提供通信。RTE层的代码都是通过工具链配置生成的。

      5 BSW模块简介

        作为一个嵌入式软件工程师，估计打交道最多的就是BSW层了，这一层和MCU息息相关，并且还包含了大量的一些知名协议栈，比方说什么UDS，XCP，TCP/IP等等，总之，学好BSW，工作不愁。下图显示BSW的组成部分：

      

        可以看到BSW分成了Services Layer，ECU Abstraction Layer, Microcontroller Abstraction Layer和Complex Drivers四个部分。

      5.1 Microcontroller Abstraction Layer

        MCU抽象层，它位于BSW的最底层，这一层其实就是我们经常说的MCAL层，这一层的作用就是将MCU资源抽象化，让上层程序的开发与MCU无关。举个例子，上层程序想通过CAN发个消息，只需要调用MCAL的消息发送接口Can_Write即可将消息成功发送出去，而不需要考虑它是通过中断还是轮询的方式发送。其实说白了MCAL就是MCU原厂针对AOTUSAR软件架构要求定制的一套底层MCU驱动，可以理解成为是AOTUSAR里面的MCU SDK驱动包。MCAL都是由MCU原厂提供源码，EB提供配置工具。

        早些年，MCAL都是要收费的，因为当时MCU原厂对一款MCU不仅要提供免费版的常规SDK包，还要提供收费版的AOTUSAR MCAL包，但是随着AOTUSAR的普遍应用，现在的MCAL基本上都是免费了。在这里不得不提一下NXP的做法，NXP为了省事，它将MCAL和常规SDK包融合了一起，而融合的方法就是在SDK包的基础上根据AOTUSAR的接口要求又封装了一层，强行AOTUSAR化，NXP将这种特殊的MCAL包称为RTD。

      5.2 ECU Abstraction Layer

        ECU抽象层，它位于MCAL的上层，这一层的作用是让ECU的硬件设计抽象化，让上层程序的开发与ECU硬件设计无关。举个例子，上层程序需要通过ADC获取电源输入电压，它根本不需要考虑什么电阻分压转换什么，因为将ADC的寄存器值转化成真实的电源输入电压，这一部分的工作已经由ECU抽象层完成。经过ECU抽象层，让上层程序基本上脱离了硬件。

      5.3 Services Layer

        服务层，它位于ECU抽象层的上面，上面提到了经过了ECU抽象层，已经大致让上层软件大致脱离了硬件，所以服务层更多的则是纯纯的软件，为APP提供相关服务和OS调度，比方说常见的UDS诊断，XCP，网络管理，通信服务等等都属于服务层。

      5.4 Complex Drivers

        复杂驱动，也就是经常所说的CDD，这一部分比较特殊，它自成一派，毕竟AOTUSAR不是万能的，它定义的那些标准模块不可能满足所有的应用需求，所以就有了复杂驱动，它是为了实现一些特殊的传感器和执行器功能，还有一些对控制时序有特殊要求功能需求场合，比方说喷油控制，胎压监测等。

        在一个ECU中，通常会有几大常见功能，比如存储功能，信息安全，通信功能等待，而AUTOSAR不同的层又根据功能划分了很多功能模块，如下图所示。看名字其实就大概猜到了每一个功能模块负责什么，在这里就不多做介绍了，因为后面会详细说明，等不及的朋友的朋友可自行提前百度。

      

        对于每一个功能模块，又细分成了很多个软件模块，如下图所示：

      

        BSW层是整个AUTOSAR的重点，后续会一个一个得慢慢学习。

      6 功能安全

        现在不管是做啥，有个词根本就绕不开，那就是功能安全。比方要是去做个母猪喂食器的项目，就说我们这个项目必须上功能安全哦，瞬间高大上了有没有，嘿嘿，懂得都懂。

        当然Autosar也为了功能安全在里面设计了很多机制和库函数，当然了，肯定都是软件层面上面的安全策略。大致可从下面几个方面来看：

      1. Memory Partitioning：

        这个非常好理解，站在APP层说，就是让不同的SWC有不同运行权限，比方说可以配置SWC1只能进行运算，而SWC2可以访问寄存器资源。站在底层来说其实就是对MCU的Memory进行分区管理，即为MPU的应用，对MPU不了解的朋友们可参考的我的MPU详解文章。

      2. E2E Protection

        End-to-End保护，这个也非常好理解，不管是外部不同ECU之间的通信，还是内部不同SWC之间的通信，都需要为保证信息在传输过程中的正确性，而AOTUSAR软件则提供了三种的E2E保护措施，分别是CRC校验，Sequence Counter，Timeout。CRC校验大家都懂，Sequence Counter就是给信息编号，防止漏和多，Timeout就是设置超时，给信息一个时限，这世界哪有一万年的爱啊。

      3. Timing Monitoring和Logic Supervison

        这个方面主要是为了解决在系统运行过程中出现任务阻塞，任务死锁，活锁，任务执行时间超限等情况。主要安全策略差不多有两种，一个其实就是看门狗，AOTUSAR有个模块叫做Wdog Manger，可以监控某个任务有没有被卡死啊，卡死就报告，还有就是OS提供函数可以计算某段代码执行的时间有没有超限。

        另外在AUTOSAR的架构中，功能安全的实现方式有Partitioning和High Performance Integrity两种，这两种的最大的区别其实就是BSW层是QM，还是ASIL。功能安全是一门大学问，在这里就不多介绍了，感兴趣的朋友自行学习。

      

      END

        以上的内容全部参考AutoSAR官方文档《AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf》，大家可自行去官网下载。里面有很多很多的内容，基本上把AutoSAR的一些基础知识都介绍了一遍，大家一定要仔细看。