分享

AUTOSAR架构的故事(干货)

 西北望msm66g9f 2020-08-29
1
AUTOSAR架构概览

之前文章《老板说项目要上AUTOSAR,我慌得一批》讲过,在新世纪,汽车产业蓬勃发展,欧洲大陆的车企们,瞄准了这是一块大蛋糕,于是在2002年成立了一个联盟,搞了个叫AUTOSAR的标准,以期一统天下。次年,他们就开搞了,开始制作这个AUTOSAR的草图。

话说,这是要定义一套标准,一个统一的架构,那这架构有什么内容呢?

一位工程师,将其想法用草图表达了出来

并解释说,这个架构大概分三层,然后看看在座的各位。会议上的其他人面面相觑,都想说,这么简陋,能统一江湖?这位工程师也不理会,不慌不忙,继续画下去:

工程师解释说,关键在这个BSW,还可以分个三四层:

  • Service Layer:这个是BSW的最高层,是给Application访问由Abstraction Layer覆盖的IO信号等。

  • ECU Abstraction Layer:这个是给底层驱动提供抽象接口的。

  • Microcontroler Abstraction Layer:这个是基础软件的最底层,它包含有μC的驱动以及外围的设备驱动等。

还有,Application就是应用,跟其他架构写的应用类似,就不用多说了。而这个Runtime Environment(RTE)呢?

RTE是给应用提供通信服务的,Applcation通过它可以访问BSW的功能,做统一标准的接口,从而实现非常方便的可移植性了,各模块也独立了。

工程师言简意赅,没有做更多的解释,然后就想细化这个架构图:

然后,他微微笑了下:这应该清晰了吧,横着看竖着看都很好理解。比如说这个Memory Service,就可以让Application通过RTE调用,做了很多方法application访问的接口,它是通过调用Memory Hardware Abstraction来访问Memory Drivers的。

通过这三层关系就实现市面上大部分功能需求了。但是,总会有这几层实现不了的功能吧,怎么办?Complex Drivers就可以提供给用户自己定义啦,可以做一些复杂的驱动。

总的来说,基础软件(BSW)可以按以下类型分:

  • Input/Output (I/O)

    标准化访问sensors, actuators以及板上的外围器件。

  • Memory

    标准化访问内部或外部的Memory(NVM)。

  • Crypto

    标准化访问密码原语,包括内部/外部硬件加速器

  • Communication

    标准化访问车辆网络系统,ECU车载通信系统和ECU内部软件

  • Off-board Communication

    标准化访问车辆到X的通信,车辆无线网络系统中,ECU车外通信系统

  • System

    提供标准化的(操作系统,计时器,错误存储器)和特定于ECU的(ECU状态管理,看门狗管理器)服务和库功能

等等,还有个东西差点漏了——Library

这个Library实际上是很多functions的集合,它可以:
  • 由BSW模块(包括RTE),SW-C,库或集成代码调用

  • 在同一保护环境中在调用方上下文中运行

  • 只能调用库

  • 可重入的

  • 没有内部状态

  • 不需要任何初始化

  • 是同步的,即它们没有等待点

2
AUTOSAR的基础软件

基础软件,即BSW。工程师打算详细讲解下这个BSW,因为它非常重要。
话说,座上的与会大咖听这位工程师讲的津津有味,越来越觉得AUTOSAR一统江湖指日可待,并期望能讨论更多细节。
工程师也准备好了设计原稿,对这些细节娓娓道来。
MCAL
从底下往上讲,第一个Microcontroler Abstraction Layer(即MCAL),其有以下模块:
  • Microcontroller Drivers

    具有直接µC访问权限的内部外围设备(例如看门狗,通用定时器)驱动程序(例如核心测试)

  • Communication Drivers

    车载ECU(例如SPI)和车辆通信(例如CAN)的驱动程序。OSI层:数据链路层的一部分。

  • Memory Drivers

    片上存储设备(例如内部闪存,内部EEPROM)和存储器映射的外部存储设备(例如外部闪存)的驱动程序。

  • I/O Drivers

    用于模拟和数字I / O的驱动器(例如ADC,PWM,DIO)。

  • Crypto Drivers

    用于SHE或HSM等片上加密设备的驱动程序。

  • Wireless Communication Drivers

    用于无线网络系统的驱动程序(车载或车外通信)。

