Technical Information
これからの車載ソフトウェア開発と品質保証
自動運転や高度運転支援への対応、より高度なセキュリティの実現など、車載ソフトウェアへの要求が多様化する中、ODD(Operational Design Domain:運行設計領域)やシナリオベースの品質保証など、国内外のさまざまな取り組みが発表されるようになりました。ソフトウェアの開発方法やその品質保証の方法もこれらの取り組みや技術に合わせて変えていかなければならない部分があります。
本講演では、そうした車載ソフトウェアを取り巻く環境の変化や背景を整理した後、これからの開発方法や品質保証に求められる要件を解説します。
※この記事は、『ベリサーブ オートモーティブ カンファレンス 2021』の講演内容を基にした内容です。
名古屋大学 大学院情報学研究科 准教授
株式会社ティアフォー 技術顧問
JSTQB技術委員
森崎 修司 氏 
車載ソフトウェアの変化
求められる環境想定の精緻化
まず車載ソフトウェアをめぐる状況として、利用環境を想定することの難しさについてお話しします。そもそも環境や利用状況についての想定は以前から簡単なものではありませんでした。現在、環境想定はいよいよ複雑さを増しています。場所(国)、環境、法令、走行時期(季節や時間帯)といった条件について、それまで人が行っていた判断や操作を、ソフトウェアでも担うようになってきたためです。
図1は、環境想定の難易度を表したものです。環境想定や制御が比較的容易な左側の「車体系」から、右側の「高度運転支援」や「自動運転」に向かって環境想定の難易度が高くなっていきます。そこには「他システムとの連携」や「ドライバーへのテイクオーバー※1」「路上障害物の判断」といった複雑な状況判断が求められることを示しています。今後、必要とされる環境想定は右側、より想定が難しい方へ向かっていくと考えています。
※1:自動運転システムによる対応が難しい場合に、システムが運転をドライバーに要求すること
ODDによる条件の明確化
環境想定が難しくなる中で求められているのが、ODDによる条件の明確化です。ODDとは、自動運転システムが正常に動作するための前提となる条件を定めたもので、「この前提が満たされないとこの機能は使えません」という条件をドライバーに確実に伝えるようにするためや、型式認定にも用いられます。
ODDの例として、国土交通省が公開している資料には次のような条件が示されています。
- 道路条件(自動車専用道路、一般道 など)
- 地理条件(山間部、設定済みジオフェンス など)
- 環境条件(天候、夜間制限 など)
- その他(速度制限、信号情報等のインフラ協調の要否 など)
例えば、車線逸脱警告やアダプティブクルーズコントロール(定速走行・車間距離制御装置)は、センサーがうまく稼働しないときにメーターなどのインジケーターで「機能しない」ことをドライバーに示します。これと同じように、想定されていない条件・場所である場合にもドライバーに伝えることが求められつつあります。
将来的にはこのODDが利便性や商品競争力につながっていくと思われます。無数にある条件の組み合わせから、適切にODDを定義することは非常に難しい判断を要します。テスト技術者や品質保証技術者が昔から取り組んできた絞り込みの技術が、複雑化する環境想定を支える技術として重要になります。
最初は確実に安全を確保できるような条件のみを環境想定として定義し、徐々に範囲を広げていくアプローチが一般的と言えるでしょう。これにはプロダクトを作る側より、品質保証する側が積極的にODDの設計に関与していく必要があります。
シナリオベースの品質保証
ODDで示された条件内で問題がないかどうかを確かめる方法として、シナリオベースの品質保証について見ていきます。シナリオを作成し、それを前提として開発したり、品質保証したりする手法が今後、主流になることが予想されます。
表は、ティアフォー社が公開しているODDをベースにしたシナリオ(ODDユースケース)の一部です。前方に車両がいない場所から発車する、同一車線内を走行する、路上駐車車両や障害物を回避する――といった具合に表の1行ごとにシナリオと対応する走行コースが示されています(図2)。開発も品質保証もこのシナリオとその組み合わせを前提として進めます。
表:ODDをベースにしたシナリオ(ユースケース)の例
出典: Tier Ⅳ Tech Blog https://tech.tier4.jp/entry/2021/04/07/160000
図3は、シナリオを階層化し、シナリオの組み合わせによってさまざまな状況を想定できるようにするためのものです。これは、自動運転を実社会で利用する際に考えなければならないことを整理するため、ドイツで発足した産官学共同のPEGASUSプロジェクトが公表した資料の一部です。
https://www.pegasusprojekt.de/files/tmpl/Pegasus-Abschlussveranstaltung/15_Scenario-Database.pdf を元に講演者が一部加筆
変化の少ないものを1層目として、下から、道路配置(道路の状態や道幅、車線数など)、標識・路側物、一時的な保守や事象(工事や一時的な通行止めなど)、可動物体(他の車両など)、環境条件(天候など)、V2X※2 と、6つの層に分けて条件を考えます。これらの層を組み合わせながら、さまざまなパターンでクルマが期待通り動くかをテストしていきます。
これらシナリオの条件を基にテストを生成し、テスト実行する流れを表したものが図4です。左から、シナリオデータベースにさまざまな各層の条件を入れておきます。条件の組み合わせによってクルマの振る舞いが変わることがありますので、それぞれのパターンについてテストを生成していきます。これについて実車テストやドライブシミュレータ、計算機上のシミュレーションでテストを実行します。
※2: Vehicle to Everything:車車間通信、歩車間通信をはじめとして車両と他のあらゆるモノとの間の相互連携を総称したもの
多岐にわたる要素技術
車載ソフトウェアの開発および品質保証の在り方が変わりつつある背景には、環境想定の複雑化のほか、自動運転や高度運転支援を実現するために多岐にわたる要素技術が使われるようになったことが挙げられます。主にセンサー、アルゴリズム、車外サービスとの連携などです。それぞれについて順番に説明します。
1.センサー
センサーについては、LiDAR(Light Detection And Ranging:レーザー光を用いたリモートセンシング技術)やアダプティブクルーズコントロールなどでよく使われるミリ波レーダー、さらにカメラ(単眼・双眼)などがあります。
このうち比較的新しいセンシング技術がLiDARで、センシング結果は点群あるいはポイントクラウドと呼ばれる粒の集合によって得られます(図5右側)。遠距離にある対象物を捉えられる一方で、カメラのように色を識別できないこと、また悪天候時のセンシングが弱点とされています。図5の右側の画像を人間の目で見ると形状などからクルマに見えるのですが、これをシステムにクルマだと認識させるのは難しい場合があるため、現状ではこのLiDARの情報にカメラやミリ波レーダーから得られた情報を組み合わせて対象物を判断するセンサーフュージョンという技術を使って推測することがあります。
出典:Kumar, G A.; Lee, Jin H.; Hwang, Jongrak; Park, Jaehyeong;
Youn, Sung H.; Kwon, Soon. 2020.
"LiDAR and Camera Fusion Approach for
Object Distance Estimation in Self-Driving Vehicles"
Symmetry 12, no. 2: 324.
2.アルゴリズム
センサーから得られた情報を基に物体を認識するアルゴリズムを図6に示します。
LiDARの画像に見られた粒の集合(点群)から対象を推測することをクラスタリングと言います。例えば、その形状から対象物がクルマなのか歩行者なのかをクラスタリングにより推測します。そこにLiDARよりも高い解像度と色の情報を持つカメラを用いた画像認識アルゴリズムや、レーダーによる前走車認識アルゴリズムを加え、これら複数のセンサーの結果を統合して判断していきます。
また、センサーごとに明るさ(時間帯)や天候などへの弱点や適性があるため(例えば、夜はカメラよりLiDARの方が正確な情報を収集でき、雨天時や雪の日にはLiDARよりレーダーの方が有効)、状況に応じてどの情報に重きを置いて判断するかを決めていく必要があります。こうした統合的な判断を行うのがセンサーフュージョンです。実際には非常に難しいところですが、効果的なアルゴリズムが開発されれば、高い価値を生む可能性を秘めています。
3.車外サービスとの連携
3番目の要素技術「車外サービスとの連携」として、ここではダイナミックマップに触れます(図7)。ダイナミックマップは、静的情報である3次元地図情報に通行規制などの準静的情報、事故情報などの準動的情報、周辺車両や歩行者といった動的情報を組み合わせたデジタル地図であり、これをネットワークから得ることで自動運転や高度運転支援に活用しようというものです。全体が4つの階層に分かれており、階層ごとに最新情報が反映されます。ダイナミックマップは、センサーが収集する情報より多くの、より詳細な情報をもたらすことで、自動運転をさらに安全で精緻にするものとして期待されています。現在はISO14296に向けて標準化が進められています。
出典:ダイナミックマップの概念/定義および、SIP-adusにおける取り組みに関する報告
https://www8.cao.go.jp/cstp/gaiyo/sip/iinkai/jidousoukou_30/siryo30-2-1-1.pdf
新しいタイプの欠陥とその対応
ここまで車載ソフトウェアをめぐる環境や要素技術について見てきました。これまでと同様に要素技術単体に対して故障モード影響解析
(FMEA)のような分析をして、単体では問題がないことを確認していても、特定の組み合わせだけで不具合が出たり、考慮すべき点が増えたりということが起こっています。ここ3、4年ほどの間で、こうした不具合や考慮すべき点をサイバーフィジカルギャップと呼んで、これに対する研究も進められています。
現実世界をセンシングしてコンピュータ上にモデル化し、モデルの上で分析して最適な結果を導き出し、それを現実世界にフィードバックするシステムを「サイバーフィジカルシステム」と呼びます。この現実(フィジカル)とモデル(サイバー)の間に「差」が生じることをサイバーフィジカルギャップと呼んでいます。
例えば、自動運転中のクルマの前方にクルマがある場合のサイバーフィジカルギャップを次の①~③で説明します(図8)。
- ①自動運転システムはセンサーから情報を取得します
(1.センサーによる情報取得) - ②この情報を基に前方の物体をクルマと判断します
(2.物体認識) - ③対象の位置を時系列で捉えて、前に進んでいるか、止まっているかを判断します。前方の車両が信号待ちなどで一旦停止しているとして後ろについて停車すべきか、駐車しているとして追い越すべきか判断し経路を選択します (3.経路選択)
この経路選択を間違うこともサイバーフィジカルギャップと呼ばれる欠陥の一つです。サイバーフィジカルギャップを防ぐには、まず、センサーやアルゴリズム単体での検証が求められます。センサーが壊れたことをどのように自己診断するか、物体認識の精度、経路選択の妥当性などを、これまでの車載ソフトウェアと同じように検証することになります。
「単体での妥当性確認」は既存の品質保証の方法である程度対応できますが、難しいのは、個々では問題なく見えるにもかかわらず、情報取得、物体認識、経路選択といったフィードバックループの中に一つ不具合が生じることによって問題がドミノ倒しのように後続のフィードバックループに悪影響を与えるケースです。例えば、センサーの一つが故障して自己診断機能が動き始めている間に別のセンサーの精度が落ちると、センサーフュージョンの物体認識アルゴリズムがそれを想定しておらず、結果として後続の経路選択で実現されている正しい経路選択が行われなくなるようなケースです。
これらはサイバーフィジカルギャップの中でも特に手ごわい不具合で、品質保証の現場ではこのようなコーナーケースをひたすら探して対処する必要があります。私もこうした研究に取り組んでいます。
セキュリティ
セキュリティは基本的に安全性の検証と似ていますが、いくつか異なる部分もあります。悪意ある攻撃者は次々に新たな脆弱性、新たな手口で攻撃してくるため、製品として出荷した後も継続的にこれらに対応していかなければなりません。スマートフォンやPCで随時行われているセキュリティアップデートのような頻繁なプログラムの更新が求められます。
また、攻撃対象となる機能の重要性により攻撃のレベルも変わってくるため、対策をどの程度に見積もるのかも難しい問題で、自動運転や高度運転支援のセキュリティを考える上では重要な課題になると予想されます。
どのように開発と品質保証を変えていくべきか
より精緻な品質保証と開発プロセス
これまでお話ししたように、自動運転や高度運転支援を前提として車載ソフトウェアは大きく変化しています。品質保証や開発についても、同時に仕組みを変えていく必要があります。
まず、プロダクト開発と品質保証をこれまで以上に独立させる必要があります。品質保証は品質保証として、プロダクトはプロダクトとして社会需要やコストに応じた開発をしていくことが重要です。図9に示した通り、今まではプロダクトに対してその仕様が満たされているかといった品質保証が中心でしたが、これからはよりユーザーや現実世界の要求に対して品質保証がどうあるべきかを考慮することが求められます。
次にテスト(テストケース)の増加を抑えることも重要です。例えば、派生型の開発をする場合、ある車種に対してテストを行う、次の車種には今までのテストに機能追加、機能変更分を加えてテストを行う、といった手法でテストしていてはテストが著しく増えてしまいます。従って、まずプロダクトを共通化し、共通化されたプロダクトの使用を前提とした全体のプロダクト群を定義して、それに合わせてテストする「プロダクトライン」の考え方を取り入れていかなければテストが肥大化していきます。
最後に開発プロセス(活動)についてですが、単体テストで検出可能なバグを、実車のテストで検出するようなことがあれば大変な手戻りにつながってしまいます。開発プロセスや開発活動ごとに、どのような欠陥が混入される可能性があって、それらをどのように検出するべきかという想定をこれまで以上にしっかりと持つ必要があります。
先ほどシナリオベースの品質保証について説明しましたが、他の車両の動きや天候などさまざまな条件を組み合わせてテストケースを作り出していきます。これを全て手作業でやるのは現実的ではありません。つまりテストケースの自動生成機能を前提としたテスト実行の自動化プラットフォームを作る必要があります。ハードウェアの開発に携わる企業では、すでに検査の自動化はかなり進んでいると思いますが、これからはソフトウェアでも当たり前になっていくと思われます。
継続的な開発の必要性
車載ソフトウェアの変化に伴い、継続的に開発・品質保証を続け、製品(ソフトウェア)に問題がない状態を維持することが求められるようになります。その典型例は、新たな脆弱性に対するセキュリティアップデートが必要になることです。
こうしたソフトウェアのアップデートを積極的に活用して次のようなことが実現できます。
・クルマ購入後に特定の機能を追加購入できるオンデマンド機能
・交通シナリオデータベース(ダイナミックマップなど)の随時更新
このような継続的なリリースを前提として、開発や品質保証のプロセスも変化させていかなくてはなりません。
おわりに
ここまで、自動運転や高度運転支援を支える技術や課題を通じて、開発や品質保証に対する新たな要求について俯瞰してきました。技術の進化に応じてさまざまな工夫が求められると同時に、継続的な開発・品質保証の重要性も浮き彫りになってきたと思います。
継続的な開発をするには、前提としてV字型開発からアジャイルに代表されるイテレーティブな開発にシフトしていくことが大切であり、私自身も現在ベリサーブ社と共同でこうした開発に適した品質保証の在り方について研究しているところです。成果などについてはブログやSNSでも発信していますのでご参照いただければと思います。
この記事をシェアする