发明内容
有鉴于此,本公开的目的是提供一种计算系统及消息路由方法。
根据本公开实施例的第一方面,提供一种计算系统,包括由多个IoT设备的通信耦合而构成的互联网络,每个IoT设备存储有连接信息,所述连接信息用于描述基于所述互联网络构建的虚拟树型网络结构中的所述每个IoT设备访问作为根节点的IoT设备要途径的IoT设备,每个IoT设备包括IoT处理器和存储器,所述存储器存储有可由所述IoT处理器执行的计算机程序,所述计算机程序包括:
客户端接口模块,用于发送消息,所述消息指定目标IoT设备;
通信服务模块,用于接收消息,并根据所述连接信息确定所述消息从当前IoT设备到达所述目标IoT设备要途径的IoT设备,并据此发送所述消息,以将所述消息依次发送给所述要途径的IoT设备并到达所述目标IoT设备。
可选地,所述互联网络为总线结构、星形结构、环形结构、网状结构、树型结构或以上结构的组合。
可选地,所述互联网络为树型拓扑结构时,所述虚拟树型网络结构和所述互联网络具有相同的拓扑结构。
可选地,在所述连接信息中,将每个IoT设备到达作为根节点的IoT设备要途径的IoT设备与该IoT设备的名称标识的组合作为该IoT设备的资源标识符。
可选地,所述通信服务模块包括:
前端路由单元,用于接收消息,并根据所述连接信息确定从当前IoT设备到达所述目标IoT设备要途径的IoT设备以及当前IoT设备与相邻IoT设备的通信类型,并以当前IoT设备与相邻IoT设备的通信类型作为输入参数调用通信接口以发送所述消息;
后端通信单元,用于向所述前端路由单元提供所述通信接口。
可选地,所述后端通信单元在启动时创建至少一种通信类型的通信线程,每种通信类型的通信线程操作相应通信类型的通信硬件,所述通信接口根据输入参数调用相应通信类型的通信线程以发送所述消息。
可选地,所述通信服务模块以进程形式常驻内存执行。
可选地,所述虚拟树型网络结构的构建步骤包括:
确定所述互联网络的一个IoT设备作为根节点;
确定每个IoT设备与作为根节点的IoT设备之间的至少一条路径,从所述至少一条路径中选出一条路径作为该IoT设备访问作为根节点的IoT设备的路径,并确定该IoT设备与相邻IoT设备的通信类型。
可选地,从所述至少一条路径中选出一条路径包括:
根据路径包含的IoT设备的数量从所述至少一条路径中选出一条路径;
根据路径包含的通信类型从所述至少一条路径中选出一条路径。
可选地,作为根节点的IoT设备与外部的云计算平台连接。
可选地,所述通信类型包括:USB、PCIe和UART。
第二方面,本公开实施例提供一种消息路由方法,适用于由多个IoT设备的通信耦合而构成的互联网络,每个IoT设备存储有连接信息,所述连接信息用于描述基于所述互联网络构建的虚拟树型网络结构中的每个IoT设备访问作为根节点的IoT设备要途径的IoT设备,所述消息路由方法包括:
根据所述连接信息确定消息从当前IoT设备到达目标IoT设备要途径的IoT设备;
将所述消息依次发送给所述要途径的IoT设备并到达所述目标IoT设备。。
可选地,所述互联网络为总线结构、星形结构、环形结构、网状结构、树型结构或以上结构的组合。
可选地,所述通信结构为树型拓扑结构时,所述虚拟树型网络结构和所述通信结构的树型拓扑结构相同。
可选地,所述虚拟树型网络结构的构建步骤包括:
确定所述互联网络的一个IoT设备作为根节点;
确定每个IoT设备到作为根节点的IoT设备的至少一条路径,从所述至少一条路径中选出一条路径作为该IoT设备到作为根节点的IoT设备的路径,并确定该IoT设备与相邻IoT设备的通信类型。
可选地,所述通信类型包括:USB、PCIe和UART。
第三方面,本公开实施例提供一种交通灯控制系统,包括由多个交通灯控制装置的通信耦合而构成的互联网络,每个交通灯控制装置耦接至少一个交通灯,且每个交通灯控制装置存储有连接信息,所述连接信息用于描述基于所述互联网络构建的虚拟树型网络结构中的每个交通灯控制装置访问作为根节点的交通灯控制装置要途径的交通灯控制装置,每个交通灯控制装置包括处理器和存储器,所述存储器存储有可由所述处理器执行的计算机程序,所述计算机程序被执行时实现以下操作:
根据所述连接信息确定消息从当前交通灯控制装置到达目标交通灯控制装置要途径的交通灯控制装置;
将所述消息依次发送给所述要途径的交通灯控制装置并到达所述目标交通灯控制装置,其中,接收到消息的交通灯控制装置根据消息控制与其耦接的交通灯。
第四方面,本公开实施例提供一种工控系统,包括由多个传感器设备的通信耦合而构成的互联网络,且每个传感器设备有连接信息,所述连接信息用于描述基于所述互联网络构建的虚拟树型网络结构中的每个传感器设备访问作为根节点的控制装置要途径的传感器设备,每个传感器设备包括传感器、处理器和存储器,所述存储器存储有可由所述处理器执行的计算机程序,所述计算机程序被执行时实现以下操作:
根据所述连接信息确定消息从当前传感器设备到达目标传感器设备置要途径的控制装置,所述;
将所述消息依次发送给所述要途径的传感器设备并到达所述传感器设备,其中,接收到消息的传感器设备根据消息控制传感器工作。
本公开实施例提供一种计算系统,在多个IoT设备组成的互联网络上构建虚拟树型网络结构,并将虚拟树型网络结构的连接信息存储在每个IoT设备中,每个IoT设备都可以根据连接信息确定消息传输的下一个IoT设备并发送消息给下一个IoT设备,从而无需IoT设备配置专门的网络组件来启动TCP/IP协议栈以及复杂的路由策略就可以完成消息传输,因此非常适用于低成本和低功耗的IoT设备组成的互联网络。
具体实施方式
以下基于实施例对本公开进行描述,但是本公开并不仅仅限于这些实施例。在下文对本公开的细节描述中,详尽描述了一些特定的细节部分。对本领域技术人员来说没有这些细节部分的描述也可以完全理解本公开。为了避免混淆本公开的实质,公知的方法、过程、流程没有详细叙述。另外附图不一定是按比例绘制的。
物联网整体架构
图1是本公开一个实施例所应用的物联网(IoT)100的一种系统架构图。
云110可以表示互联网,或者可以是局域网(LAN)、或广域网(WAN),诸如公司的专有网络。IoT设备可以包括以各种组合来分组的任何数量的不同类型的装置。例如,交通控制组206可以包括沿着城市中的街道的IoT设备。这些IoT设备可以包括红绿灯、交通流量监控器、相机、天气传感器等。交通控制组206或其他子组中的各IoT设备可以通过无线链路208(诸如,LPWA链路等)来与云110进行通信。进一步地,有线或无线子网络212可以允许IoT设备彼此通信,诸如通过局域网、无线局域网等。IoT设备可以使用诸如网关210等另一装置来与云110进行通信。
IoT设备的其他分组可以包括远程气象站214、本地信息终端216、报警系统218、自动柜员机220、报警面板222、或移动车辆,诸如应急车辆224或其他车辆226等。这些IoT设备中的每一个都可以与其他IoT设备、与服务器140、或与两者进行通信。
如从图1中可以看出,大量IoT设备可以通过云110进行通信。这可以允许不同的IoT设备自主地向其他装置请求或提供信息。例如,交通控制组206可以从远程气象站组214请求当前天气预报,所述远程气象站组可以在没有人为干预的情况下提供预报。进一步地,可以由自动柜员机220向应急车辆224警告正在发生盗窃。当应急车辆224朝向自动柜员机220前进时,其可以访问交通控制组206以请求准许到达所述位置,例如,通过灯变红以在交叉路口阻止交叉车流足够的时间从而使应急车辆224无阻碍地进入交叉路口。
诸如远程气象站214或交通控制组206等IoT设备集群可以被配备成与其他IoT设备以及与云110进行通信。这可以允许IoT设备在装置之间形成自组织(ad-hoc)网络,允许它们用作单个装置,其可以被称为雾装置。下面关于图2进一步讨论雾装置。
在图2中,虚线包围的IoT设备的集群可以被称为雾装置302、在云110边缘操作。如本文使用的,雾装置302是可以被分组用于执行特定功能,诸如交通控制、天气控制、工厂控制、视频采集等的装置集群。
在一个示例中,雾装置302包括在交通交叉路口的一组IoT设备。雾装置302可以根据由OpenFog联盟(OFC)等发布的规范来建立。这些规范允许在将雾装置302耦合到云110以及耦合到端点装置(诸如在这个示例中的交通灯304和数据聚合器306)的网关210之间形成计算元件的层级结构。雾装置302可以利用IoT设备集合提供的组合的处理和网络资源。因此,雾装置302可以用于任何数量的应用,包括例如金融建模、天气预报、交通分析等。
例如,通过交叉路口的交通流量可以由多个交通灯304(例如,三个交通灯304)控制。对交通流量和控制方案的分析可以由通过网状网络与交通灯304和彼此通信的聚合器306实施。可以通过网关210将数据上传到云110。网关210从云110接收命令。所述网关210通过网状网络与交通灯304和聚合器306通信。
可以在雾装置302中使用任何数量的通信链路。例如,与IEEE 802.15.4兼容的短程链路308可以提供靠近交叉路口的IoT设备之间的本地通信。例如,与LPWA标准兼容的较长范围链路310可以提供IoT设备与网关210之间的通信。为了简化所述图,并非每个通信链路308或310都标有附图标记。
雾装置302可以是大规模互连网络,其中,多个IoT设备例如通过通信链路308和310彼此通信。可以使用由Open Connectivity Foundation TM(OCF)于2015年12月23日发布的开放互连协会(OIC)标准规范1.0来建立网络。这个标准允许装置发现彼此并且建立互连通信。也可以使用其他互连协议,包括例如,来自AllSeen联盟的AllJoyn协议、优化的链路状态路由(OLSR)协议、或用于移动自组连网的更好方法(B.A.T.M.A.N.)等。
在一些方面,受到应用场景、制造工艺和制造成本的限制,用于组成雾装置的多个IoT设备都不具有网卡这样的网络组件,因此在组建雾装置时,只能将多个IoT设备之间适配的通信类型接口进行通信耦合以形成互联网络。例如,通过USB接口或PCIe将两个IoT设备互相联通。当然,IoT设备的数量可提供一定冗余,从而允许即使丢失了许多IoT设备也可以维持通信。
在一些方面,来自一个IoT设备的通信可以沿着最方便的路径传递以到达网关210,例如,具有最少数量的中间跳数或最高带宽等的路径。在这些网络中,互连的数量提供了大量的冗余,从而允许即使丢失了许多IoT设备也可以维持通信。
在一些方面,雾装置302可包括临时IoT设备。换句话说,并非所有IoT设备都可以是雾装置302的永久成员。例如,图2中,如下三个瞬态IoT设备已经加入雾装置302:第一车辆312、第二车辆314和行人316。在这些情况下,IoT设备可以内置在车辆312和314中,或者可以是由行人316携带的智能电话。还可以存在其他IoT设备,诸如自行车计算机、摩托车计算机、无人机等中的IoT设备。
由IoT设备形成的雾装置302可以通过云110与客户端通信,例如,与作为位于云110的边缘的单个装置的服务器140通信。在这个示例中,可以在雾装置302内没有标识任何特定IoT设备的情况下发生到雾装置302中的特定资源的控制通信。因此,如果雾装置302内的一个IoT设备发生故障,则雾装置302中的其他IoT设备可能能够发现和控制资源,所述资源诸如致动器或附接到IoT设备的其他装置。例如,交通灯304可以是有线连接的,以便允许任何一个交通灯304控制其他交通灯304的灯。聚合器306也可以在交通灯304的控制下在雾装置302的其他功能中提供冗余。
在一些示例中,可以使用命令式编程风格来配置IoT设备,例如,每个IoT设备具有特定功能和通信伙伴。然而,可以以声明性编程风格来配置形成雾装置302的IoT设备,以便允许IoT设备重新配置它们的操作和通信,诸如以响应于条件、查询和装置故障来确定所需的资源。这可以在诸如行人316的瞬态IoT设备加入雾装置302时执行。
由于行人316可能比车辆312和314行进得更慢,因此雾装置302可以重新配置自身以确保行人316有足够的时间使其通过交叉路口。这可以通过形成车辆312和314以及行人316的临时组以控制交通灯304来执行。如果车辆312或314中的一个或两个是自主的,则临时组可以指导车辆在交通灯304之前减速。进一步地,如果交叉路口处的所有车辆都是自主的,则可能减少对交通信号的需求,因为自主车辆的防撞系统可能允许高度交叉的交通模式,这对于交通灯来说可能太复杂而无法管理。然而,交通灯304对于行人316、骑车人或非自主车辆仍然可以是重要的。
当瞬态装置312、314和316离开雾装置302的交叉路口附近时,雾装置302可以重新配置其自身以从网络中消除那些IoT设备。当其他瞬态IoT设备接近交叉路口时,雾装置302可以将其自身重新配置为包括那些装置。
雾装置302可以包括用于多个交叉路口的诸如沿着街道的交通灯304,以及沿着街道的所有瞬态IoT设备。雾装置302然后可以将其自身分成功能性单元,诸如交通灯304和靠近单个交叉路口的其他IoT设备。这种类型的组合可以使得能够在雾装置302中形成更大的IoT构造,例如,执行具体功能的IoT设备组。
例如,如果应急车辆加入雾装置302,则可以创建应急构造或虚拟装置,其包括街道的所有交通灯304,从而允许控制整个街道的交通流量模式。应急构造可以指导沿着街道的交通灯304保持红色以用于反向交通,并且绿色用于应急车辆从而加速应急车辆的通过。
如雾装置302所示,IoT网络的有机演变是改进或最大化IoT实施方式的效用、可用性和回弹性的中心。进一步地,所述示例表明了用于提高可信度并因此提高安全性的策略的有用性。装置的本地标识在实施方式中可能是重要的,因为身份的分散化确保不能利用中心机构来允许对可能存在于IoT网络内的对象进行模仿。进一步地,本地标识降低了通信开销和时延。
区块链可以用于分散标识,因为它们可以在装置之间提供关于当前使用的名称和身份的协议。如本文使用的,区块链是由数据结构块组成的身份记录的分布式数据库。进一步地,如本文使用的,条款区块链可以包括其他分布式分类账系统中的任何一个或多个。其他分布式分类账方法包括瑞波(Ripple)、超级分类账、多链、无钥签名基础设施等。每个数据结构块基于事务,其中下发装置、复合装置或虚拟装置的新名称是事务的一个示例。
使用区块链进行标识,可以通过观察名称和身份的重新下发来检测模仿,而无需相应的终止。公共区块链可能是最有用的,因为它们可以使得不同的观察者团体能够检测错误命名、恶意命名或命名基础设施故障。
图3是本公开一个实施例的IoT设备400的结构图,它可以是图1的交通控制组206中的物联网装置,也可以是远程气象站214、本地信息终端216、报警系统218、自动柜员机220、报警面板222、应急车辆224或其他车辆226中的物联网装置,也可以是图2的交通灯304和数据聚合器306中的物联网装置,或者第一车辆312、第二车辆314和行人316相关的物联网装置。
IoT设备400可以包括物联网处理器402,所述处理器可以是微处理器、多核处理器、多线程处理器、超低电压处理器、嵌入式处理器或其他已知处理元件。处理器402可以是片上系统(SoC)的一部分,其中处理器402和其他组件形成为单个集成电路或单个封装体,诸如EdisonTM或GalileoTMSoC板。作为示例,处理器402可以包括基于架构核心TM的处理器,诸如QuarkTM、AtomTM、i3、、i5、i7或MCU级处理器,或者可从加利福尼亚州圣克拉拉市的公司获得的另一此类处理器。然而,可以使用任何数量的其他处理器,诸如可从加利福尼亚州森尼维耳市的超威半导体公司获得的、来自加利福尼亚州森尼维耳市的MIPS科技公司的基于MIPS的设计、由ARM控股有限公司或其客户或其许可证持有人或采用者许可的基于ARM的设计。处理器可以包括诸如来自公司的A5-A9处理器,来自科技公司的SnapdragonTM处理器、或来自德州仪器公司的OMAPTM处理器之类的单元。
处理器402可以通过总线406与系统存储器404通信。可以使用任何数量的存储器装置来作为定量的系统存储器404。作为示例,存储器404可以是根据联合电子器件工程委员会(JEDEC)的基于低功率双倍数据速率(LPDDR)的设计的随机存取存储器(RAM),诸如根据EDEC JESD 209-2E的当前LPDDR2标准(发布于2009年4月)、或下一代LPDDR标准,诸如将提供LPDDR2的扩展以增加带宽的LPDDR3或LPDDR4。在各实施方式中,各个存储器装置可以是任何数量的不同封装体类型,诸如单管芯封装体(SDP)、双管芯封装体(DDP)或四管芯封装体(Q17P)。在一些实施例中,这些装置可以直接焊接到母板上以提供较低档的解决方案,而在其他实施例中,这些装置被配置为一个或多个存储器模块,这些存储器模块进而通过给定的连接器耦合到母板。可以使用任何数量的其他存储器实施方式,诸如其他类型的存储器模块,例如,不同种类的双列直插式存储器模块(DIMM),包括但不限于microDIMM或MiniDIMM。例如,存储器的大小可以在2GB与16GB之间,并且可以配置为DDR3LM封装体或LPDDR2或LPDDR3存储器,其通过球栅阵列(BGA)焊接到母板上。
为了提供诸如数据、应用、操作系统等信息的持久存储,大容量存储装置408还可以经由总线406耦合到处理器402。为了实现更薄更轻的系统设计,可以通过固态驱动器(SSD)来实施大容量存储装置408。可以用于大容量存储装置408的其他装置包括闪存卡,诸如SD卡、microSD卡、xD图卡等,以及USB闪存驱动器。
在低功率实施方式中,大容量存储装置408可以是管芯上存储器或与处理器402相关联的寄存器。然而,在一些示例中,大容量存储装置408可以使用微硬盘驱动器(HDD)来实施。进一步地,除了所描述的技术之外或代替所描述的技术,任何数量的新技术可以用于大容量存储装置408,诸如电阻变化存储器、相变存储器、全息存储器或化学存储器等。例如,IoT设备400可以包括来自和的3D XPOINT存储器。
组件可以通过总线406进行通信。总线406可以包括任何数量的技术,包括工业标准架构(ISA)、扩展ISA(EISA)、外围组件互连(PCI)、外围组件互连扩展(PCIx)、PCIExpress(PCIe)或任何数量的其他技术。总线406可以是例如在基于SoC的系统中使用的专有总线。可以包括其他总线系统,诸如I2C接口、I3C接口、SPI接口、点对点型接口、和电源总线等。
总线406可以将处理器402耦合到网状收发机410,用于与其他网状装置/雾装置302通信。网状收发机410可以使用任何数量的频率和协议,诸如IEEE 802.15.4标准下的2.4千兆赫(GHz)传输,使用由特别兴趣小组定义的低功耗(BLE)标准、或标准等。为具体无线通信协议配置的任何数量的无线电可以用于到网状装置/雾装置302的连接。例如,WLAN单元可用于根据电气和电子工程师协会(IEEE)802.11标准来实施Wi-FiTM通信。另外,例如,根据蜂窝或其他无线广域协议的无线广域通信可以经由WWAN单元发生。
网状收发机410可以使用多个标准或无线电进行通信以用于不同范围的通信。例如,IoT设备400可以使用基于BLE的本地收发机或另一低功率无线电与地理上邻近的装置(例如,在约10米内)通信以节省功率。可以通过ZigBee或其他中间功率无线电到达更远的网状装置/雾装置302,例如,在约50米内。两种通信技术可以以不同功率水平在单个无线电上发生、或者可以在单独的收发机(例如,使用BLE的本地收发机和使用ZigBee的单独网状收发机)上发生。网状收发机/雾装置302可以并入MCU中作为可由芯片直接访问的地址。
可以包括上行链路收发机414以与云110通信。上行链路收发机414可以是遵循IEEE 802.15.4、IEEE 802.15.4g、IEEE 802.15.4e、IEEE 802.15.4k或NB-IoT标准等的LPWA收发机。IoT设备400可以使用由Semtech和LoRa联盟开发的LoRaWANTM(长距离广域网)在广泛区域上进行通信。本文描述的技术不限于这些技术,而是可以与实施长距离、低带宽通信的任何数量的其他云收发机一起使用,诸如Sigfox和其他技术。进一步地,可以使用IEEE 802.15.4e规范中描述的其他通信技术,诸如时隙信道跳变。
除了针对网状收发机410和上行链路收发机414所提到的系统之外,还可以使用任何数量的其他无线电通信和协议,如本文所述。例如,无线电收发机410和414可以包括LTE或其他蜂窝收发机,其使用扩频(SPA/SAS)通信来实施高速通信,诸如用于视频传输。进一步地,可以使用任何数量的其他协议,诸如用于中速通信的网络,诸如静止图片、传感器读数和网络通信的提供。
无线电收发机410和414可以包括与任量的3GPP(第三代合作伙伴计划)规范兼容的无线电,特别是长期演进(LTE)、长期演进-高级(LTE-A)、长期演进-高级专业版(LTE-APro)、或窄带IoT(NB-IoT)等。可以注意到,可以选择与任何数量的其他固定、移动或卫星通信技术和标准兼容的无线电。这些可以包括例如任何蜂窝广域无线电通信技术,其可以包括例如第五代(5G)通信系统、全球移动通信系统(GSM)无线电通信技术、通用分组无线电服务(GPRS)无线电通信技术、或GSM演进的增强型数据率(EDGE)无线电通信技术。可以使用的其他第三代合作伙伴计划(3GPP)无线电通信技术包括UMTS(通用移动电信系统)、FOMA(自由移动的多媒体接入)、3GPP LTE(长期演进)、3GPP LTE-高级(长期演进-高级)、3GPP LTE-高级专业版(长期演进-高级专业版)、CDMA2000(码分多址2000)、CDPD(蜂窝数字分组数据)、Mobitex、3G(第三代)、CSD(电路交换数据)、HSCSD(高速电路交换数据)、UMTS(3G)(通用移动电信系统(第三代))、W-CDMA(UMTS)(宽带码分多址(通用移动电信系统))、HSPA(高速分组接入)、HSDPA(高速下行链路分组接入)、HSUPA(高速上行链路分组接入)、HSPA+(高速分组接入Plus)、UMTS-TDD(通用移动电信系统-时分双工)、TD-CDMA(时分-码分多址)、TD-SCDMA(时分-同步码分多址)、3GPP Rel。8(Pre-4G)(第3代合作伙伴计划发布8(第Pre-4代)),3GPP Rel。9(第三代合作伙伴计划发布9),3GPP Rel。10(第三代合作伙伴计划发布10),3GPP Rel。11(第三代合作伙伴计划发布11),3GPP Rel。12(第三代合作伙伴计划发布12),3GPP Rel。13(第三代合作伙伴计划发布13),3GPP Rel。14(第三代合作伙伴计划发布14)、3GPP LTE Extra、LTE授权辅助接入(LAA)、UTRA(UMTS陆地无线电接入)、E-UTRA(演进型UMTS陆地无线电接入)、LTE高级(4G)(长期演进-高级(第4代))、cdmaOne(2G)、CDMA2000(3G)(码分多址2000(第三代))、EV-DO(演进-数据优化或演进-仅数据)、AMPS(1G)(高级移动电话系统(第1代))、TACS/ETACS(总接入通信系统/扩展总接入通信系统)、DAMPS(2G)(数字AMPS(第2代))、PTT(按键通话)、MTS(移动电话系统)、IMTS(改进型移动电话系统)、AMTS(高级移动电话系统)、OLT(挪威语“Offentlig Landmobil Telefoni”,公共陆地移动电话)、MTD(瑞典语Mobiltelefo nisystem D的缩写,或移动电话系统D)、Autotel/PALM(公共自动陆地移动)、ARP(芬兰语“Autoradiopuhelin”,“汽车无线电话”)、NMT(北欧移动电话)、Hicap(NTT(日本电报电话公司)的高容量版本)、CDPD(蜂窝数字分组数据)、Mobitex、DataTAC、iDEN(集成数字增强网络)、PDC(个人数字蜂窝)、CSD(电路交换数据)、PHS(个人手持电话系统)、WiDEN(宽带集成数字增强网络)、iBurst、非授权移动接入(UMA,也称为3GPP通用接入网络,或GAN标准)、无线吉比特联盟(WiGig)标准、一般的mmWave标准(无线系统在10-90GHz及以上运行,诸如WiGig、IEEE 802.11ad、IEEE 802.11ay等)。除了上面列出的标准之外,可以将任何数量的卫星上行链路技术用于上行链路收发机1014,包括例如符合ITU(国际电信联盟)或ETSI(欧洲电信标准协会)发布的标准的无线电等等。因此,本文提供的示例被理解为适用于现有的且尚未明确表达的各种其他通信技术。
可以包括网络接口控制器(NIC)416以向云110或其他装置(例如网状装置302)提供有线通信。有线通信可提供以太网连接,或者可以基于其他类型的网络,诸如控制器区域网络(CAN)、本地互连网络(LIN)、设备网(DeviceNet)、控制网(ControlNet)、数据高速通道、过程现场总线(PROFIBUS)或过程现场网(PROFINET)等。可以包括附加的NIC 416以允许连接到第二网络,例如,通过以太网提供到云的通信的NIC 416、以及通过另一种类型的网络提供到其他装置的通信的第二NIC 416。
总线406可以将处理器402耦合到用于连接外部装置的接口418。外部装置可以包括传感器420,诸如加速计、水平传感器、流量传感器、温度传感器、压力传感器、气压传感器等。接口418可用于将IoT设备400连接到致动器422,诸如电源开关、阀门致动器、可听声音生成器、视觉警告装置等。
虽然未示出,但是各种输入/输出(I/O)装置可以存在于IoT设备400内或连接到所述物联网装置。例如,可以包括显示器以示出诸如传感器读数或致动器位置等信息。可以包括诸如触摸屏或小键盘等输入装置以接受输入。
电池424可以为IoT设备400供电,但是在IoT设备400安装在固定位置的示例中,它可以具有耦合到电网的电源。电池424可以是锂离子电池、金属-空气电池,诸如锌空气电池、铝-空气电池、锂-空气电池、混合型超级电容器等。
电池监测器/充电器426可以包括在IoT设备400中以跟踪电池424的充电状态(SoCh)。电池监测器/充电器426可用于监测电池424的其他参数,以提供故障预测,诸如电池424的健康状态(SoH)和功能状态(SoF)。电池监测器/充电器426可以包括电池监测集成电路。电池监测器/充电器426可以通过总线406将关于电池424的信息传送到处理器402。电池监测器/充电器426还可以包括模数(ADC)转换器,所述模数转换器允许处理器402直接监测电池424的电压或来自电池424的电流。电池参数可以用于确定IoT设备400可以执行的动作,诸如传输频率、网状网络操作、感测频率等。
电源块428或耦合到电网的其他电源可以与电池监测器/充电器426耦合以对电池424充电。在一些示例中,电源块428可以用无线功率接收器代替,以例如通过IoT设备400中的环形天线无线地获得功率。无线电池充电电路可以包括在电池监测器/充电器426中。所选择的特定充电电路取决于电池424的尺寸,并且因此取决于所需的电流。可以使用由Airfuel联盟颁布的Airfuel标准、由无线电力联盟(Wireless Power Consortium)颁布的Qi无线充电标准、或者由无线电力联盟颁布的Rezence充电标准等来执行充电。在一些示例中,电源块428可以用太阳能电池板、风力发电机、水发电机或其他自然电力系统来增强或代替。
图4是本公开一个实施例的物联网处理器402的结构图。由于物联网处理器402可以是微处理器、多核处理器、多线程处理器、超低电压处理器、嵌入式处理器或其他已知处理元件,图4仅以微处理器为例示出了物联网处理器402的结构图。
程序存储ROM(只读存储器)504是物联网处理器402中只读而不可写入的存储器,主要用来放置用户所开发的程序,而其性质乃属于不常更动或永不变动之资料。物联网处理器402的动作便是依据储存于此区之程序指令运作。与一般的CPU执行多种多样的指令不同,物联网处理器402一般只执行用户固定开发的程序(例如对于摄像头物联网装置而言,拍摄摄像头安放的位置的视频,并在从视频中识别出异常情况时报警),很少涉及其它程序。
寄存器堆506可以包括用于存储不同类型的数据和/或指令的多个寄存器,这些寄存器可以是不同类型的。例如,寄存器堆506可以包括:整数寄存器、浮点寄存器、状态寄存器、指令寄存器和指针寄存器等。寄存器堆506中的寄存器可以选用通用寄存器来实现,也可以根据处理器402的实际需求采用特定的设计。
运算逻辑单元(ALU)507用于执行指令序列(即程序)。运算逻辑单元507执行每个指令的过程包括:通过总线503从存放指令的程序存储ROM 504中取出指令,对取出的指令进行译码,执行译码后的指令,并将指令执行结果等保存在结果累积器508中,如此循环,直到执行完指令序列中的全部指令或遇到停机指令,将执行结果它能够给输入/输出端口509输出。
具体地说,运算逻辑单元507通过总线503将指令从程序存储ROM 504中搬运到寄存器堆506中的指令寄存器中,并接收下一个取指地址或根据取指算法计算获得下一个取指地址,取指算法例如包括:根据指令长度递增地址或递减地址。然后,运算逻辑单元507按照预定的指令格式,对取回的指令进行解码,以获得取回的指令所需的操作数获取信息。操作数获取信息例如指向随机存储器(RAM)505中存储的操作数。运算逻辑单元507通过总线503,获取RAM 505中的操作数,进行运算执行。运算执行的结果写入结果累积器508中,适当的时候通过输入/输出端口509输出。
IoT设备400经常需要计时和计数,从而在特定时刻或特定事件累积到一定数量时产生一些动作。例如,红绿灯处的摄像头的IoT设备400需要定时切换红/黄/绿灯,并在变灯时发送采集的视频数据到物联网中的其它节点,例如发送到聚合器306进行交通数据分析。计时器/计数器501就是用来计时/计数的单元。计时器(Timer)由外加振荡晶体经除频电路来提供数种不同的时基(TimeBase)。计数器(Event Counter)专用于累计外部的事件个数,可能为脉冲或其它形式,也可用以产生正确的时间延迟。
中断产生器502是物联网处理器402中产生中断的单元,用来处理立即事件,或列为优先处理的事件,负责时间计数器超时中断,及外部事件产生中断请求等工作。大部分微控制器的中断处理系统是多层的,内设有中断优先级电路,以决定先后顺序。常应用于物联网处理器402平时呈待机状态(Halt-Stop),由外加信号来唤醒的情况,或者需要立即处理(传感器、开关、警报器、电源故障预警器)的事件,或者需要一个固定间隔来处理(Display,Key Scan,Read-Time Clock)。在IoT设备400中,经常涉及到中断处理。例如,在摄像头的IoT设备400中,经常需要在监测到某些人或事件时产生报警,或产生一系列动作(例如将视频录制好传送给聚合器306或监控节点),在这些情况下,都需要产生中断,由中断来控制运算逻辑单元507的执行。另外,IoT设备400中,中断产生器502经常与计时器/计数器501相配合产生中断。例如,红绿灯处的摄像头的IoT设备400需要定时切换红/黄/绿灯,在计数器计量固定时间长度后,中断产生器502产生中断,让运算逻辑单元507控制产生变灯的动作,并在需要时发送采集的视频数据到物联网中的其它节点,例如发送到聚合器306进行交通数据分析。
图5a-5e示出雾装置中可实现的多种不同拓扑结构。图5a示出了网状拓扑。如图5a所示,多个IoT设备511之间被互相联通起来,并且每一个IoT设备511至少与其他两个IoT设备511相连,从而形成网状拓扑。图5b示出了星型拓扑结构。在星型拓扑,各个IoT设备512通过点到点的方式连接到一个IoT设备513上。IoT设备513执行集中式通信控制策略,由IoT设备513向目标设备传送信息,因此IoT设备513的结构相对复杂,负载更重。此种拓扑结构的雾装置承担任务时,可以将简单任务放在IoT设备512执行,将复杂任务放在IoT设备513上执行。例如,IoT设备513将实时采集到的视频流发送给IoT设备513,IoT设备513对视频流进行初步整理和加工,例如删除无效视频流、将视频流重新编解码、压缩视频流,加工后的视频流传送给后端的云监控服务平台。通过这种方式,减少数据通信量并节省带宽。图5c示出了环状拓扑。在环形网中,IoT设备514通过点对点链路形成形成封闭的环。图5d示出了树型拓扑。如图上所示,IoT设备515作为根节点,其余IoT设备516作为子节点,间接或者直接地连接到IoT设备515。在树型拓扑,每个子节点的IoT设备都可以经由一条唯一路径到达根节点。和星型拓扑中的IoT设备513类似,IoT设备515的结构可以相对复杂,并承担更多任务。同样,具有此种拓扑的雾装置承担任务时,可以将简单任务放在IoT设备515执行,将复杂任务放在IoT设备516上执行。图5e示出了混合拓扑。图上标记出构成混合拓扑的环状拓扑51和树型拓扑52和53,这里就不再详细描述。
在上述拓扑中,作为通信基础设施的通信类型有多种,包括但不局限于经由USB(通用串行总线,Universal Serial Bus)端口、PCIe(高速串行计算机扩展总线标准,peripheral component interconnect express)总线、UART(通用异步收发传输器,Universal Asynchronous Receiver/Transmitter)。
当然,雾装置还可以其他拓扑形式,尤其是当雾装置应用于实际场景时,工程人员会结合各个IoT设备的硬件特性以及用户需求,实现上述拓扑中的一种或者多种上述拓扑的更复杂的组合。
根据本公开实施例,在上述的拓扑或者其更复杂的组合上,可以构建虚拟树型网络结构。虚拟树型网络结构的构建过程包括以下步骤:先将其中的一个IoT设备确定为根节点,将其余设备确定为子节点,然后从根节点开始,确定直接与根节点互联的IoT设备(即根节点的相邻的IoT设备)作为第一级子节点,针对每个第一级子节点,确定直接与每个第一级子节点互联的IoT设备作为第二级子节点,以此类推,直到最后一级的子节点。虚拟树型网络结构的构建过程可在将各个IoT设备的物理连接完成之后执行。在工程上实现时,当确定了作为根节点的IoT设备之后,可以由这个IoT设备开始,逐级探测各级子节点,并在探测过程中,获得各个IoT设备与相邻IoT设备互联的通信类型。也可以在进行各个IoT设备的物理连接之时,记录各个IoT设备与其他IoT设备的连接关系及通信类型。各个IoT设备与相邻IoT设备之间的通信类型可能有多个,但在虚拟树型网络结构中,相邻两个IoT设备之间只能有一种通信类型,因此在具有多个通信类型的情况下,需要从中选出一个作为虚拟树型网络结构中的通信类型。
下面以图6a和6b为例,描述如何构建虚拟树型网络结构。其中,图6a示出了在图5a所示的网型拓扑中构建的虚拟树型网络结构,图6b示出了在图5d所示的树型拓扑中构建的虚拟树型网络结构。
参考图6a所示,将IoT设备601被设定为根节点,其余IoT设备B、C、D和E被设定为子节点。根据各个IoT设备到根节点经过的路径,定义B、C、D和E的资源标识符(URI),分别为:/root/B-id、/root/C-id、/root/D-id和/root/E-id。B-id、C-id、D-id和E-id为IoT设备B、C、D和E的名称标识。在虚拟树型网络结构中,IoT设备B、C、D和E均为根节点的第一级子节点。将虚拟树型网络结构整理为连接信息,并以表格1存储该信息。
表格1
从表格1可以看出,虚拟树型网络结构的相邻两个IoT设备之间只有一种通信类型。如果Root->/root/D-id之间的通信类型包括两种:USB端口和PCIe总线,则选择Pcie总线作为root和IoT设备D的通信类型并记录在连接信息中。被选中的通信类型应为优选的通信类型,即该通信类型具有较为高效的通信效率或具有其他好处。
参考图6b所示,IoT设备606为树型物理互联网络的根节点,同时也被设定为虚拟树型网络结构的根节点,将其余设备A、B、C、D和E设定为虚拟树型网络结构的子节点。图上A和B为第一级节点,C为A的第二级节点,D和E为B的第二级节点。换言之,物理互联网络与虚拟树型网络结构的结构相同。根据各个IoT设备到根节点经过的路径,定义A、B、C、D和E的资源标识符(URI),分别为:/root/A-id、/root/B-id、/root/C-id、/root/D-id和/root/E-id。A-id、B-id、C-id、D-id和E-id为IoT设备A、B、C、D和E的名称标识。
将虚拟树型网络结构整理为连接信息,并以表格2存储该消息。
表格2
源设备->目的设备 |
通信类型 |
root->/root/A-id |
USB |
root->/root/B-id |
USB |
/root/A-id->/root/A/C-id |
Pcie |
/root/B->/root/B/D-id |
UART |
/root/B->/root/B/E-id |
Pcie |
如果在物理互联网络中,一个IoT设备到根节点有多条路径,则在构建虚拟树型网络结构时,需要在多条路径选出一条作为虚拟树型结构中的路径。可以以下述之一的策略选出该路径:1)选出的路径经过最少数量的IoT设备;2)根据通信类型选出具有较高通信效率的一条路径,例如,优先选择以PCIe总线连接的IoT设备。
在一个物理的互联网络中,可以构建多个虚拟树型网络结构。例如,将其中一部分IoT设备构建在一个虚拟树型网络结构中,将另一部分IoT设备构建在另一个虚拟树型网络结构中,两个虚拟树型网络结构各自承担不同任务,两个虚拟树型网络结构通过两个根节点进行通信。多个虚拟树型网络结构之间可以重叠。例如将一个IoT设备同时作为两个虚拟树型网络结构的根节点。根节点也可以作为和外部系统(例如云计算平台)交互的I/O节点。虚拟树型网络结构是各自独立的,某个虚拟树型网络结构的任务失败不会影响到其他虚拟树型网络结构的任务执行。虚拟树型网络结构中还可以任意增加节点。多个虚拟树型网络结构还可以通过路由器或交换机连接,例如将每个虚拟树型网络结构的根节点连接到路由器或交换机上,由此组成了更复杂的互联网络。
由于连接信息只记载了虚拟树型网络结构中的各个IoT设备之间的连接关系,因此当根据虚拟树型网络结构传输消息时,任意两个IoT设备之间只有唯一消息传输路径,每个IoT设备只需要按照该唯一消息传输路径将消息从本地发送给下一个IoT设备,从而,每个IoT设备都不需要具有复杂的路由策略。由于复杂的路由策略不仅需要硬件支持,而且在运行时往往会需要消耗很多资源,这些都不利于IoT设备的成本控制和功耗控制。因此,相比较而言,本公开实施例提供的雾装置将降低整体上的制造成本控制和运行功耗。
当源IoT设备预备向目标IoT设备发送一条消息时,源IoT设备检索连接信息,以得到消息传输路径。消息传输路径有以下两种可能:该消息传输路径上包含了根节点和该消息传输路径不包含根节点。包括根节点的消息传输路径可以表示为:源IoT设备->若干中间设备->根节点->若干中间设备->目标IoT设备(即源IoT设备->根节点->目标IoT设备)。不包括根节点的消息传输路径可以表示为:源IoT设备->若干中间设备->目标IoT设备(中间设备也可以不存在,即目标IoT设备为源IoT设备的相邻设备)。检索完连接信息之后,源IoT设备可以将消息以及检索到消息传输路径传送给下一个IoT设备,下一个IoT设备按照消息传输路径将消息接着往后传输,而无需再检索连接信息,以此类推。源IoT设备还可以将消息和目标IoT设备传送给下一个IoT设备,下一个IoT设备继续检索连接信息,得到消息传输路径,并将消息和目标IoT设备接着往后传输,以此类推。连接信息存储在每个IoT设备,以便于每个IoT设备都可以作为源IoT设备发送消息。另外,每个IoT设备还可以仅存储与其相关的连接信息,即每个IoT设备仅存储上述表格中的一部分数据(上述表格列出了所有IoT设备的连接信息),从而减少了每个IoT设备上的数据存储量。此外,如果设定如上格式的资源标识符,则可以利用源IoT设备和目标IoT设备的资源标识符得到消息传输路径,例如,如果IoT设备B的资源标识符为/root/B,则IoT设备D的资源标识符为/root/B/D-id,则直接将消息从B发送到D,如果IoT设备B的资源标识符为/root/B,则IoT设备D的资源标识符为/root/C/D-id,则将消息从B发送到D的消息传输路径为:B->root->C->D。
图7是本公开一个实施例的消息路由方法的交互图。如图上所示,70表示物理互联网络,71表示虚拟树型网络结构,由源IoT设备711发送消息到目标IoT设备712,713为消息传输路径上的途径IoT设备。
从源IoT设备711开始,执行步骤S1,即检索连接信息,获得到达目标IoT设备712的要经过的IoT设备713,然后执行步骤S2,即将消息发送给要经过的IoT设备713,IoT设备713接收到消息之后,执行步骤S3,即检索连接信息,获得到达目标IoT设备的要经过的IoT设备713,然后执行步骤S4,重复这样的操作,直到将消息发送给目标IoT设备712。
图8是本公开一个实施例的消息传输系统的软件架构图。该消息传输系统可部署在每个IoT设备中。如图上所示,该消息传输系统包括一个客户端接口模块80和作为服务端的通信服务模块81。客户端接口模块80用于发起一个消息传输请求,该消息传输请求可指定消息内容和目标IoT设备。通信服务模块81接收到消息之后,并根据连接信息确定从当前IoT设备到达目标IoT设备要经过的IoT设备,并据此发送消息,以将消息依次发送给要经过的IoT设备并到达目标IoT设备。当一个IoT设备作为源IoT设备时,通过客户端接口模块80和通信服务模块81将消息发送给要经过的下一个IoT设备,而下一个IoT设备通过通信服务模块81接收消息,并将消息发送给下一个IoT设备,重复这样的操作,最终将消息发送给目标IoT设备。
可选地,通信服务模块81包括前端路由单元811和后端通信单元812。前端路由单元811接收消息,检索连接信息,获得到达目标IoT设备要经过的IoT设备,并确定当前IoT设备与相邻IoT设备的通信类型,并以当前IoT设备与相邻IoT设备的通信类型作为输入参数调用通信接口以发送消息。后端通信单元812向前端路由单元811提供通信接口。
可选地,通信服务模块81可作为一个守护进程常驻在内存中运行,当通信服务模块81接收到从客户端接口模块80发送过来的消息时,创建线程以进行相应处理。通信服务模块81时刻处于消息侦听状态,不仅侦听来自本地的客户端接口模块80的相应端口,而且侦听相邻的IoT设备上的的相应端口,使得通信服务模块81不仅能够接收本地的客户端接口模块80发送来的消息,也能够接收相邻的IoT设备上的客户端接口模块80发送来的消息。
由于每个IoT设备可以具有一个或以上的通信类型,因此后端通信单元812可在启动时构建各种通信类型的通信线程,每种通信类型与一种通信硬件对应,例如usb线程、pcie线程、uart线程,每个通信类型的通信线程调用基于相应通信硬件的硬件通信线程。对于前端路由单元811来说,由于不同通信的实现细节都封装在通信接口中,因此它无需关注不同通信类型的实现细节。实践中,可根据所有可选的通信硬件编码通信模块,并将通信模块编译成通信线程库,该通信线程库作为固件安装在所有IoT设备,支持IoT设备所有可用的通信类型。后端通信单元812初始化的时候,加载通信线程库,然后前端路由单元811根据需要调用通信接口。
如图9所示,研发人员经过步骤901-903构建出通信线程库90。步骤901定义通信线程API,步骤902根据头文件填写代码,步骤903编译得到通信线程库。通信线程库90可以作为固件或者软件程序存储在IoT设备的存储器中。后端通信单元812启动后,执行步骤911和912,即加载通信线程库,并接受前端路由单元的通信调用。
可选地,客户端接口模块80与通信服务模块81以及前端路由单元811和后端通信单元812之间通过本地过程调用(Local Procedure Call)的形式实现通信。本地过程调用(Local Procedure Call)是本地进程之间实现通信的技术手段。
应理解,当在源IoT设备与目标IoT设备之间传输消息时,首先源IoT设备先利用客户端接口模块80和通信服务模块81将消息发送给下一个IoT设备,下一个IoT设备的通信服务模块81接收到消息,将消息传输给下一个IoT设备,重复上述操作,直到消息被传送给目标IoT设备。
在本实施例中,前端路由单元811无需关心后端通信单元812的具体细节,因此对通信线程库90的代码扩展不会影响到前端路由单元811,更不会影响到通信服务模块81。这种扩展有时难以避免。例如,当雾装置中增加新的IoT设备时,而现有的通信线程库90不能支持该IoT设备的通信硬件,则此时就需要在通信线程库90增加对该通信硬件的支持。通信线程包括软件通信线程和硬件通信线程并通过软件线程调用硬件线程。
需要说明的是,上述消息传输系统可实现为计算机程序,并作为固件存储在每个IoT设备的存储器中,由物联网处理器执行。
图10用于示意前端路由单元811和后端通信单元812之间的调用关系。如图上所示,前端路由单元811调用后端通信单元812,后端通信单元812在启动时构建各种通信类型的软件通信线程,并在一个通信类型的软件通信线程中操作相应通信类型的硬件通信线程。图上示出了PCIE通信线程、USB通信线程和UART通信线程。
综上所述,本公开实施例利用IoT设备之间的通信耦合构建计算系统,该系统基于虚拟树型网络结构进行消息传输,使得每个IoT设备都无需专门的交换机和路由器等网络组件以及复杂的路由策略就可以完成消息传输,由此本公开实施例非常适用于低成本和低功耗的IoT设备组成的互联网络。
本公开实施例的商业价值
在物联网时代,一些低端的电子设备有连接到物联网上的需求。但是这些电子设备一般不具有网卡等网络组件,如果给这些电子设备增加网卡等网络组件,一方面将大大地增加产品成本,另一方面又增加了系统功耗,而基于本公开实施例,这些电子设备则能够以低成本和低功耗形式满足这些需求。因此本公开实施例有很多应用场景。
例如,本公开实施例可实现在交通灯控制系统中。具体地,交通灯控制系统由多个交通灯控制装置的通信耦合而构成的互联网络,每个交通灯控制装置耦接至少一个交通灯,每个交通灯控制装置存储有连接信息,连接信息用于描述基于互联网络构建的虚拟树型网络结构中的每个交通灯控制装置访问作为根节点的交通灯控制装置要途径的交通灯控制装置,每个交通灯控制器的结构和在先的IoT设备结构相同,每个交通灯控制器都可以根据连接信息确定消息从当前交通灯控制装置到达目标交通灯控制装置要途径的交通灯控制装置,然后根据要途径的交通灯发送消息,以实现将消息依次发送给要途径的交通灯控制装置并到达目标交通灯控制装置,而接收到的消息的交通灯控制器根据消息控制与其耦接的交通灯,例如控制交通灯的颜色或开关。本示例中的交通灯控制装置可与交通灯集成在一起。
再例如,本公开实施例可实现在工控系统。具体地,工控系统包括由多个传感器设备的通信耦合而构成的互联网络,且每个传感器设备有连接信息,连接信息用于描述基于互联网络构建的虚拟树型网络结构中的每个传感器设备访问作为根节点的控制装置要途径的传感器设备,每个交通灯控制器的结构和在先的IoT设备结构相同,每个传感器设备包括传感器、处理器和存储器,存储器存储有可由处理器执行的计算机程序,计算机程序被执行时实现以下操作:根据连接信息确定消息从当前传感器设备到达目标传感器设备置要途径的控制装置,将消息依次发送给要途径的传感器设备并到达传感器设备,其中,传感器设备根据接收到的消息控制其内部的传感器工作,并可将得到的数据回传给当前传感器设备。
还有,本公开实施例可用于云计算边缘采集视频或者人脸图像并对采集到的视频流或人脸图像进行编解码、压缩等后上传到视频AI平台。
综上所述,本公开实施例提供的低成本、低功耗的消息路由解决方案能够应用于多个应用场景,因此该解决方案将具有市场前景和商业价值。
本领域的技术人员能够理解,本公开可以实现为系统、方法和计算机程序产品。因此,本公开可以具体实现为以下形式,即完全的硬件、完全的软件(包括固件、驻留软件、微代码),还可以实现为软件和硬件结合的形式。此外,在一些实施例中,本公开还可以实现为一个或多个计算机可读介质中的计算机程序产品的形式,该计算机可读介质中包含计算机可读的程序代码。
可以采用一个或多个计算机可读介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如但不限于为电、磁、光、电磁、红外线或半导体的系统、装置或器件,或其他任意以上的组合。计算机可读存储介质的更具体的例子包括:具体一个或多个导线的电连接,便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或者闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器、磁存储器或者上述任意合适的组合。在本文中,计算机可读的存储介质可以是任意包含或存储程序的有形介质,该程序可以被处理单元、装置或者器件使用,或者与其结合使用。
计算机可读信号介质可以包括在基带中或者作为截波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或者其他任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质之外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令系统、装置或器件使用或者与其结合使用的程序。
计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于无线、电线、光缆、RF等等,以及上述任意合适的组合。
可以以一种或者多种程序设计语言或者组合来编写用于执行本公开实施例的计算机程序代码。所述程序设计语言包括面向对象的程序设计语言,例如JAVA、C++,还可以包括常规的过程式程序设计语言,例如C。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中,远程计算机可以通过任意种类的网络包括局域网(LAN)或广域网(WAN)连接到用户计算机,或者,可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
以上所述仅为本公开的优选实施例,并不用于限制本公开,对于本领域技术人员而言,本公开可以有各种改动和变化。凡在本公开的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本公开的保护范围之内。