ISO 26262およびシミュレーションベースのテストにより、自動化機能の安全性を向上

2018年9月19日：完全自動化実現への最も重要なステップの1つは、車両の自動運転システムの機能安全性を保証することです。「両目を閉じ、両手を離す」シナリオでは、エラーは許容できません。自動運転において、安全要件の妥当性はどのように確認するのでしょうか。

この場合、安全性を確保するためには車両レベルでのテストでは不十分です。ただし、ISO 26262のソフトウェア安全規格は実用的な選択肢になる可能性があります。

ISO 26262のVサイクル開発プロセスを採用することにより、自動車メーカーやサプライヤは、自動化機能の安全システムにおける開発基盤を構築することができます。ISO 26262への完全な適合を実現するには、要件に関するテストの計画、規定、実行、評価、および文書化を含む、体系化された方法でソフトウェアとハードウェアをテストし、その妥当性を確認する必要があります。

シミュレーションは極めて重要

車両が環境を検知する方法を制御する組込みソフトウェアの役割は、自動運転車両にとって最も重要です。自動運転車両では、オンボードコンピュータが収集したリアルタイムデータを使用して賢明な判断を行い、乗員に即時のフィードバックを提供することにより、リスクを最小限に抑えています。

ISO 26262規格では、システム挙動の妥当性確認段階において、シミュレーションの役割が極めて重要であると規定されており、あらゆるレベルでシミュレーションを行うことが推奨されています。シミュレーションの利点は、テストが再現可能であり、性能／耐久性の限界を上回るテストや危険な状況のテストを実施できることです。

ISO 26262では、ソフトウェアの安全要件の検証作業に、MIL（Model-in-the-Loop）、SIL（Software-in-the-Loop）、およびHIL（Hardware-in-the-Loop）シミュレーションの使用を提案しています。これらのシミュレーションプロセス（MIL、SIL、HIL）はすべて、自動運転車両の要件を作成するという共通の目標に対して適用することができます（図2を参照）。

ISO 26262では、ソフトウェアの安全要件の検証を満たすために、以下を推奨しています。

ソフトウェアの単体（コンポーネント）テスト（6-9）：ISO 26262では、単一のソフトウェアコンポーネントをテストする場合、要件ベースのテスト、インターフェーステスト、欠陥挿入テスト、およびパフォーマンステストといったテスト手法を使用することを強く推奨しています。

ソフトウェアの統合とテスト（6-10）：サブシステムに統合されたアプリケーションソフトウェアとベーシックソフトウェア、および分散機能に対応したアプリケーションソフトウェアの統合には、同じテスト手法（要件ベースのテスト、インターフェーステスト、欠陥挿入テスト、およびパフォーマンステスト）の使用が推奨されます。

ソフトウェアの安全要件の検証（6-11）：ソフトウェア開発における最後のマイルストーンであるこれらのテストは、ターゲットハードウェア上で実行してソフトウェアが正常に動作しているか検証する必要があります。そのため、HILシミュレータは絶対に必要です。ISO 26262の第2版では、HILシミュレーションの使用はさらに重要とされており、自動車安全度水準（ASIL）の最高分類でもHILシミュレーションの使用が強く推奨されています。

アイテムの統合とテスト（4-8）：ISO 26262では、システムの概念が明確に定義されておらず、さまざまなプロジェクトバリアントを自由に使用して、必要なテスト手法を適用することができます。自動車産業は、ますます多くのステップを仮想化し、シミュレーションの割合を高めることを目指しています。そのため、この業界での統合テストにおける個々のコンポーネントの成熟度は非常に高く、極めて早期の段階で統合テストを完了させることができます。

セーフティクリティカルなプロジェクトで使用されるすべてのソフトウェアツールには、必要な信頼性レベルの分類を行う必要があります。ただし、極めてセーフティクリティカルなツールの一部では、資格認定が必要です。ソフトウェアツールを認証すると、この資格認定のプロセスをクリアできます。

意図された機能の安全性（SOTIF: Safety Of the Intended Function）

ISOには、傘下の特別作業グループが設けられており、SOTIF（意図された機能の安全性）と呼ばれる仕様の公開に取り組んでいます。この規格は、自動運転機能の安全に関する指針の提示を目的としており、以下が含まれています。

