TOYOTA Developers Night 2018-2020年の実証実験成果発表【後編】 コネクティッドカーを走らせるインフラ開発は「めっちゃ大変だった」 ーTOYOTA × NTTグループが共同研究開発を語り合うー

アーカイブ動画

登壇者プロフィール

トヨタ自動車株式会社
コネクティッドカンパニー
コネクティッド先行開発部 InfoTech 主任 高橋 克徳氏

株式会社NTTデータ
技術開発本部 デジタル社会基盤技術センタ
シニアエキスパート　葛西 亮生氏

NTTコミュニケーションズ株式会社
BS本部スマートワールドビジネス部
スマートモビリティ推進室　船引 魁人氏

日本電信電話株式会社
NTTデジタルツインコンピューティング研究センタ
研究員　磯村 淳氏

日本電信電話株式会社
NTTデジタルツインコンピューティング研究センタ
研究員　高木 雅氏

日本電信電話株式会社
NTTスマートデータサイエンスセンタ
研究主任　森 皓平氏

日本電信電話株式会社
NTTスマートデータサイエンスセンタ
研究主任　林 亜紀氏

トヨタとNTTグループが共同研究・開発を行った背景とは

・トヨタとNTTグループが「コネクティッドカーICT基盤」実証実験の成果を語る！

イベント冒頭は、モデレータも務めたトヨタ自動車（以下、トヨタ）の高橋克徳氏が登壇。NTTグループと共同で研究開発を開始した背景について振り返った。

「私たちは車両ビッグデータには、大きな価値を生み出す可能性があると考えています。クルマが社会のセンサーとなり、ビッグデータを得ることで、カーシェア・ライドシェアなど新たなモビリティサービスの提供が可能になる。また、事故や渋滞ゼロ、カーボンニュートラルといった社会課題の解決、さらなる価値提供にもつながるでしょう」（高橋氏）

コネクティッドカーは通信ネットワーク、クラウドなど、様々な要素で構成されている。これらの仕掛けを実現していくためには、データを蓄積処理するための基盤や、データを分析活用するための仕組み、ソフトウェアアップデートなど、幅広い技術を確立して組み合わせていく必要がある。

車両ビッグデータ活用例としては、クルマのナビから集めたデータで渋滞を解消したり、車両メンテナンスの効率化、故障予知などが挙げられた。高度安全運転支援や自動運転向けの地図の生成、障害物の検知などの用途も期待されている。

コネクティッドカーに適したICT基盤として、技術面でインパクトが大きいのは、データ量の増加で、1台あたりのデータアップロード量はスマートフォンと比べると多いと説明された。

「近い将来、EB（エクサバイト）クラスのデータ量。つまり100京、10の18乗バイトを超えるデータ量になります。その膨大なデータを適切なタイミングと場所で、適切に処理することが求められます」（高橋氏）

高橋氏は、共同研究開発の進め方についても紹介。技術検討を進めるワーキンググループと、検討結果を検証する実機検証に分かれ、お互いの技術やリソースを持ち寄っているという。現在も週に一度の定例会を継続して行い、課題解決に務めていることが語られた。

技術開発の領域は、ユースケースを実現するEnd to Endでのアーキテクチャ、ビッグデータ処理を実現するインフラ基盤の確立という大きく2つに分類される。

テーマを絞り込むと共に目標値も定め、開発は進められた。なお、ユースケースは「静的地図生成」「障害物検知」「渋滞検知」に設定した。

コネクティッドカーに搭載される通信機器から、ネットワークを経由してセンター側にデータを送り活用するための、コネクティッドカープラットフォームも開発した。その検証環境は、100台以上のサーバーで構築されている。

DCM（※車両専用の通信機。Data Communication Moduleの略）も新たに特別なものを開発した。開発したDCMを使うことで車両が得た映像、CAN、位置といった情報のサイズや頻度をコントロールすることが可能となった。「データの蛇口をつけたイメージ」と、高橋氏は表現している。

共同開発の利点を活かし、点線から下部のデータを収集する領域をトヨタが開発。上部の通信を行うアプリ部分はNTTグループが開発した。実験前の結合テスト段階ではうまくいっていたが、実際に車両に搭載すると動かない状態が数週間続いたことなど、高橋氏は当時の苦労も明かした。

