2409039_ja-JP

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

2409039_ja-JP

2409039_ja-JP

AUTOSARネットワーク管理のスリープ/ウェイクアップの関連性

こんにちは、現在EcuMとネットワークマネジメントのデバッグを行っています。仕様書をいくつか参照しましたが、まだ不明な点があり、ご指導をお願いしたいです。

  1. ネットワーク**マネジメント**のスリープ/ウェイクアップには、EcuMとの連携が必須ですか(つまり、EcuMがウェイクアップの原因を検証する必要がありますか)?

  2. ネットワーク管理のスリープ/ウェイクアッププロセス中、ECUはスリープ(つまりEcuMスリープ)に入る必要がありますか?

  3. 質問1への回答が「はい」の場合、EcuMはインターフェースを介してウェイクアップイベントを取得します。 EcuM_SetWakeupEvent 。ただし、AUTOSAR EcuM 仕様 SWS_EcuM_04318 には次のように記載されています。 「選択されたスリープモードに関連付けられていないウェイクアップイベントは無視される。」 これはどういう意味で理解すればいいのでしょうか?

  4. AUTOSAR EcuM仕様にはインターフェースに関する2つの項目も含まれています EcuM_ValidateWakeupEvent – SWS_EcuM_02790とSWS_EcuM_02791。ComMチャネルに関連するウェイクアップソースは、任意のフェーズで有効であると述べています。これは、どのフェーズでもウェイクアップイベントを保留(すなわち、成功裏に通過 EcuM_SetWakeupEvent)し、その後検証される可能性があるという意味でしょうか?

Re: The connection between AUTOSAR Network Management sleep/wake-up

こんにちは、

1. NMの睡眠・覚醒にはEcuMの協調が必要ですか?
必ずしもそうとは限りません。NM/ComMはネットワーク通信を管理し、EcuMはECUの電源状態を管理します。EcuMウェイクアップ検証は、ECUが実際にEcuMスリープ状態に入った場合に主に重要となる。

2. NMスリープとは、ECUがEcuMスリープに移行しなければならないことを意味しますか?
いいえ。ネットワークはECUがRUNモードのままローカル機能を実行し続ける間、バススリープに入ることができます。

3. SWS_EcuM_04318を理解するには?
つまり、EcuMは現在選択されているスリープモードに設定されたウェイクアップイベントのみを受け入れているということです。そのスリープモードで有効になっていないソースからのウェイクアップイベントは無視されます。これは、誤ったハードウェアイベントが意図せずECUを起動させるのを防ぎます。

4. ComM関連のウェイクアップソースは、EcuMのどのフェーズでも検証可能ですか?
はい。これは意図的な特別措置です。汎用ウェイクアップソースはスリープ中にのみ受け入れられますが、ComMチャネルに関連付けられたソース(CANウェイクアップフレームなど)は、EcuM_SetWakeupEventを介して保留し、EcuM_ValidateWakeupEventを介して任意のEcuMフェーズで検証できます。これにより、ウェイクアップイベントによって進行中のGo-Sleepシーケンスを中止することが可能になります。これは、NMウェイクアップをEcuMにリンクさせる重要なメカニズムです。

要するに、NMスリープ≠ECUスリープであり、ComMリンクされたウェイクアップソースはEcuMで特別な処理を受け、通常のウェイクアップシーケンス外での検証が可能となる。


BR、ペトル

回复: The connection between AUTOSAR Network Management sleep/wake-upこんにちは、ご回答ありがとうございます。あなたの回答に関して、まだいくつか疑問点があります。度々お手数をおかけして申し訳ございません。また、事前に感謝申し上げます。

ネットワーク**マネジメント**のスリープ/ウェイクアップも、ウェイクアップソースの検証にEcuMが必要になるように思えます。なぜなら、ネットワーク**マネジメント**のパッシブモードでは、EcuMによるウェイクアップソースの検証が必要だからです。ComMチャネルに関連付けられたウェイクアップソースが正常に検証されると、EcuMはComMインターフェースを呼び出し、ネットワークはウェイクアップできます。最初の回答で、EcuMのウェイクアップ検証は、ECUが実際にEcuMスリープ状態に入った場合にのみ必要だとおっしゃっていましたね。つまり、ネットワークマネジメントのスリープ/ウェイクアップの後、ECUもEcuMスリープ状態に入り、その後EcuMのウェイクアップ検証プロセスを経る必要があると解釈しています。しかし、これはあなたの2番目の回答と多少矛盾しているように思えます。私の理解が正しいかどうか自信がありません。

あなたの3回目と4回目の回答では、SWS_EcuM_04318ではEcuMは現在選択されているスリープモードに設定されたウェイクアップイベント情報のみを受け入れていると書かれています。回答4で、ComM関連のウェイクアップソースは特別なケースだとおっしゃいましたね。では、ComM関連のウェイクアップソースはSWS_EcuM_04318の制約を無視できるのでしょうか?それとも設計段階ですべてのComM関連ウェイクアップソースをスリープモードのウェイクアップイベント情報として設定しなければならないのでしょうか?

ウェイクアップソースを最初に有効にする必要がありますか?EcuMは、スリープフェーズ中に有効化するためにEcuM_EnableWakeupSourceを呼び出します。有効化後で初めてペンディング(EcuM_SetWakeupEventインターフェースのフィルタリングを成功裏に通過)できるのでしょうか?もしそうなら、回答4の「ComMチャネル関連ソース(例:CANのウェイクアップフレーム)はEcuM_SetWakeupEventでペンディング可能」という文言についてですが、このペンド操作はEcuMのスリープフェーズ中にのみ発生し、その後の検証はEcuMの任意のフェーズで行われるのでしょうか?それとも、他のドライバ自身が有効化ステップを行っているのか、それとも他にシナリオがあるのでしょうか?

ご回答をお待ちしております。
タグ(1)
評価なし
バージョン履歴
最終更新日:
4 週間前
更新者: