SommRがやってくる

この（ごく短い）シリーズの第1部では、ソフトウェアデファインドビークル（SDV）の文脈におけるコミュニケーションのセマンティクスとシンタックス、そしてこれら二つの意味について、その水に足を浸してみました。潜在的な解決策の選択肢が膨大かつ拡大し続ける世界において、実際の製品を構築する際の課題について、暫定的な考察を行いました。同時に、車両製品範囲内のエンジニアリング文化にも同様に多様な側面が存在することを併せて検討しました。最後に、Eclipse uProtocolプロジェクトがこの文脈でどのように価値を提供しようとしているのかを見て、まとめました。

さて、uProtocolのビジョンにおける成功要因について、もう少し詳しく検討してみましょう。いくつかの好条件が予想通り整った場合に今年起こりうる展望を踏まえつつ、一つの可能性をさらに掘り下げていきます。

uProtocol自体は、自動車業界のあらゆる通信問題を包括的に解決する万能ソリューションではない。むしろ、現代の車両-クラウド-アプリケーションシナリオに関わる技術的に多様な領域間でサービス間通信を可能にするための接着剤と共通概念を提供する「メタミドルウェア」と呼ぶべきものである。

このようなソフトウェア基盤が真に成功するには、多くの要素が組み合わさる必要がある。最初の記事で示唆した通り、その大半は技術的な性質のものではない。本稿の議論の背景として、成功の幾つかの次元を定義しておこう。

技術的成功とは、あるものが特定の技術的問題を解決し、その解決が十分に優れているため、特定のシナリオにおいて関連する技術的KPIによって計測される目的適合性があると見なされる軸である。

成熟度の成功とは、純粋なコードを超えた「非技術的」要件を満たすことにある：開発コミュニティの目標とマインドセットは、本番環境対応ソフトウェアを構築・維持することにあるのか？その結果、品質プロセス遵守指標に関連し貢献する非コード成果物の創出と進化がもたらされるのか？

採用成功は本質的にプロジェクトの付加価値増幅器であり、問われるのは「このコードは複数の組織によって生産的に利用されているか？」という点である。この属性には実際には第二の、より暗黙的でありながらも依然として非常に望ましい効果がある：コードベースのあらゆる積極的な採用者と貢献者は定義上「仕組みを理解している」ため、同じ語彙で会話できるのだ。これは商業的協業において極めて有益であり、関係者は概念的・技術的な調整を省略し、業務の価値創造段階に直ちに移行できる。

エコシステムの成功は 、上記の要素すべてが調和し、中核技術が拡張性を可能にし、あらゆる種類の貢献を促すときに実現します 。成功したエコシステムでは、参加者が中核要素の採用成功を活用して自らの拡張や貢献（オープンモデルと商用モデルの両方）を行うことが可能になります。特定の課題領域を解決するための極めて成功したツールボックスを構築できる。成功事例として、Kubernetes（k8s）のコアコンセプト（および実装）を中心に発展したCloud Native Computing Foundationのエコシステムが挙げられる。

uProtocolがk8sほどの規模に成長するとは（嬉しい驚きではあるが）思えないものの、この小規模なプロジェクトにおいても上記の成功ステップを想定し、その道筋を助ける可能性のあるアイデアについて議論することは可能です。

uProtocolが自動車用サービスメッシュとして有用であるためには、自動車用プロトコル、すなわちメカトロニクス領域の車両向け通信ネットワークに接続する必要がある。ここで通常、事態は複雑化する。その理由は別の記事で扱うほど多岐にわたる。したがって本稿では、現時点での実装の可用性は不可能であるものの¹、概念的・エコシステムレベルで有用なシナリオを描き出す^。

