索姆瑞即将到来
uProtocol迈入车载嵌入式领域的首步
在本系列（篇幅极短）的第一部分，我们初步涉足了通信语义与语法领域，并探讨了这两者在软件定义车辆（SDV）语境中的潜在意义。我们初步探讨了在当前环境下构建实际产品的挑战——潜在解决方案的格局庞大且持续扩张，同时车辆产品范畴内的工程文化同样呈现出多样性。最后我们以Eclipse uProtocol项目为例，阐述了该项目如何在此背景下创造价值。
现在，我们将花更多时间探讨uProtocol愿景的成功要素。我们将深入挖掘一个机遇，展望若今年若干关键因素如期汇聚，可能实现的进展。
uProtocol成功要素
uProtocol本身并非解决整个汽车领域通信问题的万能方案。与其说它是万能解决方案，不如称其为"元中间件"——通过提供粘合剂和通用概念，使现代车-云-应用场景中技术各异的领域能够实现服务间通信。
对于此类软件基础设施而言，唯有多方协同方能取得真正成功。正如我们在首篇文章中提及的，其中多数因素并非技术层面的考量。让我们先界定几个成功维度，作为后续讨论的背景框架。
技术成功是指某项技术在解决特定技术问题时，其表现足够出色，足以被视为符合目的——该判断依据特定场景中相关技术关键绩效指标（KPI）进行评估。
成熟度的成功在于满足超越纯代码的"非技术性"要求：开发社区的目标和思维方式是否致力于构建并维护可投入生产环境的软件？这是否促成了与质量流程遵循度指标相关且能为其增色的非代码成果的创建与演进？
采用成功本质上是项目的增值倍增器，其核心问题在于："该代码是否被多个组织高效利用？"这一属性还具有另一种隐性但同样重要的效应：每个活跃的代码库采用者和贡献者都必然理解"事物运作机制"，他们使用相同的术语体系。这对任何商业合作都是重大利好，参与方可跳过概念与技术层面的协调工作，直接进入价值创造环节。
生态系统的成功源于 上述所有因素的协同作用，其核心技术需具备可扩展性并鼓励各类贡献。成功的生态系统能让参与者借助核心组件的采用成功，推动自身扩展与贡献——无论采用开源还是商业模式。生态系统能打造出解决特定领域问题的卓越工具箱——以极具代表性的成功案例而言，不妨对比围绕Kubernetes（k8s）核心理念（及实现方案）发展起来的云原生计算基金会（CNCF）生态系统。
虽然看到uProtocol发展到k8s的规模会让我（欣喜地）感到意外，但我们仍可为这个规模较小的项目规划上述成功路径，并探讨有助于实现该目标的构想。
uProtocol 概念
为阐释uProtocol概念，让我们设想这样一个用例：某智能手机伴侣应用请求特定车辆的速度信息，由此触发的速度数据报订阅请求将从应用出发，经由一系列后端服务，最终抵达目标车辆，并在车内传递至能够提供该数据点的域控制器单元。 订阅端点处理请求后，将速度信息发布至其"网络邻域"。uProtocol服务网格随即捕获该信息并沿整个链路转发，最终使伴侣应用得以显示（近乎）实时的车辆速度。
uProtocol定义了若干组件来实现这一目标：
- uPClient 实现将通用 uProtocol 的子/子和命令和响应消息适配到特定传输协议。例如，可以存在一个针对 MQTT 协议的 Rust 实现的 uPClient。
- uStreamer能够在不同的传输协议域之间路由消息（发布/订阅数据、命令/响应消息）。为此，uStreamer至少连接两个uPClient，并追踪哪些消息需要从一个域传递到另一个域。
- uSubscription服务管理跨域订阅——例如，当两个不同的发布/订阅网络构成更大解决方案时，这些网络中的uSubscription组件会追踪并转发来自一个网络客户端的订阅请求，这些请求针对的是最初在另一个网络中发布的消息。
还有更多细节和若干组件——例如uTwins，它可用于域内或域集（如整辆车）的数据缓存/缓冲/存储——但本文将聚焦于核心构建模块。
这种内置扩展点的组件架构展现了生态系统构建的核心要素：它既定义了核心编程模型（API与语义），又深刻认识到唯有通过社区的广泛采用与工具箱的持续扩充，才能真正实现最初的愿景。随着每个采用者为工具箱增添新组件，uProtocol的实用价值将呈指数级增长。例如，新增单个uPClient适配器便能提升所有uProtocol组件的价值——因为它将所有组件的应用场景拓展至全新环境。
嵌入式连接
要使uProtocol作为汽车服务网格发挥作用，它需要连接到汽车协议，即机电域的车载通信网络。这通常是事情变得复杂的地方，其原因足以单独写成一篇文章。因此本文将描绘一个在概念层面和生态系统层面都具有实用价值的场景——尽管在撰写本文时，实际实现方案尚无法公开发布¹。
基于上述主题，uProtocol迈向嵌入式汽车领域的良好第一步，是将两端光谱的发布/订阅网络连接起来。在汽车领域，一个相关的候选协议是AUTOSAR® SOME/IP——这是在汽车网络基础设施之上构建发布/订阅式通信的规范。通过创建SOME/IP uPClient实现，可将SOME/IP网络分段纳入更广泛的uProtocol服务网格。这将实现前述示例用例：车载SOME/IP网络2内的实体发布速度数据报，随后通过uProtocol机制将其路由至网络/协议基础设施的其他分段。
该方案的主要挑战仍在于非技术层面：SOME/IP属于AUTOSAR®规范，这意味着根据AUTOSAR IP许可协议3，当前规范版本的开源实现是被禁止的，因此无法在开源项目中实现uProtocol-SOME/IP连接。
对SommR的期许
目前，Eclipse SDV工作组正在等待SommR的到来。SommR是基于Rust语言从零实现的SOME/IP协议，它将成为构建uProtocol桥接方案的理想选择。自2022年中项目启动以来，项目贡献者一直在努力获得AUTOSAR®知识产权政策的许可。虽然目前尚未取得成果，但今年内有望获得积极进展。
一旦SommR就位，我们将看到uPClient与其建立连接，从而实现SOME/IP在uProtocol服务网格中的集成。这将使我们能够构建上述伴侣应用场景，以及包含SOME/IP控制单元的类似配置。我们有望由此在开源世界与传统汽车领域之间架起首座桥梁。
在此背景下还有一点值得关注：SommR和uProtocol项目均致力于交付并维护可用于汽车产品的生产就绪代码。具体实施细节与覆盖范围仍在演进中，但可以肯定的是，这些项目将全面涵盖流程定义（通过Eclipse基金会开发流程实现）、项目需求规格说明、文档编制、测试覆盖率及相关关键绩效指标等核心要素。这些项目很可能成为（同样仍在发展的）Eclipse SDV质量/成熟度计划的早期采用者，该计划旨在为该软件应用于商业汽车产品工程流程奠定基础。
外卖
简而言之，Eclipse uProtocol 及即将推出的 Eclipse SommR 项目可成为开源技术如何成为构建汽车软件基础设施关键推动力的典范。该典范将涵盖：
将成熟的汽车领域技术与IT风格的网络堆栈无缝集成，构建更宏大的整体。
一个实践案例，展示开放式开发模式与开源基金会如何在汽车价值链中实现合作伙伴间高效协作，且无需高昂成本。
一个孵化器和试验场，用于探索开源项目如何提供汽车级软件质量，从而或许能揭示这种质量标准的实质内涵...
若您对本文提及的任何内容感兴趣，我们诚挚邀请您加入Eclipse SDV Slack频道、参与uProtocol项目会议、订阅邮件列表，或参加我们的社区活动（具体参与方式请参阅此Eclipse SDV信息页）。
跨越边界的协作是摆脱常规零和企业博弈的最佳出路。
1: 但请参阅文章的最后一段。
2: 不，uProtocol网格无法替代那些针对高吞吐量、最低延迟实时通信进行优化的专用解决方案。是的，这仍然存在许多客户相关且期望的应用场景（事实上这些场景通常更易被客户察觉）。不，uProtocol整体可能不适合作为讨论汽车安全认证的有效对象——尽管其子组件和专用适配器完全可能适用。
3: 我们知晓vsomeip项目。但鉴于当前围绕现有AUTOSAR®规范的任何开放式实现所引发的争议，我们尚未明确自身在此项目中的立场。
联系我们
您有任何问题吗？请随时给我们留言。我们将非常乐意提供帮助。
现在就联系我们！