本文是一篇关于电源管理框架的论文阅读笔记【By CoryXie <cory.xie@gmail.com>】，虽然算不上原创，但也不是完全的翻译，因此勉强选择了这个类型。
原文：<A Framework for Context-Aware Power Management on Embedded Devices>
来源：http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6379923&contentType=Conference+Publications
1. 策略定义
这个框架的本质是允许程序员直观地定义电源管理行为作为策略（policies），无需进入电源管理框架的细节。
框架中使用了两个基本策略定义（policy definitions）：上下文定义（context definition）和控制定义（control definition）。
A.上下文定义（context definition）
上下文定义（Context definition），定义了一组电源控制操作所依赖的信息。例如，如果程序员希望当用户不看显示器时就关闭显示器背光，“用户没有看屏幕”就是一个上下文（context），作为“关闭背光” 动作的理由。上下文定义（context definition）又进一步细分为两类：primary context 和composite context。
Ø primary contexts是最低层上下文，其值由设备驱动和应用直接设置
Ø composite contexts是对primary contexts的逻辑组合。
如下图所示的sensor.temperature和 sensor.dir.pitch 就被定义为 primary contexts；而screen.isWatched就被定义为composite context，代表对智能手机用户是否在注视着屏幕的推断。
由于此规则可以通过更新描述来轻松地被修改，很容易适应其他具有不同的外观和内部组件（包括传感器，或应用程序）的产品的电源管理情形。
B.控制定义（controldefinition）
控制定义（control definition），定义了一组对每个条件的电源管理动作（power management actions）。
图2显示了基于XML的控制定义（control definition）的一个例子。在这个描述中，当用户当前没有正在观看屏幕的时候，显示屏的背光亮度被下降到10％。由于条件可以以上下文的逻辑组合（logical combination of contexts）来书写，对于定义电源管理策略的程序员就变得直观和易于配置。
2. 框架描述
图3显示了该框架的整体架构，以及软件组件之间的关系。为了实现上下文感知的电源管理，我们设计了两个系统服务：上下文管理器（context manager）和电源管理器（power manager）。
这些组件分别处理上下文和控制定义，以为每个提供具体的机制（concrete mechanism）。上下文管理器（context manager）监听从设备驱动程序和应用程序来的主要上下文更新（primary context updates），并在他们所依赖的上下文更新时重新计算复合上下文（composite contexts）。上下文的更新被通知给电源管理器（power manager），电源管理器使用控制策略来决定具体的电源管理动作，并通过设备驱动程序对每个设备管理器执行所决定的动作。
该框架使用D-Bus作为在各个软件组件之间通信的方式。D-Bus支持两种通信：method 和 signal，其中method类似于点对点的RPC，而signal类似于广播消息。
A.上下文管理器（Context Manager）
上下文管理器（context manager）负责收集主要上下文（primary contexts），并管理他们，根据他们计算复合上下文（composite contexts），并通知其更新。上下文管理器（context manager）提供的D-Bus服务如下：
驱动程序和应用用个setValue来设置primary context的值。当一个primary context的值被setValue改变时，所有依赖它的composite contexts都被更新。对于某些需要复杂计算的composite contexts，该框架还对context manager提供了plugin机制，可以在其内部更新primary context。这种功能可以允许框架不支持的composite contexts的计算在plugin中实现。
这里的上下文管理器（context manager）除了用于电源管理功能外，也可作为传感器融合机制（sensor fusion mechanism）独立存在。
B.电源管理器（Power Manager）
电源管理器根据当前的上下文决定电源管理动作。原则上，这个管理器不需要任何的D-Bus服务接口，因为它的被动性。也就是说，电源管理器侦听上下文更新，并采取适合当前上下文条件下的电源管理操作，但不接受请求。相反，它依赖于策略的定义，用以确定电源管理要执行的动作。
然而，由于实际原因，我们添加了下面的D-Bus的方法，用以让应用程序禁止执行电源管理动作：
使用上述方法，应用程序可以阻止特定的电源管理目标进入低于指定水平的省电模式。例如，当应用程序需要通知某些事情，从而自动的省电动作是不必要的时候，应用程序可以阻止LCD背光的亮度低于60％。虽然这种情况，当然也可以使用上下文（contexts）来建模，但是如果应用程序的内部信息被显露为上下文（contexts），电源管理策略会变得相当复杂。因此，该方案决定从这个管理器采取的自主电源管理决策中排除应用程序的内部电源管理决策，而是提供一个接口，用来接收来自应用程序的请求。请注意，当多个应用程序的请求同时发送时，采用所有所要求的最大等级值。