【小猫爪】AUTOSAR学习笔记02-Communication Stack简介

前言

  这一章开始，就开始来看看AUTOSAR架构中BSW层的一个最最最重要的部分，那就是Communication Stack部分。它占据了BSW层很大一个篇幅，如下：

1 简介

  Communication Stack主要承载了ECU的通信功能，例举一下汽车电子通信网络中的几大总线，CAN, LIN, FlexRay，以太网。所以不难想象Communication Stack必须要针对这四大总线实现它们的驱动以及相关常见协议栈，比如说CAN的UDS，以太网的TCP/IP等。整个Communication Stack的结构如下图所示：

  仔细观察四大总线的消息传递路径，可以发现在AUTOSAR架构中基本上都大同小异，对于接收消息而言，四大总线上的消息大多都是先由MCAL层中的Driver，然后传输到位于ECU抽象层的Interface，Interface层会根据消息类型进行分配最后再传输到该消息对应的服务层，对于发送则是一个相反的过程。

  Communication Stack所提供的服务，主要有两类，一类主要负责通信数据的传输，主要有Com服务和Dcm服务，这两者主要负责ECU大量系统数据的传输，另外一类则负责通信模式的管理，包括有SM模块和NM，这两者主要负责状态管理和网络管理。

  Com服务主要负责传递来自APP层的消息，说简单点它就是把系统中的一些系统变量参数根据一定数据组合规则打包（或者解包），然后根据一定的时间/事件规则发送出去（或者接收进来）。

  Dcm服务主要实现了UDS诊断协议，接收来自外部的请求，并作出响应，对UDS感兴趣的朋友可参考我的UDS文章：《小猫爪：汽车电子小知识02- ISO14229-1（UDS）简介》。

  SM模块则是负责总线的状态管理，主要负责总线通信开启和关闭，另外还负责总线错误的检测和恢复。而NM模块则负责总线的网络管理，基于总线报文协议控制ECU的睡眠和唤醒。

  除了上面提到的几个非常常见的模块外，Communication Stack还有很多其他模块，在这里就不多介绍了，感兴趣的小伙伴可以关注本系列的后续文章。另外也可以参考这篇文章来提前了解一下Communication Stack的模块：《Autosar Com Stack 通讯功能栈》。

2 CAN消息的传播路径

  以CAN总线为例，简单的例举一下其消息在整个Communication Stack的流动规则。

2.1 Com服务

  Com服务中的CAN消息传递路径如下图所示：

  对于接收而言，MCAL层中的CanDrv接收到最原始的CAN报文后传输到CanIf模块，CanIf模块相当于是一个报文分类模块，它会根据CAN ID将CAN报文分类，然后传递到服务层的不同模块，比如图中的PduR模块。经过了CanIf模块后，这个时候原始CAN报文变换为服务层PDU。PduR功能为PDU路由，它会对PDU再次进行分类，随后将其传递到更上层的软件模块，比如Com模块。

2.2 Dcm服务

  Dcm服务中的CAN消息传递路径如下图所示：

  在Dcm服务中，对比Com服务，发现其有两个不同，第一个不同为Dcm服务与APP没有交集，因为Dcm就是UDS。第二个不同为在CanIf模块和PduR模块中多了一层CanTP模块，这个模块其实就是实现了ISO15765-2中描述的UDS on CAN的网络层，感兴趣的朋友可参考我的文章：《小猫爪：汽车电子小知识01- ISO15765（UDS on CAN）详解》。

2.3 SM服务和NM服务

  前面提到过两者主要负责ECU系统的状态管理和网络管理，它们比较特殊，并不是类似以Com和Dcm服务这种单纯的数据传输功能，后面我们会详细介绍这两个功能，CanIf模块直接就将PDU传输到这两个模块了，在这里就不多展开介绍了。

  除了CAN，其他的总线结构也差不多类似，在这里就不做介绍了，感兴趣的朋友可以自行去查阅资料学习。

3 补充说明

  Autosar中很多模块的名称都是简写的，大家可以参考Autosar官网的文档《AUTOSAR_TR_BSWModuleList.pdf》来对着了解每个模块的全名是啥子，然后再找到其对应模块的文档来仔细研究，不出一个月，你就会对AUTOSAR滚瓜乱熟，烂熟于心。这里小截一段图给大家看看里面的内容：

END