機能安全について理解する

01. 機能安全とは

1-背景の紹介

自動車は複雑であるため、業界は安全要件を満たすコンポーネント システムの提供に取り組んでいます。例えば、アクセルバイワイヤシステムでは、ドライバーがアクセルペダルを踏むと、ペダル上のセンサーがコントローラーに信号を送り、コントローラーはエンジン回転数、車速、ペダル位置などの信号を総合的に分析します。 、などを実行し、制御コマンドをアクセラレータ オントロジーに送信します。スロットルバイワイヤシステムなどのシステムのテストと検証は、自動車業界にとっての課題です。ISO 26262 の目標は、すべての自動車 E/E システムに統一された安全規格を提供することです。

IEC-61508 から生まれた機能安全の国際規格草案 ISO-26262 は、2009 年 6 月にリリースされました。ドラフトの公開以来、ISO-26262 は自動車業界で広く注目を集めています。エンジニアは ISO-26262 を最先端のものとみなしています。テクノロジーの最先端とは、デバイスまたはプロセスが特定の時点で開発された最高の最先端技術です。製品の故障によって生じた損害については、自動車メーカーが通常責任を負います。ISO-26262 は、システムの安全性を測定する方法を提供する自動車業界の共通規格です。

図 1: 安全関連システム

ISO-26262 は、V モデルを使用して機能安全を管理し、システム、ソフトウェア、およびハードウェアのレベルで製品の開発を規制します。ISO-26262 規格は、製品のコンセプト段階から製品寿命段階まで、製品開発プロセス全体にわたる規制と推奨事項を提供します。システムとコンポーネントに許容可能なリスク レベルを割り当てる方法を詳しく説明し、テスト プロセス全体を文書化します。一般に、ISO 26262:

• 車両の安全ライフサイクル全体 (管理、開発、生産、運用、サービス、廃止) を提供し、これらのライフサイクル段階で必要なアクティビティのカスタマイズをサポートします。
• リスク カテゴリ (ASIL) を決定するための自動車固有のリスクベースのアプローチを提供します。
• ASIL を使用して、許容可能な残留リスクを達成するためにプロジェクトに必要な安全要件を指定します。
• 適切かつ許容可能なレベルの安全性を確保するための検証および検証措置の要件を提供します。

2- リスクの評価 - ハザード分析とリスク評価 (HARA)

新しく開発されたモデルを明確に定義したら、自動車の機能安全の最初のショットも開始しました。潜在的な危険を特定し、評価するには HARA が必要です。通常、OEM の機能安全エンジニアは、車両レベルの機能に対して HARA 分析を実行して、潜在的な危険シナリオを特定し、潜在的な危険ごとに必要なリスク軽減のレベルを決定します。HARA は、特定の運転シナリオにおける潜在的に危険な状況にさらされる頻度と期間 (露出)、潜在的な危険を軽減するために誤動作を修正するために必要な制御の量 (制御可能性)、および運転シナリオにおける潜在的な結果の重大度を考慮します。誤動作が発生します (重大度)。

HARA は、コンポーネントまたは要素レベルではなく、車両レベルで特性に対して実行されます。潜在的な危険ごとに、いくつかの潜在的な運転シナリオが考慮されます。例: 前方衝突軽減システムでは、意図しないブレーキの潜在的な危険性が、動作速度や運転条件などのさまざまな運転シナリオに従って評価されます。

3- 安全レベルの割り当て - 機能安全整合性レベル (ASIL)

HARA プロセス中に、OEM は特定された潜在的なリスクごとに ASIL (自動車安全度レベル) 評価を割り当てます。ASIL は開発プロセス中に決定されます。考えられるリスクに応じて。

図 2: 機能安全レベルの評価

