can-bus - Autosar 中的 IPDM 是什么？如何为多个 IPDU 执行多路复用？
问题描述
在 autosar 中阅读 ComStack 时，我开始了解 IPDM 模块。我阅读了技术参考，但仍然不清楚 IPDU 的功能以及如何使用不同的 IPDU 进行多路复用。我知道 Multiplexing/Demultiplexing 或 Selector 字段，但是这里如何链接？
解决方案
AUTOSAR_SWS_IpduM（第 7 章）和 AUTOSAR_TPS_SystemTemplate（第 6.5 章）对此进行了很好的解释。
IpduM 下层连接到 PduR。所以 MultiplexedIPdu 的接收/传输。
IpduM 更高层连接到 Com：
- 直接（IpduM 中的优化选项）
- 在 PduR 上
静态部分会有一个 ISignalIPdu，Com 中 MultiplexedIPdu 的每个动态部分都有一个 ISignalIPdu。选择器甚至被添加到每个 ISignalIpdu-ID。对于传输，Com 中动态 ISignalIpdu 之一的触发器将转发到 IpduM，IpduM 还将静态部分的 ISignalIPdu 添加到 MultiplexedIpdu。
对于接收，在 Com 中会有动态 ISignalIpdu 和静态 ISignalIpdu 的 RxIndication。
因此，在 Com 中，您只需将 ISignalIPdus 当作彼此的 ISignalIPdu 来处理，而不用担心它们是否被多路复用。您甚至可以在 Com 中单独监控每个动态部分的超时。
因此，您只需通过应用程序更新 ISignals/ISignalGroups，这将更新 Com-Buffers，而 Com/IpduM 将根据配置决定何时发送以及发送什么。
虽然，我在该领域的经验是，许多开发人员无法真正从底层抽象应用程序及其端口/接口以及到 RTE 中的信号和信号组、信号/信号组和 Com 中的接收/传输模型的映射帧/PDU（或以前的消息）。在以前使用（或不使用 IL）的项目中看到了这一点，例如 Vector CANbedded，或者现在使用 AUTOSAR Com。
这就是为什么应用程序组件必须一直被触及和重写的原因，因为它们非常依赖于车辆通信描述的信号。而且我什至经常看到“应用程序组件”实际上通过重新实现传输请求或自己进行超时监控来绕过 Com（或 IL）中的传输/接收模型。