主车辆的ECU 300执行的唤醒控制和诊断操作的示例性实施例的框图。作为一个非限制性示例，图3可以与汽车的发动机控制模块的操作相关联。图3描绘的块可以实现为硬件设备或者部件、逻辑处理模块、软件实施过程等。图3为了便于说明和清晰示出了单独的块。
[0047]E⑶300的图示的实施例可以包括但不限于:唤醒请求管理器302 ;唤醒计时器304 ;非易失性存储器306 ;唤醒记入日志模块308 ;计时器诊断模块310 ;以及唤醒诊断模块312。这些元件和模块根据需要协作以支持下面参照图4-7更详细地描述的各种任务、方法和过程。
[0048]唤醒请求管理器302代表当E⑶300的控制器处于活动通电状态下时执行或者启用的逻辑处理模块。就此，唤醒请求管理器302可以被视为控制器的功能模块。唤醒请求管理器302适当地配置为接收由ECU、软件任务、例行程序和/或主车辆的车载子系统所发出的唤醒请求320，并且根据需要处理接收到的唤醒请求320。唤醒请求指示请求例程、过程、任务或者部件(即“请求程序”)想让ECU 300的控制器因为某种原因在指定时间(或者次数)唤醒。作为一个非限制性示例，为了在车辆关闭之后在指定时间测试电池状态，车辆的电气子系统可以发出唤醒控制器的唤醒请求。为此，可能需要在发动机关闭之后一小时、二小时、四小时以及八小时测试电池状态。作为另一非限制性示例，为了测试燃料箱状态，车辆的燃料子系统可以发出另一唤醒控制器的唤醒请求。就此，可能需要在发动机关闭之后五小时、七小时以九小时检查燃料箱状态；唤醒请求可以在这些时间用于启动E⑶300的控制器。
[0049]如下面更详细地描述的，唤醒请求管理器302在E⑶300的控制器关闭(断电)之前立即执行某些任务和过程。例如，唤醒请求管理器302对每一个接收到的唤醒请求320打上时间戳记，确定哪个唤醒请求320考虑为优先请求，以及基于所选的唤醒请求320和与唤醒计时器304相关联的附加请求设置下一个请求的唤醒时间。当设置下一个唤醒时间时，唤醒请求管理器302还可以考虑未服务的唤醒请求。在确定下一个唤醒时间将是什么之后，唤醒请求管理器302与唤醒计时器304以适当方式协作以利用下一个唤醒时间设置配置唤醒计时器304。唤醒请求管理器302还将唤醒请求信息保存在非易失性存储器306中。这使ECU 300能够在控制器断电之后保留与唤醒请求相关联的数据。在某些实施例中，非易失性存储器306至少存储以下信息，但不限于:在唤醒计时器304中编程的唤醒计时器值；唤醒计时器304的当前运行时间值；以及与唤醒请求源于的请求程序相关联的标识符(例如，地址、部件名或者代码)。
[0050]如上所提及的，唤醒计时器304可以实施为与控制器硬件相关的不同的单独的硬件设备。唤醒计时器304维持运行时间计数，运行时间计数可以由运行时间值、运行时钟值等表示。在某些实施例中，每当车辆状态不处于“运行”或者“开动”模式时，运行值复位，并且它不管控制器的状态(通电或者断电)而保持活动。实际上，编程到唤醒计时器304中的唤醒时间基于运行时间值。因此，当前设置的唤醒时间引用运行时间值的计数状态。由此，当唤醒计时器304到达设置的唤醒时间时，其发起唤醒程序，在唤醒程序中，操作功率/电压被应用于控制器硬件，控制器硬件转而使控制器转换至其通电状态。
[0051]唤醒记入日志模块308可以实施为:当唤醒计时器304启动E⑶300的控制器时执行或者启用的逻辑处理模块。就此，唤醒记入日志模块308可以被视为控制器的功能模块。图3的虚线322示意性地指示了唤醒记入日志模块308响应到达设置的唤醒时间的唤醒计时器304。在这个背景下，唤醒计时器304可以用作唤醒记入日志模块308的启动触发器。当活动时，唤醒记入日志模块308获得存储在非易失性存储器306中最近的唤醒请求信息，并且将包括所获信息的新条目填入唤醒历史数据阵列。唤醒记入日志模块308还将实际唤醒计时器值添加至新条目以当控制器实际唤醒时保持追踪。在某些实施例中，唤醒记入日志模块308与计时器诊断模块310通信以获得关于唤醒计时器304的操作状态的诊断信息。因此，在唤醒历史阵列中的每一个条目至少包括以下信息，但不限于:设置的唤醒请求；对应的编程唤醒时间设置；对应的从唤醒计时器304获得的实际唤醒时间；以及在条目制定时指示唤醒计时器304有效还是无效的诊断计时器信息。
[0052]在车辆保持在非活动状态时(即，直到车辆再次发动)，唤醒记入日志模块308维持唤醒历史阵列。这使每当唤醒计时器304在车辆的非活动状态期间唤醒控制器时，唤醒记入日志模块308能够更新唤醒历史阵列。由此，每当控制器响应于设置的唤醒时间唤醒时，唤醒记入日志模块均向历史阵列增添新的条目。
[0053]如上面所简要提及的，计时器诊断模块310生成并且提供指示唤醒计时器304是否在有效准确的状态下操作的诊断计时器信息。就此，计时器诊断模块310可以实施为:当ECU 300的控制器醒着时执行或者启用的逻辑处理模块。在某些实施例中，计时器诊断模块310单独地检查唤醒计时器304的操作和有效性并且生成指示唤醒计时器304有效还是无效的标记或者输出。
[0054]唤醒诊断模块312可以实施为:当车辆的通电状态唤醒E⑶300的控制器时执行或者启用的逻辑处理模块。图3的虚线324表示车辆通电条件，车辆通电条件转而启动唤醒诊断模块312。唤醒诊断模块312分析在紧接车辆的断电状态之前的期间维持的唤醒历史阵列。唤醒诊断模块312回顾记入日志唤醒历史数据以确定请求的唤醒时间是否(合理地)对应于实际的唤醒时间，并且检查控制器实际上是否如期唤醒。唤醒诊断模块312还检查控制器自身是否意外唤醒，即，在无对应的唤醒请求的情况下。唤醒诊断模块312还可以检查唤醒计时器是否还具有尚未服务的编程唤醒时间。如果是，则唤醒诊断模块312确定设置的唤醒时间是否已经经过(即，最后安排的唤醒时间是否错误地跳过)。
[0055]唤醒诊断模块312适当地配置为生成指示唤醒特征的有效性的诊断故障码326。在某些实施例中，如果唤醒历史数据确定为有效，则唤醒诊断模块312生成“合格”;如果唤醒历史数据指示问题，则生成“不合格”。由此，每当车辆发动(即，发动机启动)并且还存在之前的计时器唤醒时，就生成“合格”或者“不合格”，其中，代码基于在紧接车辆的非活动状态之前的期间收集的唤醒历史数据指示控制器唤醒特征的有效性。
[0056]图4是图示了唤醒计时器设置过程400的示例性实施例的流程图，唤醒计时器设置过程400可以与唤醒请求管理器302的操作相关联。关于本文所描述的过程执行的各种任务可以由软件、硬件、固件或者其任何组合执行。为了图示，过程的说明指上面关于图1-3提及的元件。实际上，所描述的过程的部分可以由所描述的系统的不同元件执行，例如，唤醒请求管理器302、唤醒计时器304、唤醒记入日志模块308或者唤醒诊断模块312。应了解，所描述的过程可以包括任何数量的附加或者替代任务，在附图中示出的任务不需按图示顺序执行，以及所描述的过程可以并入具有本文未详细描述的附加功能的更全面的程序或者过程。另外，只要预期的全部功能性保持完整，则在附图中示出的一个或多个任务可以从所图示的过程的实施例省略。
[0057]如上所提及的，唤醒请求管理器302处理唤醒请求并且利用下一个唤醒时间对唤醒计时器304进行编程。因此，过程400可以在E⑶的控制器的关闭程序期间执行。就此，在控制器保持活动时，过程400完成。过程400的图示的实施例检查是否已经接收到至少一个唤醒请求(查询任务402)。如果未接收(查询任务402的“否”分支)，则过程400将下一个唤醒时间设置为等于零或者任何指定“禁用”值以指示唤醒时间将不被编程(任务404)。过程400还将“唤醒设置”变量设置为“假”(任务406)并且将“唤醒ID”变量设置为空值(任务408)。“空ID”值可以为解释为意味着请求程序尚未发起任何唤醒请求的任何值。在设置这两个值之后，过程400进行到下面更详细地描述的任务418。
[0058]如果已经接收到一个或多个唤醒请求(查询任务402的“是”分支)，则过程400通过检索唤醒计时器的当前运行时间值而继续(任务410)。如之前所阐释的，运行时间值指示自从车辆关闭后经过了多长时间，不论控制器实际上何时断电。由此，在车辆关闭与控制器断电之间可能存在时间偏移。例如，如果停车，而立体声在完全断电之前运行二十分钟，则唤醒计时器的当前运行时间值将指示约二十分钟的运行时间。作为另一示例，如果发动机和其他系统约同时完全关闭，则唤醒计时器的当前运行时间将指示接近，诸如零的初始值的运行时间。
[0059]接着，过程400计算或者以其他方式确定为唤醒计时器编程的下一个唤醒时间设置(任务412)。如下面更详细地描述的，下一个唤醒时间基于当前运行时间值、由接收到的唤醒请求指示的请求的唤醒时间以及关于唤醒计时器硬件的实际限制的其他因素确定。过程400还将“唤醒设置”变量设置为“真”(任务414)并且将“唤醒ID”变量设置为识别请求程序的值(任务416)。在某些实施方式中，设置变量“唤醒ID”以指示地址、用户名或者分配给请求程序的代码。
[0060]过程400通过利用下一个唤醒时间配置唤醒计时器而继续(任务418)。另外，过程400将相关的唤醒请求信息存储在非易失性存储器中(任务420)。如上面所提及的，所存储的信息可以用于结合唤醒诊断模块的操作。在过程400完成时，控制器可以断电并且休眠。
[0061]再次参照任务412，当