确定下一个唤醒时间将是什么时，过程400可以考虑各种因素。如果仅存在一个待考虑的唤醒请求，则过程400继续处理下面所描述的请求。然而，如果存在多个待考虑的唤醒请求(例如，新请求、未服务的请求、待定请求等)，则过程400选择具有最短唤醒时间的请求。这确保控制器将唤醒以服务下一个唤醒请求。因此，如果过程400在两小时内接收第一唤醒请求并且在五小时内接收第二唤醒请求，则将选择第一请求用于进一步处理。另外，过程400可以使用第二请求的时间戳来保持追踪唤醒时间的“剩余”量，从而使最初请求的唤醒(五小时)仍被服务。由此，当控制器醒着时，除了处理任何最近接收的唤醒请求之外，它可能需要更新与任何未服务或者待定的请求相关联的唤醒时间。
[0062]在某些实施例中，在控制器转换为非活动状态时或者在紧接控制器关闭之后，比较与所选唤醒请求相关联的唤醒时间和阈值时间，阈值时间旨在防止竞争条件，其中，请求唤醒时间被编程在控制器仍醒着的时候发生。这类竞争条件可能导致错过唤醒时间。为了处理这些情况，每当请求唤醒时间小于最小时间周期时，最小时间周期用于设置唤醒计时器。阈值时间周期长到足以防止上面所提及的定时冲突类型。在某些实施例中，最小时间周期可以为:10秒、30秒、60秒等。应了解，阈值时间段可以改变以适应特殊实施例和预期应用的需要。
[0063]如果由所选唤醒请求限定的唤醒时间大于或者等于阈值时间段，则过程400保持限定唤醒时间并且按以下所描述的方式继续。如果由所选唤醒请求限定的唤醒时间小于阈值时间段，则过程400使用下一个唤醒时间设置的最小时间并且如下面所描述的那样继续进行。在某些实施例中，阈值时间等于最小时间。在其他实施例中，不同的时间值可以用作阈值时间和最小时间。
[0064]过程400还可以检查与唤醒计时器硬件的计数容量相关联的对于最大时间的请求唤醒时间。例如，唤醒计时器可以设计为计数至最大计时器值(例如，72小时)。由此，如果唤醒请求需要在80小时之后的唤醒时间，则唤醒计时器将不能直接适应请求。因此，如果由所选唤醒请求限定的唤醒时间大于或者等于阈值时间，则过程400使用最大计时器值而不是请求唤醒时间。如果由所选唤醒请求限定的唤醒时间小于阈值时间，则过程400保持限定唤醒时间并且按需要对唤醒计时器进行编程。在某些实施例中，最大阈值时间等于唤醒计时器的最大计时器值。在其他实施例中，最大时间值可以不同于唤醒计时器的最大计时器值。
[0065]如上面所阐释的，当车辆的发动机/点火装置关闭时，唤醒计时器可以开始计数。然而，在替代实施例中，唤醒计时器控制机构可以灵活配置，从而使其可以在发动机/点火装置关闭之后开始计数。应了解，如果需要这样，则下面所描述的方法可以按需要修改供不同唤醒定时方案使用。假设(针对该特殊示例)当发动机/点火装置关闭时唤醒时间开始，则控制器不必与发动机或者点火装置同时关闭。相反，控制器可以在发动机关闭之后在不定量的时间内保持活动。例如，驾驶员可以使用车载远程通信系统、使用信息通讯系统、使用导航系统等保持收听已停放的车辆的广播。因此，过程400可以对相关的考虑已经在发动机关闭与控制器断电程序之间记录的任何经过的时间的唤醒时间进行分析和编程。例如，假设唤醒请求在发动机关闭之后指定60分钟的唤醒时间，以及控制器在发动机关闭之后保持10分钟活动。如果请求唤醒时间不受任何其他调整，则唤醒计时器将被编程为在50分钟内唤醒。不管控制器实际上何时断电，该定时偏移形式确保唤醒请求按预期方式服务。
[0066]图5是图示了唤醒记入日志过程500的示例性实施例的流程图。过程500在控制器处于活动状态时，以及在ECU已经在车辆的之前的非活动关闭状态期间执行至少一个唤醒事件之后执行。在某些实施例中，过程500在控制器初始化期间执行，控制器初始化在控制器唤醒之后发生。因此，过程500的迭代针对每一个唤醒事件执行。
[0067]过程500可以通过检查当前的唤醒事件是否由唤醒计时器发起而开始(查询任务502)。针对该示例，查询任务502检查指示导致处理器被执行的复位源的处理器的状态寄存器。计时器唤醒通过这些寄存器识别并且独立于唤醒实际上是否被请求。如果当前唤醒事件不由唤醒计时器发起，则过程500检查当前唤醒事件是否对应于通电复位(查询任务504)。就此，当点火设备打开，当发动机发动，当串行数据消息到达等时，通电复位发生。另夕卜，一些车辆当车门打开时执行通电复位。如果通电复位已经发生(查询任务504的“是”分支)，则过程500执行唤醒诊断(任务506)以检查基于时间的唤醒特征的性能。下面参照图6和图7更详细地描述示例性唤醒诊断。
[0068]如果查询任务504确定通电复位尚未发生，则最后请求的唤醒时间被清除(任务508)并且过程500结束。该情境对应于“运行复位”条件，如果在存储器中检测到错误，或者如果在微处理器中发生非法中断，或者如果软件由于某种原因损坏，则“运行复位”条件可以发生。在这种情况下，控制器未适当操作，以及唤醒计时器不能被诊断。由此，在不对唤醒计时器执行诊断的情况下，唤醒时间被清除并且过程500结束。
[0069]查询任务502的“是”分支指示唤醒事件由唤醒计时器导致。因此，过程500确定唤醒计时器是否为记入唤醒历史阵列日志的第一事件(查询任务510)。如果是，则唤醒历史阵列被清除(任务512)以为具有新条目的群体做好准备。如果不是(查询任务510的“否”分支)，则唤醒历史阵列转移或者以其他方式操纵以适应对应于当前唤醒事件的新条目(任务514)。另外，过程500增加代表控制器在车辆的最后非活动周期期间受基于计时器的唤醒的次数的计数(任务516)。针对该示例，计数每基于计时器的唤醒事件增加一次。作为替代实施方式，如果需要这样，计数可以根据任何预定方案调整。
[0070]过程500可以读取或者以其他方式获得指示唤醒计时器的有效性和无效性的计时器诊断结果(任务518)。如上面参照计时器诊断模块310 (见图3)所提及的，E⑶可以使用独立过程检查唤醒计时器的有效性。本文所描述的任务518获得计时器诊断模块310的输出。在某些实施例中，计时器诊断模块310的输出可以为代码、标记或者指示唤醒计时器是有效(准确)还是无效(不准确或者处于错误状态)的任何适当的格式化数据。过程500还读取或者以其他方式获得实际的唤醒计时器值，实际的唤醒计时器值表示唤醒计时器的当前运行时间值(任务520)。
[0071]过程500可以通过在最后的控制器关闭期间检查唤醒时间是否设置而继续(查询任务522)。如果是，则所请求的(设置的)唤醒时间存储在唤醒历史阵列的新条目中(任务524)。附加信息可以被写入新条目，包括但不限于:在任务520处从唤醒计时器获得的实际唤醒时间；在任务518处读取的计时器诊断结构；以及识别唤醒请求的请求程序的“唤醒ID”变量的值(任务526)。如果唤醒时间不在最后控制器关闭(查询任务522的“否”:分支)期间设置，则任务524跳过以及新条目将不包括设置的唤醒时间。查询任务522的“否”分支指示在唤醒计时器硬件中指示故障的情境。即使没有这样要求，但可以想象创建故障，导致唤醒计时器偶发性地唤醒处理器。在这种情况下，复位源将表明计时器唤醒，但存储在非易失性存储器中的数据将指示实际上未请求任何唤醒。在控制器醒着时，任务524和526对应于将各自的唤醒信息记入日志的操作。唤醒历史阵列的内容可以被视为计入日志的唤醒信息的集合。
[0072]图6是用于检测意外唤醒的过程600的示例性实施例的流程图。过程600表示在任务506期间执行唤醒诊断的其中一个唤醒诊断(见图5)。该说明假设对应于过程600的诊断启用以及唤醒计时器由于任何其他原因尚未不合格。过程600涉及分析在车辆的活动操作状态期间的计入日志的唤醒信息以获得唤醒诊断。因此，所图示的过程600的实施例通过将唤醒历史阵列的索引(index)初始化为诸如零的起始值而开始(任务602)。索引允许过程600确定阵列何时结束(通过比较索引值和在过程500的任务516处维持的计数；见图5)。就此，过程600检查唤醒历史阵列是否结束(查询任务604)。如果是，则过程600导致查询任务622 (在下面对该流程进行更详细地描述)。
[0073]始于查询任务604的主循环为在唤醒历史阵列中的每一个条目执行一次。由此，如果阵列未结束(查询任务604的“否”分支)，则过程600通过检查经分析的条目的计时器诊断的结果而继续(查询任务606)。如果计时器诊断的结果指示唤醒计时器不合格或者无效(查询任务606的“否”分支)，则停止当前条目的进一步分析，索引增加(任务608)以及过程600返回到查询任务604。
[0074]当计时器诊断指示唤醒计时器对经分析的条目有效时，接着进行查询任务606的“是”分支。就此，过程600检查所请求的(或者设置的)唤醒时间是否等于零(查询任务610)。在这个背景下，为零的唤醒时间指示“唤醒设置”变量等于“假”(见上面过程400的说明)。为零的唤醒时间指示尚未设置任何唤醒时间；在这个背景下，零为默认初始化值。由此，如果实际上存在具有为零的设置的唤醒时间的计时器诱发唤醒事件，则经分析的当前事件可以指示意外唤醒。
[0075]查询任务610的“否”分支指示编程的唤醒时间不等于零。此时，过程600比较从唤醒计时器记录的实际唤醒时间和编程的唤醒时间(查询任务612)。针对该示例，查询任务612检查实际唤醒时间是否在相对于设置的唤醒时间的指定时间窗内。时间窗表示仍为了查询任务612导致“匹配”的诸如五秒的允许公差。如