CN105083168B - 控制器唤醒特征的控制和诊断 - Google Patents

Abstract

本发明公开了控制器唤醒特征的控制和诊断。本文提出了一种用于车辆的电子模块的控制和诊断方法。根据所公开的方法，所述电子模块的处理器的至少一个唤醒事件在所述车辆的非活动停车状态期间执行。所述至少一个唤醒事件由所述电子模块的唤醒计时器发起。所述方法接下来在所述车辆的非活动停车状态期间将与所述至少一个唤醒事件相关联的唤醒信息记入日志以获得计入日志的唤醒信息。在所述车辆的活动操作状态期间分析所述计入日志的唤醒信息以获得唤醒诊断，以及所述方法在所述车辆的所述活动操作状态期间生成指示所述唤醒诊断的输出。

Description

控制器唤醒特征的控制和诊断

技术领域

本文所描述的主题的实施例一般涉及在车辆中使用的类型的电子控制和诊断系统。更具体地说，主题的实施例涉及车载电子控制单元的唤醒特征的控制和诊断。

背景技术

现代车辆包括许多实现各种操作的电子和基于处理器的子系统。现有技术包括可以用于执行各种控制方案、诊断例程以及关于车辆的操作的其他过程的电子控制单元（ECU）。诸如汽车的车辆可以包括被编程执行对其他车载子系统的诊断检查的ECU。在车辆处于活动操作状态时，一些诊断检查可以执行，而其他诊断检查可以在非活动周期期间，例如在停车时执行。就此，嵌入式控制器可以设计为（经由车载计时器）唤醒它们以在停车周期期间监测某些车辆系统。

因此，需要有以准确和节能方式诊断控制器唤醒特征的操作的技术和方法。此外，其他所需特征和特性将通过结合附图和上述技术领域和背景技术所作的随后的具体实施方式和所附权利要求书而变得显而易见。

发明内容

提供了车辆的电子模块的控制和诊断方法的示例性实施例。在所述车辆的非活动停车状态期间，所述方法针对所述电子模块的处理器执行至少一个唤醒事件，其中，所述至少一个唤醒事件由所述电子模块的唤醒计时器发起。所述方法接下来在所述车辆的非活动停车状态期间，将与所述至少一个唤醒事件相关联的唤醒信息记入日志。在所述车辆的活动操作状态期间分析计入日志的唤醒信息以获得唤醒诊断。所述方法接下来在所述车辆的所述活动操作状态期间生成指示所述唤醒诊断的输出。

还提供了用于车辆的电子控制模块的示例性实施例。所述电子控制模块包括：处理器；唤醒计时器，所述唤醒计时器操作性地与所述处理器相关联；以及非易失性存储器元件，所述非易失性存储器元件配置为存储与由所述处理器管理的唤醒请求相关联的唤醒请求信息。所述处理器、所述唤醒计时器和所述非易失性存储器元件协作以在所述车辆的非活动停车状态期间，针对所述处理器执行至少一个唤醒事件，所述至少一个唤醒事件由所述唤醒计时器发起。在所述车辆的所述非活动停车状态期间，维持唤醒历史阵列（historyarray）；所述阵列包括与所述至少一个唤醒事件相关联的至少一个条目（entry）。在所述车辆的活动操作状态期间分析唤醒历史阵列以获得唤醒诊断。在所述车辆的所述活动操作期间，生成输出；所述输出指示所述唤醒诊断。

还提供了车辆的电子模块的控制和诊断方法的示例性实施例。所述电子模块包括处理器和唤醒计时器。所述方法在所述车辆的非活动停车状态期间操作所述唤醒计时器以针对所述处理器发起唤醒事件。所述方法接下来在所述唤醒事件期间操作所述处理器以执行车辆诊断，管理唤醒请求以及将与所述唤醒事件相关联的唤醒信息记入日志。所述方法在所述车辆的非活动停车状态之后的所述车辆的活动操作状态期间，基于计入日志的唤醒信息执行唤醒诊断。所述方法接下来在所述车辆的所述活动操作期间生成所述唤醒诊断的结果。

本发明还公开了以下技术方案。

1、一种用于车辆的电子模块的控制和诊断方法，所述方法包括：

在所述车辆的非活动停车状态期间，针对所述电子模块的处理器执行至少一个唤醒事件，所述至少一个唤醒事件由所述电子模块的唤醒计时器发起；

在所述车辆的所述非活动停车状态期间，将与所述至少一个唤醒事件相关联的唤醒信息记入日志以获得计入日志的唤醒信息；

在所述车辆的活动操作状态期间分析所述计入日志的唤醒信息以获得唤醒诊断；以及

在所述车辆的所述活动操作状态期间生成指示所述唤醒诊断的输出。

2、根据方案1所述的方法，其中：

所述车辆的所述非活动停车状态对应于熄火状态；以及

所述车辆的所述活动操作状态对应于点火状态。

3、根据方案1所述的方法，其中，所述记入日志包括：

针对每一个已执行的唤醒事件，将请求唤醒时间和对应于所述请求唤醒时间的实际唤醒时间记入日志，所述实际唤醒时间从所述唤醒计时器获得。

4、根据方案1所述的方法，其中，分析所述计入日志的唤醒信息包括：

确定在所述车辆的所述非活动停车状态期间是否发生了意外唤醒事件。

5、根据方案1所述的方法，其中，分析所述计入日志的唤醒信息包括：

确定在所述车辆的所述非活动停车状态期间是否错过了请求唤醒时间。

6、根据方案1所述的方法，其中，生成所述输出包括：

当所述分析导致合格唤醒诊断时，生成第一诊断代码；以及

当所述分析导致不合格唤醒诊断时，生成第二诊断代码。

7、一种用于车辆的电子控制模块，其包括：

处理器；

唤醒计时器，所述唤醒计时器操作性地与所述处理器相关联；以及

非易失性存储器元件，所述非易失性存储器元件配置为存储与由所述处理器管理的唤醒请求相关联的唤醒请求信息，其中，所述处理器、所述唤醒计时器和所述非易失性存储器元件协作，以便：

在所述车辆的非活动停车状态期间，针对所述处理器执行至少一个唤醒事件，所述至少一个唤醒事件由所述唤醒计时器发起；

在所述车辆的所述非活动停车状态期间维持唤醒历史阵列，所述唤醒历史阵列包括与所述至少一个唤醒事件相关联的至少一个条目；

在所述车辆的活动操作状态期间分析所述唤醒历史阵列，以获得唤醒诊断；以及