• 自動運転（AD）アーキテクチャの高度な概念に関する詳細
• ISO 26262の危険事象とは異なるSOTIFの危険事象を評価する方法
• シナリオとトリガイベントの特定および評価方法
• SOTIF関連リスクの低減方法
• SOTIF関連リスクの検証および妥当性確認方法
• 自動運転車両の発売前に満たすべき基準

2018年後期のSOTIF規格にご注目ください。

検証および妥当性確認に関する要件の定義

dSPACE Inc.でシミュレーション、テスト、およびEEDM部門のビジネス開発マネージャを務めるJace Allenは、自動システムの開発プロセスに関わる企業は、ある時点でISO 26262または同様の周知の規格への適合性に関する監査を受けるだろうと確信しています。ただし現在は要件の確立が焦点となっています。

「自動システムのすべての要件とは何でしょうか」とアレンは述べます。「現在は誰も知りません。だからこそ、検証および妥当性確認プロセスの開発には大きな意味があるのです。現在の車載テストは、重大なテストシナリオを発見することにより、それらに必要となるシナリオ要件を定義することにほかなりません。」

自動運転車両の機能の妥当性確認に必要とされる膨大な量のテストを考慮すると、実際の道路でこれらのテストをすべて遂行することは現実的ではありません。ただし、この大掛かりな取り組みは、以下を組み合わせることにより達成できます。

1. 仮想シミュレーションテスト（すなわちMIL、SIL、HIL）
2. シミュレーションによって拡張したテストベンチ
3. 路上のフィールドテスト

標準的なシミュレーション技術の場合、シミュレーションおよびテストリソースが不足していると、テストで必要とされる作業量を満たせない可能性もあります。このような状況では、ロバストな統計的テスト手法を使用して、妥当性確認のカバレッジを拡大することが重要です。これを実現するには、統合された確率的テスト手法やより高度なAIアルゴリズムを利用してテストプロセスを管理し、さらに広いカバレッジを確保できるようにします。これにより、不合理なリスクを減らすことができます。

環境の検知

OEM各社にとって、要件を作成するうえで良い出発点となるのは運転席です。さまざまなエンジニアが、実世界の状況を把握するセンサやデータレコーダを搭載した車両を世に送り出しています（図3を参照）。

フィールドテストで収集したデータはラボに戻され、シミュレーションシステムにダウンロードされます。エンジニアは単一のシナリオと自動化ツールから収集したデータを使用して、何千もの異なるバージョンを完全に再生することにより、起こり得る多様な状況を理解することができます。現在開発中のSOTIF仕様では、そのようなテストにおけるガイドラインを提供します。

残存するリスク

不確実性に満ちた世界において、自動運転車両のどこかが故障する可能性はどの程度ありますか。そして本当にどこかが故障した場合、結果はどうなるのでしょうか。残存するリスクの影響を理解するには、まずリスクを特定し、それらを評価して、リスク管理の行動計画を決定する必要があります。

リスクは、既知のリスクと未知のリスクという2つのカテゴリに分類することができます。

許容可能なレベルのシステム安全性では、あらゆる危険を原因とする不合理なリスクを回避することが必要です。これには、制御対象のシステムの制限も含まれます。許容可能なレベルを決定するには、残存する既知と未知の両リスクを評価する必要があります。

既知のリスクは要件ベースのテストを使用して評価できますが、未知のリスクの評価には、テスト手法（すなわち、要件ベースのテストとシナリオベースのテスト）を適切に組み合わせ、確率論的技術を使用する必要があります。

既知のリスクの検証

一般に、既知のリスクの検証プロセスは次の手順で行います。

1. 要件とテスト目標を見直します。
2. テスト仕様を作成します。
3. パラメータ（すなわち、前提条件、データ構成、入力、予想される結果、および実際の結果）を含め、テストケースを設計します。
4. テストを実行し、記録します。
5. テスト結果とテストカバレッジを検証します。
6. テストプロセス中に発見された問題をすべて解決します。

MILからSILおよびHILに至るまで完全なトレーサビリティを確保して、テストを繰り返し、プロセスを管理することが重要です。ISO 26262においては、特にテストケースを作成および設計する場合、信頼性の高い構造化テストプロセスを確保することがとりわけ重要です。

