CN102780727A - 一种物联网终端设备的动态电源管理方法 - Google Patents
一种物联网终端设备的动态电源管理方法 Download PDFInfo
- Publication number
- CN102780727A CN102780727A CN2011101236639A CN201110123663A CN102780727A CN 102780727 A CN102780727 A CN 102780727A CN 2011101236639 A CN2011101236639 A CN 2011101236639A CN 201110123663 A CN201110123663 A CN 201110123663A CN 102780727 A CN102780727 A CN 102780727A
- Authority
- CN
- China
- Prior art keywords
- power consumption
- request
- correspondence
- power
- terminal equipment
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Power Sources (AREA)
Abstract
本发明涉及一种物联网终端设备(监控设备),其通过为物联网终端设备(监控设备)的驱动对象设置代理对象实现对驱动对象的代理,进而通过设置的代理对象实现对驱动对象功耗调整事件的中间控制和管理。本发明还提供一种对物联网终端设备(监控设备)进行电源动态管理的方法。利用本发明,设备始终可用,系统随时可以自动关闭,减少了驱动程序和应用程序开发人员的麻烦,提高了系统开发效率,节省了电源,延长了待机时间,在不损失性能的前提下尽可能优化系统功耗,性能稳定可靠,适用范围较广,给人们的工作和生活带来很大的便利。
Description
技术领域
本发明涉及物联网终端设备(监控设备)及其管理方法,特别涉及物联网终端设备(监控设备)及对该物联网终端设备(监控设备)进行电源动态管理的方法。
背景技术
现代社会中,随着科学技术的不断进步,越来越多的人们已经开始使用物联网终端设备(监控设备),而对于众多的物联网终端设备(监控设备)来说,电源的供给是必不可少的。因此电源管理是物联网终端设备(监控设备)上的重要课题,在现有技术中,各类嵌入式操作系统平台均在某种程度上支持动态电源管理(DPM,Dynamic Power Management)。下面以MontaVista公司的MontaVista Linux系统和Microsoft公司的Windows Mobile系统为例进行介绍。
MontaVista Linux系统是MontaVista公司对Linux内核针对物联网终端设备(监控设备)做了一定裁剪和完善的Linux版本,也是物联网终端设备(监控设备)上使用较为广泛的Linux系统。MontaVista系统把系统按照不同的参数分为不同的操作点(Operation Point),一个操作点对应一种功耗和性能的固定的参数搭配,比如Core电压1.1v,CPU频率13MHz,SRAM timing CAS2,由不同的策略(Policy)把一组操作点映射成一个操作状态(Operation State),系统初始化时,必须创建一些操作点,策略,和操作状态,运行过程中,系统的DMP框架负责管理Policy和在不同的操作状态间切换。在MontaVista中,驱动必须响应PM_SUSPEND和PM_RESUME请求。
而Window Mobile是Microsoft公司的 以WinCE为内核,并作一定裁剪和完善的物联网终端设备(监控设备)操作系统。Windows Mobile在WinCE4.0后引入了专门的电源管理程序,这个电源管理程序代替了以前散见于GWES(图形、窗口、事件子系统)的函数,定义了一系列的电源管理状态:D0、D1、D2、D3。应用程序可以接收系统电源管理状态的改变的通知,可以请求改变电源管理状态,并可以阻止系统关闭电源。在Windows Mobile中,驱动必须响应IOCTL_POWER_SET请求,并改变设备状态。
以上的这两种技术都在某种程度上以一定的灵活性和可扩展性改善了物联网终端设备(监控设备)的电源管理,但是,应用程序和驱动程序仍然在DPM中承担比较重要的责任,开发人员也需要对系统使用的策略和机制有较为深入的了解才能最大限度的节省功耗。举例而言,在Windows Mobile上,当某个设备响应电源管理程序的IOCTL_POWER_SET请求时,必须记录自己的电源管理状态,在状态改变的过程中,也必须维护自己的状态。在MontaVista中,应用程序在使用设备前必须查询设备电源管理状态,如果已经关闭,则需要开启电源。另外,二者都过于依赖应用程序进行电源管理,希望应用程序能主动关闭特定设备的电源(比如请求电源管理状态变更,或者改变策略),此举固然加大了应用程序的灵活性,但也加大了开发人员的负担。
随着构件技术的发展,出现了新一代的基于构件技术的网络操作系统平台。从而有必要利用其构件技术,在不牺牲性能和节省功耗的前提下,减轻开发人员的负担,提高开发效率,实现性能,功耗,开发效率的平衡。
发明内容
鉴于以上内容,有必要提供一种物联网终端设备(监控设备),其通过采用代理机制,实现在不损失性能的前提下尽可能优化系统功耗,性能稳定可靠,适用范围较广。
此外,还有必要提供一种电源动态管理方法,适用于物联网终端设备(监控设备),其通过采用代理机制,实现在不损失性能的前提下尽可能优化系统功耗,性能稳定可靠,适用范围较广。
一种物联网终端设备(监控设备),该物联网终端设备(监控设备)基于代理机制进行电源的动态管理。该物联网终端设备(监控设备)包括:存储装置和中央处理器。该存储装置用于存储一操作系统及电源动态管理程序。该中央处理器用于在运行该操作系统后,读取并执行该电源动态管理程序以执行以下步骤:a、为需要代理的驱动对象创建并注册对应的代理对象,以根据代理对象为对应的驱动对象进行代理;b、通过代理对象监控并拦截向对应的驱动对象发起的功耗请求事件;c、判断代理对象的电源管理状态是否合适以响应该功耗请求事件;d、若代理对象的电源管理状态合适,则向对应的驱动对象发送该功耗请求事件,在对应的驱动对象响应完该功耗请求事件后转到下述步骤e,或者,若代理对象的电源管理状态不合适,则转到下述步骤f;e、进行功耗调低:在需要将功耗调低时,向对应的驱动对象发送功耗调低请求,在功耗调低请求发送成功的情况下更改代理对象自身的电源管理状态,随后转到上述步骤b,或者,在不需要将功耗调低时,直接转到上述步骤b;及f、进行功耗调高:向对应的驱动对象发送功耗调高请求,在功耗调高请求发送成功时更改代理对象自身的电源管理状态,随后转到上述步骤c,或者,在功耗调高请求发送失败时,转到上述步骤b。
一种电源动态管理方法,适用于物联网终端设备(监控设备),该方法采用代理机制对物联网终端设备(监控设备)进行电源动态管理。该物联网终端设备(监控设备)安装有操作系统和电源动态管理程序,该方法包括步骤:运行该操作系统;读取并执行该电源动态管理程序以执行以下步骤:a、为需要代理的驱动对象创建并注册对应的代理对象,以根据代理对象为对应的驱动对象进行代理;b、通过代理对象监控并拦截向对应的驱动对象发起的功耗请求事件;c、判断代理对象的电源管理状态是否合适以响应该功耗请求事件;d、若代理对象的电源管理状态合适,则向对应的驱动对象发送该功耗请求事件,在对应的驱动对象响应完该功耗请求事件后转到下述步骤e,或者,若代理对象的电源管理状态不合适,则转到下述步骤f;e、进行功耗调低:在需要将功耗调低时,向对应的驱动对象发送功耗调低请求,在功耗调低请求发送成功的情况下更改代理对象自身的电源管理状态,随后转到上述步骤b,或者,在不需要将功耗调低时,直接转到上述步骤b;及f、进行功耗调高:向对应的驱动对象发送功耗调高请求,在功耗调高请求发送成功时更改代理对象自身的电源管理状态,随后转到上述步骤c,或者,在功耗调高请求发送失败时,转到上述步骤b。
采用了该发明的物联网终端设备(监控设备)上基于代理机制的动态电源管理方法,由于其中使用了代理机制,从而拦截了对驱动对象的接口访问并结合事件通知,整体上监控了驱动对象的使用情况,并可以自动记录设备的功耗状态,自动切换设备的功耗状态,使设备对使用者来说始终可用,对系统来说则随时可以自动关闭,并使得驱动程序开发人员减少了设备状态维护的麻烦,而仅仅需要响应特定的电源管理请求,使得应用程序开发人员减少了查询设备电源状态的麻烦,仅仅需要实现特定的业务逻辑,从而提高了系统开发效率;同时由于驱动对象会被代理对象及时关闭电源,所以节省了不必要的电源,延长了待机时间,在不损失性能的前提下尽可能优化系统的功耗,而且系统工作性能稳定可靠,适用范围较为广泛,给人们的工作和生活都带来了很大的便利。
附图说明
图1为本发明物联网终端设备(监控设备)的系统架构示意图。
图2为本发明物联网终端设备(监控设备)及对其进行电源动态管理的方法中的代理对象的第一种状态机示意图。
图3为本发明物联网终端设备(监控设备)及对其进行电源动态管理的方法中的代理对象的第二种状态机示意图。
图4为本发明物联网终端设备(监控设备)及对其进行电源动态管理的方法中的代理对象的第三种状态机示意图。
图5为本发明使用代理机制的电源动态管理方案与Windows CE中的电源管理方案的功耗对比示意图。
图6为本发明使用代理机制的电源动态管理方案与现有技术中不使用代理机制的电源管理方案的CPU性能对比示意图。
具体实施方式
本发明应用之物联网终端设备(监控设备)包括存储装置和中央处理器(Central Processing Unit,CPU),所述存储装置和中央处理器虽未于图中示出,但本领域技术人员应当毫无疑义的知晓所述物联网终端设备(监控设备)包括所述存储装置和中央处理器,应当毫无疑义的知晓所述存储设备可用于存储任意适合的可被导入或导出的数据(包括任意适合的程序代码段),且应当知晓所述中央处理器用于数据的运算和处理(例如:运行操作系统,执行任意适合的程序等)。在本实施例中,所述存储装置用于存储一操作系统及电源动态管理程序,所述中央处理器用于在运行该操作系统后,读取并执行该电源动态管理程序。
为了能够更清楚地理解本发明的技术内容,特举以下实施例详细说明。
请参阅图1至图4所示,所述的物联网终端设备(监控设备)中包括动态电源管理功能模块和设备驱动功能模块,其中,所述的方法包括以下步骤:
(1)物联网终端设备(监控设备)系统进行初始化操作;
(2)所述的动态电源管理功能模块根据设备驱动功能模块进行代理对象创建和初始化操作,包括以下步骤:
(a)所述的动态电源管理功能模块截获所述的设备驱动功能模块的接口注册请求;
(b)所述的动态电源管理功能模块判断所述的设备驱动功能模块是否需要代理,包括以下步骤:
(i)对所述的设备驱动功能模块的类型进行判断;
(ii)如果该设备驱动功能模块为外部物理设备的驱动功能模块,则返回需要代理的判断结果;
(iii)如果该设备驱动功能模块为与功耗无关的驱动程序或者伪驱动程序,则返回不需要代理的判断结果;
(c)如果需要代理,则所述的动态电源管理功能模块创建对应的代理对象,包括以下步骤:
(i)所述的动态电源管理功能模块根据所述的设备驱动功能模块的接口和该设备驱动模块的名称创建相应的代理对象;
(ii)所述的动态电源管理功能模块使用该设备驱动功能模块的名称来注册该对应的代理对象;
(d)所述的动态电源管理功能模块对所述的代理对象进行初始化操作,包括以下步骤:
(i)所述的动态电源管理功能模块初始化该代理对象的初始电源管理状态;
(ii)所述的动态电源管理功能模块初始化该代理对象的定时器定时间隔;
(3)所述的动态电源管理功能模块将功耗请求事件送至所创建的相应代理对象,其中该功耗请求事件可以为读或写数据事件、控制请求事件、用户通知事件、操作系统的线程调度事件或者用户的锁屏或解锁通知事件;
(4)所述的代理对象根据该功耗请求事件进行电源管理状态调整操作,并向设备驱动功能模块发送功耗调整请求,包括以下步骤:
(a)所述的代理对象接收所述的功耗请求事件;
(b)代理对象判断当前的电源管理状态是否适合响应此功耗请求事件;
(c)如果适合,则转发该功耗请求事件,并进行功耗调低处理操作,包括以下步骤:
(i)代理对象判断当前的电源管理状态是否需要向功耗更低的方向调整;
(ii)如果需要,则启动定时器,反之,则返回前述步骤(a);
(iii)如果有新的功耗请求事件到达,则返回上前步骤(b);
(iv)如果定时器达到系统预设的超时时间,则该代理对象向设备驱动功能模块发送功耗调低请求;
(v)如果发送成功,则该代理对象更改当前自身的电源管理状态,并返回上述步骤(a);
(vi)如果发送失败,则返回上述步骤(a);
(d)如果不合适,则进行功耗调高处理操作,包括以下步骤:
(i)该代理对象向设备驱动功能模块发送功耗调高请求;
(ii)如果发送成功,则该代理对象更改当前自身的电源管理状态,并返回上述步骤(a);
(iii)如果发送失败,则返回上述步骤(a);
(5)所述的设备驱动功能模块根据所述的功耗调整请求对设备的电源管理状态进行物理转换。
其中,本发明主要是关于物联网终端设备(监控设备)上的电源管理技术,特别是关于嵌入式操作系统上对物联网终端设备(监控设备)上CPU,及各个典型外设如LCD、Audio Codec等的动态电源管理技术。本发明的方法的核心是代理机制,在代理的基础上,可以自动维护设备电源状态,可以自动切换电源状态,实现外设电源管理状态的自适应管理。
对于代理机制的基本思想,人类社会中已经由来已久,比如委托代理是一种普遍的社会现象。凡是存在中间环节的过程,都会涉及代理现象。以专利申请为例,申请人可能只是出具交底书,而专利申请相关的规范性文件则往往由代理人准备,但对申请人而言,它无需关注知识产权局的各类规范性文件,而是认为知识产权局也可以接受交底书,即这些规范性文件对申请者是透明的。这样安排的好处是分工协作,专业劳动,对申请人而言减少了负担,对整个社会(系统)而言提高了申请效率。
而在计算机技术领域,类似机制也被广泛使用。代理机制在计算机领域应用的基本思想是,客户端(这个客户端是广义的,泛指任何使用某项服务的程序)对服务端发出的调用被代理拦截,经过特定处理后发送到服务端,服务端返回的结果也被代理拦截,经过处理后发送到原始客户端。这个拦截过程实现了额外的功能,使得使用服务端所必需的某些额外操作得一向客户端屏蔽。从而简化了客户端的编程,提高开发效率。
比如,在COM的远程接口调用中,客户端调用非本地接口时和本地接口并无差别,系统自动处理接口参数的列集和散集,客户调用实质上发送到其代理,这个代理对象把参数列集处理(即按照特定规律封装数据),并发送到远程接口的代理,这个远程代理把接口方法散集处理(即按照特定规律解包数据),然后调用真正的接口方法。这个过程对客户端而言是透明的,简化了客户端的编程,否则客户端将不得不使用原始的套接字(Socket),将不得不自行处理应用层协议,即传递数据的语义,以供双方分辨接口调用的参数。不得不处理容错,连接关闭和缓存等一系列问题。
同理,在JAVA平台的RMI(远程方法调用)中,在CORBA的接口调用中,以及任何严肃的分布式计算环境中,都有类似的机制。
总之,代理机制可以有效的减少客户端的开发负担,自行拦截客户端的调用,并作处理,使得某些系统必要的工作对使用者透明。
对于本发明的基于代理机制的动态电源管理技术,主要由DPM程序,驱动对象,驱动对象的代理对象及应用程序(实际指驱动对象使用者,也包括其他系统服务,下文提及应用程序,均符合此涵义)以及操作系统内核共同组成。驱动对象实现特定的IO请求和电源管理请求(Power_Request),代理对象拦截应用程序对驱动对象的调用,按照特定策略处理后向驱动对象转交方法调用,在调用结束后,也按照特定策略处理调用结果,在此过程中实现对设备使用的监控,自动完成电源管理状态的维护和切换(参考图1,基于代理机制的动态电源管理技术框图)。
上述的驱动对象应该至少具有以下功能特点:
(1)实现系统驱动接口方法,可以响应正常的IO请求,典型的比如读数据,写数据,控制请求,即RWC方法(Read/Write/Control)。
(2)在实现驱动的接口方法同时,额外响应电源管理请求,以物理的转换设备电源管理状态,典型的比如挂起设备,恢复设备请求,即Power_Request(Power_Suspend、Power_Resume)等。
(3)驱动对象需使用某种系统提供的方法发布自己的接口,以使得应用程序或其他系统服务找到驱动对象。
上述代理对象应该至少具有以下功能特点:
(1)实现与驱动对象相同的系统驱动接口方法(但不能响应Power_Request),可以响应正常的IO请求,但不是真正操作物理设备以响应此请求,而可以使用转交或者别的方法响应此请求。
(2)一个定时器句柄,以在代理对象访问结束后激发定时策略。
(3)设备电源管理状态,以记录,转换,维护状态机。
(4)接收通知的方法,以便于处理非接口方法调用但使用外设的情况。
(5)驱动对象的指针或者句柄,便于转发调用请求。
上述的DPM程序应该至少具有以下功能特点:
(1)维护代理对象列表,使得代理对象可以被管理和控制。
(2)实现系统驱动接口方法,使得系统其他服务或者应用程序可以管理,访问电源管理程序。
注意,实现驱动接口方法是非限定性的,目的只是提供其他服务或者应用程序访问的方法。
上述应用程序应该至少具有以下功能特点:
(1)发现特定驱动对象接口服务的能力。典型的如根据约定服务名,使用系统提供的服务接口查找例程发现其感兴趣的接口服务。
(2)使用特定驱动对象接口服务的能力。典型的如设定缓冲区大小,设定控制器参数,设定IO请求包相关数据项等。
上述的内核应该至少具有以下功能特点:
(1)提供注册服务接口的方法。
(2)提供挂接到注册服务接口方法的回调机制。
(3)提供查找服务接口的方法。
在实际使用当中,基于代理机制的动态电源管理方法的实现步骤如下:
1、驱动对象:
步骤1 —— 实现系统为驱动程序规定的接口方法。
步骤2 —— 在某个接口方法(比如Control方法)中实现Power_Request请求。
步骤3 —— 使用操作系统提供的发布构件对象的方法发布自己。
2、代理对象(请参阅图2所示):
步骤1 —— 等待其他系统服务或者应用程序(以下统称客户端)对驱动接口的请求。
步骤2 —— 判断代理对象的电源管理状态是否合适响应此RWC请求。
步骤3 —— 状态合适响应此请求,转发RWC请求。不合适转后续步骤9。
步骤4 —— 判断代理对象的电源管理状态是否需要向功耗更低方向调整。
步骤5 —— 需要调整,则启动定时策略。不需要调整,返回上述步骤1。
步骤6 —— 新的请求到达,返回上述步骤2。
步骤7 —— 定时到达,给驱动对象发送Power_Request,请求调低功耗。如果成功,更改自身电源管理状态。
步骤8 —— 停止定时策略。返回上述步骤1。
步骤9 —— 给驱动对象发送Power_Request,请求调高功耗。如果成功,更改自身电源管理状态,转步骤2。如果失败,返回上步骤1。
上述所给出的步骤仅仅是一个典型设备的实施步骤,根据实际情况,允许适当的变化。举例而言,物联网终端设备(监控设备)上LCD的使用往往既和其接口调用方法有关,也和用户输入事件相关,可以参考上述步骤给出其代理对象的实现步骤如下,请参阅图3所示:
步骤1 —— 等待其他系统服务或者应用程序(以下统称客户端)对驱动接口的请求和用户事件通知(如按键事件或触屏事件)。
步骤2 —— 判断代理对象的电源管理状态是否合适响应此RWC请求。
步骤3 —— 状态合适响应此请求,转发RWC请求。不合适转步骤9。
步骤4 —— 判断代理对象的电源管理状态是否需要向功耗更低方向调整。
步骤5 —— 需要调整,则启动定时策略。不需要调整,转步骤1。
步骤6 —— 新的请求或者用户事件通知到达,回步骤2。
步骤7 —— 定时到达,给驱动对象发送Power_Request,请求调低功耗。如果成功,更改自身电源管理状态。
步骤8 —— 停止定时策略。转步骤1。
步骤9 —— 给驱动对象发送Power_Request,请求调高功耗。如果成功,更改自身电源管理状态,转步骤2。如果失败,转步骤1。
而对于CPU也可视为一个特殊的设备,虽然其无RWC方法的调用,但一样存在多个功耗状态的转换,可以使用代理对象封装。不同的是其关注的事件或者请求不一样而已,CPU的代理对象典型的关注操作系统的Idle线程被调度事件,用户的锁屏和解锁通知等,CPU的驱动对象往往和具体CPU的电源管理架构和状态有关,根据其能力不同有不同的实现,具体请参阅图4所示。
同时,上述所给的步骤仅仅涉及驱动对象的代理和必要的自动管理机制的使用(如定时机制和事件机制),并不限制其所涉代理对象具体电源管理状态的多寡和其具体实现以及与其他DPM策略的整合。比如某些CPU芯片的低功耗状态可能比较多,而某些CPU芯片则可以根据其使用状况(如利用率、IO吞吐量、Cache缺失率等)动态调频调压,均可以被整合进基于代理机制的动态电源管理技术。
而且,在图2至图4中的各个状态仅供示意使用,与实际实现中不保证一致,实际上,在实际实现中,仅仅一个Suspend状态往往是不够的,某些设备可能有多个低功耗状态。
3、DPM程序:
步骤1 —— 截获驱动对象注册(发布)接口请求。
步骤2 —— 判断对象是否需要代理。
步骤3 —— 需要代理,则根据驱动对象接口和驱动对象名创建代理对象并使用驱动对象名注册代理对象,实现代理。不需要则转步骤1。
步骤4 —— 初始化代理对象,包括初始电源管理状态,定时器定时间隔等。
步骤5 —— 接受用户请求,事件通知,根据所掌握的代理对象处理或者转发。
以下结合附图说明以及具体实例对本发明作进一步的详细说明。
本发明能够在新一代基于构件的网络操作系统Elastos实现基于代理机制的动态电源管理方案。Elastos是32位的嵌入式操作系统,其包含进程、线程等系统API以及图形系统、文件系统和网络系统等系统服务。在Elastos中,各个系统服务,如驱动程序,均需实现系统规定的特定接口。使用者需先找到特定接口,方可使用其接口方法。以下为详细实施方式。
驱动对象
步骤1:驱动程序需实现如下所示的IDriver接口,以响应IO请求(即RWC调用)。
以audiocodec驱动为例,Read方法返回录音数据,Write方法写入待播放的音频数据,Control方法设置采用率,声道数等参数。Audio驱动实现上述3个方法响应应用程序或其他系统服务的RWC调用。
步骤2:在Control方法中,实现几个约定的nControlCode响应Power_Request请求。
步骤2.1:nControlCode为1000,则使外设芯片进入Suspend状态。
步骤2.2:nControlCode为1001,则使外设芯片从Suspend状态恢复正常。
步骤2.3:nControlCode为1002,则使外设芯片进入PowerOff状态。
步骤2.4:nControlCode为1003,则是外设芯片从PowerOff状态回复正常。
步骤3:调用系统方法DzRegisterService发布驱动接口,即DzRegisterService(wszDriverServiceName, (IDriver *)pDriver)。
代理对象
一个代理对象具有如下的结构:
class CVirtualDevice : public Driver {
public:
CARAPI Read(
/* [in] */ UINT64 u64Offset,
/* [in] */ UINT uNumberOfBytesToRead,
/* [out] */ EzByteBuf ebbData,
/* [out] */ IEvent * * ppCompletionEvent);
CARAPI Write(
/* [in] */ UINT64 u64Offset,
/* [in] */ EzByteBuf ebbData,
/* [out] */ UINT * puNumberOfBytesWritten,
/* [out] */ IEvent * * ppCompletionEvent);
CARAPI Control(
/* [in] */ INT nControlCode,
/* [in] */ EzByteBuf ebbInData,
/* [out] */ EzByteBuf ebbOutData,
/* [out] */ IEvent * * ppCompletionEvent);
virtual void Dispose() {}
public:
CVirtualDevice( IObject * pObject,
unsigned long InitPowerState,
BOOL IgnoreTimer=false,
BOOL IgnoreControl=false
);
CVirtualDevice( UINT DeviceID,IObject * pObject);
void InitDevPowerMode(ULONG mode);//rename this api later.
void KeepSpecifiedMode(ULONG mode,BOOL KeepOn);//disable timer policy
void SetChangeModeInterval(ULONG interval);
ECODE ChangeMode(DeviceMode mode);
ECODE ChangeMode();
ECODE SetMode(ULONG mode);
ECODE SetPowerMode(ULONG mode);
void UpdateInputLastUse();//event handler
void RestartTimer();
void RestartTimer(int Interval);
ULONG GetLeftInterval();
ECODE ChangeModeByStep();
void SetChangeModeCallBack(TimerCallBackProc proc);
unsigned long PowerState;//tag
int hTimer;//timer handle
BOOL KeepOn;//disable timer policyc
BOOL IgnoreControl;//ignore Control call
BOOL IgnoreRead;//ignore Read call
BOOL IgnoreTimer;// suspend device will not stop timer.
TimerCallBackProc ChangeModeCallBack;
unsigned long ModeChangeInterval;//interval between mode change
private:
IDriver * piRealdev; //Physical Object
int DeviceID;
unsigned long SpecifiedMode;// default power mode of Proxy Object
};
PowerState有如下几个状态:
DevicePowerOff、DeviceSuspend、DeviceVeryLowPower、DeviceLowPower、DevicePowerOn。
步骤1:等待客户端对驱动接口的请求。
步骤2:根据PowerState判断代理对象的电源管理状态是否合适响应此RWC请求,一般而言,如果PowerState是PowerOn状态,则认为可以响应,否则不可以。但驱动程序可以通过IgnoreControl等标志设定哪些调用可以忽略。
步骤3:可以响应,转发RWC请求。否则转步骤9。
步骤4:RWC请求完成,判断代理对象的电源管理状态是否需要向功耗更低方向调整。一般而言,如果PowerState不是PowerOff状态,则认为需要向下调整。
步骤5:需要调整,则调用RestartTimer()函数启动定时策略。不需要调整,回步骤1。
步骤6:新的请求到达,回步骤2。
步骤7:定时到达,调用SetMode函数给驱动对象发送Power_Request(1000号或者1002号控制字),请求调低功耗。如果成功,更改自身电源管理状态。
步骤8:停止定时策略。回步骤1。
步骤9:调用SetMode函数给驱动对象发送Power_Request(1001号或者1003号控制字,视当前PowerState而定),请求调高功耗。如果成功,更改自身电源管理状态,转步骤2。如果失败,回步骤1。
程序
步骤1:驱动对象使用DzRegisterService注册接口时,截获其调用,方法是注册回调函数。此函数被调用时回调函数也被回调。
步骤2:判断对象是否需要代理:一般而言,只有物理的,具体的外设驱动需要被代理,而与功耗无涉的驱动程序,伪驱动程序(即实现IDriver接口,以提供某些特殊服务)则不需要。
步骤3:DzRegisterService函数的参数在回调发生时被带回,包括驱动对象接口和驱动对象名,则调用CProxyDevice的构造函数创建代理对象,然后调用DzRegisterService注册代理对象,即接口指正换成代理对象的,而名字仍使用约定名,以此实现代理。
步骤4:初始化代理对象,包括初始电源管理状态,定时器定时间隔等,直接使用代理对象指针即可完成。
步骤5:接受用户请求,事件通知,根据所掌握的代理对象处理或者转发,比如锁屏事件,按键事件,触屏事件需要相应调用CPU和LCD的代理对象处理。
应用程序
步骤1:查找系统服务,通过EzFindService带约定服务名找到驱动接口指针。
此步骤与DPM程序的步骤3即实现了驱动对象的代理。此时应用程序使用的接口实质上驱动对象的代理对象。
步骤2:使用系统服务。此步骤和未使用基于代理的电源管理技术时没有任何差别,此处不再详述。
由于本发明的方法中使用了代理机制,拦截对驱动对象的接口访问并结合事件通知,整体上监控了驱动对象的使用情况,可以自动记录设备的功耗状态,自动切换设备的功耗状态,使设备对使用者而言始终可用,对系统而言随时自动关闭,对驱动开发人员而言减少设备状态维护的麻烦而仅仅需要响应特定的电源管理请求,对应用开发人员而言减少查询设备电源状态的麻烦而仅仅需要实现特定的业务逻辑。
总之,对最终用户而言,由于驱动对象会被代理对象及时关闭电源,所以节省了不必要的电源,延长了待机时间,对应用和驱动开发人员而言,由于只关心设备本身业务逻辑而非系统电源管理状态,提高了开发效率。
对于后一点,作为本发明的主要贡献,不难理解,因代理对象的使用对其使用者是透明的,电源管理的引入对应用开发者无任何额外要求,对驱动开发者仅仅多了几个必要的请求。对于前一点,提升功耗表现和不损性能则并非显而易见,以下以图表说明。
再请参阅图5所示,其中描述了在物联网终端设备(监控设备)的典型应用场景下,本发明的方案的一种实现和现有技术中的Windows CE方案的功耗对比,图中“ ”为本发明的方案的功耗柱状图,“ ”为Windows CE方案的功耗柱状图;这里硬件方案均使用基于Marvell PXA270(应用处理器)+Broadcom BCM2121(通讯处理器)的双CPU架构,测试仪器使用Agilent高精度电源。
结论:本方案在所有场合下都略有胜出,说明,由于驱动对象会被代理对象及时关闭电源,本方案在功耗提升方面是有效的。
再请参阅图6所示,其中描述了使用代理机制和不使用代理机制下某些典型应用所耗用的CPU时间,也即性能表现,图中“ ”为本发明使用代理机制的方案的CPU时间的柱状图,“ ”为不使用代理机制的方案的CPU时间的柱状图。我们使用CPU使用率衡量性能,即使用同一应用同一场景在不同情况下对CPU的耗用情况来判断性能损耗情况。可以看出,在引入代理机制后,CPU的使用率略有下降,但下降幅度非常小,可以接受。
结论:本方案以一定的性能损耗带来开发效率的提升和功耗的节约,是可行的。
采用了上述的物联网终端设备(监控设备)上基于代理机制的动态电源管理方法,由于其中使用了代理机制,从而拦截了对驱动对象的接口访问并结合事件通知,整体上监控了驱动对象的使用情况,并可以自动记录设备的功耗状态,自动切换设备的功耗状态,使设备对使用者来说始终可用,对系统来说则随时可以自动关闭,并使得驱动程序开发人员减少了设备状态维护的麻烦,而仅仅需要响应特定的电源管理请求,使得应用程序开发人员减少了查询设备电源状态的麻烦,仅仅需要实现特定的业务逻辑,从而提高了系统开发效率;同时由于驱动对象会被代理对象及时关闭电源,所以节省了不必要的电源,延长了待机时间,在不损失性能的前提下尽可能优化系统的功耗,而且系统工作性能稳定可靠,适用范围较为广泛,给人们的工作和生活都带来了很大的便利。
在此说明书中,本发明已参照其特定的实施例作了描述。但是,很显然仍可以作出各种修改和变换而不背离本发明的精神和范围。因此,说明书和附图应被认为是说明性的而非限制性的。
Claims (9)
1.一种物联网终端设备(监控设备),其特征在于,该物联网终端设备(监控设备)基于代理机制进行电源的动态管理,该物联网终端设备(监控设备)包括:
存储装置,用于存储一操作系统及电源动态管理程序;
中央处理器,用于在运行该操作系统后,读取并执行该电源动态管理程序以执行以下步骤:
a、为需要代理的驱动对象创建并注册对应的代理对象,以根据代理对象为对应的驱动对象进行代理;
b、通过代理对象监控并拦截向对应的驱动对象发起的功耗请求事件;
c、判断代理对象的电源管理状态是否合适以响应该功耗请求事件;
d、若代理对象的电源管理状态合适,则向对应的驱动对象发送该功耗请求事件,在对应的驱动对象响应完该功耗请求事件后转到下述步骤e,或者,若代理对象的电源管理状态不合适,则转到下述步骤f;
e、进行功耗调低:在需要将功耗调低时,向对应的驱动对象发送功耗调低请求,在功耗调低请求发送成功的情况下更改代理对象自身的电源管理状态,随后转到上述步骤b,或者,在不需要将功耗调低时,直接转到上述步骤b;及
f、进行功耗调高:向对应的驱动对象发送功耗调高请求,在功耗调高请求发送成功时更改代理对象自身的电源管理状态,随后转到上述步骤c,或者,在功耗调高请求发送失败时,转到上述步骤b。
2.如权利要求1所述的物联网终端设备(监控设备),其特征在于,所述步骤e包括:
e1、在对应的驱动对象响应完该功耗请求事件后,判断代理对象的电源管理状态是否需要向功耗更低的方向调整;
e2、若需要调整,则启动定时器,或者,若不需要调整,则转到上述步骤b;及
e3、若有新的功耗请求事件在定时器计时过程中向对应的驱动对象发起时,则转到上述步骤c,或者,若没有新的功耗请求事件在定时器计时过程中向对应的驱动对象发起,则在预定的时间到达时,向对应的驱动对象发送功耗调低请求,在功耗调低请求发送成功的情况下更改代理对象自身的电源管理状态,随后转到上述步骤b。
3.如权利要求1所述的物联网终端设备(监控设备),其特征在于,所述电源动态管理程序属于所述操作系统的一部份。
4.如权利要求1所述的物联网终端设备(监控设备),其特征在于,所述驱动对象指的是该物联网终端设备(监控设备)的驱动程序。
5.如权利要求4所述的物联网终端设备(监控设备),其特征在于,所述需要代理的驱动对象指的是该物联网终端设备(监控设备)的涉及功耗的驱动程序。
6.如权利要求1至5中任一项所述的物联网终端设备(监控设备),其特征在于,所述功耗请求事件包括读或写数据事件、控制请求事件、用户通知事件、操作系统的线程调度事件或者用户的锁屏或解锁通知事件。
7.一种电源动态管理方法,适用于物联网终端设备(监控设备),其特征在于,该方法采用代理机制对物联网终端设备(监控设备)进行电源动态管理,该物联网终端设备(监控设备)安装有操作系统和电源动态管理程序,该方法包括步骤:
运行该操作系统;
读取并执行该电源动态管理程序以执行以下步骤:
a、为需要代理的驱动对象创建并注册对应的代理对象,以根据代理对象为对应的驱动对象进行代理;
b、通过代理对象监控并拦截向对应的驱动对象发起的功耗请求事件;
c、判断代理对象的电源管理状态是否合适以响应该功耗请求事件;
d、若代理对象的电源管理状态合适,则向对应的驱动对象发送该功耗请求事件,在对应的驱动对象响应完该功耗请求事件后转到下述步骤e,或者,若代理对象的电源管理状态不合适,则转到下述步骤f;
e、进行功耗调低:在需要将功耗调低时,向对应的驱动对象发送功耗调低请求,在功耗调低请求发送成功的情况下更改代理对象自身的电源管理状态,随后转到上述步骤b,或者,在不需要将功耗调低时,直接转到上述步骤b;及
f、进行功耗调高:向对应的驱动对象发送功耗调高请求,在功耗调高请求发送成功时更改代理对象自身的电源管理状态,随后转到上述步骤c,或者,在功耗调高请求发送失败时,转到上述步骤b。
8.如权利要求7所述的电源动态管理方法,其特征在于,所述步骤e包括:
e1、在对应的驱动对象响应完该功耗请求事件后,判断代理对象的电源管理状态是否需要向功耗更低的方向调整;
e2、若需要调整,则启动定时器,或者,若不需要调整,则转到上述步骤b;及
e3、若有新的功耗请求事件在定时器计时过程中向对应的驱动对象发起时,则转到上述步骤c,或者,若没有新的功耗请求事件在定时器计时过程中向对应的驱动对象发起,则在预定的时间到达时,向对应的驱动对象发送功耗调低请求,在功耗调低请求发送成功的情况下更改代理对象自身的电源管理状态,随后转到上述步骤b。
9.如权利要求7至11中任一项所述的电源动态管理方法,其特征在于,所述功耗请求事件包括读或写数据事件、控制请求事件、用户通知事件、操作系统的线程调度事件或者用户的锁屏或解锁通知事件。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2011101236639A CN102780727A (zh) | 2011-05-13 | 2011-05-13 | 一种物联网终端设备的动态电源管理方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2011101236639A CN102780727A (zh) | 2011-05-13 | 2011-05-13 | 一种物联网终端设备的动态电源管理方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN102780727A true CN102780727A (zh) | 2012-11-14 |
Family
ID=47125480
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2011101236639A Pending CN102780727A (zh) | 2011-05-13 | 2011-05-13 | 一种物联网终端设备的动态电源管理方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102780727A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105893092A (zh) * | 2016-04-01 | 2016-08-24 | 腾讯科技(深圳)有限公司 | Com组件处理方法和装置 |
CN114827118A (zh) * | 2022-04-18 | 2022-07-29 | 恩平市帝赛斯音响器材厂 | 一种基于互联网的网络电源远程管理系统 |
-
2011
- 2011-05-13 CN CN2011101236639A patent/CN102780727A/zh active Pending
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105893092A (zh) * | 2016-04-01 | 2016-08-24 | 腾讯科技(深圳)有限公司 | Com组件处理方法和装置 |
CN105893092B (zh) * | 2016-04-01 | 2021-02-12 | 腾讯科技(深圳)有限公司 | Com组件处理方法和装置 |
CN114827118A (zh) * | 2022-04-18 | 2022-07-29 | 恩平市帝赛斯音响器材厂 | 一种基于互联网的网络电源远程管理系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105205766B (zh) | 基于云平台的移动互联网医院就诊系统 | |
US20100077063A1 (en) | System and method for emulating a computing device | |
US9395786B2 (en) | Cross-layer power management in a multi-layer system | |
US7272730B1 (en) | Application-driven method and apparatus for limiting power consumption in a processor-controlled hardware platform | |
TWI549001B (zh) | 基於背景資訊之功率及負載管理 | |
US20140136829A1 (en) | Method, Network Card, and Hard Disk Card for Accessing Shut-Down Hard Disk | |
CN105187512A (zh) | 一种虚拟机集群负载均衡方法及系统 | |
AU2008317006A1 (en) | Systems and methods to adaptively load balance user sessions to reduce energy consumption | |
CN106059835B (zh) | 一种低能耗计算机集群节点的高可靠性控制方法 | |
CN102460393A (zh) | 用于在虚拟存储资源之间建立云桥的系统和方法 | |
KR20090060700A (ko) | 네트워크 프로토콜 기반의 소비전력 절감형 홈게이트웨이및 그 제어 방법 | |
WO2013063972A1 (zh) | 一种通信方法、通信装置及电子设备 | |
CN104471523A (zh) | 计算机系统及其控制方法 | |
WO2015123225A1 (en) | Aggregating memory to create a network addressible storage volume for storing virtual machine files | |
WO2023046141A1 (zh) | 一种数据库网络负载性能的加速框架、加速方法及设备 | |
US20090327775A1 (en) | User imposed power constraints on web server based on user preferences | |
TWI311414B (zh) | ||
Li et al. | More than capacity: Performance-oriented evolution of pangu in alibaba | |
CN101661325B (zh) | 一种移动设备的电源动态管理方法 | |
CN102780727A (zh) | 一种物联网终端设备的动态电源管理方法 | |
CN102902593A (zh) | 基于缓存机制的协议分发处理系统 | |
Ren et al. | Phantasy: Low-latency virtualization-based fault tolerance via asynchronous prefetching | |
US20220334906A1 (en) | Multimodal user experience degradation detection | |
CN1619467A (zh) | 计算机系统及电源管理状态切换方法 | |
EP2083537B1 (en) | Data network and method of controlling thereof |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20121114 |