在所述车辆的所述活动操作期间生成指示所述唤醒诊断的输出。

8、根据方案7所述的电子控制模块，其中：

所述唤醒历史阵列的每一个条目均包括请求唤醒时间和对应于所述请求唤醒时间的实际唤醒时间；以及

所述实际唤醒时间从所述唤醒计时器获得。

9、根据方案7所述的电子控制模块，其中，分析所述唤醒历史阵列包括：

确定在所述车辆的所述非活动停车状态期间是否发生了意外唤醒事件。

10、根据方案7所述的电子控制模块，其中，分析所述唤醒历史阵列包括：

确定在所述车辆的所述非活动停车状态期间是否错过了请求唤醒时间。

11、一种用于车辆的电子模块的控制和诊断方法，所述电子模块包括处理器和唤醒计时器，所述方法包括：

在所述车辆的非活动停车状态期间操作所述唤醒计时器，以针对所述处理器发起唤醒事件；

在所述唤醒事件期间操作所述处理器，以执行车辆诊断，管理唤醒请求以及将与所述唤醒事件相关联的唤醒信息记入日志；

在所述车辆的所述非活动停车状态之后的所述车辆的活动操作状态期间，基于计入日志的唤醒信息执行唤醒诊断；以及

在所述车辆的所述活动操作期间生成所述唤醒诊断的结果。

12、根据方案11所述的方法，其中：

所述车辆的所述非活动停车状态对应于发动机关闭状态；以及

所述车辆的所述活动操作状态对应于发动机启动状态。

13、根据方案11所述的方法，其中，执行唤醒诊断包括：

确定在所述车辆的所述非活动停车状态期间是否发生了意外唤醒事件。

14、根据方案11所述的方法，其中，执行唤醒诊断包括：

确定在所述车辆的所述非活动停车状态期间是否错过了请求唤醒时间。

15、根据方案11所述的方法，其中，执行唤醒诊断包括：

确定是否成功执行了至少一个请求唤醒时间；

确定在所述车辆的所述非活动停车状态期间是否错过了请求唤醒时间；

当确定在所述车辆的所述非活动停车状态期间错过了请求唤醒时间时，报告“不合格”输出；以及

当确定成功执行了至少一个请求唤醒时间并且在所述车辆的所述非活动停车状态期间未错过请求唤醒时间时，报告“合格”输出。

16、根据方案11所述的方法，进一步包括：

接收指示针对所述处理器的请求唤醒时间的唤醒请求；

基于所述请求唤醒时间和所述唤醒计时器的运行时间值确定针对所述唤醒计时器的下一个唤醒时间设置；以及

利用所述下一个唤醒时间设置配置所述唤醒计时器。

17、根据方案16所述的方法，其中，确定所述下一个唤醒时间设置包括：

当所述请求唤醒时间小于阈值时间时，使用针对所述下一个唤醒时间设置的最小时间。

18、根据方案17所述的方法，其中，所述阈值时间等于所述最小时间。

19、根据方案16所述的方法，其中，确定所述下一个唤醒时间设置包括：

当所述请求唤醒时间大于阈值时间时，使用针对所述下一个唤醒时间设置的最大时间。

20、根据方案19所述的方法，其中，所述最大时间对应于所述唤醒计时器的最大计时器值。

提供本发明内容以简单介绍在以下具体实施方式中将进一步描述的构思的选择。本发明内容不旨在识别所要求的主题的关键特征或基本特征，亦不旨在帮助确定所要求的主题的范围。

附图说明

当结合以下附图考虑时，对主题的更全面的理解可以通过参照具体实施方式和权利要求书而得出，其中，在整个附图中，相同的附图标记表示相似的元件。

图1是利用电子控制单元（ECU）的车辆的简化示意图；

图2是ECU的示例性实施例的框图；

图3是图示了唤醒控制和诊断操作的示例性实施例的框图；

图4是唤醒计时器设定过程的示例性实施例的流程图；

图5是唤醒记入日志过程的示例性实施例的流程图；

图6是用于检测意外唤醒事件的过程的示例性实施例的流程图；以及

图7是用于检测错过唤醒的过程的示例性实施例的流程图。

具体实施方式

以下具体实施方式本质上仅为图示性的并且不旨在限制主题的实施例或者这类实施例的应用和使用。如本文所使用的，词“示例性”意味着“用作示例、例子或者图示”。在本文中描述的任何实施方案均不必理解为比其他实施方案优选或有利。此外，本发明无意于受在前述技术领域、背景技术、发明内容或以下的具体实施方式中提出的任何明示或暗示的理论的限制。

技艺和技术在本文中可以依据功能和/或逻辑块部件，以及参照可以通过各种计算部件或者设备执行的操作、处理任务以及功能的符号表示进行描述。这类操作、任务和功能有时被称为被计算机执行、计算机化、软件实施或者计算机实施。应该了解，附图所示的各种快部件可以由配置为执行具体功能的任何数量的硬件、软件和/或固件部件实现。例如，系统或部件的实施例可以采用可以在一个或多个微处理器或其他控制设备的控制下实行多种功能的各种集成电路部件，例如，存储器元件、数字信号处理元件、逻辑元件、查询表等。

当在软件或者固件中实施时，本文所描述的系统的各种元件基本上为执行各种任务的代码段或者指令。程序或者代码段可以存储在处理器可读介质（例如，非暂时性介质）中，从而使当指令执行时，存储的指令能够执行所描述的功能。处理器可读介质的示例包括：电子电路、半导体存储器设备、ROM、闪速存储器、可擦ROM（EROM）、软盘、CD-ROM、光盘、硬盘等。

图1是包括至少一个车载电子控制单元（ECU）102的车辆100的简化示意图。虽然车辆100描绘为具有三个ECU102，但可以部署任何数量以适应特殊实施例的需要。在某些实施例中，ECU 102可以适当地配置为用作车身控制模块、发动机控制模块、动力系统控制模块等。以下说明涉及与发动机控制模块相关联的某些控制和诊断操作。然而，实际上，本文所描述的控制和诊断操作能够由车辆100的任何车载ECU执行。

图2是ECU 200的示例性实施例的框图。在图1中示出的每一个ECU 102可以根据图2所示进行配置。ECU 200的图示的实施例一般包括但不限于：处理器202；唤醒计时器204；存储器206；一个或多个输入/输出接口208；一个或多个通信模块210；以及电源212。ECU200的元件可以经由任何适当的调节信号和数据通信的互连架构214联接在一起。

