• Column
  • Industrial IoTが求めるシカケの裏側

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

ファストデータの遠隔収集の課題解決(その2)

坂元 淳一(アプトポッド代表取締役)
2018年6月28日

ポイント5:使用帯域の想定

 伝送時の総使用帯域においては、データ量に加え、選択したプロトロルによるヘッダサイズなどを加えた総量の算出が不可欠である。ここでは前項で紹介した実装について、一定の条件で各方式での総使用帯域を計算してみる。

HTTPの場合

条件 : 毎秒6000個のデータをまとめてパッケージし1秒ごとに送信
圧縮方式と圧縮率:FLATE(level2)により圧縮率は約31.5%
データ部長(1秒パッケージ):4万5360バイト
データ送信あたりのヘッダ長:約200バイト
秒間当たりのデータ量:4万5560バイト
必要帯域:36万4500ビット/秒(約364.5kビット/秒)

MQTTの場合

条件 : 毎秒6000個のデータを個別にリアルタイム送信
圧縮方式と圧縮率:非圧縮
データ部長:24バイト
データ送信あたりのヘッダ長:20バイト
秒間当たりのデータ量:26万4000バイト
必要帯域:211万2000 bps(約2Mビット/秒)

WebSocketの場合

条件 : 毎秒6000個のデータを個別にリアルタイム送信
圧縮方式と圧縮率: Context Take Overにより圧縮率は平均約33%
データ部長:7.92バイト
データ送信あたりのヘッダ長:6バイト
秒間当たりのデータ量:8万3520 バイト
必要帯域:66万8200ビット/秒(約668kビット/秒)

設計次第で3G回線でもCANデータは送信できる

 いかがだっただろうか。以上の結果から各ユースケースにおける選択肢をまとめて見る。

ユースケース1の場合


    選択肢:HTTPにより1秒毎のデータパッケージを送信する
    想定使用帯域:364kビット/秒
    伝送可能なモバイル網:3Gまたは4G

ユースケース2の場合

選択肢1:HTTPにより1秒毎のデータパッケージをデータ回収用に送信し、かつMQTTでリアルタイム確認用に送信する
想定使用帯域:約2.4Mビット/秒(HTTP : 364kビット/秒 + MQTT : 2Mビット/秒)
伝送可能なモバイル網: 4G

選択肢2:WebSocketでデータ回収用とリアルタイム確認用の送信を実装
想定使用帯域:約668kビット/秒
伝送可能なモバイル網:4G

 以上の結果から、3G網でもリアルタイム性を求めないデータ回収だけであれば、HTTPによって大量のCANデータの送信を実現できる。リアルタイム性を確保する場合は、使用する帯域幅が大幅に上がるため、4G網などの広帯域の確保が必要になる。

 ただし上記の前提は、あくまでも通信帯域のアベレージである。実際の移動体計測においては、地域よって帯域幅が大幅かつ急峻に変化する。十分な帯域を確保できない地域の場合は、データ種の取捨選択や、リサンプリングなどデータフィルタリングを行った上でペイロードを軽減する必要がある。

 計測走行中に電波が断絶する地域などもある。そこでは、前回解説した欠損回収の機構に加えて、計測地域の帯域測定などを実施することで、実測としてのアベレージを把握し、欠損回収処理時の帯域確保を想定した設計が必要になる。

 次回は、帯域計測事例などを紹介し、データフィルタの実装などについて解説する。

坂元 淳一(さかもと・じゅんいち)

アプトポッド代表取締役。大手外資系ソフトウェアベンダーのプロダクトマーケティングなどを経て2006年にアプトポッドを設立。コンサルティグ、ソフトウェア開発などを中心に、エネルギーやモビリティ、スマートシティなどの社会実証事業やPoCプロジェクトに従事。2013年よりM2M/IoTのファストデータ処理に特化したエンドツーエンドの汎用フレームワークとクラウドサービスを自社製品として提供を始め、自動車分野やロボティクス分野など、産業機械製品のコネクテッド化を推進する事業を展開している。