CN105706469B

CN105706469B - 管理机器对机器设备

Info

Publication number: CN105706469B
Application number: CN201480062205.0A
Authority: CN
Inventors: N.博内; T.斯纳佩; Y.普拉布迪尔; J.本托; M.普林斯
Original assignee: Vodafone IP Licensing Ltd
Current assignee: Vodafone IP Licensing Ltd
Priority date: 2013-09-13
Filing date: 2014-09-12
Publication date: 2020-03-10
Anticipated expiration: 2034-09-12
Also published as: GB2518975A; GB2584371A; WO2015036778A1; GB2518255A; GB201415925D0; GB201409641D0; GB202012324D0; GB201415003D0; US10305862B2; GB2518976A; WO2015036782A1; WO2015036776A1; WO2015036772A1; EP3767984B1; GB2518257A; GB201415921D0; US10630646B2; GB2518522B; GB2518521A; EP3832982A1

Abstract

用于管理包括具有存储器位置的存储器仓库的设备的系统和方法，其中每一个存储器位置存储与一个或多个设备相关联的一个或多个属性。设备管理器布置成执行命令以对存储在存储器位置中的一个或多个属性采取动作，并且从一个或多个设备接收对应的一个或多个属性的值。同步器配置成维持存储在存储器仓库中的属性与关联于设备的属性之间的同步。

Description

管理机器对机器设备

技术领域

本发明涉及用于管理设备并且具体地机器对机器设备的方法和系统。

背景技术

受管理的设备并且具体地机器对机器（M2M）设备可以使用在许多不同情况下并且并入到各种不同项目和硬件中。典型地，这些受管理的设备将具有低计算资源，在功率方面受约束，并且具有受约束的功能。然而，可以开发这样的受管理的设备的大网络，其要求维护、控制和其它交互。此外，受管理设备的这些网络可以具有不同类型和年龄，并且也可以具有不同版本的所安装的软件和固件。这在整体上增加了网络的复杂度以及用于控制网络和网络内的各个设备的设备管理器的复杂度。

确保由不同设备（或者具有不同类型软件和固件的类似设备）形成的网络受到管理的一种方式是在每一个设备管理器内维持关于各个设备的信息。例如，设备管理器然后可以根据正确的通信协议并且以正确的格式从每一个单独的设备接收数据或者向其发送数据。当做出错误时并且尤其当数据以错误格式发送给现场中的设备时或者是当发送各个设备未正确解译的命令时，这则可能引起受管理的设备不正确地执行或者甚至失效。通过这些受管理设备的性质，可能难以或者不可能手动地干预或重设设备，尤其是在其嵌入在难以访问的硬件中或者没有特定维护调度的情况下。此外，在有限机载功能的情况下，每一个受管理的设备可能未必具有充足资源来报告错误或者从这样的情况恢复。

这增大了必须确保设备管理器跟进受管理设备类型和软件版本的设备管理器和用户或指令应用上的负担。该问题随着网络中的设备数目和设备类型的增多而变得更加困难。

因此，要求克服这些问题的用于管理设备的方法和系统。

发明内容

对照该背景技术并且依照第一方面，提供一种用于管理设备的系统，包括：

具有存储器位置的存储器仓库（store），其中每一个存储器位置存储与一个或多个设备相关联的一个或多个属性；

设备管理器，其布置成执行命令以对存储在存储器位置中的一个或多个属性采取动作并且从一个或多个设备接收对应一个或多个属性的值；以及

同步器，其配置成维持存储在存储器仓库中的属性与关联于设备的属性之间的同步。这允许更高效地管理设备。因为设备管理器可以对存储在存储器中的属性而不是直接对设备执行命令，因而不要求与每一个设备的直接且高度可用的通信链接，这是因为同步可以例如在通信中的中断修复之后发生。此外，设备管理器不需要关注每一个设备的特定格式或配置，这是因为存储器仓库可以维持在更加可预测、一致或稳定的布置中。属性可以属于许多不同类型。例如，特定属性可以是布尔真或假（例如门开着）或者控制命令（例如打开门）。设备可以属于任何类型。它们可以是物理设备（例如家用物品，诸如冰箱）或者虚拟机（例如物理机器的软件仿真）。数据或元数据可以用于限定如何以及何时执行同步。例如，可以存在同步之间的特定或预确定的延迟或者这可以是可变的并且取决于其它因素（例如在周四，这必须是每三分钟，但是在周五，其将按每五分钟执行）。设备管理器可以执行附加任务或动作。例如，设备管理器可以测量从每一个设备、设备群组、用户或应用所接收或者发送到其的数据的体积或数量。这样的信息可以用于计帐或开账单目的（例如与数据体积、读取或更新数目等的成本相关联）或者用于优化网络。该信息还可以用于记录和/或错误检查目的（例如以检测异常业务量体积）。

可选地，命令可以限定为声明式命令。例如，命令可以使用声明式编程语言来表述或呈现。

优选地，所执行的命令可以是基于集合的操作。例如，基于集合的方案可以限定针对可以从数据集合获得的经处理结果的要求，而不是如何获得该结果。还可以采取程序性方案，但是这限定做什么以及如何进行它。

优选地，基于集合的操作可以包括以下中的任何一个或多个：SQL、进程（procedural）、数据操纵、配置管理、插入、选择、更新、创建、读取、写入、擦除和搜索。

优选地，系统还可以包括用于与每一个设备通信的一个或多个接口。

可选地，设备管理器还可以配置成通过一个或多个接口中的第一接口与每一个设备通信。设备和设备管理器中的任一者或者二者可以发起通信。例如，设备可以请求数据（例如更新）或者设备管理器可以从设备请求数据。数据或元数据可以发送到设备和/或存储在设备上以例如限定通信如何以及何时发生。接口可以属于不同形式，包括但不限于例如WiFi、蜂窝、zigbee、蓝牙、WiMax。

有利地，同步器还可以配置成在通过接口与一个或多个设备的通信可用时进行操作。

可选地，同步器还可以配置成在通过接口与一个或多个设备的通信不可用时发起与一个或多个设备的通信。可以做出这样的通信（例如信道或接口）的发起。例如，唤醒消息可以发送到一个或多个设备。这例如可以通过不同接口或信道，诸如SMS、固定线路或者通过移动网络。此外，系统可以配置成核实与一个或多个设备的通信是否可用并且然后优选地，取决于这样的测试的结果而做出一个或多个动作。

可选地，同步器还可以配置成以一定间隔进行操作。间隔可以通过调度限定（例如在时间X处联系设备A，在时间Y处联系设备B等），或者特定设备或设备群组可以以特定时间间隔同步（例如每X分钟）。间隔或指定的时间可以是预确定的或者基于其它准则动态地设定。例如，这些时间或间隔可以基于当前网络负载和/或针对特定设备的要求（某些设备群组然后可以比其它更为经常地同步——例如心脏监护器）。例如，间隔可以作为数据或元数据任一者或二者被限定和存储在设备上或者设备管理器内。同步器也可以连续地操作。

优选地，同步器可以通过控制设备的属性来维持所存储的属性与关联于一个或多个设备的属性之间的同步。这可以涉及由同步器执行的输出类型操作。

可选地，同步器通过更改或控制所存储的属性来维持所存储的属性与关联于一个或多个设备的属性或者一个或多个设备的属性之间的同步。这可以涉及由同步器执行的输入类型操作。控制可以包括动作，包括例如针对匹配进行检查。

有利地，存储器仓库还配置成存储和/或检索一个或多个属性的之前版本。例如，属性可以被存档。

可选地，系统还可以包括一个或多个属性的概要（schema）或数据库概要。例如，这可以用于存储表格数据（例如随时间的能量（energy）读取）。

可选地，一个或多个属性可以是设备的任何可执行代码、由设备所检测的参数和/或由设备所接收的参数。

可选地，可执行代码可以是固件、操作系统和/或一个或多个软件应用。

可选地，系统还可以包括布置成将数据传达给设备管理器的第二接口，并且进一步地，其中响应于所传达的数据而执行对存储在存储器位置中的一个或多个属性采取动作的命令。

优选地，可以从用户和/或应用接收数据。

可选地，设备管理器或系统的另一部分还可以布置成确定用户和/或应用是否被授权。还可以确定是否允许用户和/或应用具有访问。这可以基于凭证和/或其它安全机制。

优选地，可以布置存储器位置，其具有复制一个或多个设备的数据结构。这可以是物理或逻辑布置。该数据结构可以充当针对设备群组的。

可选地，数据结构可以是跨不同类型设备所共同的统一数据结构。这允许针对特定任务、操作或控制动作优化设备管理器而不需要针对不同具体设备再格式化或定制这些动作。

可选地，对存储在存储器位置中的一个或多个属性采取动作的命令可以符合统一数据结构，该系统还包括适配器，所述适配器配置成适配命令以向同步器提供指令来以特定于每一种不同类型设备的格式控制一个或多个设备的属性。适配器可以用于允许设备管理器与不同类型设备通信。这可以包括在不同标准（例如TR-069、OMA LWM2M、MQTT等）内使用的设备。

可选地，与一个或多个设备相关联的一个或多个属性可以是开账单和/或记录数据或者被用于这样的目的。

可选地，一个或多个设备可以属于选自包括以下项的群组的类型：机器对机器M2M设备、另外的设备管理器、一个或多个设备的控制器、以及接收实体。可以使用其它设备类型。

有利地，设备管理器还可以配置成接收一个或多个准则，并且监视一个或多个设备以确定何时满足一个或多个准则。

可选地，设备管理器还可以配置成在满足一个或多个准则时触发事件。例如，这可以是警告消息、向用户或向应用的消息。事件还可以例如是执行涉及设备的动作，诸如软件或固件更新。

优选地，事件可以是预确定的。例如，事件可以是将特定消息发送给预确定的地址或位置。这例如可以包括一个或多个地址或者回叫。

而且或者替代于事件引起发布命令，它们还可以引起改变或更新属性。附加地，事件可以用于触发对元数据的改变或更新。例如，事件可以引起调度或间隔改变。

根据第二方面，提供一种用于管理设备的方法，包括以下步骤：

存储与一个或多个设备相关联的一个或多个属性；

对一个或多个所存储的属性采取动作；

从一个或多个设备接收一个或多个属性的值；以及

维持存储在存储器仓库中的属性与关联于设备的对应属性之间的同步。

可选地，方法还可以包括以下步骤：接收命令以改变一个或多个设备的属性，其中命令以符合一个或多个所存储的属性的数据结构的第一形式而接收，其中维持同步的步骤还包括将所接收的命令转换成符合一个或多个设备的数据结构的形式的步骤。

优选地，命令可以通过第一接口接收，并且其中经转换的命令通过第二接口而传达到一个或多个设备。

可选地，方法还可以包括以下步骤：接收限定步骤顺序的命令以用于改变一个或多个设备的属性，其中对一个或多个所存储的属性采取动作的步骤根据步骤顺序来执行。

有利地，方法还可以包括以下步骤：在根据步骤顺序而同步一个或多个设备的一个或多个属性之后，更新设备的固件或其它可执行代码组件。在一个示例中，设备管理器可以接收不同版本的数据模型（例如版本1和版本2）。设备管理器然后可以管理将每一个设备变换到新版本但是更新属性的过程，其继而导致改变软件或固件组件。数据模型还可以响应于软件或固件改变而更新。设备还可以卷回到较早版本或者较早数据模型以及在版本中向前移动。

优选地，针对不同设备类型接收限定不同步骤顺序的不同命令。不同设备类型例如可以包括类似或相同的硬件，但是具有不同安装的软件和/或固件。

有利地，设备可以取决于所存储的一个或多个属性而被更新到固件或另一可执行代码组件的不同版本。例如，一个或多个属性可以指示当前版本，并且因此更新可以是到当前版本可以支持的下一版本或最高版本。在另一示例中，属性可以指示软件或固件的版本，并且因此这可以用于确定要安装不同软件或固件的兼容版本（例如操作系统版本5可以与特定软件版本2而不是3一起使用）。

可选地，所存储的一个或多个属性可以针对不同设备类型而存储在单个或共同的数据结构中或者作为单个或共同的数据结构而存储。因此，设备管理器、用户或应用仅需要从一个数据结构（例如单个数据库）查询或检索数据以便控制或管理各种不同设备。单个数据结构的部分可以例如跨不同设备类型而是共同的。

优选地，维持所存储的属性与设备的对应属性之间的同步还包括在更新一个或多个设备之前转换属性。因此，设备管理器、用户或应用可以监视、管理或控制不同类型设备而不必再格式化、修改或转换数据。转换可以在两个方向上进行（即至设备或从设备）。

可选地，方法还可以包括以下步骤：接收针对固件或其它可执行代码组件的每一个版本的数据模型，然后使用数据模型来限定如何在版本之间变换。例如，在其可以继续之前，软件、固件或其它更新可以具有依赖性（例如软件Y的版本B仅可以在软件Z的版本C已经安装之后安装）。

可选地，方法还可以包括以下步骤：

接收请求内的准则，其中准则取决于一个或多个属性；

监视一个或多个属性；

在满足准则时进行报告。

优选地，方法还可以包括在满足准则时向请求者报告一个或多个属性的步骤。

有利地，监视一个或多个属性的步骤还可以包括监视一个或多个所存储的属性。

有利地，监视一个或多个所存储的属性可以发生在与设备的通信可用时。例如这可以连续地监视或者周期性地检查。

优选地，维持同步的步骤可以发生在与设备的通信可用时。

可选地，方法还可以包括以下步骤：

执行存储在存储器仓库中的属性中的一个或多个的分析以生成指示资源的使用或需求的输出。以此方式，所存储的属性以及因而设备属性可以用于计算或推断正在使用或者要求或者将要求多少资源。

有利地，用于执行分析的属性可以与资源无关或者仅疏远地与资源有关。例如，设备可以测量一个或多个值或者接收指令以操作一件仪器。资源可能不由一个或多个设备直接测量，但是可以存在间接链接或连接。可以执行分析以评估资源的使用或者当前或将来需求而不需要直接地测量它（或者其可以是不能容易测量的某物）。

