AUTOSAR の Watchdog プロトコル スタックを簡単に理解する記事 (パート 1)
序文
まず最初に、いくつか質問したいのですが、次のとおりです。
- ウォッチドッグの基本的な機能は何ですか?
- ウォッチドッグは一般的な意味で 2 つのカテゴリに分類できますか?
- ウォッチドッグ ソフトウェアの動作メカニズムは AUTOSAR アーキテクチャに基づいていますか?
- ウォッチドッグは機能安全とどのように関係しますか?
- ウォッチドッグを使用するプロセスで回避する必要がある落とし穴は何ですか?
今日は、これらの質問を一緒に調べて答えてみましょう。誰でも理解しやすいように、この記事のトピックの概要を以下に示します。
文章
ウォッチドッグの基本機能
ご存知のとおり、ウォッチドッグ (中国語名はウォッチドッグ) は、デバイスが無人であるときにシステムに異常が発生した場合に、システムのリセット操作を自動的に完了して、機能全体を継続的に使用できるようにすることを実現します。
ウォッチドッグ機能はセーフティ クリティカルなシステムに必要ですが、セーフティ クリティカルでないシステムにも必要です。
なぜそんなことを言うのですか？その理由は、ハードウェアの世界で動作するソフトウェアは、ハードウェア自体の老朽化や損傷、外部からの電磁干渉など、さまざまな外部要因の影響を受け、プログラムの実行中に予期せぬ動作を引き起こす可能性があるためです。デバイスが人の少ない砂漠地帯にある場合、間違いなく不必要なメンテナンス費用が多額に増加することになります。
自動車に使用される多くのコンポーネントでは、自動車の過酷な環境を考慮して、さまざまな ECU 内のソフトウェアが外部電磁干渉や高温などの環境要因の影響を受け、「暴走」または「」現象が発生する可能性があります。この時点でウォッチドッグが存在する場合、ウォッチドッグは、修理のために 4S ショップに送られるのをただ監視するのではなく、システム リセット メカニズムを積極的にトリガーして、正常に再び使用できるようにすることができ、製品の評判に影響を与える可能性があります。または、不要なアフターメンテナンス費用が追加されます。
ウォッチドッグの実装ロジックに基づいて、一般にウォッチドッグをハードウェア ウォッチドッグとソフトウェア ウォッチドッグに分けることができます。
ハードウェアウォッチドッグはその名のとおり、ハードウェア自体の仕組みによってウォッチドッグ機能を実現するもので、その本質もタイマーの原理によって実現されますが、現時点ではソフトウェアの役割はタイマーを有効にすることだけです。 、タイマー自体の変更と更新はハードウェア自体によって完了します。ソフトウェア ウォッチドッグは、タイマー全体をソフトウェアによって完全に有効にして更新します。もちろん、ソフトウェアもタイマーによって完了しますが、それは間接的なものにすぎません。方法。
ハードウェアウォッチドッグ
前述したように、ハードウェア ウォッチドッグは、一般に「ハード ドッグ」として知られるウォッチドッグ機能を完了するために独自のタイマーに依存します。一般的なハードウェア ウォッチドッグには、MCU に組み込まれたウォッチドッグ、PMIC に組み込まれたウォッチドッグ、および独立した外部ウォッチドッグが含まれます。
どのハードウェア ウォッチドッグを選択するかについては、独自のシステム設定のニーズに完全に依存し、同じものを選択することはできません。ただし、ハードウェアウォッチドッグを使用する場合は、次の 2 つの点を考慮する必要があります。
- ハードウェア ウォッチドッグの最大タイムアウト時間がシステム設計要件を満たしているかどうか、タイムアウト時間が小さすぎると、システム全体が不安定になり、誤ってウォッチドッグがトリガーされてしまいます。
- ハードウェア ウォッチドッグをオフにできるかどうかに関係なく、主要なセキュリティ システムでは、通常、ウォッチドッグが一度オンになるとオフにすることは許可されないことが要求されます。
- ハードウェア ウォッチドッグ システムは、デフォルトで電源がオンまたはオフになります。ウォッチドッグがデフォルトでオンになっている場合、ソフトウェアでは、チップの電源がオンになった後にウォッチドッグに給電またはリセットすることを考慮する必要があります。ソフトウェアをフラッシュしたりソフトウェアをデバッグしたりする前にアクションを閉じる。
- GPIO、IIC、または SPI 通信方法を介してドッグに餌を与えるなど、ハードウェア ウォッチドッグがドッグに餌を与えるために使用する方法はどれですか。これは、さまざまな通信ドッグ餌やり方法にチップのハードウェア リソースの要件があるため、比較的シンプルで信頼性が高いためです。可能な限り通信方法は犬に餌を与えるために使用できます。T 君は GPIO が IIC よりも優れており、IIC が SPI よりも優れていると考えています。
次の図 1 は、さまざまな通信方式を備えた市販のハードウェア ウォッチドッグのリストです。
- GPIO 給餌犬ハードウェア ウォッチドッグ:
- IIC 給餌犬ハードウェア ウォッチドッグ:
- SPI 給餌犬ハードウェア ウォッチドッグ:
ソフトウェアウォッチドッグ
前述したように、ソフトウェア ウォッチドッグは、一般に「ソフト ドッグ」として知られるソフトウェア タイマーによるウォッチドッグ機能の実現に属します。ソフトウェア ウォッチドッグの時間も、基本的にハードウェア周辺機器のハードウェア タイマーに依存する必要があります。
たとえば、通常、タイミング機能を実行するには ostick メソッドを使用します。タスクは、ソフト ドッグによって監視されているタイマーが減少し続けるメイン プログラムを実行し、他のタスク プログラムはタイマーをリセットします。ソフトウェアがタスクのメイン プログラムを監視している場合、タイマがゼロにリセットされると、他のタスクが正常に実行されていないと判断でき、このときアクティブにリセットすることでウォッチドッグ機能を実現できます。
一般に、ソフトドッグを実行するメインタスクの優先度は、監視対象タスクの優先度よりも低く設定しないでください。ハードウェアウォッチドッグと併用して使用します。一般に、ソフトドッグのメインタスクとハードウェアウォッチドッグのフィードは、メインタスクは同じタスクに入れられるため、以下の図 2 に示す階層関係が保証されます。
上の図は参考用の実際の例として使用されており、具体的な実装方法はプロジェクトの要件に応じて決定できます。この図では、タスク A、B、および C の優先順位はすべてタスク D の優先順位よりも低くなります。タスク D で硬い犬に餌を与えると、タスク D が正常に実行されている一方で、他のタスクがハングアップしてしまう可能性があります。システムが常に正常に動作しているため、ハードウェアウォッチドッグの保護機能が果たせなくなります。
したがって、ハード ドッグに餌を与えるタスクの優先度が高くなりすぎて、他の優先度の低いタスクがハングして検出できなくなるのを防ぐために、優先度の低いタスクを保護するためにソフト ドッグを追加する必要があります。
タスクA、B、Cにより各カウンタをリセットします。リセット値の設定は各タスクの最大実行時間と周期に合わせて決定する必要があり、タスクDは各タスクを実現するためにソフトドッグ監視本体を実行します。カウンタのデクリメント動作では、リセット値時間内にすべてのタスク カウンタが 0 に等しくない場合、他の優先度の低いタスクが正常に実行されていることを意味します。このとき、ハード ドッグには GPIO、IIC、またはSPI は通常通り、それ以外の場合は、いずれかのカウンターが 0 の場合は、犬への餌やりを停止するか、リセット動作を積極的にトリガーする必要があります。
AUTOSAR ウォッチドッグ プロトコル スタックの概要
実際、AUTOSAR アーキテクチャでは、ソフト ドッグとハード ドッグを組み合わせて使用する上記のアプリケーション シナリオについて、Watchdog プロトコル スタック全体での標準化も考慮されているため、実際のプロジェクト開発プロセスでさらに学習することができます。以下の内容 AUTOSAR ベースの Watchdog プロトコル スタックの動作原理と使用法を理解します。
以下の図 3 は、Watdog プロトコル スタックの AUTOSAR アーキテクチャのソフトウェア レベルのトポロジ図を示しています。
上の図 3 に示すように、AUTOSAR アーキテクチャでは、ウォッチドッグ プロトコル スタックは次の 3 つのソフトウェア モジュールに分割できます。
- ウォッチドッグ ドライバー: ハードウェア ウォッチドッグのレジスタ操作と制御を実装するために使用され、MCU 内部ウォッチドッグ (内部ウォッチドッグ) と外部ウォッチドッグ (外部ウォッチドッグ) に分けることができます。外部ウォッチドッグは GPIO、IIC、または SPI を介してドッグ フィードを実現できます。
- Watchdog Interface : Watchdog If は Watchdog Stack 全体の一部であり、その主な機能は、上位レベルの Watchdog Manager と基礎となる Watchdog Driver 間の接続を実現することです。もちろん、それに接続されている基礎となる Watchdog Driver が複数存在する可能性があります。マルチコア設計ではより一般的です。
- ウォッチドッグ マネージャー: ウォッチドッグ マネージャー モジュールは、ウォッチドッグ プロトコル スタック全体のサービス層です。ウォッチドッグ マネージャーの主な機能は、プログラム全体の実行の正確性を担当し、対応するハードウェア ウォッチドッグの犬の餌やりアクションをトリガーすることです。監視全体のコアの役割。
AUTOSAR ウォッチドッグ スタック全体の機能は、前述の AUTOSAR アーキテクチャに基づく 3 つのモジュールを通じて実現できます。次に、Xiao T がこれら 3 つのモジュールをより明確に理解できるように、これら 3 つのモジュールについて詳しく説明します。実戦に応用。
Watchdog Driver モジュールについて
このモジュールは、ハードウェア ウォッチドッグの初期化、動作モードの変更、ドッグに餌を与えるためにウォッチドッグをトリガーする方法の設定などの機能を提供します。同時に、ウォッチドッグがチップ内部に位置するかどうかに応じて、チップ内部に位置するウォッチドッグを内部ウォッチドッグと呼び、チップ外部に位置するウォッチドッグを外部ウォッチドッグと呼ぶことができます。
内部ウォッチドッグか外部ウォッチドッグかに関係なく、ウォッチドッグ ドライバーによって使用されるウォッチドッグ駆動 API は常に一貫している必要があります。内部ウォッチドッグの場合、そのドライバーは MCAL レイヤーに属し、外部ウォッチドッグの場合は ECU ハードウェア抽象化レイヤーに属します。外部ウォッチドッグ ドライバーは、ドッグ フィード アクションを実現するために MCAL 内の他のドライバーを呼び出す必要があります。 GPIO、IIC または SPI などのドライブ。
内部ウォッチドッグ
前述したように、内部ウォッチドッグはチップ内部のハードウェアウォッチドッグであり、内部ウォッチドッグドライバーは通常チップメーカーによって提供されますが、チップの内部ウォッチドッグを使用する前に、リセット アクションはコールド リセットであり、不完全なリセットなどのシナリオがある場合でも、そうでない場合はセキュリティ監視の目的が達成されない可能性があります。
内部ウォッチドッグはチップ自体に関係しているため、チップ自体のハードウェアに問題があると内部ウォッチドッグ自体が機能しなくなり、保証できない窮地に陥る可能性があります。主要なセキュリティ システムの場合、内部ウォッチドッグだけを使用するのは安全ではなく、機能の安全性を確保するには外部ウォッチドッグに依存する必要があります。
外部ウォッチドッグ
外部ウォッチドッグは、保護されたチップの外側にあるウォッチドッグです。ウォッチドッグは独立したハードウェア ウォッチドッグにすることができます。つまり、この種のウォッチドッグはウォッチドッグ機能のみを提供しますが、一般的には QM レベルであり、別のタイプの統合ウォッチドッグです。この種のウォッチドッグは、通常、ASIL B または ASIL D の機能安全レベルの要件を満たすことができます。
通常、重要な安全システムには外部ウォッチドッグが必要ですが、ある意味、内部ウォッチドッグは実際には必要なく、外部ウォッチドッグが重要です。
ウォッチドッグ制御モード
AUTOSAR アーキテクチャでは、ウォッチドッグ ドライバーのウォッチドッグ制御モードは次の 3 つのモードを持つように定義されています。
- オフ モード: ウォッチドッグがオフであることを示します。主要な安全システムの場合、オフに切り替えることはできません。つまり、一度オンにするとオフにすることはできません。
- スロー モード: ウォッチドッグの長時間のドッグ給餌ウィンドウを示します。これは通常、システム起動の初期化プロセスで使用されます。
- 高速モード: システムの通常動作中に使用される、ウォッチドッグの通常のドッグ給餌ウィンドウ給餌モードを示します。
番犬の給餌タイミング
以下の図 4 に示すように、ウォッチドッグの初期化、ウォッチドッグ フィードのトリガー、およびウォッチドッグ モードの変更には 3 種類の関数呼び出しシナリオがあります。
-
ウォッチドッグの初期化: EcuM モジュールを通じて関数Wdg_Init を呼び出して、ウォッチドッグの初期化設定を完了します。
-
ウォッチドッグをトリガーして犬に餌を与える: WdgM モジュールを通じて WdgIf モジュールによって提供される関数WdgIf_SetTriggerConditionを呼び出して、基礎となるドライバーが犬に餌を与えるアクションを実行するようにトリガーします。
-
ウォッチドッグ モードを変更します。WdgM モジュールを介して WdgIf モジュールによって提供される関数WdgIf_SetModeを呼び出して、ウォッチドッグ モードを変更します。
以下の図 5 は、Wathdog ドライバーと基盤となるウォッチドッグ ハードウェア間の対話のタイミング図です。以下の図から、WdgIf_SetTriggerCondition が Wdg ドライバー内の関数 Wdg_SetTriggerCondition を呼び出し続けて、ドッグの給餌アクションを実現することがわかります。
共通機能APIと設定パラメータ
誰もがこのモジュールの主要な機能を簡単に簡単に呼び出すことができ、より明確に理解できるようにするために、Xiao T は表の形式で次の概要を作成しました。
Watchdog If モジュールについて
Watchdog If モジュールの機能の説明
Watchdog If モジュールの正式名は Watchdog Interface インターフェイスであり、基礎となる Watchdog Driver の抽象化として、このインターフェイスは基礎となるハードウェアとソフトウェア間の分離を実現します。
このモジュールの基本機能は、基盤となるウォッチドッグ ドライバーと上位層のウォッチドッグ管理モジュール間の対話を実現するための、基盤となるドライバーの抽象化層としてのみ使用されます。基盤となるウォッチドッグ ドライバーのウィンドウ制御や期間などの特性は、 Watchdog If モジュールを介して完了するように設定することはできません。
複数のウォッチドッグ ドライバーが上位ウォッチドッグ マネージャーによって管理されている場合は、DeviceIndex をチェックする必要があり、エラーがある場合は、時間内に報告する必要があります。
共通機能APIと設定パラメータ
誰もがこのモジュールの主要な機能を簡単に簡単に呼び出すことができ、より明確に理解できるようにするために、Xiao T は表の形式で次の概要を作成しました。
ウォッチドッグ マネージャー モジュールについて
Watchdog Manager モジュールの仕組み
ウォッチドッグ マネージャーは、アプリケーション層のソフト ドッグ メカニズムとして理解でき、このソフトウェア メカニズムによって監視されるオブジェクトは「監視エンティティ」と呼ばれます。その監視方法は以下の3種類に分けられます。
-
Alive Supervision: 定期タスクが定期的に実行されるかどうかを監視するために使用されます。
-
期限監視: イベントベースのタスクの実行時間がタイムアウトしたかどうかを監視するために使用されます。
-
論理監視：タスクの実行タイミングが正しいかどうかを監視するために使用されます。
各監視エンティティの対応するチェックポイントをマークすることにより、各監視エンティティは 1 つ以上のチェックポイントを持つことができます。監視エンティティ内のチェックポイントとその変換関係は内部グラフと呼ばれます。別の監視エンティティからのものである場合、チェックポイントとその変換関係はは外部グラフです。
上記の 3 つの監視メカニズムは各エンティティを監視するために使用され、監視対象の各エンティティでは、特定の要件に応じて 1 つ以上、または 3 つのメカニズムすべてが有効になっている場合があります。上記 3 つの監視メカニズムの監視結果に基づいて、各監視エンティティを計算できます。これはローカル ステータスと呼ばれます。
各監視エンティティのステータスが決定すると、最終的に MCU 全体の監視結果が決定され、この最終ステータスをGlobal Statusと呼びます。
ウォッチドッグ マネージャーの具体的なワークフロー:
S1: ウォッチドッグ マネージャー モジュールは、ウォッチドッグ If およびウォッチドッグ ドライバーを介してドッグに供給するウォッチドッグ ドライバーのトリガー条件を設定する責任を負います。トリガー条件は、ウォッチドッグ マネージャーの関数インターフェイスを通じてカウンター値をリセットすることです。
S2: カウンタが 0 でない場合、ウォッチドッグ ドライバはドッグに 1 回餌を与え、カウンタ値を 1 減らします。
S3: カウンター値がウォッチドッグ マネージャーによって時間内にリセットされなかった場合、カウンター値は 0 に減らされ、その後ウォッチドッグ ドライバーはドッグへの給餌を停止するため、ウォッチドッグはシステム リセットをトリガーします。それ以外の場合は S2 の実行を継続します。
トリガー条件が満たされず、犬に通常どおり餌を与えることができない場合、システムで犬に餌を与える方法が 2 つあることに注意してください。
- ウォッチドッグ タイムアウトのリセットを待ちます。ドッグへの餌やりを停止し、ウォッチドッグ タイムアウトのリセットを待ちます。
- システム リセットを直ちにアクティブにトリガーします。ウォッチドッグ マネージャーでエラーが発生すると、システム リセットをアクティブにトリガーできます。
上記２つのリセット方法は共存可能であり、具体的にどちらのリセット方法を実行するかは必要に応じて実行可能である。
ウォッチドッグ マネージャを使用する場合、ウォッチドッグ ドライバの初期化はウォッチドッグ マネージャではなく EcuM モジュールによって完了するため、ウォッチドッグ マネージャの初期化は OS の電源をオンにした後に実行する必要があります。
アライブ監修
前述したように、定期タスクの監視エンティティでは、指定された時間範囲内での対応する監視エンティティの実行数が決定され、この監視メカニズムを使用して、特定の定期タスクの実行頻度が多すぎる、または少なすぎることを検出できます。
AliveSupervision を使用するプロセスでは、次の点に注意してください。
- 監視エンティティの場合、Alive 監視メカニズムが使用されている場合、チェックポイントは 1 つだけである必要があります。現在サポートされているチェックポイントは 1 つだけです。
- Alive Supervision の監視方法とその効果を決定するには、次の 4 つのパラメータに従って調整して使用します。
期限の監督
前述したように、非周期タスクの監視エンティティの場合、監視エンティティに対応する 2 つのチェックポイント間の時間が一定の範囲内にある必要があり、2 つのチェックポイント間の時間が設定された最小値内であるかどうかを判断できます。値と最大値の間。
Deadline Supervision を使用するプロセスでは、次の点に注意してください。
- この監視メカニズムは遅延のみを監視できますが、エンド チェックポイントが実行されていないなどのタイムアウトは検出できません。
- 監視メカニズムは、start 1、start2、end2、end1 などのネストをサポートしていません。
- 次の図は Deadline Supervision のロジック図であり、2 つのチェックポイント間の時間差を計算することで、設定された要件が満たされているかどうかを判断できます。
ロジック監視
前述したように、ロジック監視はプログラムフローの実行タイミングが正しいかどうかを認識するために使用され、機能安全を満たすECUにとって非常に重要であり、実際の実行プロセスにおけるチェックポイント間の切り替え関係が設定を満たしているかどうかを確認することで、チェックポイントが切り替わります。設定されたチェックポイント関係内にない場合は、エラーが報告されます。両方がチェックポイント内にある場合は、すべてが正常に実行されています。
以下の図は論理監視のトポロジを示しており、2 つのチェックポイント間の切り替え関係が静的に設定された切り替え関係グループに属するかどうかを識別することで、正常なシーケンス動作が実行されるかどうかを判断します。
以下の図に示すように、これは Watchdog Manager モジュール全体の動作メカニズムです。
上の図に基づいて、次の重要な結論を導き出すことができます。
- Alive Supervisionを使用した監視エンティティ、判定結果はWdgM_Mainfunctionで取得されます。
- Deadline Supervision または Logical Supervision を使用してエンティティを監視する場合、判定結果は関数WdgM_CheckpointReachedで取得されます。
- 各監視エンティティにはローカル ステータスがあり、ローカル ステータスの最終結果によって最終 ECU のグローバル ステータスが決まります。したがって、WdgM のローカル ステータスがどのように変化するかを把握する必要があります。下の図 10 はローカル ステータスの状態を示しています機械：
上の図 10 から、次の基本的な結論を導き出すことができます。
- 図に示すように、実行シーケンス 10 では、WdgM_Init 関数の実行後、各監視エンティティのローカル ステータスがWDGM_LOCAL_STATUS_OKに変更されます。
- 図に示すようにシーケンス 11 を実行すると、 WdgM_Init の実行中にWdgMInitialModeによって参照されない監視エンティティが存在する場合、これらの監視エンティティの値はデフォルトでWDGM_LOCAL_STATUS_DEACTIVATEDに設定され、同時にWdgMInitialMode のWdgMInitialModeによって参照される監視エンティティがWDGM_LOCAL_STATUS_OKに設定されていない場合は、 WDGM_LOCAL_STATUS_DEACTIVATEDにも設定されます。
- すべての監視エンティティの監視結果が OK で、監視エンティティのローカル ステータスが WDGM_LOCAL_STATUS_OK の場合、シーケンス 1が実行されます。
- 監視エンティティのステータスが WDGM_LOCAL_STATUS_OK であるが、対応するアライブ監視、デッドライン監視、または論理監視の結果が正しくない場合、ステート マシンはシーケンス 2を実行します。
- 監視エンティティの生存監視の結果にはエラーしきい値を設定できるため、監視エンティティのデッドライン監視または論理監視の結果がすべて正しい場合でも、誤っているが期限を超えない特定の生存監視結果が存在する場合、 set error しきい値に達すると、シーケンス 3 が実行され、WDGM_LOCAL_STATUS_FAILED に入ります。
- 現在の監視エンティティ (SE) の状態が WDGM_LOCAL_STATUS_FAILED 状態である場合、デッドライン監視または論理監視の結果はすべて正しいが、エラーしきい値を超えない少なくとも 1 つのアライブ カウンター エラーがある場合は、シーケンスが実行されます。 4 が実行されます。
- SE Local Status == WDGM_LOCAL_STATUS_FAILED 状態、SE の Alive Supervision が正しく、現在の障害数が 1 より大きく、対応する Deadline Supervision または Logical Supervision の結果が正しい場合、SE は引き続き状態のままになります。 WDGM_LOCAL_STATUS_FAILED 状態ですが、シーケンス 4など、エラーの数が 1 つ減少します。
- SE Local Status == WDGM_LOCAL_STATUS_FAILED 状態、SE の Alive Supervision が正しく、現在の障害数が 1 で、対応する Deadline Supervision または Logical Supervision の結果がすべて正しい場合、状態は切り替わります。 WdgM_MainFunction 状態で WDGM_LOCAL_STATUS_OK に変更し、同時にエラーの数を 0 に減らします (シーケンス 5など) 。
- SE ローカル ステータス == WDGM_LOCAL_STATUS_FAILED 状態、SE の生存監視が正しくなく、現在の障害の数がしきい値を超えている場合、または少なくとも 1 つの対応するデッドライン監視または論理監視の結果が間違っている場合、ステータスが表示されます。 WdgM_MainFunction で WDGM_LOCAL_STATUS_EXPIRED 状態 (シーケンス 6など) に切り替えます。
- SE Local Status == WDGM_LOCAL_STATUS_OK 状態で、状態を OFF 状態に切り替えるために WdgM_SetMode が実行された場合、ステート マシンの状態はシーケンス 7などの WDGM_LOCAL_STATUS_DEACTIVATED 状態に変更されます。
- SE Local Status == WDGM_LOCAL_STATUS_FAILED 状態で、状態を抑制状態に切り替えるために WdgM_SetMode が実行された場合、ステート マシンの状態はシーケンス 8などの WDGM_LOCAL_STATUS_DEACTIVATED 状態に変更されます。
- SE Local Status == WDGM_LOCAL_STATUS_DEACTIVATED ステータスの場合、WdgM_CheckpointReached 関数と WdgM_MainFunction 関数はシーケンス 8などの監視関数を開始しません。
- SE Local Status == WDGM_LOCAL_STATUS_DEACTIVATED 状態の場合、WdgM_SetMode を実行して状態をアクティブ状態に切り替えると同時に、ステート マシンの状態はシーケンス 9 などの WDGM_LOCAL_STATUS_OK 状態に変更されます。
- 他の状態から WDGM_LOCAL_STATUS_EXPIRED 状態に切り替える場合、ウォッチドッグ マネージャーは、ウォッチドッグ モードの設定や NVM データの書き込み、リセット理由などの特別な操作を実行できる特定の時間保持メカニズムを提供します。
上で監視エンティティのローカル ステータス ステート マシンの変換条件について説明した後、監視エンティティのグローバル ステータス ステート マシンを詳しく見てみましょう。これを以下の図 11 に示します。
上の図 11 に示すように、ウォッチドッグ マネージャーには、監視対象ソフトウェア全体に対してグローバル ステータスが 1 つだけあります。ステート マシンの変更に関する具体的なルールは次のとおりです。
- WdgM_Init 関数が実行されると、Global Status == WDGM_GLOBAL_STATUS_OK (シーケンス 13 など)。
- Global Status == WDGM_GLOBAL_STATUS_OK ステージの場合、関数 WdgM_DeInit が実行され、ステート マシンが次のように切り替わります。 Global Status == WDGM_GLOBAL_STATUS_ DEACTIVATED (シーケンス 14 など)。
- グローバル ステータス == WDGM_GLOBAL_STATUS_OK、およびすべての SE のローカル ステータス == WDGM_LOCAL_STATUS_OK または WDGM_LOCAL_STATUS_DEACTIVATED の場合、グローバル ステータスはシーケンス 1 のように変更されません。
- グローバル ステータス == WDGM_GLOBAL_STATUS_OK で、ローカル ステータス == WDGM_LOCAL_STATUS_FAILED の SE が少なくとも 1 つあり、SE 結果 == WDGM_LOCAL_STATUS_EXPIRED がない場合、グローバル ステータスはシーケンス 2 などの WDGM_GLOBAL_STATUS_FAILED 状態に切り替わります。
- グローバル ステータス == WDGM_GLOBAL_STATUS_OK で、ローカル ステータス == WDGM_LOCAL_STATUS_EXPIRED の SE が少なくとも 1 つあり、WdgMExpiredSupervisionCycleTol 設定が 0 より大きい場合、グローバル ステータスはシーケンス 3 などの WDGM_GLOBAL_STATUS_EXPIRED 状態に切り替わります。
- グローバル ステータス == WDGM_GLOBAL_STATUS_OK で、ローカル ステータス == WDGM_LOCAL_STATUS_EXPIRED の SE が少なくとも 1 つあり、WdgMExpiredSupervisionCycleTol 設定が 0 に等しい場合、グローバル ステータスはシーケンス 4 などの WDGM_GLOBAL_STATUS_STOPPED 状態に切り替わります。
- グローバル ステータス == WDGM_GLOBAL_STATUS_FAILED、ローカル ステータス == WDGM_LOCAL_STATUS_FAILED の SE が少なくとも 1 つあり、WDGM_LOCAL_STATUS_EXPIRED に等しい SE がない場合、グローバル ステータス ステータスは変更されないままになります (シーケンス 5 など)。
- グローバル ステータス == WDGM_GLOBAL_STATUS_FAILED、およびすべての SE == WDGM_LOCAL_STATUS_OK または WDGM_LOCAL_STATUS_DEACTIVATED の場合、グローバル ステータスは WDGM_GLOBAL_STATUS_OK (シーケンス 6 など) に切り替わります。
- グローバル ステータス == WDGM_GLOBAL_STATUS_FAILED で、ローカル ステータス == WDGM_LOCAL_STATUS_EXPIRED の SE が少なくとも 1 つあり、WdgMExpiredSupervisionCycleTol 設定が 0 より大きい場合、グローバル ステータスは WDGM_GLOBAL_STATUS_EXPIRED (シーケンス 7 など) に切り替わります。
- グローバル ステータス == WDGM_GLOBAL_STATUS_FAILED の場合、ローカル ステータス == WDGM_LOCAL_STATUS_EXPIRED の SE が少なくとも 1 つあり、WdgMExpiredSupervisionCycleTol が 0 に設定されている場合、グローバル ステータスは WDGM_GLOBAL_STATUS_STOPPED (シーケンス 8 など) に切り替わります。
- Global Status == WDGM_LOCAL_STATUS_EXPIRED で、タイムアウト カウンター カウントが WdgMExpiredSupervisionCycleTol で設定された値より小さい場合、そのステータスはシーケンス 9 のように変更されません。
- Global Status == WDGM_LOCAL_STATUS_EXPIRED で、カウントが WdgMExpiredSupervisionCycleTol より大きい SE が少なくとも 1 つある場合、その状態は WDGM_GLOBAL_STATUS_STOPPED に切り替わります。この状態では、ウォッチドッグ ドライバーはドッグへの供給を停止し、ウォッチドッグ タイムアウトのリセットを待ちます。シーケンス10;
- Global Status == WDGM_GLOBAL_STATUS_STOPPED の場合、そのステータスはシーケンス 11 のように変更されません。
- 呼び出し関数 WdgIf_SetMode が失敗すると、グローバル ステータスも WDGM_GLOBAL_STATUS_STOPPED 状態 (シーケンス 12 など) に切り替わります。
共通機能APIと設定パラメータ
誰もがこのモジュールの主要な機能を簡単に簡単に呼び出すことができ、より明確に理解できるようにするために、Xiao T は表の形式で次の概要を作成しました。
ウォッチドッグと機能安全の関係
ISO26262ではプログラムフロー監視が最も重要な項目となっており、プログラムフロー監視によりソフトウェア動作時に設計意図を逸脱する可能性のあるエラーを発見し、適切な対策を講じて安全運転を確保します。
AUTOSAR ソフトウェア アーキテクチャでは、プログラム フローの監視機能は主に Watchdog プロトコル スタックによって実現されており、上から順に WdgM モジュール、WdgIf モジュール、Wdg ドライバ モジュールが含まれており、アプリケーション層ではこれら 3 つのモジュールが構成されています。 RTE を通じてアプリケーションに与えられるこの層はインターフェイス サービスを提供し、それによって最下位層でアプリケーション層ソフトウェアを監視する目的を実現します。
番犬の実務経験
- EcuM モジュールを通じてウォッチドッグの初期化が完了した後、最初に設定されたウォッチドッグ カウンタの初期値は、ウォッチドッグ ドライバの初期化からウォッチドッグ マネージャの初期化までの時間を可能な限りカバーできます。そうでない場合は、犬がタイムアウトになってしまいます。
- OS をシャットダウンする前に、ウォッチドッグ マネージャの初期化解除プロセスからシステムの電源ダウンまたは再リセットまでのプロセスを確実にカバーできるように、初期化解除プロセス中にウォッチドッグ マネージャをより大きなタイムアウト値に設定する必要があります。
- ECU がスリープ モードをサポートしている場合、ECU がスリープ状態にあるときにウォッチドッグがまだアクティブである場合、ウォッチドッグ フィード操作は EcuM モジュールで完了する必要があります。
- システムの初期化と休止状態の 2 つの段階では、ウォッチドッグがタイムアウトする可能性があるかどうかを考慮することが重要です。基礎となるハードウェアが時間内にドッグに餌を与えることができない場合、システムに大きな影響を与えます。
ウォッチドッグ プロトコル スタック全体には多くの内容があるため、皆さんが理解しやすいように、Xiao T はウォッチドッグ プロトコル スタック全体の説明を 2 つのパートに分けて説明し、次のパートでは上記 3 つの監視メソッドの内部処理ロジックに焦点を当てます。ご清聴ありがとうございます。
犬がタイムアウトになりました。
- OS をシャットダウンする前に、ウォッチドッグ マネージャの初期化解除プロセスからシステムの電源ダウンまたは再リセットまでのプロセスを確実にカバーできるように、初期化解除プロセス中にウォッチドッグ マネージャをより大きなタイムアウト値に設定する必要があります。
- ECU がスリープ モードをサポートしている場合、ECU がスリープ状態にあるときにウォッチドッグがまだアクティブである場合、ウォッチドッグ フィード操作は EcuM モジュールで完了する必要があります。
- システムの初期化と休止状態の 2 つの段階では、ウォッチドッグがタイムアウトする可能性があるかどうかを考慮することが重要です。基礎となるハードウェアが時間内にドッグに餌を与えることができない場合、システムに大きな影響を与えます。
ウォッチドッグ プロトコル スタック全体には多くの内容があるため、皆さんが理解しやすいように、Xiao T はウォッチドッグ プロトコル スタック全体の説明を 2 つのパートに分けて説明し、次のパートでは上記 3 つの監視メソッドの内部処理ロジックに焦点を当てます。ご清聴ありがとうございます。
AUTOSAR のよりエキサイティングで実践的なコンテンツについては、公式アカウント「ADAS と ECU に関する私の意見」をぜひご注目ください。