たとえば、ある車のスピードメーターが故障した場合、車の発進時から何の情報も表示されないが、ドライバーは故障に気づきやすく、運転をしない、あるいは慎重な運転を選択する可能性があるため、QMに分類できます。つまり、シナリオの制御性は非常に高く、重大度は非常に低いです。対照的に、ドライバーが高速でブレーキを踏み損なった場合、重傷を負う可能性が高いため車両を制御できない場合は、ASIL-D に分類できます。

これらの状況に適切に対処するために、ISO 26262 は ASIL 評価を使用してサプライヤーが実行する必要がある開発手順の厳密さを決定し、安全目標の要件を定義します。

1. FIT 率 (時間内故障): FIT 率は、所定の期間内の車両の許容可能な故障率です。車両は ASIL 評価で指定された FIT レートを満たす必要がありますが、OEM はシステム内の基礎コンポーネントの FIT レートを柔軟に選択することもできます。

2. 安全コンセプト (安全コンセプト): 安全コンセプトは、障害を検出する方法と障害を制御する方法を決定します。ASIL 定格が高いシステムには、より厳密な障害検出および応答機能が必要です。

3. 安全要件: 安全要件は、特定の障害に対する適切な対応を指定します。たとえば、センサーがメモリ破損などの内部安全関連の問題を検出した場合、障害応答システムは他のシステムに障害ステータスを示すために、指定された時間内にコントローラーを介した通信を終了することがあります。これは安全要件で説明されている典型的な安全メカニズムですが、障害応答システムが常に適切であるとは限りません。たとえば、インテリジェント運転機能の場合、車両は欠陥のあるオペレーティング システムを採用する可能性があり、その場合、車両を最小限のリスク状態（たとえば、車の横に安全に駐車するなど）にするために必要な時間、冗長システムが引き継ぐ必要があります。道）。システム障害の場合、厳密な開発プロセスに従うことで、機能が安全に動作するという確信が高まります。

4- 継続的なテストと統合

自動車の機能安全では、開発プロセス全体を通じて V モデルが採用されています。V モデルでは、開発の各ステップに対応するテストのステップが必要です。ベンダーは開発プロセスを定期的に評価し、ハードウェアとソフトウェアの両方の開発が必要な手順に従っていることを確認します。

図 3: V-word 開発モデル

OEM、サプライヤー、または独立したサードパーティ企業は、機能安全の実現を確実にするために、関連するすべての作業成果物の機能安全監査と評価を実施します。機能安全には、適切な監視と完全なシステム統合を確保するための包括的な管理プロセスが必要です。

02. 機能安全エンジニアとは何ですか?機能安全エンジニアの仕事は何ですか?

機能安全技術者とは何ですか? この質問は一見簡単に答えられますが、よく考えてみると、真の統一された答えを見つけるのは簡単ではないことがわかります。たとえば、完全な開発システムプロセスを持つ大企業と小規模な新興企業では、おそらく機能安全エンジニアの定義が異なるでしょう。考えた結果、新しいプロジェクトを例にして、機能安全エンジニアとは何か、製品開発プロセスで機能安全エンジニアが何をするのかを説明することにしました。

1- 見積段階

1. セキュリティ要件の分析と明確化:

機能安全エンジニアは、顧客の安全入力を分析して、社内製品の安全要件が顧客の安全要件と一致しているかどうかを確認する必要があります。通常、関連するセキュリティ要件は、会議の形式で顧客と話し合って明確にします。

2. 影響分析を実行するには:

一般の機能安全技術者は、顧客のセキュリティ要件を分析した後、社内プラットフォームプロジェクトや量産されている他の顧客プロジェクトに、そのまま再利用できる機能があるのか​​、修正して再利用できる機能があるのか​​を判断する影響分析も行います。まったく新しい製品開発の場合、クライアントは影響分析を無視します。

3. 開発インターフェイス契約 (DIA) の責任分担:

機能安全エンジニアは、製品の開発境界を明確にした後、顧客との各当事者の開発責任の範囲を決定し、開発プロセスにおける出力の責任者と、両当事者が出力にどのように関与するかを明確にする必要があります。当事者は上記の内容について責任を負い、合意に達した後、DIA は完了します。最後に、両当事者が DIA に署名する必要があることを忘れないでください。

