全部学习汇总： https:///GreyZhang/hack_autosar
继续学习AUTOSAR，永无止境的官方文档。
4.5 通讯规范
ComSpec 的大图
AUTOSAR 系统中组件之间交换信息的最高级别描述是 PortInterfaces，如前面的部分所示。 然而，这样的端口接口只描述了结构，并不包括关于是否需要可靠地进行通信，或者在实际数据尚不可用的情况下是否存在初始值的信息。
此信息是特定于角色的，即它应应用于 PortPrototypes 而不是 PortInterfaces 的级别。 因此，大多数与通信相关的属性都与 SwComponentType 的 PortPrototypes 相关。
通信属性组织在所谓的通信规范（根据元模型：ComSpec）类中。
请注意，通信规范是可选的，即在任何情况下都不需要它的存在。 图 4.29 和 4.30 提供了通信规范的概述。派生的元类在以下子章节中进行解释。
如前所述，在 SwComponentType 级别所需的 ComSpec 元类附加到 PortPrototype 声明，而 PortPrototype 声明又是 SwComponentType 定义的一部分。 尽管如此，ComSpecs 的使用并不限于 AtomicSwComponentTypes 的 PortPrototypes（更多详细信息请参阅第 2.5 节）。
然后，第 7.5.1 和 7.5.2 节解释了与 RTE、RTE 事件和相应的通信属性相关的发送方-接收方和客户端-服务器通信模式。
几个 ComSpecs 允许定义与关联的 DataPrototype 相关的 initValues。 有关 initValues 表示的更多详细信息，请参阅第 5.7.2 节。
此外，语义约束适用于 ComSpec 的特定子类只能由对应类型的 PortInterface 类型的 PortPrototypes 拥有。
一个 PPortPrototype 上下文中 PPortComSpec 的数量限制
在一个 PPortPrototype 的上下文中，只能有一个 PPortComSpec 引用给定的 dataElement 或 clientServerOperation。
换句话说，在一个 PPortPrototype 的上下文中不允许存在两个或多个 PPortComSpec，它们引用相同的 dataElement 或 clientServerOperation。
一个 PPortPrototype 上下文中 RPortComSpec 的数量限制
在一个 RPortPrototype 的上下文中，只能有一个 RPortComSpec 引用给定的 dataElement 或 clientServerOperation。
换句话说，在一个 RPortPrototype 的上下文中不允许存在两个或多个 RPortComSpec，它们引用相同的 dataElement 或 clientServer 操作。
PRPortPrototype 可以同时拥有 RPortComSpecs 和 PPortComSpecs
与 PPortPrototype 和 RPortPrototype 不同，PRPortPrototype 可以同时拥有 RPortComSpecs 和 PPortComSpecs。
然而，以下限制适用：
一个 PRPortPrototype 上下文中 RPortComSpecs/PPortComSpecs 的数量限制
在一个 PRPortPrototype 的上下文中，只能有一个 RPortComSpec 和一个 PPortComSpec 引用给定的 dataElement 或 clientServerOperation。
换句话说，在一个 PRPortPrototype 的上下文中不允许存在两个或多个 PPortComSpec，它们引用相同的 dataElement 或 clientServerOperation。 以同样的方式，不允许在一个 PRPortPrototype 的上下文中存在两个或多个 RPortComSpec，它们引用相同的 dataElement 或 clientServerOperation。
[constr_1290]、[constr_1291] 和 [constr_1292] 存在的基本原理是 AUTOSAR 通信层需要明确的通信行为规范。 冗余 RPortComSpecs/PPortComSpecs 的存在很容易相互矛盾，这将阻止为 AUTOSAR Com 创建有效配置。
提供的 PortPrototype 的通信属性。 此类将包含对所有类型的提供端口有效的属性，独立于客户端-服务器或发送方-接收方通信模式。
所需 PortPrototype 的通信属性。 此类将包含对各种需求端口有效的属性，独立于客户端-服务器或发送方-接收方通信模式。
PortInterface 与 ComSpec
表 4.59 中记录了特定类型的 PortInterface 和一种 ComSpec 的允许组合。
如第 2.5 节所述，在某些情况下 CompositionSwComponentType 拥有的 PortPrototypes 可能具有 initValues。
因此，CompositionSwComponentTypes 拥有的 PortPrototypes 可能具有 ComSpecs。 不需要在组合级别定义的 ComSpecs 与在 CompositionSwComponentType 内定义的 ComSpecs 匹配。
如果需要一致性，则此约束可能是将现有 AtomicSwComponentTypes 集成到具有 PortPrototypes 和 ComSpecs 的 CompositionSwComponentType 的主要障碍。
4.5.1 发送方-接收方通信的通信规范
通信规范以不同的方式适用于特定类型的通信。 图 4.31 显示了 RPortPrototype 上与发送方-接收方通信相关的通信属性的元模型。
PRPortPrototype 上下文中重复存在 initValue
如果在 PRPortPrototype 拥有的 NonqueuedReceiverComSpec 中定义了 initValue，则应忽略其值。
图 4.31：RPortPrototype 与 senderreceiver 通信相关的通信属性。
用于队列和非队列发送者-接收者通信的 ComSpec
发送方-接收方通信可能是队列或非队列。 这方面主要体现在 dataElement.swDataDefProps.swImplPolicy 的值上。 如果该属性的值设置为队列，则应定义 QueuedSenderComSpec 和/或 QueuedReceiverComSpec。 在所有其他适用情况下 NonqueuedSenderComSpec resp。 应使用 NonqueuedReceiverComSpec。因此，约束 [constr_1129]、[constr_1130]、[constr_1131] 和 [constr_1132] 应适用。
在队列通信的情况下，queueLength 属性仍然是唯一的信息项，而在非队列的情况下，它预见了几个用于控制通信行为的属性。
特定于接收器的通信属性（由 SenderReceiverInterface 输入的 RPortPrototype）。
特定于非队列接收的通信属性。
特定于队列接收的通信属性。
处理接收超时违规的策略。
这个是对于时间数值原语的解释
这部分主要是看了一部分发送器-接收器通信的一些通信详细要求，但是并不是全部的部分。在工具设计上，还有一些具体的限制条件需要考虑，这部分放在后面找时间继续做相应的梳理。
