Close
必数百万ものシナリオをどのようにして作成するか？
テスト数の爆発的増大を避けるには？
テストの合格・不合格をどのように見分けるか？
必数百万ものシナリオをどのようにして作成するか？
テスト数の爆発的増大を避けるには？
テストの合格・不合格をどのように見分けるか？
テスト数の爆発的増大を避けるには？
上位の抽象シナリオから具体的でシミュレーション可能なテストケースを作成する段階において、私たちは大量のパラメータの値を確定しなければなりません。その対象は抽象シナリオに記載されたパラメータに限られません。他にもODD（運航設計領域）で想定された運航条件（路面の種類、速度の範囲、天候条件、等々）のパラメータ群などを考慮する必要があります。
では、いったいどれだけのテストケースが必要になるのでしょうか？全てのパラメータの組み合わせを総当たりでシミュレーションしては”途方もない”回数のシミュレーション実行を要することになります。一方でランダムなバリエーション戦略を取るならば、重要でセーフティクリティカルなコーナーケースを十分に網羅できません。よりインテリジェントでスマートなテストケース生成アプローチが必要です。
例として、一定の量のパラメータをカバーするために必要なテストシナリオの数を計算してみましょう。仮に、100個のパラメータと1個につき3種類の値しかないとすると、約10^48（1兆）個のテストシナリオが必要になります。また、1回のシミュレーションに1秒かかると想定すると、全体のシミュレーション時間は10^34年となります。
上記のような複雑さがある以上、インテリジェントなテストシナリオ生成の目標は次の通りであるべきです。可能な限りのパラメータの組み合わせをシミュレーションすること無しに、システムの安全性に関する必要な信頼性を達成すること。この目標を達成するために、私たちはより興味深いシナリオにフォーカスすることでテスト数を減らし、関心のないシナリオを作成することを減らしています。もちろん、ここで「興味深い」の定義に疑問が生じます。この文脈では「興味深い」という表現には2つの意味があります。起こりうる可能性の高いシナリオと、セーフティクリティカルな状況を含むシナリオです。一方で「起こりうる可能性が低い」「セーフティクリティカルな状況でない」テストケースは少なくなります。この分類は2段階アプローチで実現されており、各段階で独自のテスト終了基準があります。
一つ目の段階は、確率分布などのバリエーション戦略に従ってパラメータ範囲を管理し易いよう分割します。これにより、可能性の高いシナリオをより多く取得し、ありそうもないシナリオを、より少なくすることができます。このプロセスのベースはそれぞれのパラメータの様々な個別の値の範囲の定義です。
例としまして、速度が0km/hから60km/hの間であると想定される車両を想定してみましょう。
ISO 26262の”Equivalence Classes”のコンセプトと同様に、この値の範囲は「0-40km/h」、「40-50km/h」、「50-60km/h」などの個別の範囲に分割できます。次に、これらの個別の範囲毎に確率が定義されます。個別のシナリオのバリアント毎にこれらの確率の乗算が結果の確率につながり、ユーザが定義したしきい値により、どのシナリオが実際に実行されるかを制御できます。
セーフティクリティカルな状況での振舞いに関して高水準の信頼性を達成するために２番目のバリエーションステップでは、AIテクノロジを用いてパラメータの空間を探索しテスト対象固有の弱点を検出します。弱点は各シミュレーションの実行後に評価可能なWeakness関数により正式に定義されます。このようなWeakness関数の１つの例としまして、衝突までの時間があります。値が小さいほど、よりセーフティクリティカルな状況（弱点のスコアが高い）に対応します。弱点検出はn次元空間（nは異なるパラメータの数）におけるローカル、およびグローバルな最大値を見つける事を目標とする最適化問題として説明できます。
この「弱点検出」の結果は、テスト対象をクリティカルな、または望ましくない振舞いへと導くテストケース、または弱点が無いことを確率論に基づいてレポートします。
これにより、余りクリティカルではない状況（例えば、全ての車両の距離が遠く離れている場合など）に対するテストケースの量を減らします。従って、テストケースの総量が爆発的に増えることはありません。
Copyright © 2022 BTC Embedded Systems & BTC Japan
