AUTOSAR网络管理需求规范

1.概述

1.1 AUTOSAR基本定义

AUTOSAR，全称为Automotive Open System Architecture，即汽车开放系统架构。它是由全球各家汽车制造商、零部件供应商以及各种研究、服务机构共同参与的一种汽车电子系统的合作开发框架，并建立了一个开放的汽车控制器（ECU）标准软件架构。AUTOSAR设计的初衷，是通过提升OEM以及供应商之间软件模块的可复用性和可互换性来改进对复杂汽车电子电气架构的管理。主要解决事项有以下三条：
1.对应用软件与底层软件之间以及应用软件之间的接口进行标准化。
2.给出一个控制器软件参考架构。
3.规定了开发流程中的文件交换格式。

直白一点说就是（说人话），通过AUTOSAR软件架构将控制器（ECU）的软件底层做了一个标准的封装，只需要修改其中的一些配置和参数，就可以匹配不同的硬件，不会因为厂家芯片的更换而导致代码模块全部推倒重来。同时大大提高不同厂家代码移植性。AUTOSAR在软件架构上分为应用层（APP）、中间层（RTE）、基础软件（BSW）和复杂驱动（CDD）。其中基础软件层有进行了进一步分层设计，其中就有微控制器抽象层（MCAL），就是硬件驱动，将硬件的底层接口做了封装，如果芯片换了，只需要配置一下MCAL即可，上层代码不需要改动就可以继续使用。从开发角度看，提高了代码的复用性以及可维护性，有利于提高开发效率。

1.2 CAN总线基本介绍

  控制器局域网（CAN）是一种串行总线通讯协议，有效支持分布式实时控制系统要求的实时性、灵活性。在汽车上，连接各个ECU、传感器单元，传输速度可以达到1Mbit/s。本文仅介绍下CAN总线的主要特点，由于CAN总线内容非常丰富，只言片语难以讲清楚，这里不做详细赘述。
  CAN 总线在数据通信方面具有较强的实时性、较高的安全性和可靠性、较高的灵活性等突出特点。与一般总线相比，CAN 总线的主要特点可以归纳为以下几个方面：
(1) CAN网络采用多主工作方式，网络中的所有节点低位相同，在任意时刻，网络上的任何一个节点都可以主动的向网络上发送消息。
(2) CAN网络采用非破坏性的总线仲裁机制，通过为每个节点分配不同的ID（标识符）来确定节点的优先级。同一时刻，当网络上如果多个节点同时向向总线发送消息而产生冲突时，根据ID进行优先级判断，优先级低的节点推出发送队列，优先级高的节点继续发送。
(3) 总线上传输的CAN消息以广播的形式在整个网络上传输，CAN节点可以通过对报文ID进行过滤实现点对点、一对多、全局广播等各种形式的接收。
(4) 每帧数据具有循环冗余校验和其他检查错误机制。
(5) CAN器件可以设置休眠/唤醒模式，将CAN 器件设为睡眠模式能够减少系统的电源消耗，停止器件内部的活动，断开与总线驱动器的连接。CAN器件的唤醒模式可以通过总线激活和系统内部的状态唤醒两种方式。唤醒时，传输层需要等待一段时间，然后通过检查11 个连续的“隐性”位判断是否已经与总线活动同步。

1.3 网络管理基本介绍

汽车电子网络管理我的理解就是，使得车载网络中的ECU节点能够有序的休眠和唤醒，在没有通信需求的时候进入休眠，在有通信需求的时候立即唤醒，如此可以优化车辆的能量消耗。目前实际开发中，基本有两种形式，一是OSEK/VDX网络管理体系，二是AUTOSAR网络管理体系。
AUTOSAR-CanNm基于分散的直接网络管理策略，这意味着每个网络节点仅依赖于在通信系统内接收或传输的网络管理PDU来执行自给自足的活动。
这里解释下什么叫直接网络管理，与之对应的还有间接网络管理。在OSEK/VDK网络管理中提供了两种网络监控方法。一种是利用监控周期性消息的方法间接监控，即间接网络管理（Indirect Network Management）。另一种是采用逻辑环机制，设计专门的NM消息进行通信，从而监控整个网络状态，达到网络管理的目的，即直接网络管理（Direct Network Management）。

AUTOSAR网络管理采用分布式的直接网络管理方法。网络状态的变化是由周期性NMPDU的接收情况和节点请求网络的状态综合考虑的。AUTOSAR-CanNm算法基于周期性的网络管理PDU，由集群中的所有节点通过广播传输接收。接收到网络管理PDU表示发送节点希望保持网络管理集群处于唤醒状态。如果任何节点准备进入总线睡眠模式，它将停止发送网络管理PDU，但只要从其他节点接收到网络管理PDU，它就会推迟到总线睡眠模式的转换。最后，如果由于不再接收到网络管理PDU而导致专用计时器超时，则每个节点都会启动到总线睡眠模式的转换。

