自動運転車、開発のカギは”AWS Greengrass”にあり　クラウドサービスと車載PCをつなぐAWS IoTの活用法

自動運転MaaSプラットフォーム「Web.Auto」

小田洋平氏：それでは、「自動運転MaaSプラットフォームWeb.AutoにおけるAWS IoTの活用事例」というテーマで、株式会社ティアフォー・ソフトウェアエンジニアの小田から発表させていただきます。よろしくお願いいたします。では内容に入っていきます。

本日のアジェンダですが、まず自動運転MaaSプラットフォーム「Web.Auto」のご紹介をさせていただきます。それから、Web.Autoの中には「Web.Auto Agent」というものがあるんですけれども、そのWeb.Auto Agantの開発の課題であったり、どういうソリューションをとったか、最後にWeb.Auto Agantを使ったサービスをどのように発展してきたかというお話をさせていただこうと思います。

それではさっそく、Web.Autoのご紹介からさせていただきます。弊社、株式会社ティアフォーといいます。メインの業務としては自動運転ソフトウェア開発、「Autoware」の開発があって、その自動運転技術を活用した物流サービスであったり、近距離低速自動運転サービスであったりといったものの開発を行っています。自動運転の実証実験は日本各地で、珍しいものとしては例えば5GやVRと連携したものも行っています。

Autowareは完全オープンソースで開発されている自動運転用ソフトウェアです。世界各地で使われていて、開発を推進している「The Autoware Foundation」という国際団体にも、業界をリードする45社が加盟しています。

自動運転のソフトウェア、4つの機能

自動運転ソフトウェアと言われても、なかなか馴染みのない方もいらっしゃると思うので、主な機能を簡単に4つ（Localization／Perception／Planning／Control）書いてみたんですけれども。Localization以下の3つはわりと馴染みがあるものかなという感じはします。

2番目のPerceptionは、センサーデータを見て周りに何があるのか……例えば人がいて、じゃあその人はどういうふうに歩いているのか、止まっているのかといった、行動予測をしたりするというものです。

3番目のPlanningはそれを見てどのように進むべきか、あるいはしばらく止まって進むのを待つかとか、そういった走行プランの決定をするところです。

最後のControlは、実際にそれを実現するために、例えばステアリングを切るとか、アクセルを踏むとかブレーキを踏むとか、そういったことです。

少しわかりにくいのが、一番上のLocalizationというものかと思うんですけれども。これは3Dの地図データと実際のセンサーデータから、自車両が地図上のどこにいるのか、どう動いているのかを特定するものです。これも人間は無意識にやっていると思うんですけれども、ロボットとか自動運転では非常に重要な技術になります。

では実際にAutowareが動いているところを見ていただこうと思います。左下が車両の前に付いているカメラの映像で、3Dで映っている部分がAutowareから見た世界とお考えください。これを比べていくと、ちょっとおもしろいかなと思います。

（映像を指して）このようにまず車両が進んでいくと、交差点で向かいから車が来ました。そうすると自分の進行方向とクロスするぞというのを判定して、止まって様子を見るとか。そして、通行人が渡っていこうとしているので「人が動いているから待とう」といったかたちで、待ってから動いたりしています。

このAutowareの見ている世界というのは、先ほどのLocalizationですね。地図のデータとセンサーデータをマッチさせて、自分が今ここでこう動いている、というものを認識した結果になっています。

Web.Autoは「人」と「モノ」の移動を便利にするプラットフォーム

注意が必要なのは、「自動運転車がある」ということと、それで「タクシーやバスのようなサービスができる」ということの間には、少しギャップがあるということです。

例えば自動運転サービスをしたいとなると、先ほどのLocalizationで使うような地図を作成したり、編集したり、あるいは車両側にあるソフトウェア・地図のアップデートを行ったり、車両が今どこで何をしているのか、前に何をしていたのか、次に何をするのかといったものを管理したり。

ほかにも車両が立ち往生したりしていないか、問題が起きていないかというのを監視して、そういう状態に人が介入する必要があるようだったら対応するとか、そういったいろいろなハードルがあります。

