前言
在AUTOSAR中，Ecu的唤醒流程并不能简单的看作是对各个外设模块的供电动作。Autosar给了软件开发人员很大的自由度去设计目标项目Ecu的唤醒动作，而自由度越大的代价就是开发人员需要很好的设计Ecu的唤醒时序，提供Ecu唤醒过程的鲁棒性。
唤醒源的状态
在EcuM中规定了唤醒源的4中状态：NONE、PENDING、VALIDATED、EXPIRED。四种状态关系的切换关系如下所示：
当Ecu上电时，唤醒源的初始状态是NONE，当唤醒源状态切换到NONE时，需要通知到BswM模块，上图也可以看出，唤醒源的每次状态切换都需要通知到BswM模块，通知接口：BswM_EcuM_CurrentWakeup。
EcuM是如何知道有唤醒事件呢？EcuM如果想知道有唤醒Ecu的事件，最好的方式就是给底层提供一个接口或者注册一个回调，Autosar里规定了标准接口：EcuM_SetWakeupEvent。当有唤醒事件发生时，底层的硬件模块（例如：Transceiver、Sensor）最先识别到，之后通过该接口上报给EcuM。
EcuM主函数会轮询检测底层上报的唤醒事件，如果想进一步的分析唤醒事件是不是有效的总线唤醒源（网络管理报文），需要Ecu有正常的收发报文能力，想要收发报文，Transceiver和Controller两个模块均需要启动。一般来讲，Transceiver会在程序初始化时进入正常的工作模式，而Controller进入正常的工作模式是EcuM调用EcuM_StartWakeupSources的结果，而该接口的内部功能的实现由开发者自行把控，autosar并未做硬性的要求。
启动Transceiver和Controller，建立了报文的正常收发能力，Ecu即可进一步的将报文上报上层模块，如：CanIf，即此时Ecu可以拿到总线的RawData，不管是不是网络管理报文，Ecu都可以做进一步的功能实现，如收到诊断报文唤醒网络等。
一般来说，会在EcuM模块配置两个时间参数，CheckWakeup和ValidateWakeup时间，如果CheckWakeup时间走完走完没有判断到有效的唤醒源，则调用EcuM_StopWakeupSources关闭唤醒源，这里多数关闭controller，进而Ecu失去通信能力。
ValidateWakeup时间参数配置与否决定了是否使用唤醒事件的验证功能，如果配置该参数，且验证唤醒事件有效后则通知ComM使能通信，调用ComM接口：ComM_EcuM_WakeupIndication。如果该参数没有配置，则EcuM不在绕圈，直接通知BswM唤醒事件有效，通知ComM开启通信。个人理解：该参数配置较合理。
第一：可以验证唤醒事件的有效性，避免因总线抖动等干扰造成的非预期Ecu唤醒；
第二：如果使用的Transceiver没有Pn功能，Ecu会因总线的扰动而不断的唤醒，假设总线有应用报文没有网络管理报文，ValidateWakeup时间给0，Ecu将会不断的走上下电流程，如果下电选择OFF流程(实际项目中很多开发人员没有开启Reset流程的Operation,即直接冷启动，这不符合autosar规范，也不安全)，将会带来未知问题（如果Ecu内核有一定时间内唤醒次数限制，超过阈值则可能上锁保护），设置该参数可以有效的延迟Ecu唤醒频率。
审核编辑：刘清