4. プロジェクトの機能安全計画と安全関係書類を準備します。

見積段階で、機能安全エンジニアは、プロジェクトの期間計画と顧客の安全に関する意見に従って、プロジェクトの機能安全計画の最初のバージョンを作成する必要があります (主な内容は、管理を計画し、プロジェクト期間中の安全活動の実行を指導することです)日付、キーノード、タスク、成果物、責任、リソースなどを含むプロジェクト開発プロセス全体）および安全性ファイル（主な内容は、開発された製品が ISO 26262 の要件に従って開発されたことを顧客に明確にすることです）機能安全を達成するために準備された証拠（製品開発のすべての段階の主要な成果の記録、成果のレビュー記録などを含む）。

5. レビュー会議の準備をするには:

上記の内容が完了したら、機能安全エンジニアは評価者とのレビュー会議の予約を入れることができます。会議では、監査人が機能安全技術者が作成した証拠に基づいてプロジェクトの製品開発の成熟度を評価し、現在の開発ニーズが満たされているか、安全性に関するリスクはないかを確認し、評価報告書を会議で出力します。現在の段階。[注]：各社の開発プロセスが異なるため、機能安全評価の要件も異なりますが、機能安全評価は基本的にプロジェクトのキーノードで実施されます。

6. 品目の定義と危険性の分析:

OEM の観点から、機能安全エンジニアは、開発製品の関連する最上位の定義を完了する必要があります (主な内容は、機能、ドライバー、環境、およびそれらとの関係を含む、車両レベルで関連する項目を定義および説明することです)安全目標とその安全性不当なリスクを回避するためのレベル）を取得し、製品のトップレベルの機能安全目標と機能安全の概念を取得し、サプライヤーにパッケージ化します。

2- 概念設計段階

機能安全の概念/要件の開発: 機能安全エンジニアは、機能安全の概念/要件 (FSC/FSR) の開発を完了する必要があります。機能安全コンセプトの主な目的は次のとおりです。

1. 製品の機能的または劣化した機能的動作は、機能安全の目標に従って定義されるものとします。

2. 関連する障害の合理的かつタイムリーな検出と制御に対する制約は、機能安全の目標に従って定義されるものとします。

3. 耐障害性を達成するため、または製品自体、ドライバー、または外部対策を通じて関連する障害への影響を軽減するために、製品レベルの戦略または対策を定義する必要があります。

4. 機能安全要件をシステム アーキテクチャ設計に割り当てます。

5. 機能安全の概念を検証し、安全性検証の基準を定義します。

図 4: 機能安全の目標と安全要件の階層

3-開発および設計フェーズ

システム開発・設計

1. 技術的な安全コンセプト/要件の開発:

機能安全エンジニアは、TSC/TSR の開発を完了する (またはシステム要件エンジニアが完了するのを支援する) 必要があります。技術的安全コンセプトの主な目的は次のとおりです。

a. 機能、依存関係、制約、および属性の観点から、システム要素およびインターフェイスの実装に必要な技術的セキュリティ要件を策定します。

b. システム要素およびインターフェイス実装のセキュリティ メカニズムに対する技術的なセキュリティ要件を策定します。

c. 生産、運用、サービス、および耐用年数終了時のシステムとその要素の機能安全に関する関連要件を策定します。

d. 技術的安全要件がシステム レベルでの機能安全要件を満たしているかどうか、また機能安全要件と一致しているかどうかを検証します。

e. セキュリティ要件を満たし、セキュリティ以外の要件と矛盾しないシステム アーキテクチャ設計と技術的なセキュリティ概念を策定する。

f. システム アーキテクチャ設計を分析し、故障を防止し、生産およびサービスに必要な安全関連の特殊特性を導き出します。

g. それぞれの ASIL レベルに従って、システム アーキテクチャ設計と技術的安全コンセプトが安全要件を満たすために適用可能かどうかを検証します。