未知のリスクの検証

未知のリスクの検証では、既知のものとは基本的な違いがあります。これらのテストは、主に確率に基づくものである必要があります。未知のリスクの検証でも要件ベースのテストは行いますが、シナリオベースのテストで補完する必要があります。

シナリオベースのテストでは、自動化されたテストを使用して、起きる確率の高いシナリオを定義し、妥当性確認と検証を行います。シナリオとは、実世界で起きる可能性があると考えられる状況（2車線道路から渋滞中の1車線へと合流する車両など）を再現するものであり、通常は外部要素とシステムとの相互作用（大雨で前方監視カメラの視界が悪化するなどの影響）を伴います。

「100万種類のシナリオを手作業で作成またはプログラムすることはできません」とAllenは述べます。「それらのシナリオを作成するには、自動化ツールを使用する必要があります。その後も、インテリジェントな管理と自動化されたテストプロセスにより、これらのシナリオを実行する必要があります。」

テストシナリオのモデリング

テストシナリオを作成するには、高精度のモデルとシミュレーションツールを使用して、仮想的にシーンを再現する必要があります。テストシナリオは、自動車、車載環境センサ（レーダー、LiDAR、GPS、HDマップなど）、道路、道路交通、さまざまな交通参加者（歩行者、サイクリスト、標識、およびそれらの予想される挙動）などのモデル要素を使用してシミュレートした環境に実装されます。テストシナリオをモデリングする手法では、パラメータの変化を管理することにより、テストケースを無限とも言える種類に作り変えられるという実用上の利点があります。

エンジニアがさまざまなテストシナリオを数多くシミュレートする必要がある場合でも、それぞれのシナリオを手作業で指定する必要はありません。リソースや特にOpen DRIVE、Open SCENARIO、Open Simulation Interface（OSI）などの規格を使用すれば、多数のシナリオ記述ファイルをインポートできます。また、路上での車両テストで取得した独自のセンサデータも利用可能です。こうして定義したテストシナリオを使用して、さまざまな自動運転アルゴリズムの妥当性を確認することができます。

自動運転機能の検証

ISO 26262では、欠陥や安全上のリスクが特定された場合は、潜在的なリスクを評価して最高レベルの安全目標を定義することを求めています。ISO 26262の後続の部分では、安全目標に違反する可能性のあるランダムなハードウェア障害や規則的なソフトウェア障害を回避し制御するための要件とガイダンスを提示しています。ISO 26262では、さらに単体テストから機能テスト、およびシステム統合テストに至るまでの反復作業を行うための標準化された手法を策定しています。

自動システムの関数アルゴリズムの検証では通常、開発プロセス全体を通じてシナリオベースのテストが実行されます。検証プロセスのテスト手法には以下があります。

1. MIL（Model-in-the-Loop）とSIL（Software-in-the-Loop）を使用したPCベースのシミュレーション
2. HIL（Hardware-in-the-Loop）シミュレーション
3. テストベンチ
4. フィールドテスト／実車によるテストドライブ

dSPACEでは、これらのテスト手法を支援するため、モデル、車載開発およびデータ取得プラットフォーム、PCベースのシミュレーション環境、HILテストシステム、機械式テストベンチを含む完全なツールチェーンに加え、データおよびテスト管理ソリューションによる路上テストを含めたテストプラン全体に関するサポートを提供しています。dSPACEのリアルタイムシミュレーションモデルスイートでは、幅広いシミュレーションをサポートすることができます。dSPACE Automotive Simulation Models（ASM）を使用すると、エンジニアはバーチャルビークル、道路網、トラフィック操作、トラフィックオブジェクト、センサモデル、ビークルダイナミクスなどを作成することができます。標準化されたインターフェースにより、ASMモデルのプロパティを個々のプロジェクトに合わせて容易に調整できます。また、ASMにはシナリオ情報をインポートし、シナリオの変更を自動化できるオープンインターフェースも用意されています。上述のテスト手法において、これらのモデルを追加のハードウェアやソフトウェアツールと組み合わせて使用することで、さまざまな自動運転システムに対応することができます。

PCベースのシミュレーション