处理器202可以视特殊实施例的情况以各种不同的方式实施或者执行。例如，处理器202可以使用通用微处理器、内容可寻址存储器、数字信号处理器、专用集成电路、现场可编程门阵列、任何适当的可编程逻辑设备、分立栅极或者晶体管逻辑、分立硬件部件或者设计为执行本文所描述的功能的任何组合。另外，处理器202也可以实施为计算设备的组合，例如，数字信号处理器和微处理器的组合、多个微处理器、结合数字信号处理器内核的一个或多个微处理器、或任何其他这类配置。针对该特殊示例，处理器202实现为电子设备包或者集成电路芯片，集成电路芯片可以通过移除其操作电压而被放置到非活动、休眠或者断电状态中。再次维持操作电压使处理器202转换回到其活动的、唤醒以及通电状态。

处理器202代表ECU 200的主要逻辑和处理部件。因此，处理器202适当地配置为执行支持主车辆的操作可能所需的各种特征、功能和过程。例如，如果ECU 200部署为车辆的发动机控制模块，则处理器202可以对于与各种发动机、点火和燃料系统相关联的电子控制和诊断操作负责。当唤醒时，处理器202可以对一个或多个其他车辆子系统执行诊断检查，不论车辆的发动机打开还是关闭。例如，处理器202可以设计为在停车时检查电池子系统或者燃料子系统的状态。如下面更详细地描述的，唤醒计时器204根据需要唤醒处理器202，从而使处理器202可以在关闭其自身（回到休眠模式）时执行这类诊断检查。

唤醒计时器204可以实现为：操作性地与处理器202相关联的单独部件或者集成电路芯片。在某些实施例中，在车辆处于发动机关闭状态时，唤醒计时器204实现为：追踪运行计数的硬件计时器。另外，唤醒计时器204可以被编程或者以其他方式设置为追踪处理器202的唤醒次数。为此，唤醒计时器204可以被视为保持操作的“永远开启”部件，而不论车辆处于发动机打开还是发动机关闭状态，也不论处理器202处于通电还是断电状态。如下面更详细地描述的，如果编程有唤醒时间设置，则唤醒计时器204在编程时间发起唤醒事件以唤醒处理器202。在某些实施例中，唤醒事件通过将操作功率（电压）应用于处理器202而发起，从而使处理器202可以执行所需的任务和过程。

存储器206可以使用任何数量的部件以及使用任何类型的存储器技术实现（视特殊实施例的情况）。由此，存储器206可以包括但不限于： RAM存储器、闪速存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动磁盘、CD-ROM或者本领域已知的任何其他形式的存储介质。就此，存储器206可以联接至处理器202，从而使处理器202可以从存储器206读取信息以及将信息写入存储器206。在替代实施方式中，一些存储器206可以整合到处理器202。作为示例，处理器202和存储器206可以常驻在ASIC中。

针对ECU 200的该实施例，存储器206包括非易失性存储器元件，非易失性存储器元件用于存储与由处理器202管理的唤醒请求相关联的唤醒请求信息。非易失性存储器元件在无操作功率/电压的情况下保持其存储的数据，从而使唤醒请求信息被保存，而不管处理器202的操作状态（通电或者断电）如何。如下面更详细地阐释地，存储的唤醒请求信息用于填入用作唤醒事件的日志的唤醒历史阵列。

输入/输出接口208可以用于操作电压、传感器信号等。同样地，通信模块210可以用于数据通信、网络化等。实际上，输入/输出接口208和通信模块210可以与其他车载ECU协作和/或与其他车载子系统通信。

电源212可以包括：稳压器、功率调节部件和/或向ECU 200的设备和电子部件提供一个或多个操作电压的其他元件。例如，电源212为处理器202和唤醒计时器204提供操作电压。唤醒计时器204可以根据需要适当地配置为控制到电源212的访问，以对处理器202进行通电和断电（即，以下面更详细地描述的方式唤醒和关闭处理器202）。

本文所提出的主题涉及用于嵌入式控制器的唤醒特征的控制和诊断的方法，诸如ECU 200的处理器202。唤醒特征可以用于发起车载诊断检查。因此，监测唤醒计时器以确保处理器202按预期唤醒。本文所描述的系统对来自众多请求程序的所需唤醒时间进行裁定，并且对发生以确保它们正确发生的唤醒事件进行监测。本文所描述的方法收集来自其他子系统的唤醒请求，并且在控制器完全关闭之前设置下一个唤醒时间。诊断法运行以监测每一个唤醒事件的正确性；诊断法可以在下一个车辆通电状态发起。另外，可以通过独立的诊断检查监测唤醒计时器本身的准确度。唤醒诊断特征允许控制器在事件的持续期间不保持通电的情况下监测长期事件，这将导致过度电池耗竭。显而易见地，该特征是独立的，因此，它消除了使一个模块唤醒另一模块的模块间通信的复杂性。

本文所描述的方法从车载子系统、ECU和/或处理任务收集唤醒请求，并且在控制器关闭程序期间处理请求以为控制器设置下一个唤醒时间。在控制器关闭程序期间，给予最近（时间上）请求的唤醒时间以优先权，而其他唤醒请求在事件中排队，最高优先权唤醒请求在关闭发生之前取消。在控制器醒着时，分析计时器信息以确定是否已经经过了程序化的唤醒时间。如果经过，则下一个请求唤醒时间将变成当前请求唤醒时间。如果请求唤醒时间在预定的、短期时间（例如，10秒）内，则将不允许控制器关闭直到在唤醒请求已经被服务之后。这确保由于唤醒时间导致的在关闭与唤醒之间的竞争条件不发生。如果请求唤醒时间超出唤醒计时器的硬件能力，则将设置硬件可以管理的最长的可能的唤醒时间，从而使请求更长唤醒时间的过程可以运行并且请求包括最初请求时间的剩余部分的新的唤醒时间。这使控制器能够在正确时间唤醒，但是它将经历一个或多个介入唤醒以复位唤醒计时器。

