这是场景...
我需要为每个任务 2 个不同的可运行文件...
- First : to receive data at specific times at the beginning of the task.
- Second: to send data at specific times at the end of the task.
这些可运行文件中的每一个都应在任务开始时为不同的组件进程提供数据（与发送者接收者接口的隐式接收模式相同，但使用过滤器属性无法实现一些过滤）或发送数据仅在任务结束时的特定时间。
现在我该如何处理？我应该为每个组件定义这些可运行文件吗？还是让所有组件之间的通信都通过这个应该处理发送和接收时间的公共组件？
我是 AUTOSAR 的新手，所以请告诉我什么是最好的解决方案。
...让所有组件之间的通信通过这个应该处理发送和接收时间的公共组件？
这就是我在过去几年中看到的很多。许多从事通信堆栈的开发人员不了解这些功能，实际上在 SWC 中重新实现了一些实际上在 ComStacks 中可用和完成的东西......甚至在 Vectors CANbedded 堆栈中（在 IL（交互层）中）。它使 SWC 如此依赖于通信，以至于发生变化的概率非常高。
超时处理由 IL 和 AUTOSAR Com 根据 SystemDescription/EcuExtract（和旧 DBC 文件）PduTiming、IPDU 传输模式和信号传输属性进行处理。
IPDU 传输模式： * NONE --> 不是由 Com 触发，而是由 Com_TriggerIPDUSend() 手动触发 * PERIODIC --> Com 根据配置的时间周期循环触发 * DIRECT --> 在配置信号的“事件”上触发（TRIGGERED* )
* MIXED (PERIODIC + DIRECT) --> "EventPeriodic" .. 这也包括一个可能的 MDT（最小时间延迟）
只是命名一些信号属性值： * PENDING - 在和 IPDU TxMode MIXED 中，这不会触发事件，因此将等待下一个传输事件（或仅与下一个消息周期） * TRIGGERED - 像以前的 DBC“OnWrite” * TRIGGERED_ON_CHANGE - 像前 DBC“OnChange”，因此仅当值与上一个值相比发生变化时
AUTOSAR Com 还可以根据配置的时间段监控接收到的 IPDU。
IpduGroups 可用于启用/禁用 IPDU 传输和 IPDU RxDeadline 监控（超时处理）。
所以，最后，大多数 SWC 并不真正需要关心接收/传输时间.. 他们只是向/从他们的端口写入/读取，仅此而已。
另一个好的特性是 SignalGroup 处理，它消除了保持复杂数据（结构）同步的负担。以前，有人可能会锁定中断，直到消息中的所有数据都更新。
E2E 保护现在可以由 E2E 变压器处理。
因此，SWC 可以在 VFB（虚拟功能总线）级别上建模，然后映射到 ECU。它们的连接保持不变，但如果 SWC 仅通过同一 ECU 内的 RTE 上的内部 ECU 进行通信，或者通过 ComStack 跨 ECU 边界通过 ECU 间进行通信，则与 SWC 完全无关。SWC 可以使用 dataReceivedEvents 或 dataReceiveErrorEvents 来获得有关接收或接收错误（例如超时）的通知，以及有关传输完成的 dataSendCompletedEvent。或者他们也可以通过检查 Rte_Read/Write 调用的 RTE 返回码来“轮询”。
与 DataTransformations、Data/PortMapping 和转换的 RTE 功能一起，拥有可重新配置的 SW 应该更容易，而无需一直更改 SWC。
移动 SWC 也将更容易，无论是将它们移动到多核处理器（具有多核操作系统和多核 RTE）上的另一个核心，还是将功能从传感器移动到高性能中央 ECU。
PDU 级别的网关路由关系甚至不需要任何 SWC，这可以通过配置 PduR 路由关系并在此处交换 POSTBUILD 配置来处理。甚至 Com 中基于信号的路由也可以这样完成。