直白一点说就是（说人话），当节点接收到一个NMPDU 时，意味着该网络管理消息的发送节点意图保持网络的唤醒状态。如果某个节点停止发送NMPDU，意味着该节点准备进入睡眠状态。但是，只要该节点接收到来自其它节点的NMPDU，就重新启动等待定时器，推迟进入睡眠状态的时间。如果直到CANNM_MSG_TIMEOUT_TIME 超时都没有收到其他节点的NMPDU，意味着所有节点都想休眠，于是整个网络便进入总线睡眠状态。

注：关于这块具体内容，可以查阅AUTOSAR_SWS_CANNM官方文档，以获得更多认知。

2.CAN协议栈

2.1 CAN协议栈定义

CAN通信服务是一组用于车辆CAN通信系统的模块。其主要任务是为CAN通信网络提高一套统一的接口，同时从应用程序中隐藏相关的协议和消息属性。CAN通信协议栈支持传统的CAN通信（CAN2.0）以及CANFD通信（前提是硬件上支持CANFD）。
好了开始说人话，我们先来看看AUTOSAR架构中 CAN ECU的软件结构：

我们再来看看AUTOSAR中CAN通信涉及的各个模块：
简单的说，一句话：抽象程度高，有许多基础模块可以使用。

2.2 CAN通信发送过程

接下来，讲一下AUTOSAR架构中CAN通讯是如何进行的，其数据流/信号流是如何跑通的。
先讲发送：

1. BSW调度器周期性调用Com模块Com_MainFunctionTx函数，Com模块将从其缓存器中读取需发送的数据；
   
2. Com模块的Com_MainFunctionTx函数将调用PduR模块PduR_Transmit函数，将数据传给PduR模块；
   
3. PDUR模块路由到CAN Interface模块，调用CanIf_Transmit函数，这样数据从PduR模块传给了下层的CAN Interface模块；
   
4. CAN Interface模块再调用Can Driver模块的Can_Write函数，将数据写入相应的寄存器；
5. Can_Write函数将访问仲裁，数据长度和数据寄存器，将数据写入。

2.3 CAN通信接收过程

再讲接收

1. BSW调度器周期性调用CAN Driver模块的Can_MainFunctionRead函数；
2. CAN Driver模块的Can_MainFunction_Read函数将访问CanController（硬件）的寄存器（仲裁寄存器，数据寄存器和数据长度寄存器）并读取这些寄存器的数据；
3. 数据读取结束后，这时继续调用CAN Interface模块的CanIf_RxIndication函数，这样数据从CAN Driver模块传给了上一层的CAN Interface模块；
   
4. CAN Interface模块再调用PduR模块的PduR_RxIndication函数，将数据传到PduR模块；
   
5. PduR模块路由到Com模块，调用Com_RxIndication函数，将数据传到Com模块，Com模块将会把数据存入其缓存，供应用层软件读取使用
   

上述内容仅是简单描述了CAN通信的发送和接收流程。这也仅是对其软件过程有一个简单了解，如果要深入研究并理清其中的机制，必须研读AUTOSAR官方文档。当然此文作为一个起点，正如古人所说“大文章全凭起首，好结局总在后头”，本人将结合自己工作实际以及学习，后续会继续更新并完善，解决此文中涉及到的具体概念，具体问题，具体机制，具体软件实现过程。

3.网络管理模式介绍

AUTOSAR网络管理有三种状态：
1. Bus Sleep Mode
2. Prepare Bus Sleep Mode
3. NetworkMode

下图显示了与API规范相关的UML状态图：
模式改变相关的转换用绿色表示；
错误处理相关的转换用红色表示；
可选的节点检测相关的转换用蓝色表示；
此外，假定已启用总线负载降低功能。

3.1 运行模式

前面那张图是引用《AUTOSAR_SWS_CANNetworkManagement_4.3.1》，在这里我按照自己的理解，对其做个简单梳理：

定义如下：
BSM：睡眠模式
NM：网络模式
PBM：预睡眠模式
RMS：重复报文模式
NOS：正常操作状态
RSS：准备睡眠模式

1. ECU上电进行初始化，进入睡眠模式。如果没有唤醒源唤醒，将一直停留在BSM状态。
2. 从本节点ECU或其他任何NM报文中检测到唤醒请求，进入RMS状态。简单的说就是出现本地唤醒或远程唤醒时，本地唤醒即自身节点“我”主动要和其他节点通信，远程唤醒即其他节点向要和“我”通信。
3. 重复报文计时器已超时并且有网络请求。

3.1.1 Bus Sleep Mode

3.1.2 Prepare Bus Sleep Mode

3.1.3 NetworkMode

3.2 定时器控制及参数

3.3 网络管理报文

3.4 总线休眠处理

3.5 应答丢失行为处理