每次控制器由于唤醒计时器唤醒，所要求的唤醒计时器值、实际唤醒计时器值及其错误状态的日志均被记录到非易失性存储器中。当控制器由于外部事件（例如，打开点火设备，或者当另一模块唤醒控制器时）唤醒时，日志条目被解析。检查每一个条目以确定实际唤醒时间是否在所请求的唤醒时间的指定窗口内。如果不在，则设置指示“意外唤醒”发生的诊断故障码。另外，在外部唤醒事件时，诊断检查以确定唤醒时间是否被请求，唤醒时间是否经过，以及唤醒事件是否未记入唤醒历史日志。如果满足该标准，则设置指示“未检测到唤醒”的诊断故障码。如果所有的记入日志的唤醒均在规定窗口内，则对于“意外唤醒”代码记录“合格”。如果不存在未服务的唤醒事件并且计时器唤醒正确服务（如由意外唤醒诊断确定的那样），则对于“未检测到唤醒”代码记录“合格”。

图3是图示了可以由主车辆的ECU 300执行的唤醒控制和诊断操作的示例性实施例的框图。作为一个非限制性示例，图3可以与汽车的发动机控制模块的操作相关联。图3描绘的块可以实现为硬件设备或者部件、逻辑处理模块、软件实施过程等。图3为了便于说明和清晰示出了单独的块。

ECU 300的图示的实施例可以包括但不限于：唤醒请求管理器302；唤醒计时器304；非易失性存储器306；唤醒记入日志模块308；计时器诊断模块310；以及唤醒诊断模块312。这些元件和模块根据需要协作以支持下面参照图4-7更详细地描述的各种任务、方法和过程。

唤醒请求管理器302代表当ECU 300的控制器处于活动通电状态下时执行或者启用的逻辑处理模块。就此，唤醒请求管理器302可以被视为控制器的功能模块。唤醒请求管理器302适当地配置为接收由ECU、软件任务、例行程序和/或主车辆的车载子系统所发出的唤醒请求320，并且根据需要处理接收到的唤醒请求320。唤醒请求指示请求例程、过程、任务或者部件（即“请求程序”）想让ECU 300的控制器因为某种原因在指定时间（或者次数）唤醒。作为一个非限制性示例，为了在车辆关闭之后在指定时间测试电池状态，车辆的电气子系统可以发出唤醒控制器的唤醒请求。为此，可能需要在发动机关闭之后一小时、二小时、四小时以及八小时测试电池状态。作为另一非限制性示例，为了测试燃料箱状态，车辆的燃料子系统可以发出另一唤醒控制器的唤醒请求。就此，可能需要在发动机关闭之后五小时、七小时以九小时检查燃料箱状态；唤醒请求可以在这些时间用于启动ECU 300的控制器。

如下面更详细地描述的，唤醒请求管理器302在ECU 300的控制器关闭（断电）之前立即执行某些任务和过程。例如，唤醒请求管理器302对每一个接收到的唤醒请求320打上时间戳记，确定哪个唤醒请求320考虑为优先请求，以及基于所选的唤醒请求320和与唤醒计时器304相关联的附加请求设置下一个请求的唤醒时间。当设置下一个唤醒时间时，唤醒请求管理器302还可以考虑未服务的唤醒请求。在确定下一个唤醒时间将是什么之后，唤醒请求管理器302与唤醒计时器304以适当方式协作以利用下一个唤醒时间设置配置唤醒计时器304。唤醒请求管理器302还将唤醒请求信息保存在非易失性存储器306中。这使ECU300能够在控制器断电之后保留与唤醒请求相关联的数据。在某些实施例中，非易失性存储器306至少存储以下信息，但不限于：在唤醒计时器304中编程的唤醒计时器值；唤醒计时器304的当前运行时间值；以及与唤醒请求源于的请求程序相关联的标识符（例如，地址、部件名或者代码）。

如上所提及的，唤醒计时器304可以实施为与控制器硬件相关的不同的单独的硬件设备。唤醒计时器304维持运行时间计数，运行时间计数可以由运行时间值、运行时钟值等表示。在某些实施例中，每当车辆状态不处于“运行”或者“开动”模式时，运行值复位，并且它不管控制器的状态（通电或者断电）而保持活动。实际上，编程到唤醒计时器304中的唤醒时间基于运行时间值。因此，当前设置的唤醒时间引用运行时间值的计数状态。由此，当唤醒计时器304到达设置的唤醒时间时，其发起唤醒程序，在唤醒程序中，操作功率/电压被应用于控制器硬件，控制器硬件转而使控制器转换至其通电状态。

唤醒记入日志模块308可以实施为：当唤醒计时器304启动ECU 300的控制器时执行或者启用的逻辑处理模块。就此，唤醒记入日志模块308可以被视为控制器的功能模块。图3的虚线322示意性地指示了唤醒记入日志模块308响应到达设置的唤醒时间的唤醒计时器304。在这个背景下，唤醒计时器304可以用作唤醒记入日志模块308的启动触发器。当活动时，唤醒记入日志模块308获得存储在非易失性存储器306中最近的唤醒请求信息，并且将包括所获信息的新条目填入唤醒历史数据阵列。唤醒记入日志模块308还将实际唤醒计时器值添加至新条目以当控制器实际唤醒时保持追踪。在某些实施例中，唤醒记入日志模块308与计时器诊断模块310通信以获得关于唤醒计时器304的操作状态的诊断信息。因此，在唤醒历史阵列中的每一个条目至少包括以下信息，但不限于：设置的唤醒请求；对应的编程唤醒时间设置；对应的从唤醒计时器304获得的实际唤醒时间；以及在条目制定时指示唤醒计时器304有效还是无效的诊断计时器信息。

在车辆保持在非活动状态时（即，直到车辆再次发动），唤醒记入日志模块308维持唤醒历史阵列。这使每当唤醒计时器304在车辆的非活动状态期间唤醒控制器时，唤醒记入日志模块308能够更新唤醒历史阵列。由此，每当控制器响应于设置的唤醒时间唤醒时，唤醒记入日志模块均向历史阵列增添新的条目。

如上面所简要提及的，计时器诊断模块310生成并且提供指示唤醒计时器304是否在有效准确的状态下操作的诊断计时器信息。就此，计时器诊断模块310可以实施为：当ECU300的控制器醒着时执行或者启用的逻辑处理模块。在某些实施例中，计时器诊断模块310单独地检查唤醒计时器304的操作和有效性并且生成指示唤醒计时器304有效还是无效的标记或者输出。