図 5: システム レベルでの製品開発

2. セキュリティメカニズムのカスタマイズ:

一般に、製品設計の初期段階で、開発者は主要なチップ (マイクロコントローラー、SBC、ASIC、ドライバー IC、インテリジェンス センサーなど) の選択をすでに完了しています。この段階では、機能安全エンジニアは、チップ マニュアルのセキュリティ メカニズムの調整を完了する際にも主導権を握り、製品でどのメカニズムを使用する必要があるか、どのメカニズムを調整できるか、および十分な理由を示します。

3. システムセキュリティアーキテクチャの開発:

システム要件、システム アーキテクチャ、機能安全要件、および技術安全要件を使用して、機能安全エンジニアはシステム安全アーキテクチャの設計を開始できます (またはシステム アーキテクチャ エンジニアの設計を支援できます)。システムのセキュリティ アーキテクチャを設計する際には、次の点に注意する必要があります。

a. システムセキュリティアーキテクチャと前段階のシステムアーキテクチャ設計の一貫性を確保します。

b. システム セキュリティ アーキテクチャは、技術的なセキュリティ要件を満たすことができなければなりません (対応するセキュリティ要件とセキュリティ メカニズムがシステム セキュリティ アーキテクチャに反映されることが望ましいです)。

c. 設計されたシステムセキュリティアーキテクチャが完全に検証できるかどうか、期待されるソフトウェアおよびハードウェア設計がシステムセキュリティアーキテクチャを満たすことができるかどうか、およびシステム統合中のテストの実行に便利かどうか。

d. 安全関連の内部および外部インターフェースは、設計時に十分に考慮されなければなりません。

e. この段階で ASIL レベルを低下および分解する必要がある場合は、ASIL の要件に従って分解する必要があります。

4. システムレベルのセキュリティ分析を開始します。

完全な安全要件とシステム安全アーキテクチャにより、機能安全エンジニアはシステムレベルの安全分析 (FMEA 分析、FTA 分析、DFA 分析) を開始できます。安全分析を実行する主な目的は、システム設計が対応する ASIL レベルの機能安全要件を達成していることを証明する証拠を提供し、障害の原因と障害の影響を特定し、安全関連のシステム コンポーネントとインターフェイスを特定または確認することです。

a. F​​MEA 分析: FMEA は定性的かつ帰納的な単一点故障分析手法であり、主に製品設計および製造プロセスの弱点を初期段階で検出して除去することを目的としています。

b. FTA 分析: FTA は、ブール論理を使用してシステムの望ましくない状態を分析し、一連の下位レベルのイベントを組み込む演繹的故障分析です。FTA の目的は、システム内で実際に発生した障害の経路を分析して、システム障害の原因を特定することです。

c. DFA 分析: DFA の主な目的は、潜在的な原因またはトリガー要因を分析することによって、必要な独立性が設計で完全に実現されていることを確認することです (独立性の独立性とは、連鎖的な障害や 2 つ以上の要素間に障害がないことを意味します。共通)故障の原因となり、安全目標の違反につながる可能性があります）、または相互干渉の免除（FFI の干渉がないとは、安全要件の違反につながる可能性のある 2 つ以上の要素間での連鎖故障がないことを意味します）。必要に応じて、関連する可能性のある障害を軽減するために、対応する安全対策を開発することもできます。

図 6: さまざまなタイプのコヒーレンス障害間の関係

ハードウェアの開発と設計

1. ハードウェア セキュリティには次の開発が必要です。

システムレベルの安全要件、安全アーキテクチャ、および安全分析を入力すると、機能安全エンジニアはハードウェア安全要件の開発を開始できます (またはハードウェア エンジニアの開発を支援します)。ハードウェアの安全要件は主に、ハードウェアに割り当てられた技術的安全要件とシステム アーキテクチャ設計から導き出されます。

図 7: ハードウェア レベルでの製品開発

