私はスリッパを履いた男で、上海で長年カーエレクトロニクスエンジニアをしています。
古いルールなので、気に入ったテキストを共有して、高い知識と低い文化を持ったエンジニアになることを避けてください。
人生において人々は常にあなたを攻撃します。彼らの主な武器は、あなたの価値、能力、可能性など、あなた自身に対する疑念を植え付けることです。彼らはこれを客観的な意見として装う傾向がありますが、常にあなたに自分自身を疑ってもらいたいと考えています。
この記事では主に以下の内容についてお話します。
-> 1. 車両の機能安全診断フレームワークの技術要件
-> 2. 診断フレームワーク技術の学習
早速、本文が始まります。
車両の安全性について、エンジニアは機能安全とソフトウェア アーキテクチャについて言及します。これらは次の 2 つのソリューションから検討できます。
-> 機能安全に準拠したソフトウェア アーキテクチャ。
-> 機能安全ソフトウェア アーキテクチャ。
これら 2 つの次元は、それらの間の関係に注目します。
機能安全を満たす車載ソフトウェアアーキテクチャのためには、ソフトウェア開発の観点から、現在のソフトウェアアーキテクチャ設計プロセスの機能安全への準拠、つまりソフトウェアアーキテクチャ設計プロセスがISO 26262で提案されているさまざまな要件を満たす必要があります。
-> マークメソッド;
-> 設計原則;
-> 設計要素の要件;
-> 安全分析要件;
-> エラー検出メカニズムの要件。
→ エラー処理の仕組みや設計検証方法など、
ソフトウェア アーキテクチャ レベルでの主流のセキュリティ分析戦略は、ソフトウェア FMEA (障害モードおよび影響分析) とソフトウェア DFA (依存障害分析) です。
機能安全ソフトウェア アーキテクチャでは、組み込みソフトウェア システムの観点からシステム レベルの機能安全をサポートすることに重点が置かれています。電気自動車の安全アーキテクチャの考え方に基づいて、「階層化された監視のアイデア」、「安全対策」、および「診断フレームワーク」が「機能安全ソフトウェア アーキテクチャ」の中核であると個人的に信じています。「この記事の残りの部分は主に診断フレームワークに焦点を当てます。
使用する基本的なソフトウェア開発プラットフォームが AUTOSAR CP、AP、または非 AUTOSAR であっても、機能安全ソフトウェア アーキテクチャの設計思想は同様であり、ここでは AUTOSAR CP に基づいて説明します。
1. 車両の機能安全診断フレームワークの技術要件
機能安全の場合、OBD フレームワークは予想されるリスクを検出し、その重要な部分を占めます。
FTTI (フォールト トレラント時間間隔、フォールト トレラント時間間隔) と組み合わせて、故障診断プロセスを理解します。障害の発生から被害の可能性までの期間は FTTI 時間であり、この期間には主に診断テスト、障害対応プロセスが行われ、被害の可能性が発生する前に安全な状態に移行することが期待されます。診断テスト プロセスでは、診断テストのトリガー、障害確認 (デバウンス) などを考慮する必要があり、障害対応プロセスでは、適切な動作モード (フェール セーフ、フェール動作、緊急動作など) への移行、障害の保存などを考慮する必要があります。
要約すると、OBD フレームワークのコア設計では、診断テストと障害対応プロセスの範囲を考慮する必要があります。機能安全診断フレームワークの主な技術要件は次のとおりです。
-> 1. 障害の統合管理: 車両ソフトウェア多層監視フレームワークの各障害監視層によって報告される障害ステータスを統合管理し、データの一貫性を確保します。
-> 2. 障害応答時間の要件: 障害検出から安全な状態に入るまで、フォールト トレランス時間間隔の要件を満たす必要があります。障害がトリガーされた後は、その後の機能低下の実行アクションに密接に関連付けられます。
-> 3. 独立性要件: オンチップのセキュリティ メカニズムと機能には共通の原因があり、独立した監視 (MCU オフチップ監視) をサポートする必要があります。これは、オンチップ ハードウェア監視上のソフトウェアに対するより高い要件です。
-> 4. 多様化要件: ソフトウェア アーキテクチャはフレームワーク設計の一般化を満たし、セキュリティ ポリシーの多様化をサポートする必要があります。
-> 5. 診断テストのタイミング: 電源のオンとオフ、サイクル、条件のトリガー - これらの条件は仕様で明確に定義し、対応する機能実装者に公開する必要があります。
-> 6. 障害デバウンス/遅延チェック: 安全メカニズムのデバウンス テスト機能をサポートする必要があり、少なくとも時間ベースおよびカウントベースのデバウンス アルゴリズムをサポートする必要があります。これらのデバウンス戦略は、AUTOSAR DEM モジュールの既製の戦略です。
-> 7. 診断イベントと機能の分離: 診断イベントと機能の独立した管理、およびそれらの間にマッピング関係があります - 診断イベント、DTC、および機能のマッピング関係。
-> 8. 障害ストレージ: 障害情報の不揮発性ストレージをサポートします。対応するコード設定ツールで、DTC、DTC ステータス、スナップショット情報などをチップ メモリ アドレスに 1 つずつ対応するように定義します。
2. 診断フレームワーク技術の学習
診断フレームワーク テクノロジを開始する前に、参考となる 2 つの考慮事項があります。
1: 需要に応じてオンボード診断テストのタイミングを決定します
a. オンボード ECU コントローラの電源がオンの場合: 一般的なアプリケーション要件と併せて説明します。安全機構とそれに対応する機能は二重点を構成しており、潜在的な多点障害の故障率を低減するために、一般に安全機構はシステムの起動段階 (電源投入時) に自己テストを実行する必要があります。この点は、オンボード オペレーティング システムを備えたマルチコア ECU に特に当てはまります。ここで、マルチプロセッサ システムでは診断テストの同期の問題も考慮する必要があることに注意することも重要です。
b. オンボード ECU コントローラーの実行時: 一般に、定期診断テストと条件診断テストに分けられます。診断サイクルの定義では、FDTI (障害検出時間間隔) の制約を考慮する必要があり、条件付き診断テストは通常、状態遷移が発生したとき、または機能がアクティブ化される前に機能を診断します。これはイベント トリガーに似ています。
c. オンボード ECU コントローラーの電源がオフの場合: 時間のかかるテストを実行することを選択すると、テスト結果は通常、次回の起動時に処理されます。したがって、テスト結果はパワーダウン時の不揮発性メモリに保存する必要があります。！！
2: グループ診断テストを実行する
診断管理 (診断のトリガーや障害への対応など) を容易にするために、それらは重大な障害/非クリティカルな障害、診断テストのタイミングなどの要素に従ってグループ化されています。電源投入時に重大な障害 (Critical Fault) が検出された場合、これはプラットフォーム レベルの車両ソフトウェア AUTOSAR について研究しているときに非常に重要なポイントです。現在、車両コントローラーのマルチコアおよびマルチシステムのステータス (コア障害 (Core Fault)、揮発性メモリ テスト障害 (Ram Test Fault) など)。このとき、障害応答はサイレント状態 (MCU が継続的にリセット状態にあるなど) で処理されるように選択できます。
車載の 3 層監視フレームワークの場合:
-> レベル 1(機能レベル）;
-> レベル 2 (機能監視レベル) は ASW (アプリケーション ソフトウェア、ソフトウェア アプリケーション SWC の上位層) 層にあります。
-> レベル 3 (コントローラ監視レベル) は BSW (基本ソフトウェア) 層にあります。
BSW 層に位置するオンボード ソフトウェア診断フレームワークは、主に診断テストと障害対応のプロセスをカバーします。
(1) 車載ソフトウェアアーキテクチャでは、AUTOSAR、BswM、EcuM が主に電源オンと電源オフの管理 (状態管理モジュール) を担当し、STARTUP、UP、SHUTDOWN の段階で電源オン、ランタイム、電源オフの診断テストを実行します。
(2) ASW レベル 1 は機能入出力の診断をカバーし、ASW レベル 2 (E-Gas Level2) は通常、ASW レベル 1 の ASIL レベルの分解を実現するための ASW レベル 1 機能の冗長アルゴリズムとして実装されます。
(3) テストマネージャーは、ソフトウェアライブラリのセキュリティメカニズムの診断テストの開始と、対応するテスト結果の収集を担当します。
(4) AUTOSAR DEM モジュールは、オンボードのレベル 1/2/3 のテスト結果を収集し、イベント デバウンスを診断し、障害コードをマークし、NvM を通じて障害情報を保存します (主に DTC、ステータス ビット、スナップショット情報などを保存します)。FIM は、DEM 診断テストの結果 (デバウンス後) に従って設定された機能にマークを付け、機能ソフトウェア (ASW-Level1) はマークに従って機能を抑制することを決定します。
3 つは、車両の基本的なエネルギー安全性を確保するためのモビリティ プラットフォームとして機能します。