そういったハードルを下げて、より自動運転車で人とモノの移動を便利で豊かにしようというプラットフォームがWeb.Autoになります。例えばWebブラウザを使って運行管理をしたり、Autowareの自動アップデートをしたり、映像配信を使って遠隔地から車両の状態を監視したりといったものがあります。

また、先ほどの地図の作成ツールであったり、シミュレーターでテストを実行したりといった開発支援の機能を持っていたりします。

画面を少しお見せすると、例えばこういった地図を作成する画面であったり、車両を呼んでどこかに向かわせるといった機能もあります。あるいは、これは車両に付けたカメラの映像を遠隔から取っているところです。この中で監視することもできますし、あるいは介入が必要な時は遠隔から運転をするといったことも可能です。

以上、簡単にWeb.Autoというサービスのご紹介をさせていただきました。

自動運転技術の搭載された車両とはどういうものか

次にWeb.Auto Agentの話に入っていきます。

まずはちょっと、自動運転車両がどういうものかを簡単に説明したいと思うんですけれども。自動運転車両は、通常の車より高性能なコンピューターで車載PCが搭載されています。これは例なんですけれども、ちょっと普通のPCよりゴツい、産業用PCがたくさん積まれているのがわかると思います。

これを簡単な図にすると、センサーであったりブレーキやアクセル、あるはステアリングなどといったものと車載PCがネットワークでつながっている図になります。

車載PCの中にはUbuntu OSが入っていて、その上にROS（Robot Operating System)というロボット用のフレームワークみたいなものが入っていて、そのROSをベースにしたソフトウェアがAutowareという位置付けになります。

ただこの時点ではAutowareはスタンドアローンで動くソフトウェアなので、例えばクラウドから指示を送ったり情報を取ったりすることはできません。Web.Auto Agentというのは、クラウドにあるWeb.Autoと車載PCにあるAutowareを接続するためのアプリケーションです。

主な役割としては、Autowareから出るテレメトリ情報、位置・速度あるいはステータスみたいなものを、加工しながらクラウドへ送信します。あるいは逆に、クラウドを経由して、例えば走行ルート・発信指示といったユーザーからの指示をAutowareに伝えるといった役割があります。

Web.AutoとWeb.Auto Agent、Web.Auto AgentとAutowareがつながることで、結果的にWeb.AutoとAutowareがつながるということになります。

Web.Auto Agentの開発で見えた4つの課題

では、このWeb.Auto Agentの開発の状況について、入っていきたいと思います。Web.Auto Agentの技術選定時の状況としては、PoCですね、実証実験用に作成したプロトタイプはありましたが、走行フィールド・車両の種類・台数といったものが増加していき、またWeb.Autoの開発メンバーが増えているという状況でした。

この時点で見えていた課題について、大きく4つを挙げようと思います。まず1つ目が「車載PCの環境差異による問題が頻発していた」ということです。車載PCにはさまざまな構成があって、もちろんライブラリー等に違いがあったりします。そこが原因で問題が起きることが多かったです。

こういった環境依存で起きる問題というのは、なかなか事前のテストで気づきづらいという特性があります。そのような問題の発生に備えて、対応できるメンバーをセットアップのたびにフィールドに派遣するという、コストの高い作業が発生していたという状況でした。

2番目の問題として「アップデートのために車載PC上で作業を行う必要がある」という問題がありました。アップデートの時も車載PCで作業を行う必要があると、アップデートの作業にかかる時間・労力がすごく高くなってしまいます。サービス開発でどんどん新しい機能を入れてアップデートしていきたいとなっても、そこがボトルネックになってしまって新しい機能を入れられない、リリースができないという状況がありました。

3番目の課題としては、エラーが起きた時の問題として「車載PC内のログが必要になってしまう」ことがあります。これはもちろん調査に時間がかかるということになりますし、問題が起きてから対応する、調査するというかたちになるので、なかなかプロアクティブに対応することが難しいということがありました。また、車載PC内にログを出すので、ログをローテーションする必要があって、そのために過去のログを見てみたいと思ってもローテーションによって消えているといったことが起きます。