2. ハードウェア セキュリティ アーキテクチャ設計:

ハードウェア セキュリティ アーキテクチャの設計は主にハードウェア アーキテクトの責任であり、機能安全エンジニアの支援とサポート、およびハードウェア アーキテクチャのレビューが行われます。ハードウェア セキュリティ アーキテクチャは、モジュール性、適切な粒度レベル、およびシンプルさの特性を満たすように努める必要があります。ハードウェア アーキテクチャの設計プロセスでは、ISO 26262 のパート 5 のハードウェア アーキテクチャの設計方法も参照できます (表 1)。

図 8 - ハードウェア アーキテクチャの設計原則

3. ハードウェアおよびソフトウェア インターフェイス (HSI) のリスト:

ハードウェア設計段階では、機能安全エンジニアは、ハードウェア エンジニアがハードウェアおよびソフトウェア インターフェイス リストの設計を完了するのを支援します。ソフトウェアおよびハードウェア インターフェイスを定義するときは、次の要素を考慮する必要があります。

a. メモリ (RAM、ROM など)。

b. バスインターフェース (CAN、LIN など)。

c. コンバーター (A/D、D/A、PWM);

d. Ｉ/O口；

e. ウォッチドッグ (インナードッグ、アウタードッグ)

f. マルチプレクサ。

[注]: HSI の責任分担も企業ごとに異なり、システム エンジニアやソフトウェア エンジニアが HSI の定義を主導する必要がある場合もあります。

図 9: ソフトウェアおよびハードウェア インターフェイスの概要

4. ハードウェアセキュリティ分析:

機能安全エンジニアは、FMEA および FMEDA 分析を含むハードウェア レベルの安全分析においてハードウェア エンジニアを支援する必要があります。

a. F​​MEA 分析: ハードウェア FMEA 分析では、システム FMEA 分析に基づいてハードウェア コンポーネントを直接分析し続けることができます。

b. FMEDA 分析: FMEDA の計算には多くの入力が必要です (安全目標、ハードウェア故障率目標値、安全要件、安全アーキテクチャ、BOM テーブル、ミッション プロファイル、安全機構リスト、SN29500 の基本故障率など) .)、これらの入力により、FMEDA の計算を開始して、設計されたハードウェア製品の 3 つの指標値 (SPFM、LFM、PMHF) が対応する ASIL レベルの要件を満たしているかどうかを確認できます。

図 10: ハードウェア故障率のメトリック値

ソフトウェアの開発と設計

1. ソフトウェアのセキュリティには以下の開発が必要です。

