[CP_AUTOSAR]_分层软件架构_内容详解

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_总目录