スマートカーの機能安全ソフトウェア アーキテクチャ

01 E-GAS 安全アーキテクチャの考え方

自動車の機能安全は、電子および電気システムの故障によって引き起こされる人身危害のリスクを妥当な範囲内に制御することを目的としています。次の図は、一般的な電子および電気システムのハードウェア構成図です。電子および電気システムのコンポーネントには、図に表示されているハードウェアに加えて、図には表示されていないソフトウェアも含まれています。

##図 1 一般的に使用される電子および電気ハードウェア システム

電子および電気システムの障害には、ソフトウェアおよびハードウェアの設計エラーによって引き起こされるシステム障害と、ランダムなハードウェア障害によって引き起こされる障害の両方が含まれます。システムのアーキテクチャに応じて、機能障害を防止および検出し、障害発生時の被害を回避または軽減するために、さまざまな安全機構を設計する必要があります。これには、これらの安全メカニズムを管理および制御し、機能安全の開発全体の困難さを軽減するための強力な機能安全ソフトウェア アーキテクチャが必要です。

現在、E-GAS (ガソリンおよびディーゼル エンジン コントロール ユニット向けの標準化された E-ガス監視コンセプト) は、間違いなく最も広く使用されているセキュリティ ソフトウェア アーキテクチャ ソリューションです。 E-GAS は当初、ガソリン/ディーゼル エンジン管理システムの安全アーキテクチャ ソリューションとして提案されましたが、簡単な適応により、車体システム、トランスミッション システム、新エネルギー 3 電気システムなどにも使用でき、非常に優れた性能を発揮します。パフォーマンス 拡張性があり、広く使用されています。

#下の図は、E-GAS の 3 層ソフトウェア アーキテクチャの設計図で、上から順に Level1 ～ Level3 の計 3 層に分かれています。は機能実装層（機能レベル）、Level2は機能監視レベル、Level3はコントローラ監視レベルです。このアーキテクチャは、優れた階層化された監視フレームワークを形成し、機能安全分解を効果的に実現します。 QM (ASIL X) の安全分解戦略 ASIL X (ASIL 機能冗長ソフトウェアまたは安全対策 (レベル 2、レベル 3) は、最高の要求レベルに従って開発されます) ASIL X (ASIL X) は、機能ソフトウェアの安全性開発コストを効果的に削減できます。

図 2 E-GAS 3 層監視アーキテクチャ ソリューション

#レベル 1 の機能実装層##レベル 1 は機能実装層であり、モーター コントローラーなどの特定の機能の実装を完了します。言い換えれば、この層は要求されたトルクをモーターのトルク出力に変換します。

#レベル 2 機能監視レイヤー

レベル 2 は機能監視レイヤーであり、監視に使用されます。 Level1 機能が正常に動作するかどうか。 Level2 の核心は、Level1 が正常に実行されているかどうかを判断するメソッドを設計することです。 Level1が正常に動作しているかどうかの判定方法は監視対象機能に関係することが多いですが、ソフトウェアの多様化や冗長化など監視対象機能ごとに判定方法が異なります。ただし、合理性チェックなど、より応用範囲の広い判断方法もあります。

図 3 合理性チェック

図に示すように上図において、レベル2が合理性検証手法を用いてレベル1の機能が正常に動作しているかどうかを判定する場合、まずセンサーから入力された信号に基づいて制御量の許容出力の妥当な範囲を計算し、次に実際の出力を計算します。アクチュエータからフィードバックされる量をフィードバックし、最終的に Level1 の実際の出力量が許容範囲内であるかどうかを判断し、許容範囲を超えている場合は Level1 の機能が異常であると判断し、エラー処理を行います。

#レベル 3 コントローラー監視レイヤー

レベル 3 はコントローラー監視レイヤーであり、主に次のもので構成されます。機能構成の 3 つの部分。

電子および電気システムのハードウェア診断: コントローラーの CPU コアの障害、RAM の障害、ROM の障害などの電子および電気システムのハードウェア障害を監視します。

