☞返回总目录
相关总结：典型的 SOME/IP 多绑定用例总结
7.3.3 典型的SOME/IP多绑定用例
在前面的章节中，我们简要提到，在一个典型的SOME/IP 网络协议的部署场景中，AP SWC不太可能自己打开套接字连接来与远程服务通信。为什么不太可能呢？因为SOME/IP被明确设计为尽可能少的使用端口。这种需求的原因来自于低功耗/低资源的嵌入式 ECU：并行管理大量的IP套接字意味着在内存资源方面的巨大成本。
因此，与非汽车IT 对端口的使用模式相比，通信伙伴主要是AUTOSAR CP的车内网络以某种方式要求这种方法，这是不常见的。
通常，这种需求导致了一种架构，其中一个 ECU(网络端点)的所有SOME/IP 流量通过一个IP端口进行路由！这意味着，不同本地应用程序（服务提供者或服务消费者）的SOME/IP消息使用一个套接字连接进行复用。
在经典的 AUTOSAR（CP）中，这是一个直观的概念（比如：RTE），因为已经有一个共享的通信栈，整个通信都通过它进行。通过一个套接字对不同的上层PDU进行复用是集成在CP的SoAd基本软件模块中的核心功能。对于一个具有POSIX套接字API的POSIX兼容操作系统，许多应用程序的 SOME/IP通信复用一个端口意味着引入一个中央守护进程，该进程管理相应的端口。这个进程的任务是在 SOME/IP网络通信和本地通信之间架起桥梁，反之亦然。
从上图可以看出，ara::com应用程序中的服务代理通过（绿色线条）一个SOME/IP桥与远程服务实例2进行通信。在这个图中有两点可能会引起注意：
-
将从
应用程序到桥的通信路径（绿色）与从桥到服务实例2的通信路径（蓝色）用不同的颜色表示。 -
在
服务发现和SOME/IP桥的功能块周围画了一个框。
使用不同颜色表示的原因很简单：两部分使用不同的传输机制。第一部分（绿色）在代理和SOME/IP桥之间使用供应商特定的实现，第二部分（蓝色）必须符合SOME/IP规范。供应商特定在这里意味着，供应商不仅决定他使用哪种技术（管道、套接字、共享内存等），还决定他在该路径上使用哪种序列化格式（见 7.1 节）。在这里，显然进入了优化的领域：在一个优化的 AP产品中，供应商不会为用绿色线条表示的通信路径使用不同的序列化格式, 否则会导致低效。首先，服务消费者中的服务代理在将数据传输到桥节点之前会对数据进行专有的序列化，然后SOME/IP桥必须对其进行反序列化并重新序列化为SOME/IP序列化格式！所以，即使AP产品供应商对于本地通信有一个更精细的序列化方法，使用它也没有好处，因为SOME/IP桥就无法在内部和外部之间简单地复制数据。对于示例场景，我们最终使用一个多绑定设置，即使与本地ara::com应用程序和SOME/IP桥节点通信的技术传输（管道、Unix 域套接字、共享内存等）是相同的，绑定的序列化部分也不同。
关于图中的第二点：我们在服务发现和 SOME/IP桥功能周围画了一个框，因为在产品实现中，很可能它被集成到一个组件中 (在一个守护进程）中运行。这两个功能高度相关：注册表（服务发现）部分也由 ECU本地部分（接收本地注册,并为本地FindService请求提供服务）和网络相关功能（基于SOME/IP服务发现的提供/查找）组成，其中注册表必须进行仲裁。这种仲裁在其核心也是一种桥接功能。
