全部学习汇总： GitHub - GreyZhang/hack_autosar: learning autosar documents, aha, very hard!
继续学习AUTOSAR，看一下官方文档。最近的几次文档学习，都太偏向于软件工具的设计，看得有一些糊涂。相比之下，我现在倒是感觉出来了嵌入式的有意思之处。最起码，嵌入式的很多工作面向的是一个真实的现实世界，这样我们的思考模型其实是很容易建立的。相比之下，我现在看得内容就难理解多了。
4.3.1.4 触发接口元素映射
TriggerInterfaceMapping 定义了在上下文 TriggerInterfaces 中定义的 Triggers 的相关性。
在两个不同的 TriggerInterfaces 的上下文中定义不相等的命名触发器的映射。
定义给定上下文中两个特定名称不同的触发器的映射。
图 4.15：TriggerInterface 元素的映射
4.3.1.5 复合数据类型元素的映射
PortInterfaces 元素的映射不限于将整个 DataPrototype 相互映射。
复合数据类型元素的映射
对于 DataInterfaces 的应用程序，也可以形式化地描述 ApplicationCompositeDataTypes 或 ImplementationDataTypes 类别 STRUCTURE 或 ARRAY 的元素相互之间的映射。
如果例如发送方和接收方的数据元素由不同的 ApplicationRecordDataType 类型化可以使用此能力。
在这种情况下，ApplicationCompositeDataTypes 或ImplementationDataTypes 类别STRUCTURE 或ARRAY 的元素相互映射允许定义满足兼容性规则的特定元素对。
发送方元素到接收方元素的映射
除非属性 swImplPolicy 设置为 queued，否则不需要将发送方的所有元素都映射到接收方的元素以实现兼容性。
有关兼容性规则的详细信息在第 6.3 章中说明。
ApplicationCompositeDataTypes 或 ImplementationDataTypes 的未映射元素和属性 swImplPolicy
如果属性 swImplPolicy 设置为队列，则不允许在接收方侧具有类别为 STRUCTURE 或 ARRAY 的 ApplicationCompositeDataTypes 或 ImplementationDataTypes 的未映射元素。
接收方未映射的数据元素应具有 initValue
如果在 SubElementMapping 中不考虑 ApplicationCompositeDataTypes 或类别 STRUCTURE 或 ARRAY 的 ImplementationDataTypes 的元素，则如果 NonqueuedReceiverComSpec 由 AbstractRequiredPortPrototype 聚合，则封闭的 dataElement 应具有 initValue。
图 4.16：复合数据类型元素的映射
ApplicationCompositeDataType 和嵌套的 ImplementationDataType 的组合
ApplicationCompositeDataTypes 或 ImplementationDataTypes 类别的 STRUCTURE 或 ARRAY 元素的映射适用于 ApplicationCompositeDataType 和嵌套的 ImplementationDataTypes，甚至适用于它们的组合，即一个 PortInterface 可以使用 ApplicationCompositeDataType 而另一个 PortInterface 使用嵌套的 ImplementationDataType。
复合元素到原始数据原型的映射
还可以将提供端的复合数据类型的元素映射到所需端的原始 DataPrototype。 为此，firstElement 的多重性应设置为 1，而 secondElement 的多重性应设置为 0。
一般来说，firstElement 的多重性在技术上也可以设置为 0，但这种情况保留供将来使用。
只有一种从复合到原始用例的映射
在 [TPS_SWCT_01195] 描述的情况下，在封闭的 DataPrototypeMapping 中应仅存在一个 subElementMapping。
提供方的原始数据原型不应映射到请求方的复合数据类型的元素
DataPrototypeMapping 的用法。 SubElementMapping 不支持以下配置：
• 在提供者/客户端引用的 AutosarDataPrototype 由类别 VALUE 的 ApplicationPrimitiveDataType 或类别 VALUE 或类别 TYPE_REFERENCE 的 ImplementationDataType 键入，最终解析为类别 VALUE。
• DataPrototypeMapping 聚合了一个subElementMapping，它引用了请求者/服务器端的ImplementationDataTypeElement 或ApplicationCompositeElementDataPrototype。
这个元类允许定义复合数据类型元素的映射。
这个元类提供了引用复合数据类型元素的能力。
这个元类代表 SubElementMapping 相对于 ImplementationDataType 的特殊化。
这个元类代表了 SubElementMapping 相对于 ApplicationCompositeDataTypes 的特殊化。
图 4.17：InstanceRef 的实现，用于映射复合应用程序数据类型的元素
ApplicationCompositeElementInPortInterfaceInstanceRef 上下文中 rootDataPrototype 和 base 的一致性
ApplicationCompositeElementInPortInterfaceInstanceRef 引用的 rootDataPrototype 应归角色库中引用的 DataInterface 的适用子类所有。 这意味着如果Base是一个 ParameterInterface，那么 rootDataPrototype 应该是一个 ParameterDataPrototype。 否则 rootDataPrototype 应该是一个 VariableDataPrototype。
ApplicationCompositeElementInPortInterfaceInstanceRef 上下文中数据类型的一致性
属性 contextDataPrototype 和 targetDataPrototype 的定义应（通过类型原型模式）包含在用于类型 rootDataPrototype 的数据类型定义的上下文中。
换句话说，应该可以通过用于类型 rootDataPrototype 的数据类型的定义创建的类型原型链到达 contextDataPrototype 和 targetDataPrototype。 并且，正如 InstanceRef 的定义所暗示的那样，contextDataPrototypes 应相互封闭，并最终封闭 targetDataPrototype。
图 4.18： InstanceRef 的实现，用于映射复合实现数据类型的元素
ArVariableInImplementationDataInstanceRef 上下文中数据类型的一致性
属性contextDataPrototype 和targetDataPrototype 的定义应包含在用于类型rootDataPrototype 的数据类型定义的上下文中。
这一次的梳理暂且到此结束，这一次主要是看了端口映射中剩余的部分。从下一次的梳理，我将开始看一下数据转换的部分。