独立監視: コントローラー関連の障害が発生すると、コントローラーは安全関連のロジックを確実に実行できなくなります。安全性を確保するには、追加の外部独立監視モジュールが必要です。 MCU に重大な障害が発生した後でも、安全な状態に入ることができるということです。この追加の独立監視モジュールは通常、ウォッチドッグが統合された電源管理チップです。

アプリケーションフローチェック：Level1、Level2の監視プログラムが正常に動作しているか監視します。この監視機能は、バインディング プログラム フロー検査とウォッチドッグ フィードによって実装されます。 Level1 および Level2 に関連する監視プログラムが設定された順序で実行されない場合、または指定された時間内に実行されない場合、プログラム フロー チェックは失敗し、犬に正常に餌を与えることができず、システムは安全状態に入ります。

図 4 レベル 3 の機能ブロック図

02 海外における機能安全ソフトウェアアーキテクチャの展開

機能安全とソフトウェアアーキテクチャに関しては、「機能安全に準拠したソフトウェアアーキテクチャ」と「機能安全に準拠したソフトウェアアーキテクチャ」の2つの側面から見ることができます。機能安全ソフトウェア アーキテクチャ」を参照して、それらの間の関係を調べます。

前者は、ソフトウェア開発の観点から見た、ソフトウェア アーキテクチャ設計プロセスの機能安全への準拠に焦点を当てています。つまり、ソフトウェア アーキテクチャ設計プロセスは、ISO によって提案されているさまざまな要件を満たす必要があります。 26262. マーキング方法、設計原則、設計要素要件、セキュリティ解析要件、エラー検出機構要件、エラー処理機構および設計検証方法などの要件。その中で、ソフトウェアアーキテクチャレベルでのセキュリティ分析の主流の手法それは「ソフトウェアFMEA（故障モード影響解析）」と「ソフトウェアDFA（依存故障解析）」です。

後者は、組み込みソフトウェア システムの観点からシステム レベルの機能安全をサポートすることに焦点を当てています。 E-Gasセキュリティアーキテクチャの考え方に基づき、「機能安全ソフトウェアアーキテクチャ」の中核となるのは「階層型監視の考え方」「セキュリティ対策」「診断フレームワーク」であると考えており、「階層型監視の考え方」と「記事で述べたように、このセクションの残りの部分は主に「診断フレームワーク」に焦点を当てます。使用する基本的なソフトウェア開発プラットフォームが AUTOSAR CP、AP、または非 AUTOSAR であるかどうかに関係なく、機能安全ソフトウェア アーキテクチャの設計思想は類似しており、ここでは AUTOSAR CP に基づいて説明します。

#1) 機能安全診断フレームワークの技術要件

##図 5 障害応答時間とフォールト トレラント時間間隔

障害診断プロセスを理解するために、FTTI (フォールト トレラント時間間隔) を組み合わせます。障害の発生から起こり得る危険が発生するまでの期間が FTTI 時間であり、この期間には主に診断テスト、障害対応プロセスが行われ、起こり得る危険が発生する前に安全な状態に移行することが期待されます (図 4.1-8) ）。診断テスト プロセスでは、診断テストのトリガー、障害確認 (デバウンス) などを考慮する必要があります。

障害対応プロセスでは、適切な動作モード (フェール セーフ、フェール動作、緊急動作など) への移行を考慮する必要があります。 、障害ストレージなど。

要約すると、「診断フレームワーク」の中核となる設計では、診断テストと障害対応プロセスをカバーすることを考慮する必要があります。機能安全診断フレームワークの主な技術要件は次のとおりです。

