Eclipse uProtocol

コミュニケーションには、生き物であれ技術システムであれ、二つの重要な側面がある：メッセージと媒体である。あるいは、非常に大雑把な類推で言えば、セマンティクスと構文論である。

メッセージ／セマンティクスは、何が伝達されているか に関わる。同じ言葉や概念について合意している二人の人間は、音声、テキスト、手話、モールス信号などを使用するかに関わらず、会話を成立させることができる。これが内容である。

媒体／セマンティクスは、望ましい情報をどのように伝達するかという 問題である：通信当事者間で、使用する仕組みについて合意し、それを運用できる限り、あらゆる記号の列（「メッセージ」）を伝送できる。これが配管^{工事である¹}。

技術システムにおいて、メッセージ／セマンティクスの整合性の範囲は通常、資産のスケーラビリティを決定する。メッセージの内容が明確に定義されている限り、通信当事者の数は増加し、時間の経過に伴う基盤技術の変化にも対応できる。このようなシステムのコンポーネントは交換可能となり、非依存に進化できる。これによりビジネスロジックの安定性が達成され、ドメイン固有のサービスが対象とする市場（いわゆる「エコシステム」）が拡大する。

ソフトウェアシステムにおいて、具体的な配管は極めて重要であると同時に驚くほど柔軟である。機能しなければ何も流れず、その量は膨大で、絶えず変化し進化し続ける。ソフトウェア開発の多くの時間は、異なる配管の適応と統合に費やされ、新たなミドルウェアが至る所で、ほぼあらゆる機会に^次々と現れるように感じられる。

本稿の残りの部分では技術的な基盤部分に焦点を当てますが、コンテンツ標準化に向けた既存のオープンコミュニティの取り組みとして、COVESAの車両シグナル仕様（VSS）および車両サービス定義（uService）プロジェクトが挙げられます。Eclipse Foundationのソフトウェアデファインドビークル（SDV）ワーキンググループでの活動と相まって、これらのグループは本分野において共同開発によるコミュニティ主導のソリューションを確立するための真剣な取り組みを進めています。

これは車両システムやソフトウェアデファインドビークル（SDV）アーキテクチャの文脈においても同様であるが、いくつかの追加的な複雑さが伴う。SDVスタイルのシステムは、非常に異なる当事者間の通信で構成される。一方の端には、マイクロコントローラが車両に深く組み込まれたメカトロニクス領域があり、ブレーキを踏めば車が確実に制動するよう保証する。もう一方の端には、車両機能のリモート制御やドライバープロファイルの管理などに使用される、ユーザー向けのクラウドサービスやモバイルアプリケーションが存在する。

技術スペクトルの両極端は、使用される配管システムに対する要求事項の幅も同様に広範に及んでおり、極めて多様なエンジニアリングの考え方から生じている。リアルタイムで最小限の遅延が求められる実車CAN通信ラインは、クラウドからアプリへの通信スタックとは大きく異なり、この両者の間には様々な中間領域が存在する。それぞれが特定の開発文化と関連付けられ、周囲の組織に及ぼす影響も異なるのである。

要するに：SDVの文脈における配管は、技術的なレベル以上に複雑である。

関連する技術領域はすべて進化を遂げ、それぞれの要件を満たす独自のソリューション群を構築してきた。実車における物理層および転送プロトコルには多様な選択肢が存在し、IoT領域はメッセージングと通信インフラの分野で貢献し、クラウドは過去10～20年で数多くの選択肢を進化させてきた^³。しかし現代の車両とその支援ITシステムは、これらを何らかの形で有用な意味あるものとし、そのすべての上に持続的な顧客価値を構築することが^{期待されている⁴}。

