当分析一个复杂问题时,往往要求我们对多个模块的关联乃至整个系统的关联有非常清晰的了解,才能快速定位问题。在AUTOSAR系统的分层架构中,模块间的关联非常密切,本文介绍EcuM,CoM,CanNm模块等模块的关联,希望读者通过本文了解三个模块之间的协同工作机制,有助于工作中分析问题。
ComM的内外部唤醒
ComM可以通过NM(Network Manager)去保持Network的唤醒,同时也可以通过SM(State Manager)去激活通信,总而言之就像一个通信的总管。下面会通过两种唤醒源来解释ComM的状态机。
1. 内部唤醒
-
当ComM上电初始化时会首先进入到No Communication中,这个状态下会不断循环判断有没有本地的唤醒请求
-
如果检查到有本地通信请求API执行(本地请求可以由SWC,DCM或者BSWM发起),状态则将往Full Communication迁移(Allow通信通道,让CanSM打开通信)
-
进入Full Communication后由于是内部唤醒,会首先进入Network Requested,执行正常的报文收发,能一直主动去保持Network的唤醒状态
-
一旦本地COM Mode释放后,则进入Ready Sleep状态,NM PDUs停发
-
如果这时其他ECU也都不需要通信,等收到NM Prepare-Bus-Sleep的指示后Network进入Prepare Bus Sleep状态后,开始停止Tx IPDUs,进入Slien
本文深入探讨了AUTOSAR系统中EcuM, ComM和CanNm模块之间的关联,特别是ComM的内部和外部唤醒机制,以及它们如何影响状态迁移。在ComM的内部唤醒过程中,从No Communication到Full Communication的状态转变是由本地通信请求触发的;而外部唤醒时,ComM进入Ready Sleep状态,依赖外部信号维持Network唤醒。EcuM在状态管理中起到关键作用,只有在UP状态下才能维持ComM的Full Communication。状态关联图和CanNm的状态迁移图进一步帮助理解这些模块的工作协同。"
132704596,19687618,Java中的声明式事务管理,"['Java', '数据库', 'Spring框架', '事务管理']
订阅专栏 解锁全文
586

被折叠的 条评论
为什么被折叠?