• 統合障害管理: E-GAS 多層監視フレームワークの各障害監視層によって報告される障害の統合ステータス管理
• 障害応答時間の要件: 障​​害 検出から安全な状態に入るまで、フォールト トレランス時間間隔 (FTTI) 要件を満たす必要があります。
• # 独立性要件: オンチップ セキュリティ メカニズムと機能の間には、共通の原因による問題があり、独立監視 (MCU) をサポートする必要があるオフチップ監視)
• 多様な要件: ソフトウェア アーキテクチャはフレームワーク設計の普遍性を満たし、セキュリティ戦略の多様化をサポートする必要があります (プロジェクトによって、セキュリティ メカニズムの要件が異なります)
• 診断テストのタイミング: 電源のオンとオフ、サイクル、条件トリガーなど。
• 障害のデバウンス/遅延チェック: 安全メカニズムのデバウンス テスト機能は、少なくとも時間ベースおよびカウントベースのデバウンス アルゴリズムをサポートする必要があります。
• 診断イベントと機能の分離: 診断イベントと機能は、
• 障害ストレージ: 障害情報の不揮発性ストレージをサポート

##2) 外国の診断フレームワーク技術の解釈

診断フレームワーク技術を解釈する前に、参考として 2 つの提案があります。

① 提案 1: 要件に基づいて診断テストのタイミングを決定する

a. 電源投入時: 以下に基づいて説明します。典型的なアプリケーション要件。安全機構とその機能は二重の意味を持ち、潜在的な多点故障の故障率を低減するために、一般に安全機構はシステム起動時（電源投入時）に自己診断を行う必要があります。さらに、マルチプロセッサ システムでは、診断テストの同期の問題を考慮する必要があります。

b. 実行時: 一般に、定期的な診断テストと条件付き診断テストに分けられます。診断サイクルの定義では、FDTI (障害検出時間間隔) の制約を考慮する必要があり、条件付き診断テストは通常​​、状態遷移が発生したとき、または機能をアクティブ化する前に機能を診断します。

c. 電源オフ時: 時間のかかるテストを実行することを選択でき、通常、テスト結果は次回の起動時に処理されます。

② 推奨事項 2: グループ診断テストを実施する

#診断管理 (診断のトリガーや障害への対応などを含む) を容易にするため、重大な障害/非重大な障害、診断テストのタイミング、その他の要因に応じてグループ化されます。コア障害、Ram テスト障害などの重大な障害が電源投入時に検出された場合、障害応答はサイレント状態で処理できます (MCU が連続リセット状態にあるなど)。

図 6 「機能安全診断フレームワーク」と「機能安全診断制御フロー」 ##E-Gas の 3 層監視フレームワーク Level1 (機能レベル) と Level2 (機能監視レベル) は ASW (アプリケーション ソフトウェア、つまり図 4.1-9 の SWC) 層に位置します。 , Level3（コントローラー監視レベル）はBSW（基本ソフトウェア）層に位置します。 「診断フレームワーク」も BSW 層に位置し、前述したように主に診断テストと障害対応プロセスをカバーします。その構成と作業プロセスは次のとおりです。

• BswM と EcuM は主に電源オンと電源オフの管理を担当し、電源オン、実行時、および起動時、起動時、およびシャットダウン時の電源オフ時に診断テストを実行します。
• #ASW-Level1 (E-Gas Level1) は関数の入出力の診断をカバーし、ASW-Level2 (E-Gas Level2) は一般に、 ASW-Level1 機能と ASW-Level1 ASIL レベルの分解を実現、TestLib (E-GasLevel3) は ECU および MCU レベルでハードウェア障害を監視します (ISO26262 (2018)-Part5 Annex D および MCU 安全マニュアルを参照することをお勧めします) ）、レベル 1 およびレベル 2 の一般的な原因による障害の診断をカバーし、論理的かつ時間に依存しない診断のための質問と回答のウォッチドッグ メカニズムを実装するために「監視コントローラー」とともに使用されます
• TestManager が担当しますTestLib 安全メカニズムの診断テストをトリガーし、対応するテスト結果を収集するため
• DEM は E-Gas Level1/2/3 のテスト結果を収集し、診断イベントをデバウンスし、障害コードをマークし、障害を保存しますNvM を通じて情報を提供します。 FiM は、DEM 診断テストの結果 (デバウンス後) に基づいて設定された機能にマークを付け、機能ソフトウェア (ASW-Level1) がマークに基づいて機能の抑制を決定します。

以上がスマートカーの機能安全ソフトウェア アーキテクチャの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。