【小猫爪】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的一些基础知识都介绍了一遍,大家一定要仔细看。