可选地，资源可以是以下中的任何一个或多个：自然资源；消费者产品；食物；饮料；运输；房产（premises）访问；动力（power）；电力；燃气（gas）；燃料；水；公共运输；电信；软件；以及娱乐。可以评估其它资源。在一个示例中，一个或多个属性可以描述已经操作一件仪器（例如门）的次数。资源可以是建筑物的占用。因此，一个或多个属性可以用于基于建筑物的当前要求或者在将来而间接地计算剩余容量、预期动力、水、通信。

在另一示例中，设备可以测量或者以其它方式记录一个或多个特定产品的销售。

优选地，所执行的分析可以由机器学习算法执行。例如，这可以使用人工智能技术，诸如受监管或不受监管的学习、决定树学习、神经网络、支持向量机等。

可选地，方法还可以包括以下步骤：

接收描述在存储器仓库内的存储器位置的添加、删除或修改的信息；以及

根据所接收的信息对存储器仓库做出改变。换言之，当要求新的功能或者需要管理不同属性时，可以改变存储器仓库内的存储器位置。

优选地，信息可以与一个或多个设备的固件更新相关联。因此，存储器仓库可以利用转出（roll out）的固件或软件更新来维持和更新。新的或者改变后的存储器位置也可以卷回到之前的版本。以此方式，可以维持数据模型。对数据模型的改变可以是自动化的，使得固件或软件改变触发针对存储在存储器仓库内的数据模型的对应改变。

以上所述方法可以实现为包括程序指令以操作计算机的计算机程序。计算机程序可以存储在计算机可读介质上。

计算机系统可以包括处理器，诸如中央处理单元（CPU）。处理器可以以软件程序的形式执行逻辑。计算机系统可以包括存储器，其包括易失性和非易失性存储介质。可以包括计算机可读介质以存储逻辑或程序指令。系统的不同部分可以使用网络（例如无线网络和有线网络）连接。计算机系统可以包括一个或多个接口。计算机系统例如可以包含适当的操作系统，诸如UNIX、Windows（RTM）或者Linux。

应当指出的是，以上所述任何特征可以与本发明的任何特定方面或实施例一起使用。

附图说明

本发明可以以数种方式付诸实践，并且现在将仅通过示例的方式并且参照附图描述实施例，在所述附图中：

图1示出包括北向接口和南向接口的示例设备管理平台的示意图；

图2示意性图示了使用图1的北向接口的方法；

图3示出用于操作图1的设备管理平台的数据流的示意图；

图4示意性图示了具有图1的北向接口的各种用户类型的交互；

图5示出图1的设备管理平台的处理引擎的示意图；

图6示出在图1的设备管理平台中使用的示例数据模型的示意图；

图7示出另外的示例数据模型；

图8示出由图1的设备管理平台内的处理引擎使用的示例类对象结构的示意图；

图9示出形成图1的设备管理平台的组件的物理布置的示意图；

图10示出用于唤醒由图1的设备管理平台所管理的一个或多个设备的过程的流程图；

图11示出SMS从设备发送到图1的设备管理平台的过程的示例流程图；

图12示出图1的南向接口的逻辑视图的示意图；

图13示出用于表示受管理的设备的示例管理信息基础数据结构；

图14示出设备接口模型的类图；

图15示出用于管理设备的示例系统的示意图；

图16示出用于管理设备的示例方法的流程图；以及

图17示出用于管理设备的另外的示例方法的流程图。

应当指出的是，附图出于简单起见而图示并且未必按照比例绘制。相同特征提供有相同的参考标号。

具体实施方式

系统可以描述为设备管理10平台（如图1中所示），其可以提供可以与顾客或用户应用过程（其可以描述为垂直应用20）集成的服务和机制的核心集合。

应用可以形成受管理的设备或机器对机器（M2M）平台的部分或者可以从其分离。图1图示了多个垂直应用20，全部经由设备管理（DM）总线55结构与还可以描述为设备管理应用代理（DMAP）60的设备管理器对接。DMAP 60可以视为可以由许多不同垂直应用所使用的使能（enabling）技术。垂直应用可以限于网络平台，其可以触发基本设备管理功能，例如获取器（getter）/设定器、固件管理等。

DM平台10可以支持多个垂直应用种类和类型。DMAP 60虚拟化物理设备以便向垂直顾客或用户应用提供那些物理设备的一致视图。用于实现此的底层机制对于垂直应用可以是透明的，并且用于与物理设备对接的机制、协议和数据结构可以是DMAP 60的功能的部分。

如图3中示意性图示的，DM解决方案的功能和数据流150可以分离成三个架构组件：

1. 提供DMAP 60与垂直应用20之间的通信的北向接口（NBi）160。这将在设备管理（DM）总线55之上执行；

2. DMAP服务器60；

3. 经由设备数据（DD）总线向物理M2M设备提供通信和控制的南向接口（SBi）170。

查看架构模型的可替换方式是作为企业架构环境中的组件，其中垂直应用20位于EA总线上方并且通过使用设备管理总线55调用面向服务架构（SOA）服务来与设备相互操作。

DMAP服务器60设计为意图满足许多不同设备管理应用的要求的使能技术。如其名称所暗示的，它是应用代理。存在说明性应用的许多示例，包括机器对机器（M2M）终端25、监视设备30能量35、连接壳体（cabinet）45、无所不在的计算机（UBI）40、移动资产45等。垂直应用20可以是允许工作人员执行基本设备管理功能的网络应用。附加地，可以使用基于云的SaaS方案。

DMAP 60可以是由第三方顾客可访问的并且可以管理第三方设备/资产，因此部署可以具有与其它类型应用代理类似的安全要求。换言之，可以假定DMAP 60是针对安全利用有吸引力且可访问的目标。所采取的安全方案是使用网络元件中通常不使用的多个主机级别安全机制的深度方案中的防御（文件整体性检查、根套件扫描、安全角色实施、主机等级防火墙）。

在以下章节中描述五个分离的总线结构。连接矩阵和防火墙（IoD）规范可以向这些映射，但是可以进一步扩展。例如，DM总线55可以用于与具有不同安全要求的不同垂直应用20通信。因此，DM总线55可以分离成多个物理/逻辑通信路径并且在每一个上具有适当的安全控制。

DM总线55可以与运营商（operator）托管的网络应用通信，该应用可以提供对DMAP60的访问以供运营商信任的工作人员使用。这可以在控制网络服务器（垂直应用20）与DMAP60之间具有单个VPN连接的情况下满足。DMAP 60与代理65对接，其可以是受管理或M2M设备内的组件（软件和/或硬件）。

图3示意性图示了若干类型的连接：

1）最终用户接口（顶部箭头），典型地这将是基于网络的UI，但是其可以是如由垂直应用20所限定的任何机制。

2）连接设备管理应用平台的组件的内部接口（从底部起两个和三个的箭头）。这些可以以编程方式实现为本地对象的存取程序。可替换地，基于远程进程呼叫（RPC）和序列化的EJB/OSGi类型环境可以用于跨多个平台（例如云环境）分离这些层。在该示例中，这些接口将以编程方式描述。换言之，NBi 160和DM处理引擎165可以运行在单个平台上。

3）外部接口（水平箭头、底部箭头和从底部起第四个箭头）可以使用连接/无连接协议来提供它们支持的组件之间的通信功能。在该示例中，功能上存在四种类型的外部接口：

a. 设备管理总线。使用网络服务在垂直（头端）应用20与设备管理平台10之间提供通信。

b. 设备安全总线。提供AAA服务的完整集合并且限定用户角色和安全ACL。

c. 设备控制总线。向M2M平台提供管理API连接。例如，可以在该总线上调用SMS唤醒。

设备数据基础

可以使用到设备的有线和蜂窝连接。M2M平台管理设备可以支持蜂窝承载商，从而允许SMS唤醒和APN连接。一些设备还可以具有附加有线连接。M2M平台连接可以视为受信任的并且任何其它连接应当基于逐个情况地处置并且应当分配给分离的安全域。在图中未示出的是操作和维护（O&M）连接要求。这些例如可以在本地实现或者使用设备控制总线之上的VPN。这些可以包括DNS、NTP、SNMP、SYSLOG、SSH和备份协议，但是如所要求的，可以支持附加协议。

垂直应用20是使用设备管理平台与设备120对接、管理和操纵设备120的应用。

垂直应用可以由具有变化安全角色的不同种类的用户155使用，例如：

● 负责针对许多类型设备的操作的管理工作人员

● 负责由其顾客所拥有的设备的OpCo顾客

● 拥有他们向最终用户供应以使用（出于某种目的）的设备的顾客

● 使用设备120的最终用户和人员。

特定种类用户将使用的垂直应用20可以类似地变化。应用类型可能包括但不限于：

● 管理工作人员：监视和配置复制/重复机制

● Opco顾客：出于开账单目的而监视利用

● 拥有设备的顾客可以使用版本管理工具来部署软件更新和确保他们正确地操作。

● 使用设备的最终用户可以使用网络服务，所述网络服务允许他们与他们使用的设备120交互。

许多其它垂直应用20可以部署成支持垂直视场的需要。示例可以包括UBI、连接壳体、RMCS。

垂直应用20可以通过北向接口（NBi）160与DMAP 60通信。这还称为设备管理或DM总线55。

NBi 160可以提供总线接口以用于与由DM平台所管理的物理M2M资产通信并且控制其。

NBi 160可以允许垂直应用20与DMAP的NBi之间的双向通信。通信可以使用网络服务，并且连接可以例如通过垂直应用20向DMAP的NBi或者从DMAP 60向垂直应用20建立。

从DMAP向垂直应用所发起的连接被称为回叫。

DM总线协议

图2示意性图示了使用NBi 160的方法80。跨NBi总线的所有数据流可以在连接的上下文内操作。连接可以出于单个请求/响应的目的或者其可以横跨多个请求/响应循环。连接方可以执行AAA验证。一旦经验证，则该方可以在DMAP 60的控制之下具有对预限定的资产的授权访问。AAA机制可以支持所有三个AAA功能（验证、授权和计帐）。

管理应用85可以包括记录、警报、诊断和分析。顾客应用90可以包括之前描述的任何垂直应用20或者附加应用。企业架构总线95提供应用85、90与DMAP 60之间的接口。这可以在例如内部或外部网络之上。设备安全和设备控制总线分别提供DMAP 60与单点登录（SSO）105和全局数据服务平台（GDSP）108组件之间的接口。设备数据总线100可以在一个或多个承载商网络110之上提供DMAP 60与受管理的设备（例如各个设备120、其它DM平台130或一个或多个网关集线器140）之间的接口。这些承载商网络可以包括蜂窝、无线或有线网络。

DMAP 60可以要求针对操作人员的管理接口。例如，这可以用于管理之后通过AAA实施的北向方的访问权限。可以包括O&M接口，但是这可以视为特殊情况并且将进入O&M安全分区中。管理垂直应用可以执行管理类型/仪表盘功能。连接管理/超时/队列问题可以通过标准化管理/kpi捕获接口而解决。在数据结构方面描述资产，其中使用基于角色的注释来限定访问控制。可以使用基于角色的安全模型授权经验证的连接具有对资产的不同等级的访问。例如，这可以使用JSON/XML模型，其中使用“很好形成的”数据结构（即XML）描述请求和响应二者。

为了遵照安全要求，该应用/DM总线协议可以在基于证书的验证机制的基础上使用SSL加密。附加地，可以适当地使用VPN以确保在DM总线55之上的数据业务量的正确分离。向内部管理应用的DM总线业务量可以与传递给公共互联网上的第三方垂直应用20的业务量在分离的VPN之上运行。

DM总线访问机制

可以存在所支持的多个类型的访问：

1）DM获取/设定API——允许第三方应用向DMAP 60做出直接查询并发布命令并且获取同步/立即响应的API机制。

2）DM获取API——允许第三方应用向DMAP 60做出直接查询并且获取异步响应的API机制（例如，可以使用两个不同的API或者一个具有标志。）

3）DM获取/设定http——允许第三方网络查询的http查询机制

4）回叫——异步请求可以使用XML回叫机制返回数据结果集合。这可以是经由URL。

同步请求可以在请求查询或动作时出现，并且可以立即返回结果。异步请求可以在请求查询时出现，并且结果将在随后的时间点处可用。同步可以通过分离的或集成的组件或功能来维持。

同步请求

同步请求可以在所得动作的状态或结果立即已知时使用。如果状态在改变，则可以使用多个查询来轮询状态。尽管轮询是简单的，但是其可能不是非常高效的。

异步请求

这提供用于以更高效的方式应对改变的条件或事件的机制。当源自异步请求的动作生成结果时，该结果可以供应回到指定URL并且结果数据可以使用XML注释来封装。该类型的请求可以在以下情况时使用：

● 在请求可以完成之前将存在（可能不可预测持续时间的）延迟

● 将存在所生成的多个响应（结果集合）。这些可以使用光标（依照SQL）同步实现，但是其增加复杂度。

● 设备将通知发送给M2M平台（例如传感器数据的所调度通知或排除）。

要应用于特定设备或设备群组的动作可以存储在存储器（易失性或非易失性）内的存储位置内并且然后立即地或者在一段时间之后（经调度或者必要时在立即条件下）同步或应用于设备。动作可以是改变、添加、更新或者删除设备的特定值或属性或者从设备获得数据。因此，同步可以是双向的。

回叫机制还可以用于从设备发送的传感器数据通知。警报、传感器数据、诊断和异步获取器全部可以使用相同的回叫机制。

回叫机制

URL回叫机制可以实现为设定器机制，其中所请求的动作将借助于指定URL而传达回到调用的应用。该方案的优点在于，其使得非常高效地使用资源并且可以用于以简单方式描述复杂行为。

回叫——一次结果

