ティアフォーは自動運転システムをどう評価しているか　自動運転ソフトウェア特化型・シミュレーション実行基盤「Evaluator」開発の裏側

登壇者の自己紹介とアジェンダの紹介

徳永誠氏：本日は、私から「自動運転システムの評価とそれを支える評価基盤の概要」ということで、大枠の話にはなってしまうのですが、私たちティアフォーがどのように自動運転の評価をやっているかについてお話しさせてもらえればと思っています。

（スライドを示して）本日のアジェンダです。ざっくりと自動運転システムとはどのようなことかと、それを評価するためのストラテジーについて。最後に、私たちのプロダクトの紹介と、どのようなことを今後やっていきたいのか、フューチャーワークなどについて話せればと思っています。

（スライドを示して）まず、簡単に自分の自己紹介からお話しさせてもらえればと思っています。私は名前を徳永といいます。今はティアフォーで、CI/CDチームのチームリードをしていますが、もともと大学院の頃は、多物体追跡の研究を行っていました。

その後、ワークスアプリケーションズという会社でクラウドのシステムとSREですね、運用やシステム開発などを行った後、ティアフォーに2018年7月頃にジョインしています。

自動運転システムの意義は「安全な社会を実現する」こと

さっそく、Autonomous Driving Systemというところで、自動運転システムの簡単な概要についてお話ししたいと思います。

（スライドを示して）なぜ、Autonomous Driving System、自動運転システムが今必要になっているのかというと、やはり自動運転システムの意義は、「安全な社会を実現する」というのが一番大きなところになっています。

右下の図は少しショッキングな話ではあるのですが、特に若い年齢の方の死亡理由の中で、不慮の事故と呼ばれているものの割合がとても多くある状態になっています。

この不慮の事故は、さまざまな要因があるのですが、実はこの中の3分の2が交通事故と、その関連の死因であると言われています。

やはり交通事故など、自動車が関わってくるものが、若年者の死亡理由を大きく占めているので、こういった課題をどのように解決していくのかがこれからの社会課題に対して、大きな意義となります。

世界を見ると、年間だいたい130万人が交通事故で亡くなっているとも言われています。例えばボーイング787、大型の旅客機が12機墜落する規模感の事故が、毎日のように起こっているという現状になっています。

規模が違うので、完全に自動運転と比較することはできないかもしれませんが、数として見るとやはり大きなもの、ということが言えるのではないかなと思っています。

また、もう1つの意義としては、自動運転社会において時間を有効活用していくことが、大きいと思っています。

特に車社会のアメリカなどでは、通勤に平均1時間ほどかかっているというデータもあり、この時間をどれだけ有効活用できるかが生産性を上げる取り組みなどにつながっていくかなと思っています。

自動運転を設計する上での必要な機能をすべて有するOSS「Autoware」

私たちは自動運転システムの開発をしている会社ですが、その中で「Autoware」と呼ばれているシステムをメインでコントリビュートしています。

Autowareは、OSSとして公開されているもので、正確にいうと弊社ティアフォーのものではなく、the Autoware Foundationと呼ばれる独自のNPO法人が運営しているものになります。

基本的には、誰のものでもなくみんなのものではあるのですが、メインとしてコントリビュートなどを行っています。

このAutowareはどういったものかというと、自動運転システムを設計するにあたって必要な機能などをユーザーが自由に組み合わせて、目的に合ったシステムを構築できるものです。

このAutowareは世界を見ると、30以上の車や20以上（の国）、500以上の会社で使われた実績があります。

自動運転ソフトウェアのビルドとテストケースを実行をサポートする「Web.Auto」

（スライドを示して）ここでもう1つ、ティアフォーが開発しているプロダクトに、「Web.Auto」というものが存在します。これはどういったものかというと、Autowareなどを活用した自動運転システムの開発だったり、それを運用をしていきたいユーザーに対して、サポートすることを目的としたWebサービスです。

一連の流れとして、Develop、Build、Test、Deployment、Operation、Data Collectionと、そういった開発から実際の運用までの流れをWeb.Autoはサポートしていて、それぞれのステップに合ったサービスを提供しています。

今回話すのは、（スライドの）左上のほうにある「CI/CD PIPELINE」と呼ばれているところで、基本的にAutowareシステムのDevelopment、Build、Test、一部Deploymentなどをつかさどっているシステムです。

自動運転システムをどのように評価するのか？

では、自動運転システムをどのように評価していくのかについて、簡単にお話しさせてもらえればと思います。

（スライドを示して）自動運転システムで、何が難しいのかと言われると、やはり安全性の担保です。最初のスライドで紹介したとおり、自動運転の意義は、どれだけその事故を未然に防げるかや、どれだけ安全な社会を実現できるかにかかっていると思っています。

