シナリオ記述言語で広がる自動運転システムのテスト共有の輪
こんにちは。TIER IV のシミュレータチームで自動運転シナリオ記述言語のスクリプトインタプリタを開発している山﨑です。
TIER IV は昨年度末、JARI・名古屋大学とともに、SAKURA プロジェクトで設計されたカットインシナリオを TIER IV のシナリオシミュレータで動作させることに成功しました。本記事ではその事例を通じて、自動運転シミュレータが直面する挙動の互換性問題を紹介します。
シナリオ？
まずは冒頭で登場した単語『シナリオ』の説明から始めましょう。『scenario』という英単語そのものの意味から大きく外れていないために説明なしに用いられることが多いのですが、専門用語の一種です。
自動運転システムの設計やテスト、シミュレーションの文脈で語られる『シナリオ』とは、大雑把に言って『自動運転車をとりまく状況の説明』のことを指します。例えば、こんな具合です。
自動運転車が直線道路を走っている。道路の法定制限速度は 60 Km/h だ。
最初の時点で、自動運転車からみて 100 m 先の道路脇（つまり歩道）に歩行者が立っている。歩行者はただ立っているだけで歩く素振りはない。
しかし、自動運転車と歩行者の距離が 30 m を切った瞬間、突然歩行者が車道に飛び出した！
ここで重要なのが「このとき自動運転車はどうするべきだ」という話はシナリオに含まれていないという点です。狭義の『シナリオ』とはあくまで状況の説明であって、それに対して自動運転車がどういった行動をとるべきかという話は仕様や機能要求として区別されます。
たとえば、この例では「道路の法定速度が 60 Km/h である」とは書かれていても、この状況下で自動運転車が時速何 Km/h で走っているかや走るべきかについては言及されません。それは自動運転車自身が考えるべきことだからです。
機能要求は、先の例に続けて
このとき、自動運転車は道路を 60 Km/h で走行するが、歩行者の飛び出しを検知すると 1 m/s² の減速度で減速し、歩行者を回避するか停止しなければならない。歩行者に接触してはならない。
という風に決められます。もっとも、実際の機能要求は自動運転車に乗っている人の安全や乗り心地、周囲の状況など多くの要素を加味して、もっと複雑な条件が指定されたり複数のパターンに分かれたりするため、これはあくまで単純化された例として捉えてください。
つまり、自動運転の文脈における『シナリオ』とは、自動運転システムの「できることの範囲」をきちんと決めてそのとおりにシステムを構築するための、考えを共有するための道具と言えます。
シナリオを再現しよう！
自動運転車をとりまく状況を『シナリオ』として、そのとき自動運転システムがとらなければならない行動を『機能要求』として表現することができました。そうなると次に気になってくるのは「実装された自動運転システムは本当に機能要求通りの動作をするの？」という疑問です。
この疑問を解消する最も分かりやすく確実な手段は、実車で動作確認を行うことです。自動運転車は現実世界を走るものですから、シナリオの状況を現実に再現して、自動運転システムが期待した動作をしてくれるかを目で見て確認するというわけです。しかし、実際にそれを行うには非常に多くの手間や工夫が必要です。本題とは逸れるため簡単な紹介にとどめますが、例えば、TIER IV における実験の手順は大まかに次のように定められています。
実験前
- スキルの習得（セーフティドライバー・オペレータ認定）、自動運転システムの理解、改造車の知識の習得
- 情報の入手
- 実験実施計画、緊急連絡網
- リスクアセスメント
実験中
- 目的・内容・項目の再確認
- 点検（安全面、始業車両、終業車両、人）
- 異常・危険の察知
実験後
- 反省会
- （もしもヒヤリハット・事故が起きた場合）インシデント管理
特に、実験前の手順にはそれぞれより詳細な申請・計画・確認フローが存在し、実際の準備は一ヶ月かそれよりも前から始められます。実験は開発実験と実証実験の二種類に分けられますが、開発中は早さを重視するということはなく、どちらも同様の手順を踏む必要があります。
実験の工夫については、分かりやすい例としてダミーの人形を利用した飛び出し等の模擬があります。先のシナリオの例は歩行者の飛び出しでしたが、これの開発実験を行う場合、開発中の自動運転システムには失敗する可能性がわずかにでも存在する以上、本物の人間を飛び出しさせて実験するわけにはいかないので、人形で代替します。
これについては実際の実験の様子を見ていただくのが一番です。以下の動画をご覧ください。
他にも、死角からの飛び出し検知の実験にも同じ方法がとられます。
実験は一回で終わりではなく、自動運転車の速度を変えたり、飛び出しの位置やタイミング・速さを変えたりと、ひとつのシナリオについてパラメータを変えながら複数回行われます。また、実験は簡単なものであっても、数日間に渡って行われることもままあります。
こうして行われる実験でしか得られない知見やデータは多く存在し、例えばセンサのログデータは実験終了後も様々な用途で用いられます。他にも、ハードウェアが絡む部分は実験しなければ分からないことばかりです。しかし、これだけの手間をかけて実験する以上、実験対象の機能がそもそも動作しないとか、机上でも確かめられるような問題点は取り除いた上で実験を行いたいという要望は大きいです。
また、TIER IV では OSS コミュニティを巻き込んで凄まじい速度で Autoware を進化させ続けていますが、大勢で並行してシステムに変更を加えるため、その機能追加や変更に際して既存の機能に問題が出ていないか、つまり、これまで意図通りの挙動ができていたシナリオで望ましくない動作をするようになってしまっていないかを都度確認したいという要望もあります。
そんな要望に応える手段として、実車での実験を行う前に、シミュレーション空間でシナリオを再現してシステムの挙動を確認するというアプローチがあります。
シナリオ記述言語？
さて、シミュレーション空間でシナリオを再現するためには、シミュレーションを行うコンピュータにシナリオを理解してもらう必要があります。先のシナリオ例は日本語の普通の文章として書きましたが、このままではコンピュータには理解できません。日本語で書かれたシナリオをコンピュータが直接理解できるよう、日本語を解析するプログラムを頑張って書くというのもアプローチのひとつかもしれませんが、シナリオをコンピュータにとって理解しやすい形に書き直すほうがずっと簡単です。
そこで、先のシナリオ例をもう少し形式的になるように書き直してみたものがこちらです。
道路：
形状：直線
法定速度：60 Km/h登場人物：
乗用車 A：
運転手：自動運転システム
歩行者 A：
運転手：なし最初の状態：
乗用車 A：
場所：車道の適当な場所
速度：60 Km/h
歩行者 A：
場所：乗用車 A から 100 m 先の歩道
速度：0 Km/h出来事：
（１）乗用車 A と歩行者 A の距離が 30 m 以下になると、歩行者 A が車道に向かって飛び出す
最初に比べて記述が長くなってしまいましたが、むしろこちらのほうが読みやすいという方も居るかもしれません。自由な日本語の文章では書く人によって説明の順序などに癖が出てしまうため、ある程度型にはまった書式のほうが組織で管理する文書としては魅力的です。
あとはこれを英語に直して、コンピュータの理解を助けるための記号や合言葉を随所に差し込んでいけば、コンピュータにとってかなり読みやすいシナリオにすることができます。
そうして出来上がった「シナリオを書くための書式」をシナリオ記述言語（Scenario Description Language）ないしシナリオフォーマット（Scenario Format）と呼びます。どちらかと言えば後者の「シナリオフォーマット」という呼び方のほうが広く用いられているように感じますが、自動運転シナリオも日進月歩、いまやいちプログラミング言語と呼べるほどの機能を搭載しつつあるものも存在するため、筆者は「シナリオ記述言語」という呼び方の方が好みです。
ただ、実際に TIER IV が利用しているシナリオ記述言語は上記のような「日本語の文章をコンピュータにとって読みやすく変形する」という手順によって設計されたものではなく、始めからコンピュータ可読なシナリオ記述言語たらんとして設計されたものです。どちらも最終的な文書の見た目や構造は概ね上の例と似たような形に落ち着くことが多いので、あまり設計の手順は気にする必要はないかもしれません。どちらも似たようなものに落ち着くのは、どちらも「自動運転シナリオ」という限定された用途に焦点を絞った道具であるためです。
また、TIER IV が用いているのは国際標準のシナリオ記述言語なのですが、実のところ、TIER IV 社内や Autoware Foundation のみの利用を考えると、国際標準のシナリオ記述言語ではなく TIER IV 独自のシナリオ記述言語を Autoware の仕様に特化して設計したほうが短期的には便利です。例えば、Autoware 特有の機能を含むシナリオを書くことは国際標準そのままではいささか面倒で、幾らかの拡張や小細工が必要となってきます。しかし、それでも国際標準のシナリオ記述言語を用いているのは、長期的にはこちらのほうが有利になるためです。よく知られたシナリオ記述言語を用いていれば、TIER IV や Autoware Foundation によって書かれたシナリオを同じシナリオ記述言語を採用している他社・他団体でも利用できるほか、その逆、他社や他団体によって書かれたシナリオを TIER IV や Autoware Foundation が Autoware のテストに利用することもできるのです。
そして、これこそが今回の JARI・名古屋大学との取り組みで重要だったポイントです。つまり、TIER IV のシミュレータと SAKURA プロジェクトは同じシナリオ記述言語、OpenSCENARIO を採用していたのです。
ASAM OpenSCENARIO
OpenSCENARIO とは、自動車産業を中心とした標準規格の策定を行っているドイツの団体 ASAM. e. V. がメンテナンスしているシナリオ記述言語です。恐らく、現時点で存在するシナリオ記述言語の中で最も広く知られているものがこれです。
特定のシミュレータに固有のシナリオ記述言語（多くの場合、Python 等のスクリプト言語によって記述される DSL の形態をとります）や、より高性能であったり記述性の高いシナリオ記述言語の提案や研究など、数だけを見ればシナリオ記述言語は非常に多くが発表されていますが、実用レベルまで仕様が整備され公開されているという点で OpenSCENARIO は現状最も優れた選択であると筆者は評価しています。
そんな OpenSCENARIO にはこの記事を書いている 2022 年 5 月現在、バージョン 1.0 系（1.0、1.1.0、1.1.1 があり、以後 1.x と表記します）と、リリース準備が進められているバージョン 2.0 が存在します。
OpenSCENARIO 1.x は XML によって表記される、とてもオーソドックスな仕様のシナリオ記述言語です。「保守的なシナリオ記述言語を設計せよ」と指示が与えられた場合、ほどんどの設計はこれと似たようなものに落ち着くのではないでしょうか、という出来栄えです。書き心地は、野暮ったい・記述が冗長・書いていて楽しくないといった、あまり良いものではありませんが、それこそが 1.x の最も優れた点です。どういう意味かと言うと、初めて OpenSCENARIO 1.x を目の当たりにしたプログラミング経験が無い人であっても、なんとなくどう書けばいいかを察することが出来て、実際の挙動も概ね見た目通り・想定通りのものになるという点で優れています。また、OpenSCENARIO 1.x をサポートするシミュレータ側の視点に立つと、この特徴は実装の容易さという観点から魅力的な特徴です。
一方、OpenSCENARIO 2.0 は 1.x の「野暮ったい・記述が冗長・書いていて楽しくない」という欠点の克服に加え、シナリオのパラメタライズ機能に強く注力して仕様策定が進められています。筆者はまだドラフト段階のリリースを簡単に確認しただけに過ぎませんが、一見して非常に記述がコンパクトになったなという印象を受けます。シナリオ記述言語というよりはプログラミング言語然としていて、高密度・高機能になっています。しかし、同時に 1.x の持っていた「初見でも分かりやすい」という良さを失っているようにも感じるため、この辺りはトレードオフだと考えています。
では 1.x と 2.0 のどちらを利用する方が良いのか、という疑問が湧くかと思いますが、これに関しては現状 1.x が手堅いと考えています。というのも、2.0 は 1.x の置き換えが意図されているわけではなく、1.x と並行して開発が進められていく予定であると ASAM が表明しているからです。加えて、1.x と 2.0 は将来的に統合される計画であるとも述べられているため、どちらを利用していても、最終的なゴール地点は同じところになるはずです。2.0 はまだ正式リリースがされていない段階ですし、1.x は仕様が徐々に熟れてきている上に TIER IV のシミュレータを始め無料で利用できるシミュレータのいくつかによってサポートされているので、さしあたっては 1.x から試してみるのが良いでしょう。
TIER IV の OpenSCENARIO 実装
さて、その OpenSCENARIO を実際にシミュレータ読み込めるようにする、実装の話をしましょう。
TIER IV にはテストしたい領域に合わせて設計されたシミュレータが複数並行して開発されており、その中でもシナリオ記述言語を読み込んでシナリオを再現するものを特にシナリオシミュレータと呼んでいます。そのシナリオシミュレータは、先の節でも少し触れたように、現在は OpenSCENARIO 1.x を採用しています。
シナリオシミュレータの実装開始時点では OpenSCENARIO 1.0 がリリースされたばかりだったため、ベースは 1.0 のまま、徐々に最新の 1.1.1 へ移行を進めている状況です。初出の OpenSCENARIO 0.9.1 から 1.0 間には非互換な変更があったものの、それ以降は後方互換を保って仕様のアップデートが続けられているため「まだ実装できてない機能はあるけど、1.x なら概ね動作する」という安心感を持って実装を続けられています。
TIER IV のシミュレータは当然 TIER IV の自動運転システムである Autoware をターゲットとしています。そのため、シナリオシミュレータには「シナリオに従って Autoware に走行を依頼」しつつ「シナリオに従って Autoware の走行を邪魔」したりすることで Autoware の安全性を確かめるような機能が求められます。しかし、OpenSCENARIO は Autoware のために設計されているわけではなく、世界の様々なシミュレータ、様々な自動運転システム、様々な用途のうち皆が共通して必要としているものを中庸にサポートしています。そこで、TIER IV のシミュレータは OpenSCENARIO を如何にして Autoware に適用するかを考えて実装する必要があります。
まず考えなければならないことは、Autoware に対して命令しても良いこと・命令しては駄目なことの区別です。
Autoware はセンサーで周囲を見て、自分で物事を判断して走行しなければならないため、シミュレータが Autoware にありとあらゆる情報を提供してはテストになりません。例えば、Autoware の飛び出し検知機能をテストしたい場合、Autoware に対して「これからこの歩行者が飛び出すぞ」などという情報を与えてしまうことは NG です。他には、制限速度 60 Km/h の道路で「59 Km/h くらいを維持して走ってほしいぞ」と伝えることも NG です。Autoware 自身が制限速度を把握して、自分の速度を決めなければなりません。他にも、OpenSCENARIO では車を瞬間移動させることが出来ますが、現実の車はそのようなことは出来ないので当然 Autoware に瞬間移動を命令することも NG です。
なお、テスト対象の自動運転車以外、つまり Autoware を邪魔する役の車両に対しては瞬間移動の命令は OK としています。この機能が「何故かそれまでセンサーに映っていなかった物体が突然眼の前にパッと現れたら Autoware はどうする？」というテストに便利なためです。
ここで、Autoware は単独でも自動運転システムとして機能する柔軟なソフトウェアですが、TIER IV が提供する自動運転サービスではインターネットを介して FMS（Freet Management System: 運行管理システム）から目的地や経由点などの情報を得て走行する、クラウドと連携して全体でひとつのシステムという形をとります。そのため、シミュレータはシナリオの記述に従ってシミュレーション空間内の非 Autoware 車両や歩行者を操作しつつ、Autoware に対しては FMS のフリをして情報を送ることで、Autoware に「自分は今本物の道路を走行している」と錯覚させるように構成されています。つまり、Autoware に対しては実際のところ FMS が Autoware へ配信する情報と同じもの、大雑把には初期位置・目的地・経由地点のみがシナリオから命令できることになります。
次に考えなければならないことは、Autoware 固有の機能をテストしたいとき、如何にして OpenSCENARIO の範疇でそれを記述するのかです。
OpenSCENARIO がカバーしていない Autoware の機能として、異常状態からの復帰機能があります。これは Autoware による自動走行中にセンサーが壊れた場合や車載コンピュータの一部が（高温になりすぎて）ダウンしてしまった場合などに、Autoware 自身がその異常を検知して、残された設備を駆使して安全に路肩などへ停車する機能です。この機能をテストするためにはシミュレーションの実行中に「Autoware の機能の一部を壊す」必要があります。OpenSCENARIO は車両に対して多くのことが命令出来るよう規格が整備されていますが、流石に「とある機能を壊す」というような特殊な命令は用意されていません。そのため、OpenSCENARIO の仕様に含められている「シミュレータ固有の命令を記述する欄」を駆使してこれを実現します。
最後に考えなければならないことは、シナリオをどのようにしてテストに用いるか、です。
本記事のはじめで述べたように、シナリオはあくまで『自動運転車をとりまく状況の説明』であり、テストで確かめたい「望ましい挙動」はそれとは別です。OpenSCENARIO でもそれは同じで、OpenSCENARIO で表現できるのはシミュレーションで再現するべき状況のみです。とは言え、TIER IV ではシナリオシミュレーションを自動運転システムのテストに使っているので、シナリオとそれに対する Autoware の望ましい挙動はセットで書けてほしいものです。そのため、TIER IV のシミュレータは特別に「この条件を満たしたらテスト成功」「この条件を満たしたらテスト失敗」という風に、OpenSCENARIO の枠組みの中で、上手にシナリオの実行をテストの成否につなげるような記述が出来るようにしてあります。
具体的には、「シミュレーションを成功として即座に終了せよ」「シミュレーションを失敗として即座に終了せよ」のふたつの特別な命令を追加しました。シミュレータはこの命令が実行されると、シミュレーションの成否を結果ファイルに書き出したりシステムに通知した後、自身と Autoware をシャットダウンするようになっています。OpenSCENARIO の仕様に含められている「シミュレータ固有の命令を記述する欄」を利用して、シナリオを書いている人からシミュレータに対して命令をするイメージですね。実際には、OpenSCENARIO のイベント機能と組み合わせて「自動運転車が歩行者と接触した場合」「シミュレーションを失敗として終了せよ」という具合に用います。このアプローチはどちらかと言えば宣言型の趣のある OpenSCENARIO の中に異なるプログラミングパラダイムを混ぜ込んでしまっているようにも見えるため少々不本意なのですが、命令形プログラミング言語に慣れ親しんでいるプログラマであれば違和感なく扱えるため、OpenSCENARIO を大きく変更しないという制限の中では妥当な選択であったと考えています。
以上のように、TIER IV のシナリオシミュレータは OpenSCENARIO から逸脱しないよう、注意深く Autoware をテストするための機能を追加して実装されています。
SAKURA Project
かつて、ドイツ経済エネルギー省主導で行われた PEGASUS というプロジェクトがあります。これは、自動運転システムの評価フレームワーク標準化を目指すプロジェクトで、非常に大きな枠組みなので、本記事に関連する部分だけかいつまんでまとめると
- 自動運転システム安全性を評価するためにシナリオシミュレーションを活用しよう
- シナリオにはどれだけの情報を盛り込めば良いか
- 自動運転システムを安全にするためには、どんなシナリオを準備すれば良いか
- 大量のシナリオが必要となるが、どうやって効率よく用意するか
- 自動運転システムは各シナリオに対してどのような挙動をするのが望ましいか
という具合の内容です。ASAM OpenSCENARIO も元々はこのプロジェクトの成果物のひとつであり、今日の全てのシナリオによるテストは多かれ少なかれ PEGASUS の影響を受けていると言っても過言ではないでしょう。
さて、翻って記事冒頭で名前を挙げた SAKURA Project について紹介します。名前から察することが出来るように、こちらは日本のプロジェクトです。大枠としては、レベル 3 以上の自動運転システムの安全評価プロセスの確立を目指す取り組みで、現在、日本の経済産業省によって実施されています。そのベースにはかつての PEGASUS の成果があるため、プロジェクトの中核にはやはりシナリオを用いた自動運転システムのテストが据えられています。JARI（日本自動車研究所）はこの SAKURA のプロジェクトパートナーであり、特にシナリオデータベースを手がけています。
簡単に言えば、「何をどこまでやれば自動運転システムは安全になったと言えるのか」を確かめる手順を考えているのが SAKURA Project で、JARI はそのために必要な「シナリオ集の策定」を行っています。
ここで、「何故 PEGASUS をそのまま採用せず SAKURA を新しく始めたのか」と疑問に思う方もいらっしゃるかも知れませんが、PEGASUS は欧州のプロジェクトであり、欧州は日本では道路事情も法律も異なるため、日本でそのまま採用するには難しいというのが理由です。わかりやすい例だと、日本は左側通行、ドイツは右側通行なので、右左折が絡むシナリオは軒並み左右が逆になってしまいます。他にも信号機など、ドイツと日本の道路には多くの違いがあるため、PEGASUS の考え方そのものは流用することができても、多く部分には練り直しが必要となってしまいます。
今回の JARI・名古屋大学との取り組みは、さらにこのシナリオ集のうち「レーンチェンジ」あるいは「カットイン」と呼ばれる種類のシナリオを TIER IV のシミュレータで動作確認する、というものでした。
カットインシナリオ
ここからが本題です。
記事冒頭にも触れたように、今回動作させたのはカットインと呼ばれる類のシナリオです。カットインシナリオとは、自動運転車が走行している最中に、隣の車線から別の車が車線変更で（多くの場合は自動運転車の前に）割り込んでくるようなシナリオを言います。逆に、自動運転車の前を走っていた別の車が車線変更で隣の車線へ出ていく場合はカットアウトと呼ばれます。
シナリオの挙動を簡単に図に示すと次のようになります。
カットインシナリオは自動車線維持システム（ALKS: Automated Lane Keeping System）を評価するためのシナリオ群に属します。より詳しい内容は経済産業省より公開されている JARI のレポートを参照ください。
さて、今回の JARI カットインシナリオは Carla Simulator 向けに OpenSCENARIO 0.9.1 で書かれていました。Carla Simulator は TIER IV のシミュレータと同じく OpenSCENARIO 1.x をサポートするオープンソースのシミュレータです。Carla Simulator は TIER IV が OpenSCENARIO を使い始めるよりも早い段階、1.0 のリリース前から OpenSCENARIO 0.9.1 を実装しています（最新のサポート状況は Carla Simulator のドキュメントをご参照ください）。
OpenSCENARIO 0.9.1 および 1.0.0 の頃は 1.1.1 の現在よりも仕様に曖昧な部分が多く、明記されていない部分の挙動については実装者が良い塩梅に辻褄を合わせるしかありませんでした。筆者は TIER IV のシナリオシミュレータに OpenSCENARIO を実装するにあたって、先発の Carla Simulator が曖昧な部分をどの様に実装したかをしばしば参考にすることがあったので、Carla Simulator がどの程度 OpenSCENARIO の機能を持っているかを大雑把に把握できていました。そのため、JARI のシナリオの内容を聞けば 0.9.1 から 1.0 へ書き換えるだけで動作しそうだと考えていました。
その予想はあたっていたのですが、しかし、今回一番大きな問題となったのは OpenSCENARIO でシナリオを記述した後、実際にシミュレーションするとき車線変更の挙動そのものだったのです。
OpenSCENARIO による車線変更
OpenSCENARIO では車両に対して「隣の車線へ車線変更せよ」という具合に車線変更が命令できるようになっています。
詳細な仕様の説明は ASAM による公式マニュアルに譲るとして、大枠としては車線変更先となる車線を指示し、追加で細かい注文をつけるような仕様になっています。追加の注文とは、
- 指定した秒数で車線変更を完了させてほしい
- 指定した距離進んだ地点で車線変更を完了させてほしい
- 指定した一定のペースで横にズレるよう車線変更を行ってほしい
の三種類です。
カットインシナリオが Carla Simulator で動作することは予め JARI によって確かめられていましたが、シナリオに書かれている内容と上記の OpenSCENARIO 車線変更命令の仕様を突き合わせてみると、どうやら Carla Simulator の車線変更の挙動はシナリオに指定された注文とは異なることがわかりました。結論から言えば、これは Carla Simulator が車線変更機能を一部しか実装していないために、追加注文を無視して「自然な」車線変更を行うようになっていたのが原因でした。また、この事実が判明した時点では TIER IV のシナリオシミュレータも似たようなもので、注文を無視してそれらしい車線変更で済ませる実装になっていました。
折角の機会なので TIER IV シナリオシミュレータは、カットインシナリオを動作させるために必要な部分を規格どおりにきちんと実装することにしました。そこで改めて OpenSCENARIO の仕様を眺めるわけですが、上に並べた三種の追加注文の部分について色々と問題があることがわかりました。例えば、以下のようなとき、シミュレータはどのように自動車を操作すれば良いでしょうか？
- 「0 秒で車線変更を完了させてほしい」と注文されたらどうする？
- 「0 m 進んだ地点で車線変更を完了させてほしい」と注文されたらどうする？
- 「0 m/s のペースで横にズレるよう車線変更を行ってほしい」と注文されたらどうする？
答えは、「シミュレータ毎に異なる」です。実際にどうするべきかは、シミュレータの実装者各々が考える必要があります。OpenSCENARIO が定めるべきことではありません。OpenSCENARIO は世界の様々なシミュレータに対して搭載されることを意図されて設計されているため、挙動の仔細はシミュレータに一任しています。これは、例えば非常にリアルに摩擦や慣性、運動モデル等を考慮するようなシミュレータがあるかも知れませんし、一方で、リアルな挙動は度外視した単純なシミュレータもあるかも知れないからです。では TIER IV のシナリオシミュレータはどうなのかと言うと、後者に近いと言えます。
TIER IV のシナリオシミュレータは、特に「Autoware は判断を正しく行えているか？」をテストするために開発されています。つまり、Autoware の大量の機能のうちプランナと呼ばれるモジュールだけをテストしたいのです。具体的には、センサーが信じられないほど完璧に動作し、道路は全く滑らない完璧なコンディションで、車両も制御命令に対して完璧に追従してくるような状況、つまり Autoware が「自分以外のせいで上手くいかなかった」と一切の言い訳ができない状況下でシミュレーションすることが求められています。つまり、リアルであることよりもシンプルでノイズが無いことが重要というわけです。
そのようなシナリオシミュレータのコンセプトを踏まえて、今回は次のように実装することにしました。
- 「0 秒で車線変更を完了させてほしい」と注文されたら、隣の車線へ瞬間移動する
- 「0 m 進んだ地点で車線変更を完了させてほしい」と注文されたら、隣の車線へ瞬間移動する
- 「0 m/s のペースで横にズレるよう車線変更を行ってほしい」と注文されたら、まっすぐ走る（車線変更は永遠に終わらない）
つまり、シナリオに記載された内容を愚直なまでにそのまま実行してみせる、というものです。シンプルさを最大限に重視した形ですね。
ここでシミュレータのコンセプトを守りつつ取ることの出来る選択肢は、他にもいくつか存在します。その中でももっともありふれた選択肢は「現実の車はそんな動きはできない」というエラーを通知して、シナリオシミュレーションを中断するというものでしょう。ただし、この方法ではどこまでが現実的で、どこからが非現実的なのかのルールをきちんと定める必要があります。ルールと言うよりは、きちんと物理挙動を計算する必要がある、といったほうが正しいかも知れません。その点、この実装は言われたとおりにすればよいだけなので間違いがありませんし、軽量・高速に計算ができます。
この実装が選択された決め手は、「シナリオシミュレータは単体で TIER IV が行いたいシミュレーションの全てをカバーする必要はない」という、ある種の妥協でした。先にも少し触れたように、TIER IV はシナリオシミュレータ以外にも複数のシミュレータを開発しています。例えば、シナリオシミュレータとは真逆の、リアルな摩擦や慣性・運動モデル・センシングを模擬するシミュレータがあれば、実際に計測されたセンシングデータを元にした物体認識機能のテストに特化したシミュレータもあります。そうした事情を考慮して、非現実的な動作をも実行できてしまうという今回の選択の懸念点は、むしろ「ひとつくらいそういうことが出来るシミュレータがあったほうが便利（かも知れない）」と気楽に捉えることにしました。
車線変更命令の他の問題点についても、同様の方針で実装を行いました。例えば、車線変更命令には先の三種の追加注文の他にも、車線変更の軌道を指示することが可能です。指示できる車線変更は以下の四種類です。
- f(x) = A * x³ + B * x² + C * x + D
- f(x) = f_0 + rate * x
- f(x) = A * sin(x) + B
- 瞬間移動
こちらもこちらで厄介です。軌跡の概形しか示されていないため、細かいパラメータはシミュレータ実装者側で決める必要があります。さらに、特に厄介なのが二番目で、これは字義通りに捉えるのならば、「車線変更を始める瞬間にカクッと車を斜めに向けて、そのまま一直線に車線を斜めに横切り、またカクッと正面を向いて完了」という、非現実的な挙動になります。車線変更開始時と終了時に、カットインする方の車に乗っている人には無事では済まないほどの G が掛かってしまうでしょう。
とは言え、この二番目の軌跡には幾らか解釈の余地があり、例えば「この数式の軌跡を努力目標として、現実的な範囲で数式に近い車線変更を行う」としても良いでしょう。ただ、この方法には、シナリオを書いた人にとって、実際にどのような動きになるかがシミュレーションを行うまで分からないという欠点があります。そのため、TIER IV のシナリオシミュレータでは、やはり、シナリオに記載された内容を愚直なまでにそのまま実行してみせることとしました。率直に言ってテストとしては役に立たないレベルで非現実的かもしれませんが、シナリオを作成する過程においては挙動を頭に思い浮かべやすいという点で便利かも知れないためです。
ちなみにこの数式ですが、OpenSCENARIO 規格にはこれらの数式が示されているのみで各変数の説明がありません。説明がなさすぎて意味不明なのですが、察するにこの式は車線変更の様子を真上から眺めたときの車両の移動軌跡を示しているのでしょう。つまり、x が車の正面方向軸で、単位はメートルであると思われます。となると f(x) は車線変更開始時点の位置からの左右方向の差分でしょうか。正負、つまり左右の区別は実装側で上手いこと辻褄を合わせるしかありません。
加えて、今回のカットインシナリオで指定されていた軌跡こそがこの不自然な二番目の軌跡だったことが最も大きな難点だったかも知れません。結局、これについては三番目の軌跡も実装しておいて動かしてみてから考えることとしました。
シナリオを動作させよう！
最終的に、今回のカットインシナリオには以下の変更を施しました。
- OpenSCENARIO 0.9.1 から 1.0 へ書き換え
- カットインされる側の車両を自動運転車とするための TIER IV シナリオシミュレータ特有の命令
- いくつかのパラメータの不備の修正
TIER IV シナリオシミュレータ側で行った対応は未実装であった OpenSCENARIO の車線変更命令の実装です。
そして、これらの対応をによって動作に成功したカットインシナリオがこちらです。まずは、非現実的な直線軌道でカットインを行うシナリオの実行の様子です。
青枠で囲われた車が強引にカットインを行う様子がきちんとシミュレートできています。カットインされる方の車両、つまり緑枠の車両は自動運転車役で、その裏には本物の Autoware が接続されています。シミュレータが上手に実車のデータに似せたそれを Autoware と送受信しているため、Autoware は現実の公道を走行していると思い込んでいるわけです。
青枠の車のカットインを検知した自動運転車（Autoware）はすぐに急減速、しばらく様子を伺って、問題ないようだと判断するとまた走行を再開する様子がきちんとシミュレートできています。
次は、非現実的な直線軌道ではなく、現実でも有り得そうな滑らかな軌跡でカットインさせてみたシナリオの様子です。
Autoware が、先の非現実的なカットインよりも幾らか緩い減速をするようになっていることが分かります。結局、非現実的なカットインはそうでないカットインとは少々異なるシミュレーション結果をもたらしてしまうようです。
ただ、結果が異なるため非現実的なカットインは使い物にならないと一概に断ずることはできないため、これらの妥当性はこれから評価していくことになります。シナリオシミュレータは自動運転システムをテストするためのものですが、なんと次はシナリオシミュレータが自動運転システムのテストとして妥当なのかがテストされる番というわけですね。
まとめ
JARI・名古屋大学とのプロジェクトにおいて、SAKURA Project のカットインシナリオを TIER IV のシミュレータで動作させることに成功しました。この成功によって、TIER IV のシミュレータを ISO 規格の準拠判定に用いることができるかもしれないと分かりました。
今回のプロジェクトでは、標準規格に基づいたシナリオ記述言語を採用し、規格の範疇に収まるよう注意深くシミュレータへの実装を行うことで、他社・他団体で作成されたシナリオを僅かな変更で動作させられるということも確認できました。規格に準拠してシナリオ記述言語を実装することは、シナリオ記述言語の事情とシミュレータの事情、そして自動運転システムの事情とを上手に取り持つ必要があるため簡単な作業ではありませんが、相応のリターンを得ることができたと手応えを感じています。
TIER IV・Autoware Foundation によって書かれたシナリオが他社や他団体のシミュレータで動作し、他社や他団体で書かれたシナリオが TIER IV のシミュレータで動作する、そうして Autoware のみならず世界中の自動運転システムがより安全になっていけば良いと TIER IV は考えています。
長い記事でしたが、ここまでお読み頂きありがとうございました。最後に、TIER IV ではシミュレータとそれに連なるツールチェインを一緒に開発していただけるメンバーを募集しています。この記事を読んで TIER IV のシミュレータ関連業務に興味を持って頂けた方は是非以下のページからご応募ください。
Contact
For job opportunities, visit here.
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
