こんにちは、ティアフォーでWebプラットフォーム開発を行っている徳永です。
今回は、自動運転システムの開発にWebの技術がどのように使われているかの一例として、現在弊社で開発しているシミュレーションを用いたContinuous Integration（CI）システムの概要を紹介したいと思います｡
はじめに
警察庁の統計によると、2020年7月には24,951件の交通事故が発生しており、そのうち死亡事故が185件発生しています。
事故とまではいかなくとも、一歩間違えていれば事故になっていたヒヤリハットも発生しているでしょう。
自動運転車の走行においてはこういった事象が発生することは当然防がねばならず、人間が運転するよりもむしろ安全だという世界を作り出すことが一つのミッションであると言えます。
このミッションを達成するためには、事前に十分なテストを行い､ あらゆる状況に対応できるよう自動運転システムが進化していく必要があります。
自動運転のテスト
自動運転においても、実車を用いたテストは重要です。実験場所に赴き、テストしたい状況を作り出し、自動運転車が意図通りに動作することを確認します。
しかしながら、雨や雪が降っている状況や、事故一歩手前のギリギリの状況など、全ての状況について実車を用いたテストを行うことは現実的ではありません。
一方、シミュレーションされた空間で車を走行させることができればこういった特殊なケースのテストも可能になりますし、もっとありきたりな状況であったとしても、実車を用いるより素早く多くの状況をテストすることが可能になります。
そのため、自動運転システムの開発ではシミュレータを用いたテストを行うことがとても重要となってきます。
自動運転の仕組みとシミュレーションの分担
先日の記事でも紹介がありましたが、Autowareはいくつかのモジュールで構成されており、それぞれが役割・責務を負っています。
シミュレーションを用いてAutowareのテストを行う際、１種類のシミュレータで全ての機能をテストするよりも、それぞれのモジュールに対して最適なシミュレータを用いたテストを行うことで、より効率的にテストを実施することが可能です。
ティアフォーでは、以下のような分担でのシミュレーションの活用を考えています。
- Log Simulator － Perceptionモジュールのテスト
- 実際に計測したセンサやカメラなどのログデータを入力とし、それらの情報を基に周辺物体の検知・追跡・予測などを行うPerceptionモジュールに関するテストを行う。
- Planning Simulator － Planningモジュールのテスト
- 物体検知などのPerceptionに関する情報は理想的な情報をダミーで与え、車両のPlanningに関するテストを行う。
- E2E Simulator － 結合テスト
- Game Engineを用いた仮想的な3Dマップ内で仮想車両を走行させることで、現実を模した状況において、Sensing, Perception, Planningなど全てを対象としたテストを行う。また、ランダムな状況で長時間走行させることで、事前に想定することが難しいエッジケースの探索も行う。
これらのシミュレーションは、Autoware開発者がローカル開発環境での動作確認などで用いたり、あるいは各機能の実装時にProduct Ownerが受け入れ確認用として用いることなどが考えられます。
シミュレーションとContinuous Integration（CI）
自動運転ソフトウェアの開発で重要なことの一つに、日々の開発によって変化するソフトウェアの安全性をどう担保するかが挙げられます｡ソフトウェアが日々変化していく際には、その過程で今まで対応できていたことに対応できなくなるなどのデグレード（デグレ）が発生することも考えられます。
新しくリリースされたソフトウェアが実際の車両に適用されるまでにこれらを検知して着実に修正するためには、継続的にテストを実施し、常に既存のテストに合格している状態を保ちながら開発を行うことが必要となってきます。
こういった継続的なテストを一般的にContinuous Integration（CI）と呼びます。
CIによる安全性担保
Autowareは様々なノードから構成されているため、何かの拍子にデグレが入るという可能性もあります。もし、想定している機能が正しく動いていない状態で実車試験を行うと、想定外の挙動で事故に繋がることも考えられます。
こういったことをなくすため、ティアフォーではシミュレーションによるCIパイプラインを構築し、Autowareの開発を進めていく際に、前章のPlanning Simulatorによるリグレッションテストを回しています。
シミュレーションにおいて、他の車両の動きやAutowareによる自動運転車がどのような動きを行えばよいかを定義したものをシナリオと呼びます。シミュレーションによるAutowareの動作テストはこのシナリオを基に行っています｡
テスト対象となるシナリオは、概ね以下のような流れにより登録されます。
- 自動運転車の走行環境(ODD)を定める
- ODDに準じたテスト要件を整理
- テスト要件から、使用する地図を定め、シミュレーションを行うシナリオを作成
- シナリオをシミュレータが読み込めるフォーマットで記述
- 作成したシナリオをシミュレータで実行し､シナリオが意図通り動作しているか確認
- CIとして登録し、以後リグレッションテストの対象シナリオとなる
現在、社内のCIシステムの中には、多くのシナリオが登録され、AutowareにPRが発行されたタイミングやリリースのタイミングで、自動的にリグレッションテストが回るようになっています｡ Autoware開発者は自身がコードの変更を行った際にリグレッションテストの結果を参照し、自身のコードがデグレを発生させてないか確認することができます｡
このように、CIを開発の軸に置くことによって、安全性を担保しつつもAutowareの開発スピードを落とさないような仕組みを日々試行錯誤しながら構築しています｡
シミュレーションの課題と技術的チャレンジ
シミュレーションを行うにあたり、解決すべき課題はたくさん存在します。
例えば、以下のような課題が存在します。
- シナリオの記述そのものに時間がかかる
- 特徴的なシナリオを事前に考えることに限界がある
- GameEngineのシミュレーションを行う場合、3Dマップ生成に関するコストが高い
こうした課題を解決するために、Ontologyを用いたシナリオ自動生成（Ontology based Scene Creation for the Development of Automated Vehicles）や、HD Map（Paracosm: A Language and Tool for Testing Autonomous Driving Systems）またはログデータからシナリオ自動生成する手法などの活用により、シナリオをシステム的に網羅的かつ低コストに生成できないかを現在検討しています。また、3DマップについてもODDなどの要件から自動生成ができないかといったことを検討しています｡
ティアフォーではCIとしてシミュレータを動作させるための基本的な部分の開発のみでなく、このような研究分野も調査し、より先進的で安全な自動運転の実現に向けた開発を日々行っています。
まとめ
ティアフォーでは、安全な自動運転社会の実現に向けて様々な取り組みを行なっています。本記事では幅広く紹介しましたが、それぞれの詳細な内容に関しては別の記事で紹介することができればと思います。
現在ティアフォーでは、自動運転システムはもちろん、それを支えるWebシステムを一緒に開発していく仲間も募集しています。もしご興味があれば是非エントリーをご検討ください！！
