AUTOSAR_TPS_SoftwareComponentTemplate53_兼容性1
Grey
全部学习汇总： GitHub - GreyZhang/hack_autosar: learning autosar documents, aha, very hard!
AUTOSAR_TPS_SoftwareComponentTemplate53_兼容性1
- 解决SWC与端口的链接问题。
- 设计以及实施是否可以映射。
- 兼容性设计师自上而下的，线考虑兼容AUTOSAR的类型，然后再考虑兼容其派生类型。
- AUTOSAR中的元类型，在使用中引用的属性需要考虑与它的兼容性。不同层级模型设计的时候，也要考虑下一层模型设计的时候实例化上层信息时候可能出现的兼容性问题。
- 应用原数据类型的兼容性，这里给出了具体的规则。我觉得，这种规则嵌入式设计的人员没有必要去熟练理解，毕竟这个算是最终的工具检查功能。
- record与array类一般不兼容，除非特殊的说明存在。下面给出的两个约束条件其实是做了进一步的解释说明。
- 对于实施数据类型的兼容性，这部分开始涉及到RTE了。
- 软件基础类型的兼容性，需要考虑：大小、字节排序、编码、本地声明、存储对齐等方面。
- 软件数据定义属性的兼容性。
- 关于单位的兼容性，要么是本身就是兼容的，那么是通过一个中间的转换缓冲可以做到兼容。另外，给出了一些具体的实施限制，这些最终工具解析的时候应该会有所实现。
- 物理维度上的兼容性，感觉上这个是不是跟单位也有一定的相关度只是更加具体了一些？
- 约束的兼容性其实很好理解，为什么会有上下文呢？肯定约束是有一个越来越窄或者不变的过程，不能够约束不住。而另种兼容的模式是则是大家都没有约束的时候。
- 实施数据类型的兼容性。
- 这里的兼容性的最终评判决定点，似乎很多时候又是走到了RTE上，我改找机会接触下这个配置工具啊！
- 运算方法的兼容性。
- 这部分比较繁琐，直接做一个猜测吧。从一般的设计理念或者思考思路上来说，应该在单位、物理维度等层面有一定的转换的可能性，这个应该就有兼容的方法。但是，是否能够百分百利用现成的信息转换，这个需要看是否所有的转换规则都考虑到位了。
- 存储布局的兼容性，这个相对来说容易理解，必须百分百表达相同的含义，但是可以有不同的计算方式。
这部分主要是看了兼容性的概述以及数据类型的兼容性，而在数据类型兼容性方面又着重看了应用数据类型、实施数据类型、软件基础类型以及软件数据定义属性等几个不同的方面，还剩下一部分关于数据类型兼容性的梳理，后续专门找时间补充阅读一下。
