【小猫爪】AUTOSAR学习笔记09-Communication Stack之Dcm模块

前言

  前面对Communication Stack的通信管理理部分介绍清楚了，接下来就来看看Communication Stack中负责诊断通信的Dcm模块以及三大总线上对应的传输层，分别是CanTp模块，DoIP模块，FlexRayTP模块。

1 Dcm简介

  Dcm 模块为诊断服务提供标准的函数接口，在控制器产品开发、制造和售后服务期间，用户可以通过外部诊断工具访问 Dcm 模块实现对控制器进行刷新、故障诊断等操作。说白就是Dcm是AUTOSAR架构对UDS协议的具体实现，对UDS协议不熟悉的朋友可以参考我的另外两篇文章：1.《小猫爪：汽车电子小知识01- ISO15765（UDS on CAN）详解》；2.《小猫爪：汽车电子小知识02- ISO14229-1（UDS）简介》。

  Dcm模块是PduR模块的上层模块，当PduR接收到下层传输模块的UDS PDU后，就会将其路由发送到Dcm模块，同理，PduR模块也会将Dcm模块下发的PDU路由到对应的传输层模块。

  为实现 Dcm 功能，AUTOSAR 规范根据诊断服务执行的过程，将 Dcm 模块分为 3个子模块，分别是：

1. DSL(Diagnostic Session Layer)实现诊断数据的接收和发送、管理诊断时间参数、管理诊断会话状态和安全等级；
2. DSD(Diagnostic Service Dispatcher)检查诊断服务是否支持、管理从 DSP 子模块得到的诊断响应；
3. DSP(Diagnostic Service Processing)执行诊断服务处理。
   

2 CanTp简介

  CanTp 模块在 AUTOSAR 架构中位于 CanIf 和 PduR 模块之间，参考 ISO 15765 标准，实现通信双方之间的基于 ISO 15765 协议的 CAN 通信功能，即实现了UDS on CAN的网络层，接收来自CanIf传来的诊断报文后对其进行单帧多帧处理，然后将PDU传输给PduR模块。

  CanTp模块的主要功能有：
  1. 收发单帧和多帧报文，对多帧报文进行解包和组包；
  2. 控制数据流；
  3. 检测报文收发过程中的各类错误，并向上层报告；
  4. 支持多连接通道。

  在这里需要了解一下的就是，以前的ISO15765是基于Clasic CAN实现的，一帧CAN报文只有8个字节，但是后面随着CANFD的横空出世，ISO-15765也随之调整，对于4种帧类型的定义变成如下：

  关于CanTP的一些其他具体细节在这里就不多说了，感兴趣的朋友可自行查找相关资料学习。

3 DoIp简介

  下面再来看看Dem模块的另外一个传输层DoIP （Diagnostic over IP）模块，这个模块其实就是UDS协议在以太网总线上的传输层的实现，即ISO13400规范的实现，其在AUTOSAR Communication Stack的位置如下图所示：

  DoIP 模块位于 SoAd 模块之上，负责接收 SoAd 传递的 PDU，对于非诊断报文，在 DoIP 内部进行处理；对于诊断报文，在对头部和部分 payload 检测完之后，将数据传递给上层 PduR，并回复 DoIP 层面的 ACK/NACK；另外，DoIP 也会接收来自 PduR 的 PDU，并加上 DoIP 头部后进行发送。DoIP功能主要有车辆发现，状态查询，路由激活（含安全认证），诊断数据收发。

  在车内用到DoIP模块的一般都是Gateway角色的设备，一般应用场景为：诊断仪Tester作为客户端，对车内网的支持DoIP协议的ECU进行诊断，而通常支持DoIP协议栈的ECU又会起到网关作用，自身作为诊断Server端的同时还具有诊断路由的功能，在路由打通后，发送的诊断数据根据目的地址的不同分别流向车内网的不同ECU。

  关于DoIP的一些其他具体细节在这里就不多说了，感兴趣的朋友可自行查找相关资料学习。汽车上还有一个常用总线为FlexRay，这个总线说实话出现的概率不多，就个别车企喜欢用这个，关于FlexRayTP的一些其他具体细节在这里就不多说了，感兴趣的朋友可自行查找相关资料学习。

END