安全なラボ環境でPCベースのMIL/SILシミュレーションを使用すると、開発の極めて早期の段階からテストを開始することができます。エンジニアは、モデル（制御モデル、バスシステム、車両モデルなど）やバーチャルECU（V-ECU）を使用することで、個々の車載機能、車両システムをテストできるだけでなく、特定のシミュレーションハードウェアからは独立したバーチャルビークル全体をテストすることも可能です。

ソフトウェアベースのシミュレーションプラットフォームであるdSPACE VEOSを使用すると、エンジニアは幅広いシミュレーションをPCシステム上で実施することができます。VEOSでは、リアルタイム以上に高速にテストを実行できます。これにより、高速テスト実行を通じて高いテストスループットが実現されます。さらに、PCを組み合わせてクラスタ化することにより、多数のシミュレーションを並行して実行することができます。PCクラスタは、シミュレーションジョブとテストケースをスケジューリングする1つの中央ユニットによって制御されます。

VEOSではHILテストに使用するのと同じオープンな標準インターフェースが提供されるということも、このタイプのMIL/SILテストにおける極めて重要な側面の1つです。そのため、気が遠くなるような量のテストを実行する必要があると予想される場合でも、同じテスト資産やツール（シナリオ、モデル、テストなど）をすべて使用できることにより、相乗効果が発揮され再利用性も向上します。

エンジニアは、PCベースのSILシミュレーションを使用することにより、HILテストやフィールドテスト／実車によるテストドライブを行う前の開発の極めて早期の段階でもテストを開始することができます。また、この方法では、統合システムのECUやその他のあらゆるコンポーネントのハードウェアの入手前であっても、バーチャルECUの機能を使用することでシミュレーションやテストを行うことも可能です。

HILテスト

HILシミュレーションテストは、自動テスト車両の実際のセンサシステム（すなわち、カメラ、レーダー、LiDAR、超音波など）で使用されるデータ融合プロセスやアルゴリズムの妥当性を確認するための優れたアプローチです。HILシミュレーションテストは、あらかじめ決められたスケジューリングに基づいて行われます。このテストは再現性とコスト効率に優れており、24時間年中無休で実行することができます。さらに、HILテストの結果をベースとして、品質目標を達成したりソフトウェアの安全要件を検証したりすることができます。

また、HILテストを使用すれば、システムのソフトウェアとハードウェアのあらゆる側面を考慮した真の「リアルタイム」を達成することも可能です。これはISO 26262の中心的な原則であり、自動車業界におけるECUソフトウェアの妥当性確認で確立された標準的な方法です。

シミュレーションでは、自動運転車両のセンサ（すなわち、カメラ、レーダー、LiDAR、超音波など）の挙動を再現するモデルを作成する必要があります。また、V2X、GNSS、およびマップから取得したデータをモデリングして車両の周辺状況とその環境認識機能の全体像を提供できるようにする必要もあります。センサシステムの構造はファンクションブロックとして識別されます。センサシステムは、物理計測、光学機器、波動伝播などによって決定された検出ポイントに基づいて検出を行います。

HIL環境では、テストセットアップに実際のセンサを使用することもあり得ます。テストシナリオに描かれている実世界での挙動を再現するデータ／情報を生成するためには、これらのセンサを適切にスティミュレートすることが必要です。dSPACEは、環境センサインターフェース（ESI）という専用のインターフェースを通じて、テストセットアップのセンサをスティミュレートする特別なソリューションを開発しました。ESIユニットは、テスト環境全体のリアルタイムでの整合性を維持するために、複数のタイプのセンサを同期的にスティミュレートすることができます。

そのため、下図のように、エンジニアはdSPACEツールチェーンを使用することで、テスト目標に合ったさまざまな機能のテストセットアップを幅広く選択することができます。

テストベンチ

HILシミュレーションのテスト環境にアクチュエータシステムの機械コンポーネントを含める必要がある場合は、テストベンチとHILを統合することで優れたソリューションが実現します。テストベンチは、実際の機械的な限界のテストをサポートしているため、ハードウェアの品質を保証しつつ、統合センサやアクチュエータを含めることが可能です。

