框架图
通讯栈在Autosar框架里面的位置
具体包括这一堆，有以太网，CAN，LIN，flexRay硬件，通过各自的TP或者不通过TP给到PDUR模块去转发到服务层，有some ip，COM，诊断之类的。NM模块对每种通讯都有各自的状态管理，是从服务层直接控制到MCAL层的，当然也可以控制服务层的开关，里面只是一种例子。另外就是XCP模块可以直接从应用层或者RTE层调用到MCAL进行各种通讯方式的标定。
如果觉得上面的图太乱了，可以看看这张图会清晰很多，里面包含了我们常用的几个通讯模块。
譬如CAN通讯，报文到达芯片引脚后会先进入MCAL层的CAN模块，传给抽象层的canif。如果是诊断类的报文还需要通过cantp模块进行解析，再给到服务层的DCM模块。如果是普通报文只需要通过PDUR转发上去给到COM模块。旁边的LIN和FR也是一样的，LINTP模块比较少用到所以在这里没有展示。IPDUM是在PDUR模块的转发的时候进行多路复用的。OS用来调度服务层的处理，譬如MCAL层的CAN接收可能是通过中断实现的，但是应用层需要周期去获取数据，这样就需要OS周期调度COM接收函数来解析接收到的CAN数据。
收发流程
普通信号发送过程，RTE层将信号给到COM层打包成为IPDU，下面几个PDU都是报文，只是名字不同而已，各自有细微差异，可以暂时理解为都是报文。COM模块调用PduR_ComTransmit()接口给到PDUR模块，PDUR调用CanIf_Transmit()接口转发给canif模块，canif模块通过调用Can_Write()接口给到MCAL的CAN模块，CAN模块最后调用把报文发送出去。
诊断报文也是类似的，从DCM模块发送下去，因为遵从TP协议，所以需要多经过一层cantp。
各层有一些数据缓存区，COM层的接收和发送都有缓存区，canif只有发送有缓存区，接收没有，而且大小可以自己配置。硬件层有mailbox，也属于缓存区，但是每个mailbox同一时间只能塞下一条报文，得发出去或者传给canif模块之后才能放入下一条报文。
ECUC模块
ECUC是一个不生成代码却有用的模块，里面包含了全局PDU，每条报文一个，主要是让PDUR转发的时候能够根据每条报文一一对应。让COM和PDUR之间的IPDU、canif和PDUR之间的IPDU都一一对应起来。当然，你也可以在PDUR里面进行转发，或者进行一条报文转多条报文的转发。
在诊断链路当中，ECUC为DCM和PDUR之间通讯提供IPDU，为PDUR和cantp之间提供了IPDU，为canTP和canif之间提供的是NPDU，有数据帧和流控帧两种。
RTE模块
RTE可以进行内部通讯，为两个SWC之间提供通讯，包括核间通讯。
COM模块
任务就是把上层的信号打包成报文发下去，把下面的报文解析出来给到上层。
譬如可以在RTE层调用下面这两个函数来进行信号收发。
为了能够处理一些复杂的数据类型可以将信号分组再给到COM模块，收发可以调用下面四个接口，注意调用的先后顺序就行。这里有一点，信号组是为了处理复杂的数据类型，并不是为了解决其他问题，换言之，只有遇到复杂数据类型才需要使用到信号组。我在最近某个项目当中遇到一种为了解决时序问题而使用信号组来打补丁的解决方式，提出过反对这种不标准用法的意见，但迫于项目组其他成员的意见不得不妥协，修改过后又继续出现新的问题，还需要再继续修改，确实非常头痛且无奈。
IPDU也可以在逻辑上打包成为组，组也可以作为成员继续打包成为更大的组，大的组相对于里面的组成为主组，里面的组相对于外面的组称为子组。
将IPDU打包成组，可以控制Com模块的发送接收功能。譬如我有ABC三条发送报文，某个时候不想发送AC，只想发送B，那我可以将AC报文打包为一个组，调用接口只发送B报文的IPDU。
发送方式有几种，有因为信号发送的，也有因为报文发送的。
触发型信号搭配直接型报文，平时不发送，在信号触发的时候就会引起一次报文发送。
等待型信号搭配周期型报文，需要等待到周期到达的时候才会统一发送出去。
触发型信号搭配混合型报文，不仅在周期到达的时候发送，还会在信号触发的时候发送。
触发型信号搭配N次型报文，在信号触发的时候就会发送N次报文。这种类型因为很像触发型信号搭配直接型报文，被很多工具统一了。
Deadline监控：对发送出去的报文监控获取应答的时间是否超时，如果超时将会触发回调函数。
接收流程有立即接收和延迟接收两种。立即接收将会在PDUR收到报文的时候立即转发给COM，并且立即触发RTE的接收回调函数解析信号给到RTE。延迟接收在PDUR收到报文的时候调用Com_RxIndication()接口将IPDU给到COM，但COM不会立即触发RTE的回调函数继续解析信号给RTE，而是等到运行到Com_MainFunctionRx()接口的时候，才会触发RTE的接收回调接口，将解析后的信号给到RTE。至于什么时候调用到Com_MainFunctionRx()接口，一般由BSWM模块来管理，轮询或者周期调用。
PDUR模块
按照发送来看，COM的IPDU可以单独转发到CANIF或者LINIF，也可以同时转发到CANIF和LINIF。可以通过BSWM调用PduR_EnableRouting()和PduR_DisableRouting()接口将某个路由的通路使能或者失能。
它就是一个网关，可以从一个接口模块路由到另一个，必要时可以进行缓冲。下图就是由LIN路由到CAN的示意图。
PDUR有一个零损耗操作Zero Cost Operation，当PduR只用来进行一对一转发的时候，为了优化性能而将执行代码以宏的形式生成出来。需要PduRRoutingTable仅包含Com跟CanIf，Dcm跟CanTp，CanNm跟Com之间的通讯，不包含IPDU Group。
IPDUM模块
I-PDU Multiplexer，IPDU多路复用器，在Autosar架构的这个位置，报文可以不走PDUR，而直接通过IPDUM来走。
有这样一种情况，一条报文里面，有静态部分和动态部分，静态部分是一样的，动态部分会有一个或者多个信号，位置和数量都不确定，但这条报文的IPDU ID是一样的。所以我们通过MUX来区分这些IPDU ID相同，但是动态部分结构不一致的报文，都是通过canif------IPDUM------COM的方式接收上来，就能正确解析，发送也是类似的。
CAN模块
接收、发送确认、busoff处理，唤醒处理，都需要配置选择是中断处理还是轮询处理。
CAN中断需要在OS里面添加
轮询模式需要在SCHM模块里面调用Can Mainfunctions接口。
COMM模块
这个模块同时管理NM和SM模块
设置每个通道的通信模式
COMM会收集并协调来自通信请求者的总线通信访问请求
提供一个API，用于禁用信号发送功能，以防止电子控制单元（ECU）发出信号。
主动地激活通信总线
Bus error管理
COMM模块的几种状态，需要注意的是，每个通道都有自己的状态，可以can1已经静默了，但是can2依然能够正常收发。
状态跳转图是一样的，有点像网管状态跳转图。
Request of full communication也称为主动唤醒，由COMM向CANSM请求full communication，然后有多个动作：
1.CANSM设置canif发送模式为normal，canif模块设置canTrcv模块发送模式为normal
2.CANSM设置canif控制器模式为normal，canif模块设置can模块控制器模式为normal
3.CANSM开始COM模块的报文收发
4.最后CANSM向COMM模块汇报已经转换到full communication