☞返回总目录
相关总结：AutoSar AP CM中的序列化总结
7.1 序列化
Serialization（见 [11]）是将特定数据结构转换为标准化格式的过程，以便在发送方和接收方之间进行交换。如果要将数据从一个网络节点传输到另一个网络节点，通常会使用这个概念。当将数据放到网络上并读取回来时，必须遵循确切的、商定好的规则，才能在接收方正确解释数据。对于网络通信用例来说，需要一种定义好的方法将进程内的数据表示转换为网络格式并再转换回来，这一点非常明显：进行通信的模块可能基于具有不同字节序和不同数据字大小（16 位、32 位、64 位）的不同微控制器，因此采用完全不同的对齐方式。
在 AUTOSAR CP 中，Serialization 在节点内部通信中不起作用，内部内存数据表示可以直接从发送方复制到接收方。这是因为在典型的 CP 产品中做了三个假设：
- 所有本地软件组件（SWC）的字节序相同。
- 所有本地 SWC 中某些数据结构的对齐方式是一致的。
- 交换的数据结构在内存中是连续的。
第一点可能有点特殊，因为通常情况下，“内部” 通信一般意味着在单核或多核微控制器甚至多处理器系统上进行通信，在这些系统中，字节序在任何地方都是相同的。只有当我们考虑由不同微控制器系列的 CPU 组成的系统时，这个假设才可能无效，但那时你已经在讨论这种通信在典型意义上是否仍然是 “内部” 通信了。
对于 CP，第二个假设是有效的，因为在这里，整个单地址空间系统的静态映像由源文件或目标文件构建而成，这就要求映像的不同部分之间的编译器设置无论如何都要在某种程度上保持一致。
第三个假设在 CP 中也得到了保证。不允许在软件组件（SWC）间通信中使用的非连续数据类型进行建模。
对于 AP，情况确实不同。在这里，在运行时加载可执行文件（这些可执行文件在不同时间独立构建的，在不同时间上传到 AP ECU）绝对是一个受支持的用例。然而，不同的 ara::com 应用程序的编译器设置在对齐决策方面不同的可能性很高。因此，AP 产品（更具体地，是其 IPC 绑定实现）必须支持交换的事件 / 字段 / 方法数据的序列化。AP 内部 IPC 的序列化如何完成（即转换为哪种通用格式）完全由 AP 供应商决定。关于第三点，AP 的限制较少。例如，AP 支持交换 std::map 数据类型或可变长度成员的类似记录的数据类型。这些数据类型在内存中通常不是连续的（取决于分配策略）。因此，即使地图或记录中的数据在布局上与接收方兼容，在传输过程中也必须进行深拷贝（意味着从不同的内存区域收集包含的元素及其引用 —— 见 [12]）。当然，产品供应商可以应用优化策略来消除通信路径中的序列化和反序列化阶段：
- 关于对齐问题，最简单的方法可能是允许系统的集成商进行配置，使得对于某些通信关系，对齐可以被认为是兼容的（因为他拥有关于所涉及组件的必要知识）。
- 中间件技术中常见的另一种方法是在首次进行 ara::com 通信调用之前，通过交换一种检查模式作为一种初始化序列来验证双方的对齐设置是否相等。
- 可以通过提供关心连续性的向量实现来避免由于非连续内存分配而需要深拷贝的问题。
7.1.1 零拷贝影响
在 IPC / 中间件实现中，通常性能优化的首要任务之一是避免在数据的发送方和接收方之间进行不必要的复制。因此，“零拷贝” 这个流行语被广泛用来描述这种模式。当我们谈论 AP 时，我们有对单独进程中运行的应用程序提供内存保护这样的架构期望，典型的通信方法需要从源地址空间到目标地址空间进行至少一次的数据复制。高度优化的 IPC / 中间件实现甚至可以通过在通信的 ara::com 组件之间设置共享内存区域来消除这一单一复制步骤。如果你看 5.19，你会看到，我们在 API 设计中直接鼓励这种实现方法。但是，如果产品供应商不解决序列化问题，他无法从共享内存方法中受益：如果在通信伙伴之间必须进行转换（也就是序列化 / 反序列化），那么无论如何都必须进行复制 —— 所以旨在实现 “零拷贝” 的复杂共享内存方法就实现不出。