様々な難題はあったものの、当初の目標を達成した満足感を語り、その詳細については、後続の登壇者たちにバトンを渡した。

大規模・リアルタイム・コスト──3大課題をどう克服したか

続いて登壇したNTTデータの葛西亮生氏は、基盤アーキテクチャにおける課題とともに、それぞれどのように取り組んでいったのかを語った。

コネクティッドカー基盤は、「大規模データ処理」「リアルタイムデータ処理」「合理的コスト」を実現する必要がある。

大規模データ処理に対しては、これまでも導入実績があり、ビッグデータの分散処理に適しているラムダアーキテクチャを採用した。

※ラムダアーキテクチャ：ビッグデータ分析とファストデータ分析を組み合わせるための仕組み

コネクティッドカーから大量に飛んでくるデータを受け取るコンポーネントでは、Apache Kafka。受けきったデータを処理するコンポーネントでは、同じくApacheのSparkを導入している。

「当初は、エッジコンピューティングが有効だと考えていました。ただ実際にテストしてみると、動画転送では効果はあるものの、物体認識や位置推定レベルでは直接効果が見られず、目標の7秒を実現することは難しいと判断しました」（葛西氏）

リアルタイムデータ処理の実現に対しては、エッジコンピューティングを導入するのはもちろん、車両・アプリケーションでも高速化に向けた改善を行った。例えば車両では、以前は必要な動画を撮影し終えてからまとめて送っていたため、待ち時間が発生していた。こま切れで送るように改善することで、待ち時間を減らすことに成功した。

アプリでは、処理の思考を変えた。以前は、何がどのレーンに映っているのかを推定した上で、後続車両に通知しようと考えていたが、こちらも先と同様、時間的な遅れが生じる要因となっていた。

そこで、何か映った段階でまずは通知する。その後、どのレーンに落ちているかを後続車が撮影・通知する。段階的な通知に変更した。

続いてはコストである。各エッジに余剰リソースを確保しておけば、事故による交通量増大などのインシデントが発生しても対応できるが、そのような仕様ではコストが高くなるのは明白だ。そこで開発したのが、スライドのような仕組みである。

「データに優先度をつけ、高いものは近くの拠点で。逆に低いものはそれほど近くなくてもよい拠点で、各拠点のリソース状況を監視しながら、分散・処理する仕組みを構築しました」（葛西氏）

各セッション後は、登壇者とのトークセッションならびに、視聴者からの質問に回答する時間が設けられた。

高橋：インフラエンジニアとしてのモチベーションはどのあたりにありましたか。

葛西：大きくは2つあります。1つはものづくりの面白さ、もう1つはチャレンジングな取り組みができる点です。特に今回のプロジェクトは、クルマのIoTに取り組むという、誰も解いたことがない難易度の高い課題に取り組んだので、基盤屋としての腕がなりました。

高橋：目標の7秒を達成するまでの苦労、実際に達成したときの気持ちはどうでしたか。

葛西：初年度は15秒でしたので、これはマズいと思いましたね。ただそこからは両社のメンバーがまさに膝を突き合わせてアイデアを出し合うことで、10秒、7秒とタイムが縮まっていき、最終的には平均7秒、最速5秒を実現。目標を達成したときは、信じられない気持ちと安堵感が共存している感覚でした。

高橋：15秒の内訳は？

葛西：各処理で約4～5秒です。動画を撮影して送る処理では、撮影に2秒、送信に2秒。物体認識処理、位置推定処理でも同様です。

広域分散環境におけるメッセージキューイング技術

続いては、NWエッジ拠点を構成する要素のひとつ、広域分散メッセージキューイング（以下、MQ）について、NTTコミュニケーションズの船引魁人氏が解説した。

「車両の観点から考えれば、どの拠点、どのアプリにいつデータを送ればいいのかを、意識する必要がなくなります。拠点から車両にメッセージを送る場合も同様です」（船引氏）

MQ技術を活用することを決めると、ある課題が浮かび上がってきた。コネクティッドカー基盤では車両や拠点が広域に分散するため、各NWエッジ拠点に存在するMQクラスタの連携をどうするかである。

