空港での遠隔自動運転システムの取り組み
TIER IVで遠隔監視システム周りのチームに所属している長友と言います。
今回はTIER IVにおける自動運転車の遠隔監視システムについてご紹介したいと思います。
自動運転と遠隔運転
TIER IVでは自動運転システムと遠隔運転システムを組み合わせた遠隔型自動運転システムを開発しています。
早速ですが、ここで不思議に思われる方もいらっしゃるのではないでしょうか。
「自動で車を動かせるなら、遠隔運転なんて要らないんじゃないの？」
実は入社前は私も同じ疑問を持っていました。なんだか自動運転車のアイデンティティを否定しているようにも思えますよね。
答えは簡単で、現時点の自動運転車を実際に運用して行くには、どうしても機械だけでは完全に解決できない状況が、まだ存在するからです。
そうしたコーナーケースを遠隔運転で補うことで、現在の技術レベルでも、自動運転車を使ったモビリティーサービスを運用できるようにしよう、ということですね。
ではどのようなケースで遠隔運転システムが活用されるのでしょうか。
自動運転レベルごとに見てみましょう。
※自動運転レベルの定義についてはこちらもご覧ください。
Lv2/Lv3自動運転車と遠隔サポート
Lv2またはLv3自動運転は、必要に応じて人間の運転手による操縦が必要とされる自動運転レベルです。
「無人」タクシーや「無人」バスの場合は自動運転車に運転できる人間が乗っていませんから、必要になっても操縦できる人間がいないことになります。ですので、Lv2やLv3の自動運転システムはそのままでは「無人」にすることができません。
そこで遠隔運転システムの出番になります。人間の運転が必要な時は、遠隔地から人間が操縦してあげれば良いのです。
Lv4自動運転車と遠隔サポート
Lv4以上の自動運転では、走行環境が予め想定された範囲内であれば、人間の運転手による操縦は必要ありません。
また、万が一想定外の状況に陥った場合でも、安全に停車することが保証されます。
このレベルの自動運転車の場合、走行自体は自動運転システムだけで完結することが可能です。
しかしそれでもなお、簡単に解決できない問題は残ります。
例えば、無人タクシーの走行中に、前方で路駐車が道を半分塞いでいる場面を考えてみましょう。
この無人タクシーはその路駐車を右に回避して走行を続けるべきでしょうか？
それとも、停まって路駐車が動き出すのを待つべきでしょうか？
あるいは手前の交差点で曲がって、別の経路で目的地に向かうべきでしょうか？
通常の走行と比べると、この判断は自動運転システムには難しいタスクです。
もし仮に自動運転システムがなんらかの判断を導き出したとしても、その妥当性を担保することは困難と言わざるを得ません。万が一、誤った判断に基づいて走行して事故を起こしてしまったら、誰がどのように責任を取れば良いのでしょうか。そのために必要な仕組みや、妥当な補償の範囲や、ユーザーが心得ておくリスクはどうなるのか…などなど、考え始めればキリがありません。
こういった時には、遠隔監視システム越しに、人間のオペレーターに任せてしまった方が簡単です。我々はごく日常的にこうした判断を的確に実施しています（少なくともそういうことになっています）し、万が一判断を誤った場合の責任の取り方も、保険や法律等の社会システムとして整備されていますから、それをそのまま流用することができます。
もちろん、将来的には自動運転システムも妥当な判断を下せるようになるでしょうが、そのためには今以上に多くの情報を分析できる必要があります。
一方、判断さえ人間が与えてしまえば、安全に路駐車を回避すること自体は、現在の自動運転システムで十分に実施可能です。
無人車両での乗客のサポート
自動運転車を使ったモビリティーサービスを運営する上では、純粋に走行に関すること以外で人間の関与が必要になるケースも多数あります。
例えば無人バスで、乗客の乗降が安全に完了したことを自動的に判断するのは簡単ではありません。
ドア付近に人が居るかどうか程度ならセンサーでなんとでもなりますが、乗車したお客様は席にしっかりと座れているでしょうか？席に座らず立つことを選んだお客様は、握り棒を手にするなどしてしっかり発車に備えているでしょうか？
いずれはAIで十分な精度の自動判定が可能になるかも知れませんが、現時点では、遠隔監視システムで車内や車外の様子を人間が目視で確認した方がずっと簡単です。
遠隔運転と遠隔監視
ここまでの説明では「遠隔運転」と「遠隔監視」という表現を意図的に混在させて書いてきましたが、これらが指し示している対象はそれぞれ異なります。
TIER IVでは、自動運転車の走行状況を遠隔地から映像および音声で目視して把握することを「遠隔監視」と呼び、その上で自動運転車の走行を遠隔地から制御することを「遠隔運転」と呼んでいます。
遠隔運転するためには車両の映像や音声（クラクション等）も当然必要ですから、遠隔運転システムは遠隔監視システムを包含する形になります。
遠隔監視システムの要件
では、遠隔監視システムにはどのような要件があるのでしょうか。
映像品質
まず何よりも一定以上の品質の映像が必要です。
解像度が低過ぎても、ノイズが乗り過ぎていても、動きがカクカクし過ぎていても、正しい状況判断ができなくなります。
具体的には、前後の車両、対向車、周囲の歩行者、信号機、各種交通標識が視認できる必要があります。
遠隔映像の品質にはさまざまな要因が関係しますが、大元のカメラの性能はとりわけ重要です。
TIER IVでは遠隔監視用の高性能カメラを開発しています。詳しくはこちらをご覧ください。
遅延
綺麗な映像が得られても、それが何十秒も前のものでは意味がありません。遅延が少ないことも遠隔監視の必須要件です。
遠隔運転の場合、遅延は特にシビアです。
遅延が大きいと、映像と実際の車両との位置や動きのズレが大きくなります。人間が直接車に乗って運転する際には、自身の操作と車両の動きとの関係を無意識に学び、適宜操作を調整していくのですが、あまりにもズレが大きいとこの調節が上手く働かなくなるため、まともに走らせることができなくなります。
一方、発進時や追い越し時の安全確認程度であれば、遅延の影響はそこまで厳しくはありません。
しかしそれでも低遅延であるほど有利なのは間違いありません。
遅延が極めて小さければほんの少し先の状況を予測できれば問題ありませんが、遅延が大きい場合は、より遠い先の未来まで周囲の動きを予測する必要が出てきます。
TIER IVの遠隔監視システムは、WebRTCを用いて超低遅延映像配信を実現しています。
この通信システムの詳細については以前のテックブログ記事をご覧ください。
ただし内容はだいぶ古いので、最新の実装はここからだいぶ変わっています。
こちらについてはまた別の機会に改めてご紹介したいと思います。
安定性
画質や遅延と並んで大切な要素が安定性です。「ここぞ」という瞬間に映像が途切れていては何の意味もありません。
実は、現在の遠隔自動運転システムにおいてもっとも難しいのがこの安定性の問題です。
いつでもどこでも一定品質の映像を保証したい（しなければならない）のですが、それには映像を伝送する通信網の品質が極めて重要になってきます。
TIER IVは各通信会社の皆さんとも仲良くさせて頂いており、折々の実証実験ではそれぞれベストを尽くして頂いています。
しかしこれから自動運転車の利用がますます広がっていく上で、常に十分な品質の通信網が得られるとは限りません。
全体的に十分な帯域幅が空いていなかったり、突発的な機器のトラブルで通信に大きな影響を与える場面も出てくるでしょう。
消極的な対応としては、できるだけ遠隔監視に必要なビットレートを下げることや、そもそも遠隔監視する時間を減らす（Lv4自動運転など）ことが考えられます。
ですが、より積極的に通信安定性を求めていくことも必要だと考えています。
多回線通信
前置きが長くなりましたが、ここからがやっと本稿の本題です。
TIER IVは昨年度、関係各社と共同で、成田国際空港において遠隔自動運転システムの実証実験を行いました。
その中で我々が主に取り組んだ課題がまさに通信安定性を積極的に求めるための仕組みでした。
その仕組みとは多回線通信です。
複数の通信網を同時に使い、最も状態の良い回線で得られた映像を用いるようにすれば、一本の回線だけを用いるよりも安定した映像が得られるはず…という単純なアイディアです。
多回線の使い方
細かい実現方法を議論する前に、複数の通信回線が利用できるならどんな使い方ができるのかを考えてみましょう。
ざっと考えると、次の図で示すような３つの通信パターンが考えられます。
冗長配信
まず思い浮かぶのは冗長配信です。
同じ通信内容を複数の回線を通じて別々に送るようにすれば、そのうちいずれかの回線で何か問題が起きても、残りの回線を通じて正しくデータを届けることができます。
一方で、最終的に使われなかったデータは捨てられることになりますから、その伝送のために用いられた帯域は無駄になってしまいます。
あまり回線利用効率の良い使い方とは言えません。
切替配信
回線利用効率という意味では、いずれか通信品質の良い回線だけを用いる切り替え配信が最適でしょう（パケット代的にも…）。
実際、我々が普段使っているスマートフォンやモバイルルーターが内部的に行なっているのは（主に）これと同じ原理です。定期的に最適な基地局を探して、そこに向かって通信することで、通信品質を維持しているわけです。
スマートフォンやモバイルルーターの自動基地局切り替え（ハンドオーバー）はよくできた仕組みですが、我々には細かなコントロールができない仕組みでもあります。
例えば、通常は単独のキャリアに閉じて切り替わるので、せっかく複数の通信キャリアがそれぞれインフラを設置してくれていても、いずれか１つのキャリアの基地局しか使うことはできません（ただしマルチキャリア対応モバイルルーターも世の中には存在します）。
また、常に最適な基地局と通信できるという保証もありません。
特に都心部での移動体通信では、ある地点で捕まえた基地局が移動後の地点ではあまりうまく通信できなくなっているにも関わらず掴みっぱなしになってしまう、といった事象が起こりがちです。
複数の通信回線を自分たちの手で細かく使い分けられるなら、何らかの情報を用いて最適な通信相手（≒通信回線）を選ぶ仕組みを実現できるかも知れません。
振分配信
複数の通信回線が使えることによる他の可能性としては、それらを束ねて使う事により、見た目上の帯域幅を増やすことが考えられます。
自動運転車の遠隔監視では、車両の周囲360度の映像が必要です。
現行のTIER IVの車両では、この広い視野を得るために４〜６台のカメラを用いています。
さらに車両の用途によっては、車内や車両近辺などを映すカメラが追加で必要とされるケースもあります。
これらのたくさんのカメラから得られた映像を、より良い画質、より低い遅延で映像を送るためにはより広いネットワーク帯域が求められます。
もし、それぞれ十分な通信品質を持った回線が複数利用できるのであれば、それらに各カメラの映像通信を分担させることができそうです。
また、複数台の自動運転車が同時に走る場合にはそれぞれの車両で通信帯域を分け合うことになりますが、この時に車両単位で通信回線を譲り合うことで、より効率良く通信待機を利用することができそうです。
成田国際空港での実証実験
TIER IVは総務省の令和３年度「課題解決型ローカル5G等の実現に向けた開発実証」の一環として、成田国際空港でローカル５Gネットワークを用いた遠隔自動運転システムの実証実験に参加しました。
この実証実験はNTT東日本、成田国際空港、KDDI、そしてTIER IVの４社からなるコンソーシアムの共同プロジェクトとして行われ、近い将来の空港での自動運転技術の実用化を目指して、特にローカル５Gネットワークを利用した遠隔監視技術の有効性の検証と課題の抽出を目的として実施されました。
想定用途
本プロジェクトでは、成田国際空港の制限区域内でターミナルビル間の移動が必要なお客様向けに運行している無料シャトルバスの無人化をターゲットに設定しました。
空港制限区域では、トーイングトラクターやボーディングバスなど、さまざまな車両が日夜走行しています。
これらが走る空港内の環境は、飛行機や作業員が行き来する特殊な環境であり、
たとえ公道での走行実績のある自動運転システムであったとしても、そのまま対応できるかは未知数です。
今回の実証実験の目的の一つは、空港の制限区域内という特殊な環境でも弊社の自動運転システムが問題なく動作することを確認することにありました。
ところで、ご存知の通り、成田国際空港は第１、第２、第３の三つのターミナルビルを持つ巨大空港です。
例えば、第３ターミナルからのフライトなのに間違えて第２ターミナルビルの反対側の端に居たとして、そこから第３ターミナルビルまでを徒歩で移動するとなると、その移動距離は約700メートルに及びます。
もし出発直前でターミナルを間違えていたことに気づいたら…お恥ずかしながら筆者も昔、冷や汗をかいたことがあります。
実は、成田国際空港ではターミナル間を移動する無料のシャトルバスが用意されています。
複数の路線がありますが、例えば一般エリア（出国手続き前エリア）で三つのターミナルを全て巡回するバスは１周が約25分で、４分～５分に１本の間隔で運行しています。
また、制限区域（出国手続き後エリア）を走行するバスもあり、こちらは20分〜30分間隔で運行しています。
このバスを自動運転車で無人化することができれば、例えば運行間隔をさらに短くしたり、タクシーのように必要なタイミングで呼び出せたり、目的の搭乗口への最短経路で走らせたりすることが可能になるかも知れません。
今回はその手始めとして、第２ターミナルビル70番バスゲート付近から第３ターミナルビルバスゲートまでの約700メートルの区間（制限区域）において自動走行レベル３相当の遠隔無人運転での走行試験を実施しました。
利用車両
今回の実証実験に利用した車両はTIER IVで開発したシャトルバス型自動運転車です。
こちらの車両の詳しいご紹介は別の機会に譲りたいと思いますが、簡単にご紹介させていただくと
- 私道や限定的な公道での走行を想定したオンデマンド型自動運転シャトル
- タジマ社製の小型EVバス「GSM8」をベースに自動運転対応車両に改造
- 定員10名（うち客室８名）
となっています。
走行速度は最大で約20km/hです。今回は片道およそ5分ほどの行程となります。
マルチキャリア5G
ところで空港における自動運転車の利用実験は、我々の他にも数箇所で行われています。
制限区域に限って見ても、羽田空港や中部国際空港などでも他社さんによる同様の取り組みが行われています。
それら他の事例と今回の実証実験との大きな違いは、（もうお分かりだと思いますが）遠隔監視映像の伝送に複数のモバイル通信網を用いた多回線通信技術を用いている点です。
しかも。
今回用いた通信網は、
NTT東日本さんが空港内に敷設したローカル５Gネットワークと、
KDDIさんにご用意いただいたキャリア５Gネットワークの二つです。
通信業界の二大巨頭による夢のタッグが実現です。これは燃える展開ですね！
ローカル５Gは昨今町中に張り巡らされつつある５Gモバイルネットワークの技術を用いた、 特定のエリアまたは敷地・建物内専用の高速モバイル通信網です。
特定の敷地内に専用の５G基地局を設置することで、その敷地内の通信機器で独占的に利用できるモバイルネットワークを構築することができます。
空港は巨大な閉鎖空間ですし、遠隔監視には通信の安定性が重要です。
キャリアネットワークでは通信帯域の空き具合は一般の利用者の多寡に影響を受けてしまいますから、ローカル５Gはまさにうってつけのテクノロジーと言えます。
一方でキャリアネットワークの強みは、既に広い範囲で敷設されており、追加の投資が必要ない（あるいは比較的安価）という点でしょう。
単純に安定性だけを考えれば、用途に合わせて独占的に利用できるローカル５Gに軍配が上がりますが、例えばコストの問題からローカル５G基地局が設置できない区間や、ローカル５G網に万が一の問題が起きた際のバックアップ回線としては利用価値があります。
多回線通信パターン：切替配信
さまざまな多回線通信の利用パターンのうち、今回は特に切り替え配信方式を中心に実験を行いました。
もう少し具体的には、
- 遠隔監視システムでは、ローカル５Gとキャリア５Gのより品質の良い回線で映像を伝送することで、より高画質の映像で遠隔監視が行えるかを検討しました
- 自動運転システムではローカル５Gの高品質な回線を前提としつつ、万が一の事態によってローカル５Gが一時的に失陥したとしても、キャリアネットワークに自動的にフォールバックして障害の影響を最小化できるか検討しました
今回は両回線ともに、走行区間全体で安定した通信ができることを事前に確認しています。
そのため、一部のローカル５G基地局を一時的に落とすことで、切り替えが必要な場面を実験的に作り出しました。
仕組みの説明
次の図はTIER IVの通常の遠隔自動運転システムの概略図です。
ご覧の通り、TIER IVの遠隔自動運転車は、Autowareを搭載して自動運転を担うメインのECU（以降、Autoware ECUと記述します）と、遠隔映像の配信を担うサブのECU（弊社ではメディアストリーミングECUと呼称しています）の２つのECUで構成されています。実際にはそれぞれ複数のECUで構成するケースもありますので、厳密に言うと２台のECU（車載コンピューター）を使っているわけではありません。
Autoware ECUは、各種センサーからの入力データを元に車両を制御するまさに自動運転車の心臓部となるECUです。
車両の状態やAutoware自身の内部情報などの遠隔モニタリングに有用な情報（テレメトリー）は、インターネットを通じて逐次遠隔監視システムへと送られます。
また、例えば「発車」「停車」などの、遠隔オペレーターからAutowareへのさまざまな命令も、同じようにインターネットを通じてやりとりされます。
一方、メディアストリーミングECUは、カメラから入力した周囲の映像をエンコードして遠隔監視システムへと送信します。
上述の通り、映像通信にはWebRTCテクノロジーを利用していますので、メディアストリーミングECUの実態は「IoTデバイスとして制御可能なWebRTCクライアント」となっています。現在の実装は、時雨堂さんが開発したオープンソースのWebRTCクライアントmomoを改造したものを利用させて頂いています。
今回は多回線通信に対応するため、以下のようにシステム構成を変更しました。
鍵を握るのは「回線選択モジュール(line selector)」です。
このモジュールに通信状態に関するさまざまな情報を与えることにより、各々のタイミングでどの通信回線を選択するべきかを判断することができます。
より良い映像伝送を目指すメディアストリーミングECUでは、ローカル５Gとキャリア５Gのどちらがより良好な通信状況であるかを回線選択モジュールに選ばせ、その指示に基づいて映像を送信する回線を都度切り替えます。
切り替えるタイミングを工夫することで、切り替え時に一時的に映像データが途切れることのないように工夫をしています。
一方、ローカル５G通信の失陥時を想定したAutoware ECUでは、サーバーとの通信状態を回線選択モジュールの入力として用いました。
サーバーとの通信が切断されたと見做された場合、車両は一時的に安全に停車し、キャリアネットワークを利用して再接続を試みます。
これによって、万が一のネットワーク障害時でも遠隔監視を継続することができ、車両への駆けつけ対応が必要になる場面を回避することができます。
ちなみにこの場合でも映像は途切れなく伝送され続けていますので、監視自体は途切れることはありません。
なお、わざわざ停車せずに走り続けることも原理的には可能なのですが、一時的にせよ車両の状態をモニタリングできない状況で走らせることは危険を伴うため、今回は安全に倒して一時停車させる設計としました。
デモ映像
実際に制限区域内で撮影した切り替え時の映像を以下に示します。
こちらはTIER IVの遠隔監視フロントエンドであるAutoware Driveの画面キャプチャーです。
キャプチャー時に画質が劣化してしまっているので本来の美しさをご紹介できないのが心苦しいのですが、実際の画面はもう少し鮮明な映像となっています。
画面を見ていただくと７本の映像が出ています。６本が車外、１本が車内を写しています。
小さくて見づらいのですが、それぞれの右下に「CH」の表示があります。「CH.1」がローカル５G、「CH.2」がキャリア５Gで通信している状態であることを示しています。
動画の５秒目あたりで、CH.1からCH.2に切り替わっているのがわかります。
この切り替えが起こるあたりで、それまで握っていたローカル５G基地局の圏外に出ています。本来なら次の基地局に引き継がれるのですが、この映像を撮影したタイミングでは引き継ぎ先の基地局は意図的に止めています。
キャリア５G側の電波はこの前の段階から捕まえており、ローカル５G側の通信が途切れるのを見越して一斉に切り替えています。
ご覧の通り、切り替えに掛かる時間（＝監視が途切れる時間）は瞬き程度です。
※なお「CH」表示は今回の実証実験用に特別に用意したものです。
まとめ
以上、TIER IVで開発を進めている遠隔自動運転システムの多回線通信対応についてご紹介しました。
多回線通信に対応することで、無人の自動運転サービスを支える遠隔監視システムのキモとなる通信の安定性を向上できることを示すことができました。
今回は空港とローカル５Gという特殊な環境での試行となりましたが、この技術の応用範囲はこれに留まるものではありません。
公道などさまざまな場面で、それぞれの通信環境に応じていろいろな使い方が可能な作りになっていますので、今後も引き続き改良・検証を続けていきたいと考えています。
また、成田国際空港における実証実験は今年度も継続して実施しています。ここで得られた知見についても、後日このテックブログでご紹介できればと考えています。乞うご期待。
TIER IVでは、映像・音声や超低遅延通信を用いた自動運転を取り巻くさまざまな支援サービス／技術を開発中です。
ご興味のある方は我々と一緒に腕を奮ってみませんか。
ぜひご応募ください！
（ご応募の際は「Backend Engineer (MaaS)」または「Frontend Engineer (MaaS)」をお選びください）
Contact
- For press, community and speaking requests, contact pr@tier4.jp.
- For business opportunities and partnership, contact sales@tier4.jp.
Social Media
Twitter | LinkedIn | Facebook | Instagram | YouTube
More
