世界を動かす技術を、日本語で。

ドイツのラインメタル、バトルスイート接続型武器システムプロトコルをオープンソース化

概要

  • onboardapiインターフェースライブラリ は、センサーシステムとソフトウェア間の通信を効率化
  • 標準化データモデル により、複雑なハードウェア・ソフトウェア環境での相互運用性を実現
  • DDS標準 に基づき、信頼性と低遅延を保証
  • 複数言語対応 や後方互換性をサポート
  • ライセンス情報 や設定方法も明示

onboardapiインターフェースライブラリの概要

  • onboardapiライブラリ は、センサーシステムとソフトウェアコンポーネント間のシームレスな通信を実現
  • 標準化データモデル を提供し、異種システム間の相互運用性を確保
  • ddkitソフトウェア開発キット 上に構築
  • Object Management Group (OMG) による Data Distribution Service (DDS) 標準を採用
  • データ中心のパブリッシュ-サブスクライブアーキテクチャ を基盤とし、高負荷アプリケーション向けに 信頼性低遅延 を保証

主な特長

  • DDS XTypes および XCDR2エンコーディング 対応により、 完全な後方互換性 を実現
  • データモデル進化時も、 異なるバージョンのソフトウェア間通信 が可能
  • コアライブラリはC++ で提供
  • Java, C# / .NET, Python 向けのラッパーを利用した 多言語統合 が可能
  • 高い拡張性柔軟性 を備えた設計

利用開始ガイド

  • Client/Serviceアーキテクチャ と基本ロジックの理解
  • C++、Python、C# / .NET、Java の各言語でのサンプルコード提供
  • 設定方法 を詳細に解説
  • データモデル および 全インターフェース のブラウズ機能
  • Changelog で最新機能やアップデート状況を確認

ライセンス・免責事項

  • インターフェース記述EPL v2.0 ライセンス
  • ランタイムライブラリEULA-RME-SDK-1.0 ライセンス
  • 詳細なライセンス情報免責事項 を明示

Hackerたちの意見

最初はワクワクしたけど、DDSがベースだって知ってちょっとがっかり。

DDSに対する嫌悪感、なんで?完璧なフィットだと思うけど。

タクティカルマイクログリッドスタンダード(TMS、MIL-STD-3071)を思い出すなぁ。多分、TMSもDDSを使ってるからだと思うけど。DDSみたいなプロトコルで、リアルタイム保証があって、組み込みシステムで動的メモリアロケーションなしに使いやすさを優先するものがあるのか知りたい。リアルタイムじゃないシステムでも同じように機能する必要があるし。DDSの問題は、組み込みシステムでうまく実装するには重すぎることだよね。

DDSの実装でそのほとんどを提供しているものがあると思うよ。メモリプールを使っているかもしれないけど、アロケーションなしではないかも。それ以外だと、PX4は内部データバス用にメモリ内だけのpub/subを使っていて、DDSにちょっとインスパイアされてる。

DDSの実装にはいろいろあって、動的メモリ割り当てが不要な組み込みや宇宙飛行アプリケーションに対応してるものも結構あるよ。いくつかのDDS機能は犠牲になるけど、小さな組み込みプラットフォームで大きな動的サイズのメッセージのキューを扱う必要はないからね。あんまり選ばれることはないと思うけど、見た中で組み込みDDSを使ってるハードウェアは、普通のUDPを使った方が良かったんじゃないかな。で、もっとパワフルなハードウェアで動いてるクライアントがDDSへの変換を担当する感じ。でも、組み込みDDSを使ってる製品も出てるよ。

Zenoh(https://zenoh.io/)は、DDSの良い代替手段だよ。ほとんどの機能を保ったままマイコンにスケールダウンできるし、必要ならルーティングされたハイブリッドメッシュにもスケールアップできる。スキーマの強制がミドルウェア層から外れるから、ちょっと違うけどね。でも、今やROS2のDDSの代わりとして一流のミドルウェア実装になってるよ。

いや、彼らはオープンソースにしてないよ:https://github.com/rheinmetall。ドキュメントを公開しただけ。なんか変だね、何のためなんだろう?

API用のIDLファイルもあるけど、彼らのライブラリなしでは使えないよ:> データモデルはddkit > フレームワークに基づいたカスタムフォーマットの.rmodelで定義されています。 > .rmodelデータモデルはドキュメント用だけで、 > 通信レイヤーで使用される実際のインターフェースを反映していません。ネットワーク > 通信は提供されたライブラリを通じてのみ可能です。

タイトルの「プロトコル」って、そういう意味だったんじゃないかな。確かに誤解を招くよね。

「こんにちはCodex、私のバトルスーツの仕様についてのウェブサイトを添付しました。ドキュメント化されたAPIを使って、センサーデータのグループを表示するHome Assistant用のプラグインを作成してください。データを取得するコマンドだけ使って、スーツにアクションを実行することはできません。スーツのAPIは頑丈じゃなくて、安っぽいおもちゃよりもひどい状態だと思って、読み取り呼び出しはゆっくりと順番に、間に最低1分は空けて行ってください。可能であれば、データをタンクやレーダードームのように意味のあるカテゴリーにグループ化してください。私のHome Assistantはローカルネットワークのデフォルトで、認証情報はcredentials.txtにあります。終わったらテキストを送ってください。よろしく、さようなら。」

SFの冷たいオープニングとしては最高だね。

「カンプファンツークスコードがうまくいってない。」 - 「KIを使って改善できないの?ハンスから聞いたけど、このクラウスコードはプログラミングが得意らしいよ。」 - 「規制のせいでミストラルしか使えない。」 - 「じゃあオープンソースにしよう、他の人もクラウスコードを使えるように。」 - 「そうだね!これは確かに合法的な抜け道で素晴らしいアイデアだ!」

Hacker Newsで議論の続きを見る