可以使用异步请求，其中请求单个动作并且可以存在请求与动作之间的未知时间延迟。例如，锁定并且擦净（wipe）设备的命令可以仅在DM平台已经建立与所标识的设备的联系之后执行。如果设备关断，则其可能在完成操作之前花费一些时间（或者超时）。

回叫——多个结果

可以使用异步请求，其中将存在多于一个结果。这可以是没有结果或者潜在地无限数目的结果。示例可以是针对具有低信号等级的设备的查询。可以存在满足该请求的变化数目的设备，从而在延长的时间段内返回结果。回叫机制提供以相对简单的方式传递该响应顺序的机制。

回叫——记录结果和传感器数据

传感器数据结果可以借助于回叫机制而供应给控制应用。进行请求的应用可以描述感兴趣的传感器数据，将使其被供应的条件以及回叫将该传感器数据传递给的URL。要指出：多个应用可能潜在地查看相同传感器数据，简单地通过描述多个回叫请求。

回叫——警报

警报可以在发生需要记录的一些事件并且需要传达描述事件的信息时出现。警报可以是你如何描述将使警报生成的触发。触发条件可以是简单的，例如数据字段具有特定值，或者值进入指定范围。

警报和传感器数据输送可以以相同方式实现。传感器数据的调度输送也可以被视为警报。

更复杂的警报触发可以利用使用布尔逻辑而组合的多个条件来指定。

回叫——诊断

在概念上，这些以与回叫警报类似相同的方式起作用。仅有的不同将是如何限定诊断警报。诊断可以是具有帮助台第一、第二、第三线路支持职责的支持组织所感兴趣的。诊断机制可以由应用20在该类型组织的控制之下管理。

回叫——指定触发/动作对

应用可以通过利用描述回叫数据响应要在哪里发送的URL而调用请求来请求异步活动（回叫）。针对传感器数据、警报和诊断的回叫可以使用该相同机制并且可以通过指定具有触发条件的回叫来执行其功能。触发条件和随后的动作形成对。该API可以包含：

● 回叫URL——回叫在激发触发时将数据传递到其处

● 在激发触发时要传递到URL中的数据结构的XML限定

● 将使回叫激发的触发的XML限定。该触发限定可以包括条件集合以及条件之间的布尔关系。

● 针对触发/动作对的名称——一旦已经限定和命名触发/动作对——则可以分配给具体设备和/或设备集合。

使用回叫

回叫参数可以在单个API呼叫中指定，或者可替换地，某人可以使用之前限定和命名的以下限定：

● 要在URL中传递的数据结构

● 触发指定。

在警报的情况下，诊断和传感器数据和命名回叫加上触发指定可以以三个示例方式之一与设备相关联：

1）设备类型，特定类型的所有设备。

2）设备版本，特定版本的所有设备。

3）设备，在逐设备的基础上。

当设备的实例数据（描述分配给对象的数据对象的编程术语——对象可以是虚拟化设备对象）改变时，其将首先处理与该设备相关联的所有回叫，然后其将处理在设备版本等级处指定的回叫，并且最后其将处理在设备类型等级处的回叫。所有回叫可以被命名。一旦经命名的回叫已经起作用，则具有相同名称的较高等级（设备版本、设备类型）处的回叫可以不被触发。

这种使用经命名的数据结构和触发的方案通常提供以下能力：动态地修改所返回的数据结构和触发，而不用需要修改应用程序或者甚至需要重启那些应用。

使用情况示例：

● 顾客应用描述作为指示设备故障的条件集合的触发列表。这些条件可以根据指示设备具有特定故障（触发列表）的值来限定。值仅是示例。可以设定任何值并且可以使用不同条件。

○ 动力等级＜12，

○ 设备版本2.56，

○ 温度读数＞34

● 回叫被限定到顾客的网络服务平台中。该限定包括：

○ 网络服务URL

○ 获取对顾客应用的访问的用户名/密码凭证

○ 将传达跨越给网络服务URL的数据结构

● 警报/诊断根据以下创建：

○ 设备类型，

○ 触发列表

○ 回叫。

回叫方法可以是与顾客应用20集成的有利方法。可替换方案可以是轮询的同步获取器。

该使用情况中的最后步骤可以使警报/诊断与表示设备类型的设备实例结构相关联。如果警报/诊断已经存在，则其可以以该新限定改写。

该方案允许警报/诊断针对单个设备、相同版本等级处的设备的集合或者指定设备类的所有设备而指定。

限定成检测具有特定硬件错误的设备的命名触发可能随时间而提炼以在不同情况下触发。随着时间的演变，支持人员或自动化系统可以提炼触发，因此其在标识特定故障、条件或准则方面更有选择性和更准确。一旦修改，则触发可以被激活并且使用该命名触发的所有应用可以开始接收针对与新的且提炼的触发条件匹配的设备的回叫。

该触发/动作机制将允许支持团队通过随时间提炼触发而创建越来越复杂的诊断/警报能力。当新的故障被诊断或者满足其它准则时，则触发可以（再）限定为更特定且更有选择性。

类似地，当限定警报/诊断时，有可能针对各个设备、或者指定版本处的设备或者针对指定类型的所有设备而限定其。

北向API可以具有以下中的任何一个或多个：

- 可以提供可用于使用北向接口160的第三方的API规范

- API的集合可以是具有异步变量的极其简单的获取和设定。复杂度和细节可以变化并且取决于可以获取和设定的对象，例如设备的数据模型。

- 北向接口160可以是以下中的任何一个或多个：

○ 基于SOAP的远程进程回叫接口

○ 基于http和资源URL的RESTful接口

○ 使用SOAP的网络服务接口

○ JSON

○ 其它

- 远程进程呼叫（RPC）——这可以导致应用20与可以形成开放服务网关发起（OSGi）类型解决方案的部分的虚拟设备之间的非常紧密耦合。

- 获取/设定APi和获取/设定http。这些导致类似功能，但是包括针对异步更新的支持。

- 回叫结构可以进行缩放。NBi 160可以分布在多个DMAP与多个北向垂直体之间。

- 北向接口160可以充当对垂直应用的SaaS接口。

获取/设定API或北向接口160可以使用由云服务器（例如Sierra无线的云服务）提供给用户或顾客的API。SNMP可以使用相同方案，但是其中使用诱骗服务器实现回叫。使用网络服务在两个方向上在应用之间进行通信可以用于管理网络服务意识应用之间的信息的双向流动。

DMAP服务器

软件可以托管在云中。可以使用云、主/从、代理和转发器配置。

设备管理应用代理60可以使用声明式机制来描述所有操作、对象和动作。每一个DMAP服务器可以管理：

● 可以属于许多不同类型和/或版本的受管理设备120的集合

● 设备发现机制，使得连接设备可以添加到受管理设备区（设备或用户驱动的）。

● 设备注册/解注册机制，使得设备可以被置于可替换状态中。

● 针对不同类型和/或版本的设备的集合执行固件更新操作所必要的固件图像和逻辑/数据结构（服务器可以从例如NBi功能获取固件图像）。针对设备的数据模型可能需要支持固件版本化。软件图像可以被视为数据模型上的项目，其将具有版本和设定器功能以发起负载和安装固件。同样可以适用于驻留在设备上的应用软件。

● 针对许多不同类型和/或版本的设备的集合执行应用软件更新操作所必要的应用软件图像和逻辑/数据结构。对哪个软件安装在每一个设备上进行管理和编目是较高等级的垂直应用（头端）功能。

● 回叫以及用于使那些回叫操作的规范和安全凭证。

● 触发以及使设备引起触发被激活所必要的触发条件或准则的描述。

● 支持传递给所注册的回叫的适当警报、诊断、记录和传感器数据事件以及事件数据的生成的设备/回叫/触发映射。

图4示意性图示了各种用户类型通过一个或多个DM总线55与NBi 160交互以便提供到DMAP 60中的路径来控制和监视设备120。用户155例如可以包括最终用户156、顾客157以及OpCo 158。

DMAP服务器的处理引擎165可以限于简单过程的小集合。示例实现在图5中示意性示出。这些可以实现为按顺序执行的多个活动线程或者单线程过程。过程可以访问设备实例，并且同步机制可以在设备实例等级处操作（即过程可以不具有对它们的任何可见性）。

设备实例

由DM服务器管理的每一个物理设备120可以实例化。这些设备实例数据可以包含涉及物理设备120的所有最新信息，并且可以认为是物理设备120的虚拟化。设备的实例数据的内容可以使用北向接口160使用任何获取器/设定器机制来引用。

设定器不限于设定数据值，但是它们也可以支持调用命令的能力。例如，表示擦净/锁定的数据变量实例可以用于通过对表示擦净/锁定的设备实例变量执行锁定（或锁定和擦净）的设定器操作来支持擦净/锁定机制。

设备实例数据可以具有对设备类对象的引用，（即可以存在针对每一个设备类型的单个设备类数据对象）。这些数据还可以包括对设备版本实例（参见设备版本实例化章节）对象的引用。

设备版本对象可以包含描述由在指定版本等级处的设备使用的数据模型的数据结构。

因而，设备实例可以具有对可以包含由该设备类型和版本的所有设备使用的数据模型的设备版本对象的引用。这些数据结构和关系例如可以支持在固件的版本之间的变换设备所必要的机制。

设备实例数据模型

设备数据模型可以在给定TR-069和OMA LWM2M（以及其它示例协议）中所使用的设备数据模型的先验知识的情况下限定。适配器的随后开发因此可以变得更为直接了当。这直接映射到LWM2M TR-069和SNMP MIB数据模型上。可以包括附加特征和结构。

在该示例中，模型在四个等级中的任何一个或多个处工作：

1）垂直应用视图

2）DMAP视图

3）协议（LWM2M）视图

4）设备视图

每一个等级可以具有不同要求，但是优选地可以使用设备数据模型的单个XML限定并且可以从其生成针对不同等级的必要结构（参见SDK数据建模工具）。

设备实例数据可以使用数据模型限定，其中每一个设备的每一个版本可以具有与其相关联的数据模型。该数据模型可以采取XML限定的树结构（例如）的形式，其中树上的每一个节点描述具有限定的属性的特定类型的数据元素以及与其相关联的元信息。可替换地，其可以是数据元素树上的分支节点。

图6示出示例数据模型190的示意图。在该图中，屏幕保护程序被示出为描述屏幕保护程序对象的叶节点。这可以是包含对作为屏幕保护程序的文件的引用的串类型，或者例如其可以属于类型二进制大对象（BLOB）并且包含JPG或者其它图像文件的二进制数据内容。

铃声（ring）信号节点被示出为分支节点并且在该示例中可以包含对多个不同铃声信号数据对象的引用。

数据模型元信息可以包含多个属性，其可以约束将如何使用设备实例数据，这可以包括（但可以扩展）：

● 安全角色——可以存在分配给数据模型中所描述的每一个数据项目的多个安全角色，其中角色将约束通过不同动作者在与设备的实例化数据项目交互时所允许的访问权限。安全角色可以是固有的，由此允许高等级分支节点结构拥有下属于它的所有数据项目的安全限定。

● 默认值——这些可以用于序列化并且在第一次实例化数据项目时（支持固件版本之间的变换）。

● 值的有效范围——这些可以用于数据规范化（支持数据分析所要求的）。

● 主要/次要生效——这些可以由设备的开发者用于限定设备可以保持的值的有效范围。这允许数据建模器描述可以保持在数据元素中的数据的合法或有效值。

● 序列化规则——描述将如何复制/克隆数据项目

● 时间性规则——该数据项目需要多频繁地更新

复杂对象

在架构上，数据模型可以具有层级结构。这可以使用关系数据基本系统来表示，从而意味着开发者可以在要求的情况下使用数据库。然而，可能优选的是，开发者以智能方式设计数据模型。

数据模型190允许开发者表示相关数据结构的集合成好像它们是单个数据对象。图7示出另外的示例数据模型200。在该示例中，对象DM列表是列表区域并且引用多个列表结构（例如每一个具有列表特征的列表名称）。这些列表中的每一个表示不同数据对象种类。

以此方式对不同数据项目的集合分组的优势在于，具有类似使用的数据结构可以被共同地操纵成好像它们是单个对象。如该图中所示，三个示例列表结构被示出为具有不同安全角色。

设备数据模型——元数据

设备数据模型允许开发者在名称、数据类型、默认值和有效值范围方面（即用于分析处理的规范化、生效和优化）描述与设备相关联的所有数据项目。

设备数据模型在该示例中可以采取三种形式：

● 类模型——其中提供针对设备的类（或类型）的数据模型；

● 群组模型——其中提供针对设备集合的数据模型（其中以某种任意方式限定设备的集合）。要指出，设备可以包括在多个群组模型中；以及

● 实例模型——其中数据模型特定于具体物理设备。

多个模型的先后次序可以遵循类-群组-实例，其中实例超越群组，群组超越类。

除数据类型信息之外，数据模型可以支持关于设备数据项目和设备能力的其它类型元信息。这可以包括：

● 信息性和描述性。这可以以现有方式简单地使用以对设备能力和行为进行证明（document），并且可以引用与设备相关的文档和信息的其它源。其在考虑不同设备类型之间的交互以及用于描述设备的分类学系统时具有令人感兴趣的应用。使用情况可以是有iBeacon（或类似物）能力的设备，其识别具体类型的设备并且当iBeacon检测到其识别并且其可以交互的设备时。这样的示例使用情况包括在汽车、收费系统和停车系统中的使用。

● 时间性。该信息可以用于描述数据项目的关键性以及设备管理器应当多频繁地尝试更新信息——示例可以是来自功率计的仪表读数，其中在24小时时段内要求至少一个仪表读数。包括时间性元数据属性允许连接系统与物理设备相呼应地操作、自动化数据收集活动以及用于优化（例如在低蜂窝活动的时间期间操作）。可以包括附加元信息以描述在特定数据项目的时间性要求不满足的事件中调用的警报动作。

● 安全访问控制和角色限定。该元数据可以用于填充用来提供授权和访问控制安全机制的相关联策略仓库。

