本发明涉及为智能设备提供统一抽象表示的计算机系统，同时涉及基于该计算机系统的计算机实现方法。
背景技术：
：：物联网有可能改变传统行业，以及我们的生活和工作方式。近几年技术和应用开发发展迅速。许多新技术正在出现，以实现“物”(也称为智能设备)的连接。现阶段，有几个相互竞争的标准，包括蓝牙、zwave、zigbee或传统ip网络协议。此外，不同的制造商可能会实施其他专有协议和独特功能。目前世界上，还没有与这些智能设备和物联网交互的通用接口。对于拥有不同品牌的智能设备的消费者来说，设备的交流互动是非常不方便和昂贵的。不同制造商的设备之间缺乏统一的控制、访问和互操作性，阻碍了物联网应用的快速采用。许多智能设备和物联网缺乏统一的表现，也给许多服务提供商带来了挑战。他们必须花大量资源和努力来建立具体的接口，以应付不同的标准、协议和制造商。虽然大多数制造商努力在自己的产品内开发共同的界面，但它仍然是一个非常分散的市场。在不同制造商之间交流互动和控制智能设备没有共同的技术或标准。现有技术，诸如蓝牙、z-wave等网络协议都已经试图定义常见的智能设备的应用配置文件，其描述了具有相关服务的设备能力以及如何操作这些服务。然而，他们定义的设备的应用配置文件只属于自己的协议，并且仍然缺乏跨不同协议的互操作性。所有设备的应用配置文件都需要某种结构化数据来完全表示设备在树状数据结构中的功能，一些技术(例如onvif或upnp)利用xml格式来表示设备的应用配置文件并发送动作调用xmlsoap格式。然而，这种xml格式的数据是重量级的，并且难以用于与客户端web应用程序的交互。此外，他们在处理和通信方面都耗费太多的资源。与xml或其他结构数据格式相比，json(javascript对象表示，使用人类可读文本传输由属性-值配对组成数据对象的开放标准格式)具有相同的能力来表示公共设备和应用配置文件结构格式。此外，它更易于人眼阅读，更容易通过软件(如客户端javascript和服务器端node.js代码)进行解析和分析。此外，json更紧凑，消耗更少的网络带宽。在本发明中，我们开发了基于json的设备应用配置文件，与现有技术基于xml的模型相比，显示出巨大的技术先进性，它是为各种物联网设备创建通用设备的应用配置文件的最佳技术。技术实现要素：本发明所要解决的首要技术问题在于提供一种为智能设备提供统一抽象表示的计算机系统。本发明所要解决的另一技术问题在于提供一种为智能设备提供统一抽象表示的计算机实现方法。为实现上述目的，本发明采用下述的技术方案：一种为智能设备提供统一抽象表示的计算机系统，包括：a.统一接口，用于将具有相关服务的可用智能设备在具有通用格式的设备对象中进行表示；b.定义可用智能设备的第一单元，包括以下中的至少一个：i.设备对象，代表具有相关服务的可用智能设备的抽象表示；ii.第二模块，被配置为通过调用必要的设备驱动程序来发现和注册可用的智能设备；iii.至少一个处理模块，和至少一个设备控制命令模块；c.第二单元，包含智能设备的通用网络接口标准或协议。其中较优地，所述第一单元被配置为将所述智能设备的硬件细节和相关联的服务转换为设备的表示，即所述设备对象；并且将所述设备对象在所述统一接口处呈现。其中较优地，所述公共设备管理层通过至少一个设备驱动程序来执行设备管理过程，包括至少一个以下过程：a.设备和服务发现过程；b.设备注册过程；c.通过调用与所述设备相关联的至少一个服务来实现设备控制过程；d.设备事件订阅过程。其中较优地，所述公共设备管理层中的设备驱动程序至少包含一个驱动程序，也可以包含多个驱动程序；所述公共设备管理层具有层次结构，顶层驱动程序依赖于至少一个底层驱动程序。其中较优地，所述统一抽象表示是基于web的应用编程接口。其中较优地，所述应用编程接口是具有标准json格式的restfulapi。其中较优地，所述的计算机系统，还包括：多个系统的组合，形成具有至少一种布局的的集群，所述布局包括：串行、并行、垂直、水平、分层和多个布局的组合，其中至少一个系统被部署为另一系统或多个系统的设备驱动程序。其中较优地，至少一个系统将设备对象的应用简档发送到其他系统，以使其他系统能够通过所述系统的管理接口来管理所述设备。一种将设备硬件细节和相关联的服务转换为统一抽象表示的计算机实现方法，基于上述智能设备提供统一抽象表示的计算机系统，包括以下步骤：a.通过调用至少一个设备的驱动程序来发现可用的设备；b.为每个被发现的设备创建一个设备对象，设备对象包含设备的完整信息以及操作信息；c.根据设备对象注册设备；d.设备对象的应用简档使用统一接口以抽象的方式呈现设备的相关服务；e.通过调用至少一个设备驱动程序来控制设备；f.根据每个模式定义验证输入和输出变量的数据完整性。其中较优地，所述的计算机实现方法，还包括以下步骤：a.客户端通过统一接口发送ajax请求，ajax请求以纯json格式处理基于文本消息的动作调用；b.根据设备对象提供的json格式定义验证输入数据；c.将文本消息转换为设备的动作api调用名称和输入数据；d.将请求和相关数据分发到设备驱动程序来处理控制命令；e.根据设备对象提供的json格式定义验证输出数据；f.将设备返回的数据转换为文本消息，通过统一接口返回到客户端。附图说明图1是描绘本发明的软件框架(m200)管理智能设备的的实例图；图2是描绘软件框架的高级功能的实例图；图3是描绘软件框架的概括性架构，包括一组api接口和模块的实例图；图4是描绘根据本发明的实施例的框架部署的分层布局的实例图；图5是描绘由框架管理的设备对象(m100)的实例图；图6是描绘以json格式实现的设备的应用配置文件(m110)的实例图；图7是表示可切换灯泡json文档的应用配置文件实例图；图8a是json文档的一个实施例中，具有两种服务的可切换和可调光灯泡的应用配置文件的部分代码展示示意图；图8b是json文档的一个实施例中，具有两种服务的可切换和可调光灯泡的应用配置文件的部分代码展示示意图；图9是描绘设备驱动程序(m150)的实例模型图，还包括一组设备对象；图10是根据本发明的实施例的软件框架在发现和注册智能设备时执行的动作的流程图；图11是描绘框架如何提供智能设备的通用抽象接口的示例的模型图；图12是根据本发明的实施例的由客户端应用和软件框架执行的交互并控制智能设备动作的示例流程图；图13是客户端应用程序执行的检索与设备对象相关联的json模式文档(m280)的动作的流程图；图14是根据本发明的由客户端应用程序，软件框架在与智能设备进行事件订阅和接收事件更新的交互中执行动作的实例流程图。具体实施方式下面结合附图和具体实施例对本发明作进一步的详细说明。本发明通过实施例说明，但是实际应用并不受到附图中所描述的应用场景限制，其中相同的附图标记表示相似的项目。对本发明中公开的实施例的引用不一定是相同的实施例，并且这样的引用意味着至少一个。虽然讨论了具体的实现方式，但是应当理解这是为了说明的目的而完成的。相关领域的技术人员可以认识到，在不脱离本发明的范围和精神的情况下可以使用其它组件和构造。在本发明所提供的实施例中，统一接口可以为api接口，用于将具有相关服务的可用智能设备在具有通用格式的设备对象中进行表示；第一单元用来定义可用智能设备，至少包括：设备对象、第二模块、处理模块和设备控制命令模块。其中，当在网络上发现智能设备时，第二模块调用必要的设备驱动程序将发现的智能设备注册(p20)到软件框架，并将其表示为软件框架内部的设备对象。处理模块(m220)包括主要功能模块，其包括以下至少一个功能：设备发现(m222)、设备注册(m224)、设备控制(m226)和设备事件订阅(m228)。设备控制命令模块可以为设备驱动程序管理模块(m230)，设备驱动程序管理模块(m230)与分组在设备硬件抽象层(m240)中的每个设备对象的设备驱动程序通过接口互动。第二单元，包含智能设备的通用网络接口标准或协议。以上为本计算机系统的一个实施例，并不是对本专利申请的限制。在下面的描述中，阐述了许多具体细节以提供对本发明的全面描述。然而，对于本领域技术人员来说，可以在没有这些具体细节的情况下实践本发明。在其他情况下，我们未详细描述众所周知的特征，以免使本发明的描述变得主次不分。许多物联网/智能设备利用不同的网络标准和协议，诸如蓝牙、zwave、zigbee或ip网络协议。此外，不同的制造商可能会实现专有协议和独特功能。实现大量设备的统一代表和描述是一项挑战，使得物联网/智能设备之间的互操作性非常困难。我们发明了一种新的解决方案来应对这一挑战，参考图1，该解决方案引入了一个软件框架(m200)来管理连接到框架的所有智能设备(m41x)。作为web服务器，该框架使用统一格式将至少一个外部接口(称为应用编程接口(m300))暴露给框架外的客户端。通过此框架，客户端可以通过应用编程接口(m300)以统一的命令访问所有智能设备，无需处理不同网络协议和设备细节的麻烦。以下发明的软件框架(m200)可以应用于智能家居和物联网(iot)应用。该软件框架可以实现为智能网关的一部分，或者在诸如智能电话或平板电脑的移动设备中，或者在运行在云中的服务器机器中，或在防火墙后面的pc或连接的“智能”联网设备中，通过计算机网络访问物联网(iot)设备。图2是描绘本发明的软件框架(m200)的高级功能的实例模型图。在软件框架顶层，它开放了一组设备管理api接口(即应用编程接口m300)，在我们优选的实施例中，我们用restful(m310)风格的api接口实现到外部世界连接。这接口不仅仅限于与restful风格的api接口实现。在软件框架内部，它利用公共设备管理层(m210)来管理一组设备对象(m100)。这些设备对象是从设备驱动程序(m150)生成，并向软件框架报告的。公共设备管理层(m210)拥有设备驱动程序管理模块(m230)，负责管理所有设备驱动程序，例如发送发现(p10)请求，加载和卸载设备驱动程序(p14)等。当在网络上发现智能设备时，设备驱动程序将发现的智能设备注册(p20)到软件框架，并将其表示为软件框架内部的设备对象(m100)。每个设备对象(m100)实例表示发现的智能设备。外部世界可以通过软件框架的api接口(m300)获得发现的智能设备的列表，并通过由软件框架(m200)实现的api接口(m300)来控制这些智能设备。在我们当前的实施例中，我们使用restfulapi(m310)构建框架的api接口(m300)。对于在相同协议中共享公共设备驱动程序(m160)的智能设备，您可能会看到多个设备对象，它们表示从同一公共设备驱动程序(m160)创建的不同智能设备，如图2所示。框架的api接口(m300)还用于设备事件订阅。要接收设备事件，外部世界用户将其事件订阅请求和地址信息发送到软件框架的api接口。当设备事件到达软件框架时，软件框架会向用户的地址发送事件更新。用户地址可以是可接收数据的任何url或套接字地址。通过这种设计，我们为各种物联网(iot)设备创建了一个双向数据通道。图3是描绘软件框架的高级架构包括一组api接口和模块的实施例图。在操作系统和网络协议栈(m400)之上的软件框架中有两个主要层。公共设备管理层(m210)和设备硬件抽象层(m240)。公共设备管理层(m210)包括处理模块(m220)和设备驱动程序管理模块(m230)。处理模块包括主要功能模块，其包括以下至少一个功能：设备发现(m222)，设备注册(m224)，设备控制(m226)和设备事件订阅(m228)。设备驱动程序管理模块(m230)与分组在设备硬件抽象层(m240)中的每个设备对象的设备驱动程序(图1中的m150)通过接口互动。图4是描绘根据本发明的实例的框架部署的分层布局的实例图。基于我们的设计，多个软件框架可以在几乎任何布局的组合中形成集群。任何软件框架都可以调用另一个软件框架来控制由另一个软件框架管理的设备。在典型的软件部署环境中，软件框架可以具有分层布局，管理一组智能设备的下层框架实例可以被部署为上层框架实例的设备驱动程序。响应于对下层框架的api接口的请求，较低层框架实例可以将其被管理设备对象信息发送到上层框架实例。然后上层框架可以通过下层框架实例的管理界面来管理实际的智能设备。另一种部署方法是设备驱动程序可能具有层次结构，我们有一个公共设备驱动程序(m160)来管理不同供应商的专有驱动程序(m170)作为其依赖关系。例如，在我们的实现中，我们有一个通用的蓝牙le驱动程序，能够发现附近的所有蓝牙le设备，并将其与已安装的供应商专有驱动程序相匹配。在匹配的情况下，常见的蓝牙le模块将向框架注册供应商专有设备对象。如果找不到匹配项，蓝牙le模块将收集由蓝牙le标准定义的所有知名信息，例如设备名称，设备类型等。然后，该设备将作为通用蓝牙注册到该框架le设备。通过利用这种设计，我们可以在不同的部署环境下实现管理各种智能设备的最大灵活性。图5是描绘由软件框架管理的设备对象(m100)的实施例图。设备对象包括应用配置文件(m110)和硬件配置文件(m120)两者。设备的应用配置文件是json格式文档。它代表了设备的全部功能以及如何操作它们。此json文档由设备驱动程序(m150)创建，该设备驱动程序(m150)在发现阶段读取和分析设备以创建该设备的框架内部对象模型。此框架的客户端，如客户端应用程序或第三方web服务可以通过软件框架的api接口(m300)检索此json文档，以便他们知道如何向该设备发送api调用动作或订阅事件更新。设备的硬件配置文件包括如何操作设备的内部实现，这些信息对软件框架和外部世界是不可见的。设备对象实现一组公共设备抽象接口(m130)，例如接受设备api调用动作和事件订阅请求等。软件框架可以调用该公共设备抽象接口以一致地与不同类型的设备进行通信，而不管其硬件配置将是什么。图6是描绘以json格式实现的设备的应用配置文件(m110)的实例图应用配置文件包括设备的基本信息(m122)的列表，诸如设备的供应商信息，友好名称等；以及名为“服务列表”(m180)的列表，其定义与设备相关联的可用服务。服务列表(m180)包含服务列表的定义(m182，m184，m186)。每个服务列表包含抽象api(m182a，m182b，m182c)和名为“服务状态表”(m192)的列表。从功能的角度来看，设备应用简档描述服务列表(m182，m184，m186)，并且每个服务包含对动作呼叫列表的定义(例如m182a，m182b，m182c)。每个动作调用定义包括表示全抽象api调用接口的参数定义列表。在我们实现的实例中，将包含对一组变量的定义的服务状态表servicestatetable(m192，m194，m196)映射到抽象api调用接口的参数。这些变量的定义包括有关其数据类型的信息，以及是否可以以事件发生。变量的数据类型可以是简单的或复杂的类型。简单类型包括字符串，整数，布尔值，数字和json规范的一致性。复杂类型用于表示具有复杂结构的数据对象。通过这样做，该软件框架的客户端可以根据设备模型中定义的数据类型向框架发送表示操作api调用的文本消息。图7是表示可切换灯泡json文档的应用配置文件实施例图。json文档包括设备的基本信息，例如姓名，制造商信息等；服务列表，其中每个服务都包含对操作列表的定义，每个操作都描述此设备支持的操作api调用。通过利用基于json的设备模型和上述过程，客户端应用将具有统一的表示。利用这种统一的设备应用配置文件和抽象设备接口，提供开关功能的灯泡将具有对客户端的统一表示，而不管设备的网络协议服务表示由智能设备提供的一组单独和可互换的功能。例如，可调灯泡可以提供两种服务：一种是开关服务；另一个是调光服务。开关服务包含两个用于打开或关闭灯泡的抽象api接口，并且调光服务包含两个api接口以获得并设置灯泡的调光级别。图8是json文档的一个实施例图，其表示具有两种服务的可切换和可调光灯泡的应用配置文件：二进制开关服务和调光服务。此外，定义的服务实体可以在其他情况下重复使用。例如，该开关服务实体可以用于描述诸如电视机、洗衣机等的其他智能设备所提供的切换功能。调光服务也可以用于描述可调光电视或监视器屏幕。“服务状态表”(m192)包含映射到由服务定义的抽象api接口的每个参数的变量定义变量的数据类型在服务状态表(m192)中定义，并且可以是可能包含json对象或数组中的复杂数据的简单类型(布尔型，整数型，数字和字符串)或复杂类型。通过利用这种抽象api接口和变量类型信息，我们可以通过软件框架的api接口(m310)将设备的应用程序配置文件发送到框架外的客户端。然后，客户端将知道如何发送正确的api调用来控制设备。此外，“服务状态表”中的每个变量的定义可以用“sendevents”布尔标志来注释。软件框架将缓存变量的最新已知值，这些值是从其成功的操作调用或事件更新中获取的。如果变量的“sendevents”标志在设备的应用配置文件中为真，并且该变量的值由底层网络堆栈或动作api调用更改，则软件框架将向事件订阅者发送事件更新。例如，如果用户关闭灯泡，则所有事件订户将从框架获得上述更改的更新。通过这样做，我们在客户端和物联网设备之间拥有灵活的双向数据通道。图9是描绘设备驱动程序(m150)的实施例的模型图，还包括一组设备对象。每个设备驱动程序表示一种类型的网络协议，并且可以管理该类别中的一个或多个设备对象，例如蓝牙z-wavezigbee每个采用设备驱动程序的onvif协议。此外，设备制造商的非标准专有实现也可以通过该软件框架来支持，并且在该通用的基于抽象的json的应用配置文件中被呈现给客户端。每个设备驱动程序具有暴露于框架的公共管理接口(m190)。软件框架可以管理诸如驱动程序加载和卸载的设备驱动程序，通过该公共管理接口(m190)启动设备发现过程。当从软件框架接收到发现请求时，设备驱动程序将根据它们自己的发现协议，例如蓝牙或z波网络扫描、upnpssdp、用于onvif摄像机的ws-发现来启动设备发现过程。设备对象将是为每个新发现的设备生成并注册到软件框架。图10是根据本发明的实施例的软件框架在发现和注册智能设备时执行的动作的流程图。软件框架的处理模块(m220)将调用(p10)设备驱动程序管理模块(m230)内的必需设备驱动程序(m232，m234)以发现所有连接的物联网设备。根据发现请求(p12)发出，其网络上的所有可用设备(m412，m416)根据标准连接协议响应相应的设备驱动程序(p16，p18)。设备驱动程序(m232，m234)将通过为软件框架内部创建和呈现设备对象(图5中的m100)来将发现的设备(p20)注册到软件框架。每个设备对象包含该智能设备的应用配置文件(图5中的m110)。此应用配置文件是一种json格式的文档，其中包含有关智能设备及其操作的所有信息。图11是描绘软件框架如何提供智能设备的通用抽象接口的示例的模型图。在软件框架启动之后，客户端可以向软件框架发送设备发现请求(p02)，软件框架处理模块将向驱动器管理模块内的设备驱动程序发送该请求(p10)。驱动程序将与智能设备(m410)进行交互(p12和p16)，以完成发现过程。一旦发现，相应的驱动器将发现的智能设备(p20)注册到软件框架作为设备对象(m100)。使用设备对象的通用格式，我们实现了具有相关服务的设备的统一表示。图12是根据本发明的实施例的由客户端应用和软件框架执行的交互并控制智能设备动作的示例流程图。在通过软件框架的api接口(m300)接收到设备的应用配置文件之后，外部世界中的客户端应用将文本消息(p50)中的动作api调用请求发送到框架的外部api接口(m300)。软件框架然后将通过设备抽象接口(图5中的m130)发送api调用数据到相应的底层设备驱动程序(p52)，其中api调用数据将被转换为设备的硬件配置文件和设备对象内的内部实现。软件框架将在内部调用正确的驱动程序，就是说，z-wave驱动程序(m234)，将这些api调用转换成设备自己的控制协议，也就是说，z-wave协议与智能设备(m410)通信(p56)。在完成动作后，智能设备将确认或输出数据(p58)发送回驱动器，然后依次发送到软件框架的处理模块(p60)和客户端应用程序(p62)。通过利用这种设计，我们有一个与外部世界的每种类型的设备的通用设备应用配置文件。例如，灯泡将仅暴露开关应用简档作为框架，则开关api调用数据可以通过其设备抽象接口(m130)发送到灯泡的设备对象。然后，这个开关api调用将被转换为设备对象的硬件配置文件及其内部实现，无论它们基于什么通信协议。图13是客户端应用程序执行的检索与设备对象相关联的json模式文档(m280)的动作的流程图。在本发明所提供的一个实施例中，web服务api抽象层，统一xml或所有类型的数据到json。设备驱动程序负责将接收到的数据转换为json，使用json模式验证api数据。使用httpurl应用程序解析api数据模式的json指针，完整解析后的模式前端可见，可以创造出动态生成的表单和测试工具。统一的web服务api规范放在设备驱动程序里，可以是静态文件，也可以从服务发现的结果里动态生成的。让客户端看到api规范后可以生成相应的访问代码。在我们的发明中，如果其抽象api调用的任何参数是复杂类型，则每个设备对象必须携带与其应用配置文件(图5中的m110)一起的json模式文档。当调用设备的抽象api(图6中的m182a)时，复杂类型的实际数据可以是json数组或json对象。此json模式文档(m280)包含设备抽象api(图6中的m182a)公开的所有复杂类型数据的详细定义。在设备的应用配置文件(图6中的m110)中，在“服务状态表”(图6中的m192)内部，映射到设备的抽象api(m182a)的特定复杂类型参数的变量定义包括json指针字符串，它引用了json模式文档(m280)中的子模式定义。框架将在运行时取消引用此json指针，以验证复杂类型的输入和输出数据。客户端应用程序可以从框架的restfulapi接口(m310)检索与该json指针相关联的子模式定义，以用于预处理和验证目的。例如，客户端应用程序可以根据变量的模式定义在其用户界面上自动生成输入表单。当处理设备操作api调用或事件更新数据时，软件框架将根据其简单的类型和模式定义验证所有简单和复杂的类型数据。图14是根据本发明的由客户端应用程序，软件框架在与智能设备进行事件订阅和接收事件更新的交互中执行动作的实例流程图。在发现过程之后，设备对象将注册到软件框架。客户端应用程序可以通过调用软件框架的事件订阅api接口来订阅(p80)设备事件更新。订阅信息包含感兴趣的设备和用于接收事件更新的订户的地址。在接收到事件订阅请求之后，软件框架将请求分派到各个设备对象。设备对象将向其设备驱动程序发送(p82)请求。在运行时间期间，如果从智能设备生成任何事件更新，则将事件数据(p84)发送到其设备驱动程序。在接收到事件数据后，设备驱动程序将调度(p86)到由软件框架管理的设备对象。软件框架将比较新事件数据与设备对象的内部缓存值，其可以从先前的动作调用或事件更新中获取。如果有变化，软件框架将向其订阅者广播(p88)事件更新。此外，如果动作api调用改变如“服务状态表”(图6中的m192)中定义的任何设备状态，软件框架将会意识到这一点，因为它将这些状态缓存在其存储器内。在这种情况下，软件框架还向其订户广播事件更新。尽管本文已经描述了本发明的优选实施例，但是本领域技术人员将理解，在不脱离本发明的精神或所附权利要求的范围的情况下，可以对其进行变化。当前第1页12当前第1页12