というのも、KafkaやApacheといったメッセージングミドルウェアの多くは、メッセージをレプリケーション（複製）することで連携している。そのため車から拠点へ（上り）、拠点から車（下り）で異なった特徴を持つコネクティッドカーでは、レプリケーション連携ではさまざまな問題が発生するからだ。

「車両から拠点へのアップロード通信では、サイズの大きい動画を頻繁に送る特徴があるため、受け取る拠点側の負荷が高くなります。そのため、データをすべてレプリケーションすると、物理的に拠点間のNW帯域が逼迫する可能性があります。処理の重複、不要データの滞留との課題もありました」（船引氏）

そこで発案したのが、以下スライドの仕組みだ。中央の囲み2つがNW拠点であり、左の車両から上がってきたデータは、振り分けポリシーを決めるロードバランサーを介し、黄色部分、メッセージの管理や定義を行うと同時に、アプリケーションと接続する機能を有するMQ、Brokerへと送られる。

同アーキテクチャでは、プロトコル変換なども担うProxyを付帯し、各種ネットワークの状態監視も行う機能を有している。そのためある拠点で障害や負荷が発生した場合、まさにスライドのように別のNWエッジ拠点（下部）に、すべてのデータをレプリケーションすることなく、特定のデータだけを送ることが可能となっている。

一方、拠点から車両へのダウンロード通信では、車両がエンジンを切っている。山間部などで電波状況が悪い。あるいは、2つのNWエッジ拠点の境界線では、同じデータが送られるとの問題があった。

このような問題も、今回構築した仕組みであれば解決すると船引氏は説明する。ポイントは、車両とNWエッジ拠点との接続情報を論理的なキューで構成し、KVSのようなかたちで管理することである。すべてのNWエッジ拠点で共有している点だ。

「通知Proxy、拠点間Proxyを設けることで、車両がどこのNWエッジ拠点にいるかが、コネクティッドカー基盤全体で把握できます。また、データのやり取りにACKを使うことで、車両に情報が正しく届いたとの返答があったのを確認してから、データを送り元から削除するよう配慮しています」（船引氏）

シミュレーション段階ではうまくいったものの、実際の車両とアプリケーションを使った実証実験ではトラブルも発生するなど、苦労もあったと振り返った。それでも結果としてプロジェクトを成功できたことは大きいと船引氏は述べ、トークセッションに移った。

高橋：NWエッジ基盤開発のモチベーションについて聞かせてください。

船引：ネットワークなどのインフラは、つながることが当たり前だと思われています。しかし実際に開発の裏側に入ると、担当者があれこれと考え、施策した上で成り立っていることが多々あります。その一旦を、エンジニアとして駆け出しの私が担えることです。先進的なネットワークを一から考えることも楽しいですね。

高橋：台数が増えていった際の振り分け対策について、聞かせてください。

船引：NWエッジ拠点内での、横のスケールアウトだと考えています。例えば特定のNWエッジ拠点にデータが集中した場合は、振り分けを監視しているロードバランサーのポリシーを動的に変えることで、対応できる設計となっています。

高橋：グローバルでも活用できるかという質問がきています。

船引：実証実験では国内の2拠点での取り組みでしたが、そもそもグローバルを目指した設計思想ですので、グローバルはもちろん、拠点が増えても対応できると考えています。

障害物検知ユースケースに向けた高速データ利活用技術

続いて、日本電信電話の磯村淳氏が登壇。障害物検知を二段階で行う際に用いる、NTTグループ独自の高速時空間管理技術「Axispot」について解説した。

障害物検知のユースケースを実現するにあたって、3つのポイントがあった。

１．対象車両のみを時間と空間で高速に検索
２．大量の車両データのリアルタイム格納
３．全国展開を見据えたスケーラビリティ

1つは、格納と検索の高速性の両立だ。データ格納の高速性を重視すると、一般的に検索が遅くなる。一つひとつデータを取り出し、合致しているかを確認する必要があるからだ。

逆に検索の高速性を重視すると、今度はデータの格納が遅くなるという。例えば汎用的なツリー構造のインデックス。確かに検索スピードは上がるが、データを格納・削除・更新する度にツリーを再構築する必要がある。