それを実現するにあたって、事前の評価としてどのようなことをやっていけばよいのか、どのような評価プロセスを用いて、どのような評価方法を用いればいいのかといったところがやはり難しくなっています。

これは、よくあるV字のプロセスではあるのですが、例に漏れず自動運転も、大きく分けるとこのようなプロセスで順に評価などを行っています。

左からデザインのところで、設計の部分から要求分析、要件定義、基本設計、詳細設計。そして評価のところで、単体テスト、結合テスト、システムテスト、受け入れテストと、順に階層が下に下がって、それから上に上がっていくという、よくあるプロセスになります。

リリースされるまでにどのような評価を行うかというと、本当に安全かを確認するにあたって、実際の車両を用いて、あらかじめ用意したすべてのテストケースをテストしていければ、一番それが確実かなとは思います。

しかし、実際にそれをやりきるのは難しいことになってしまいます。例えばテストケースとして1,000、2,000。もっと大きな数も実際には動いているのですが、そういったレベルの話であったり、実際にその車両を用意したり、それをオペレーションする人員を用意したり、場所を用意したりと、さまざまなコストがやはりかかってしまいます。

なので、なるべく低コストに抑えつつ、なおかつ安全だよねと証明する評価手法が必要不可欠になってきます。こういったことを行うために、ティアフォーでは、よくあるシステムテスト、結合テストのような段階、フェーズにおいて、シミュレーションを使って評価を行うようにしています。

各シミュレーターの特性を加味してワークフローを組み立てている

今回は、このシミュレーションに対してどのような評価を行っているのかについて話せればと思います。

（スライドを示して）先ほど用いたシミュレーションの評価です。ティアフォーではさまざまなシミュレーターを、（私たちとは）別のSimulation Teamが開発しています。

さまざまなシミュレーターがありますが、やはりシミュレーターの種類によって得意なところや、どのようなAutowareのコンポーネントを評価するのかといった、得意、不得意なもの、ターゲットが違ったりと、さまざまな特性が存在します。

例えば、（スライド）左上の「Driving Log Replayer」と書いてあるところは、センサーやカメラを事前に持っておいて、その実際のデータを流して認識や自己推定といった、結果の評価を行っています。

また、真ん中の「Scenario Simulator」と呼んでいるところは、ほかの車両や後方車、あるいは信号など、情報をあらかじめ与えておいて、Autowareがどのように振る舞ったのか、判断したのかといったものを評価します。

次の「AWSIM」と書いてあるところは、ゲームエンジンを用いることで、センサーや、車両のアクチュエーションをシミュレーションします。よくあるエンドツーエンド的なシミュレーターですね。Autowareの入力から出力までを一貫して評価することができます。

このように、シミュレーターごとに特性があるので、このシミュレーターをさまざま組み合わせることによって、自動運転システムの評価のパイプラインやワークフローを組み立てています。

シミュレーションのプラットフォームをクラウドを利用して開発している

現在ティアフォーで運用しているこのシミュレーションのテストケースの数は、実は今すでに2,000テストケースほど存在していて、今の1回のリリースでは、2,000件から3,000件ぐらいテストケースが実行されています。

実際に、1テストケースにシミュレーションが5分かかるとなると、単純計算で2,000件×5分で1万分。これを日数に直すと7日程度の時間がかかってしまいます。

いくらシミュレーターを使って効率化できたとしても、どれだけこれの並列性を増して大規模に実行するかといったところが、やはりまだ問題として残っています。

（スライドを示して）私たちCI/CDチームがどのようにしてこれを解決しているのかというと、このシミュレーションを実行する基盤をクラウドで作ってしまおうといったところで、このシミュレーションのプラットフォーム、評価基盤をクラウドを利用して開発しています。

評価基盤は、設計から評価までというやつですね。先ほどのV字のプロセスの流れを高速かつ低コストに行って、よくある「V字プロセスを設計したきり、そしてそのまま開発したきり」というかたちではなく、なるべく高速かつ低コストに回すことで、よりアジャイルに近いサイクルを回すことも目的とした評価基盤の作成を目指しています。

例えば設計のところで、評価のテストケースをブラウザ上で誰でも簡単に作成できて、それを管理することが可能であったり、開発のDevelopの段階で手元の環境でシミュレーションをすばやく実行でき、開発者の素早いフィードバックにつながっていきます。

Testの評価のところでは、例えばコードの修正をトリガーにして、クラウド上で大規模にシミュレーションを実行します。

最後のAnalysisでは、大規模にしたシミュレーションの結果の傾向の分析や、あるいはより詳細なデータの解析ができる基盤を作成しています。

Autowareの自動運転の評価に特化したシミュレーションの実行基盤「Evaluator」を開発

具体的にどのようなものを開発しているのかをお見せできればと思います。

