继续看《AUTOSAR_RS_Features》，今天看一下通过总线进行的通信要求。
需要定义通信数据的传输和接收。
依赖总线以及不依赖总线的功能需要拆分开。
支持把信号映射成通信协议的数据单元，拿我现在熟悉的内容来说，可能是把一些消息中的信号组合成CAN报文的消息帧。
支持固定大小以及动态大小的信号。这里的动态大小，其实也有一个上限值。
支持信号的网关传输，而网关本身看上去应该就是多个总线信号转移。
不同于上一条，这一条中的IPDU其实有一点协议栈的感觉了。
支持基于用户请求、时间基准以及底层总线请求的数据传输。
收发超时都该是AUTOSAR本身支持的。看起来，如果AUTOSAR的软件用起来了，这部分功能其实是可以用配置取代的。
支持信号的过滤，一定程度上是为了保证数据有效后再往下传递。
信号应该有初始值，而这部分我清楚的是现在我在工作中看到的用法其实是有问题的。
通信部分，支持了大小端的转换。
如果数据按照组的方式进行管理，需要确保一组数据的一致性满足后再传输。
支持收发的取消，而这部分一个典型场景是加速关机过程。
超过底层总线属性本身大小的数据也应该可以传输，而这个其实有点协议栈多帧报文的感觉。
针对大数据的传输高效，需要增加一个额外的内湖交互层模块。
需要支持XCP。
支持不同网络全局时间的分发同步。
致辞总线的状态管理，用于追踪总线总线的状态，检查当前的总线是否被使用。
通信状态管理需要支持动态的总线访问限制，这让我联想到了UDS的8x命令，让不相干的节点保持静默。
提供一个机制保持总线唤醒，并且可以由总线保持唤醒状态。这个杜少让我想到了CAN唤醒了，而从上面的描述看，这正好是我现在不熟悉的网络管理的功能。
支持把总线同步置于睡眠状态。
即使是总线活动的，也可以允许部分节点的选择性关闭。这个让我想到了部分网络唤醒这么个概念。
好，上面这就是对这部分信息的一个简单梳理。置于收货嘛，算是第一次真正从这种正式的文档文件中认识了最近比较磨耳朵的几个技术术语。后面这部分的设计、配置、测试等可能需要更多的时间来打磨了。