「時空間インデックスという技術が解決します。先のようなツリー構造ではなく、モートン曲線という空間充填曲線の特性を活かした技術です」（磯村氏）

さらに、磯村氏は概要を説明していった。以下スライドの左図に示す世界地図の4分割を繰り返していき、0と1のビットを付与する。その0・1で構成される1次元のビット配列に、前方一致検索をすることで、空間の範囲検索が可能になるという仕組みだ。

例えば、「1001」という前方ビットを検索すると、世界地図におけるこの領域のみを検索することができるという。磯村氏たちは同技術を3次元に拡張し、時間次元を含むことで、高速なデータ書き込みと時空間の範囲検索を同時に両立可能とした。

2つ目のジレンマも、同じく格納と検索に関するもので、ビッグデータの集約において必要なDBを複数サーバーで構築する、分散DBについてだ。

「サーバーの場所をランダムに設定すると、格納は高速になりますが、検索時に時間がかかります。一方、地図を4分割してサーバーを割り当てると、検索時のルールが定まり、速くなります」（磯村氏）

しかし、東京都の都心部は昼間車両が多く、逆に夜は少なくなる。一方、黒枠の郊外エリアは真逆の車両量となる。つまり、車両が移動することを考慮する必要があった。

そこで考案されたのが「限定的ノード選択」という技術だ。格納先ノードを複数選択する機能を持たせることで、スライドのとおり、格納時の負荷を分散させながら、検索ノードを特定できる。

「この技術を開発したことで、格納性能は3.2倍、検索性能は246倍まで向上。負荷分散が実現できました」（磯村氏）

磯村氏はこのように達成感を述べ、セッションを締めた。

車両選択アルゴリズムにおける取り組み

続いては、日本電信電話の高木雅氏が登壇。同じく障害物検知のユースケースについて、「車両選定」に対する取り組みを紹介した。

「車両選定には大きく2つの役割があります。1つは障害物情報を配信すべき車両の選定。すなわち、障害物の近くを通過するだろうと思われる後続車両の選定です」（高木氏）

もう1つは障害物の監視だ。風に吹かれて移動したり、警察や道路管理者が拾って撤去するといった最新情報を車載カメラで撮影した車両を選定する。

車両選定の流れは4つのフェーズから構成されており、まずは、車両の位置情報を時空間DBから検索する。次に、各車両と障害物地点の距離を判定する。この時点で、車載カメラの射程距離より遠い車両、つまり障害物が小さく映っている車両を除外する。

続いては車両がどちらを向いているか、方向である。ここでは車載カメラの画角内に障害物を捉えていないと推測される車両を除外する。

そして最後のフェーズでは、周辺車両同士の位置関係を調べることで、他の車両の陰になり障害物が見えない車両を判定し、除外する。このフェーズが技術的に最も複雑だと高木氏は話し、詳しく説明していった。

当初は、各車両の見える範囲を計算して障害物と当たり判定する方法を考えた。例えば以下のスライドの赤い車両は、緑色の車両の陰となる停止線付近は見えない、と判定できる。

しかしこのアルゴリズムでは、すべての周辺車両に対して総当りで判定を行う必要があるため、計算量が膨大になる。具体的には車両台数の二乗に比例する計算コストが発生するため、車両が密集する状況では計算に時間が掛かる。そこで、計算コストを抑えるため、新しいアルゴリズムを考案した。

「車両から障害物が見えるのであれば、障害物から車両も見えるはず。逆転の発想による技術です。障害物の視界範囲を計算して、逆に障害物から各車両に対して、当たり判定を行うアルゴリズムに刷新しました」（高木氏）

当たり判定はシンプルになり、計算量は周辺車両台数に準ずるため、計算コストは大幅に減った。結果として、駐車場なみに車両が密集する大渋滞でも、100ミリ秒を切る高速での判定を実現した。

お台場での実証実験でも苦労はあったが、成功した達成感が大きかったと語り、トークセッションに移った。

高橋：モビリティの専門家ではない高木さんならではの苦労や工夫はありましたか。