唤醒诊断模块312可以实施为：当车辆的通电状态唤醒ECU 300的控制器时执行或者启用的逻辑处理模块。图3的虚线324表示车辆通电条件，车辆通电条件转而启动唤醒诊断模块312。唤醒诊断模块312分析在紧接车辆的断电状态之前的期间维持的唤醒历史阵列。唤醒诊断模块312回顾记入日志唤醒历史数据以确定请求的唤醒时间是否（合理地）对应于实际的唤醒时间，并且检查控制器实际上是否如期唤醒。唤醒诊断模块312还检查控制器自身是否意外唤醒，即，在无对应的唤醒请求的情况下。唤醒诊断模块312还可以检查唤醒计时器是否还具有尚未服务的编程唤醒时间。如果是，则唤醒诊断模块312确定设置的唤醒时间是否已经经过（即，最后安排的唤醒时间是否错误地跳过）。

唤醒诊断模块312适当地配置为生成指示唤醒特征的有效性的诊断故障码326。在某些实施例中，如果唤醒历史数据确定为有效，则唤醒诊断模块312生成“合格”；如果唤醒历史数据指示问题，则生成“不合格”。由此，每当车辆发动（即，发动机启动）并且还存在之前的计时器唤醒时，就生成“合格”或者“不合格”，其中，代码基于在紧接车辆的非活动状态之前的期间收集的唤醒历史数据指示控制器唤醒特征的有效性。

图4是图示了唤醒计时器设置过程400的示例性实施例的流程图，唤醒计时器设置过程400可以与唤醒请求管理器302的操作相关联。关于本文所描述的过程执行的各种任务可以由软件、硬件、固件或者其任何组合执行。为了图示，过程的说明指上面关于图1-3提及的元件。实际上，所描述的过程的部分可以由所描述的系统的不同元件执行，例如，唤醒请求管理器302、唤醒计时器304、唤醒记入日志模块308或者唤醒诊断模块312。应了解，所描述的过程可以包括任何数量的附加或者替代任务，在附图中示出的任务不需按图示顺序执行，以及所描述的过程可以并入具有本文未详细描述的附加功能的更全面的程序或者过程。另外，只要预期的全部功能性保持完整，则在附图中示出的一个或多个任务可以从所图示的过程的实施例省略。

如上所提及的，唤醒请求管理器302处理唤醒请求并且利用下一个唤醒时间对唤醒计时器304进行编程。因此，过程400可以在ECU的控制器的关闭程序期间执行。就此，在控制器保持活动时，过程400完成。过程400的图示的实施例检查是否已经接收到至少一个唤醒请求（查询任务402）。如果未接收（查询任务402的“否”分支），则过程400将下一个唤醒时间设置为等于零或者任何指定“禁用”值以指示唤醒时间将不被编程（任务404）。过程400还将“唤醒设置”变量设置为“假”（任务406）并且将“唤醒ID”变量设置为空值（任务408）。“空ID”值可以为解释为意味着请求程序尚未发起任何唤醒请求的任何值。在设置这两个值之后，过程400进行到下面更详细地描述的任务418。

如果已经接收到一个或多个唤醒请求（查询任务402的“是”分支），则过程400通过检索唤醒计时器的当前运行时间值而继续（任务410）。如之前所阐释的，运行时间值指示自从车辆关闭后经过了多长时间，不论控制器实际上何时断电。由此，在车辆关闭与控制器断电之间可能存在时间偏移。例如，如果停车，而立体声在完全断电之前运行二十分钟，则唤醒计时器的当前运行时间值将指示约二十分钟的运行时间。作为另一示例，如果发动机和其他系统约同时完全关闭，则唤醒计时器的当前运行时间将指示接近，诸如零的初始值的运行时间。

接着，过程400计算或者以其他方式确定为唤醒计时器编程的下一个唤醒时间设置（任务412）。如下面更详细地描述的，下一个唤醒时间基于当前运行时间值、由接收到的唤醒请求指示的请求的唤醒时间以及关于唤醒计时器硬件的实际限制的其他因素确定。过程400还将“唤醒设置”变量设置为“真”（任务414）并且将“唤醒ID”变量设置为识别请求程序的值（任务416）。在某些实施方式中，设置变量“唤醒ID”以指示地址、用户名或者分配给请求程序的代码。

过程400通过利用下一个唤醒时间配置唤醒计时器而继续（任务418）。另外，过程400将相关的唤醒请求信息存储在非易失性存储器中（任务420）。如上面所提及的，所存储的信息可以用于结合唤醒诊断模块的操作。在过程400完成时，控制器可以断电并且休眠。

再次参照任务412，当确定下一个唤醒时间将是什么时，过程400可以考虑各种因素。如果仅存在一个待考虑的唤醒请求，则过程400继续处理下面所描述的请求。然而，如果存在多个待考虑的唤醒请求（例如，新请求、未服务的请求、待定请求等），则过程400选择具有最短唤醒时间的请求。这确保控制器将唤醒以服务下一个唤醒请求。因此，如果过程400在两小时内接收第一唤醒请求并且在五小时内接收第二唤醒请求，则将选择第一请求用于进一步处理。另外，过程400可以使用第二请求的时间戳来保持追踪唤醒时间的“剩余”量，从而使最初请求的唤醒（五小时）仍被服务。由此，当控制器醒着时，除了处理任何最近接收的唤醒请求之外，它可能需要更新与任何未服务或者待定的请求相关联的唤醒时间。

在某些实施例中，在控制器转换为非活动状态时或者在紧接控制器关闭之后，比较与所选唤醒请求相关联的唤醒时间和阈值时间，阈值时间旨在防止竞争条件，其中，请求唤醒时间被编程在控制器仍醒着的时候发生。这类竞争条件可能导致错过唤醒时间。为了处理这些情况，每当请求唤醒时间小于最小时间周期时，最小时间周期用于设置唤醒计时器。阈值时间周期长到足以防止上面所提及的定时冲突类型。在某些实施例中，最小时间周期可以为：10秒、30秒、60秒等。应了解，阈值时间段可以改变以适应特殊实施例和预期应用的需要。

如果由所选唤醒请求限定的唤醒时间大于或者等于阈值时间段，则过程400保持限定唤醒时间并且按以下所描述的方式继续。如果由所选唤醒请求限定的唤醒时间小于阈值时间段，则过程400使用下一个唤醒时间设置的最小时间并且如下面所描述的那样继续进行。在某些实施例中，阈值时间等于最小时间。在其他实施例中，不同的时间值可以用作阈值时间和最小时间。

