自動運転車にとって安全性の確保は非常に重要です。自動運転の安全性は、機能安全性 (FuSa) と意図された機能の安全性 (SOTIF) の 2 つの観点から見ることができます。FuSa は、電気および電子コンポーネントに障害が発生した場合にシステムが許容可能なリスクを抱えていることを保証するのに対し、SOTIF は、機能やパフォーマンスの制限が不十分な場合にシステムが許容可能なリスクを抱えていることを保証します。
ISO 26262 と ISO 21448 は、それぞれ自動運転システムの FuSa と SOTIF への準拠を保証するための高度な国際標準です。ISO 21448 規格では、ISO 26262 開発活動を ISO 21448 開発活動と連携させる必要性について言及し、非常に高いレベルでのマッピング関係について説明しています。ただし、ISO 21448 における SOTIF 開発活動の反復的な性質を考慮すると、2 つの規格間のワークフローの直接的な 1 対 1 マッピングは存在しません。したがって、ISO 26262 と ISO 21448 の開発活動を調整する方法と、一方の規格で実行された分析が他方の規格にどのような影響を与えるかを明確に理解する必要があります。
この目標を達成するために、この文書では ISO 26262 規格と ISO 21448 規格の間の詳細なワークフローを提案します。SOTIF 変更による設計変更が FuSa 解析に影響を与えるかどうか、またはその逆を判断する方法について説明しました。アジャイル開発におけるセキュリティ プロセスの考慮事項についても説明しました。
導入
安全性は、自動車システムを開発する際に考慮する必要がある重要な側面の 1 つです。多くの企業が自動運転に移行するにつれて、システムの複雑さが増し、安全性とセキュリティの複雑さがさらに増しています。ISO 26262、ISO 21448、ANSI/UL 4600 などの安全規格は、エンジニアやアナリストが自動車システムの安全性を確保する方法についての指針を提供します。
ISO 26262 は、システムの電気および電子コンポーネントに許容できないリスクが存在しないことを証明する方法に関するガイダンスを提供する機能安全規格です。ISO 21448 は、意図された機能の安全性 (SOTIF) 規格であり、システム内のコンポーネントの不十分な機能やパフォーマンスの制限によってシステムが不当なリスクをもたらさないようにする方法に関するガイダンスを提供します。SOTIF 標準は、既知および未知のリスクを軽減するように設計されています。ISO 26262 および ISO 21448 規格とは異なり、UL 4600 は、無人システムの安全プロファイルの構築に関するガイダンスを提供する規格です。3 つの規格はすべて、自動運転車の安全性の向上に役立ちます。
UL 4600 は独立した規格ですが、ISO 21448 の第 4.4 項では、開発活動を ISO 26262 の活動と整合させる必要性について言及しています。ISO 21448 付属書 A.2.3 は、ISO 21448 と ISO 26262 の開発活動の連携に関するトップレベルの情報を提供していますが、これらの開発活動がどのように相互作用するかについては十分な情報がありません。さらに、ISO 26262 では、分析の対象を安全システムに関連する電気および電子コンポーネントに限定しています。ただし、ISO 21448 は、あらゆるヒューマン マシン インターフェイスだけでなく、自動運転車全体にも適用されます。したがって、システム、ハードウェア、およびソフトウェアのレベルでの活動に好ましいワークフローは何か、また ISO 26262 および ISO 21448 の観点から安全性を確保するだけでなく、安全性の特定にも役立つ体系的なプロセスを開発する方法を理解する必要があります。未知のリスク。
この制限に対処するために、このホワイトペーパーでは、ISO 26262 と ISO 21448 の間で開発活動を調整するためのワークフローについて詳しく説明します。また、ワークフローで考慮されるプロセスの背後にある理由についても説明し、ワークフローを示す実例を示します。私たちは、私たちのワークフローが組織内でより良いプロセスを生み出し、一緒に働くチーム間のより良いコミュニケーションを促進するのに役立つと信じています。
背景と関連業務
ISO 26262
ISO 26262 は、道路車両の機能安全規格です。機能安全とは、電気および電子システムの障害による不当なリスクがないことを指します。ISO 26262 は、システム レベル開発、ハードウェア開発、ソフトウェア開発の V モデルに従っています。ISO 26262 に準拠したプロセス モデルと各フェーズに関連付けられた部品番号を図 1 に示します。
まずコンセプトフェーズ (ISO 26262 パート 3) から開始し、機能安全のために分析する関連項目を定義します。機能ブロック図を作成し、各ブロックに関連付けられた機能を特定します。依存関係が定義されたら、プロジェクト境界内のモジュールの障害を特定します。これらの障害に基づいて、対応する危険を特定し、危険分析およびリスク評価 (HARA) を実行します。HARA 中に、重大度 (S)、制御性 (C)、および危険度 (E) の評価を各障害に割り当て、対応する自動車安全度レベル (ASIL) を決定します。決定される最高レベルは、システム全体に割り当てられる ASIL レベルです。また、HARA 中の各危険に対応する安全目標も定義しました。HARA が完了したら、機能安全要件を作成し、すべての調査結果を機能安全コンセプト (FSC) に集約します。
FSC が生成されたら、次の段階であるシステム仕様と設計 (ISO 26262 のパート 4) に進みます。このフェーズでは、システム仕様、アーキテクチャ、技術的安全要件、ハードウェアとソフトウェアのインターフェイス要件を定義し、調査結果を技術安全コンセプト (TSC) に要約します。TSC を定義した後、ハードウェア レベルでの開発を開始しました (ISO 26262 のパート 5)。このフェーズでは、ハードウェア (HW) の安全仕様と HW 設計を作成し、HW アーキテクチャのメトリクスを分析および評価し、ランダムなハードウェア故障率を計算し、HW の統合とテストを実行します。
図 1 - ISO 26262 (機能安全) のワークフロー
ソフトウェア フェーズ (ISO 26262 のパート 6) は、ハードウェア開発フェーズと並行して開発されます。このフェーズでは、まずソフトウェア (SW) セキュリティ仕様、SW アーキテクチャ、および設計を定義します。次に、ソフトウェアを実装し、単体テスト、統合テスト、要件ベースのテストを実行します。
ハードウェアおよびソフトウェア レベルでの開発後、システム テストおよび安全性検証フェーズ (ISO 26262 のパート 4) に移行します。このフェーズでは、ハードウェア、ソフトウェア、システム、車両の統合テストと安全性検証の計画を策定します。テスト後は、生産、運用、サービス、および廃棄の段階 (ISO 26262 パート 7) に移行します。この段階では、生産および保守計画を実行し、修理手順を作成し、ユーザー マニュアルを作成します。ISO 26262 プロセス モデルに従いながら、ツール認定や構成管理など、ISO 26262 パート 8 で詳述されている他のサポート プロセスを使用する場合があります。
ISO 21448
ISO 26262 とは異なり、ISO 21448 は車両の電気および電子コンポーネントの故障には対処しておらず、安全性が重要なシステムに限定されません。ISO 21448 は、目的の機能に関する安全規格であり、主に無人システムに適用されます。不十分な機能、パフォーマンスの制限、予見可能な誤用から生じるセキュリティ問題に対処します。
ISO 21448 で提案されているプロセスを図 2 に示します。この図は、プロセスの各段階と、それに対応する規格内の条項番号を示しています。示されているように、無人システムの仕様と設計を収集することから始めます (ISO 21448 の第 5 項)。仕様で定義された機能に基づいて、潜在的に危険な行為を特定することにより、危険の特定とリスク評価 (HIRE) (第 6 条) を実行します。
HIRE では、各有害行為の制御可能性 (C) と重大度 (S) を評価し、C=0 または S=0 の場合、それらを合理的かつ許容可能なリスクとして定義します。C と S の両方がゼロより大きい場合、リスクは許容できないと見なされます。
また、HIRE フェーズでは、許容できないリスクを伴う危険性の許容基準仕様の作成を開始できます。受け入れ基準を定義するには、GAMAB (フランス語の「globalement au moins aussi bon」から、世界的に少なくとも同等に優れている)、ALARP (合理的に実行可能な限り低い)、MEM (最小限の内因性死亡率) などの根拠とデータが必要です。事故や死亡事故の情報を含む情報源。この情報を使用して、発生する可能性のある事故の数が人間のドライバーよりも少ないか、以前のバージョンの車両よりも少ないか、同等であることを保証するための許容基準を提案します。
HIRE が完了したら、トリガーとなるイベントと機能の欠如の分析を実行します (第 7 条)。この段階では、センサーの制限、アルゴリズムの制限、アクチュエーターの制限、および誤用の可能性があるケースを特定します。次に、残留リスクが高く、対応する許容基準が満たされない可能性があるなど、許容できないリスクを伴うトリガー条件を分析します。許容できないリスクを伴う条件のトリガーについては、SOTIF 関連の機能変更を定義します (第 8 条)。トリガー条件が C = 0 または S = 0 である場合、許容基準に達することができ、それを許容可能なリスクとみなし、検証および検証戦略の定義 (第 9 条) に進むことができます。
図 2 - ISO 21448 (SOTIF) ワークフロー
検証および検証戦略を定義した後、既知のシナリオの評価を実行します (第 10 条)。その間、センサー検証、アルゴリズム検証、アクチュエータ検証、および車両検証が実行されます。既知のシーンの評価が完了したら、未知のシーンの評価に進みます (項目 11)。私たちは現実世界で安全性検証を実施し、残留リスクが許容レベルであることを確認します。
未知のシナリオの評価が完了したら、SOTIF リリース (第 12 条) に進み、システムが厳密かつ十分に分析されて SOTIF が受け入れられるかどうかを判断します。そうでない場合は、SOTIF 関数の変更を実行する必要があります。評価者が SOTIF を受け入れられると判断した場合は、生産と運用に進むことができます。運用段階 (第 13 条) では、SOTIF の問題を引き起こす可能性のある新しいイベントや条件を特定するために、ランタイム監視などのメカニズムが依然として必要です。
関連作業
システム、ハードウェア、ソフトウェアの開発を網羅する、完全な一般的なワークフローをご提案します。
ISO 26262 と ISO 21448 間のワークフロー
図 3 は、私たちが提案する ISO 26262 と ISO 21448 の間の詳細なワークフローを示しています。四角形は ISO 26262 活動とその関連部分を表します。角丸の長方形は、SOTIF アクティビティとそれに対応する条項番号を示します。単一の方向の矢印は、一方向の関連付けを示します。これは、意図されたアクティビティのシーケンス フローであることを意味します。両方向の矢印は双方向の関連付けを示します。これは、アクティビティの 1 つに対する更新に基づいて、他のアクティビティを再度実行する必要があるか、対応する作業成果物を変更する必要があることを意味します。双方向の点線の矢印は、ISO 26262 アクティビティと ISO 21448 アクティビティ間の双方向の影響を示します。双方向の影響とは、ある標準に含まれる情報が別の標準のアクティビティや作業成果物に影響を与える可能性があることを意味します。
図 3 に示すように、ISO 26262 は項目定義から始まりますが、ISO 21448 は仕様と設計から始まります。最初は完全な仕様とデザインを得ることができない場合があることに注意してください。したがって、SOTIF は非常に反復的なプロセスです。仕様と設計から、高レベルの機能アーキテクチャ (FuSa の機能ブロック図に似ていますが、無人システム用) を生成できます。ISO 26262 で使用される用語は、ISO 21448 で分析される無人システムと正確に一致する必要はありません。
FuSa システムと無人システムの間では、図 4 に示すように 3 つの異なるタイプのアーキテクチャを検討できます。タイプ 1 アーキテクチャの場合、保護されたシステムと無人システムが別々にあります。たとえば、システムのセキュリティを確保するために車両にリモート モニターを装備することを検討するとします。次に、リモート オペレータと制御に関連してシステムの機能安全性を検討します。一方、SOTIF では、無人および人間とマシンの相互作用を考慮します。これらのアーキテクチャでは、SOTIF と機能安全の側面はそれほど相互作用せず、変更の影響分析を実行することが容易になります。
私たちが検討する 2 番目のアーキテクチャはタイプ 2 アーキテクチャで、機能安全システムは無人システムのサブセットです。例としては、緊急ブレーキ システムが FuSa システムとみなされているが、車両には FuSa システムに含まれていない追加の認識アルゴリズムが搭載されている場合があります。これらのシステムでは、FuSa コンポーネントとそのインターフェイスに関連する更新を SOTIF にマッピングする必要があり、その逆も同様です。これは設計を改善し、SOTIF で機能変更を行う必要がある場合に FuSa と SOTIF の両方を考慮するのに役立ちます。
図 3 - ISO 26262 と ISO 21448 間のワークフロー
図 4 - 考えられるアーキテクチャのタイプ
図ではタイプ 3 と呼ばれる 3 番目のアーキテクチャは、FuSa と SOTIF の両方に準拠する同じアーキテクチャを必要とします。例としては、エンドツーエンドの機械学習 (ML) モデル、つまりセンサー データを入力として受け取り、ホイール モーターの速度を出力として生成する ML モデルを使用する車両が挙げられます。
ISO 26262の関連項目の定義に従い、HARAを実施します。ISO 21448 では HIRE を実装します。HARA 中に SOTIF に関連する問題が発見される可能性があり、HIRE 中にも障害が見つかる可能性があることに注意してください。したがって、それらを追跡し、それに応じて分析を更新する必要があります。
HARA の後、ISO 26262 では、機能安全要件、安全目標、ASIL 情報、および HARA からの発見を含む機能安全コンセプト (FSC) を作成しました。ISO 21448 には FSC に相当するものはありません。ISO 26262 で FSC を作成した後、システム開発フェーズに入り、最初にシステムの仕様と設計を作成します。ISO 21448 に相当するフェーズはありませんが、アーキテクチャ (および無人システムの一部である場合は FuSa システム アーキテクチャ) は仕様と設計で更新できます。
ISO 26262 のシステム アーキテクチャと設計段階の後、技術安全コンセプト (TSC) が完成します。TSC には、技術安全要件、ハードウェアとソフトウェアのインターフェイス仕様、およびシステム安全分析の一部として行われたその他の観察が含まれます。ISO 21448 の活動に相当する TSC フェーズは、システムレベルの機能欠陥とトリガー条件の分析です。この段階では、ISO 26262 のハードウェアとソフトウェアの詳細に基づいて機能安全の問題を予測する方法と同様に、センサー、アルゴリズム、アクチュエーターのリストに基づいて潜在的な欠陥とその原因を特定します。ただし、コンポーネントの欠陥が何であるか、またそれらを引き起こすトリガー条件が正確にわかっていないため、これらの欠陥を最終的に判断することはできません。私たちが仮説を立てている根本的な欠陥が実際にシステムレベルで発生しているかどうかを理解するには、ボトムアップ分析が必要です。
ISO 26262 で TSC を開発した後、ハードウェア (HW) セキュリティ分析フェーズに移行します。ハードウェア セキュリティ分析フェーズを指定していますが、TSC の完了後にハードウェアとソフトウェアの開発を並行して開始できることに注意してください。ハードウェア分析フェーズでは、ハードウェア仕様の生成、設計、ハードウェア アーキテクチャ メトリクスの評価を行い、FMEDA を実行します。ISO 21448 の場合、私たちが実行する同等の分析は、機能上の欠陥を分析し、HW コンポーネントに固有の条件をトリガーすることです。この段階では、センサーの限界、アクチュエーターの限界、ECU、またはハードウェアのパフォーマンスに影響を与える可能性のあるその他の条件を推定します。
図 5 - 姿勢、位置特定、予測、計画、および制御機能を含むタイプ 2 アーキテクチャ
ISO 26262 に準拠したハードウェア安全性分析に続いて、ハードウェアの安全性検証を実施し、その際にハードウェアを統合してテストします。ISO 21448 における同等のことは、運用設計ドメイン (ODD) で発生する可能性のあるシナリオに対してハードウェア コンポーネントを検証することです。これにより、トリガー条件が存在する場合でもシステムが期待どおりに安全に動作していることを確認できます。
ISO 26262 におけるハードウェア (HW) の安全性検証に続いて、ソフトウェア安全性 (SW) 分析が行われます。ここでは、ソフトウェア仕様を定義し、ソフトウェア FMEA を設計および実行して、ソフトウェア レベルでの問題を特定します。ISO 21448 におけるこれに相当するのは、ソフトウェアの機能欠陥とトリガー条件の分析です。この段階で、アルゴリズムの制限を特定します。機械学習 (ML) アルゴリズムの場合、ML モデルだけでなく、これらのモデルをサポートする ML ライブラリも分析する必要があることに注意してください。
ISO 26262 のソフトウェア安全性分析に続き、単体テスト、統合テスト、要件ベースのテストを通じてソフトウェア検証を実行します。ISO 21448 の同等のステップは、ODD のシナリオに対してソフトウェアを検証することです。この分析中に、アルゴリズムの新しいトリガーを発見できる可能性があります。ハードウェアまたはソフトウェアの更新がトリガーとなる場合、ボトムアップ分析が実行され、システムレベルの欠陥と車両レベルの危険性が更新されます。分析または検証中に、新しい FuSa または SOTIF の問題が発見される可能性があり、それに応じて標準間でマッピングする必要があることに注意してください。SOTIF の問題に対処するための変更を提案する場合は、新しく追加された変更が新たな機能安全の問題につながるかどうかも考慮する必要があります。
ISO 26262 によるソフトウェア検証の後、統合とテストを行ってから、完全な車両レベルのテストを行います。ISO 21448 の対応するものは、シナリオベースの統合検証と車両検証です。このキャンペーン中に新しい問題が発見された場合は、それをトリガー条件と十分に機能していないシステムレベルの分析にマッピングします。さらに、ハードウェアおよびソフトウェア レベルの検証に基づいて、システム レベルのイベントの新しいトリガーを特定できた場合、テスト計画は更新されます。車両レベルの検証におけるリスクの受け入れは、当社の受け入れ基準と対応する検証目標に従って行われることに注意してください。
表 1—タイプ 2 アーキテクチャのワークフローの説明
ISO26262の車両レベル試験を経て、安全性の確認を実施します。ISO 21448 におけるこの活動に相当するのは、車両を道路に配備し、残留リスクを計算する未知のシナリオの評価です。未知の領域で発見された新しい問題は、必要に応じて SOTIF の機能変更を実行し、仕様と設計を更新するために使用されます。
ISO 26262 による安全性検証の後、当社は生産、運用、廃止措置およびサービスに移行し、その間に生産および保守計画、アップグレードおよび修理手順を開発し、ユーザーマニュアルを開発します。ISO 26262 における同等のフェーズは運用フェーズであり、このフェーズでは、現実世界に配備された車両を監視して、潜在的に未知のトリガー条件が発生する可能性があるかどうかを確認します。新しいトリガー条件が特定された場合は、それを既存のリストに追加し、SOTIF プロセスを繰り返します。
事例分析
図 3 に示す提案された詳細なワークフローと、図 4 に示すさまざまなタイプのアーキテクチャに関する明確なガイダンスを提供するには、ドライブ、ブレーキ、ステアリングのアクチュエーターの自動制御の実装について、図 5 に示す次のタイプ 2 アーキテクチャを検討してください。
ワークフローの例を表 1 に示します。表の最初の列は、ISO 26262 の部品番号と ISO 21448 の条項番号を示しており、これらは一貫していると考えられます。記号PXは品番X、記号CYは品番Yを意味します。
結論と今後の取り組み
このペーパーでは、ISO 26262 と ISO 21448 の間の詳細なワークフローを提案し、どの段階を調和させる必要があるかを示します。また、SOTIF 問題に対処する設計変更が新たな FuSa 問題を引き起こさないようにする必要性についても説明します。また、その逆も同様です。ドライブ、ブレーキ、ステアリング アクチュエーターの自動制御を備えたサンプル アーキテクチャを通じてワークフローについて説明しました。フェーズの調整については議論しましたが、2 つの標準を調整する際に品質管理と変更管理をどのように考慮するかについては議論しませんでした。今後の作業の一環として、このような分析も含める予定です。