4番目に「開発作業の属人性が高い」ということがあります。クラウド側とAgentのアーキテクチャがまったく異なるので、それぞれ別のメンバーがやることになりがちでした。その場合、1つの機能を作るのに異なるメンバーや異なるチームで作業することになるので、開発効率やオーナーシップが下がってしまう問題がありました。また、それぞれのメンバーが自分のやりやすいほうに引っ張られてしまうので、全体としてどうするべきかといったソリューションが考えづらいという問題がありました。

そこで、Web.Auto Agentの基盤技術として、AWS Greengrassを使うことにしました。これはAWSクラウドの機能をデバイスに拡張するサービスです。

AWS Greengrassの導入で改善できたこと

AWS Greengrassは、デバイスの認証やMQTT、ローカルシャドウを使ったデータのやり取りといったことはできるんですけれども、一番大きな機能としてAWS Lambdaをエッジデバイス上で動かすことができます。ローカルLambdaという機能になるかと思いますが、これは通常のAWS Lambdaのように、例えばMQTTメッセージでイベントドリブンで動かすといったこともできますし、常時プロセスを起動させておくこともできます。

ではこのAWS Greengrassを入れたことで、どのように変化があったのかを見ていきたいと思います。まず構成ですが、直接OSの上でWeb.Auto Agentが動くのではなく、GreengrassのローカルLambdaとしてWeb.Auto Agentが動くというかたちになります。

最初の改善としては、環境依存の問題が激減したということがありました。ローカルLambdaは通常のLambdaのように、依存するライブラリや環境変数といったものをパッケージングした状態で車載PCにデプロイすることが可能です。また動作自体もGreengrassコンテナというかたちで動かすことができます。

これによって車載PCの環境と切り離した状態で動かすことができるようになりました。それによってリリース前のテストを行った時でも、「ここで動けばほかの環境でも動く」といった信頼性のあるものにすることができました。また、セットアップ時にエラーに備えてメンバーを現地に派遣する必要もなくなりました。

次の改善ポイントとして、アップデート・リリースを頻繁に行えるようになったというものがありました。ローカルLambdaを更新したいといった場合でも、その元になっているAWS Lambdaを更新して、Greengrassグループのデプロイを実行するだけなので、車載PC上で作業する必要がありません。

ローカルLambdaの中身をアップデートしたいという場合だけではなくて、例えばローカルLambdaを追加したい・減らしたいといったアップデートでも、クラウド側の変更だけで対応可能です。またシャドウでバージョン管理をしているので、これによってアップデートが必要な車両もすぐにわかるようになりました。

次に、Web.Auto Agentで発生するエラーへの対応速度が上がったという改善がありました。Greengrassのシステムであったり、そこで動くローカルLambdaのログは、CloudWatchLogsに書き込むことができます。そのため、もちろんリモートからデバッグすることもできますし、ログの永続化も容易です。

また非常に便利だったのは、例えばECSのようなクラウド側のサービスとWeb.Auto Agentで、同じ監視ソリューションが使えるということです。例えばWeb.AutoではCloudWatchLogsとDatadogを連携させたりしていたんですが、そういった外部サービスとの連携も同じようにできますし、そのおかげでアラートなどの仕組みも作りやすく、1つにまとめることで異常にも気付きやすいという環境を作ることができます。

最後に、Web.Auto Agentの開発の属人性が下がったという改善がありました。開発作業は基本的にはAWS Lambdaと同じなので、Webエンジニアのスキルセットがあればすぐに開発することができます。これにより縦割り感がなくなって、全体最適を目指せるようになりました。

それぞれのメンバーが「この処理は車載PCでやるべきなのか、クラウドでやるべきなのか」を簡単に考えられるようになりましたし、例えば車載PCのリソースを有効活用するといった戦略は、特に5Gがこれから普及して、Web.Autoが扱うデータ量が増加した場合は、さらに重要になるかなと予想しています。

それでは実際に、Web.Autoから自動運転車を走行させている様子を、少し見ていただこうかなと思います。

（動画再生）

これは弊社で開発している「Milee（マイリー）」という車両なんですけれども、後ろに人が乗っていますが、運転はしていません。例えばこのようにタブレットを開いて「ここに向かいます。なので今から来てください」とすることができます。

