AUTOSAR知识点Com：CANSM规范部分解读

Posted 2023-03-30 剑从东方起

1、概述

        看规范过程中的记录点，这部分主要是与其他模块的交互，以及本身或者其他模块和本模块的交互点在哪里，部分规范翻译。

2、CanSM与其他模块的交互

规范里面的图形如下

 2.1、ECUM

        EcuM模块初始化CanSM模块,与CanSM模块交互,进行CAN总线唤醒验证。下个章节会描述调用了什么函数。

2.2、SchM

        BSW调度模块调用CanSM模块的主函数（此处理解一个含义SCHM，个人理解与OS的调度有些类似）,这对CanSM模块的循环处理是必要的。

2.3、ComM

        ComM模块使用CanSM模块的API来请求CAN网络的通信模式,这些网络标识具有唯一的句柄。唯一的句柄其实就是handle

        CanSM模块可以将网络的当前通信模式通知到ComM模块。ComM告诉 CanSM要做什么。

2.4、CanIf

        CanSM模块使用CanIf模块的API来控制CAN控制器的操作模式,也可以使用CDD模块CAN收发器的API。

        CanIf模块通知CanSM模块发生了什么事件，就是回调，其实真正关联的也就两个，如下图

2.5、 Dem

        CanSM模块将特定的生产错误报告到DEM模块，这个地方有个点，就是Busoff问题，问题如下。

        假设将busoff故障上报给DTC，那么我们设定一个条件5次快恢复才上报，此时应该怎么实现呢？

2.6、BswM

        CanSM需要将总线特定的模式更改通知到BswM模块。

        与通知ComM什么区别呢？一个是通信方面，一个是总体所处状态。

2.7、Nm

        CanSM模块将部分网络是否可用通知给CanNm模块，并在部分联网的情况下处理已通知的CanNm超时异常。

2.8、Det

        CanSM模块在错误检查开启的前提下，向Det模块发送开发和运行时的错误。

3、其他说明

描述一个头文件注意点：

        CanSM.h应该包含头文件ComM.h 规范解释一些API需要使用ComM的定义。以此看来头文件在AUTOSAR里面包含是很严谨的。

其他功能说明

        一个ECU可以有不同的通信网络。每个网络都必须用唯一的网络句柄（也就是handle）来标识。ComM模块向网络请求通信模式。通过它的配置，它知道哪个句柄被分配给什么样的网络。对于CAN，它使用CanSM模块。

        CanSM模块负责CAN网络的控制流抽象（其实相对于硬件抽象层就是多了一层状态控制，抽象CanIf的接口）:它根据来自ComM模块的模式请求改变配置的CAN网络的通信模式。

        因此CanSM模块使用了Canlf模块的API。Canlf模块负责配置的CAN控制器和CAN收发器的控制流抽象(Canlf模块的数据流抽象与CanSM模块无关)。CAN控制器模式和CAN收发器模式的任何变化都将由Canlf模块通知给CanSM模块。根据CAN网络状态机的通知和状态(CanSM模块应为每个配置的CAN网络实现)，CanSM模块通知ComM和BswM。

CanSM模块应该将当前的网络模式存储在内部。

CanSM的模式有

COMM_NO_COMMUNICATION,

COMM_SILENT_COMMUNICATION,
COMM_FULL_COMMUNICATION

         CanSM模块应在每个成功的控制器模式更改或总线条件更改到canif_cs_stop时存储,以确保每个可以控制器的内部更改模式。

详解AUTOSAR：AUTOSRA软件架构（理论篇—2）

目录

1、应用软件层

2、运行时环境

3、基础软件层

3.1、服务层

3.2、ECU抽象层

3.3、微控制器抽象层

3.4、复杂驱动层

---

AUTOSAR规范主要包括：软件架构、方法论和应用接口三部分内容。其中，软件架构是实现软硬件分离的关键，它使汽车嵌入式系统控制软件开发者摆脱了以往ECU软件开发与验证时对硬件系统的依赖。

在AUTOSAR软件架构中，汽车嵌入式系统软件自上而下分别为：应用软件层（Application

Software Layer，ASW）、运行时环境（Runtime Environment，RTE）、基础软件层（Basic Software Layer，BSW）和微控制器（Microcontroller）。为保证上层与下层的无关性，通常情况下，每一层只能使用下一层所提供的接口，并向上一层提供相应的接口。如图下图所示：

1、应用软件层

应用软件层（Application Software Layer，ASW）包含若干个软件组件（Software Component，SWC）（软件组件在下一篇文章讲解），软件组件间通过端口（Port）进行交互。每个软件组件可以包含一个或者多个运行实体（Runnable Entity，RE），运行实体中封装了相关控制算法，其可由RTE事件（RTE Event）触发。

2、运行时环境

运行时环境（Runtime Environment，RTE）作为应用软件层与基础软件层交互的桥梁，为软硬件分离提供了可能。RTE可以实现软件组件间、基础软件间以及软件组件与基础软件之间的通信。RTE封装了基础软件层的通信和服务，为应用层软件组件提供了标准化的基础软件和通信接口，使得应用层可以通过RTE接口函数调用基础软件的服务。此外，RTE抽象了ECU之间的通信，即RTE通过使用标准化的接口将其统一为软件组件之间的通信。由于RTE的实现与具体ECU相关，所以必须为每个ECU分别实现。

3、基础软件层

基础软件层（Basic Software Layer，BSW）可分为四层即：服务层（Services Layer）、ECU抽象层（ECU Abstraction Layer）、微控制器抽象层（Microcontroller Abstraction Layer，MCAL）和复杂驱动（Complex Drivers），如下图所示：

可以将基础软件层进一步细化，包括：系统服务( System Services)、存储器服务（Memory Services）、通信服务（Communication Services）等，它们主要用于提供基础软件服务，包括标准化的系统功能和功能接口。如下图所示：

3.1、服务层

服务层（Services Layer）提供了汽车嵌入式系统软件常用的一些服务，其可分为系统服务（System Services）、存储器服务（MemoryServices）以及通信服务（Communication Services）三大部分。提供包括：网络通信管理、存储管理、ECU模式管理和实时操作系统（Real Time Operating System，RTOS）等服务。除了操作系统外，服务层的软件模块都是与ECU平台无关的。

3.2、ECU抽象层

ECU抽象层（ECU Abstraction Layer）包括板载设备抽象（Onboard Devices Abstraction） 、存储器硬件抽象（Memory Hardware Abstraction)、通信硬件抽象（Communication Hardware Abstraction）和I/O硬件抽象（Input/Output Hardware Abstraction）。

该层将ECU结构进行了抽象，负责提供统一的访问接口，实现对通信、存储器或者IO的访问，从而不需要考虑这些资源是由微控制器片内提供的，还是由微控制器片外设备提供的。该层与ECU平台相关，但与微控制器无关，这种无关性正是由微控制器抽象层来实现的。

3.3、微控制器抽象层

微控制器抽象层（Microcontroller Abstraction Layer，MCAL）是实现不同硬件接口统一化的特殊层。通过微控制器抽象层可将硬件封装起来，避免上层软件直接对微控制器的寄存器进行操作。微控制器抽象层包括微控制器驱动(Microcontroller Drivers）、存储器驱动（Memory Drivers）、通信驱动（Communication Drivers）以及I/O驱动（IO Drivers），如下图所示：

3.4、复杂驱动层

由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题，难以抽象，所以在AUTOSAR规范中这部分没有被标准化，统称为复杂驱动( Complex Drivers）。