04/09/2024
Eclipse uProtocol
コミュニケーションには、生き物が行うか機械が行うかに関わらず、「メッセージ」と「媒体」という2つの重要な要素が伴います。この要素を非常に大まかに例えると「セマンティクス」と「シンタックス」になります。
メッセージ（セマンティクス）は、コミュニケーションの内容に関係します。当事者が同じ用語や概念について同じ認識を持っていれば対話が成立します。音声、テキスト、手話、モールス信号など、どれを使うかは自由です。これがコンテンツです。
媒体（シンタックス）は、必要な情報を伝える方法に関係します。使用するメカニズムに同意して処理できれば、コミュニケーションの当事者間で、一連の記号（「メッセージ」）をやりとりできます。これがプラミング（ネットワーキング）です 1。
技術システムにおいては、通常、メッセージ（セマンティクス）をどの程度調整できるかによってアセットの拡張性が決まります。メッセージの内容が明確に定義されている限り、通信する当事者の数を増やす、時間の経過によるプラミングを変更するなどの対応が可能です。このようなシステムではコンポーネントレベルで入れ替え可能であり、個々に進化させることができます。これによってビジネスロジックの安定性を実現でき、ドメイン固有の製品の市場規模（エコシステム）が拡大します。
ソフトウェアシステムではプラミングが非常に重要であり、かつ驚くほど柔軟性に富んでいます。プラミングが機能しなければ、データは流れていきません。プラミングが多く存在すれば、物事は継続的に変化・進化します。ソフトウェア開発分野では、様々なプラミングの適応と統合に多くの時間を要し、新しいミドルウェアが次々と所構わず現れているような印象を受けます2。
ここからは、プラミングについて詳しく説明します。コンテンツを標準化するためのオープンコミュニティの取り組み、特に、COVESAのVehicle Signal Specification（VSS）プロジェクトとVehicle Service Definition（uService）プロジェクトを詳しく取り上げます。Eclipse FoundationのSDVワーキンググループが進めている各種の作業に関わるのはもちろんのこと、これらのプロジェクトグループでは、「コミュニティ主導の共同開発製品を誕生させる」という目標に誠実に取り組んでいます。
SDVの現状
この試みは、車両システムとソフトウェアデファインドビークル（SDV）アーキテクチャのコンテンツにも当てはまります。SDVスタイルのシステムは、まったく異なる当事者間の通信で構成されます。一方の端には、ブレーキを踏むと車両にブレーキがかかるように車両に深く組み込まれたマイクロコントローラを使うメカトロニクス領域があります。もう一方の端には、車両の機能の遠隔制御、ドライバープロファイルの管理などに使用されるユーザー向けのクラウドサービスやモバイルアプリケーションがあります。
この両端にある技術はエンジニアリング手法が多様であるがために、使用されるプラミングについても、同様の広範な要件を必要とします。リアルタイムで遅延が最小限の車載CAN通信ラインと、クラウドからアプリケーションへのプロトコルスタックとでは要件が大きく異なります。これら2つは開発文化や周囲の組織も大きく異なるため、様々なグレーゾーンが存在します。
要するに、SDVにおけるプラミングの複雑さは、技術レベルだけの問題ではないのです。
SDVに関連する技術は大きな進化を遂げ、技術要件を満たす独自のソリューションが構築されてきました。物理プロトコルや通信プロトコルには様々な種類のものが存在し、IoTがメッセージングと通信インフラを担い、クラウドが過去10～20 年の間にその進化を支えてきました3。しかし、今や最先端のクルマやそれをサポートするITシステムは、その存在意義を示す必要に迫られています。とりわけ持続的な価値を提供することが重要です4。
ユーザーからの新しい要望やテクノロジーの進化に対応する一般的な方法としては、新たな課題を解決する「新しいもの」を発明することです。すべての当事者に関連しそうなすべてのニーズを丹念に収集して、ニーズ対応した「標準」を構築することもひとつの方法でしょう5。このアプローチが効果的な場合もありますが、ソリューション環境が拡大している事実を考えると、核心的な問題は解決されず、むしろ悪化させる可能性もあります。顧客にとって価値のあるものを構築するには、膨大な種類のテクノロジーを連携させる必要があるためです。
Eclipse uProtocolのビジョン
Eclipse FoundationのSDVワーキンググループでは、SDVエコシステムに関連する事柄に貢献することを使命としています。そのため、上記で紹介したさまざまな懸案事項がワーキンググループの中心に据えられています。ワーキンググループで扱う物にはeCalからZenohまで優れたミドルウェアソリューションが含まれていますが、最近のプロジェクトとして、特定のプラミングを大規模ソリューションに体系的かつエコシステム規模で組み込む統合アプローチの提供に着手しました。このプロジェクトはEclipse uProtocolと呼ばれ、2023年後半にGMによって最初に公開されて以来、多くの貢献活動が行われています。uProtocolのアプローチでは、2つのことを別々の方法で行うことを目指しています。
- 別のミドルウェアを実装するのではなく、
- （上述したように、技術全般に及ぶ）既存の複雑な組織間のコラボレーションを促進できる概念と抽象化を提供します。
uProtocolは、メカトロニクスからクラウドまでの通信領域を接合できる接着剤であり、これらの領域内でよく使用される様々なミドルウェアオプション間を橋渡しする共通のアプローチを提供して接合します。uProtocolは、一般に使用される通信プロトコルの実装をすばやく連携できるようにする、既製の統合コンポーネントの提供に取り組んでいます。また、サービスディスカバリ、データサブスクリプション、デジタルツイン機能など、よくある問題に対してクロスドメインの統合を提供する、高レベルのアプリケーションも定義します6。
uProtocolの価値をより理解しやすくするために、今日の高級車に期待される機能を考えてみましょう。これには、少なくとも3つのまったく異なる技術領域が関連します。ひとつはスマートフォンによる車両用コンパニオンアプリケーションです。最新の例を見ると、このようなアプリケーションは（ジオロケーションや現在の走行速度などの）ほぼライブの車両データ表示と（温度制御、トランク／ドアの開放、充電プロセスの管理などの）リモートコマンド実行を組み合わせて提供します。
いずれの機能も、車載の高性能計算デバイスや車両インフォテインメント／接続システム、クラウドサービスバックエンドを介した車載組み込み領域からスマートフォンアプリケーションへ、またはその逆方向にデータとコマンドが流れる必要があります。これらの各ステップには、少なくとも1つの異なる通信プロトコルに加えて、多くのデータ管理、処理、ストレージが含まれ、それぞれ、独自のAPIとプログラミングモデルが付属し、そのすべてが常に進化していくでしょう。
これをビジネス（「ドメイン」）アプリケーションの開発者ニーズと照らし合わせてみます。開発者は、このチェーンの遠端にあるサービスと対話する必要がありますが、それらのサービスは、自分たちとは遠くかけ離れた技術的環境に存在しがちです。この遠く離れたエンドポイントの製品ライフサイクル、運用組織、エンジニアリングプロセスは自分たちのものとは大きく異なり、使用する用語や概念の意味の違いが障害となるでしょう（この記事の最初のメッセージ／セマンティクスのテーマを参照してください）。
uProtocolが目指しているのは、この環境全体にわってサービスやデータソースを定義、検索、参照するための統一された方法を提供することによって、問題を解決することです。uProtocolアダプタとゲートウェイは、サービスのグローバルな参照メカニズム、APIエンドポイントに共通の信頼できる情報源、およびドメイン境界を越えたデータとコマンドの流れに必要な接着コンポーネントを取り入れています。uProtocolは、pub/subのネットワークサブスクリプション管理やデジタルツインスタイルのデータキャッシュなど、確立された概念を活用し、その実装に関わる一方で、1つの特定のドメインで使用される特定のテクノロジーからビジネスAPI定義を切り離し、また、特定のソリューションシナリオで使用されるプロトコルを統合するように設計されています。
uProtocolを使用すれば、開発者はテクノロジーマップのどこで操作していても、同じ方法でデータソースやAPIエンドポイントとやりとりできます。uProtocolのサービスメッシュ内では、呼び出しやデータアクセスは、ある車載サービスから別の車載サービス、車両からクラウド、クラウドから車両、アプリケーションから車両などで、まったく同じように機能します。これら共通の概念とAPI定義（「プログラミングモデル」）により共通の基盤が確立され、様々な分野の開発者チーム間の調整が可能となります。uProtocolは、テクノロジーや組織の境界を橋渡しすることを目指しています。
uProtocolプロジェクトの状況
uProtocolプロジェクトの開発者コミュニティは、EclipseのSDVワーキンググループで最も急速に成長しているコミュニティの1つです。ここ数カ月で様々な貢献が始まり、uProtocol対応のエコシステムの基盤が目に見えるほど大きく形成、拡張し始めています。uProtocol は多くのオープンソースSDVコンポーネントの統合力と連携ポイントになる可能性をすでに示しています。
特にコア仕様とAPI定義を進化・改善させており、複数の新しいプログラミング言語ライブラリ（SDK）を構築しています（現在、uProtocolサポートは、Java、C++、Rust、Python、Kotlinをサポートしています）。また、Android Binder、Eclipse Zenoh、MQTTブローカを連携するプロトコルアダプタの第1弾の取り組みも進んでいます。このペースで進み続ければ、2024年には、一般公開されるプルーフポイントやショーケースとして、uProtocolサービスファブリックが、Eclipse SDVブループリントプロジェクトのいずれかに導入されることになるでしょう。
展望
現時点で、uProtocolはGMのUltifiプラットフォームの中核的な存在であり、プロジェクト全体に信頼性と推進力の両方を提供しています。ただし、オープンソースプロジェクトの真の価値は、複数の採用者に価値を付加できること、また、おそらく、共有テクノロジー領域で成長する様々なオープン製品や商用製品の基盤になることにあります。したがって、実際の製品や運用インフラストラクチャにuProtocolの採用が進むことが、今後数年間の重要な成功指標になります。
この目標の達成には、具体的な自動車テクノロジー向けのuProtocolアダプタやブリッジが増える必要があります。オープンソースコミュニティにとって、ここが直近の課題となります。従来の自動車用プロトコルスタックは通常、自社専有であるか、IP規制によって保護されているからです。
たとえば、SOME/IPのようなAUTOSAR® 通信インフラストラクチャは組み込み自動車業界ではサービス指向通信コミュニティでは大きな存在であり、これらと緊密な統合ができればuProtocolのビジョンは大きな恩恵を受けるでしょう。これらの仕様に付随するIPポリシーの存在により、オープンソースの公開を実現するには困難が伴い時間がかかりますが、そのような試みの1つがEclipse SommRプロジェクトで現在行われています。
次のブログ投稿で、このプロジェクトについて詳しく報告します。
Daniel Krippner
役職：
テクニカルストラテジスト
FOSSチーム内での役割：
コミュニティへの関与、テクノロジー／機会の分析、開発
「境界を越えたコラボレーションは、企業間のゼロサムゲームから抜け出す最善の方法です。」
1:これらの2つの要素は相互に影響し合います。媒体の制約はメッセージがどのように表現、使用されるかに影響します。一方、メッセージの要件はどの媒体が有益を左右します。
2:ソフトウェアエンジニアは、「媒体はメッセージである」というMcLuhanの見解に心から納得しています。この見解は、「...通信媒体が伝えるメッセージではなく、通信媒体自体が、研究の主な焦点であるべきだ」ということを示唆しています。
3:当時は、「クラウド」という呼称はありませんでした。
4:ここでは「持続的」がキーワードです。ある時期に完璧な製品を構築することを目指すことはできますが、その素晴らしさが他の10件の製品ラインでも並行して再現し、その後、次世代の製品が登場するまで2年間ずっと続く必要があります。そして、この様々な製品はすべて、10年を超える運用の間、保守し続ける必要があり、数百万台が販売される可能性もあります。
5:標準が非常に多いのはこのためです。
6:この考え方のもとでは、uProtocolが特定のユースケースすべてに対応するわけではないことは明らかです。（車両の1つのサブドメイン内での重要なリアルタイム通信など）ユースケースによっては、それだけに特化した既存のアプローチを使った方が、よりうまく解決できます。
