一种基于串口通信的程序更新方法和系统

1.本技术涉及物联网程序更新技术领域，尤其涉及一种基于串口通信的程序更新方法和系统。


背景技术：

2.随着物联网技术的发展以及应用场景的不断更新，传统嵌入式linux应用程序或驱动模块经编译后，往往需借助外部工具软件如filezilla等通过局域网通信方式实现程序端的更新，这种更新方式仅适用于短距离、有网络、小范围且弱干扰的环境，嵌入式开发平台亟需融入新的程序更新方式以适应多样化场景下的程序更新需求。


技术实现要素：

3.有鉴于此，本技术的目的在于提出一种基于串口通信的程序更新方法和系统，本技术能够针对性的解决现有的问题。
4.基于上述目的，本技术提出了一种基于串口通信的程序更新方法，包括：
5.串口更新模块搜寻待更新的目标设备，若搜寻成功，则存储当前串口信息，等待握手；否则直接退出；
6.串口更新模块发起握手请求，若握手成功，则将所有待更新数据进行组帧；否则检查设备连接情况并返回上一步骤；
7.程序更新开始，串口更新模块开始下发更新数据；
8.对接收的更新数据进行循环冗余校验，若校验失败，请求串口更新模块重发当前帧数据；如果校验成功，则判断当前更新数据是否为最后一帧，若不是，写入指定位置并修改当前帧接收状态；否则执行下一步骤；
9.遍历帧接收状态数组，检查数组元素是否全部置位，若未全部置位，找出未置位的元素位置，上传信息请求串口更新模块补发丢帧数据；否则调用已封装的控制台运行函数，运行更新映像。
10.进一步地，所述帧接收状态数组是一个长度为64字节的全局变量，在程序更新开始前将其初始化为0，在每次接收并写入一帧真实的更新数据后，将数组元素中的某一位置1，共可表示512个帧接收状态，在运行更新映像前遍历该数组即可获得整个更新过程的丢帧情况。
11.进一步地，在所述串口更新模块搜寻待更新的目标设备之前，进一步包括：
12.在终端上电启动后加载一个与主机通信的主程序，所述主程序包含程序更新所需全部信息。
13.进一步地，所述将所有待更新数据进行组帧，包括以下中的一种或多种：更新握手帧、更新准备帧、更新开始帧、更新可执行帧、更新驱动帧、更新设备树帧、更新检查帧、更新命令帧、更新返回帧。
14.进一步地，在所述串口更新模块开始下发更新数据之后，进一步包括：
15.终端在每次接收到串口更新模块下发的更新数据或命令后，执行对应的空间开辟、数据写入和命令运行操作，随后将最终的数据处理或命令执行情况以更新返回帧的形态反馈给串口更新模块；
16.收到反馈信息的串口更新模块提取更新返回帧的返回状态这一字段数据，以此判断更新数据或命令在终端是否正确写入或执行，返回状态为0表示数据写入成功，可进行下一帧数据或命令的更新；否则，表示当前帧数据更新失败，需重新下发当前更新数据。
17.进一步地，所述对接收的更新数据进行循环冗余校验，包括：
18.终端在接收到更新数据后，按照约定数据帧结构对所述更新数据进行解析；
19.计算当前帧数据的crc校验码并与接收数据帧的crc校验码进行对比，若一致，则表示接收无误；否则，收集错误信息并上传返回状态字段值为1的更新返回帧数据，请求更新模块重发当前帧数据。
20.进一步地，所述串口更新模块发起握手请求，包括：
21.串口更新模块按照约定数据帧结构发送握手帧信息，收到握手请求的终端上传携带mpu型号、通信模组类型及版本号的握手帧数据，由串口更新模块对所述握手帧数据进行解析与存储。
22.基于上述目的，本技术还提出了一种基于串口通信的程序更新系统，包括：
23.搜索单元，用于搜寻待更新的目标设备，若搜寻成功，则存储当前串口信息，等待握手；否则直接退出；
24.握手单元，用于发起握手请求，若握手成功，则将所有待更新数据进行组帧；否则检查设备连接情况并返回上一步骤；
25.数据下发单元，用于在程序更新开始后下发更新数据；
26.校验单元，用于对接收的更新数据进行crc校验，若校验失败，请求串口更新模块重发当前帧数据；如果校验成功，则判断当前更新数据是否为最后一帧，若不是，写入指定位置并修改当前帧接收状态；否则执行下一步骤；
27.置位检查单元，用于遍历帧接收状态数组，检查数组元素是否全部置位，若未全部置位，找出未置位的元素位置，上传信息请求串口更新模块补发丢帧数据；否则调用已封装的控制台运行函数，运行更新映像。
28.总的来说，本技术的优势及给用户带来的体验在于：相较于传统通过局域网实现更新映像写入的程序更新方法，利用串口写入的方式不仅不占用额外的mpu硬件资源，还可有效弥补程序在无网络情况下无法更新的劣势。
附图说明
29.在附图中，除非另外规定，否则贯穿多个附图相同的附图标记表示相同或相似的部件或元素。这些附图不一定是按照比例绘制的。应该理解，这些附图仅描绘了根据本技术公开的一些实施方式，而不应将其视为是对本技术范围的限制。
30.图1示出本技术的丢帧及错帧重传流程图。
31.图2示出串口握手成功界面示意图。
32.图3示出根据本技术实施例的基于串口通信的程序更新方法的流程图。
33.图4示出根据本技术实施例的串口更新成功后的软件界面示意图。
34.图5示出根据本技术实施例的基于串口通信的程序更新系统的构成图。
35.图6示出了本技术一实施例所提供的一种电子设备的结构示意图；
36.图7示出了本技术一实施例所提供的一种存储介质的示意图。
具体实施方式
37.下面结合附图和实施例对本技术作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。
38.需要说明的是，在不冲突的情况下，本技术中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本技术。
39.串口作为处理器或微控制器中常用外设接口之一，具有通信简单、速度稳定且安全可靠等特点，利用串口有线地进行程序端的更新，不仅能弥补主机编译生成的目标文件在无网络情况下无法下发至终端更新运行的缺陷，同时也可简化程序下载这一过程。对此，本技术将在分析、提取程序更新共性技术的基础上，实现基于串口通信的程序更新方案。
40.1程序更新共性技术分析
41.对于嵌入式终端而言，不论是串口更新、5g nr远程更新亦或是借助外围软件进行程序更新的方式，其最终都是将主机编译生成的可执行文件或驱动程序等更新映像文件写入终端更新运行。因此，本技术中程序更新涉及的共性技术主要有：update固化自启机制、通用更新帧结构设计、通信保护机制等。
42.1.1update固化自启机制
43.无论是串口更新还是远程更新，都需事先在终端上电启动后的瞬间加载一个与主机通信的主程序，才能完成程序间更新运行，在本技术中则为主机编译生成的可执行文件update，通过加入对应启动规则并将其固化在终端，由终端在每次上电启动时加载该主程序，从而引导整个程序更新作业的顺利进行，该程序包含程序更新所需全部信息，通常不允许轻易修改。
44.以stm32mp157芯片例，其自启服务关键内容如代码(a)所示，unit表示启动依赖单元，真正启动行为发生在service块中，此处表示内核启动服务myd-ya157c启动后再启动通信主程序服务update，而该通信主程序服务对应的启动脚本autostart.sh如代码(b)所示。
[0045][0046]
通信主程序update源工程框架及其文件说明如表1所示，该框架成功编译后会生成一个名为“update”的可执行文件，为后续将阐述的串口更新提供通信服务。在update工程框架中，emuart构件主要是为串口通信操作而设计，包含待更新串口的初始化、更新数据的组帧与解析等操作；uecom构件则是专门为5g远程数据通信而设计，主要涉及到5g通信模组初始化、网络信息注册等操作；ueupdate则是真正的程序更新操作构件，本技术实现的串
口更新需依赖此构件才能进行，该构件主要负责更新数据的分析、更新命令的执行、更新结果信息的反馈以及更新映像文件的运行等操作。emuart、uecom和ueupdate为其他应用构件。
[0047]
表1update工程框架及相关文件说明
[0048][0049]
1.2通用更新帧结构设计
[0050]
为确保程序更新过程中数据传输的正确性，就需事先对待更新数据进行特殊化“处理”，并予以一定的通信机制进行约束。从终端更新所需的不同操作角度划分，可设计如下几种通用更新数据帧结构。
[0051]
(1)更新握手帧。为实现待更新数据的硬件无关性及终端可选的程序更新方式，就需在终端上电后提供部分必要信息供更新模块决策判断，包括终端mpu型号、通信模组类型及软件版本，帧格式如表2所示。
[0052]
表2更新握手帧格式
[0053][0054]
(2)更新准备帧。在程序更新前，需先指定更新映像要在终端设备的运行位置，应包含工程名和当前帧号等信息，帧格式如表3所示。
[0055]
表3更新准备帧格式
[0056][0057]
(3)更新开始帧。完成更新映像运行空间开辟后，更新模块还需向指定终端下发更新开始提示，告知终端此次更新类型、更新总帧数和更新程序数量等信息，帧格式如表4所示。更新开始帧的帧标识是1；共有三种更新类型可选择：0表示只更新可执行文件，1表示更
新可执行文件和驱动程序，2表示更新可执行文件、驱动程序及设备树文件；当前帧号用于记录当前更新进度，在更新过程若发现某帧数据丢失，可告知更新模块丢帧的帧号进行重传；总帧数表示程序更新需操作的所有数据帧个数；更新程序数量表示当前更新映像文件的总和；更新映像名数组记录当前更新操作的所有目标文件名称。
[0058]
表4更新开始帧格式
[0059][0060]
(4)更新可执行帧、更新驱动帧、更新设备树帧。完成程序更新前期工作后，就要将正式数据下发至终端更新运行，由于可执行文件、驱动程序和设备树文件三者在终端的运行方式不同，因此对其分别设计了类似的帧格式，帧格式如表5所示。三种帧结构对应的帧标识分别为2、3、4；由于同一时刻可能会存在更新多个同类型的文件数据，设立文件层的方式有助于更好地确定同类型下更新文件的写入位置；当前帧号表示更新操作的进度；更新代码大小记录此帧更新数据大小，最大为1024字节；更新数据则为实际要写入终端设备的数据。
[0061]
表5更新可执行帧、更新驱动帧、更新设备树帧格式
[0062][0063]
(5)更新检查帧。在更新操作完成即将运行更新映像前，需对更新数据进行一次完整的正确性检查。若更新中途出现丢帧现象，则需告知更新模块丢帧帧号以完成丢帧重传操作，帧格式如表6所示。更新检查帧是每次程序更新都要校验的一种帧格式，帧标识为5；当前帧号表示当前更新进度；丢失帧数表示此次程序更新丢帧的个数，丢帧个数默认最多40个；丢失帧号记录了当前更新操作丢失的所有帧号，每两个字节记录一个帧号。
[0064]
表6更新检查帧格式
[0065][0066]
(6)更新命令帧。更新数据正确下发至终端并经更新校验成功后，便可进行更新运行操作，该操作命令由更新模块发布，帧格式如表7所示。更新命令帧表示整个更新操作完成，帧标识为6；当前帧号记录更新操作进度。
[0067]
表7更新命令帧格式
[0068][0069]
(7)更新返回帧。为确保整个更新过程其数据的完整性、正确性，就需在终端每次接收到更新数据后回发一个确认信息供上位机抉择是否进行下一帧数据的发送操作，帧格式如表8所示。整个程序更新过程都需更新返回帧实现更新模块和终端数据的间歇性交互，帧标识为7；当前帧号记录当前更新操作进度；返回状态字段用于提示更新模块每帧更新数据到达终端后的执行状态：0表示成功，其他则为失败。
[0070]
表8更新返回帧格式
[0071][0072]
1.3通信保护机制
[0073]
在程序更新流程中，良好的数据传输规则或应急措施可有效避免更新数据在传输过程中因终端异常等而导致程序更新失败。对此，本技术引入应答机制和丢帧、错帧重传机制，以此确保整个程序更新作业的正常进行。
[0074]
1.应答机制
[0075]
作为程序更新稳定执行的基础，应答机制是指更新模块与终端进行数据交互过程中，终端在收到更新模块下发的更新数据或命令后会反馈一个经处理后的应答信号，以此告知更新模块本次更新数据写入或命令执行情况。在本技术实现的程序更新方案中，应答机制是通过更新返回帧数据来完成，终端在每次接收到更新模块下发的更新数据或命令后，会执行对应的空间开辟、数据写入和命令运行等操作，随后便将最终的数据处理或命令执行情况以更新返回帧的形态反馈给更新模块，收到反馈信息的更新模块会自动提取更新返回帧的返回状态这一字段数据，以此判断更新数据或命令在终端是否正确写入或执行，返回状态为0表示数据写入成功，可进行下一帧数据或命令的更新；否则，表示当前帧数据更新失败，需重新下发当前更新数据。
[0076]
2.丢帧及错帧重传机制
[0077]
丢帧及错帧重传是程序更新的第二层保护机制，是指更新过程中可能因终端异常或其他因素导致当前更新数据丢失或接收异常。当重传机制检测到有丢帧或错帧现象，便会将错误信息收集并上传至更新模块，由更新模块根据提示信息重发这些更新数据帧完成更新，以此确保整个更新进度的可靠性及正确性。其执行流程图如图1所示。
[0078]
验证当前接收的更新数据帧是否正确则是通过循环冗余校验(cyclic redundancy check，crc)机制来实现，终端在接收到更新数据后，会按照约定数据帧结构对其进行解析，紧接着计算当前帧数据的crc校验码并与接收数据帧的crc校验码进行对比，若一致，则表示接收无误；否则，收集错误信息并上传返回状态字段值为1的更新返回帧数据，请求更新模块重发当前帧数据。
[0079]
而对于程序更新是否丢帧的判断，则需在更新数据全部接收完、更新命令执行前进行，终端会在每次运行更新映像前对接收的所有更新数据帧进行一次整体校验操作。若校验结果出现丢帧，则将丢失帧的帧号信息反馈给更新模块，由更新模块重发所有丢失的数据帧，终端收到补发数据后会再次进行校验操作，直至全部更新数据帧都校验通过后才会运行最终的更新映像。
[0080]
2基于串口通信的程序更新技术
[0081]
2.1串口通信协议设计
[0082]
鉴于数据通信本身的不稳定性以及终端自身所处环境的复杂性，为防止更新数据传输异常，确保整个更新流程顺畅执行，对此，本技术为程序更新方案设计了一种高效、可靠的更新数据传输帧格式。其帧格式如表9所示。
[0083]
表9串口通信数据帧协议
[0084][0085]
数据帧格式中的emuartframehead和emuartframetail字段分别表示当前帧数据更新正式开始和结束；而当前帧数据的长度用length表示；cmd表示当前帧数据传输的目的，是一种可扩展的命令字段；data为终端需真正写入或运行的数据，包括可执行文件、驱动程序或设备文件数据；crc字段则表示length、cmd和data三者的crc校验和，依据该校验码的比对结果以验证当前帧数据的正确性及完整性。
[0086]
2.2串口握手机制
[0087]
串口握手前更新模块需主动寻找、连接终端设备，本技术设计了终端自动搜寻规则：程序更新前，串口更新模块先遍历所有已打开的端口，向其发送指定信息(本技术利用字符串“[are you an emuart？？]”)搜寻设备，终端在连接就绪的情况下，收到串口更新模块的连接请求后，会通过更新数据帧返回一个应答信息(本技术利用字符串“[yes,i am an emuart！！]”)。串口更新模块收到应答信号会自动存储此刻与终端通信的端口，紧接着会按照约定数据帧结构发送握手帧信息(本技术利用字符串“shake”)，收到握手请求的终端会自动上传携带mpu型号、通信模组类型及版本号的握手帧数据，由串口更新模块对其进行解析与存储。串口成功握手后的界面如图2所示。图中，5gdc-edp(特指本技术所使用的嵌入式开发平台的名称，5g数据通信嵌入式开发平台(5g data communication embedded development platform，5gdc-edp)，5gdc-edp本身是一款基于c#语言编写、需运行在windows系统的图形化软件)。
[0088]
串口更新模块在成功获取到终端设备的相关信息后，便会对当前更新映像实行规则制约与检查操作，如对更新映像数据在终端开始写入位置等重要信息的检查，避免用户因操作失误(如更新映像选用出错)而导致的程序开发风险。
[0089]
2.3串口更新流程
[0090]
待更新程序经编译后会生成一个名为“main”的可执行文件，串口更新界面打开后默认选中该目标文件需要更新，相应地，用户也可选择是否更新驱动程序或设备树文件。update程序作为系统程序更新的重要支撑，承载着程序更新业务逻辑所需的全部信息，在与串口更新模块有机融合下完成更新数据间歇性交互、信号应答等操作。本技术的串口更新实现步骤如下：
[0091]
(1)串口更新模块搜寻待更新的目标设备。若搜寻成功，则存储当前串口信息，等待握手；否则直接退出。
[0092]
(2)串口更新模块发起握手请求。若握手成功，则将所有待更新数据进行组帧；否则检查设备连接情况并返回(1)。
[0093]
(3)程序更新开始，串口更新模块开始下发更新数据。
[0094]
(4)终端软件对接收的更新数据进行crc校验。若校验失败，请求串口更新模块重
发当前帧数据；校验成功，则判断当前更新数据是否为最后一帧，若不是，写入指定位置并修改当前帧接收状态；否则执行(5)。
[0095]
(5)遍历帧接收状态数组，检查数组元素是否全部置位。若未全部置位，找出未置位的元素位置，上传信息请求串口更新模块补发丢帧数据；否则调用已封装的控制台运行函数，运行更新映像。至此，串口更新过程完成。
[0096]
其中，帧接收状态数组是一个长度为64字节的全局变量，在程序更新开始前会将其初始化为0，终端在每次接收并写入一帧真实的更新数据后就会将数组元素中的某一位置1，共可表示512个帧接收状态，在运行更新映像前遍历该数组即可获得整个更新过程的丢帧情况。串口更新实现的具体流程如图3所示。
[0097]
图4展示了串口更新成功后的软件界面。
[0098]
为测试本技术提出的串口更新方案性能状况，本技术在同等条件下，对比串口更新与基于文件传输协议(file transfer protocol，ftp)的filezilla工具软件的更新成功率及平均耗时。实验共分为3组，以stm32mp157为待更新平台，在更新文件数据总大小为52kb、83kb和126kb的条件下，分别对其进行200次的程序更新操作，其串口更新结果统计如表10所示。
[0099]
表10串口更新方案与借助filezilla软件更新对比
[0100][0101]
由表可知，本技术实现的串口更新方案相较于借助filezilla软件更新方案具有较高的耗时性，但在平均耗时相仿的前提下，串口更新方案拥有更好的稳定性，且基本不受更新文件数据总大小的影响，不仅可以弥补程序在无网络情况下无法更新的短板，又完全能满足系统开发的程序更新需求。
[0102]
申请实施例提供了一种基于串口通信的程序更新系统，该系统用于执行上述实施例所述的基于串口通信的程序更新方法，如图5所示，该系统包括：
[0103]
搜索单元501，用于搜寻待更新的目标设备，若搜寻成功，则存储当前串口信息，等待握手；否则直接退出；
[0104]
握手单元502，用于发起握手请求，若握手成功，则将所有待更新数据进行组帧；否则检查设备连接情况并返回上一步骤；
[0105]
数据下发单元503，用于在程序更新开始后下发更新数据；
[0106]
校验单元504，用于对接收的更新数据进行crc校验，若校验失败，请求串口更新模块重发当前帧数据；如果校验成功，则判断当前更新数据是否为最后一帧，若不是，写入指定位置并修改当前帧接收状态；否则执行下一步骤；
[0107]
置位检查单元505，用于遍历帧接收状态数组，检查数组元素是否全部置位，若未全部置位，找出未置位的元素位置，上传信息请求串口更新模块补发丢帧数据；否则调用已
封装的控制台运行函数，运行更新映像。
[0108]
本技术的上述实施例提供的基于串口通信的程序更新系统与本技术实施例提供的基于串口通信的程序更新方法出于相同的发明构思，具有与其存储的应用程序所采用、运行或实现的方法相同的有益效果。
[0109]
本技术实施方式还提供一种与前述实施方式所提供的基于串口通信的程序更新方法对应的电子设备，以执行上基于串口通信的程序更新方法。本技术实施例不做限定。
[0110]
请参考图6，其示出了本技术的一些实施方式所提供的一种电子设备的示意图。如图6所示，所述电子设备20包括：处理器200，存储器201，总线202和通信接口203，所述处理器200、通信接口203和存储器201通过总线202连接；所述存储器201中存储有可在所述处理器200上运行的计算机程序，所述处理器200运行所述计算机程序时执行本技术前述任一实施方式所提供的基于串口通信的程序更新方法。
[0111]
其中，存储器201可能包含高速随机存取存储器(ram：random access memory)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。通过至少一个通信接口203(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网、广域网、本地网、城域网等。
[0112]
总线202可以是isa总线、pci总线或eisa总线等。所述总线可以分为地址总线、数据总线、控制总线等。其中，存储器201用于存储程序，所述处理器200在接收到执行指令后，执行所述程序，前述本技术实施例任一实施方式揭示的所述基于串口通信的程序更新方法可以应用于处理器200中，或者由处理器200实现。
[0113]
处理器200可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器200中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器200可以是通用处理器，包括中央处理器(central processing unit，简称cpu)、网络处理器(network processor，简称np)等；还可以是数字信号处理器(dsp)、专用集成电路(asic)、现成可编程门阵列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本技术实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本技术实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器201，处理器200读取存储器201中的信息，结合其硬件完成上述方法的步骤。
[0114]
本技术实施例提供的电子设备与本技术实施例提供的基于串口通信的程序更新方法出于相同的发明构思，具有与其采用、运行或实现的方法相同的有益效果。
[0115]
本技术实施方式还提供一种与前述实施方式所提供的基于串口通信的程序更新方法对应的计算机可读存储介质，请参考图7，其示出的计算机可读存储介质为光盘30，其上存储有计算机程序(即程序产品)，所述计算机程序在被处理器运行时，会执行前述任意实施方式所提供的基于串口通信的程序更新方法。
[0116]
需要说明的是，所述计算机可读存储介质的例子还可以包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存
储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他光学、磁性存储介质，在此不再一一赘述。
[0117]
本技术的上述实施例提供的计算机可读存储介质与本技术实施例提供的基于串口通信的程序更新方法出于相同的发明构思，具有与其存储的应用程序所采用、运行或实现的方法相同的有益效果。
[0118]
需要说明的是：
[0119]
在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备有固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本技术也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本技术的内容，并且上面对特定语言所做的描述是为了披露本技术的最佳实施方式。
[0120]
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本技术的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
[0121]
类似地，应当理解，为了精简本技术并帮助理解各个发明方面中的一个或多个，在上面对本技术的示例性实施例的描述中，本技术的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本技术要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本技术的单独实施例。
[0122]
本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
[0123]
此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本技术的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
[0124]
本技术的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(dsp)来实现根据本技术实施例的虚拟机的创建系统中的一些或者全部部件的一些或者全部功能。本技术还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者系统程序(例如，计算机程序和计算机程序产品)。这样的实现本技术的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这
样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
[0125]
应该注意的是上述实施例对本技术进行说明而不是对本技术进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本技术可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干系统的单元权利要求中，这些系统中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
[0126]
以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到其各种变化或替换，这些都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。