目录
- 1、软件分层内容
- 1.1、Microcontroller Abstraction Layer
- 1.2、ECU Abstraction Layer
- 1.2.1、I/O HW Abstraction
- 1.2.2、Communication Hardware Abstraction
- 1.2.3、Memory Hardware Abstraction
- 1.2.4、Onboard Device Abstraction
- 1.2.5、Crypto Hardware Abstraction
- 1.3、Services Layer
- 1.3.1、System Services
- 1.3.2、Memory Services
- 1.3.3、Communication Services
- 1.3.4、Crypto Services
- 1.4、Complex Drivers
- 2、多核上软件结构
- 2.1、BSW模块的分布
- 2.2、BSW OS BswM EcuM的分布
- 2.3、多核的System Services
- 3、混合的关键性系统架构内容
- 3.1、AUTOSAR safety handling总览
- 3.2、 BSW模块分配
- 4、模块总览
- 4.1、模块总览
1、软件分层内容
在前面 章节(点击跳转)中,我们简要介绍了CP_AUTOSAR分层软件的架构,其主要分为应用层,运行时环境(RTE)以及基础软件层(BSW),软件分层架构如下图所示。而BSW作为连接硬件和上层软件的核心组件,在CP_AUTOSAR架构中起到了桥梁作用,它不仅提供了硬件抽象,还负责资源管理、错误处理、性能优化等关键功能,对于构建稳定、高效、安全的汽车电子系统至关重要,本文将详细介绍BSW模块内容。
1.1、Microcontroller Abstraction Layer
Microcontroller Abstraction Layer,即MCAL在CP_AUTOSAR架构中BSW模块扮演着关键角色,它通过提供对微控制器硬件的抽象访问,极大地简化了上层软件的开发和维护工作,同时确保了软件的性能、稳定性和可移植性。
MCAL一些特性说明:
1、硬件抽象:MCAL屏蔽了不同微控制器之间的硬件差异,向上层软件提供了统一的接口。这意味着上层软件可以使用相同的API来访问诸如GPIO、ADC、定时器等硬件资源,而无需关注这些资源在不同微控制器上的具体实现。
2、初始化和配置:MCAL负责初始化微控制器的硬件资源,如配置寄存器、设置中断等。它提供了配置文件,允许用户根据具体的应用需求来配置硬件资源的初始状态。
3、驱动程序:MCAL包含了针对微控制器特定外设的驱动程序,如CAN、LIN、FlexRay等通信接口的驱动。这些驱动程序遵循AUTOSAR标准,提供了标准化的接口,使得上层软件可以使用一致的方法来访问和控制这些外设。
4、可配置性和可移植性:MCAL的标准化接口和配置机制使得软件具有良好的可配置性和可移植性。软件开发者可以通过调整配置参数,轻松地将软件从一种微控制器移植到另一种微控制器上,而无需对软件代码进行大量修改。
MCAL由如下模块组构成:
1、Microcontroller Drivers
内部外设的驱动程序(如,看门狗,通用计时器);
具有直接访问μC的功能(例如Core测试);
2、Communication Drivers
ECU板间或者与车辆之间的通信驱动(如,SPI/CAN);
OSI层:部分的数据链路层;
3、Memory Drivers
片上内存设备的驱动(如,内部EEPROM和Flash),外部内存设备;
4、I/O Drivers
模拟量和数字量的输入输出的驱动(如,ADC,PWM,DIO);
5、Crypto Drivers
片上加密模块(如,SHE(Security Hardware Extension),HSM(Hardware Security Module)),SHE通常集成在微控制器中,适用于嵌入式系统的安全需求;而HSM作为独立的安全模块,适用于需要更高安全等级和更强大加密性能的场景;
6、Wireless Communication Drivers
无线网络系统的驱动;
MCAL的软件架构如下图所示:
SPIHandlerDriver
以SPIHandlerDriver为例子,SPIHandlerDriver是用于控制和管理SPI(Serial Peripheral Interface)总线通信的驱动程序,可以允许多个客户端去访问SPI总线。
SPIHandlerDriver模块应该完全负责SPI通信中用于芯片选择的专用引脚的控制,而不是把这些引脚作为通用的数字I/O引脚来对待。这是因为Chip Select信号是SPI通信中一个关键的控制信号,用于选择与微控制器通信的具体SPI外设。将这些引脚直接交给SPIHandlerDriver处理,可以确保SPI通信的正确性和效率,避免与其他I/O操作发生冲突或引起不必要的延迟。
因此,在设计和配置AUTOSAR MCAL架构时,应当确保用于Chip Select的SPI引脚仅由SPIHandlerDriver模块控制,而不应该被DIO Driver(数字I/O驱动)所管理,以此来保证SPI通信的专一性和高效性。
比如,下面这个架构案例:
1.2、ECU Abstraction Layer
1.2.1、I/O HW Abstraction
I/O Hardware Abstraction包括了一组软件模块,它们是根据外设所处的位置(片上或者板上),ECU硬件分布(μC引脚连接和信号电平反转)抽象而来。
比如,下面这个架构案例:
1.2.2、Communication Hardware Abstraction
Communication Hardware Abstraction包括了一组软件模块,它们是根据通讯控制器位置,ECU硬件布置抽象而来。每一个通讯系统,都需要抽象出来(如CAN,LIN,FlexRay)。比如,一个ECU的微控制器有2路内部CAN通道,一个带有4个CAN控制器的板上ASIC(Application-Specific Integrated Circuit,为CAN定制的集成电路,通常有更高的性能、更低的功耗和更小的尺寸),CAN-ASIC通过SPI总线连接到总线上。
而访问通讯驱动只能通过总线接口层,如访问CAN驱动,只能通过CAN Interface。
比如,下面这个架构案例:
1.2.3、Memory Hardware Abstraction
Memory Hardware Abstraction包括了一组软件模块,它们是根据外设内存设备的位置(片上或者板上),ECU硬件布置抽象而来。比如,片上和外部的EEPROM都通过同一套机制访问。
内存指定的抽象/模拟模块(如EEPROM抽象)才能去访问内存驱动模块;
比如,下面这个架构案例:
1.2.4、Onboard Device Abstraction
Onboard Device Abstraction包含了那些ECU板上的设备的驱动,而这些设备不能被看作成传感器或者执行器,像内部看门狗或者外部看门狗。这些驱动能够通过MCAL来访问ECU板上的设备。
比如,下面这个架构案例:
1.2.5、Crypto Hardware Abstraction
Onboard Device Abstraction包括了一组软件模块,它们从加密原语(内外部软硬件或者基于软件)中抽象出来。比如,AES(Advanced Encryption Standard,高级加密标准)通过专用的安全硬件模块(SHE)完成的。
比如,下面这个架构案例:
1.3、Services Layer
1.3.1、System Services
System Services包括了一组软件模块,可以被所有层的模块所使用,比如说RTOS。
比如,下面这个架构案例:
1.3.2、Memory Services
Memory Services由一个模块构成,即NVRAM Manager(负责管理非易失性存储)。
比如,下面这个架构案例:
1.3.3、Communication Services
Communication Services是由一组适用于车载网络通信的软件模块(如CAN,LIN,FlexRay 和 Ethernet)构成,它们通过通讯硬件抽象层于驱动层通信。
有如下软件模块组成:
1.3.4、Crypto Services
Crypto Services有3个模块构成:
1、Crypto Service Manager,负责管理加密工作;
2、Key Manager,与提供密钥的一方进行交互,并管理证书链的存储和验证
3、Intrusion Detection System Manager,入侵检测系统管理,负责处理BSW和SWC模块汇报的安全事件;
1.4、Complex Drivers
Complex Drivers,复杂驱动层是用来实施非标准功能的模块,比如说通过中断/复杂的外设(PCP,Performance Computing Platform,高性能计算平台、TPU(Tensor Processing Unit),AI加速器)直接访问μC来实现传感器的估值或者执行器的控制等。
Injection control,发动机喷射控制;
Electric valve control,电磁阀控制;
Incremental Position Detection(增量位置检测),用于测量物体移动距离和位置变化的技术,尤其适用于需要高精度定位的场合,如自动驾驶汽车中的运动控制、转向系统、传动系统等。
比如,下面这个架构案例:
2、多核上软件结构
假设ECU上有2个核,多核微控制器的分层软件架构的案例如下:
2.1、BSW模块的分布
1、BSW模块可以分布在几个core 或者 partition上,所有的partition共享同一份代码;
2、模块可以在每个分区上完全相同,如图中I/O堆栈外的DIO驱动程序所示;
3、作为替代方案,它们可以使用相互依赖的分支来实现不同的行为。Com服务和PWM驱动使用主从通信机制来处理从机对于主机的调用。主从通信机制并非标准的,例如还可以使用共享内存或者BSW调度表来实现核间通信。
4、箭头指示在处理服务调用的过程中,涉及了哪些组件,具体取决于分发方法和调用的来源。
2.2、BSW OS BswM EcuM的分布
1、在每一个partition的Basic Software Mode Manager (BswM)运行了BSW模块;
2、每个Core上面都只有一个EcuM模块;
3、通过BootLoader启动的那个Core上的EcuM,是主EcuM;
2.3、多核的System Services
1、下图中出现的IOC,可以提供通讯服务,可以被客户端访问,;
2、BSW模块可以在多个核上去执行,例如图中的ComM模块;负责执行服务的核,会在运行时决定;
3、每个核运行一个ECU状态管理;
3、混合的关键性系统架构内容
3.1、AUTOSAR safety handling总览
AUTOSAR 提供了2种灵活的方法来支持安全相关的ECU:
1、允许所有的BSW模块根据需要的ASIL等级去开发;
2、选择一些模块根据ASIL等级去开发;带有ASIL等级的和没有ASIL等级分在不同的部分;ASIL(Automotive Safety Integrity Level,汽车安全完整性等级)是汽车行业中用于评估和分类车辆系统安全风险的标准。
ASIL A:最低的ASIL等级,适用于那些即使发生故障也不会导致严重后果的情况。例如,某些舒适性或信息娱乐系统可能被归类为ASIL A。
ASIL B:适用于可能导致轻微伤害或不适的情况,例如,某些辅助驾驶功能或车身控制系统。
ASIL C:适用于可能导致严重伤害或死亡的系统,但事故发生的可能性较低。例如,防抱死制动系统(ABS)或电子稳定程序(ESP)。
ASIL D:最高安全完整性等级,适用于可能导致严重伤害或死亡,且事故发生的可能性较高的系统。例如,动力转向、制动系统或自动驾驶系统的关键部分。
下图为方法1的使用案例:
3.2、 BSW模块分配
使用不同的BSW部分案例如下:
1、看门狗协议栈放置在ASIL BSW部分;
2、带有ASIL 和 non-ASIL的SWC可以用过RTE去访问WdgM;
3、其余的BSW被放置在 non-ASIL BSW部分;
补充:QM Application通常指的是Quality Management Application,即质量管理应用。
下图为方法2的使用案例:
4、模块总览
4.1、模块总览
下图展示AUTOSAR基础软件层模块的map:
更多内容可点击返回参考 CP_AUTOSAR_总目录