上記のテーマに沿い、uProtocolが組み込み自動車用分野へ進出する第一歩として、両端のパブリッシュ/サブスクライブ（pub/sub）ネットワークを連携させるのが有効である。自動車用側では、関連する候補プロトコルとしてAUTOSAR® SOME/IPが挙げられる。これは自動車ネットワークインフラ上で動作するpub/sub方式通信の仕様である。SOME/IP uPClientの実装を作成することで、SOME/IPネットワークセグメントをより大規模なuProtocolサービスメッシュの一部とすることができます。これにより、前述のユースケースを実現可能となります。具体的には、実車SOME/IPネットワーク²内のエンティティが速度データグラムをパブリッシュし、その後uProtocolメカニズムを介してネットワーク/プロトコルインフラストラクチャの他のセグメントへルーティングされるというものです。

このアイデアにおける主な課題は、再び技術的ではない点にあります：SOME/IPはAUTOSAR®仕様であるため、現行バージョンにおけるオープンソース実装はAUTOSAR IPライセンス³によって禁止されており、したがってオープンソースプロジェクト内でuProtocol-SOME/IP接続の実装は存在し得ません。

現時点で、Eclipse SDVワーキンググループではSommRの登場を待っています。SommRはRust言語によるSOME/IPのゼロからの実装であり、uProtocolブリッジ構築に最適な基盤となるでしょう。2022年半ばのプロジェクト発表以来、プロジェクト貢献者はAUTOSAR® IPポリシーに関する認可取得に向けて取り組んでおり、現時点ではまだ実現には至っていないものの、今年中に前向きな結果が得られる可能性が高い。

SommRが実装されれば、uPClientがこれに連携するようになるため、SOME/IPをuProtocolサービスメッシュに統合できるようになります。これにより、前述のコンパニオンアプリシナリオや、SOME/IP制御装置を含む類似の構成を構築可能となります。オープンソースと従来型自動車用の世界を繋ぐ最初の架け橋となることを期待しています。

この文脈でさらに興味深い点として、SommRとuProtocolの両プロジェクトは、自動車用製品で使用可能な実運用準備完了コードの提供と維持を目的としています。詳細や範囲は現在も進化中ですが、プロセス定義（Eclipse Foundation Development Process経由）、プロジェクト要件仕様書、ドキュメント、テストカバレッジおよび関連KPIなど、重要な事項が相当程度カバーされることは確実です。これらのプロジェクトは、（同様に開発途上にある）Eclipse SDV品質/成熟度プログラムの早期採用者となる可能性が高い。同プログラムは、このソフトウェアが商用自動車用製品エンジニアリングプロセスで使用されるための基盤を提供することを目的としている。

要約すると、Eclipse uProtocolおよび今後のEclipse SommRプロジェクトは、Open Source Softwareが自動車用ソフトウェアインフラ構築の重要な推進力となり得ることを示す実証事例となり得る。この実証事例には以下が含まれる：

確立された自動車用領域技術とITスタイルのネットワークスタックのシームレスな統合により、より大きな全体を構築する。

オープン開発モデルとオープンソース財団が、自動車用バリューチェーンにおけるパートナー間の第一階層で低オーバーヘッドな協業を可能にする実践例

オープンソースプロジェクトが自動車用グレードのソフトウェア品質をいかに提供できるかのインキュベーター兼実証の場であり、ひいてはその実態が何を意味するのかについての示唆すら与えるかもしれない...

ここで述べた内容に該当すると思われる場合は、Eclipse SDV Slackスペース、uProtocolプロジェクトミーティング、メーリングリスト、またはコミュニティイベントのいずれかにぜひご参加ください（参加方法の詳細については、こちらのEclipse SDV情報ページをご参照ください）。

¹: ただし、記事の最後のセクションを参照のこと。

²: いいえ、uProtocolメッシュは、高スループット・最低遅延のリアルタイム通信向けに最適化された専用ソリューションに取って代わるものではありません。はい、それでもなお顧客が関連性があると期待する多くのユースケースシナリオが残ります（実際、それらは通常顧客にとってはるかに目に見えるものです）。いいえ、uProtocol全体としては、自動車用安全認証を議論する上で有用な対象とはならない可能性が高いです。ただし、サブパーツや専用アダプターは十分に有用となる可能性があります。

³: vsomeipプロジェクトについては承知しております。しかし、既存のAUTOSAR®仕様のオープン実装に関する議論が続いている状況下では、当プロジェクトの立場について確信が持てません。