过程400还可以检查与唤醒计时器硬件的计数容量相关联的对于最大时间的请求唤醒时间。例如，唤醒计时器可以设计为计数至最大计时器值（例如，72小时）。由此，如果唤醒请求需要在80小时之后的唤醒时间，则唤醒计时器将不能直接适应请求。因此，如果由所选唤醒请求限定的唤醒时间大于或者等于阈值时间，则过程400使用最大计时器值而不是请求唤醒时间。如果由所选唤醒请求限定的唤醒时间小于阈值时间，则过程400保持限定唤醒时间并且按需要对唤醒计时器进行编程。在某些实施例中，最大阈值时间等于唤醒计时器的最大计时器值。在其他实施例中，最大时间值可以不同于唤醒计时器的最大计时器值。

如上面所阐释的，当车辆的发动机/点火装置关闭时，唤醒计时器可以开始计数。然而，在替代实施例中，唤醒计时器控制机构可以灵活配置，从而使其可以在发动机/点火装置关闭之后开始计数。应了解，如果需要这样，则下面所描述的方法可以按需要修改供不同唤醒定时方案使用。假设（针对该特殊示例）当发动机/点火装置关闭时唤醒时间开始，则控制器不必与发动机或者点火装置同时关闭。相反，控制器可以在发动机关闭之后在不定量的时间内保持活动。例如，驾驶员可以使用车载远程通信系统、使用信息通讯系统、使用导航系统等保持收听已停放的车辆的广播。因此，过程400可以对相关的考虑已经在发动机关闭与控制器断电程序之间记录的任何经过的时间的唤醒时间进行分析和编程。例如，假设唤醒请求在发动机关闭之后指定60分钟的唤醒时间，以及控制器在发动机关闭之后保持10分钟活动。如果请求唤醒时间不受任何其他调整，则唤醒计时器将被编程为在50分钟内唤醒。不管控制器实际上何时断电，该定时偏移形式确保唤醒请求按预期方式服务。

图5是图示了唤醒记入日志过程500的示例性实施例的流程图。过程500在控制器处于活动状态时，以及在ECU已经在车辆的之前的非活动关闭状态期间执行至少一个唤醒事件之后执行。在某些实施例中，过程500在控制器初始化期间执行，控制器初始化在控制器唤醒之后发生。因此，过程500的迭代针对每一个唤醒事件执行。

过程500可以通过检查当前的唤醒事件是否由唤醒计时器发起而开始（查询任务502）。针对该示例，查询任务502检查指示导致处理器被执行的复位源的处理器的状态寄存器。计时器唤醒通过这些寄存器识别并且独立于唤醒实际上是否被请求。如果当前唤醒事件不由唤醒计时器发起，则过程500检查当前唤醒事件是否对应于通电复位（查询任务504）。就此，当点火设备打开，当发动机发动，当串行数据消息到达等时，通电复位发生。另外，一些车辆当车门打开时执行通电复位。如果通电复位已经发生（查询任务504的“是”分支），则过程500执行唤醒诊断（任务506）以检查基于时间的唤醒特征的性能。下面参照图6和图7更详细地描述示例性唤醒诊断。

如果查询任务504确定通电复位尚未发生，则最后请求的唤醒时间被清除（任务508）并且过程500结束。该情境对应于“运行复位”条件，如果在存储器中检测到错误，或者如果在微处理器中发生非法中断，或者如果软件由于某种原因损坏，则“运行复位”条件可以发生。在这种情况下，控制器未适当操作，以及唤醒计时器不能被诊断。由此，在不对唤醒计时器执行诊断的情况下，唤醒时间被清除并且过程500结束。

查询任务502的“是”分支指示唤醒事件由唤醒计时器导致。因此，过程500确定唤醒计时器是否为记入唤醒历史阵列日志的第一事件（查询任务510）。如果是，则唤醒历史阵列被清除（任务512）以为具有新条目的群体做好准备。如果不是（查询任务510的“否”分支），则唤醒历史阵列转移或者以其他方式操纵以适应对应于当前唤醒事件的新条目（任务514）。另外，过程500增加代表控制器在车辆的最后非活动周期期间受基于计时器的唤醒的次数的计数（任务516）。针对该示例，计数每基于计时器的唤醒事件增加一次。作为替代实施方式，如果需要这样，计数可以根据任何预定方案调整。

过程500可以读取或者以其他方式获得指示唤醒计时器的有效性和无效性的计时器诊断结果（任务518）。如上面参照计时器诊断模块310（见图3）所提及的，ECU可以使用独立过程检查唤醒计时器的有效性。本文所描述的任务518获得计时器诊断模块310的输出。在某些实施例中，计时器诊断模块310的输出可以为代码、标记或者指示唤醒计时器是有效（准确）还是无效（不准确或者处于错误状态）的任何适当的格式化数据。过程500还读取或者以其他方式获得实际的唤醒计时器值，实际的唤醒计时器值表示唤醒计时器的当前运行时间值（任务520）。

过程500可以通过在最后的控制器关闭期间检查唤醒时间是否设置而继续（查询任务522）。如果是，则所请求的（设置的）唤醒时间存储在唤醒历史阵列的新条目中（任务524）。附加信息可以被写入新条目，包括但不限于： 在任务520处从唤醒计时器获得的实际唤醒时间；在任务518处读取的计时器诊断结构；以及识别唤醒请求的请求程序的“唤醒ID”变量的值（任务526）。如果唤醒时间不在最后控制器关闭（查询任务522的“否”：分支）期间设置，则任务524跳过以及新条目将不包括设置的唤醒时间。查询任务522的“否”分支指示在唤醒计时器硬件中指示故障的情境。即使没有这样要求，但可以想象创建故障，导致唤醒计时器偶发性地唤醒处理器。在这种情况下，复位源将表明计时器唤醒，但存储在非易失性存储器中的数据将指示实际上未请求任何唤醒。在控制器醒着时，任务524和526对应于将各自的唤醒信息记入日志的操作。唤醒历史阵列的内容可以被视为计入日志的唤醒信息的集合。

图6是用于检测意外唤醒的过程600的示例性实施例的流程图。过程600表示在任务506期间执行唤醒诊断的其中一个唤醒诊断（见图5）。该说明假设对应于过程600的诊断启用以及唤醒计时器由于任何其他原因尚未不合格。过程600涉及分析在车辆的活动操作状态期间的计入日志的唤醒信息以获得唤醒诊断。因此，所图示的过程600的实施例通过将唤醒历史阵列的索引（index）初始化为诸如零的起始值而开始（任务602）。索引允许过程600确定阵列何时结束（通过比较索引值和在过程500的任务516处维持的计数；见图5）。就此，过程600检查唤醒历史阵列是否结束（查询任务604）。如果是，则过程600导致查询任务622（在下面对该流程进行更详细地描述）。

