ニュース
【GTCJ2015】NVIDIA、エレクトロビットらが自動運転プラットフォームを積極アピール
自動運転の実現に向けて必要となる技術などを多数解説
（2015/9/23 00:00）
- 2015年9月18日開催
半導体メーカーのNVIDIAは9月18日、東京・虎ノ門ヒルズフォーラムでGPUテクノロジーをテーマにしたセミナーイベント「GTC Japan 2015」を開催した。市場が拡大し始めているディープラーニングや自動車の自動運転に向けた取り組みにフォーカスした内容となっており、GPUの果たす役割について解説し、具体的なソリューションや製品の紹介・展示を行った。ここでは、数ある講演の中でも自動運転に関わる内容についてお届けする。
アウディの新型「TT」シリーズに基礎技術が投入された「DRIVE PX」「DRIVE CX」
NVIDIAのシニア・ソリューションアーキテクトである馬路徹氏は、ADAS（Advanced Driver Assistance Systems：先進運転支援システム）の仕組みと、同社の自動運転プラットフォーム「DRIVE PX」、メーターパネルやインフォテインメントの処理を司るコクピット・プラットフォーム「DRIVE CX」について解説した。
まず馬路氏は、ADASの基本的な技術構成要件を説明。ADASは大まかに、走行環境や障害物などを認識するためのカメラ、センサー類に加え、GPSによる位置情報や道路・交通情報などを連携させる静的・動的な地図データを含む「地図モジュール」、周囲の状況を理解・予測して自動車の動作のさせ方を判断する「人工知能モジュール」がある。さらに、実際に車両の挙動をコントロールする「速度制御モジュール」と「操舵制御モジュール」、自動操縦と手動操縦の切り替えやシステムの稼働状況の表示を担う「HMI（Human Machine Interface）モジュール」で構成される。
このうち、地図モジュールと人工知能モジュールの両方を、同社が開発するDRIVE PXはカバーする。DRIVE PXはTegra X1を2個搭載し、複数のカメラやセンサー類をリアルタイムに制御可能なプラットフォーム。欧州の自動車メーカーなどが策定したECU向け汎用車載ソフトウェア規格「AUTOSAR」（オートザー）に準拠したマイクロコントローラも内蔵し、安全性を担保するシステムとの連携も可能にしている。
このDRIVE PXの性能は、駐車場において空きスペースを見つけ、実際に駐車を完了するところまで全自動で行えるレベルまですでに達している。アウディがCES（Consumer Electronics Show）で公開した各種の自動運転車もNVIDIAの技術をベースにした自動運転制御モジュール「zFAS」を搭載。搭載しているのは1世代前のTegra K1ではあるものの、正確に障害物を検知し、自動的に回避することが可能となっていることを示した。
一方でDRIVE CXは、メーター類や車内インフォテイメントを高度なグラフィックスで表現するプラットフォーム。自然言語処理も得意としており、ドライバーが目や手を離すことなく運転に集中できる、音声コマンドでの車載システムの操作が可能。新型アウディTTシリーズも、リッチなグラフィックスでメーターパネルを表現する「アウディバーチャルコックピット」を採用しているが、これもNVIDIAの技術を利用している。搭載されているものは2世代前のTegra 3とのことで、最新のDRIVE CXではさらに質感のあるグラフィックス表現が可能だという。
自動運転で重要となる物体認識の手法についても解説された。従来の物体検知においては、例えば人物については「HOG（Histograms of Oriented Gradients）」というアルゴリズムを用い、道路標識は四角い物体を検出してからその中身の文字を読み取る、という手法。他車や道路の白線の検知も、それとは異なるアルゴリズム、テクノロジーで認識する仕組みになっている。
これに対してディープラーニングを用いた手法では、学習のさせ方次第で、それら複数のオブジェクトのパターン認識を共通のアルゴリズムでカバーできるだけでなく、人物がなにをしているか、他車はどういったタイプのクルマか（スポーツカーか、トラックか、警察車両か、など）といったさらに細かい部分まで認識・把握が可能になるとした。
ただし、ドライビングの安全性やシステム全体の機能安全性を考慮した場合、ディープラーニングを活用できるDRIVE PXやDRIVE CXであっても、現状ではそれぞれ1台（ECU 1個）ずつを使えば十分ということにはならないかもしれないとも馬路氏は語っている。万が一システムにエラーや問題が発生した場合、フェイルセーフ（故障を前提とした安全設計）の考えでは、複数台を並列動作させた方が都合がよいケースもある。馬路氏は「どんどん性能は上がっていくので、将来的にはDRIVE PXを1台か、少ない台数でまかなうこともできると予想している」と期待感を示した。
故障時にどう対処するか。「機能安全」が自動運転の課題
9月16日にフランクフルトショーでNVIDIAなどとの提携を発表したフィンランドのElektrobit。その日本法人であるエレクトロビット日本の柳下知昭氏が、自動運転の実現で必須となる機能安全性に関わるアーキテクチャーについて詳しく解説した。
Elektrobitは自動車向け車載ソフトウェアを中心に開発しており、7000万台の自動車と10億もの組み込み機器に採用されている実績を持つグローバル企業。欧米、オセアニア、日本を含むアジア地域などに拠点を構え、従業員数は1900人以上。タイヤや車載システムの開発を手がけるコンチネンタルの子会社でもある。
Elektrobitの強みは、インフォテイメント用ソフトウェアと、AUTOSARの規格に準拠したECU用ソフトウェアを長年に渡って自動車メーカーに提供してきていること。最近ではコネクテッドカーに向けた取り組みや、ADASに関わるソフトウェア開発も加速させている。
そうした自動運転に対して、柳下氏は「複雑性」「コンピューティングパワー」「セキュリティ」「機能安全」という4つの課題点を挙げる。「複雑性」と「コンピューティングパワー」については、BMWやフォルクスワーゲンが提示した資料を引用し、昨今の自動車では150のソフトウェアコンポーネントで1つの車載システムが形成され、コンポーネント間の接続数は1000以上にもおよぶことを示した。
この規模と複雑性は年々増しており、比例して車載システムの処理能力も高めていく必要がある。AUTOSARのような標準化された車載制御システムを活用することが、複雑性に対処する1つの手法だと述べた。
3つ目の「セキュリティ」は、外部からのハッキング・クラッキングのような攻撃からの防御を指す。この外部からの攻撃へのセキュリティ対策を行っておくことが、後述する「セーフティ（機能安全）」が成り立つ前提条件であり、逆に「セキュリティを守るにもセーフティが必要」であると同氏は語った。
最後の「機能安全」については、車載システムなどに故障が発生した場合、自動運転車においてはどのような挙動とするのが正しく、本当に安全な処置になると言えるのかという点が大きな課題となる。例えば現在の「フェイルセーフ」の考え方では、問題が発生した際にパワーステアリングやブレーキなど一部を除き車両の機能をほぼ全て停止・制限させ、ドライバーに通知するとともにその履歴を記録する処置が取られる。その後の対処はドライバーが引き継ぐという形だ。
ところが、自動運転へと向かうにつれ、こうした考え方はだんだん通用しなくなってくる部分もある。現在は一部車種で高速道路などの特定条件下で自動運転を支援する機能が実現しているが、この場合は基本的にドライバーがステアリングを握っているため、これまでと同様の考え方でもそれほど問題はない。しかし、ステアリングに手をかけないレベルの自動運転になり、さらに乗員が眠ってしまえるような完全自動運転へと移行する段階になると、故障したからといって即座に機能停止してドライバーに操縦をゆだねるわけにもいかなくなる。数秒から数分間は機能を維持したまま、自動運転を続けなくてはならない可能性もある。なにが起こったのかをドライバーなどの乗員にどうやって理解させ、どのような処置を取るのが最も安全なのか、詳細な検討が必要だ。
機能安全の課題に対しては、車両制御システム（ECU）における方策がいくつか示された。1つは「1oo2（1 out of 2）」と呼ばれるECUを2つ並列に置く方法で、両方で同じ処理を行い、処理結果が一致しなくなった時に故障であると判定する仕組みだ。しかし、これではどちらのECUが故障したのか分からず、どちらを正として機能続行、もしくは停止すればよいのか判断できないことから、自動運転には向かない。
もう1つは「2oo3」という、ECUを3つ並列に稼働させ、1oo2のときと同様に3つの処理結果が一致しない場合は故障したと判断する方法。この場合はどのECUが故障したのか特定可能で、残り2つのECUで自動運転を継続できる。ただし、ハーネスの本数、重量、消費電力、複雑性、コストなどの面で新たな課題が残る。
それらの問題を解決するのが「1oo2D」という方法。ECUは2つだが、それぞれで処理内容を逐次チェックする仕組みを設け、どちらのECUが故障したのかを検知できるようにするものだ。また、「1oo2D」の仕組みに、最低限必要の機能を実行するだけの処理能力を備えた3つ目のECUを追加し、2つのメインECUの一部機能に問題が発生した場合には、問題のある機能だけを3つ目のECUが肩代わりする、といったアプローチも考えられるとした。
とはいえ、最後の機能を肩代わりするアプローチは、1つ1つの機能を動的に再配置可能なシステムである必要がある。この点についてはElektrobitの得意分野であるAUTOSARのプラットフォーム自体がサポートしていると述べた。NVIDIAが採用するDRIVE PXとそれに対応するElektrobitのソリューションは、AUTOSARとADASを別々のマイクロコントローラーで制御する方式を採用しており、セーフティ、セキュリティ、パフォーマンスの3つを同時に達成できるプラットフォームであると強調している。
Teslaサーバーで1日に100万km分をディープラーニング
ハンガリーのソフトウェア開発会社であるAdasWorksのラスズロ・キションティ氏は、AdasWorksが持つ自動運転向けシステムの概要を紹介し、NVIDIAのGPUを用いることのメリットをアピールした。
AdasWorksが自動運転に向けたカメラ画像の処理に関わるビジネスを始めたのは約6年前から。急速に進化していくカメラは、十分に高解像度でありながらすでに1個当たり25ドルほどの価格になっており、1個のオーバースペックなカメラより、複数の安価なカメラを同時に搭載した方が、コストがかからず容易に広い視野の情報を得られると話す。
カメラから得られた映像を処理し、自動運転のために障害物などを検知するには、馬路氏が話していたとおり、これまでは人、自動車、信号機といったオブジェクトの種類ごとに識別するアルゴリズムを変えなければならず、処理コストが大きく非効率だった。対して、アルゴリズムを1つに集約できるという点でニューラルネットワーク（ディープラーニング）のメリットは大きい。
ただし、検知するだけではなく、同時に“予測”することも必要になる。例えば歩行者が子供だったりすると、もしかすると不意に車道側に飛び出してくる可能性もあり、それに備えて徐行する必要があるかもしれない。反対に、まっすぐ（車道と並行に）走っている歩行者であれば、おそらく車道に飛び出してくる可能性は低いだろうから、スピードを落とさなくてもよいという判断になるだろう。とはいえ、万が一の場合に備えてアルゴリズムが慎重になるあまりに、なにも起きないのにどんどんスピードが落ちていくのはドライバーにとってはストレスだ。
AdasWorksでは、車両の前後左右に設けた4つのカメラ映像を同時に処理することで、周囲360°の視野で他車との距離や障害物を検知し、その位置を考慮して走行可能な「フリースペース」を色分け表示するシステムを作っている。衝突危険性の高い車両やガードレール付近を強調表示するようにもなっており、“予測”をある程度実現したものと言えるだろう。
これはNVIDIAのTegra X1を利用したシステムだが、AdasWorksがNVIDIAのチップを選択しているのには理由がある。自動運転に関わる機械学習においてはリアルタイムで実際に走行しながら車載システム上で学習する必要がなく、撮影済みの映像さえあれば間に合う。NVIDIAのハイエンドGPUであるTeslaを搭載したサーバーに必要な映像を学習用データとして流し込み、GPU処理によるディープラーニングで処理する場合、同じNVIDIAのアーキテクチャーが採用されているTegraが車載されていることは相性面で大変都合がよいからだ。
高性能なサーバー上では、数十台から数百台分の映像を同時に学習でき、1日に100万km分の映像を学習することも可能になる。あらゆる不測の事態を想定した形で機械学習を短時間かつ大量に行えるのは、認識精度を向上させる上で大きなメリットだ。また、学習した結果はオンライン経由でアップデータを配布することにより、すぐに車載システムに反映することができる。
自動運転の実現に向けてはAdasWorksとしてもまだまだ課題が多く、道半ばではあるようだが、「将来発売される車両に対して提供し、2018年にはさまざまなクルマの進化を実現していきたい」と話した。