● 安全整体性/机密性要求。附加的安全要求可能要求使用元数据来描述针对不同类型数据的安全管理规则和活动。使用声明式方案提供可以满足这些安全要求的通用解决方案。这可以包括：

○ 用于不同等级机密材料的加密机制；

○ 用于二进制数据的恶意软件扫描（传入以及传出）；

○ 针对特定类型数据项目（例如Javacard）的应用/设备等级机密性机制。这允许设备开发者在机制方面进行工程处理，从而支持数据和小应用程序代码以安全方式向和从设备的传递；

● 主要/次要生效——这些可以由设备的开发者用于限定设备可以保持的值的有效范围。还可以限定排除处置规则，并且这些可以支持默认值和警报动作。

● 公布权限。这可以是用于描述和约束如何使用设备数据的较高等级信息。这可以超过读取/写入/删除并且可以通过描述可以如何使用数据项目以及与其它系统共享而更具一般性。示例使用情况将是分发软饮料的连接壳体设备。如果设备的分发活动是公共可发布的，则这可以提供关于更宽群体行为的有价值分析信息。例如，每小时消耗的饮料的罐数可以相关于并且用作针对汉堡连锁店在接下来的30分钟内将售出多少个汉堡的预测子。声明式数据模型方案允许设备用户决定设备数据是否可以由第三方用于支持这些“较高价值”分析要求。

● 用于分析目的的数据的货币化。声明式模型允许数据点的用户理解数据点的值以用于分析目的（例如，使用之前的“碳酸饮料罐分发器”使用情况）。当执行分析时，分析算法可以向不同数据点分析和分配“权重”，其中权重可以指示数据点在预测某一值方面的价值。分配给与碳酸饮料罐售货设备相关联的数据项目的权重可能（例如）在预测汉堡销量方面为高，但是在预测将来市场上的咖啡价格方面为低。这些权重然后可以用于确定数据点的单独以及总体价值以作为分析预测子。这表示有机会向数据项目放置价值并且为数据点所表示的信息的拥有者提供针对第三方分析使用公开数据项目的动机。

● 存储/公开要求。这涉及公布权限元数据，并且限于限定数据项目值可以如何存档和存储以及存档和存储在何处。该元信息可以用于控制、管理、监视和实施私用要求。

● 处理线索和优化暗示。这是可以由物理设备（以及在那些设备上运行的软件的作者）用于描述可以如何处理数据项目的低等级信息。示例使用情况将是在精准的时间段之上平均的温度测量（例如移动平均）。为了计算移动平均，你需要存储所捕获的最后n个值的记录（其中n描述用于计算移动平均的之前值的数目）。如果设备管理器平台尝试这样做，则其可能需要连续地对被平均的信息进行采样（其将在连接和计算方面是昂贵的）。通过限定作为声明式数据模型的部分而聚集数据项目的方式，这允许设备开发者描述可以在设备上自动实现的低等级设备行为。（这假定设备上的代理软件已经实现成理解这些声明式暗示）。

● 序列化规则——描述可以如何复制/克隆数据项目。这些可以由弹性机制用于优先化哪些数据项目是重要以及还有用于促进复制和克隆的技术机制。

● 版本化信息。可以支持软件和/或固件更新，但是这样的活动可能难以管理，尤其是在软件或固件发行变换期间，因为这可以涉及对数据模型的改变。示例将是新的数据项目被引入以用于设备的固件的下一次发行。描述该新数据项目的元数据可以包括描述新数据项目将如何引入以及在发行之间变换的信息。

● 附加拓扑要求。用于表示集线器设备的数据模型可能要求以不可预测或自组（ad hoc）方式“插入”设备中的能力。该使用情况涉及M2M无线移动路由器，其已知为机器链接3G（ML3G）。这是向（任何类型的）其它设备提供以太网连接的集线器设备。潜在地，该连接可能包括向其它ML3G设备的连接，从而导致包括例如树、星和网状子网络的众多潜在拓扑模型。元数据可以用于描述设备连接附连点并且这些附连点应当提供到表示所附连的设备的等同DM结构的简单链接。该相对简单的方案暗示：

○ 附连到ML3G的每一个物联网（IoT）设备可以具有其自身的描述设备的数据模型；

○ 附连设备的逻辑相互关系可以使用父/子附连设备之间的双向链接使用DM数据模型来表示；

○ 附连设备向DM平台的物理通信可以使用（某种尚未限定的协议经由）父ML3G设备来调解。

以下应用示例将特征列表映射到OMA-DM数据结构上。在该应用示例中，M2M产品设计者已经开发M2M设备以用于监视向低电压消费者装置的12伏特电力供应。为了促进使用装置，他已经创建三个特征列表：

● 列表-场所——包含顾客位置和联系细节。该列表包含安全敏感信息（顾客的细节），因此在正常使用中将仅由要求知晓顾客细节的应用来使用。

● 列表-版本——包含描述M2M软件和硬件的版本的所有项目。该列表将典型地在执行诊断时以及在应用软件更新、补丁和修复时使用。

● 列表-传感器——该列表包含特定于该设备的传感器数据。

限定特征列表

设备的设计者将指定由设备支持的特征列表。该指定将描述数据如何从设备映射到特征列表数据结构中并且该映射将以适当方式描述（即使用XML声明注释）。例如，温度传感器读数可以映射到以上描述的列表-传感器特征列表中。在示例中，存在两个不同温度传感器，一个是意图测量M2M设备的温度的主板传感器，并且第二传感器设计成测量周围房间温度。

数据项目向特征列表中的映射还可以涉及某种数据处理，在温度传感器的情况下，映射可能涉及取得读数序列的平均，或者最大值读数。无关紧要地，机制允许设备开发者以角色特定的方式指定哪些特征可用于不同应用。

使用特征列表

不同应用可以利用不同特征列表。以上示例描述具有意图由三个不同种类的应用使用的三个不同特征列表的设备，每一个具有不同的安全访问权限。提供管理固件/软件更新机制的服务的第三方公司可能需要访问每一个设备的版本列表。这允许提供空中（OTA）更新机制的公司确认需要更新的设备的版本细节。第三方公司不需要知晓各种字段在版本列表中意指什么。所有需要知晓的是版本列表的内容需要在开始更新过程之前匹配于针对软件的特定版本的版本信息。

相同方案可以用于诊断设备缺陷，管理设备诊断过程的公司不需要知晓特征列表的内容，所有需要知晓的是将不同特征列表值映射到采取的动作上的方式。

通过提取数据值的身份以及它们表示什么，然后有可能利用特征列表数据上的高级分析，其使用受监管和不受监管的机器学习技术。对所捕获的设备数据执行分析的组织不需要知晓各种特征表示什么，相反地所有他们所需要知晓的是数据类型以及值的范围。单独从该信息有可能标识特征列表中的哪些特征在预测将来结果和趋势方面是重要的。

使用特征列表中的时间-序列数据

使用以上示例特征列表，存在称为列表-传感器的特征列表。普通地，这将简单地处理成“获取”当前特征列表值。特征列表的更高级应用支持使用时间-序列数据，由此周期性地创建特征列表项目（即每10分钟一次）。

多个行（实例）特征列表数据结构可以支持使用特征列表值的集合。这将为应用提供收集已经在一段时间之上所获取的数据的机制。

传感器值的集合可以按每10分钟（或者另一时间间隔）捕获并且应用将“获取”该数据以用于每天两次处理和分析。使用多行特征列表，设备开发者可以将传感器值的最新集合添附到多行特征列表中。查询这些数据的应用可以具有选择各个值或值范围的能力。

特征列表提供用于描述如何将数据映射到角色特定数据结构上的机制。描述和访问这些数据结构的许多机制从集合理论和关系数据库技术借用。通过提供声明式机制以描述将如何在设备（例如M2M）环境内组织和布置数据集合，其简化了在利用该数据方面所涉及的任务。除简化应用开发者的工作之外，其还简化安全过程，因为在两种情况下，特征列表数据结构可以使用基于角色的方案来安全化和使用。

该提取过程的结果是不再存在针对知晓如何组织数据的数据处理活动的要求，因为数据将总是以相同方式“供应”给应用开发者。开发者不再需要理解数据如何在装置上生成或者甚至数据表示什么。来自温度传感器的输出仅仅是用于处理的数目并且该数据的处理器不需要知晓其是可能指示将要起火的温度读数。相反，温度读数的处理器将仅仅看到超出最大值的数目，其继而可能触发适用于自动地发起向急救服务的呼叫的警报过程。

数据分析

不同应用可以以不同方式利用不同列表。图7的示例示出了具有意图由三个不同种类的应用使用的三个不同列表的设备，每一个具有不同安全访问权限。提供管理固件/软件更新机制的服务的第三方实体或公司可能需要访问每一个设备的版本列表。这将允许提供空中（OTA）更新机制的公司或实体确认需要更新应用的设备的版本细节。第三方公司不需要知晓各种字段在版本列表中意指什么。所有需要知晓的是版本列表的内容需要在开始更新过程之前匹配于软件的特定版本的版本信息。

相同方案可以用于诊断设备缺陷，管理设备诊断过程的公司或实体不需要知晓特征列表的内容，所有需要的是将不同列表值映射到要采取的动作上的方式，其借助于设计成支持设备诊断的触发/动作回叫机制。

通过提取数据值的身份以及它们表示什么，然后有可能利用列表数据上的高级分析，其例如使用受监管和不受监管的机器学习技术或者其它分析。对所捕获的设备数据执行分析的组织不需要知晓各种数据项目表示什么。相反地所有他们需要知晓的是数据类型以及值的范围（经由设备实例数据模型反映机制可用）。从该信息有可能标识列表中的哪些特征在预测将来结果和趋势方面是重要的。

数据模型SDK活动

设备数据模型可以包含许多复杂的数据结构、关系和属性，其将要求正确地且精确地维护技能。数据模型编辑工具可以由开发者用于设计、开发和维护设备。该数据模型工具可以创建描述设备的功能、数据项目、安全等的XML或其它数据结构，其可以作为设备数据模型实例对象的部分而实例化。

附加地，该数据模型可以用作用于描述物理设备120以及在其上运行的代码的处理和操作的机制。这可能要求数据模型工具创建可以由在设备上工作的编码器所使用的代码数据结构。

图8示意性图示了示例类对象结构210。

设备类实例

设备类对象215可以包含关于设备类型的通用信息并且其目的是充当针对涉及该类型的所有设备的所有活动的收集点。

设备版本实例

设备版本实例对象220可以链接到设备类型并且用于包含该版本等级处的所有设备所共同的信息。该对象可以针对在固件版本等级或版本等级顺序之间变换的设备而封装固件更新/应用逻辑。固件管理在该示例中经过三个阶段：

1）将固件加载到设备上；

2）在使固件操作之前在设备上进行检查以及任何其它准备；以及

3）应用更新——即，使其成为当前运行固件。该版本特定数据可以包括：

1）版本名称——这可以是ASCII串（空位结尾ASCII串）；

2）固件引用——对于将设备带到该固件版本所要求的固件二进制图像的引用；

3）数据模型——对描述该固件实例的设备的数据对象以及描述可以关联于该类型/版本的设备的数据项目的设备实例数据模型结构的引用。该数据结构可以用于在不同固件版本之间迁移设备实例数据。例如，这可以在新固件发行支持描述外部温度的附加数据对象的情况下发生。固件更新可以导致固件软件改变，并且其还将扩展设备实例数据模型以包括新温度设定、数据项目等；以及

4）到下一设备版本对象的链接——在设备需要变换到新设备版本等级时使用，所引用的下一设备版本对象可以描述变换到下一版本等级所要求的所有数据结构。这包括固件图像以应用在版本等级之间变换的数据模型之间的所有差异（添加、删除、改变）。

使用该声明式方案描述固件图像和固件图像之间的数据模型差异的优势包括以下能力

1）管理可以涉及多个固件版本的固件版本变换；

2）管理固件版本之间的设备数据模型改变；

3）提供逆转固件变换过程的能力，即，使设备卷回到之前的版本；以及

4）提供支持固件版本树的能力。这允许取决于要求而应用不同固件版本。

设备数据结构关系

对于特定设备类型，可以存在表示该特定类型的所有设备的单个设备类。可替换地，类似类型但是具有不同版本化要求的设备可以由多个设备类对象表示。在示例中，设备可以具有明显不同的版本化要求，诸如设计用于中文市场和欧洲市场的设备。设备可以视为完全不同的设备类型。

设备类对象215具有描述设备类对象的成员数据项目。这些成员之一可以是到设备版本对象的单个链接。

设备版本对象220将封装该版本等级处的特定设备的描述。该对象可以包含：

● 将设备的版本带到该版本等级所要求的固件图像；

● 该版本等级处的设备的设备实例数据模型（其可以限定和管理为xml数据，但是在内部其将使用例如java对象实现）；以及

● 到版本顺序中的下一版本对象（如果存在一个的话）的链接。

设备对象225可以包含：

● 对设备的设备类215和设备版本220的引用。

● 对该设备将需要变换到的目标版本的引用。

通常，这将是针对设备的最新的版本。

● 用于描述之前版本化动作的状态的版本状态字段。

● 用于控制设备将如何在版本之间变换的版本控制字段。

● 针对该类和版本等级的设备所限定的所有数据结构的设备实例数据。（如数据模型中所限定的，数据结构实例化在设备版本数据结构中。）

设备数据结构SDK活动

设备数据结构可以包含关于在不同版本之间变换固件所要求的设备的信息。用于管理不同数据结构的限定以及它们之间的关系的设备数据结构版本化工具以促进软件版本之间的自动化变换。

获取器/设定器/反映

所有数据结构可以支持在平台上可访问以及也经由北向接口160可用的获取器/设定器。在设备版本数据模型中描述的所有设备实例化数据项目也可以支持获取器/设定器。

获取器/设定器上的仅有限制可以是由基于角色的安全模型所描述的那些。设备的安全角色模型可以限定和封装到设备版本数据模型中。设备类、设备版本和设备实例对象中的所有其它数据结构可以支持适当的安全模型。