（スライドを示して）画面が拡大できないので、すみません、ちょっと簡単に言葉だけでやります。「Evaluator」と私たちは読んでいますが、Autowareの自動運転の評価に特化したシミュレーションの実行基盤として作成しています。

先ほどのスライドで説明したように、さまざまな複数のシミュレーターを活用して、より低コストにさまざまなテストケースを評価できることを目指しています。

シミュレーションをする時も、例えば自動運転システムは、パーセプションを行うためだけのハードウェアを用意したり、あるいは、LiDARや点群データを処理するためだけのコンピューターを用意したりと、状況、やりたいことによってハードウェアの構成などから大きく変わってしまうという要望があります。

そのようなハードウェアの構成もクラウド上で模擬するために、その構成などもクラウド上で再現できるようなシステムとなっています。

クラウドを利用することで、高いスケーラビリティも担保できるようになっていて、先ほどお話ししたように、同時に2,000件のテストデータのシミュレーションが実行される時でも、それをさばききる評価システムとなっています。

また、ここでは明確に触らないのですが、評価したシステム、リリースしたAutowareを、OTAアップデート、Over The Airで遠隔地からアップデートする機能も、Web.AutoのFMS、Fleet Management Systemと連携することで実現可能になっています。

アーキテクチャの説明

（スライドを示して）どのようなアーキテクチャを採っているか。簡単にですが紹介できればと思います。私たちは、クラウドを用いてWebのシステムを開発していますが、基本的にはマイクロサービスアーキテクチャと呼ばれる構成を採っています。

ここでは、細かいところまでは出しませんが、今現在、実はここに書ききれないだけの小さなマイクロサービスなどもあって、おそらく今は20前後ぐらいのマイクロサービスがCI/CD基盤の中で動いています。

この後話そうとしているのが、実際にシミュレーションをするためのクラスターを構成しているところと、実際にそのクラスターを「EKS」「Kubernetes」を使って管理をしているのですが、そこのクラウドの実行部分、あとは、実際のベンチ環境ですね、実際の実機の環境とつなげるところが今回の話のスコープとなっています。

クラウド基盤開発は何が難しいのか？

このようなクラウド基盤を作っていくにあたって、どういったことが難しいのかについて、簡単に話せればと思います。

まず、実機とハードウェアと、クラウドのコンピューティングリソースの差分が問題となってきているというのがわかってきています。

これはどういったものかというと、例えばハードウェアと、実際に動いているシステムと、CPUのアーキテクチャ、あるいは周波数、コア数、もっと言うとキャッシュのメモリ、あるいはCPUのトポロジーなどです。

実際に動くハードウェアとクラウド上で用意できるリソースの差分が出てきます。まったく同じものをクラウド上で用意していくのは、やはり困難であるという問題があります。

また、さまざまなECUを用いたハードウェア構成に関しては、先ほども話したとおり、車両の中には、複数台のハードウェアを組み合わせて、1つの自動運転システムが構築されています。

そのような自動運転システムに対して、実機の中ではほかのコンポーネントがほかのリソースの中で動いている、ハードウェアの中で動いているけれど、クラウド上では実は一緒になっていたり、そこのハードウェアの構成も、シミュレーションで再現できないといけないと言われています。

また、同じクラウド上だけの話ではないのですが、そもそものシミュレーションとしての再現性をどのように担保していくのかも課題にはなってきています。

まったく同じリソースを割り当てて、100を超えるプロセスが同時稼働しているAutowareの中で、自動運転システムのシミュレーションの結果をもう1度実行したからといって、まったく同じ結果が再現できるのかというと、そこを担保するのは、やはりまだ現代の技術としては困難です。

「Environment Parity」の考え方をベースに解決していきたい

このような課題があるのですが、私たちはEnvironment Parityと呼ばれている考え方をベースに課題を解決していきたいなと考えています。

自動運転システムの評価の観点で、実際に利用するハードウェアとクラウドで提供可能なコンピューティングリソースの間の環境の一致性のことを、私たちはEnvironment Parityと呼んでいます。

このEnvironment Parityが満たされていれば、自動運転システムを評価するにあたって十分だと言えれば、より低コストに、より安全に自動運転システムを評価できる評価基盤の構築が可能になるだろうと考えています。

逆に言えば、自動運転システムの安全性を担保するにあたって、ある機能を利用するには、どういったEnvironment Parityが満たされればよいのだろうかということを自動運転システムの設計側から考えてみる。ティアフォーは評価基盤を作っているチームと自動運転システムを開発しているチームが近いので、こういった話もよりやりやすい環境ではあるかなと思っています。

こういったところで、このEnvironment Parityという考え方をきちんと整理して、これを満たすことで自動運転システムとして評価可能である、安全であると言えるような評価基盤を、今後のフューチャーワークとして考えています。