举例说明,SPIHandlerDriver是允许多业务并发访问,为了抽象出SPI的所有功能,这些已经用为SPI功能的IO是不能做他用的。

CDD

CDD即Complex Driver,上文也提到了,它是用来实现BSW里面非标准化功能的。也就是说,标准化定义以外的功能可以通过CDD来实现,如UART,MCAL是没有定义UART的标准化的。

(这个话题,后续再详细讲解。)

I/O Hardware Abstraction

I/O Hardware Abstraction是一组模块,从外围I/O设备(片上或板上)的位置和ECU硬件布局(例如µC引脚连接和信号电平反转)中抽象出来。I/O硬件抽象不会从传感器/执行器中抽象出来!可以通过I /O信号接口访问不同的I/O设备。

Communication Hardware Abstraction

Communication Hardware Abstraction是一组模块,从通信控制器的位置和ECU硬件布局中抽象出来。对于所有通信系统,都需要特定的通信硬件抽象(例如,对于LIN,CAN,FlexRay)。

例如,ECU具有带2个内部CAN通道的微控制器和带4个CAN控制器的附加板载ASIC。CAN-ASIC通过SPI连接到微控制器。

可通过总线特定的接口(例如CAN接口)访问通信驱动程序。

Memory Hardware Abstraction 

Memory Hardware Abstraction 是一组模块,从外围存储设备(片上或板载)的位置和ECU硬件布局中抽象出来。

例如,可以通过相同的机制访问片上EEPROM和外部EEPROM器件。可以通过特定于存储器的抽象/仿真模块(例如EEPROM抽象)访问存储器驱动程序。通过在闪存硬件单元顶部模拟EEPROM抽象,可以通过存储器抽象接口对两种类型的硬件进行通用访问。

Onboard Device Abstraction

Onboard Device Abstraction 包含用于ECU板载设备的驱动程序,不能将其视为传感器或执行器,例如内部或外部看门狗。这些驱动程序通过µC抽象层访问ECU车载设备。

Crypto Hardware Abstraction

Crypto Hardware Abstraction是从加密基元(内部或外部硬件或基于软件)的位置抽象的一组模块。例如,AES原语在SHE中实现或作为软件库提供。

Crypto Services

Crypto Services包含两个模块:

  1. 加密服务管理器负责加密作业的管理

  2. 密钥管理器与密钥预配置主机(在NVM或加密驱动程序中)进行交互,并管理证书链的存储和验证

Communication Services
Communication Services是一组用于车辆网络通信(CAN,LIN,FlexRay和以太网)的模块。它们通过通信硬件抽象与通信驱动程序接口。

讲到这里,会上的其他人听着听着有些懵逼,越讲越复杂了,工程师停了下,说,通信服务这部分,涉及到CAN、LIN甚至TCP/IP等,内容很多也很重要,后续我们另外召开会议讨论吧。

Memory Services

Memory Services由一个模块NVRAM管理器组成。它负责非易失性数据的管理(从不同的内存驱动器读取/写入)。

它以统一的方式向应用程序提供非易失性数据。内存位置和属性的摘要。提供非易失性数据管理机制,例如保存,加载,校验和保护和验证,可靠的存储等。

System Services

System Services是一组模块和功能,可由所有层的模块使用。示例包括实时操作系统(包括计时器服务)和错误管理器。

其中一些服务是:

  • 取决于µC(例如OS),并且可能支持特殊的µC功能(例如Time Service),

  • 部分依赖ECU硬件和应用程序(例如ECUM Management)或

  • 硬件和µC独立。

它提供基本的申请服务以及基本软件模块。

有专门的模块可用于AUTOSAR中错误处理的不同方面, 例如:

  • 诊断事件管理器负责处理和存储诊断事件(错误)和相关的FreezeFrame数据。

  • 诊断日志和跟踪模块支持对应用程序进行日志记录和跟踪。它收集用户定义的日志消息并将其转换为标准化格式

  • 基本软件中检测到的所有开发错误都报告给默认错误跟踪程序。

  • Diagnostic Communication Manager提供了用于诊断服务的通用API

  • 其他的,等等