ハードウェア開発と同様に、技術的安全要件、システム要件とシステム アーキテクチャ、ハードウェア設計仕様、ソフトウェアとハ​​ードウェア インターフェイス リスト、およびソフトウェア開発環境を入力することで、機能安全エンジニアは、ソフトウェア要件エンジニアがソフトウェア安全要件を開発するのを支援できます。ソフトウェアのセキュリティ要件は、通常、ソフトウェアに割り当てられた技術的なセキュリティ要件、またはソフトウェアの機能および機能の要件 (安全に実行できる関連機能、システムが安全な状態を達成または維持できる関連機能、等。）。

図 11: ソフトウェア レベルでの製品開発

2. ソフトウェアセキュリティアーキテクチャ:

ソフトウェア セキュリティ アーキテクチャの設計は主にソフトウェア アーキテクトを担当し、機能安全エンジニアが支援とサポートを行い、ソフトウェア アーキテクチャのレビュー活動をサポートします。ソフトウェア アーキテクチャの設計では、一貫性、単純さ、検証可能性、モジュール性、保守性の特性を満たすように努める必要があります。ソフトウェア アーキテクチャの設計では、ISO 26262 のパート 6 のソフトウェア アーキテクチャの設計方法 (表 2、表 3、および表 4) も参照できます。

図 12: ソフトウェア アーキテクチャの設計原則

3. ソフトウェアユニットの設計と実装:

ソフトウェアユニットの設計と実装は主にソフトウェア開発者が担当し、機能安全エンジニアが提供できるサポートは比較的限られています。ソフトウェア アーキテクチャの設計と同様に、ソフトウェア ユニットの設計でも、一貫性、保守性、検証可能性の特性を満たすように努める必要があります。ソフトウェアユニットの設計と実装の活動では、ISO 26262 のパート 6 のソフトウェアユニット設計の方法 (表 5、表 6) も参照できます。

図 13: ソフトウェア ユニットの設計と実装の設計原則

4. ソフトウェアセキュリティ分析:

機能安全エンジニアは、ソフトウェア エンジニアがソフトウェア安全分析を完了するのを支援する必要があります。ハードウェアと比較して、ソフトウェア セキュリティ分析には特定の方法がありません。ソフトウェア FMEA 分析を必要とする企業もあれば、ソフトウェア セキュリティ分析に FMEA の考え方を使用するのは特に適切ではないと考える企業もあります。現時点では、通常はソフトウェア キーが使用されます。パス分析の手法は、ソフトウェアのセキュリティ分析を行うために使用されます (分析をサポートするには、ソフトウェアの動的アーキテクチャと静的アーキテクチャが必要です)。

4- テスト検証フェーズ

各段階のテストについては、機能安全技術者にテスト活動を義務付けている企業は少ないため、各段階のテストと、機能安全技術者がテスト検証段階で何をすべきかについて簡単に説明します。

機能安全エンジニアは、各段階のテストが開始される前に、ISO 26262 メソッドの調整を主導します。機能安全エンジニアは、システム、ソフトウェア、ハードウェア、および関連するテストエンジニアと協力して ISO 26262 メソッドの調整を完了する必要があり、切り出されたメソッドには十分かつ合理的な理由が与えられる必要があります。(「++」はこの方法が強く推奨され、通常はカットできないことを意味します。「+」はこの方法が推奨され、合理的な理由がある場合にカットできることを意味します。「o」はこの方法が推奨されないことを意味します)

システムテストの検証

システムフェーズのテストには通常、次のものが含まれます。

a) システム機能テスト: システム機能がシステム要件を満たしているかどうかを確認します。

b) システム統合テスト: コンポーネント間のインターフェースが設計要件を満たしているかどうかを検証します。

c) DV 試験：DV は製品設計が要求事項を満たしているかを検証する設計検証であり、DV 試験には環境耐久性試験、電磁両立性試験、電気的特性試験が含まれます。

d) PV テスト: PV は製品検証であり、主に生産ラインで生産された製品が要求を満たしているかどうかを検証します。一般に、PV 後の製品は量産に適しています。

ハードウェアテストの検証

ハードウェア段階でのテストは一般に、ハードウェア機能テスト、つまり、ハードウェア回路設計がハードウェア要件と一致していることを確認するための、関連するハードウェア要件に基づくテストに焦点を当てます。

ソフトウェアテストの検証

ハードウェア段階のテストには通常、次のものが含まれます。

a) ソフトウェア機能テスト: ソフトウェア実装がソフトウェア要件と一致しているかどうかを検証します。

b) ソフトウェア単体テスト: ユニット設計がユニット設計要件仕様と一致しているかどうかを検証します。

c) ソフトウェア統合テスト: 統合されたソフトウェアがソフトウェア要件を満たしているかどうか、およびソフトウェア コンポーネント間のインターフェイスが一貫しているかどうかを検証します。

上記のシステム、ハードウェア、およびソフトウェア レベルでのテスト検証は、それぞれシステム、ハードウェア、およびソフトウェアのテスト エンジニアの責任です。機能安全エンジニアは、関連するテスト結果が合格するかどうか、およびテストカバレッジが 100% であるかどうかに主に焦点を当てます。テストに不合格があった場合、そのテストは製品の機能安全に影響しますか。不合格項目があった場合、再テストの結果はどうなりますか。