自動運転機能が複雑になるにつれて、自動運転・ADASシステムでセーフティクリティカルなソフトウェアを開発するには、従来の手法では不十分になりつつあります。自動運転システムは複雑な現実世界の運行領域で運用されるように設計されるため、考えられるさまざまなシナリオにほぼ無限に対応することが期待されます。一方で、車両開発中に新しいエッジケースやシナリオが見つかると、システム要件を追加したり調整されます。さらに、量産車のソフトウェア開発は販売後も続き、無線アップデート(OTA)によって新しい機能追加が求められます。その結果として、ソフトウェア品質のトレーサビリティ確保と使用中のデグレード回避は、安全で期待された自動運転を保証するために重要になります。
従来のADAS開発では、セーフティクリティカルシステムの安全性を開発および評価するためにVモデルが採用されてきました（図1）。開発プロセスは、要件定義と、全体的な要件に対するシステムのパフォーマンステストで構成され、テストは各要件を高レベルの設計から分割されたコンポーネントにて行います。安全保証の要件定義は、より複雑な自動運転システムの開発では潜在的なシナリオが大幅に増えるため、実際には困難です。要件も一定ではなく、実車テストから新しい情報が追加され、システムの運行設計領域（ODD）が広がるにつれて調整されます。
このブログ記事では、２つの要件定義のアプローチについて、ご紹介します。まず、従来のシステムエンジニアリングチームが採用してきたアプローチ、そして機械学習（ML）を利用する自動運転システム企業による最近のアプローチです。さらに、開発ライフサイクルを通じて要件を管理・更新する方法についてご説明します。
要件の種類について:
自動運転システムは、社内設計チーム、ユーザー、規制当局、商用フリートオペレーターなどのさまざまなステークホルダーからの要求に応えなくてはなりません。他にもシステムはいろいろな種類の要件を満たす必要もあります（表1）。要件は通常、ステークホルダーの要求に基づいて作成されますが、運用のコンセプト、サポート戦略の実現、有効性の測定、業界の安全基準などの要素も考慮されます。たとえば、要件はISO / PAS 21448（またはSOTIF）やISO 26262などの安全基準を満たすことで、システムやコンポーネントの障害が発生した場合のリスクを最小限に抑えることができる、安全であると公表できる機能を生成できます。
要件定義へのアプローチ:
自動運転システムを開発、検証、および検証するために膨大な実運転およびシミュレーションのデータを使用（およびアクセス）する必要があるため、機械学習(ML)を中心とした自動運転プログラムは、従来のシステムエンジニアリングとは異なる方法で要件定義にアプローチします。
従来の要件定義のアプローチ:
従来のシステムエンジニアリングでは、要件定義プロセスは階層構造に従い、最高レベルの要件が機能要件とパフォーマンス要件に分割され、さらに自動運転システム、サブシステム、および各コンポーネントに割り当てられます（図2）。ステークホルダーの要求（プログラムの目標、仮定条件、期待される機能/動作など）、運用コンセプト（製品ライフサイクル中にシステムがどのように運用されるか）、人間/システムの機能割り当て（ハードとソフトがシステム・人とどう関わるか）といったハイレベルの要件は検討されて技術的な問題を特定し、設計条件を決定します。要件は、さらに定量的に評価可能なものや、その他の技術的基準により定義されます。
詳細な要件が確立された後、要件全体を各レベル（システム、サブシステムなど）で、ステークホルダーの元の要求と比較して検証します。
このアプローチは、テスト対象のシステムが遭遇しうるすべての状況を列挙できる、それほど複雑でない環境（狭い、制限のあるODD）に適しています。しかし、より広範な自動運転のユースケースの場合、システムは非常に変化しやすい環境で無限のコーナーケースを検証する必要があり、考慮する必要のある要件とシナリオの数が飛躍的に急増します（このトピックについての詳細は、このブログ投稿を参照してください）。
では、より広範なODDで要件を定義するための代わりのアプローチはあるのでしょうか？
機械学習（ML）主導の企業の要件定義アプローチ:
従来の方法に対して、MLを中心とした自動運転プログラムは、実車走行データの厳密な定量分析で、ほとんどを要件定義します。開発チームはまず、ODD（例：市街地）での安全なナビゲーションに必要な測定値のリストを作成します。たとえば、運転速度、道路の曲がり角までの距離、減速度、追従距離などです（図3）。 チームは、各項目ごとに、何千ものシナリオを調査して、快適さと安全性の適切な閾値を算出します。たとえば、安全な車間距離のために、他のODDからも先行車と追従車のシナリオを分析して、各状況においての先行車からの安全な車間距離を導き出すことがあります。この定量的な結果は、パフォーマンス要件になります。
要件定義プロセスは、自動運転システムまたは現実世界で運転する人間が経験した既知問題に基づいて反復されます。たとえば、人間のドライバーが車間距離を平均2秒、取っていても、過去の運転データを調べると先行車が急ブレーキをかけた場合にその距離では後続車が反応するのに十分な時間がないことがわかります。その場合、要件をより安全な車間距離に調整します。
データベースの要件が確立されると、アルゴリズムの開発とシミュレーションテストのシナリオ作成を並行して行います。
開発ライフサイクル全体にわたる要件の管理：
新しいエッジケースを発見したり要求からの離脱に遭遇した場合などで、ODDの範囲を広げるにつれて、要件は製品開発ライフサイクルを通じて変化します。変化し続ける要件リストを管理するためのベストプラクティスは何でしょうか？
通常、要件管理には要件のパフォーマンスの追跡、根本原因の割り当てと問題のデバッグ、および要件のしきい値調整が含まれます。システムまたはコンポーネント設計の要件確認テストを実行するときは、最初に要件を意味的に定義されたシナリオに変換することが重要です。要件（例：車間距離）は、まず機能シナリオ（例：都市近郊の先行車と追従車のセット）、次にパラメータの変動（例：道路状況、気象変動、アクター車両タイプ）にリンクさせます。パラメータ分布が定義されると、シミュレーションテスト用の具体的なシナリオ（特定のテスト可能なインスタンス）を作成できます。
各要件に対する自動運転システムのパフォーマンスを確認するため、ツールでシミュレーションテスト結果を元の要件に自動的に紐づけて、トレーサビリティを確保することができます。 開発チームはこのツールにて、検証済みの要件とさらに評価が必要な要件を把握することで、進捗状況を容易に把握することができます。
自動運転システムが要件でNGとなった場合、開発チームはそれをデバッグするか、前述のように要件の変更を検討します。 通常は要件を厳しくするとエラーがでにくくなりますが、状況によっては、要件を緩める方が安全な場合があります（たとえば、高速道路の車線合流で制限速度を超える場合）。 この例は、特定のODDの内容に応じて要件を定義することが大切であることを示しています。
当社のアプローチ:
Applied Intuitionは、要件からシナリオを自動作成できるスケールを処理できるワークフローの設定をサポートします。当社のツールを使用して、高レベルの機能要件から機能シナリオ、論理シナリオ、および具体的なシナリオをプログラムで生成し、大規模なシミュレーションを実行し、テスト結果をプログラムで分析できます。当社のエンジニアリングチームと要件やトレーサビリティのトピックについてご相談を希望の方、または詳細を知りたい方は、こちらのリンクからご連絡してください。
.webp)
.webp)