タブレットから指示するとルートが送られて、このように動いている状態を見ることができます。なので、Autowareを使ってタクシーやバスのようなサービスを、このようにして作ることができるということになります。

（動画終了）

Web.Auto Agentでどうやってサービスを発展させたのか

さて、これでWeb.Auto Agentを作ることができたんですけれども、それを使ってさらにどうやってサービスを発展させていったかという例をお話したいと思います。

新しい課題として、Web.Auto Agentを簡単にアップデートすることができるようになったというお話を先ほどしたんですけれども、その先にあるAutowareも、クラウドから簡単にOTA、無線アップデートしたいという要望があります。

それについて、解決方法として2つのパターンを考えました。1つはAWS RoboMakerとGreengrassを使う方法です。この組み合わせによって、ROSベースのアプリケーションのOTAアップデートが可能になります。

先ほど申し上げたとおり、AutowareもROSベースのアプリケーションということになるので、この組み合わせによってフルマネージドでその仕組みを作れたらいいな、という気持ちはあったんです。この時は「バージョン間の差分をファイル単位で配信したい」という要件があり、AWS RoboMakerの差分配信がまだそこまで細かい単位に対応していないということもあったので、この組み合わせは一旦断念することになりました。

そこで採用したのが2つ目の方法で、GreengrassとAWS IoT Jobsを使うことで、ちょっと手間はかかるんですけれども自分たちでカスタマイズ可能なやり方を選びました。

AWS IoT Jobsを使ったパッケージ生成の流れ

それでは簡単な流れを紹介していきたいと思います。まずはAWS IoT Jobsを使ったアップデートの、パッケージを生成する流れを見ていこうと思います。

まず開発者が新しいコードをソースにプッシュします。そうするとWebhookがAPIを呼び出し、そこでDynamoDBにビルドのメタデータが書き込まれます。AutowareのビルドはそのあとAWSのStep Functionsで行われて、その結果ビルドの成果物がS3に保存されるという流れになります。

次に、こうして作られたパッケージはどのように配布されるかを見ていきます。車両管理者は自分の車両に対して「アップデートしてほしい」というリクエストを出します。そうするとビルドのメタデータを見て、今の車両のバージョン、上げたいバージョンと、それのために必要なパッケージは何なのかを特定して、それをジョブドキュメントに記載して、AWS IoTにジョブとして登録します。

車載PC側のGreengrassでは、このジョブを監視するローカルLambdaが動いていて、ジョブが登録されるとそのジョブドキュメントに記載されたパッケージをS3から取得してきます。最後にAutowareにパッケージを展開して、新しいインストールを生成し、新しいバージョンに切り替えるという動きをします。

また、このように簡単にAutowareのアップデートすることができるようになったということで、さらにそのアップデートの安全性を担保していく必要があります。そのために先ほどのビルドの流れで言ったStep Functionsの中で、安全性を確認するためのテストを行うようにしています。

このテストにはゲームエンジンべースなどのシミュレーターが使われます。それではシミュレーターによる走行の様子を少し見ていただこうと思います。

右の画面では先ほどとほとんど変わらないかと思うんですけれども、左の画面を見るとですね……これは実際の車ではなくて、ゲームエンジンの世界の中で動いているということがわかります。

このようにセンサーなどをシミュレートすることで、Autowareをまるで実際の世界のように動かすことができて、その中で例えば「このシナリオでぶつからずに走れるか」を確認して、安全性のチェックを行うことができます。

サービス開発を容易にするAWS Greengrassの価値

それでは、まとめです。今日はAWS Greengrassによって、クラウドサービスと車載PCをつなぐサービスの開発が非常に容易になったということをお話しさせていただきました。

車載PCやエッジデバイスの開発でも、AWSクラウドのサービスであったりスキルを活用できるということや、車載PC側で作業せずにクラウド側から柔軟に機能を拡張していくことができます。

例えば先ほどのように、最初は情報のやり取りをするだけだったのが、アップデートの機能も持つといった拡張を、クラウド側からどんどんしていけるということをご紹介させていただきました。

弊社では今回ご紹介したもの以外にも新しい機能をどんどん開発していくので、ご期待いただければと思います。では説明を終わります。ご清聴ありがとうございました。