3
AUTOSAR的多核处理
此刻,有人提问,市面上μC更新换代非常快,性能也不断提升,甚至有多核处理器,这个架构如何应对多核处理?
工程师想了想,show出了下图

并结合下图给出解释:

  • BSW模块可以分布在多个分区和核心中。所有分区共享相同的代码。

  • 每个分区上的模块可以完全相同,如图中I/O堆栈中的DIO驱动程序所示。

  • 作为替代,他们可以使用依赖于核心的分支来实现不同的行为。Com服务和PWM驱动程序使用卫星主机通信来处理从相应卫星到主机的呼叫。

  • 主站与卫星之间的通信不规范。例如,它可以基于BSW调度程序提供的功能,也可以基于共享内存。

  • 箭头指示服务调用的处理涉及哪些组件,这取决于分发方法和调用的来源。

  • 每个运行BSW模块的分区中的基本软件模式管理器(BswM)

  • 所有这些分区都是受信任的

  • 每个内核一个EcuM(每个在一个受信任的分区中)

  • 通过引导加载程序启动的那个核心上的EcuM是主EcuM

  • 主EcuM启动所有卫星EcuM

  • 如图所示,IOC提供了通讯服务,这些客户端可以访问需要跨同一ECU上OS-Application边界进行通讯的客户端。IOC是操作系统的一部分。

  • BSW模块可以在多个内核上执行,例如图中的ComM。在运行时确定负责执行服务的核心。

  • 每个核心都运行一种ECU状态管理

4
AUTOSAR的Safety功能
那么,安全功能如何?工程师都有考虑和准备:

AUTOSAR提供了一种灵活的方法来支持与安全相关的ECU,可以使用两种方法:

  1. 所有BSW模块均根据所需的ASIL开发

  2. 所选模块是根据ASIL开发的,ASIL和非ASIL模块分为不同的分区(BSW分发)

注意:分区基于OSApplications,OS-Application的TRUSTED属性与ASIL/non-ASIL不相关。

使用不同BSW分区的示例,看门狗堆栈放置在自己的分区中

  • ASIL和非ASIL SW-C可以通过RTE访问WdgM

  • BSW的其余部分放在自己的分区中

经过以上的解答和分解,会议上的各位都点头表示同意,但是还是有人提了个问题,我们定义这么多功能模块,不一定所有产品都会用到,如何裁剪?

5
AUTOSAR的ICC
好了,我们接下来讨论ICC(Implementation Conformance Class):

下图显示了基本软件模块到AUTOSAR层的映射

我们称这个为ICC3,那ICC2是怎样的?

这个便是ICC2了。

到目前为止,本文档中显示的集群是该项目定义的集群。 

当前,AUTOSAR并未将ICC2级别上的群集限制为专用群集,因为许多不同的约束和优化标准可能会导致不同的ICC2群集。 可能存在不同的AUTOSAR ICC2集群,可以根据要定义的ICC2遵从性方法声明符合性。

ICC1呢?

在符合ICC1的基本软件中,不需要模块或集群。未指定此专有基本软件的内部结构。

纳尼?又回到原来的三层结构?

兼容AUTOSAR(ICC1-3)的基本软件(包括RTE)必须具有ICC3模块规范指定的外部性能。例如,针对以下行为:

  • 总线

  • 引导加载程序和

  • 应用

另外,关于ICC3中的系统描述,ICC1 / 2配置应兼容。

也是说,这个架构能屈能伸,只需遵循相关标准要求即可,非常灵活。
5
后话
会上响起了经久不绝的掌声,结构做到这份上,也是非常详尽了。但是,问题还是有的,架构中定义了那么多模块,模块之间的接口是如何的?

工程师,想了想,面对座上的期盼的目光,慢悠悠地说,我们下次会议再讨论吧……(因为要下班了,万恶资本主义的欧洲,他们的工程师,不!加!班!!)

注:以上的故事是虚构的,架构知识是真实干货,参考AUTOSAR官网架构文档。

关注公众号号“嵌入式软件实战派”,获得更多关于AUTOSAR相关的内容。

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多