aptpod Advent Calendar 2025 12月18日の記事です。
こんにちは、Automotiveグループのエンジニアの清原です。
車載システムとクラウドを連携させる際、
「車載器がそのままインターネットに接続できる」とは限りません。
今回は、そういった前提条件の事例をご紹介します。
今回の事例では、
- 車両上で動作する既存システムの 車載器
- WAN 上で稼働する intdash
の間で、車両内の各種状態や制御情報を双方向にやり取りする必要がありました。
しかし対象となる車載器は、以下のような制約を持つ既存システムでした。
- MQTT による通信機能のみを備えている
- 車両内の閉塞網で稼働し、WAN への直接的な通信経路を持たない
本記事では、このような前提条件のもとで、
- どのようなアーキテクチャを採用したのか
- MQTT と iSCP v2 をどう役割分担させたのか
- 実装をどこまでシンプルに保てたのか
について紹介します。
要件と制約
要件
本システムでは、以下の要件を満たす必要がありました。
- 車載器から各種状態情報を WAN 側へ送信できること
- WAN 側から車載器へ制御情報を送信できること
- 複数車両を同一の仕組みで扱える拡張性を持つこと
制約・非機能要件
一方で、車載環境および WAN 越し通信には次のような制約があります。
- 車載環境では通信の瞬断や遅延が発生し得る
- 制御情報を扱うため、一定の信頼性とリアルタイム性が求められる
- 車載器側の実装変更は最小限に抑えたい
これらを踏まえ、通信方式およびシステム構成を検討しました。
システム全体構成
本システムは、以下の 3 つの要素で構成されています。
- 車載器：車両内で各種状態監視を行う
- ゲートウェイ：車両内と WAN を中継
- intdash：WAN 上で稼働するクラウド側システム
車載器は MQTT クライアントとして動作しますが、
インターネットへ直接接続することはできません。
そのため、車両内に配置したゲートウェイが、
- 車載器との MQTT 通信
- WAN 側との通信
を中継する役割を担います。
このゲートウェイには弊社の車載コンピュータである EDGEPLANT T1
を使用しています。
また弊社の intdash を使うことで、既存の車載システムをブラウザベースで遠隔監視・制御できるようになるというメリットを提供できるようになります。
通信構成の概要
図1に、本システムにおける通信構成の概要を示します。
通信方式の選定（なぜ MQTT / iSCP v2 か）
本システムにおける通信方式の選定は、
ゼロベースで複数のプロトコルを比較検討した結果ではありません。
既存の車載システムおよび WAN 側システムが持つ前提条件を尊重した上で、 全体として最も現実的で拡張性のある構成を選択するという方針で設計を行いました。
車載器側の通信方式（MQTT）
車載器は既存システムであり、 車両内の各種状態に関わる情報の送受信には MQTT を用いる仕様となっていました。
本プロジェクトでは、
- 車載器の仕様変更は行わない
- 既存の通信方式をそのまま活用する
という前提があったため、車載器側の通信方式として MQTT を採用しています。
MQTT は軽量な publish / subscribe モデルを採用しており、
- 通信の瞬断が起こりやすい環境
- 帯域や遅延に制約のあるネットワーク
といった車載環境との親和性が高いプロトコルです。
結果として、既存車載器の仕様を尊重しつつ、 車載環境に適した通信方式をそのまま活用することができました。
WAN 側の通信方式（iSCP v2）
一方、WAN 上で稼働する弊社の intdash では、 リアルタイムデータ連携のための通信プロトコルとして iSCP v2 が採用されています。
iSCP v2 とは intdash 独自のリアルタイム通信プロトコルです。
そのため、intdash との連携においては、 iSCP v2 を用いた通信が前提条件となります。
iSCP v2 は、
- 双方向のリアルタイム通信
- ストリーム指向のデータ連携
- 複数クライアントの同時接続
を想定したプロトコルであり、 複数車両を統合的に扱う本システムの要件と高い親和性を持っています。
ゲートウェイでのプロトコル変換という設計判断
このように、
- 車載器側では MQTT
- WAN 側では iSCP v2
という、異なる通信プロトコルが前提となっていました。
そこで本システムでは、 車両内に配置したゲートウェイをプロトコル変換点として位置づける 構成を採用しました。
この設計により、
- 既存の車載器を変更せずに利用可能
- intdash 側の通信仕様を意識せずに車載器と連携可能
- 両者を疎結合に保ったまま接続可能
といったメリットを得ることができました。
本プロジェクトでは、 「新しい通信方式を導入すること」よりも、 既存システムをどうつなぐかを重視しています。
実装時に考慮した点・課題
実装対象の整理と役割分担
ゲートウェイには、WAN 上の intdash と通信を行うために、 弊社が提供する intdash Edge Agent2 を導入しています。
intdash Edge Agent2 は、
- iSCP v2 を用いた intdash との通信
- 接続管理や再接続処理
といった WAN 側との連携に必要な機能を担います。
そのため、本構成において新たに実装が必要となったのは、 車載器と MQTT で通信を行う部分でした。
車載器との通信には、 同じく弊社が提供する Device Connector を採用しています。
Device Connector はプラグイン方式で機能拡張が可能な仕組みを備えており、 今回実装したのは Device Connector の MQTT 対応プラグインです。
本システムにおける役割分担は、以下の通りです。
- intdash Edge Agent2
- WAN 上の intdash との通信（iSCP v2）
- Device Connector（MQTT プラグイン）
- 車載器との MQTT 通信
- メッセージの受信・送信および中継処理
MQTT Broker の扱いに関する検討
MQTT には、以下の要素が存在します。
- Publisher
- Subscriber
- Broker
そのため、MQTT プラグインを設計するにあたり、 MQTT Broker をどのように構成するかが重要な検討ポイントとなりました。
検討した構成案は、以下の2つです。
- Device Connector 内に MQTT Broker を実装する
- MQTT Broker を別途用意し、各コンポーネントが接続する
Broker を内製する場合の課題
Broker を内製する場合、
- MQTT Broker として求められる仕様の実装コストが高い
- 安定性や耐障害性の検証に工数がかかる
- 運用実績のない Broker を車載環境で使うリスクがある
といった懸念がありました。
特に、車載環境では通信の瞬断や再接続が発生しやすく、 Broker の安定性がシステム全体に与える影響は小さくありません。
OSS Broker 採用の判断
そこで今回は、 実績のある OSS の MQTT Broker である Mosquitto を利用する構成を採用しました。
この構成では、
- Mosquitto が MQTT Broker として動作
- 車載器は Publisher / Subscriber として接続
- Device Connector の MQTT プラグインも Mosquitto に接続
という役割分担になります。
この方式により、
- MQTT Broker の信頼性を OSS に委ねられる
- Device Connector の実装をシンプルに保てる
- 運用・トラブルシュートの知見を活かせる
といったメリットが得られました。
MQTT プラグインの処理フロー
本章では、Device Connector の MQTT 対応プラグインが、 どのように Publish / Subscribe を行い、 車載器と intdash 間の情報を中継しているのかを説明します。
処理フロー概要
MQTT プラグインは、以下の2つの役割を担います。
- 車載器からの情報を Subscribe して受信
- intdash 側からの制御指示を Publish して車載器へ送信
通信の流れは、
- 車載器 → intdash（上り方向）
- intdash → 車載器（下り方向）
の2系統に分かれます。
車載器 → intdash（上り方向）
- 車載器が制御状態やステータス情報を MQTT で Publish
- MQTT Broker（Mosquitto）がメッセージを受信
- Device Connector が該当トピックを Subscribe
- メッセージを内部形式に変換
- intdash Edge Agent2 を介して iSCP v2 で intdash へ送信
intdash → 車載器（下り方向）
- intdash 上で生成された制御指示が iSCP v2 で配信
- intdash Edge Agent2 がメッセージを受信
- Device Connector が MQTT メッセージとして整形
- MQTT Broker に Publish
- 車載器が Subscribe して制御指示を受信
プラグイン構造の汎用性
今回は MQTT を例に紹介しましたが、 同様の構成で 他の通信プロトコルにも対応可能です。
対応するクライアントライブラリを利用し、 Device Connector のプラグインとして実装することで、
- プロトコルごとの差異をゲートウェイ側で吸収
- 車載器ごとの仕様違いに柔軟に対応
といった構成を実現できます。
実装を通して得られた知見
ゲートウェイ集約型アーキテクチャの有効性
今回の構成では、車載器と WAN 側システムの間にゲートウェイを配置し、
- 車載器側：MQTT
- WAN 側：iSCP v2
という異なる通信方式をゲートウェイで吸収する設計を採用しました。
この構成により、
- 既存の車載器を変更せずに利用できる
- WAN 側システム（intdash）の通信仕様を車載器側に持ち込まない
- 車載環境特有の不安定な通信条件をゲートウェイで吸収できる
といった効果が得られました。
特に、車載器が既存システムである場合、 「境界をどこに引くか」 が全体設計の難易度を大きく左右します。
今回のように、プロトコル変換点を明確にゲートウェイへ集約する設計は、 現実的かつ再利用性の高いアプローチだと感じています。
OSS を活用した安定性と開発効率の両立
MQTT Broker として Mosquitto を採用したことで、
- Broker 実装に関する検討・実装コストの削減
- MQTT としての挙動に対する信頼性の確保
- トラブルシュート時に既存の知見を活用可能
といったメリットがありました。
車載環境では「正常系」よりも、
- 通信断
- 再接続
- 一時的な遅延
といった 非正常系の挙動 が重要になります。
実績のある OSS を適切に組み合わせることで、 システム全体の安定性と開発効率を両立できた点は、 本実装における大きな収穫でした。
プラグイン方式による拡張性
Device Connector のプラグイン方式を活用することで、 今回の MQTT 対応は比較的シンプルな実装で実現できました。
実際には、弊社が提供するプラグインテンプレートに対して、
- MQTT クライアントライブラリ（今回は paho-mqtt）を利用
- Publish / Subscribe の処理を追加
するだけで、車載器との通信を実現しています。
この構造は MQTT に限らず、
- 別のメッセージングプロトコル
- 独自プロトコル
- 将来的な通信方式の追加
にも同様に適用可能です。
「車載器ごとに通信方式が異なる」 という状況に対して、 ゲートウェイ側のプラグイン実装で柔軟に対応できる点は、 今後の拡張においても大きなメリットになると考えています。
まとめ
本記事では、車載環境において、
- MQTT でしか通信できない既存の車載器
- WAN 上で稼働する intdash
をどのようにつなぎ、 双方向の車両情報連携を実現したかについて紹介しました。
ポイントを振り返ると、
- 既存システムの制約を前提として受け入れる
- プロトコル変換点をゲートウェイに集約する
- OSS や既存製品を適切に組み合わせる
ことで、無理のない構成を実現しています。
車載システムでは、
- 通信が不安定になり得ること
- 将来的に車両やデバイスが増えること
- 構成変更が頻繁に発生すること
を前提に設計する必要があります。
今回紹介した構成は、 そのような前提条件の中で 現場に持ち込みやすく、拡張しやすい 一つの実装例です。
車載エンジニアの方が、 「既存の車載器とクラウドをどうつなぐか」を考える際の 参考になれば幸いです。