高木：通常の業務ではプログラムに不具合が見つかれば、すぐにデバッグを行い、修正することができます。ところが今回の実証実験では、スタート地点への車両回送や一般車両との兼ね合いなどもあり、リトライ1回に15分ほどかかっていました。トライアンドエラーのコストの高さを感じました。

また、クルマはGPSの情報を使っているため、場所によっては誤差がありました。このような場面では、プログラムにどのようなデータが入力されているのか、プログラムがどこで躓いているかを現地で素早く知ることが重要となるため、Googleマップで入力内容や判定結果を可視化しながら進めました。

高橋：クルマと異なり、DBは目に見えません。取り組む際のやりがい、楽しさはどのあたりにありましたか。また今回のプロジェクトの苦労についても聞かせてください。

磯村：自宅にある棚や冷蔵庫により多くのものを入れ、必要なときに必要なものを、いかに早く取り出せるか。このような工夫を面白いと感じる人は、DB技術に取り組んでも楽しいと思います。

今回のプロジェクトの苦労点は、1秒に数十ｍ進む速い乗り物が対象であったことです。DBにかかる時間で、実際にクルマがどれだけ進むのか常に換算するとともに、メンバーと議論しながら進める必要のあるプロジェクトであった点も、難しさを感じました。

高橋：「トンネル内など受信不能な状況ではどうするのか」という質問がきています。

高木：トンネル内だけでなく、国道246号線など高架下の道路でも、GPSで正確な位置情報を取れないという課題があります。ただ最近は、タイヤの回転数とジャイロセンサ、地図情報をマッチングして自己位置をクルマ自体が推定する技術があり、すでにカーナビなどにも搭載されています。このような技術を併用していきます。

高橋：「障害物検知においてドライバーの意識は関係ないのか」はいかがでしょう。

高木：現時点では、ドライバーが障害物に気づいているかどうかの検知は行っていません。ただ今回のアルゴリズムを使えば、ドライバーの視界に入っていない障害物を検知して注意喚起することもできます。

高橋：「実運用では定常的に何度も同じところを検索する必要があるが、その工夫について」はどうですか。

磯村：分散処理基盤をうまく活用することで、すべての道路に対して30秒で一軸まわす高速な仕組みを構築しています。

渋滞検知ユースケースに向けた映像・CANデータ解析技術

最後のセッションは、NTTから森皓平氏、林亜紀氏が登壇し、渋滞検知ユースケースに向けた映像・CANデータ解析技術について説明した。

まずは森氏が改めて、渋滞検知のユースケースを動画も交えながら解説した。

先行する車両からの情報で、渋滞の状況を判断する。その情報を、後続の情報が欲しい車両に提供することで、無駄な渋滞を回避する、というのが大きな流れである。つまり、コネクティッドカーは情報提供源になると同時に、自身も恩恵を得ることができる。

渋滞の可能性があると判断された際は、近くを走る車両へデータの収集依頼を出し、車両から映像を収集する。渋滞の検知と原因推定を行い、結果を各車両に知らせる。

「まずは渋滞の横を通過した先行車両から映像をフレーム単位で分割し、車両の物体検知を行います。この間、位置関係の変化から、各車両の移動軌跡も追跡します。追い抜いた台数をカウントして、撮影した車両の走行距離と比較し、渋滞の有無を判断します」（森氏）

車両が順調に流れているときと比べ、渋滞時は車間距離が短いことに着目した仕組みだと森氏は補足した。そしてここから、渋滞の先頭車両を確認した車両の位置情報から、渋滞の原因も推定する。

ただし、位置情報には誤差がある。そこで、映像の情報から車両がどこを走っているのかを分類し、その上で探索範囲を変更するといった工夫をしているという。

「突発指標値」で渋滞候補地点を絞り込む

ここからは林氏にバトンタッチ。エリアをメッシュ単位に絞り集計を進め、常に渋滞があるエリアはユースケースの対象外とするステップについて詳しく解説した。

システム全体の流れとしては、「時空間集計技術」を使い、CANデータを集計。そのデータから、メッシュ内に車が何台いたのかを考慮した上で解析優先度の高いメッシュを特定する。

