SOME/IP 部署中 AP SWC 不自行打开套接字连接的原因
在典型的 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 桥之间采用供应商特定实现，供应商不仅决定使用哪种技术（如管道、套接字、共享内存等），还决定该路径上使用哪种序列化格式（见 7.1 节）。这里涉及优化问题，在优化的 AP 产品中，若为绿色线条表示的通信路径使用不同序列化格式会导致低效，因为服务消费者中的服务代理传输数据时会先专有序列化，SOME/IP 桥要反序列化再重新序列化为 SOME/IP 序列化格式，即便有更精细的本地通信序列化方法也无益处，因为 SOME/IP 桥无法简单复制数据。 - 服务发现和 SOME/IP 桥功能框画框原因：
在服务发现和 SOME/IP 桥功能块周围画了一个框，是因为在产品实现中，它们很可能被集成到一个组件（在一个守护进程）中运行，这两个功能高度相关。注册表（服务发现）部分由 ECU 本地部分（接收本地注册，为本地 FindService 请求提供服务）和网络相关功能（基于 SOME/IP 服务发现的提供 / 查找）组成，且注册表必须进行仲裁，这种仲裁从核心上来说也是一种桥接功能。
总之，对于示例场景，最终会使用一个多绑定设置，即便本地 ara::com 应用程序和 SOME/IP 桥节点通信的技术传输方式相同，但绑定的序列化部分是不同的。