反映是查询数据类型和相关联的元信息的能力。反映可以支持用于访问设备数据模型。

序列化

所有数据结构可以是可序列化的。这是用于支持复制、备份和主/从配置的机制。

这允许多个DMAP服务器相互操作。所有数据结构可以序列化并且一旦序列化，则可以在DMAP服务器之间传递。该机制可以用于将DMAP服务器构造成：

1）主/从配置——其中主DMAP服务器接受NBi请求并且将通信序列化到从DMAP服务器；

2）经轮询的配置——其中DMAP服务器操作在相同等级处并且在它们之间传达实例数据；以及

3）转发器和代理配置。

备份、待机（热/温/冷）全部可以使用相同序列化机制以传达实例数据使得其可以在需要时被保存和修复。

警报、诊断和记录——触发动作

警报、诊断和记录全部可以使用相同底层机制，其限定将导致警报/诊断/记录事件发生的条件。这被称为触发动作。数据可以作为触发动作事件发生的结果而生成。触发动作还可以限定在哪里发送该数据。

触发机制

触发动作可以与设备类或设备版本实例相关联，从而意味着警报可以特定于全部属于相同类型的多个物理设备。还将有可能在逐设备的基础上限定触发动作。

触发动作可以在以下处限定：

1）设备类等级——该类的所有设备；

2）设备版本等级——特定版本等级处的特定类的所有设备；和/或

3）设备等级——各个目标设备。

触发数据结构——条件

触发可以是实例化并且命名数据结构，其中每一个命名触发具有与其相关联的多个条件。这些条件可以是简单的左值运算符右值三元组，其中：

● 左值表示变量（即设备数据项目实例对象）或另一条件触发

● 关系、逻辑或算数运算符

● 右值，其可以是左值或常量

示例条件触发可以是电压_传感器大于12。类似地，条件可以使用称为其它命名触发的布尔逻辑而成链在一起，即触发1和触发2。

触发数据结构——分量

触发可以被命名并且可以由触发条件列表构成。

触发动作数据结构

触发/动作数据结构可以用于描述要在触发条件被应用并且处理条件的结果是真的事件中执行的一个或多个动作。触发动作数据结构可以被命名并且可以包括以下中的任何一个或多个：

● 包括触发条件列表的命名触发数据结构

● 命名回叫

● 描述与触发设备数据实例相关联的实例数据的命名数据模型结构。

触发处理

触发动作处理可以以多个方式发起。在该示例中描述的机制是数据驱动的。

● 触发动作可以针对设备或设备集合来限定

● 设备数据实例数据可以更新或改变

● 可以继而处理与设备相关联的所有触发动作

● 如果与触发动作相关联的触发条件列表导致真，则相关联的数据结构可以填充有来自设备数据实例的数据（即具有相同名称和类型的所有数据项目被复制到触发数据实例结构中）。该触发数据实例结构的内容通过北向接口160而传达，如由触发动作回叫所限定的

● 机制可以用于确保该触发动作不会重复地激发。

其它发起机制可以用于处理触发，诸如背景处理，其可以迭代通过设备实例的整个列表，从而继而并且重复地测试每一个设备的触发条件。

南向接口170

受管理的设备——逻辑模型

DM平台的逻辑连接模型（参见图12，逻辑视图SBi）支持三个种类的通信。

1）唤醒——这是用于唤醒所标识的设备并且使其与DM服务器建立通信的机制。M2M平台安全模型可以仅允许从DM服务器使用SMS-MT来触发设备唤醒。这具有以下优点：设备可以仅经由M2M平台环境（具有其实施的P2P约束机制）而被触发以执行操作。该示例DM服务器触发唤醒的可替换方案是以唤醒触发来配置设备，使得设备在预限定的超时之后或者作为设备数据项目落入预限定范围之内或之外的结果而自动地触发唤醒。

2）设备SMS-MO——设备可以向DM服务器发送SMS消息。该机制可以用作套接字（socket）连接的可替换方案，其中传达给DM服务器的信息可以使用小数据分组表示。

3）设备到DM服务器。这可以是TCP/UDP客户端/服务器通信协议（可以使用其它协议），其中作为客户端起作用的设备可以建立与DM服务器的套接字连接。一旦建立连接，则客户端可以将数据改变传达给DM服务器，并且客户端还可以从DM服务器请求命令/控制/通信指示，其然后将对命令/控制/通信指示起作用。

受管理的设备——物理模型

示例数据通信类型包括SMS和互联网协议（连接或无连接）连接。物理连接路径将通过蜂窝承载商或者蜂窝和有线/无线互联网连接机制任一者。

图9示意性图示了示例物理连接布置。该示例包括用于与SBi 170对接的特定适配器。这些适配器连同SMS移动终止（SMS-MT）唤醒命令230和蜂窝网络之上的IP连接240一起可以使用在M2M设备上限定的APN连接。一旦从设备向DM服务器环境中创建APN设备上下文，则设备可能能够建立到DM服务器中的客户端服务器连接。

SMS唤醒机制

图10示意性图示了从DM服务器到设备的唤醒SMS的过程260。在该示例中，用于发起向设备（附连到PLMN网络）的通信的仅有连接路径是经由从M2M平台DM服务器环境到设备的SMS-MT。

图10示出M2M应用（DM服务器）发起SMS-MT生成。这可以由多个条件或准则触发。一些可以由例如经由北向接口160所请求的顾客动作发起。可以触发设备唤醒的其它条件可以作为指示要求一些设备交互的设备数据模型结构的结果而自动地开始（例如，实例数据可以因为其过时而要求更新）。可以应用规则，包括仅全局数据服务平台短消息对等（GDSPSMPP）客户端应用可能能够向GDSP SIM发送SMS移动终止（SMS-MT）。此外，GDSP SMPP客户端应用可以受约束使得其不能够例如向任何其它数发送SMS-MT。

从设备到DM服务器的SMS

使用M2M平台SIM的设备可以受约束使得它们仅能够向DM服务器发送SMS移动起源消息（在图11中，这被示出为M2M应用）。这可以用作从设备向DM服务器的可替换通信路径以用于要求它的情况。

图11示出从设备120向DM服务器发送SMS的示例过程270。该示例可以包括以下规则：GDSP SIM能够仅向由SMS中心（SMS-C）上所限定的GDSP SMPP客户端应用发送移动起源SMS（SMS-MO）。

以上规则可能意味着SMS-MO通过去往顾客服务器上的M2M应用（DM服务器）的M2M平台设备而发起。

设备到DM服务器IP连接

设备可以使用连接和无连接协议而支持设备到DM服务器IP连接240。当通信通过蜂窝网络发生时，设备可以建立APN设备上下文并且通信可以在该设备上下文之上发生到DM服务器上所表示的所标识设备实例对象。

对于有线和无线IP连接，可以使用设备与设备服务器之间的相同客户端服务器关系。

受管理的设备——设备类型

在一个示例实现中，可以存在三种类型的逻辑设备连接类型：

1）适配器/设备代理连接，其中存在SBi 170之上的DM服务器到设备之间的一一逻辑设备适配器连接，其使用支持对适配器和代理二者所共同的协议的代理。例如，OMA-Lite、TR-069、SNMP或另一（例如专有）协议。

2）适配器/适配器连接，其中存在到第二DM服务器的连接。在该配置中，第二DM服务器管理适配器/设备代理连接，并且数据项目从第二DM服务器传达到第一。这可以被视为主/从配置。其中最顶部的DM服务器是主，下属DM服务器是从，并且两个之间的通信使用数据对象序列化机制来促进。

3）图12图示了SBi 170的逻辑视图。第三种类型的逻辑关系是其中设备作为针对多个其它DM平台130、装置和设备120的网关而起作用，例如智能仪表通过I2C、RS484、RS232、ODB2或其它总线来控制多个其它外围设备。该最后示例是第一设备逻辑连接类型的扩展，但是其中到外围设备的物理连接通过受管理的设备120而提取。

设备数据提取

设备数据提取机制允许DM服务器虚拟化物理设备的图像，该数据提取机制涉及作为实例数据的DM服务器的设备视图，其中该实例数据的内容使用设备数据模型描述语言（例如基于XML）以声明方式描述。这然后允许应用经由实例数据间接地与物理设备交互。

针对设备管理的该声明式且间接方案具有多个益处。尤其是，其允许设备开发者/销售商借助于设备数据模型描述设备及其功能。

该设备数据模型方案可以由多个不同的应用协议所支持和使用，例如包括OMA-Lite、TR-069和SNMP。

该提取机制可以扩展成支持不必由所有底层通信协议所支持的附加属性。例如，OMA-DM支持基于角色的安全模型，但是SNMP和TR-069不支持。通过使用支持安全角色属性的数据模型，其提供与支持其的应用协议的兼容性，而且其还可以用于使用不支持其的应用协议的设备。

图13示出用于表示SNMP受管理设备的示例管理信息基础（MIB）数据结构320的部分。该应用管理协议可能不支持基于角色的属性。

支持附加属性

使用SNMP协议的设备可能仍旧使用支持安全角色规范的数据模型，其仅仅意味着设备可能不支持该基于角色的机制。其仍旧具有值，因为设备开发者现在可以根据MIB规范描述设备的数据模型并且可以在适当的情况下覆盖附加元信息。

数据模型和网关设备

如之前所描述的，设备可以作为针对多个其它外围设备的集线器或网关设备起作用，其中这些外围设备经由多种不同通信机制而连接。在该情况下，数据模型可以适应（accommodate）网关/集线器的该扩展视图成好像这些外围组件是相同数据模型的部分。集线器/网关与外围设备之间的所有通信然后可以被提取并且对于DM服务器和访问它的任何应用而言透明。在要求或期望控制/状态机制的情况下，这些可以类似地并入到设备数据模型中。

数据模型的设计者/指定者应当准确地描述设备的/集线器的数据模型使得其反映功能。

设备/南向接口层（SBi）170

设备/南向接口层提供DM平台与设备120之间的链接。设备接口层在该示例中执行若干功能：

● 服务来自较高等级层的API请求并且返回结果

● 确保请求仅与请求者的安全角色一致地执行

● 确保从多个源向物理设备的多个请求正确地同步

● 确保高效地管理设备连接

● 支持（潜在地）大量不同销售商供应的装置

● 支持经由其它DM平台的对接

用于该层的模型示意性地示为图14中的设备接口模型330。

在该图中示出的不同组件包括：

● 设备接口340——这是较高等级请求者可以使用以通过NBi 160查询和访问设备的设备对象的实例（NBi 160提供用于使应用获取/设定设备实例数据的机制）。设备接口340可以包含分离元件

○ 设备请求者对象350——这在其安全角色和套接字通信链接方面描述进行请求的代理。

○ 设备代替（surrogate）300——包含设备的标准表示。该表示可以对所有销售商设备是共同的。

○ 销售商适配器310——每一个销售商可以具有包含所有设备依赖功能的唯一子类适配器。

○ 设备连接360——包含描述SBi连接的所有数据对象。典型地，这可以是套接字连接对象加上任何其它信息，诸如未决SMS唤醒的状态、APN连接的细节、或者连接的类（有线/无线/蜂窝）。

图15示意性图示了设备接口适配器/代理模型。描述物理设备的该“代替”方案从可以用于对设备执行操作并且查询设备的API解耦合设备的销售商特定特征。设备特定逻辑在该示例中使用适配器设计模式而类似地放置在对象中。因此，这可能导致模型-视图-控制器（MVC）解决方案，其既是使用起来简单的，又可以与不同类型销售商装置一起使用。代替对象300包含保持在物理设备上的数据的表示。

该设备数据模型将使用XML注释最佳地描述。设备对象的实例可以在运行时间或者可替换地在编译时间使用XML注释。数据模型可以限定映射到OMA-DM/LWM2M数据模型上的变量的集合。数据模型可以包括例如访问控制列表（ACL）结构。

可以有可能的是使用所有权模型以在数据结构上实施ACL。然而，较为简单的方案是创建包含设备代替对象和提出查询的请求者的表示的更高等级对象。该请求者对象还可以包括请求者的安全角色。

查询设备的版本可能遵循以下示例操作顺序：

● 应用需要查询特定设备的版本。

● 应用调用针对设备类的API获取器——获取器输入参数指定唯一设备id和字段名称（该示例将查询称为版本的字段）以及请求者对象。

● 检查允许请求者对象的角色访问设备的字段。如果否，则掷出安全排除。

● 如果设备代替对象300的实例存在并且版本数据及时，则返回保持在代替实例数据中的设备版本信息并且退出。（NB，不存在查询实际设备的要求）。

● 如果设备的实例不存在——使用构建器创建模式来创建设备实例。构建器可以使用预限定的设备子类（编译时间实例）或者使用XML来创建运行时间设备实例。构建器可能需要实例化代替对象30和适配器对象310二者。

● 设备实例存在，但是虚拟化版本信息不是最新的。因此，适配器对象向M2M平台提出请求以向具有终止于DM平台中的分组数据协议（PDP）上下文的物理M2M设备发起设备SMS唤醒。

● 创建设备与DM平台之间的设备上下文。

● 设备使用其唯一设备id来标识它表示的设备。该信息用于选择表示物理设备的DM服务器上的设备实例。连接对象然后被分配给设备连接请求者对象。从设备到DM服务器的所有通信现在直接链接到表示设备实例的数据结构。

● 物理设备和DM服务器设备实例现在可以直接通信，并且设备可以将针对设备的数据结构的值传递给设备实例。这可以优化以上载所有数据或者仅被立即要求的数据。

● 向进行请求的应用返回版本_获取器功能的结果。

该“代替对象”方案的优点在于：

● 其实现起来更简单。

● 其支持对设备数据的多线程访问——可以总是最多存在设备的数据模型的单个实例，但是可能地多个代理一次查询该数据。互斥区可以操作在获取器/设定器内以确保正确同步。

● 其可以用作管理基于角色的安全模型的机制。

