まとめ：
DEM は、DTC をコアとして、DTC の監視、レポート、保存の機能を実現する AUTOSAR の基本ソフトウェア モジュールですが、AUTOSAR 診断をさらに学習する必要がある場合は、DCM、Doip、Cantp などのモジュールも体系的に学習する必要があります。
序文
Dem は AUTOSAR の中で最も多くの設定項目と最も複雑な機能を持つモジュールの 1 つです. 主に故障診断とその関連データの記録を担当します. 診断機能を実現するために重要なモジュールです. この記事ではこれらの機能について説明します最もシンプルな方法で、徹底的に話し合ってください。参考までに、この記事の概要を以下に示します。
1. 故障診断の基本
人が病気に罹ると治療が必要となり、医師はさまざまな検査結果をもとに病気の原因を突き止め、診断や治療方針を立てます。自動車が故障した場合、DTC故障コードは「検査結果」に相当し、自動車技術者は識別コードからテーブルを参照することで、故障発生条件、故障解除条件、システム機能性能、など、障害を解決するための戦略を取得します。
DTC (Diagnostic Trouble Code) は、その名前が示すとおり、ECU に特定の故障が発生したり検出されたときに全員に提示される識別コードを記録するために使用される診断用トラブル コードです。
1.1 DTCの構成
DTC 故障コードは、次の 2 つの部分で構成される 4 バイトの識別子です: DTC カテゴリと故障タイプ。DTC カテゴリは、パワートレイン、ボディ、シャーシ、ネットワークの 4 つのサブシステム (4 つのサブシステムと呼ばれる) に従ってその範囲をさらに定義できます。 PBCU の機能を次の表に示します。
1.2 DTCの意義
障害コードには次の 2 つの意味があります。
1) 生産ラインのオフライン検査：自動車の部品開発、システムインテグレーション、車両組み立ては工程が長く、部品点数も多く、非常に複雑と言えます。生産ラインで生産された車両が正常に組立ラインを出て安全に道路を走行するためには、車両が走り出す前に、部品自体に問題がないこと、および部品間の連携が正常に行われていることを確認する必要があります。組み立てライン。そのため、生産ラインの電気検査工程では車両全体の故障コードを読み取り、車両が正常かどうかを判断するために使用されます。
2) 車両のメンテナンス:車両が故障した場合、メンテナンス エンジニアはどのようにして故障部品を迅速に特定できるでしょうか? 自動車は数万点の部品で構成されており、経験に基づいてゆっくり点検する整備技術に頼っていては効率が非常に悪くなります。したがって、メンテナンスエンジニアは診断装置を使用して車両全体の故障コードを読み取り、故障コードと故障症状を比較し、迅速にメンテナンス戦略を立案します。
1.3 DTC 障害の種類
非排出ガス関連の ECU を例にとると、DTC の故障タイプは次の部分に分類できます。
ハードウェア障害: RAM、フラッシュ、CPU クロックなどのハードウェア自体の障害ソフトウェア障害:コンフィギュレーション ワードの障害、キャリブレーションの障害、または顧客定義のソフトウェア機能の障害など外部環境の障害:過電圧または不足電圧、高い周囲温度、または通信低すぎるなどの関連障害:メッセージ損失、無効な信号、チェックサム/ローリング障害など。
1.4 DTC ステータス ビットの概要
各 DTC には障害のステータスを示すバイトがあり、このバイトの各ビットの意味は次のとおりです。
| DTC のステータス: ビットフィールド名 |
少し | ビット状態 | 説明 |
| テスト失敗 | 0 | 0 | DTC はリクエスト時に失敗していない |
| この操作サイクルのテストが失敗しました | 1 | 0 | 現在の操作サイクル中に DTC が失敗しました |
| 保留中DTC | 2 | 0 | DTC は現在または前の操作サイクルで失敗しませんでした |
| 確認済みDTC | 3 | 0 | リクエスト時点では DTC が確認されていません |
| testNotCompletedsinceLastClear | 4 | 0 | 最後のコードクリア以降、DTC テストが完了しました |
| 前回クリアしてからテスト失敗 | 5 | 0 | 最後にコードをクリアして以来、DTC テストは一度も失敗しませんでした |
| この操作サイクルはテストが完了していません | 6 | 0 | DTC テストはこの動作サイクルを完了しました |
| 警告インジケータが要求されました | 7 | 0 | サーバーは warningIndicator をアクティブにするよう要求していません |
具体的な説明は以下の通りです。
Bit0: 要求時のテスト結果が不合格である; Bit1: 現在の点火サイクルで少なくとも 1 つの故障が発生している; Bit2: 現在または最後の点火サイクルでテスト結果が故障ではない; Bit3: DTC が確認された要求時、および一般的な確認が点火サイクル内である サイクル内で 1 回エラーが発生する; Bit4: DTC の最後のクリア以降、テスト結果が完了している、つまりテスト結果が PASS または FAIL; Bit5: DTC の最後のクリア以降、テスト結果は FAIL ではありません; Bit6: 現在の点火サイクル中 テスト結果は完了しました、つまり PASS または FAIL ステータスです; Bit7: ECU は警告灯を点灯する要求を受信していません
1.5 フリーズフレームと拡張データ
上記のことから、DTC の 8 ビットで DTC ステータスを記述できることがわかりますが、8 ビットで伝送できる情報は限られており、障害が現在の障害であるか過去の障害であるかを示すことしかできません。 。障害が発生したときに、車速、温度、燃料量、電力などの重要な情報をどのように記録するか?
UDS は、フリーズ フレームを使用して障害の詳細を記録できること、および拡張データはエージング カウンタを含む障害コードに関連する拡張情報を提供できることを規定しています。
| タイプ | 構成 | コンテンツ |
| フリーズフレーム | 一連の DID で構成され、ユーザーは DID コンテンツをカスタマイズできます | 車速、温度、オイル量などを記載します。 |
| 拡張情報 | 一連の DID で構成され、DID の内容は BSW によって指定されます。 | バーンイン サイクル数など、DTC を説明する追加情報。 |
2.DEMの詳細説明
2.1 DEMの主な機能
Dem の正式名は Diagnostic Event Manager で、診断障害イベントの処理、診断障害イベントおよび障害イベントに関連するデータ (障害発生時の温度、車両速度など) の保存を担当します。つまり、DEM は AUTOSAR アーキテクチャの障害に対する「中央処理装置」の役割を果たします。ユーザー ソフトウェア モジュールは障害を DEM に報告するだけでよく、すべての障害情報処理は DEM によって実行されます。
1. 障害が確認される前:ユーザー モジュールによって報告された障害のデバウンス アンチシェイク処理を行い、対応する障害が誤報障害ではないことを確認します。
2. 障害が確認された場合:障害イベントが確認されたときの障害データは NVM に保存され、障害を長期間保存することができます。
3. 故障確認後：故障の老朽化と交換、および故障を修復した後に故障を解消できる機能。たとえば、インストルメントパネルのエンジンチェックランプは、エンジンの修理後一定時間が経過すると消えます。
2.2 DEMと他のモジュールの関係
1) AUTOSAR アーキテクチャにおける DEM の場所
Dem は AUTOSAR アーキテクチャのシステム サービス層に位置し、システム サービス層は次のサービスを提供します。
1. オペレーティングシステムのスケジューリングおよび監視サービス 2. 通信およびネットワーク管理サービス 3. ストレージサービス 4. 診断サービス (UDS 通信サービスおよび障害サービス) 5. ECU ステータス管理サービス
以下のアーキテクチャ図からわかるように、Dcm と Dem は「Diagnostic Duo」として、すべての診断サービスを完全な方法で提供します。違いは、Dcm は「UDS 診断通信サービス」を専攻し、通信プロトコル スタックと直接通信し、外部の診断機器と対話して診断通信サービス (10、22 などのサービス) を提供するのに対し、Dem は障害診断サービスを専攻し、上位 SWC、BSW と通信します。 モジュールと通信し、障害レポートを受信し、NVM と通信してストレージ機能を使用します。
UTOSARアーキテクチャ図
2) Dem およびその他のモジュールの依存関係
Dem と他のモジュールの関係リンク図
NVM: Nvm は、Dem が使用するストレージ サービスを提供できます。つまり、障害のあるストレージの診断に必要な NVM ブロックを提供します。Nvm は、DEM に 2 種類のストレージ サービス インターフェイスを提供しており、DEM がリアルタイムで障害を保存して診断するための Nvm_WriteBlock() と、ストレージの電源をオフにして障害を診断するための Dem 用の NvM_SetRamBlockStatus() です。 DTC 構成プロパティに反映されます。
DCM:上図からわかるように、DCM は診断機器の 19 サービス (get Dtc) と 14 サービス (Clear Dtc) を受信すると、Dem を介して DTC データをリアルタイムで取得し、DTC をクリアする必要があります。
ECUM: Dem モジュールで初期化およびシャットダウン操作を実行します。
SWC (監視):障害イベント Event を監視および診断し、Dem_SetEventStatus() 関数を使用してイベント ステータスを Dem に報告します。Dem_SetOperationCycleState() を使用して、演算サイクル状態を制御します。
2.3 DEMコアイベント
DEM の具体的な機能を紹介する前に、まず、DEM モジュールの最も重要な要素でもある「診断イベント」という概念を紹介します。AUTOSAR ソフトウェア アーキテクチャの場合、DTC は診断機器のユーザーにのみ表示されますが、イベントは DTC ステータスの実際のコントローラであり、イベントは診断 NVM データ ストレージの実際のコントローラでもあります。
読者は必ず次のような疑問を抱くでしょう。
- なぜ「診断イベント」を導入するのか？
- 「診断イベント」ソース?
- 「診断イベント」の特徴は何ですか？
- 「診断イベント」はどのように DTC を制御しますか?
- 「診断イベント」は診断データのストレージをどのように制御しますか?
次に、上記の質問に一つずつ答えていきます。
1) イベントと DTC の関係と違い
違い：
1. 説明レベル: DTC はシステム レベルでの障害の説明であり、イベントはソフトウェア レベルでの障害監視の最小単位です。
例: あるモーターの故障は過電圧によって引き起こされる可能性がありますが、ソフトウェアは故障を直接特定することはできず、ソフトウェアは過電圧の時間イベントが発生するかどうかを監視し、DTC が発生するかどうかを計算することしかできません。
2. リンク関係:複数のイベントが同じ DTC をマッピングできますが、同じイベントが複数の DTC をマッピングすることはできません。
3. 可視性: DTC は直接見ることができますが、イベントはさらなる手段を介してのみ見ることができ、場合によっては ECU サプライヤーのみが見ることができます。
接続する：
1. DTC は、特定の種類のイベントの集中パフォーマンスを表し、イベントは DTC の特定のインスタンスです。 2. イベントの優先順位によって DTC の優先順位が決まります。 3. イベント間の依存関係によって、DTC の依存関係が決まります。 DTC;
2) 「診断イベント報告方法」
前述したように、SWC は障害イベントのステータスを監視し、Dem_SetEventStatus(EventId, EventStatus) を通じてイベント ステータスを DEM に報告できます。では、SWC の場合、イベント ステータスはどのように報告されるべきでしょうか? Dem_SetEventStatus を定期的に呼び出してレポートすることは定期レポートであり、イベント ステータスが変化したときに Dem_SetEventStatus を呼び出してレポートすることはトリガー レポートです。以下の図に示すように、2 つのレポート方法にはそれぞれ長所と短所があり、すべてに適合するものは存在しません。
一般に、小規模なコントローラーの場合、レポートする必要があるイベントの数は多くないため、定期的にレポートすることを選択できます。ドメイン コントローラーの場合、報告する必要があるイベントが多数あるため、安定した負荷率を確保するには、トリガー レポートを選択する必要があります。
3) 「診断イベント」の特徴は何ですか?
1.イベントの種類
イベントの種類は、障害イベントの報告方法に応じて BSW イベントと SWC イベントに分類できます。
| イベントの種類 |
ソース | 報告方法 | 関数名 |
| BSWイベント | BSWモジュール | 標準 C インターフェイス | Dem_ReportErrorStatus |
| SWCイベント | SWCモジュール | RTEインターフェース | イベントステータスの設定（RTE） |
2.イベントの優先順位
診断のために保存できる障害イベントの数と、対応するフリーズ フレームなどの関連データは一定であり、ソフトウェア開発エンジニアが事前に設定する必要があります。障害イベントの内部ストレージがいっぱいになった場合、イベントの優先順位を使用すると、新しい障害イベントを保存する方法の問題を解決できます。
一般に、診断優先順位の設定は、診断システムエンジニアが車両全体の機能から出発し、診断故障の重要性、安全性、深刻度などを総合的に判断して設定されます。たとえば、車の停電はエアコンの故障よりもはるかに深刻であるため、一般に電源関連の故障の優先順位はエアコン関連の故障よりも高くなります。
診断イベントの優先順位には次の重要な特徴があります。
1) 診断イベントの優先順位の値が小さいほど優先順位が高く、値 1 が最も高い優先順位になります。2) イベントの優先順位は、診断イベントがいっぱいの場合にのみ役割を果たし、残りのケースは FIFO 原則に従って格納されます。
3.イベント発生
名前が示すように、Event Occurrence は障害イベント レポート カウンタであり、障害レポートが多いほど、Event Occurrence 値が大きくなり、障害が古いことを示します。「新しい」および「古い」障害タグは、新しい障害イベントを保存する方法の調停メカニズムでも重要な役割を果たします。これについては後で詳しく説明します。
イベントの発生には次のような特徴があります。
1. 各イベント メモリ エントリには、対応するイベント発生があります。
2. イベント発生の最大値は255です。
3. イベント発生のカウント方法には 2 つの設定オプションがあります。
| 構成プロパティ | 数え方 |
| DEM_PROCESS_OCCCTR_TF | Bit0 (TestFail) 0から1にジャンプ、イベント発生+1 |
| DEM_PROCESS_OCCCTR_CDTC | Bit0 (TestFail) が 0 から 1 にジャンプし、Bit3 が 0 から 1 にジャンプし、イベント発生 +1 |
2.4 イベントメモリの記憶内容
イベント、フリーズ フレーム、拡張データなどについては上で詳しく説明しましたが、これらのデータはどのように DEM に保存されるのでしょうか? DEM は、イベント、フリーズ フレーム、拡張データを組み合わせて一元管理するイベント メモリの概念を提供します。さっそく、イベント メモリについて調べてみましょう。
イベントメモリの分類:
| タイプ | 意味 |
| Demプライマリメモリ | EventId、障害ステータス、フリーズフレーム、拡張データを保存 |
| デムミラーメモリ | |
| 永続的なイベントメモリ | OBD 関連の DTC を保存するために使用されます |
イベント メモリの構造を次の図に示します。
イベントメモリ構成アーキテクチャ図
S1: Dem モジュールはプライマリ メモリをサポートする必要があります。ミラーおよび永続メモリはユーザーのニーズに応じて選択できますが、通常は使用されません。
S2: プライマリ メモリは、障害データを保存するためのサイズが DemMaxNumberEventEntryPrimary の不揮発性ストレージ スペースです。つまり、プライマリ メモリは DemMaxNumberEventEntryPrimary Event Memory Entry で構成されます。
基本的に、DemMaxNumberEventEntryPrimary の設定量、NVM がプライマリ メモリの保存に提供する NVM ブロックの数、および保存のみ可能なイベント情報の量。
S3:各イベント メモリ エントリに格納されるコンテンツには、EventId、Occurance Counter、フリーズ フレーム、拡張データ、エージング期間などが含まれます。
2.5 イベントメモリ管理
SWC または BSW がイベントを報告すると、最終的にはどのような処理がフラッシュ内のイベント メモリになりますか?
以下の図からわかるように、イベントが報告された後、次の処理が必要です。
イベント有効条件検出
イベント制御 DTC ビット更新
イベントのメモリ保持
イベントメモリ管理フローチャート
1) イベント有効条件検出
イベントの有効化条件はDemにおけるゲートに相当し、条件が合った場合にのみ実際にイベントがDemの処理フローに入ることができます。
イベント発生条件フローチャート
図からわかるように、イベント通知から第 2 段階の DTC ビット遷移の制御まで多くのプロセスを経る必要があることが分かります。
S1:まず、現在動作サイクルが有効かどうかを判断する必要があります 動作サイクルとは、一般に点火サイクルを指し、DTC 検出の周期とみなすことができます。動作ループが有効な場合は、次の有効条件判定を開始します。そうでない場合は、イベント メモリ管理プロセス全体を直接終了します。
S2: Enable Condition 判定とは、Event レポートに追加される追加条件判定を指し、Dem は SWC の対応するインターフェイスを使用し、SWC は接続条件処理を実装します。一般に、電圧や車両モードなどのいくつかの制限に対処するために使用できます。Enable Condition 条件が満たされている場合は、85 サービス判定を実行し、Enable Condition 条件が満たされていない場合は、イベント メモリ管理プロセスを直接終了します。
S3: 85 サービスを使用して DTC の有効化を抑制している場合は、イベント メモリ管理プロセス全体を直接終了します。85 サービスが実行されていない場合は、Event Debounce プロセスを開始します。
S4:デバウンス後、最終的なイベント結果が合格または失敗の場合は、イベント制御 DTC 遷移の次の段階を開始します。そうでない場合は、直接ジャンプしてイベント メモリ管理プロセス全体を終了します。
イベントデバウンス
「デバウンス」とは、名前が示すように、イベントの誤検知が DTC の誤検知を引き起こすことを防ぐために、イベントの手ぶれ補正処理を指します。
SWC は、Dem_SetEventStatus(EventId, EventStatus) を通じて Passed/Failed/PrePassed/Prefailed の 4 つの状態を報告します。
1) SWC が成功および失敗の状態を報告する場合、Dem はデバウンス処理を実行する必要はありません。2) SWC が Prefailed および Prepassed 状態を報告する場合、Dem はデバウンス処理を実行する必要があります。
本質的に、Dem が提供する Debounce は、特定のメカニズムを通じて PrePassed/Prefailed から Passed/Failed への状態変化を処理することです。
Dem は、「Base Time」と「Base Counter」という 2 つのデバウンス メカニズムを提供します。
1. カウンターベースのデバウンス戦略
カウンターベースのデバウンス戦略のいくつかの重要なパラメーターは次のとおりです。
| パラメータ | 意味 |
| FDC(故障検出カウンタ) |
エラー カウンタ、値の範囲は -128 ～ 127 です |
| DemDebounceCounterFailedThreshold | イベント診断イベントのステータスを最終的に失敗にするデバウンス カウンターのしきい値 |
| DemDebounceCounterPassedThreshold | イベント診断イベント ステータスを最終的に合格にするデバウンス カウンターのしきい値 |
| DemDebounceCounterIncrementStepSize | SWC が Prefailed を報告すると、エラー カウンターが増加します |
| DemDebounceCounterDecrementStepSize | SWC が Prepassed を報告すると、エラー カウンターが増加します |
Couneter に基づくデバウンス メカニズム
上図に示すように、Counter-based Deboucne メカニズムでは、Dem が判定結果を記録するためのカウンター (FDC) を提供し、SWC から Dem に報告される Event ステータスが Prefialed の場合、カウンターはステップ サイズに応じて増加します。設定値に達した場合 制限値に達した場合、障害ステータスは Failed になります。報告された状態が PrePassed の場合、カウンタはステップ サイズに応じて減少し、設定された制限に達すると、障害状態は Passed になります。
2. 時間ベースのデバウンス戦略
時間ベースのデバウンス戦略のいくつかの重要なパラメータは次のとおりです。
| パラメータ | 意味 |
| デバウンス時間ベースのタスク時間 | 基本的なテストサイクル |
| DemDebounceTimeFailedThreshold | 障害ステータスが PreFailed から Failed に遷移するまでにかかる DebounceTimeBasedTaskTime サイクル数を定義します |
| DemDebounceTimePassedThreshold | 障害状態が PrePassed から Passed に遷移するまでにかかる DebounceTimeBasedTaskTime サイクル数を定義します。 |
時間ベースのデバウンス メカニズム
この戦略では、SWC がイベント ステータスの報告を開始すると、Dem モジュールが判定結果を記録するタイマーを提供し、タイマーの成長方向はイベント ステータスによって決定されます。タイマーが特定のしきい値まで蓄積すると、障害ステータスが「合格」または「失敗」に変わります。
3) イベント制御 DTC ステータス更新
イベントが一連の処理を経て、最終的に DTC ステータスを更新することができますが、DTC の 8 ビットの更新ロジックは次のとおりです。
DTC Bit0 更新ロジック
| ビット更新 | 状態 |
| 0 -> 1 | デバウンス後の最終レポートステータスは「失敗」になります。 |
| 1 -> 0 | デバウンス後、最終的に報告されるステータスは「合格」または 14 サービスを使用して DTCOR リセット イベント ステータスをクリアします。 |
DTC Bit0 更新ロジック図
DTC Bit1 更新ロジック
| ビット更新 | 状態 |
| 0 -> 1 | デバウンス後の最終レポートステータスは「失敗」になります。 |
| 1 -> 0 | オペレーション ループ更新または 14 サービスによる DTC のクリア |
DTC Bit1 更新ロジック図
DTC Bit2 更新ロジック
| ビット更新 | 状態 |
| 0 -> 1 | デバウンス後の最終レポートステータスは「失敗」になります。 |
| 1 -> 0 | (操作サイクルの更新 AND TestFailedThisOperationCycle == 0) または 14 サービスを使用してクリア DTCORTestNotCompeleteThisOperationCycle == 0 |
DTC Bit2 更新ロジック図
DTC Bit3 更新ステータス
| ビット更新 | 状態 |
| 0 -> 1 | デバウンス後、最終的に報告されるステータスは FailedAND Fialure Counter > = 障害確認しきい値です。 |
| 1 -> 0 | エージング条件に達した、または DTC が 14 サービスでクリアされた、または 障害オーバーフローが置き換えられた |
DTC Bit3 更新ロジック図
DTC Bit4 更新ロジック
| ビット更新 | 状態 |
| 0 -> 1 | デバウンス後の最終レポートステータスは「失敗」になります。 |
| 1 -> 0 | 14 のサービスで DTC をクリア |
DTC Bit4 更新ロジック図
DTC Bit5 更新ロジック
| ビット更新 | 状態 |
| 0 -> 1 | デバウンス後の最終レポートステータスは「失敗」になります。 |
| 1 -> 0 | 14 のサービスで DTC をクリア |
DTC Bit5 更新ロジック図
DTC Bit6 更新ロジック
| ビット更新 |
状態 |
| 0 -> 1 |
デバウンス後の最終レポートステータスは「失敗」になります。 |
| 1 -> 0 |
14 のサービスで DTC をクリア または 演算周期の更新 |
DTC Bit6 更新ロジック図
DTC Bit7更新逻辑
| Bit位更新 | 条件 |
| 0 -> 1 | 经Debounce后最终上报状态为FailedAND 点灯条件满足 |
| 1 -> 0 | 使用14服务清除DTCOR点灯条件不满足 |
DTC Bit7更新逻辑
4）Retention条件检测
当DTC状态完成更新后，Dem将开始进行Retention条件检测。Dem给用户提供多种策略用以判断是否需要分配Event Memory Entry。分配策略由配置DemEventMemoryEntryStorageTrigger决定，具体如下面表格所示：
| DemEventMemoryEntryStorageTrigger | 分配条件 |
| DEM_TRIGGER_ON_TEST_FAILED | DTC bit0 由0跳变成1 |
| DEM_TRIGGER_ON_CONFIRMED | DTC bit3 由0跳变成1 |
| DEM_TRIGGER_ON_PENDING | DTC bit2 由0跳变成1 |
| DEM_TRIGGER_ON_FDC_THRESHOLD | DTC bit0 由0跳变成1ORDTC bit1由0跳变成1ORDTC bit2由0跳变成1ORDTC bit3由0跳变成1 |
5）Event Memory Retention处理
Event上报经过了使能条件检测，Event控制DTC Bit位状态更新，Retention条件检测重重难关，最终被允许进入Event Memory，Dem会怎样将Event（DTCs），DTC状态，快照，扩展数据存入Event Memory中呢？
基本思路如下：
Event Memory Retention处理机制
S1:イベント メモリのすべてのイベント メモリ エントリを検索し、イベントおよび関連データがイベント メモリに格納されているかどうかを確認し、すでに存在する場合はイベント メモリ エントリ ストレージに入ります。存在しない場合は、イベント メモリ内のスペースを見つけて、イベントのコンテンツを保存します。イベント メモリ内のスペースがいっぱいの場合は、置換メカニズムを使用する必要があります。
S2:イベント メモリ ストレージに入るとき、フリーズ フレームを更新してデータを拡張するかどうかを決定するために、発生カウンターを 1 つインクリメントする必要があります。
イベントディスプレースメント処理
イベントメモリには、DemMaxNumberEventEntryPrimary という番号のイベントメモリエントリが格納されており、イベントメモリエントリがいっぱいになった場合には、新たに追加されたイベントをどのように格納するかという置換が必要となる。Dem モジュールは、交換のための完全なメカニズムを提供します。これには、次の 3 つの基本原則があります。
1. イベント優先度 (数字が小さいほど、保存優先度が高くなります) 2. イベント アクティブまたはイベント パッシブ ステータス (アクティブ優先度がパッシブ優先度よりも高い) 3. イベント発生カウンター (最新の発生の保存優先度が置き換えられたイベントは、DTC の Bit2、Bit3、Bit5 に対応し、0 に設定されます。
以下の図は、イベント ディスプレイスメント メカニズムのセット全体を示しており、置換メカニズムにおける 3 つの中心原則の役割を反映しています。
イベントディスプレイスメントのメカニズム
要約する
DEM は、DTC をコアとして、DTC の監視、レポート、保存の機能を実現する AUTOSAR の基本ソフトウェア モジュールですが、AUTOSAR 診断をさらに学習する必要がある場合は、DCM、Doip、Cantp などのモジュールも体系的に学習する必要があります。
出典 | 自動車エレクトロニクス組み込み