一般的に、テストベンチでテスト可能なアプリケーションには、レーダーセンサ、統合センサ、電動パワーステアリング、電気ブレーキ、リアホイールステアリングなどがあります。

機械式テストベンチには、次のような要件があります。

• HIL環境全体（ソフトウェアおよびハードウェア）
• 高性能、低レイテンシのHILとテストベンチの制御システムとの組み合わせ
• アプリケーション固有の負荷アクチュエータの動特性
• 低ノイズの計測信号を接続した電気構成

センサシミュレーション用のテストベンチには、バスインターフェース（CAN、LINなど）、位置センサ（シフトレバーなど）、角度センサ（ステアリングなど）、および必要な自由度を含めた関連する物理的挙動（ヨーレート、加速度など）を挿入する機能が必要です。

フィールドテスト／実車によるテストドライブ

仮想シミュレーションテストにより、テストが大幅に高速化され、自動運転車両での走行が必要な多数のテストシナリオにおけるカバレッジが向上しましたが、その一方で、フィールドテスト／実車によるテストドライブは、実際の走行条件を評価したり仮想テストを通じて取得したテスト結果を検証したりするうえで依然として不可欠です。

テストエンジニアは、シミュレートされた環境でセンサシステムおよびアルゴリズムの機能を実証したら、現場に出向いて実際の気象条件（雨、雪、氷、霧、夜間運転 、暑さ、寒さなど）での自動運転車両の性能をテストします。ここでは、実車によるテストドライブを実施してから、最終調整を行い、センサが現実の状況をどのように処理しているかを検証します。

テストデータおよびプロセスの管理

自動運転機能の妥当性を確認するために実行するすべてのトラフィックシナリオや各テスト手法では、膨大な量のテストおよびデータが生成されます。最終的には、この情報を管理する必要があります。

データ管理の観点から見た主なタスクと課題は次のとおりです。

• データの保存と管理（可用性の確保）
• データの接続およびリンクと関係性の保存（トレーサビリティの構築）
• APIやオープンインターフェースの提供によるテストおよびプロセスの自動化
• 以前に実行したシナリオとテストを使用して新しいバージョンのECUソフトウェアを迅速にテストおよび検証するための資産の再利用
• チームや組織内のデータと結果の共有

dSPACEでは、安全要件のテストの文書化を規定するISO 26262の要件に準拠するため、データ管理テクノロジであるSYNECTを提供しています。SYNECTは、テストケース、実行、およびテスト結果を管理するためのサポートを提供しており、すぐに利用可能です。このソフトウェアシステムは柔軟性やカスタマイズ性に優れており、テストシナリオの管理や、モデルやパラメータなどのテストプロセスに関連するその他の資産の管理に使用することができます。また、プロセスやワークフローの自動化に必要なオプションとインターフェースも用意されています。さらに、多数のCOTSテストツールを自動化したり、モデルベースの開発プロセスとアプリケーション／製品ライフサイクル管理（ALM/PLM）システムの関連付けも行ったりできるオープンなインターフェースと規格も提供しています。

最後に

自動運転機能の検証は、要件の定義に依存しています。ISO 26262規格では、ソフトウェアの安全要件の検証プロセスの一部として、MIL（Model-in-the-Loop）、SIL（Software-in-the-Loop）、およびHIL（Hardware-in-the-Loop）シミュレーション手法の使用を提案しています。

実際の路上で考えられるすべての自動運転シナリオをテストすることは不可能です。大多数のテストシナリオをモデリングし、その後、MIL、SIL、およびHILシミュレーション、テストベンチ、フィールドテスト／実車によるテストドライブを組み合わせたテストを行う必要があります。

dSPACEでは、お客様がISO 26262およびSOTIFに準拠したプロセスを設計できるようにするため、テストの生成やテストプロセスの自動化を実現するためのオープン規格を提供したり、アプリケーションプログラミングインターフェース（API）に基づいた関連ツールチェーンを公開したりするとともに、コンサルティングサービスも展開しています。これにより、お客様は高度な確率論的テスト手法に対応できるようになり、他社との差別化が可能になります。また、dSPACEツールチェーンは、自動運転機能の検証に必要となる大量のテストで生成される膨大な量のシナリオやデータを処理するために必須のデータ管理機能も搭載しています。