● 数据模型可以使用XML或其它注释来限定，因此命名机制可以用于与所有M2M设备数据结构相互作用，包括配置参数、固件和应用。这简化并且标准化设备管理功能。

● 其适用于众多性能优化。

● 其支持多个销售商产品。

销售商接口——设备提取

架构模型可以提供针对多于一个销售商的设备的接口。不同销售商的产品可以具有不同能力并且在一些情况下非常不同的功能。优选地，所有设备可以支持基于标准的通信协议。

每一个销售商装置类型可能要求其自身特定的设备适配器类并且每一个物理/虚拟设备连接可能要求代替300和适配器310类二者的实例对象来表示该连接。

可能要求若干类型的适配器类。图15图示并示例设备接口适配器/代理模型，其可以是：

● 标准服从——即单个适配器类可以用于支持OMA-DM标准的所有销售商设备。

● 非标准——即以非标准方式连接到销售商设备的适配器。

● DM到网关/集线器。

● DM到DM——并非所有适配器都可以连接到端点设备。可以存在对经由其它DM平台（例如iDigi、Redbend）与销售商设备通信的要求。

使用代替-适配器模型提取DM平台到设备连接意味着较高等级的应用可以全部使用相同API访问设备。

架构变形

DM服务器可以用于表示作为虚拟化设备实例的许多不同物理设备。该设备实例数据是易失性的并且可能已经在延长的时间段之上被创建。由于它们表示的物理设备不可用（例如由于它们已经关断）而尚未更新的设备实例可能是非常古老的。

如果DM服务器重启，则存在所有这种缓存的设备实例数据丢失的可能性。这种情况下的补救措施将是从物理设备（再次）再获取虚拟化设备数据。数据可以永久性存储在M2M平台中，例如在一些数据库中。由于设备实例数据全部是可序列化的，所以其可以存储在任何地方——包括在其它DMAP服务器上。

可替换地，设备实例数据可以以其它方式再获取。

设备实例数据恢复机制

存在可以用于恢复和分布设备实例数据以便改进系统可用性的若干示例方案：

● 简单备份/修复——DM服务器支持将所有数据结构备份到次要存储装置的机制。所有设备实例数据可以序列化并且该序列化数据可以保存到盘。一旦保存，则序列化对象可以在重启之后在相同DM服务器平台上再创建。可替换地，序列化数据可以用于建立恢复点并且用于在可替换的备份DM服务器平台上再创建实例。这种向所存档的恢复点的修复过程可以在冷、暖或热待机模式下运行。

● 复制——DM服务器的序列化设备实例数据结构可以传递到复制DM服务器平台。该复制次要DM服务器可以经由其北向接口160而以与主要DM服务器平台确切相同的方式来访问，但是其将不具有南向接口。（然而，其将支持SMS唤醒机制）。

● 主/从——这类似于复制服务器配置。差异在于，在该配置中，从DM服务器可以支持南向接口170并且所有设备实例数据可以使用适配器/代理DM与主DM服务器平台通信（DM通信链接，其中序列化实例数据从从传送到主服务器）。

● 混合型——DM服务器可以配置成支持以上针对不同设备所述的不同架构配置。服务器软件可以在云中运行以利用弹性计算。如果负载增大，则DM服务器软件性能通过为附加物理服务器上的这样的软件通电而增大。等同地，当不需要时，这些附加服务器将不被使用。那些服务器上的数据不应当丢失。因此，可能要求永久性数据存储。

更新软件

维护、管理和支持针对设备的软件的多个版本可以通过本系统实现。此外，DMAP60已经设计成简化并且减少该活动的成本。

描述了可以用于支持固件管理的机制。其它类型软件可以使用类似机制。这样的更新可以包括但不限于：

● 操作系统，完全刷新或者部分更新

● 其它类型固件，例如基于闪速的FPGA/硬件图像，如在某些路由器上所使用的

● 应用软件

固件更新是要求版本管理的一种软件资产。这具有附加复杂度，尤其当涉及许多不同版本的许多不同设备时。另外的管理复杂度可能针对已经由用户安装的应用软件而出现。

以下描述的机制被设计用于管理固件；然而，这些示例机制和原理可以扩展成在要求的情况下支持其它类型的软件资产。

支持设备应用软件版本和固件版本管理。

固件更新调度器/调度

固件更新可以在特定时间窗口期间被管理。具体地，固件窗口可以限定和关联于设备真实领地。例如，这可以是在逐国家的基础上，或者所有设备可以相对于特定时区而更新。

改变到新版本的软件或固件可以涉及两个阶段过程：

1）将新软件传递到平台；以及

2）重启系统，因此现在它使用新软件。

重启可以以若干示例方式触发：

1）自动地——但是这可能影响系统的用户。如果系统正用于关键任务，则这可能引起问题。

2）在用户控制之下或者遵循用户确认——这要求人类用户做出决定。

3）当最适宜时。软件图像可以在装置下一次重启时起作用。

软件卷回到之前发行可以在管理O/S更新时实现。该要求针对所有软件管理活动而被满足。

为了支持该要求，可以包括设备版本对象中的附加参考结构（参见图8中的225）以便支持后向链接。设备对象还可以包括对卷回目标版本的引用。

固件更新示例

设备销售商、应用或用户可以创建针对设备的固件的新的且改进的版本。销售商将测试该固件直到他确信它足够鲁棒以部署在实况环境中。部署固件版本的阶段然后可以包括（要指出，以下描述仅是说明性的）一系列步骤以使用声明式方案表示更新以及所有相关联的活动。更新可以连同更新数据对象中的所有依赖性和动作一起限定。更新数据对象然后可以链接到描述该更新与之前的更新之间的关系的网络数据结构中。一旦更新以及其与其它更新的关系完全限定，则DM平台可以处理这些数据结构以自动地使物理设备变换通过更新操作顺序。

这些活动可以细分成：

● 创建针对该固件发行的设备版本对象。这是描述特定软件更新连同所有其依赖性的更新对象。设备版本对象可以具有成员元素，其描述：

○ 固件图像，其将是固件代码的二进制图像

○ 该版本等级处的设备的数据模型

○ 针对该设备版本的设备的设备类

● 创建从之前的设备版本对象到该设备版本对象的链接。该链接描述该更新与其它之前更新的关系，例如以将设备从版本a更新到版本c。更新顺序将是版本a到版本b，然后最终版本c。可替换地，可以存在从版本a直接到版本c的更新路径。在任何情况下，该链接描述之前更新之间的更新变换以便将装置更新到最新版本。

● 修改现有设备实例（在测试中的该阶段处，该设备实例可以是测试装置）并且配置实例数据项目设备版本目标，使得其引用表示该新固件更新的新设备版本。

● 修改设备实例版本控制设定以指示其应当将设备从其当前设备版本变换到其新设备版本。该步骤以及之前的步骤可以向系统告知其需要更新该测试设备。

● 触发固件调度器以开始运行。

固件调度器过程可以迭代通过所有设备实例，从而在要求的情况下调用固件变换。设备对象225可以包含引用当前版本的数据对象以及针对设备类和这些的固件图像的目标版本对象。一旦已经将设备实例标识为针对设备版本变换的候选者，则一系列活动可以发生。

● 捕获当前版本处的设备的设备数据模型。在数据模型中描述的所有数据项目可以从设备读取，使得其值是当前的。可以应用的货币要求和其它元信息可以在逐项目的基础上限定。

● 新设备数据模型使用针对软件的目标版本所限定的数据模型来创建。这可以与之前的版本确切相同，或者可以存在旧与新之间的多个差异。在任何情况下，新设备数据模型可以包含充足细节以能够克隆旧数据模型并且应用对于将其带到新设备版本目标数据模型所要求的所有/任何必要修改。

● 新目标固件图像被传递到设备

● 设备加载固件图像并且重置

● 所要求的所有/任何数据结构改变被传递到设备

● 设备数据结构被更新以指示固件已经变换到新版本。

该过程的优先化和调度可以适当地提炼。可以实现以更复杂的方式扩展功能以管理固件管理活动。

固件更新——SDK活动

该系统的另外的特征和益处可以包括：

1. 虚拟化物理设备提供改进的方案。

2. 利用设备数据模型工作也是改进。

3. 任何“现成”应用管理软件可能需要在NBi总线及其能力方面实现并且将要求设备销售商支持标准化或通用数据模型。可以实现版本管理工具。

4. NBi、验证和检查第三方用户身份等可以再使用现有AAA或者身份管理机制。当使用代理服务器时，第三方（用户或应用）可以经由NBi获得对代理的访问。类似机制可以使用在M2M平台中，其中外部用户也获取对运营商平台的访问。公共系统组件的再使用因此避免烟囱式解决方案和各种系统组件的白手起家，诸如支持登录和验证的那些。

5. 对于外部用户或顾客而言，可以存在单点登录（SSO）能力使得一旦他们已经登入M2M平台的使用，则他们可以登入DM代理的服务。

6. DM代理系统本身的架构和设计可以是模块化的。

7. 处理引擎的“成云（cloudification）”可以提供附加益处。例如，如果设备数目（例如TR-069设备）明显提升，则这可以是有利的。TR-069或者其它适配器然后可以要求更高性能并且因此应当更容易放大其并且这使用云的弹性计算而可能。另外的优选特征可以是，TR-069适配器过程可以增加到具有这些适配器的云中的附加服务器上，所述适配器能够以常见方式与DMAP的其余部分通信。

类似地，如果结果是大量顾客喜欢设定针对M2M资产的警报并且触发处理要求更高性能，则这可以使用弹性云计算利用按钮的按压（或者以自动化方式）而适应。再次，触发处理组件然后需要可标识为需要分配更高总体性能的一个。

弹性计算和DMAP处理引擎的内部组件可以具有适用于云内部通信的良好限定的接口。这使用序列化机制来支持。

8. 如上文所提及的，为了“看到动作中的整个DMAP”，可以提供高等级消息流动图（使用一些现成工具）。这可以例如示出顾客→NBi→DMAP处理引擎→SBi（代替→适配器→TR-069/LWM2M）→设备管理客户端结构到不同泳道之间的交互。

9. 设计可以是灵活的，例如：

a. 针对云部署准备就绪（readiness）的设计

b. 针对缩放性和性能的设计

c. 针对关于DMAP特征范围的扩展性的设计（包括充当用于数据分析的架构中的某种角色的代理，或者业务对象的中介（brokerage））。

d. 针对数据模型的扩展性的设计：为了应对将来、尚未知晓的M2M资产和设备出现。

e. 针对安全性的设计。

f. 针对可靠性和回弹性的设计（这可以通过经由适当SLA的在IaaS顶部上的部署而自动发生）。

附加示例特征可以包括加密搜索，其中搜索项（和/或结果）被加密。这可以扩展到加密诊断/记录/警报/机器学习。加密数据可以在中性第三方平台上检验并且动作决定可以基于加密输入数据而做出。示例可以是分析公司对加密输入数据执行分析并且推导结果而不具有输入或输出的纯文本的任何知识。

也可以使用同态加密，因为这允许对加密数据执行任意计算（例如通过非受信方）而不破坏加密。

可以提供机制，所述机制允许运营商限定将训练仪器并且核实正确操作的测试。例如，存储器校验和测试可以收集跨存储器的部分使用预限定的多项式CRC检查所生成的存储器签名。存储器校验和功能是有益的，因为其可以用于确认软件版本并且其可以用于确认仪器上的存储器读取操作的正确行为。

系统提供将数据值集合映射到单个列表结构上的方式使得特定于具体任务的所有信息一起被收集并且可以在单个查询中访问。

在以上所述的两个要求的上下文中，可以创建具有所有版本特定数据的列表数据结构，其包含可以唯一地标识装置并且可以包括存储器校验和（以核实安装了特定版本的软件）的所有特征和值。可以创建第二列表数据结构，其包含涉及标识正确操作以及诊断不正确操作的可能原因的所有特征和值。

描述这些基于角色的列表数据结构包括以下益处：

1）简化应用开发者任务；

2）简化安全控制的管理和应用；以及

3）减少对于访问装置上的数据所要求的网络资源。

诸如有M2M能力的装置之类的设备提供标准化诊断、监视和管理功能使得可以以商业有效的方式管理它们。

系统的属性可以包括：

1）核实设备和M2M装置特别地是针对软件更新的候选者的高级核实机制。当前的方案是编程到软件/硬件版本信息中并且虑及查询该信息。当前方案缺乏精确，但是通过使版本核实过程更精确，其将减少潜在昂贵的错误发生的可能性。

2）提供充足数据以使得能够以设备独立方式实现复杂的错误检测和预测的增强诊断过程。当前的方案要求运营商具有装置、它如何工作以及在诊断出故障时查找的症状的一些知识。这典型地手动的过程依赖于具有随时间改进的经验的有知识的运营商。所提出的增强将允许运营商以设备独立方式执行诊断，从而要求例如设备如何工作以及在哪许多诊断活动可以使用人工智能技术来自动化的最少知识或理解。

3）促进在管理平台上由平台运营商使用复杂机器学习技术的增强数据查询过程，其中目的是标识要以及时方式采取的动作。故障诊断是一个应用，但是潜在地存在针对这一益处的许多其它应用。

4）以设备独立方式提供复杂装置侧警报的增强警报过程。

5）简化使用这些过程的方式的以上所有增强的管理，使得信息流遵循具有确保等级的整体性和机密性的基于角色的安全模型。

6）可以提供以上所有增强使得DM平台的运营商不要求可见或理解所管理的装置。

技术方案

为了限定用于从设备（例如M2M装置）收集数据值的标准机制，使得单个查询可以用于获得对多个值的访问。这些数据集合可以被称为特征列表，如上文所述。

为了限定用于指定将被映射到特征列表中的数据值和数据签名值的标准机制。

为了限定用于查询描述特征列表的元素的元信息的标准机制，例如类型、访问权限、值范围等。

为了限定用于描述特定列表等级处的访问权限以及获得对它们的访问所要求的验证要求的标准机制，这样以便保护由特征列表的内容所表示的信息的整体性和机密性。