「まずはレーン別渋滞を、突発的、周期性のあるものに分類しました。土日祝日に混む商業施設の入庫待ち、朝夕のラッシュ時の右左折レーンなどを周期的に設定。一方、事故で道が塞がっているなど、普段とは異なる予測できない渋滞を突発的としました」（林氏）

その上で、突発的渋滞に絞り処理を行うと決め、2人が所属する研究所で林氏が確立した「習慣度算出技術」を応用した「集計突発指標算出技術」を考案する。

この突発指標の入力値は、場所、台数、時間に抑え、もともと学習しておいた時間軸信頼度などの統計情報を加味し、計算を実行する。ただし、曜日、時間帯によってはデータ不足が懸念されるため、周期なし、時間帯、曜日などさまざまな粒度で突発度合いを出しておき、総合的に「突発指標値」を算出することとした。

この突発指標値を使いながら、採用メッシュ数を調整することにより、突発的な混雑が発生しているメッシュが特定でき、映像処理の対象を絞り込むことで、スピーディーな処理を実現する。

【トークセッション／Q＆A】

高橋：皆さんの苦労した点について聞かせてください。

森：実証事件のタイミングとコロナ禍が重なったため、以前とは渋滞箇所が変化していたことです。実証実験に際しては、立ち会うメンバーを制限するなどの苦労もありました。

林：現状では、コネクティッドカーを何万台も走らせる実証実験が難しいことです。それでも技術評価は必要です。そこで、GPSの軌跡の密度を活用して人手で突発渋滞のラベルをつける工夫をしました。また、突発的渋滞を見つける速さについては、実際に基盤に乗せて評価しており、2つに分けて評価する点も苦労ポイントでした。

高橋：コネクティッドカー以外でも応用できる技術でしょうか。

林：時系列の変遷があればコネクティッドカーの台数に限らず、どんなデータでも対応できます。例えば、人流、ガソリンの消費量、ネットワークの転送量など。応用的な技術だと思っています。

高橋：ここからは視聴者のご質問ですが、「データはどれくらい蓄積してから展開したのか」。

林：GPSでの評価実験のケースでは、30日分のデータを学習させました。もともと少ないデータでも対応できる点に着目した技術ですので、粒度を緩くするなどしてデータを集めることができます。購買データに適応した実験では、学習データは1週間のボリュームでも適用可能なことを確認しました。

高橋：「対向車線の情報は見ることができるのか」はいかがでしょう。

森：周囲の車両が同じ方向に向かっているのか、反対方向なのか。車両のフロント・リアどちらが見えているかを判断する仕組みとしても取り入れているため、対向車線の情報も見ることができます。

最後にはイベント全体を通しての参加者の問いに、登壇者が答える時間も設けられた。

Q：車両・サーバーどちらで処理するかの判断について

高橋：今まさに検討中のテーマで、「まだ答えが出ていない」状況です。例えばサーバーに飛ばす場合、どうしても応答まで待ち時間が発生しますから、その間をどうするのか。コストなど含め、検討しています。

Q：基板側において、グローバルも含めスケーラビリティで考慮している点

葛西：現時点では全世界のコネクティッドカーではなく、国内の車両ボリュームを想定して開発しています。ただ台数が増えたとしても横並びにすればよいとのロジックですから、問題なく動作する可能性はあると考えています。

一方で、国によりネットワーク品質は異なりますから、まったく同じアーキテクチャにはならないでしょう。その結果、管理の問題が生じると考えています。もうひとつ、車の性能も考慮に入れるべきだと考えています。

高橋：トヨタにおいてはさまざまな車種を開発していますが、データのアップロードに関しては、車種による大差はありません。

●プロジェクトの詳細資料を公開！

本イベント開催のために、同プロジェクトに関する100ページ以上におよぶ資料を公開。 資料の主なテーマは以下のような内容となっている。

• コネクティッドカーが生み出す、大量データを高速・効率的に収集
• コネクティッドカー向け ICT 基盤として技術難易度の高いユースケース検証
• 実フィールドにて実車を用いた End to End の実証実験を支えるシステム

トヨタ自動車株式会社
https://global.toyota/

トヨタ自動車株式会社の採用情報
https://www.toyota-recruit.com/career/