自動車の制御／センサーデータ収集におけるペイロード設計【第4回】

ユースケース1の場合

　リアルタイム性を気にせずデータを収集する場合、一定の時系列でデータをまとめてパッケージングし、HTTPで送信する手法が効率的だ。HTTPは圧縮方式として「gzip」をサポートしている。パッケージング時にgzipによって約30％にまで圧縮できるうえ、一定の塊で送信することで付与されるヘッダ情報などのオーバーヘッドがかかる回数も少なくなる。

　一方でデータをまとめた分だけ遅延は確定する。1秒ごとにデータをまとめて送信すれば、総合的な伝送コストを低減できるものの、必ず最低1秒の遅延が発生するため、両者のトレードオフになる。

　表示アプリケーションで表示するまでの遅延については、パッケージデータの展開、サーバーサイドでのデータベース等へのストア処理、読み出し処理などのプロセスを要するため、システムの作りによっては数秒程度発生することも否めない。

ユースケース2の場合

　データ回収性能に加え、リアルタイム性を確保するパターンは、簡単にはいかない。図1でいえば、車両側（ゲートウェイ）から送信されたCANデータをサーバー経由で表示アプリケーションにリアルタイム性高く到達させるといった場合である。

　サーバーを中心とするリアルタイム伝送システムでは、データはエッジ側（データ送出側）からサーバーを介して受信ノード（表示アプリケーション等）に到達する。

　この「エッジ → サーバー → 表示アプリケーション」の間のリアルタイム性を高めようとすると、エッジにCANバスから流入する秒間6000個のデータをひとつずつ即座に処理（ストリーム処理)して伝送することになる。いかなるインターネットプロトコルを用いようが、必ず1データずつヘッダ情報などのオーバーヘッドが付与される。

　ヘッダ情報は、処理するデータ量が多ければ多いほど、帯域やサーバー処理コストを圧迫する要素になる。たとえば比較的オーバーヘッドが少ないといわれるMQTTでも1ストリームのデータ量が秒間6000個レベルになると相応のオーバーヘッドが発生する。サーバー側でMQTTブローカーを介する場合、データ中継による処理コストにより、少量データでは起きえなかったソフトウェアレイテンシー（遅延）が発生し始める。

　さらに、リアルタイム性とデータの回収性能は、インターネットプロトコル上では矛盾した要件といえる。リアルタイム性の高いMQTT をQoS（サービス品質） ＝ 0で利用すれば、データ到達の保証がないため回収性能は期待できない。

　これに対し、QoS ＝ 2で利用すれば、ブローカーへの到達保証により回収性能は向上するもののリアルタイム性が低下する。MQTTにおいては基本的に圧縮処理をサポートしていないため、データ伝送効率にも課題がある。