为了限定用于描述不同特征列表中的特征之间的联接的标准机制，使得包含在不同特征列表中的信息可以被组合用于分析目的。

为了限定用于指定针对设备和M2M装置的签名数据值的标准机制，使得可以确认关于装置和其表示的资产的健康的信息。

共同地，这些扩展可以允许使用复杂分析。

根据一方面，提供一种允许M2M设备的开发者以这样的方式映射数据值的机制：所述方式使得适于将使用该数据的方式。机制可以允许设备或M2M平台运营商提供自动化系统以用于预测由设备或M2M平台运营商所监视的装置中的故障，而不要求该运营商具有对所监视的装置的任何知识或理解。

这可以允许将故障诊断和预测服务提供给在最终顾客房产中部署M2M装备设备的第三方。作为对该系统的扩展，其可以与业务逻辑集成以允许以应用特定方式的附加警报和预测能力。

系统和设备的一个目的是提供用于将未经组织和层级组织的数据结构映射到适于应用用途的关系组织的列表结构中的通用机制。

该设备的应用将是基于过去活动来预测其监视的装置和事件的将来行为。目的可能是例如以自动化方式针对正确操作监视装置或者其可能用于预测逼近的应用特定事件，诸如针对家用的电力要求的增大。

机制将允许运营商在一段时间之上捕获和记录装置的行为，使得来自装置的将来结果可以以对具有装置或其操作的任何知识的运营商没有任何依赖性的方式来预测。所预测的结果可能涉及所监视的装置的正确操作或者其可以是具有某一值的某种其它预测（例如预测/标识医疗紧急情况）。

示例：

i）条款1

一种设备，其将数据值映射到线性列表结构中使得列表结构的内容可以被收集和分析而收集过程或分析过程的运营商不要求对数据表示什么的任何知识。

要指出，这些数据值在以下示例中随后被称为特征。特征的集合被称为特征列表。

ii）条款2

多种特征类型适于表示不同类型的信息。

iii）条款3

特征列表和特征将具有相关联的元数据，其足以以将促进第三方对特征数据的处理的方式描述特征，而第三方不要求应用等级知识。说明性元数据将包括特征数据类型、可能值的范围、描述性信息等。

iv）条款4

一种机制，用于以便于最小化用于描述该特征数据的存储器存储要求的这种方式来描述特征数据。在校验和的情况下，仅必要的是记录校验和是正确还是不正确并且该特征数据项目可以被描述为单个位。这给予以下优点：减少对于记录和传达所捕获的特征数据所要求的存储量。

v）条款5

一种机制，用于将特征数据项目的集合描述成特征列表，包括单个压缩值顺序。这给予以下优点：最小化为了使M2M特征数据收集机制从装置收集相关特征的集合而不是做出多个请求以查询多个传感器、CRC校验和等所要求的通信交易的数目。特征列表收集过程将做出单个获取特征数据通信请求，并且针对所请求的特征列表类型的所有特征数据将在单个交易中收集。

vi）条款6

一种机制，用于描述多个特征列表，使得收集机制可以请求特定特征列表以收集，其将是完整特征集合的子集并且仅包含与其被收集的目的有关的特征数据项目。

这将允许不同特征列表收集代理收集适于其要求的特征列表。例如，医疗装置可能包含患者敏感信息，诸如位置和个人身份，其将对于医疗诊断和传染病学目的而言是有价值的，但是仪器销售商所不感兴趣的。在这样的实例中，一个特征列表将被收集以用于由硬件销售商使用和分析来确认装置的正确操作，并且第二特征列表将由医疗从业者收集以用于医疗聚焦分析的目的。

vii）条款7

一种机制，用于分配不同特征列表上的不同访问权限使得不同动作者具有对不同列表的不同访问权限，其中应用适当等级的机密性和整体性。

viii）条款8

一种机制，用于查询、修改和删除特征。使用特征列表描述感兴趣的特征值。使得不同动作者具有对不同列表的不同访问权限，其中应用适当等级的机密性和整体性。

ix）条款9

一种机制，用于标识故障电路并且使故障和故障类型与之前已经依照条款3所收集的特征信息相关联。这在随后的条款中被称为结果数据。

x）条款10

一种机制，用于标识除电路故障之外的结果数据，如在条款9中所概述的，诸如医疗紧急情况逼近并且所监视的患者要求紧急关注的指示符。

xi）条款11

依照条款10，假使没有其它结果，诸如家庭没有高效地使用电力供应并且将推荐能量审核的指示符。

xii）条款12

一种过程，其虑及使用多个签名来描述电子装置。这些签名可以以各种方式生成。签名将以设计成以唯一方式最佳地描述对象的数学适当方式来生成。一种机制将使用循环冗余代码（CRC）与预限定的多项式组合来生成签名。

xiii）条款13

设备将使用多种特征类型，以描述电子电路的多个特征。这些特征类型可以包括：

1）针对计算机存储器区中所保持的值所生成的校验和

2）从预限定输入顺序的引入之后的电路的顺序数字输出所生成的校验和

3）存储器中所保持的特定值

4）由电路生成的特定值，例如温度读数

5）依照4）已经被处理以便提供附加值的特定值，例如平均或最大-最小函数。

xiv）条款14

分析阶段，其将使特征列表与结果数据相关，其中目的是标识将预测特定结果成果的特征值改变，诸如仪器项目将在4小时内失效，或者糖尿病患者具有低血糖昏迷的风险。

该分析阶段将使用数学过程（线性回归分析和逻辑回归分析）与机器学习技术（神经网络）结合来标识哪些特征在预测和标识结果方面是重要的，诸如有M2M能力的装置的可能逼近故障或医疗紧急情况。

要指出，重要的是理解系统没有对在分析阶段期间知晓特征是什么的依赖性并且该分析活动可以完全或部分自动化。

xv）条款15

一种机制，用于描述在装置展现出如在分析阶段（依照条款14）期间所预测的故障的症状的事件中采取的动作。诸如向支持人员发电子邮件，或者提出故障报告表。

xvi）条款16

在自动化补救动作的事件中（即升级软件版本或者禁用/启用特定仪器特征），系统将发起该补救动作。

xvii）条款17

一种机制，用于描述多个特征列表之间的联接使得一个特征列表中的特征可以与另一特征列表中的特征相关。

xviii）条款18

一种机制，用于描述针对特征列表的位置信息使得位置信息的编码准许特征列表之间的相关，但是不公开真实物理位置。

xix）条款19

一种机制，用于相对于预限定的秘密参考点以三个或四个维度描述位置的位置信息。这将促进以所分析的实际地理位置匿名的方式通过位置对数据的分析。

xx）条款20

一种机制，其允许外部设备与实现本发明的设备通信，诸如以使得其能够改变特征中的特征项目值。这样的特征列表可以称为可写特征列表。

xxi）条款21

一种机制，其使特征列表中的特征值选择性地发起要执行的动作。这样的特征列表可以称为动作特征列表。动作特征列表的示例可能包含三个特征值项目，包括：

1）开始时间

2）结束时间

3）关断电传感器的动作

现在描述总体架构的另外细节，并且其可以包括：

- 用户（例如垂直体）与设备管理-DM-平台（例如DMAP）之间的第一接口（例如北向接口-NBi），所述接口允许管理一个或多个设备（例如M2M设备或管理M2M设备的集线器以及其它DM平台）；

- DM平台与（i）第二DM平台或者（ii）一个或多个设备之间的第二接口（例如南向接口-SBi），其中第二接口可以是安全的。

换言之，第一接口允许用户与受管理的设备（例如物理M2M资产）之间的经由DM平台的通信。

架构还可以包括DM平台。DM平台可以包括DM服务器。

DM服务器包括但不限于以下功能：

● 一个或多个设备的管理（直接或间接），例如包括设备的集合、设备的注册/解注册；

● 与以下的通信（直接或间接）：（a）用户（通过第一接口）和/或（b.1）一个或多个设备；或者（b.2）第二DM平台；

● 另外设备的发现；

● 设备的监视、与用户的通信的触发以用于管理设备（例如响应于观察要监视的一个或多个条件集合）、在一个或多个设备处更新软件/固件。

DM服务器还包括允许各种功能恰当地工作的机制和结构。DM服务器可以实现为硬件平台、软件平台和/或云服务（例如云托管的、作为服务的软件等）。

第二接口包括但不限于以下功能：

● 管理通信的安全性并且检查通信实体的授权；

● 处置多个请求；

● 高效地管理设备。

数据模型和代替

提取的模型结构

限定和/或生成提取的层级模型结构使得其可以用于寻址要通过设备管理平台而管理的任何设备和/或功能。层级模型结构然后可以用于导出要在特定等级（例如垂直应用等级、DMAP等级、协议等级、设备等级）处使用的特定模型。换言之，相同结构可以用于表示与设备（例如M2M设备）的管理相关联的信息，并且然后“经转换”使得其可以适当地用于正确等级，每一个等级具有特定要求。

使用代替的通信模型

一般概念是通过使用DM通信的接收实体的“代替”（例如M2M设备、另一DM平台、控制一个或多个设备的集线器），两个接口上的通信可以以显著方式分离并且简化。

特别地，“代替”是DM平台的框架内的接收实体的复制品，即，其符合统一数据结构（例如提取的模型结构）和/或针对第一接口（例如NBi）所限定的统一协议。“代替”与接收实体的实例相关联。

以此方式，用户与DM平台之间的通过第一接口（例如NBi）的通信可以使用仅符合统一数据结构的类似消息来执行，而独立于实际接收实体使用的是什么数据结构。用户有效地与“代替”而不是与实际接收实体进行通信。

类似地，DM平台中的“代替”将通过使统一数据结构“适配”为对应接收实体所使用的特定数据结构来在第二接口之上向其对应接收实体进行通信。这通过适配器的方式而完成。

附加机制

设备的离线监视

一种机制，用于允许DM平台基于用户所提供的指示来“代表”用户（例如垂直应用20）监视设备，并且然后在DM平台标识满足指示中所提供的某一准则时将信息提供回用户。

机制可以包括DM平台从用户或应用接收指示，其指定要针对一个或多个设备监视至少一个准则。指示可以包括指定方式以便一旦已经满足至少一个准则就联系用户。指示可以通过异步连接的方式提供（例如连接基本上设定成提供指示，但是不接收由至少一个准则触发的响应）。DM平台基于至少一个准则监视一个或多个设备120。DM平台响应于满足至少一个准则而联系用户或应用。指示可以是触发。

固件更新

升级设备上的软件（因此，其是最新的）的能力是设备管理的高度有价值且重要的特征——但是如果你具有全部处于不同版本的数千个设备，则难以管理。

DM平台使用声明式方案来管理针对设备集合的软件/固件管理，其支持不同设备类型、在更新期间执行的不同动作顺序以及最重要地描述更新操作应当发生的顺序的状态机（即，你需要在哪里使设备变换通过多个更新以便将设备带到最新发行等级）。

唤醒消息——安全数据的递送

这是直接经由唤醒消息（即，用于唤醒“休眠”设备的消息）递送安全参数的机制。消息可以是例如SMS消息。该消息由DM平台发送以便触发设备与DM平台之间的连接（例如UDP连接）。

特别地，当使用SMS消息时，如果不存在现有SMS密钥（即SMS信道尚未安全化），则消息可以包含通用引导程序架构（GBA）推送类型信息（因为不需要安全化SMS）。另一方面，如果存在针对SMS的现有密钥（即SMS信道已经安全化），则消息可以包含任何类型的安全信息。

在3GPP TS 33.223章节5.2.1中描述GBA推送信息。编码在章节5.3.5中限定。特别地，参见3GPP TS 33.223 V 12.0.0 (2013-12)的表5.2.1.1和图5.3.5.1，其可以在以下找到：

机制还可以包括确定SMS信道是否已经安全化的机制。该机制的一个优点在于，可以减少DM平台和设备之间的信令。重要的是要理解，在本平台上，仅使用从DM平台向设备的唤醒以唤醒设备。所有数据通信总是从设备发起。

唤醒消息——触发固定线路连接

该机制可以使用唤醒消息（或可替换消息）来提示连接从无线连接的切换，消息通过其递送到可替换无线连接（例如具有较大带宽的连接）或有线连接。切换可以例如基于要递送的大文件（例如其将占据太多带宽和/或时间）的检测而确定。消息可以提示设备自动地切换，或者提示与该设备相关联的用户切换连接。

该机制可以例如节省M2M设备中的能量以及下载文件的时间（连接时间）。

进一步增强：

● SBi——特别地，如何处置来自多方的多个请求。

● 软件/固件更新的调度。

DM平台使用声明式方案并且使用数据结构及其关系来描述事情如何工作。

“声明式方案”是用于描述表示问题的解决方案的数据驱动方式的编程项。最简单的示例是交通灯。为了以声明方式描述，你将如下描述交通灯状态（你将声明它们）：

{红色、黄色、绿色、黄色}

交通灯处理器然后比方说将永久地循环通过四个状态。

这是清楚且简单的。

编程的进程方案将如下描述处理：

如果红色，则下一状态是黄色

否则，如果绿色，则下一状态是黄色

否则，如果黄色并且前一状态是红色，则下一状态是绿色

否则，下一状态是红色。

这是更难以维持的。

改进的系统制定一种用于从装置（尤其是在M2M应用中）表示和捕获信息和数据的机制并且简化使用和管理所捕获的数据的方式。因此，其在涉及从远程装置的数据获取的许多领域中具有应用。

系统还可以促进改进的诊断和功能能力，尤其是在与其它M2M装置和应用一起使用时。M2M涉及从广泛的设备和装置捕获大量数据。挑战和机会是你如何分析和使用该数据。改进提供了一种用于组织在M2M设备上/从M2M设备所获取的数据的方法，其将使得更容易使用和了解该数据。