始于查询任务604的主循环为在唤醒历史阵列中的每一个条目执行一次。由此，如果阵列未结束（查询任务604的“否”分支），则过程600通过检查经分析的条目的计时器诊断的结果而继续（查询任务606）。如果计时器诊断的结果指示唤醒计时器不合格或者无效（查询任务606的“否”分支），则停止当前条目的进一步分析，索引增加（任务608）以及过程600返回到查询任务604。

当计时器诊断指示唤醒计时器对经分析的条目有效时，接着进行查询任务606的“是”分支。就此，过程600检查所请求的（或者设置的）唤醒时间是否等于零（查询任务610）。在这个背景下，为零的唤醒时间指示“唤醒设置”变量等于“假”（见上面过程400的说明）。为零的唤醒时间指示尚未设置任何唤醒时间；在这个背景下，零为默认初始化值。由此，如果实际上存在具有为零的设置的唤醒时间的计时器诱发唤醒事件，则经分析的当前事件可以指示意外唤醒。

查询任务610的“否”分支指示编程的唤醒时间不等于零。此时，过程600比较从唤醒计时器记录的实际唤醒时间和编程的唤醒时间（查询任务612）。针对该示例，查询任务612检查实际唤醒时间是否在相对于设置的唤醒时间的指定时间窗内。时间窗表示仍为了查询任务612导致“匹配”的诸如五秒的允许公差。如果实际唤醒时间“匹配”设置的唤醒时间（查询任务612的“是”分支），则过程600增加“意外唤醒合格”计数（任务614）；增加索引（任务616）以及返回查询任务604以执行下一迭代的主处理循环。“意外唤醒合格”计数表示在唤醒历史阵列中有多少条目通过“意外唤醒”诊断的运行计数。理想地，每一个条目将通过该诊断以及“意外唤醒合格”计数将等于在阵列中的条目数。

再次参照查询任务610，如果编程的唤醒时间等于零（查询任务610的“是”分支），则过程600增加“意外唤醒不合格”计数（任务618）。“意外唤醒不合格”计数表示在唤醒历史阵列中有多少条目未通过“意外唤醒”诊断，即控制器意外唤醒的多少次的运行计数。要注意的是，当实际唤醒时间不“匹配”编程请求唤醒时间（查询任务612的“否”分支）时，同样执行任务618。在任一种情境下，过程600假设控制器错误唤醒。除了增加“意外唤醒不合格”计数之外，过程600为了保持故障追踪而捕获所要求的和实际的唤醒时间（任务620）。在捕获所要求的和实际的唤醒时间之后，过程600继续任务616以增加索引，然后返回查询任务604以进行下一迭代。

如果唤醒历史阵列已经结束（查询任务604的“是”分支），则过程600检查“意外唤醒不合格”计数的状态。就此，如果“意外唤醒不合格”计数大于诸如零的阈值（查询任务622的“是”分支），则过程600报告“意外唤醒”诊断的“不合格”输出。“不合格”输出还可以包括“意外唤醒不合格”计数以识别哪个条目用于计数等。

如果“意外唤醒不合格”计数小于或者等于阈值数（查询任务622的“否”分支），则过程600检查记录在唤醒历史阵列中的唤醒事件的数量（查询任务626）。在这个背景下，唤醒事件的数量对应于在过程500期间维持的计数（见上面任务516的说明）。如果唤醒计数大于零（查询任务626的“是”分支），则过程600报告“意外唤醒”诊断的“合格”输出。查询任务626用于确保“合格”输出未生成，除非已经记录了至少一个成功的唤醒事件。因此，如果唤醒计数小于或者等于零（查询任务626的“否”分支），则过程600在不报告“合格”输出的情况下继续。

最后，过程600清除唤醒计数（任务630）。任务630在报告“合格”输出（任务628）之后；在报告“不合格”输出（任务624）之后或者当唤醒计数小于或者等于零（查询任务626的“否”分支）时执行。唤醒计数在此时清除，因为过程600已经考虑了在唤醒历史阵列中的所有条目（如查询任务604的“是”分支暗指的那样），以及为新的条目准备了阵列。在清除唤醒计数之后，过程600结束。

图7是图示了用于检测已经在唤醒计时器中安排的错过的唤醒的过程700的示例性实施例的流程图。过程700表示在任务506（见图5）期间执行唤醒诊断的另一唤醒诊断。该说明假设对应于过程700的诊断启用以及唤醒计时器由于任何其他原因尚未不合格。所图示的过程700的实施例通过检查最初请求的唤醒时间是否大于零（查询任务702）而开始。如果所请求的唤醒时间大于零（查询任务702的“是”分支），则过程700通过检查经分析的条目的计时器诊断的结果而继续（查询任务704）。如果计时器诊断的结果指示唤醒计时器有效（查询任务704的“是”分支），则过程700读取或者以其他方式获得实际唤醒计时器值（任务706）以及比较实际唤醒计时器值和所请求的唤醒时间（查询任务708）。

如果实际唤醒计时器值大于或者等于所请求的唤醒时间（查询任务708的“是”分支），则过程700报告“未检测到唤醒”诊断的“不合格”输出（任务710）。该情境指示唤醒计时器在未实际唤醒控制器的情况下继续经过所请求的唤醒时间。换言之，安排的唤醒时间由于某种原因错过。

如果所请求的唤醒时间小于或者等于零（查询任务702的“否”分支），或者如果计时器诊断指示唤醒计时器无效（查询任务704的“否”分支），或者如果实际的唤醒计时器值小于所请求的唤醒时间（查询任务708的“否”分支），则过程700检查“意外唤醒合格”计数（查询任务712）。显而易见地，查询任务712影响由过程600维持的“意外唤醒合格”计数。就此，查询任务712检查“意外唤醒合格”计数是否大于零。如果是，则过程700报告“未检测到唤醒”诊断的“合格”输出（任务714）。然而，如果“意外唤醒合格”计数小于或者等于零（查询任务712的“否”分支），则过程700在未报告“未检测到唤醒”诊断的“合格”或“不合格”的情况下结束。执行查询任务712以防止过程700报告“合格”，除非至少一个安排唤醒成功执行并且记录。

再次参照过程500的任务506（图5），每当车辆通电并且置于活动操作状态时，便执行唤醒诊断（例如，过程600和过程700）。由此，唤醒诊断针对在紧接之前的非活动状态的期间安排和执行的唤醒事件执行。在车辆在活动状态下操作时，发出各种“合格”和“不合格”输出（例如，诊断故障码），从而可以在那时进行所需的校正动作。