新たな要件や技術プレイヤーの変化という状況に対し、よくある反応は「新たな課題」を解決する「新たなもの」を発明することだ。それは、全ての関係者の潜在的に関連するニーズを丹念に収集・対応する規格の形をとる^{かもしれない⁵。}このアプローチが有効なシナリオも存在する。しかし、これがソリューションの多様化を招くことを考慮すると、核心的な問題を解決するどころかむしろ悪化させる。顧客にとって価値あるものを構築するには、膨大な数の技術オプションが連携する必要があるからだ。

Eclipse Foundation SDVワーキンググループは、SDVエコシステムに関連する要素を提供することを使命としており、これまで提起された課題は同ワーキンググループの核心をなすものです。eCalからzenohに至る優れたミドルウェアソリューションをポートフォリオに蓄積する中、最近のプロジェクトでは特定の基盤技術を体系的かつエコシステム規模で大規模ソリューションに統合する統合アプローチを提案しています。このプロジェクトはEclipse uProtocolと呼ばれ、2023年後半にGMによって最初に公開されて以来、かなりの貢献活動が得られています。uProtocolのアプローチは、以下の2つの点で異なることを目指しています：

• これは別のミドルウェア実装ではない。
• むしろ、それは既存の複雑な組織（上述のように技術分野全体にまたがる）における協働を促進し得る概念と抽象化を提供する。

uProtocolプロジェクトは、Eclipse SDVワーキンググループ内で最も急成長している開発者コミュニティの一つを惹きつけています。わずか数ヶ月のうちに、比較的多様な貢献が集まり始め、すでにuProtocol対応エコシステムの基盤を形作り拡張する動きが目に見えて始まっています。uProtocolは、多くのオープンソースSDVコンポーネントの統合力および結集点となる可能性をすでに示しつつあります。

特に、コア仕様とAPI定義は進化と改善が進められており、複数の新しいプログラミング言語ライブラリ（SDK）が構築中です（現在、Java、C++、Rust、Python、Kotlin向けにuProtocolサポートが存在）。また、Android Binder、Eclipse Zenoh、MQTTブローカーを連携させるプロトコルアダプターの第一弾が開発中です。このペースで進展が続けば、2024年にはuProtocolサービスファブリックがEclipse SDVブループリントプロジェクトの一つ以上に導入され、公開可能な実証ポイントおよびショーケースとして登場する見込みです。

現時点において、uProtocolはGMのUltifiプラットフォームの中核的な推進役として、プロジェクト全体に信頼性と推進力を提供しています。しかし、オープンソースプロジェクトの真の価値は、複数の採用者に付加価値をもたらす能力、そして共有技術領域で成長する多様なオープンおよび商用サービスの基盤となる可能性にこそあります。したがって、今後数年間の重要な成功指標は、実際の製品や運用インフラにおけるuProtocolのさらなる採用拡大にあります。

もちろん、これら二つの次元^は互いに影響し合う。媒体の制約はメッセージの表現方法や使用法に影響を与え、メッセージの要件はどの媒体が有用かを決定する。
²: ソフトウェア開発者はマクルーハンの「メディアがメッセージである」という見解を真に受け入れている。これは「[...] 伝達されるメッセージではなく、伝達手段そのものが研究の主眼となるべきだ」と示唆している。
³: 当時は「クラウド」と呼んでいなかったかもしれないが。
⁴: ここで重要なのは「持続的」という点だ。ある瞬間において完璧な製品を構築することは可能かもしれないが、その偉業は10の製品ラインで並行して再現され、さらに次世代製品が予定される2年後にも繰り返されねばならない。そしてこの多様性は、数百万台が販売される可能性のある10年以上の運用期間を通じて維持されなければならない...
⁵: だからこそこれほど多くの規格が存在するのだ
⁶: この範囲を踏まえると、uProtocolが途中のあらゆる専門的なユースケースへの答えになろうとしているわけではないことは明らかだろう。特定の事柄（例：車両のサブドメイン内でのリアルタイムの重要通信）は、既存の、専門的で局所的なアプローチで解決する方が良い。