1）SNMP协议支持数据结构，其作为对象层级，并且其促进外部过程以查询这些数据结构。逐项目地查询数据，或者可以在单个请求中查询数据对象的层级的子树内的数据集合。这是广泛支持的成熟技术。

2）OMA-DM和初期LWM2M协议支持以层级并且非常类似于SNMP但是针对M2M环境优化的方式来表示数据结构。

这些层级数据模型的缺点在于，它们是约束性且简单的。它们不反映要求使用数据的方式。作为结果，应用开发者需要理解在哪里以及如何组织数据并且通常需要针对数据做出多个请求以便捕获所有感兴趣的数据项目。获取数据（使用多个查询）是昂贵的，设计使用数据的应用要求域知识，其是昂贵的并且限制可以由应用如何使用该数据。

改进描述了一种将数据值组织和表示到列表结构中的方式，其中数据项目被组织为接连值顺序。M2M设备上应用开发者（潜在）感兴趣的数据项目被映射到列表结构上。说明性列表的示例：

1）硬件诊断列表，表示装置上的硬件检查的数据值顺序（CRC存储器检查、电路行为、温度传感器、水进入传感器等）。

2）仪器版本列表，所有可标识组件和软件元件的版本值的顺序。

3）传感器列表，传感器值的列表，作为未经处理/经处理的值。经处理的值的示例将是温度传感器值在五分钟时段之上平均，或者无线电信号强度在三个月时段之上平均。

4）私用个人列表，位置信息，经受数据保护法律的最终顾客的个人细节。

5）时间序列列表，其中多个列表可以组织到顺序中，使得列表可以以顺序或随机访问方式而访问和管理。

使用智能仪表作为示例：

1）硬件诊断列表可以由在现场维护智能计量仪器的组织使用并且将用于诊断和预测缺陷。

2）仪器版本列表可以由供应固件/软件更新的组织使用以核实在应用正确版本的更新。

3）传感器列表可以包含将用于分析目的的传感器读数。

4）私用个人列表可以与适当安全控制一起使用以管理顾客中心功能。

5）传感器列表（参见以上3）可以作为时间序列列表而被管理，由此以规则间隔（例如每15分钟）获取传感器值并且将其放置到多行时间序列列表中。应用然后可以在适当的情况下查询值。例如，仪表读取应用将每天查询设备两次，并且读取贯穿之前时段所获取的所有时间序列数据。

在一方面中，针对M2M设备的简单层级数据结构使用对于关系数据库所共同的概念而被映射到列表结构上。对SQL关系数据库编程熟悉的许多构造可以并入到该方面（例如使用空值、反映机制、触发、主要和外来密钥）。

可以存在该方案的许多特征（请参照以上条款），其将使得应用开发者容易得多地使用列表中所保持的数据。想法可以由硬件的设计者实现，所述设计者将特征列表限定到产品中，以便使第三方最佳地使用产品。这可以由仪器开发者以声明方式实现，所述开发者将使用XML注释来描述每一个列表的元素及其性质。例如，列表项目是移动平均，其中样本时间为x，并且其中结果被规范化在a到b的范围内。

列表管理操作可以使用集合理论构造并且因此允许两个列表作为并集（列表1+列表2）或者交集（列表1和列表2）或者作为差集（列表1-列表2）而被查询。这可以使得应用开发者更容易将数据查询映射到相关数据结构上。

列表管理操作可以使用关系（SQL）操作和构造以查询和修改数据结构。列表分量可以在应用等级处使用关系运算符和构造而映射到其它数据结构上。例如，温度传感器读数可以作为30天移动平均而映射到列表元件。这可以使产品开发者更容易呈现数据以用于应用使用。

DM平台可以描述为数据流机器，其在输入数据集上使用集合理论以生成触发附加活动（分析、诊断和警报）的结果集合。

图15示出了用于管理设备120、130、140的系统600的示意图。设备管理器或DMAP60与包含存储器位置610的存储器仓库605通信。存储器仓库605可以采取许多可替换形式，例如包括关系数据库、文件系统、硬盘驱动、分布式存储、闪速存储器、易失性存储器或非易失性存储器。每一个存储器位置与由系统600管理的设备120、130、140相关联。每一个存储器位置用于存储一个或多个属性620。

设备管理器60接收指令或命令以对一个或多个所存储的属性采取动作。例如，这可以是读取、写入、擦除或更新属性或属性群组。设备管理器60还配置成从一个或多个设备120、130、140接收与所存储的属性对应的值或数据。同步器630维持所存储的属性与关联于每一个设备的属性或值之间的同步。同步器630可以是设备管理器60的部分（远程的或分离的）。

换言之，动作可以对存储在存储器中的属性执行和/或值可以从物理设备120、130、140接收或检索。同步器630确保所存储的属性和设备值或属性维持处于同步或者更新以反映任何改变。

图16图示了用于管理一个或多个设备120、130、140的方法700。在步骤710处存储属性。这可以是在存储器仓库605的存储器位置610中。通过设备管理器60在步骤720处对这些所存储的属性采取动作。设备管理器60在步骤730处从受管理的设备120、130、140接收设备值或属性。在步骤740处维持所存储的属性620与相关联的设备120、130、140的属性之间的同步。应当指出的是，步骤710、720、730和740可以以任何次序发生并且这些步骤中的任何两个或更多可以同时发生。方法700还可以迭代或者连续地操作。

图17示出了用于分析所存储的属性数据的方法800的流程图。属性可以在步骤810处读取或检索。属性在步骤820处分析。这可以使用适当的数据分析技术实现，诸如例如机器学习。执行分析以从所存储的属性（或者单个属性）计算或估计资源的使用或需求。换言之，分析生成指示资源的需求的输出（步骤830）。

许多不同类型资源的需求或使用可以从不同类型属性而生成。资源可以与属性或者由属性所测量或控制的物理性质相关联，或者资源可以与属性分离或不同。资源可以是内部系统资源（例如可以执行诊断分析）或者资源可以在系统外部。

该方法800因此可以用于生成业务数据或者报告以及技术资源管理信息。第三方可以使用分析的输出或者被提供有所存储的属性数据并且执行其自身的分析步骤820。

计算机系统和架构可以包括处理器，诸如中央处理单元（CPU）。处理器可以以软件程序的形式执行逻辑。计算机系统可以包括存储器，其包括易失性和非易失性存储介质。可以包括计算机可读介质以存储逻辑或程序指令。系统的不同部分可以使用网络（例如无线网络和有线网络）连接。计算机系统可以包括一个或多个接口。计算机系统可以包含适当操作系统，例如诸如UNIX、Windows（RTM）或者Linux。

如将由技术人员领会的，以上实施例的细节可以变化而不脱离如由随附权利要求限定的本发明的范围。

例如，DM平台可以使用FPGA以硬件实现。

以上实施例的特征的许多组合、修改或更改将对于技术人员容易地显而易见并且意图形成本发明的部分。具体涉及一个实施例或示例所描述的任何特征可以通过做出适当改变而使用在任何其它实施例中。

Claims

1.一种用于管理设备的系统，包括：

具有存储器位置的存储器仓库，其中每一个存储器位置存储与一个或多个设备相关联的一个或多个属性；

设备管理器，其布置成执行命令以对存储在存储器位置中的一个或多个属性采取动作并且从一个或多个设备接收对应的一个或多个属性的值；以及

同步器，其配置成维持存储在存储器仓库中的属性与关联于设备的属性之间的同步，

其中所述系统被配置成执行存储在存储器仓库中的属性中的一个或多个的分析以生成指示资源的需求的输出，其中资源的需求基于存储在存储器仓库中的一个或多个属性来计算而不是直接被测量。

2.权利要求1的系统，其中命令被限定为声明式命令。

3.权利要求1或权利要求2的系统，其中所执行的命令是基于集合的操作。

4.权利要求3的系统，其中基于集合的操作包括以下中的任何一个或多个：SQL、进程、数据操纵、配置管理、插入、选择、更新、创建、读取、写入、擦除和搜索。

5.权利要求1或权利要求2的系统，还包括用于与每一个设备通信的一个或多个接口。

6.权利要求5的系统，其中设备管理器还配置成通过第一接口或一个或多个接口与每一个设备通信。

7.权利要求4的系统，其中同步器还配置成在通过接口与一个或多个设备的通信可用时进行操作。

8.权利要求5的系统，其中同步器还配置成在通过接口与一个或多个设备的通信不可用时发起与一个或多个设备的通信。

9.权利要求1或权利要求2的系统，其中同步器还配置成以一定间隔进行操作。

10.权利要求1或权利要求2的系统，其中同步器通过控制设备的属性来维持所存储的属性与关联于一个或多个设备的属性之间的同步。

11.权利要求1或权利要求2的系统，其中同步器通过控制所存储的属性来维持所存储的属性与关联于一个或多个设备的属性之间的同步。

12.权利要求1或权利要求2的系统，其中存储器仓库还配置成存储和/或检索一个或多个属性的之前版本。

13.权利要求1或权利要求2的系统，还包括一个或多个属性的概要。

14.权利要求1或权利要求2的系统，进一步地，其中一个或多个属性是设备的任何可执行代码、由设备所检测的参数、和/或由设备所接收的参数。

15.权利要求14的系统，其中可执行代码是固件、操作系统和/或软件应用。

16.权利要求1或权利要求2的系统，还包括布置成将数据传达给设备管理器的第二接口，并且进一步地，其中响应于所传达的数据而执行对存储在存储器位置中的一个或多个属性采取动作的命令。

17.权利要求16的系统，其中从用户和/或应用接收数据。

18.权利要求17的系统，其中设备管理器还布置成确定用户和/或应用是否被授权。

19.权利要求1或权利要求2的系统，其中存储器位置被布置成具有复制一个或多个设备的数据结构。

20.权利要求19的系统，其中数据结构是跨不同类型设备所共同的统一数据结构。

21.权利要求20的系统，其中对存储在存储器位置中的一个或多个属性采取动作的命令符合统一数据结构，所述系统还包括适配器，所述适配器配置成适配命令以向同步器提供指令来以特定于每一种不同类型设备的格式控制一个或多个设备的属性。

22.权利要求1或权利要求2的系统，其中与一个或多个设备相关联的一个或多个属性是开账单和/或记录数据。

23.权利要求1或权利要求2的系统，其中一个或多个设备属于选自包括以下项的群组的类型：机器对机器M2M设备、另外的设备管理器、一个或多个设备的控制器、以及接收实体。

24.权利要求1或权利要求2的系统，其中设备管理器还配置成接收一个或多个准则，并且监视一个或多个设备以确定何时满足一个或多个准则。

25.权利要求20的系统，其中设备管理器还配置成在满足一个或多个准则时触发事件。

26.权利要求25的系统，其中事件是预确定的。

27.一种用于管理设备的方法，包括以下步骤：

存储与一个或多个设备相关联的一个或多个属性；

对一个或多个所存储的属性采取动作；

从一个或多个设备接收一个或多个属性的值；

维持存储在存储器仓库中的属性与关联于设备的对应属性之间的同步；以及

执行存储在存储器仓库中的属性中的一个或多个的分析以生成指示资源的需求的输出，其中资源的需求基于存储在存储器仓库中的一个或多个属性来计算而不是直接被测量。

28.权利要求27的方法，还包括以下步骤：接收命令以改变一个或多个设备的属性，其中命令以符合一个或多个所存储的属性的数据结构的第一形式而接收，其中维持同步的步骤还包括将所接收的命令转换成符合一个或多个设备的数据结构的形式的步骤。

29.权利要求28的方法，其中通过第一接口接收命令，并且其中经转换的命令通过第二接口传达给一个或多个设备。

30.根据权利要求27至29中的任一项的方法，还包括接收限定步骤顺序的命令以用于改变一个或多个设备的属性的步骤，其中对一个或多个所存储的属性采取动作的步骤根据步骤顺序来执行。

31.权利要求30的方法，还包括在根据步骤顺序而同步一个或多个设备的一个或多个属性之后更新设备的固件或其它可执行代码组件的步骤。

32.权利要求30的方法，其中针对不同设备类型接收限定不同步骤顺序的不同命令。

33.权利要求30的方法，其中设备取决于所存储的一个或多个属性而被更新到固件或另一可执行代码组件的不同版本。

34.根据权利要求27至29中的任一项的方法，其中所存储的一个或多个属性针对不同设备类型而存储在单个数据结构中。

35.权利要求34的方法，其中维持所存储的属性与设备的对应属性之间的同步还包括在更新一个或多个设备之前转换属性。

36.权利要求33的方法，还包括以下步骤：接收针对固件或其它可执行代码组件的每一个版本的数据模型，然后使用数据模型来限定如何在版本之间变换。

37.根据权利要求27至29中的任一项的方法，还包括以下步骤：

接收请求内的准则，其中准则取决于一个或多个属性；

监视一个或多个属性；

在满足准则时进行报告。

38.权利要求37的方法，还包括在满足准则时向请求者报告一个或多个属性的步骤。

39.权利要求37的方法，其中监视一个或多个属性的步骤还包括监视一个或多个所存储的属性。

40.权利要求37的方法，其中监视一个或多个所存储的属性发生在与设备的通信可用时。

41.根据权利要求27至29中的任一项的方法，其中维持同步的步骤发生在与设备的通信可用时。

42.权利要求27的方法，其中用于执行分析的属性与资源无关。

43.权利要求27或的方法，其中资源是以下中的任何一个或多个：自然资源；消费者产品；食物；饮料；运输；房产访问；动力；电力；燃气；燃料；水；公共运输；电信；软件；以及娱乐。

44.权利要求27的方法，其中所执行的分析由机器学习算法执行。

45.根据权利要求27至29中的任一项的方法，还包括以下步骤：

根据所接收的信息对存储器仓库做出改变。

46.权利要求45的方法，其中信息与一个或多个设备的固件更新相关联。

47.一种包括程序指令的计算机可读介质，所述指令在计算机上执行时使所述计算机执行权利要求27至46中的任一项的方法。

48.一种计算机，其被编程为执行权利要求27至46中的任一项的方法。