虽然在上面的详细说明中已经提出了至少一种示例性实施例，但是，应了解，还存在大量变型。还应该了解，本文所描述的示例性实施例或者多个示例性实施例仅为示例，并不旨在以任何方式限制所要求的主题的范围、应用或者配置。确切地说，前述详细说明将为本领域的技术人员提供实现所描述的实施例或者多个示例性实施例的便捷指南。应该理解，在不脱离由权利要求书所限定的范围的情况下，可以对元件的功能和设置进行各种改变，权利要求书包括在提交本专利申请时已知的等同物和可预见的等同物。

Claims (20)

1.一种用于车辆的电子模块的控制和诊断方法，所述方法包括：

在所述车辆的非活动停车状态期间，针对所述电子模块的处理器执行至少一个唤醒事件，所述至少一个唤醒事件由所述电子模块的唤醒计时器发起；

在所述车辆的所述非活动停车状态期间，将与所述至少一个唤醒事件相关联的唤醒信息记入日志以获得计入日志的唤醒信息；

在所述车辆的活动操作状态期间分析所述计入日志的唤醒信息以获得唤醒诊断；以及

在所述车辆的所述活动操作状态期间生成指示所述唤醒诊断的输出。

2.根据权利要求1所述的方法，其中：

所述车辆的所述非活动停车状态对应于熄火状态；以及

所述车辆的所述活动操作状态对应于点火状态。

3.根据权利要求1所述的方法，其中，所述记入日志包括：

针对每一个已执行的唤醒事件，将请求唤醒时间和对应于所述请求唤醒时间的实际唤醒时间记入日志，所述实际唤醒时间从所述唤醒计时器获得。

4.根据权利要求1所述的方法，其中，分析所述计入日志的唤醒信息包括：

确定在所述车辆的所述非活动停车状态期间是否发生了意外唤醒事件。

5.根据权利要求1所述的方法，其中，分析所述计入日志的唤醒信息包括：

确定在所述车辆的所述非活动停车状态期间是否错过了请求唤醒时间。

6.根据权利要求1所述的方法，其中，生成所述输出包括：

当所述分析导致合格唤醒诊断时，生成第一诊断代码；以及

当所述分析导致不合格唤醒诊断时，生成第二诊断代码。

7.一种用于车辆的电子控制模块，其包括：

处理器；

唤醒计时器，所述唤醒计时器操作性地与所述处理器相关联；以及

非易失性存储器元件，所述非易失性存储器元件配置为存储与由所述处理器管理的唤醒请求相关联的唤醒请求信息，其中，所述处理器、所述唤醒计时器和所述非易失性存储器元件协作，以便：

在所述车辆的非活动停车状态期间，针对所述处理器执行至少一个唤醒事件，所述至少一个唤醒事件由所述唤醒计时器发起；

在所述车辆的所述非活动停车状态期间维持唤醒历史阵列，所述唤醒历史阵列包括与所述至少一个唤醒事件相关联的至少一个条目；

在所述车辆的活动操作状态期间分析所述唤醒历史阵列，以获得唤醒诊断；以及

在所述车辆的所述活动操作期间生成指示所述唤醒诊断的输出。

8.根据权利要求7所述的电子控制模块，其中：

所述唤醒历史阵列的每一个条目均包括请求唤醒时间和对应于所述请求唤醒时间的实际唤醒时间；以及

所述实际唤醒时间从所述唤醒计时器获得。

9.根据权利要求7所述的电子控制模块，其中，分析所述唤醒历史阵列包括：

确定在所述车辆的所述非活动停车状态期间是否发生了意外唤醒事件。

10.根据权利要求7所述的电子控制模块，其中，分析所述唤醒历史阵列包括：

确定在所述车辆的所述非活动停车状态期间是否错过了请求唤醒时间。

11.一种用于车辆的电子模块的控制和诊断方法，所述电子模块包括处理器和唤醒计时器，所述方法包括：

在所述车辆的非活动停车状态期间操作所述唤醒计时器，以针对所述处理器发起唤醒事件；

在所述唤醒事件期间操作所述处理器，以执行车辆诊断，管理唤醒请求以及将与所述唤醒事件相关联的唤醒信息记入日志；

在所述车辆的所述非活动停车状态之后的所述车辆的活动操作状态期间，基于计入日志的唤醒信息执行唤醒诊断；以及

在所述车辆的所述活动操作期间生成所述唤醒诊断的结果。

12.根据权利要求11所述的方法，其中：

所述车辆的所述非活动停车状态对应于发动机关闭状态；以及

所述车辆的所述活动操作状态对应于发动机启动状态。

13.根据权利要求11所述的方法，其中，执行唤醒诊断包括：

确定在所述车辆的所述非活动停车状态期间是否发生了意外唤醒事件。

14.根据权利要求11所述的方法，其中，执行唤醒诊断包括：

确定在所述车辆的所述非活动停车状态期间是否错过了请求唤醒时间。

15.根据权利要求11所述的方法，其中，执行唤醒诊断包括：

确定是否成功执行了至少一个请求唤醒时间；

确定在所述车辆的所述非活动停车状态期间是否错过了请求唤醒时间；

当确定在所述车辆的所述非活动停车状态期间错过了请求唤醒时间时，报告“不合格”输出；以及

当确定成功执行了至少一个请求唤醒时间并且在所述车辆的所述非活动停车状态期间未错过请求唤醒时间时，报告“合格”输出。

16.根据权利要求11所述的方法，进一步包括：

接收指示针对所述处理器的请求唤醒时间的唤醒请求；

基于所述请求唤醒时间和所述唤醒计时器的运行时间值确定针对所述唤醒计时器的下一个唤醒时间设置；以及

利用所述下一个唤醒时间设置配置所述唤醒计时器。

17.根据权利要求16所述的方法，其中，确定所述下一个唤醒时间设置包括：

当所述请求唤醒时间小于阈值时间时，使用针对所述下一个唤醒时间设置的最小时间。

18.根据权利要求17所述的方法，其中，所述阈值时间等于所述最小时间。

19.根据权利要求16所述的方法，其中，确定所述下一个唤醒时间设置包括：

当所述请求唤醒时间大于阈值时间时，使用针对所述下一个唤醒时间设置的最大时间。

20.根据权利要求19所述的方法，其中，所述最大时间对应于所述唤醒计时器的最大计时器值。