【具体实施方式】
为了使本发明的目的、技术方案和优点更加清楚,下面结合附图和具体实施例对本发明进行详细描述。
在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。
应当理解,本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。
取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地,取决于语境,短语“如果确定”或“如果检测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当检测(陈述的条件或事件)时”或“响应于检测(陈述的条件或事件)”。
本发明旨在提供一种技术架构,通过一种“可信物标识”,使得整个系统的数据流转,包括其中的安全机制,均基于该标识。下面通过实施例对本发明进行详述。
图1为本发明实施例提供的系统结构图,如图1中所示,该系统主要分为两大部分:第一部分为终端设备,第二部分为服务端设备。其中终端设备可以包括但不限于诸如:智能移动终端、智能家居设备、网络设备、可穿戴式设备、智能医疗设备、PC(个人计算机)等。其中智能移动设备可以包括诸如手机、平板电脑、笔记本电脑、PDA(个人数字助理)、互联网汽车等。智能家居设备可以包括智能家电设备,诸如智能电视、智能空调、智能热水器、智能冰箱、智能空气净化器等等,智能家居设备还可以包括智能门锁、智能插座、智能电灯、智能摄像头等。网络设备可以包括诸如交换机、无线AP、服务器等。可穿戴式设备可以包括诸如智能手表、智能眼镜、智能手环、虚拟现实设备、增强现实设备、混合现实设备(即可以支持虚拟现实和增强现实的设备)等等。智能医疗设备可以包括诸如智能体温计、智能血压仪、智能血糖仪等等。智能终端设备在网络中数量众多,且可能分布广泛,在图1所示系统中,仅以一个智能终端00为例示出。
服务端设备在网络侧,因各自具备的功能不同,在图1所示系统中,将其分为包含第二装置的服务端设备11、包含第三装置的服务端设备12、包含第四装置的服务端设备13、包含第五装置的服务端设备14和包含第六装置的服务端设备15。本申请实施例中,各服务端设备的划分为逻辑上的划分,实际部署时,各服务端设备可以部署在一台或多台服务器中。例如,服务端设备11、服务端设备12、服务端设备13、服务端设备14、服务端设备15分别对应一台服务器;再例如,服务端设备11、服务端设备12、服务端设备13、服务端设备14、服务端设备15被部署在一台服务器上;再例如,服务端设备11、服务端设备12、服务端设备13、服务端设备14、服务端设备15中的至少两个被部署在同一台服务器。
智能终端00中的第一装置,负责基于设备标识建立终端设备与包含第二装置的服务端设备之间的通道,并在通道上进行数据传输。
服务端设备11中的第二装置,负责在建立通道时,基于设备标识对终端设备进行身份认证,并在通道上进行数据传输。
其中,智能终端的设备标识可以是预先为合法智能终端分配的、能够唯一标识一个设备的身份标识。在本发明实施例中,可以由服务端设备12预先分配,并在终端设备00出厂时写入第一装置。
即服务端设备12中的第三装置,负责为合法终端设备分配设备唯一身份标识,并预先提供给各合法终端设备的第一装置。
图1所示的系统可以运行在物联网环境下,每一个终端设备能够通过任意一种方式直接或者间接地接入互联网,因此,接入该系统中的智能终端设备也可以称为互联网设备(Internet Device)。互联网设备具备数据和服务在端和云之间流动的能力,使得互联网服务能够通过各种硬件到达用户。在一些例子中,终端设备中可以包括YoC(Yun on Chip)云芯片,基于YoC让一个互联网设备很容易承载一个互联网服务。YoC中内置互联网设备的设备标识(Internet Device ID,称为ID2),ID2可以固化在芯片中,是不可篡改、不可预测的唯一ID。YoC中还可以包括多个密钥,例如,用于提高通信安全的密钥、用于进行设备认证的密钥、用于提高终端安全的密钥、用于提高系统安全的密钥、用于提高应用安全的密钥等,这些密钥可以与ID2关联。
在此结合图2所示实施例,对设备标识的生成机制进行介绍。在该实施例中还会涉及到厂商管理设备和标识写入设备,其中厂商管理设备设置于厂商侧,负责设备生产过程中对设备相关的管理。标识写入设备可以设置于厂商侧,也可以独立设置,负责将为终端设备分配的设备标识写入终端设备。如图2所示,可以包括以下步骤:
在201中,厂商管理设备向包含第三装置的服务端设备发送标识分配请求。
其中标识分配请求中可以包括待分配标识的设备信息,例如待分配标识的设备的型号信息、系统版本信息以及芯片信息中的至少一种。还可以包括待分配标识的设备数量信息。
在202中,包含第三装置的服务端设备针对待分配标识的设备生成唯一的设备标识。
在本步骤中,包含第三装置的服务端设备可以利用标识分配请求中携带的设备信息,为待分配标识的设备生成设备标识,一个设备标识能够唯一标识一个设备,以与其他设备相区别。
具体在生成标识信息时,可以按照预设的标识生成规则,生成对于各设备而言是唯一的,能够与其他设备相区别的信息。下面举一个标识生成规则的实例:
生成的设备标识可以由17个字符构成,采用8个字节存储。格式可以采用:Y-AAAA-BBBB-XXXXXXXX
其中,第一个字符“Y”可以采用固定字符,作为设备标识的标识符。
四个字符“AAAA”可以采用十六进制字符,代表厂商编号。
四个字符“BBBB”可以采用十六进制字符,代表待分配设备的芯片型号。当然,也可以采用诸如系统版本号等。
最后八个字符“XXXXXXXX”可以采用十六进制字符,由一串随机数组成。
上面仅仅是本发明实施例所列举的一个实例,也可以采用其他长度的字符,其中的部分内容也可以采用其他设备信息。
另外,除了利用设备信息生成设备标识之外,包含第三装置的服务端设备还可以利用其它信息生成设备信息,例如采用生成随机数的方式来生成设备信息,只要保证生成的设备信息的唯一性即可。
除了接收到标识分配请求后,实时生成设备标识的方式之外,也可以预先生成一些设备标识构成标识池,在接收到标识分配请求后,从标识池中分配一个设备标识给待分配标识的设备。
在203中,包含第三装置的服务端设备将生成的设备标识发送给标识写入设备。
需要说明的是,包含第三装置的服务端设备可以将生成的设备标识直接发送给标识写入设备,也可以经由厂商管理设备发送给标识写入设备。
在204中,标识写入设备将设备标识写入待分配标识的设备。
本步骤中,标识写入设备可以采用烧录等方式,将设备标识写入待分配标识的设备芯片中,为了保证安全性,该设备标识可以存储于第一装置的安全存储。写入设备的设备标识不能够更改,并且设备能够在需要时,获取自身的设备标识,以该设备标识表征自己的身份以及身份的合法性。
由图2所示流程可以看出,厂商不再具有生成设备标识的权限,而将设备标识的生成统一放在了网络端,由包含第三装置的服务端设备统一维护各设备标识,也就是说,由包含第三装置的服务端设备统一维护设备身份合法性。
另外,包含第三装置的服务端设备还可以进一步生成密钥信息,将该密钥信息中的全部或部分连同设备标识一起发送给标识写入设备,由标识写入设备将接收到的设备标识和密钥信息都烧录至待分配标识的设备芯片。其中包含第三装置的服务端设备可以生成一个密钥,除了自身维护该密钥之外,将该密钥连同设备信息发送给标识写入设备。包含第三装置的服务端设备也可以生成公钥-私钥对,除了自身维护该公钥-私钥对之外,将公钥或者私钥连同设备标识发送给标识写入设备以写入设备。
另外,为了保证安全,可以将标识信息连同密钥信息一起写入设备的安全存储。安全存储可以是利用诸如ARM TrustZone或Secure Element或TI M-Shield等机制在硬件上隔离出的安全区域,也可以是利用虚拟化机制隔离出一个独立的安全环境,安全存储保证了存入的密钥信息以及设备标识不可篡改和擦除。
对于采用上述实施例所提供的方式生成的设备标识可以供安全平台对设备的身份进行合法性认证。如果设备上报的设备标识是安全平台生成并维护的设备标识,则确定该设备标识对应的设备为合法设备。这一认证可以广泛地应用于多种业务场景,包括但不限于设备激活流程、业务数据下发流程、设备数据存储于云端的流程;等等,只有合法身份的设备才能够被激活,只有针对合法身份的设备才能够进行业务数据下发,只有合法身份的设备数据才能够享受存储于云端的服务,等等。
上述终端设备00与服务端设备11之间的通道可以包括但不限于:消息通道、流媒体通道和大文件通道。其中消息通道可以是一个长连接通道,用于控制信令和少量数据的传输;流式通道是用于一段时间内的流式数据通讯;大文件通道用于一次性的大量数据通讯。
为了保证安全,在建立通道的过程中需要对终端设备的身份进行认证。下面对建立通道的过程进行描述。
终端设备00中的第一装置获取认证码,将包含认证码和设备标识的数据发送给包括第四装置的服务端设备13。
服务端设备13中的第四装置接收包含认证码和设备标识的数据,利用认证码和设备标识对终端设备进行身份认证,且认证通过后,向终端设备00返回建立通道的参数信息。
终端设备00中的第一装置接收包括第四装置的服务端设备返回的用于建立通道的参数信息,利用参数信息,建立通道。
其中,服务端设备13中的第四装置在利用认证码和设备标识对终端设备进行身份认证时,可以采用以下两种方式:
第一种方式:服务端设备13中的第四装置将设备标识与认证码发送给服务端设备12,并获取服务端设备12返回的认证结果。
第二种方式:服务端设备13中的第四装置将设备标识发送给服务端设备12,获取服务端设备12返回的设备标识对应的认证码;利用从服务端设备12获取的认证码,对终端设备00发送的认证码进行认证。
其中,上述用于建立通道的参数信息可以包括:会话标识、连接服务器的IP地址和端口号,还可以包括:种子密钥。终端设备00的第一装置和服务端设备11的第二装置在通道上进行数据传输时,利用该种子密钥进行加/解密。
下面结合图3所示实施例,对上述通道建立的过程进行详述。该实施例中的连接服务器对应上述的服务端设备11,管理服务器对应上述的服务端设备13,标识服务器对应上述的服务端设备12。如图3所示,该过程可以包括以下步骤:
在301中,终端设备获取认证码。
认证码是用于提供给管理服务器进行认证时使用的,在本发明实施例中对认证码的形式并不加以限制,只要其具有一定的随机性和一定时间范围内的唯一性即可。对于认证码,可以由标识服务器向终端设备分配并进行维护。标识服务器为终端设备分配认证码后,可以在本地维护终端设备的唯一标识信息与认证码之间的对应关系。具体将在后续实施例中进行详述。
在302中,终端设备将包含认证码的数据发送给管理服务器。
在本发明实施例中,在发送认证码的同时将终端设备的唯一标识信息发送给管理服务器,以便管理服务器利用该唯一标识信息对认证码进行认证。
在303中,管理服务器利用包含认证码的数据进行认证。
在进行认证时,管理服务器可以将该认证码提供给标识服务器,由标识服务器对该认证码进行认证后,返回认证结果给管理服务器。也可以将终端设备的唯一标识信息提供给标识服务器,并接收标识服务器返回的该唯一标识信息对应的认证码,然后利用该认证码对终端设备发送的认证码进行认证。考虑到更高的安全性,优选前一种实现方式。
更进一步地,终端设备发送的包含认证码的数据还可以包括签名信息,该签名信息用于管理服务器进行校验使用,具体将在后续实施例中详述。
在304中,认证通过后,向终端设备返回用于建立通道的参数信息。
其中用于建立通道的参数信息可以包括:种子密钥(seedKey)和连接参数。其中seedKey是用于对传输数据进行加/解密的密钥;连接参数用于建立终端设备与连接服务器之间的连接,可以包括诸如sid、连接服务器的IP地址和端口号等。
上述包含认证码的数据可以通过HTTP POST的形式发送,参数信息可以通过HTTP响应的形式发送。
在305中,终端设备利用参数信息,建立与连接服务器之间的通道,后续用户端与云端之间要传输的数据通过该通道进行传输。
建立通道主要包括三方面的内容:一方面是利用连接参数建立终端设备与连接服务器之间的长连接的过程,另一方面建立云通道的过程;在一方面是配置该云通道上数据加/解密采用seedKey。这几个方面的内容将在后续实施例中进行详细描述。
下面结合一个具体的实施例,对图4所示过程进行详细描述。图4为本发明实施例提供的详细方法流程图,其中CCP模块和ID2模块为终端设备中的两个模块,CCP模块为系统级别的执行模块,也可以是应用级别的执行模块,若为应用级别的执行模块,则需要ID2模块向该应用级别的模块开放访问权限。ID2模块可以为终端设备中设置于安全执行环境的模块,例如采用安全芯片的形式,在本实施例中终端设备的唯一标识采用ID2表示。CCP是云通道协议(Cloud Channel Protocol)的简称,对于云端与用户端之间的通道协议也可以采用其他协议类型,在本发明实施例中以CCP协议为例,如图4中所示,该方法可以包括以下步骤:
在401中,CCP模块向ID2模块请求ID2。
在本发明实施例中采用固化于终端设备的芯片中,不可篡改和非法获取的ID2作为终端设备的唯一标识,该ID2固化于安全芯片中,该安全芯片在本发明实施例中作为ID2模块,即只有ID2模块具有对ID2进行处理的权限,其他模块可以向ID2模块请求ID2。
当终端设备需要与云端进行交互时,需要首先建立终端设备与云端的连接服务器之间的CCP通道以进行数据传输,此时可以由CCP模块向ID2模块请求ID2。
在402中,ID2模块向标识服务器请求认证码,该请求中携带该终端设备的ID2。
在本发明实施例中标识服务器维护有所有合法设备的ID2,并且在本发明实施例中由标识服务器为各合法的终端设备分配认证码。标识服务器接收到请求后,可以首先对请求中携带的ID2进行合法性验证,如果该ID2为合法设备的ID2,则为该终端设备分配认证码;否则,拒绝为该终端设备分配认证码。
在403中,ID2模块获取标识服务器返回的认证码。
需要说明的是,ID2模块与标识服务器之间的信息交互通过ID2模块和标识服务器之间的通道发送。在ID2模块中可以预置标识服务器的连接参数,在ID2模块与标识服务器之间建立连接后,可以采用预先约定的密钥(该预先约定的密钥可以预先写入ID2模块)对上述ID2、认证码进行加解密;也可以在连接建立后进行密钥的协商,然后利用协商的密钥对上述ID2、认证码进行加解密。
在404中,ID2模块对ID2、认证码、appkey和appsecret进行签名后,将ID2、认证码、appkey以及签名信息提供给CCP模块。
在此对签名的方式并不加以限制,可以采用诸如RSA算法等。
需要注意的是,在进行签名时是对ID2、认证码、appkey和appsecret这四个参数进行的,但发送的数据中并不包含appsecret。另外,appkey是来源于CCP模块的,也就是说,ID2模块在进行签名之前,首先从CCP模块获取appkey,然后再执行上述签名的处理后,再将ID2、认证码、appkey和签名信息提供给CCP模块,该过程图中未示出。
上述认证码的获取和签名都在ID2模块进行,由于ID2模块是一块安全芯片,属于安全执行环境,因此认证码无法被外界获取和篡改,加强了安全性。
在405中,CCP模块将ID2、认证码、应用密钥(appkey)以及签名信息通过HTTP POST形式发送给管理服务器。
在406中,管理服务器将ID2和认证码发送给标识服务器。
在407中,管理服务器利用该终端设备的ID2、认证码、appkey以及签名信息进行校验,以及获取标识服务器对认证码的认证结果。
对签名进行校验的过程可以包括:首先利用appkey确定对应的应用秘密(appsecret),在此需要说明的是,在管理服务器中预先维护有各appkey对应的appsecret;然后利用确定出的appsecret对签名信息进行验证,即在本地对ID2、认证码、appkey和appsecret进行签名,将得到的签名信息与终端设备发送的签名信息进行比对,如果一致,则校验通过;否则校验失败。
对于标识服务器而言,在接收到管理服务器发送的ID2和认证码后,确定该ID2对应的认证码。由于认证码是标识服务器针对各终端设备分配的,并且在标识服务器本地维护了各ID2对应的认证码,因此可以确定出管理服务器提供的ID2对应的认证码,然后将确定出的认证码与接收到的认证码进行比对,如果一致,则认证通过,否则认证失败。其中,认证码的分配方式可以是随机生成的,也可以从认证码池中随机选择的一个认证码。
需要说明的是,标识服务器维护的认证码是存在老化时间的,当达到老化时间后,该认证码失效。
除了上述认证的实现方式之外,还存在另一种实现方式:管理服务器将ID2提供给标识服务器,标识服务器并不负责进行认证码的认证,而是将该ID2对应的认证码返回给管理服务器,由管理服务器利用标识服务器返回的认证码对终端设备提供的认证码进行认证,如果不一致,则认证失败。但考虑到安全性的因素,前一种实现方式的安全性更高,因此优选前一种实现方式。
需要说明的是,上述校验和对认证码的认证可以采用任意的顺序先后执行,也可以同时执行。只有校验和对认证码的认证均成功时,才算认证通过,有一个不成功,则认为认证失败。
或者,可以先进行校验,如果校验失败,则可以不考虑或者不进行对认证码的认证;如果校验成功,则进一步考虑或者进行对认证码的认证。也可以先进行对认证码的认证,如果认证成功,再进一步进行校验;如果认证失败,则不用进行校验。
在408中,如果认证通过,则将用于建立通道的参数信息通过HTTP响应的形式发送给终端设备,其中用于建立通道的参数信息可以包括seedKey和连接参数,连接参数包括诸如sid、apid、连接服务器的IP地址和Port号。
sid表示会话id,由管理服务器生成,用于标识终端设备与连接服务器之间一次连接的会话,后续终端设备与连接服务器之间的数据包都要携带该sid。
apid表示终端设备的应用标识,其是用于标识应用的,属于同一应用的各通道都采用相同的apid。该apid是可选的内容。
其中发送给终端设备的用于建立通道的参数信息也是经过加密的,具体方式可以为:管理服务器向终端设备返回的HTTP响应消息的消息头中携带利用终端设备的ID2进行加密后的seedKey,消息体中携带利用seedKey加密后的连接参数。
在409中,CCP模块将HTTP响应提供给ID2模块。
在410中,ID2模块解析HTTP响应得到其中的用于建立通道的参数信息并提供给CCP模块。
解析过程可以包括:利用终端设备的ID2对HTTP响应消息的消息头进行解密,得到seedKey;再利用seedKey对消息体进行解密,得到诸如sid、apid、连接服务器的IP地址和Port号等连接参数。
也可以CCP模块将HTTP响应消息的消息头提供给ID2模块,由ID2模块利用ID2对HTTP响应消息的消息头进行解密,得到seedKey;然后将seedKey提供给CCP模块。CCP模块利用seedKey对HTTP响应消息的消息体进行解密,得到诸如sid、apid、连接服务器的IP地址和Port号等连接参数。该种实现方式图中未示出。
在411中,CCP模块利用连接参数与连接服务器建立TCP长连接。
TCP长连接建立过程为已有技术,在此不再详述。
在412中,CCP模块和连接服务器之间进行CCP连接报文的交互,从而建立终端设备与连接服务器之间的CCP通道。即CCP模块向连接服务器发送CCP连接请求,连接服务器向CCP模块发送CCP连接确认。
由于本实施例是以CCP协议为例进行描述,因此本步骤中进行通道建立时,交互的是CCP连接报文,若采用其他通道协议,则进行其他通道协议类型的连接报文。
在413中,终端设备和连接服务器之间通过seedKey对云通道上传输的数据进行加/解密。
管理服务器在分配sid和seedKey给终端设备后,会将其同步给连接服务器,也就是说,连接服务器可以从管理服务器同步sid和seedKey之间的对应关系。后续终端设备在通道上发送来的数据包会携带sid,连接服务器通过该sid就能够获知在该通道上采用什么seedKey,即该sid对应的seedKey。
终端设备对于发送给连接服务器的数据包采用seedKey进行加密,对于来自连接服务器的数据包采用seedKey进行解密。连接服务器对于发送给终端设备的数据包采用seedKey进行加密,对于来自终端设备的数据包采用seedKey进行解密。
在CCP通道上传输数据时,可以采用异步的方式收发数据。下面分别对数据的接收和发送机制进行详述。
通过CCP通道接收数据时,由于服务端返回的TCP数据是零散的、分片的且可能跨越CCP多包的,因此为了能够正确解析CCP的每个数据包,本发明实施例可以采用状态机的方式接收数据包。
另外,为了保证通道的可靠性,在CCP通道上存在一个心跳检测机制,即连接服务器周期性地发送心跳消息Ping,例如,连接服务器每隔70秒向终端设备发送一个Ping。终端设备接收到Ping后返回心跳响应Pong。若连接服务器超过设定时长未接收到Pong,则关闭该CCP通道。
在终端设备侧周期性地检测是否接收到Ping,例如每10秒检测一次是否接收到Ping。若终端设备超过设定时长未接收到Ping,例如超过120秒未接收到Ping,则也可以关闭该CCP通道。当CCP通道由于上述原因被关闭后,CCP模块可以重新执行图4所示流程,从而重新建立终端设备与连接服务器之间的CCP通道。
另外,终端设备可以对注册的网络事件进行监听,如果网络出现异常,则关闭该CCP通道。当网络恢复后,CCP模块可以重新执行图4所示流程,从而重新建立终端设备与连接服务器之间的CCP通道。
图3和图4所示实施例提供的方法可以广泛地应用于各种领域,例如可以应用于物联网中各种智能家电设备、智能汽车等与云端服务器之间的安全通信。其中连接服务器可以是云端为物联设备提供具体服务的应用服务器。
举一个例子,在智能电视中的安全芯片中预先写入为该智能电视分配的ID2,基于该ID2从标识服务器获取认证码,并基于该认证码在管理服务器处通过认证后,从管理服务器获取连接服务器的连接参数。此时的连接服务器可以为视频服务器,连接参数包括seedkey、会话标识、视频服务器的IP地址和端口号。智能电视可以进一步利用获取到的视频服务器的IP地址和端口号,与视频服务器建立CCP通道,在该CCP通道上,智能电视与视频服务器之间进行的数据交互均采用seedkey进行加密,并且采用上述连接参数中的会话标识来标识该通道上的会话。这样就保证了智能电视与视频服务器之间的安全连接。
图1所示系统中,终端设备00和服务端设备11之间在通道上进行的数据传输可以包括一些机制,下面结合实施例对于其中的事件机制和动作机制进行描述。
事件机制:
终端设备00中的第一装置获取功能模块的事件,依据事件的注册信息,向包含第二装置的服务端设备发送事件消息。服务端设备11的第二装置接收该事件消息。
其中事件的注册信息可以包括:向服务端上报的事件标识;或者,向服务端上报的事件标识以及事件标识对应的事件参数。
服务端设备11的第二装置可以对事件消息进行记录;或者,依据事件消息,向上述终端设备00或者其他终端设备发送第一消息,第一消息包括动作标识。其中,对于该终端设备00发送的第一消息,可以实现基于终端设备00上报的事件触发对终端设备00的控制。而对其他终端设备发送第一消息,可以实现基于终端设备00上报的事件触发对其他终端设备的控制,即终端设备间通过服务端(云端)的联动。
终端设备00的第一装置还可以获取功能模块的事件,依据事件的注册信息,触发事件所联动的功能模块。这里的事件的注册信息可以包括:事件标识以及事件标识所联动的功能模块和执行指令,其中执行指令用于第一装置发送给事件所联动的功能模块。这种方式可以实现一个终端设备00中功能模块之间的联动。
其中,终端设备00的第一装置可以获取开发设备发送的设备配置文件、用户配置的设备配置文件或者预置的设备配置文件;依据设备配置文件,进行事件的注册。
下面结合实施例,对该事件(Event)机制进行描述。
图5为本发明实施例提供的一种Event处理情形的流程图,如图5所示,可以执行以下步骤:
在501中,终端设备的控制中枢接收开发设备发送的设备配置文件。
终端的事件处理主要由终端设备中的控制中枢实现,控制中枢可以为终端设备中完成各功能模块的控制和协调功能的单元,
在502中,终端设备的控制中枢依据设备配置文件,在本地进行Event注册,包括注册向包含第二装置的服务端设备上报的Event信息。
上述两个步骤可以为预先的注册过程,开发者可以针对自己的智能硬件(即终端设备)定义设备配置文件(Device Profile),然后通过开发设备将Device Profile发送给终端设备和包含第二装置的服务端设备,如图6中所示。通过这种方式,终端设备的开发者就能够实现远程的Event的配置。在本实施例中,Profile中可以定义Event名称及其对应的事件参数。采用的格式可以为“Event名称:事件参数”,例如:
event1name:power_low args:10%
表示电量低于10%的事件。
在本发明实施例中,可以针对某一类终端设备提供一个通用的Device Profile,例如A智能音箱开发者和B智能音箱开发者提供的智能音箱都有播放、暂停、恢复、音量设置等功能,这两种智能音箱就可以共用这个Device Profile。对于两种智能音箱各自有特色的功能,则可以通过分别的Device Profile进行定义。这种方式可以减少智能硬件开发的重复劳动,形成累积,同时也降低了智能硬件的开发门槛,便于智能硬件开发的普及。
Device Profile可以通过一个文档来说明,更优地,可以通过树形的头文件目录形式进行组织。在该树形的头文件目录中,各节点的子节点是该节点的子功能,如图7中所示。根节点为终端设备(device),其子节点包括:电源模块(power)、音频模块(audio)、视频模块(video)……,还可以存在更多层次的子节点,在此图中不一一穷举。在电源模块、音频模块、视频模块对应的节点上分别存储电源模块、音频模块、视频模块所对应的配置信息,包括Event名称及其对应参数。如图7中所示,power上可以包括电源管理相关的配置信息(power_manage.h),audio上可以包括声音控制相关的配置信息(voice_control.h)、播放列表相关的配置信息(play_list.h)、播放控制相关的配置信息(play_control.h),vedio上可以包括亮度控制相关的配置信息(light_control.h)、图像相关的配置信息(image.h)。其中,“.h”为配置信息的格式后缀。
在终端设备端进行的Event注册可以包括:控制中枢解析Device Profile,在本地注册Device Profile所包含的事件标识,或者在本地注册Device Profile所包含的事件标识以及事件标识对应的事件参数。其中事件标识可以是Event id,或者Event名称等形式,在本发明后续实施例中,均以Event名称为例进行描述。
这些注册的Event名称为向包含第二装置的服务端设备上报的Event名称。其中,“注册”包括在本地对要注册的信息(例如Event名称、Event名称以及Event名称对应的时间参数)进行记录。
另外,在终端设备端的注册除了包含Event注册之外,还可以包含功能模块的注册,所谓功能模块指的是终端设备中具有特定功能的部分,例如电源模块、控制模块、检测模块等。开发者通过开发设备能够将功能模块注册文件发送给终端设备的控制中枢中,或者直接预置于终端设备的控制中枢,终端设备的控制中枢能够依据该功能模块注册文件进行功能模块的注册。其中功能模块注册文件可以包括各功能模块的初始化流程信息,使得终端设备在系统启动时能够自动运行各功能模块的初始化过程。另外,功能模块注册文件还可以包括各功能模块支持上报的Event名称,使得各功能模块能够将监测到的Event对应的Event名称上报给控制中枢。
在包含第二装置的服务端设备侧也存在一个注册过程,该注册过程类似地,接收开发设备发送的Device Profile,依据该Device Profile在本地注册事件信息和事件信息对应的控制指令,其中事件信息可以包括Event名称及其对应的Event参数,或者包括Event名称。这种注册可以应用于包含第二装置的服务端设备依据终端设备上报的Event实现对该同一终端设备进行控制。或者,包含第二装置的服务端设备依据Device Profile在本地注册事件信息、事件信息对应的目的设备标识和控制指令。这种注册可以应用于包含第二装置的服务端设备依据终端设备上报的Event实现对其他终端设备进行控制。关于包含第二装置的服务端设备的处理将在后续步骤中描述。
上述注册机制,除了可以在终端设备激活时执行之外,在终端设备运行过程中也可以执行,用以实现设备升级等。通过上述注册机制,开发者对终端设备的升级更加简单,例如当有新的Event注册信息时,可以将包含该新的Event注册信息的Device Profile发送给终端设备和包含第二装置的服务端设备。包含第二装置的服务端设备和终端设备通过上述的注册机制,就可以轻松实现新的Event注册。其中包含第二装置的服务端设备和终端设备的注册过程中,可以对Device Profile包含的所有Event信息均进行注册,也可以仅注册尚未注册的Event信息,对于本地已经存在的Event信息可以跳过。
需要说明的是,除了开发者通过开发设备向终端设备的控制中枢发送DeviceProfile的方式之外,也可以在控制中枢中预置Device Profile,例如在终端设备出厂时将Device Profile预置于控制中枢。还可以由用于依据自身的使用习惯或者实际使用需求,自定义地在终端设备配置Device Profile。例如通过终端设备向用户提供的接口,配置Device Profile,并由终端设备的控制中枢存储该用户配置的Device Profile。DeviceProfile的上述几种配置方式,使得无论是开发者还是终端设备的使用者,均能够根据需求灵活地对终端设备的控制方案进行配置。
在503中,终端设备的控制中枢获取功能模块上报的Event名称。
当某功能模块监测到Event后,将该Event的Event名称上报给控制中枢。
在504中,若确定功能模块上报的Event名称属于本地注册的向包含第二装置的服务端设备上报的事件标识,则控制中枢将Event名称通过Event消息发送给包含第二装置的服务端设备。
本申请实施例中,事件标识可以包括任何可以用于确定该事件的描述信息。
控制中枢在向包含第二装置的服务端设备发送Event消息时,该Event消息中可以仅携带Event名称,例如,这种方式可以适用于包含第二装置的服务端设备在注册时,注册Event名称及其对应Event参数的情况。或者Event消息中可以携带Event名称及其对应的Event参数,例如,这种情况可以适用于包含第二装置的服务端设备在注册时,并未注册Event名称对应的Event参数的情况。
后续包含第二装置的服务端设备可以基于Event消息进行各种操作,例如,包含第二装置的服务端设备可以不对Event消息进行任何确认,对接收到的Event信息进行记录。例如,包含第二装置的服务端设备还可以进行以下处理:
包含第二装置的服务端设备依据预先注册的Event名称对应的控制指令,向该终端设备发送接收到的Event名称对应的控制指令。即包含第二装置的服务端设备依据接收到的Event,对上报Event的终端设备进行控制的情况,例如控制语音录制的Event会触发对该终端设备的控制。
还有一种情况,就是包含第二装置的服务端设备在本地注册有Event名称、该Event名称对应的目的设备标识和控制指令。其中目的设备标识指向发送Event消息的终端设备或其他终端设备,对于目的设备标识指向其他终端设备的情况,用于基于一个终端设备的Event触发对另一终端设备的控制。包含第二装置的服务端设备接收到终端设备上报的Event名称后,确定在本地注册的该Event名称对应的目的设备标识和控制指令,将确定出的控制指令发送给该目的设备标识对应的终端设备。对于包含第二装置的服务端设备向终端设备下发控制指令的实现将在后续实施例中描述。
为了提高安全性,上报给包含第二装置的服务端设备的Event消息中可以携带终端设备的设备标识信息,包含第二装置的服务端设备接收到Event消息后,可以首先基于Event消息携带的设备标识信息进行身份验证,即判断是否为合法的设备标识,如果是,则对接收到的Event消息进行处理,否则可以直接丢弃。
该终端设备的设备标识可以是任意的能够唯一标识终端设备的信息,优选地,可以采用由标识分配设备统一分配给各终端设备的、唯一的物联网ID,该ID在出厂时被固化于终端设备的芯片中,不可篡改和非法获取。在包含第二装置的服务端设备处可以预先设置合法的设备标识,若终端设备的设备标识由标识分配设备统一分配,则包含第二装置的服务端设备可以预先从标识分配设备处获取合法的设备标识。
对于Event消息而言,除了包含Event名称、Event参数(可以不包含)以及设备标识信息之外,还可以包含其他内容字段,本发明对此不加以限制。
对于包含第二装置的服务端设备而言,可以被设置为对接收到的Event消息不做任何响应的返回,也可以被设置为对向终端设备返回Event响应消息。
在包含第二装置的服务端设备被设置为向终端设备返回Event响应消息的情况下,若终端设备在上报Event消息后的设定时长内未接收到Event响应消息,则可以进行Event消息的重传,并且可以对重传次数进行限制。Event响应消息中可以包含Event名称,该Event名称用于标识与Event消息之间的对应关系。
图8为本发明实施例提供的另一种Event处理情形的流程图,如图8所示,可以执行以下步骤:
在801中,终端设备的控制中枢接收开发设备发送的设备配置文件。
在802中,终端设备的控制中枢依据设备配置文件,在本地进行Event注册,包括注册Event信息所联动的功能模块和控制指令。
同样,这两个步骤可以为预先的注册过程,关于设备配置文件(Device Profile)的相关描述可以参见图5所示实施例中的相关描述,在此不再赘述。
在本实施例中的Event注册与图5所示实施例不同的是,该注册可以仅在终端设备中进行,控制中枢解析Device Profile后,在本地注册Device Profile所包含的Event名称以及Event名称所联动的功能模块和执行指令。
在803中,控制中枢获取功能模块1上报的Event名称。
当功能模块1监测到Event后,将该Event的Event名称上报给控制中枢。
在804中,控制中枢确定本地注册的功能模块1上报的Event名称所联动的功能模块2和执行指令。
若在本地注册有与该Event名称存在联动关系的功能模块,则就可以向该功能模块发送与该Event名称对应的执行指令,从而实现基于一个功能模块的Event控制另一功能模块。
在805中,控制中枢向功能模块2发送确定的执行指令。
动作(Action)机制:
服务端设备11中的第二装置向终端设备发送第一消息,该第一消息可以包括动作标识。
终端设备00中的第一装置接收该第一消息,并向包含第二装置的服务端设备11返回第二消息,该第二消息包括动作标识和动作状态,动作状态用于指示终端设备针对第一消息的动作执行状况。
服务端设备11接收终端设备返回的第二消息。
上述第一消息可以是基于终端设备00上报的事件消息触发的。即终端设备00的第一装置向包含第二装置的服务端设备11上报事件消息。服务端设备11的第二装置接收终端设备00上报的事件消息;依据预设的业务逻辑,确定接收到的事件对应的动作标识,业务逻辑包括事件与动作标识之间的对应关系;将确定的动作标识包含在第一消息中发送给终端设备00。
或者,服务端设备11的第二装置接收另一终端设备上报的事件消息;依据预设的业务逻辑,业务逻辑包括事件与动作标识、目标设备标识信息之间的对应关系,将与事件对应的动作标识包含在第一消息中发送给目标设备标识信息对应的终端设备00。
针对上述Event机制列举以下应用场景:
应用场景1:
该应用场景是终端与云端之间的Event机制。
由于开发者预先将智能音响中语音控制模块的相关Event注册到了智能硬件中的控制中枢,并且该相关Event也预先注册到了云端。其中一种Event为控制语音录制。当智能音响中语音录制模块监测到控制语音录制Event被触发时,将该Event名称上报给控制中枢。
控制中枢确定其属于预先注册的上报给云端设备的Event名称。智能音响将包含该Event名称的Event消息上报给云端设备。云端设备对于该Event本身可以不做任何确认,但可以基于该Event进行后续处理,例如对该Event所包含的控制语音进行识别,依据控制语音箱该智能音响下发相应的控制指令等。
在这种应用场景中,本发明提供的Event机制能够实现智能设备与云端设备的互联。
应用场景2:
智能门窗中的状态监测模块监测到开门的Event后,将该Event名称上报给智能门窗中的控制中枢。控制中枢确定该Event名称属于上报给云端设备的Event后,将该Event名称通过Event消息上报给云端设备。
云端设备接收到该Event消息后,通过查询预先注册的Event注册信息,确定该Event名称对应的目的设备标识和控制指令。假设确定的目的设备标识指向智能电灯,控制指令为开灯的指令,那么云端设备向智能电灯发送开灯的控制指令。这种场景能够实现,当用户开门后,智能电灯自动点亮。
在这种应用场景中,本发明提供的Event机制能够实现智能设备通过云端设备与其他智能设备的互联。
应用场景3:
该应用场景是智能设备中功能模块间的Event机制。
智能电灯中的光线检测模块监测到光线亮度低于预设阈值的Event后,将该Event名称发送给智能电灯中的控制中枢。控制中枢确定在本地注册的该Event名称存在联动的功能模块和控制指令,即该Event名称联动开关模块,对应的控制指令为开灯指令。则控制中枢向智能电灯的开关模块发送开灯指令。此时智能电灯就被打开。这种场景能够实现,当环境光线亮度低于预设阈值时,智能电灯自动点亮。
在这种应用场景中,本发明提供的Event机制能够实现智能设备内部模块之间的互联。
下面结合实施例对该Action机制进行详述。
图9为本发明实施例提供的Action机制的主要方法流程图,如图9中所示,该方法可以包括以下步骤:
在901中,包含第二装置的服务端设备向终端设备发送第一Action消息,该第一Action消息包括Action标识。
需要说明的是,第一Action消息和第二Action消息为本发明实施例中列举的第一消息和第二消息的名称,但本发明实施例并不限于这种消息名称。
包含第二装置的服务端设备向终端设备发送第一Action消息可以但不限于以下两种情况下触发:
第一种情况:包含第二装置的服务端设备受到控制设备的触发,即包含第二装置的服务端设备接收到控制设备发送的控制指令。例如,该控制设备可以是诸如智能手机、PC、笔记本电脑等任意用户可以使用的智能终端,在该控制设备上可以向用户提供针对终端设备的控制界面,通过该控制界面可以向云端发送针对特定终端设备的控制指令。
在该控制指令中包含控制设备获取到的终端设备的设备标识。该终端设备的设备标识可以是任意的能够唯一标识终端设备的信息,优选地,可以采用由标识分配设备统一分配给各终端设备的、唯一的物联网ID,该ID在出厂时被固化于终端设备的芯片中,不可篡改和非法获取。包含第二装置的服务端设备利用该控制指令中携带的目的设备标识信息,向与该目的设备标识信息对应的终端设备发送第一Action消息。
在这种情况下,可以在云端预先设置各控制指令与Action标识之间的对应关系,每一种控制指令存在与其对应的Action标识,Action标识可以预先在包含第二装置的服务端设备本地和终端设备端进行注册,若在包含第二装置的服务端设备仅注册了Action标识,在第一Action消息中仅包括Action标识,则在终端设备端可以注册Action标识以及Action标识对应的控制参数。若在包含第二装置的服务端设备注册了Action标识和Action标识对应的控制参数,则在第一Action消息中还可以包括Action标识对应的控制参数,则终端设备端就可以仅注册Action标识。也可以在包含第二装置的服务端设备和终端设备都注册Action标识以及Action标识对应的控制参数,则在第一Action消息中可以包括控制参数,也可以不包括控制参数。总的原则就是,只要终端设备能够获取到第一Action消息包含的Action标识对应的控制参数即可。在后续实施例中均以两边都注册Action标识以及Action标识对应的控制参数为例。其中Action标识可以包括任何可以用于确定该动作的描述信息,例如可以采用Action id或Action名称等形式。
具体的注册过程将在后续实施例中详述。服务端设备接收到控制设备发送的控制指令后,依据控制指令与Action标识之间的对应关系,确定出对应的Action标识,将Action标识包含在第一Action消息中下发。或者在确定出对应的Action标识后,再依据预先在本地注册的信息,将Action标识及其对应的控制参数通过第一Action消息下发给智能终端。
第二种情况:包含第二装置的服务端设备受到终端设备端的触发,即接收到终端设备上报的Event后,触发第一Action消息的下发。在一些业务逻辑中,包含第二装置的服务端设备对终端设备的控制是基于一些特定事件的,例如控制语音录制的Event会触发包含第二装置的服务端设备进行语音识别后,下发对应的控制。
在这种情况下,包含第二装置的服务端设备可以接收到一个终端设备上报的Event后,向该终端设备下发第一Action消息。
当终端设备向包含第二装置的服务端设备上报该Event时,包含第二装置的服务端设备查询与该Event相关的业务逻辑。可以预先在包含第二装置的服务端设备设置Event与Action标识之间的对应关系,在查询与该Event相关的业务逻辑时,实际上就是确定该Event对应的Action标识,然后再依据预先在本地注册的信息,将Action标识及其对应的控制参数通过第一Action消息下发给智能终端。
还存在这样的情况:包含第二装置的服务端设备接收到一个终端设备上报的Event后,向另一个终端设备下发第一Action消息。
当终端设备向服务端(云端)上报该Event时,包含第二装置的服务端设备查询与该Event相关的业务逻辑。这里的业务逻辑实际上是预置的Event与Action标识以及目的设备标识信息之间的对应关系。也就是说,通过Event一方面可以确定出对应的Action标识,另一方面可以确定出目的设备标识,然后将该Action标识包含在第一Action消息中发送给该目的设备标识对应的终端设备。
对于上述两种情况,包含第二装置的服务端设备在发送第一Action消息之前,可以首先判断该第一Action消息对应的目的终端设备的标识信息(控制指令中携带的目的设备标识信息、发送Event的终端设备的标识信息或者已注册的与Event对应的目的设备标识信息),是否为合法的设备标识,如果否,则禁止向终端设备发送第一Action消息;如果是,才允许向终端设备发送第一Action消息。
其中,在包含第二装置的服务端设备处可以预先设置合法的设备标识,若终端设备的设备标识由标识分配设备统一分配,则包含第二装置的服务端设备可以预先从标识分配设备处获取合法的设备标识。
当然除了上述两种情况的触发之外,还可以存在其他触发方式,例如包含第二装置的服务端设备定期的Action下发,在此不再一一列举。
对于第一Action消息而言,除了包括Action标识、控制参数、终端设备的标识信息之外,还可以包含其他内容字段,本发明对此不加以限制。
在902中,包含第二装置的服务端设备接收终端设备返回的第二Action消息,该第二Action消息包括上述Action标识和Action状态。
其中,第二Action消息中的Action标识与第一Action消息中的Action标识一致,用以指示该第二Action消息与第一Action消息之间的关联。Action状态用于指示终端设备针对第一Action消息的动作执行状况,鉴于动作执行的不同阶段,Action状态可以包括但不限于:
第一状态:指示接收到第一Action消息。
第二状态:指示依据第一Action消息中的Action标识所对应的控制参数执行动作的准备工作已完成。
第三状态:指示依据第一Action消息中的Action标识所对应的控制参数执行动作已完毕。
第四状态:指示依据第一Action消息中的Action标识所对应的控制参数执行动作出现异常。
针对这几种状态的第二Action消息的发送情况,将在后续实施例中进行详细描述。
在上面图9所示的实施例中已经提及关于Action注册的机制,下面通过具体实施例对Action注册的机制进行详细描述。本发明实施例中涉及的Action可以理解为包含第二装置的服务端设备下发给终端设备的控制信息,其对应的是终端设备提供的各种功能,包含第二装置的服务端设备下发的Action可以对应一个动作,也可以对应一个动作序列。Action消息可以理解为针对Action在包含第二装置的服务端设备和终端设备之间交互的消息。
为了区分不同的动作,在本发明实施例中,可以采用Action标识来标识和区分各Action。Action标识与具体的控制参数对应,其中控制参数可以包括动作类型,例如播放、暂停等。诸如暂停等一些Action仅需要动作类型即可,但还有一些诸如播放、调高音量等Action需要一些其他的参数,例如播放对象、调高音量的幅度。这些Action标识及其对应的控制参数可以通过设备配置文件(Device Profile)进行定义。Device Profile中可以采用这样的格式:“Action标识:控制参数”,其中多个控制参数可以采用逗号隔开,例如:
action1name:play,args:“小苹果”
action2name:pause
其中,action1name对应的动作是播放小苹果;action2name对应的动作是暂停。
另外,Device Profile除了可以定义Action标识及其对应的控制参数之外,还可以定义Event标识及其对应的事件参数。采用的格式可以为“Event标识:事件参数”,例如:
event1name:power_low args:10%
表示电量低于10%的事件。
开发者可以针对自己的智能硬件(即终端设备)定义Device Profile,然后通过开发设备将Device Profile发送给包含第二装置的服务端设备和终端设备,如图6所示。通过这种方式,终端设备的开发者就能够实现远程的Action和Event的配置。关于DeviceProfile参见Event机制中的相关描述,在此不再赘述。
在服务端(云端)的注册过程主要是:解析某类型终端设备的Device Profile,针对该类型终端设备在本地注册Device Profile所包含的各Action标识以及Action标识对应的控制参数、Event标识以及Event标识对应的事件参数。这样包含第二装置的服务端设备就能够进行Action消息的下发和Event消息的接收、处理。
在终端设备端的注册过程主要是:终端设备的控制中枢解析Device Profile,在本地注册Device Profile所包含的各Action标识以及Action标识对应的控制参数、Event标识以及Event标识对应的事件参数。这样,终端设备就能够针对Action消息进行接收、处理和发送,以及对Event消息进行发送和处理。
另外,与包含第二装置的服务端设备的注册不太一样的是,在终端设备端的注册除了包含Action注册和Event注册之外,还可以包含功能模块的注册,所谓功能模块指的是终端设备中具有特定功能的部分,例如电源模块、控制模块、检测模块等。开发者通过开发设备能够将功能模块注册文件发送给终端设备的控制中枢中,或者直接预置于终端设备的控制中枢,终端设备的控制中枢能够依据该功能模块注册文件进行功能模块的注册。其中功能模块注册文件可以包括各功能模块的初始化流程信息,使得终端设备在系统启动时能够自动运行各功能模块的初始化过程。另外,功能模块注册文件还可以包括各功能模块支持的Action标识,使得控制中枢接收到第一Action指令后,能够依据其中的Action标识确定执行动作的功能模块,并将该Action标识对应的控制参数提供给相应的功能模块以执行动作。
通过上述注册机制,开发者对终端设备的升级更加简单,例如当有新的Action标识时,可以将包含该新的Action标识及对应控制参数的Device Profile发送给包含第二装置的服务端设备和终端设备,包含第二装置的服务端设备和终端设备通过上述的注册机制,就能够轻松实现新的Action的升级。其中包含第二装置的服务端设备和终端设备在注册过程中,可以对Device Profile包含的所有Action标识均进行注册,也可以仅注册尚未注册的Action标识,对于本地已经存在的Action标识可以跳过。
在上面图9所示的实施例中以及提及关于第二Action消息的几种情况,下面结合一个具体实施例对包含第二装置的服务端设备和终端设备之间的Action消息交互进行详细描述。图10为本发明实施例提供的包含第二装置的服务端设备与终端设备之间的Action消息交互流程图,如图10中所示,该流程可以具体包括以下步骤:
在1001中,包含第二装置的服务端设备向终端设备发送包含Action标识和控制参数的第一Action消息,图中以动作(Action)消息进行表示。
在该第一Action消息(对应于图9所示实施例中的第一Action消息)中,通过Action标识进行唯一标识。
在1002中,终端设备接收到第一Action消息后,向包含第二装置的服务端设备返回包括上述Action标识和第一状态信息的第二Action消息,图中以动作_已接收(Action_received)消息表示。
本步骤中的第二Action消息通过Action标识和第一状态信息进行唯一标识,其中第一状态指示接收到第一Action消息。
在1003中,终端设备在依据第一Action消息中的控制参数完成执行动作的准备工作候,向包含第二装置的服务端设备返回包括上述Action标识和第二状态信息的第二Action消息,图中以动作_执行中(Action_doing)表示。
本步骤中的第二Action消息通过Action标识和第二状态信息进行唯一标识,其中第二状态指示依据第一Action消息中的控制参数执行动作的准备工作已完成。
在1004中,终端设备在依据控制参数执行动作完毕后,向包含第二装置的服务端设备返回包括上述Action标识和第三状态信息的第二Action消息,图中以动作_已完成(Action_done)消息表示。
本步骤中的第二Action消息通过Action标识和第三状态信息进行唯一标识,其中第三状态指示依据第一Action消息中的控制参数执行动作完毕。
在1005中,终端设备在依据控制参数执行动作发生异常时,向包含第二装置的服务端设备返回包括上述Action标识和第四状态信息的第二Action消息,图中以动作_异常(Action_exception)消息表示。
本步骤中的第二Action消息通过Action标识和第四状态信息进行唯一标识,其中第四状态指示依据第一Action消息中的控制参数执行动作出现异常。需要说明的是,步骤1005并不一定出现于步骤1004之后,其可能产生于步骤1002之后的任何时间中,只要发生异常,就可能会执行。
对于包含第二装置的服务端设备而言,若在发送Action的设定时长内未接收到Action_received,则重发Action。若在接收到Action_received的设定时长内未接收到Action_doing,则重发Action。若在接收到Action_doing的设定时长内未接收到Action_done,则重发Action。若接收到Action_exception,则重发Action。另外,也可以设置Action的重发次数上限,达到该重发次数上限后,不再重发Action。
另外,对于包含第二装置的服务端设备接收到的各种Action状态,可以返回给发送控制指令的控制设备。
针对上述Action机制,列举以下几种应用场景:
应用场景1:
用户手机通过云端向智能音响发送播放“小苹果”音频的控制指令。在云端设备预先存储有action标识与控制指令之间的对应关系。云端设备接收到用户手机发送来的播放“小苹果”音频的控制指令后,依据上述对应关系,确定该指令对应的action标识,例如该action标识为:
action name1:play,args:“小苹果”。
其中action name1为action标识,play和args:“小苹果”为控制参数。
然后,云端设备依据该控制指令中包含的ID2(一种由标识分配设备统一分配的、唯一标识智能设备的物联网ID)确定目的终端设备,即智能音响,向智能音响发送第一Action消息。该第一Action消息中可以包含以下字段:action标识和控制参数。
智能音响接收到第一Action消息后,向云端设备返回包含状态为action_received的第二Action消息。该第二Action消息中可以包含以下字段:action name1以及本次action状态(即action_received),这两个字段可以唯一标识智能音响本次返回的消息。
如果云端设备在设定时长内未接收到智能音响返回的包含状态为action_received的第二Action消息,则可以重新发送第一Action消息。
智能音响向云端设备返回包含状态为action_received的第二Action消息后,开始依据第一Action消息中的控制参数进行动作执行的准备工作。待准备工作完成后,向云端返回包含状态为action_doing的第二Action消息。该包含状态为action_doing的第二Action消息中可以包含以下字段:action name1以及本次action状态(即action_doing),这两个字段可以唯一标识智能音响本次返回的消息。
智能音响执行播放“小苹果”音频的动作后,向云端设备返回包含状态为action_done的第二Action消息。该包含状态为action_done的第二Action消息中可以包含以下字段:action name1以及本次action状态(即action_done),这两个字段可以唯一标识智能音响本次返回的指令。
智能音响若在动作执行过程中出现异常,则可以向云端返回包含状态为action_exception的第二Action消息。该包含状态为action_exception的第二Action消息中可以包含以下字段:action name1和本次action状态(即action_exception),这两个字段可以唯一标识智能音响本次返回的指令。另外该包含状态为action_exception的第二Action消息还可以包括指示具体异常类型的参数字段。
云端设备可以依据智能音响返回的action状态,获知智能音响对Action的动作执行状态,从而确保了云端设备下发的控制在智能硬件设备上执行的各个状态都在监控中,保证了动作执行的完整性和追查性。另外,云端设备还可以将智能音响返回的action状态返回给发送控制指令的智能手机,以便用户能够及时获知动作的执行状态。
应用场景2:
该应用场景是智能设备与云端设备之间的Event机制。
由于开发者预先将智能音响中语音控制模块的相关Event注册到了智能硬件中的IDJS CORE(控制中枢),并且该相关Event也预先注册到了云端设备。其中一种Event为控制语音录制。当智能音响的控制语音录制Event被触发时,智能音响将该Event发送给云端。云端对于该Event本身可以不做任何确认,但可以基于该Event进行后续处理,例如对该Event所包含的控制语音进行识别,依据控制语音确定相应的Action标识和控制参数,并携带在第一Action消息中下发。
应用场景3:
智能门窗检测到开门的Event后,将该Event上报给云端设备。云端设备确定该Event对应的Action标识、控制参数和目的终端设备。例如,确定的Action标识为:Actionname2,控制参数为:light,目的终端设备为智能电灯。则云端设备通过第一Action消息将Action name2及其对应的控制参数发送给智能电灯,智能电灯接收到该第一Action消息后,可以依据其中的Action name2及其对应的控制参数,进行智能电灯的点亮。并可以返回不同状态的第二Action消息。
终端设备00的第一装置可以连接传感器,即终端设备可以具备数据采集功能,例如采集声音、图像等多媒体数据,采集温度、湿度等环境参数,采集加速度、速度等运动参数,等等。终端设备00的第一装置将传感器采集的数据通过通道传输给包含第二装置的服务端设备11。传感器接入第一装置就意味着传感器的数据被透传到服务端(云端),因此可以将该传感器称为云传感器。该云传感器有两方面的接口,一方面为接入设备芯片的硬件接口,另一方面为接入上述软件部分的驱动程序接口。
对于终端设备00的传感器而言,其可以为可插拔式传感器。传感器的可插拔能力,一方面需要传感器硬件接口和驱动程序接口的标准化,另一方面是驱动程序能够从服务端动态加载。下面对驱动程序动态加载的部分进行描述。
终端设备00的第一装置负责被激活时或者检测到新连接的传感器时,可以将包含设备标识的驱动请求发送给包含第五装置的服务端设备14。依据包含第五装置的服务端设备返回的传感器信息,从包含第五装置的服务端设备下载对应的驱动程序。
服务端设备14的第五装置,负责接收到驱动请求后,依据设备标识确定第一装置预先注册的传感器信息,并返回给第一装置。
或者,终端设备00的第一装置负责被激活或检测到新连接的传感器时,向包含第五装置的服务端设备14发送驱动请求;依据包含第五装置的服务端设备14返回的传感器信息,从包含第五装置的服务端设备14下载对应的驱动程序。
服务端设备14的第五装置,负责接收到驱动请求后,检测终端设备00连接的传感器信息,并返回给第一装置。
也就是说,传感器驱动程序的动态加载可以有两种方式,一种是第一装置预先在服务端注册其传感器信息的方式,另一种是由服务端检测终端设备新连接的传感器信息。下面通过实施例对这两种方式进行详述。
图11为本发明实施例提供的一种驱动程序动态加载的流程图,在本实施例中终端设备的设备标识采用ID2表示,如图11所示,该过程可以包括以下步骤:
在1101中,终端设备被激活时,将包含ID2的驱动请求发送给包含第五装置的服务端设备。
另外,除了终端设备初次被激活时,发送驱动请求之外,若终端设备检测到新连接的传感器时,例如终端设备更换传感器或者新增加传感器等,会新连接传感器,此时终端设备的第一装置可以具备自动检测功能,检测到新连接到传感器,此时也可以向包含第五装置的服务端设备发送包含ID2的驱动请求。
在1102中,包含第五装置的服务端设备接收到驱动请求后,依据其中的ID2确定终端设备预先注册的传感器信息,并返回给终端设备。
在本实施例中,终端设备中的设备芯片在出厂之前,可以预先在服务端注册其所采用传感器的信息,例如型号信息等,然后通过该设备芯片的ID2与该传感器信息进行关联存储。当包含第五装置的服务端设备接收到包含ID2的驱动请求后,就能够根据ID2确定出与其相关联的传感器型号等传感器信息。
在1103中,终端设备依据传感器信息,从包含第五装置的服务端设备下载对应的驱动程序。
在本步骤中,可以由包含第五装置的服务端设备确定出对应的传感器信息后,直接向终端设备推送该传感器信息对应的驱动程序,由终端设备下载并加载到操作系统,从而驱动传感器正常工作。也可以由第五装置的服务端设备返回对应的传感器信息后,由终端设备依据传感器信息向包含第五装置的服务端设备发送下载请求,并由包含第五装置的服务端设备依据下载请求发送对应的驱动程序给终端设备,由终端设备下载并加载到操作系统,从而驱动传感器正常工作。
图12为本发明实施例提供的一种驱动程序动态加载的流程图,在本实施例中终端设备的设备标识采用ID2表示,如图12所示,该过程可以包括以下步骤:
在1201中,终端设备检测到新连接的传感器时,向包含第五装置的服务端设备发送驱动请求。
在本实施例中,若终端设备初次被激活时,也可以向包含第五装置的服务端设备发送驱动请求。
在1202中,包含第五装置的服务端设备接收到驱动请求后,检测终端设备新连接的传感器信息。
目前已经存在较成熟的传感器信息检测技术,本发明直接使用即可,并不对具体的检测方式进行限制。通过这种检测技术,包含第五装置的服务端设备能够获取到终端设备连接的传感器型号等传感器信息。
在1203中,包含第五装置的服务端设备将检测到的传感器信息返回给终端设备。
在1204中,终端设备依据接收到的传感器信息,从包含第五装置的服务端设备下载对应的驱动程序。
同样,在本步骤中,可以由包含第五装置的服务端设备检测出对应的传感器信息后,直接向终端设备推送该传感器信息对应的驱动程序,由终端设备下载并加载到操作系统,从而驱动传感器正常工作。也可以由第五装置的服务端设备返回对应的传感器信息后,由终端设备依据传感器信息向包含第五装置的服务端设备发送下载请求,并由包含第五装置的服务端设备依据下载请求发送对应的驱动程序给终端设备,由终端设备下载并加载到操作系统,从而驱动传感器正常工作。
通常网络中会存在数量很多的终端设备,甚至在同一个局域网中也会存在多个终端设备。在本发明实施例中,终端设备可以具备两种身份:Node(运行节点)和Gateway(网关)。
Gateway具备直接接入服务端的能力,即Gateway已与包含第二装置的服务端设备建立通道。Node可以通过网关与包含第二装置的服务端设备11连接通道。
通常对于同一个组的终端设备,可以存在一个Gateway,其他均为Node。其中“组”可以按照接入设备的覆盖区域划分,也可以按照局域网划分,还可以采用其他划分方式。其中Gateway可以由用户或云端指定,也可以由同一个组中的多个运行节点协商得到,具体协商方式本发明并不加以限制。
上面已经提到,Node可以通过Gateway与包含第二装置的服务端设备建立通道,下面结合实施例对通道的建立过程进行描述。
图13为本发明实施例提供的一种Node与服务端建立通道的流程图,在该实施例中,Node的设备标识用ID2表示。如图13所示,该过程可以包括:
在1301中,Node利用自身的ID2对应的私钥,对发送给包含第二装置的服务端设备的数据进行加密,将加密后的数据发送给Gateway。
其中连同加密后的数据一起发送的还有Node的ID2。
在1302中,Gateway将接收到的数据转发给包含第二装置的服务端设备。
在1303中,包含第二装置的服务端设备接收到该数据后,利用Node的ID2对应的公钥进行解密。
由于第二装置的服务端设备预先保存有ID2对应的公钥,因此可以利用该公钥对接收到的数据进行解密,并将解密后的数据保存到数据平台,这样就建立了Node与包含第二装置的服务端设备之间的通道,该通道需要经由Gateway进行数据转发。对于包含第二装置的服务端设备发送给Node的数据,会采用ID2对应的公钥进行加密,然后经由Gateway透传至Node,Node再利用ID2对应的私钥进行解密。
上述过程可以适用于诸如蓝牙等连接方式,其中Node和Gateway的处理由各自的第一装置完成。
图14为本发明实施例提供的另一种Node与服务端建立通道的流程图,在该实施例中,Node的设备标识用ID2表示。如图14所示,该过程可以包括:
在1401中,Node在广播帧中携带自身的ID2。
在1402中,Gateway从接收到的广播帧中获取ID2。
由于空中存在很多广播帧,Gateway不可能对任意广播帧都进行处理,在本发明实施例中,可以配置Gateway仅对本组的Node的广播帧进行处理,也就是收,仅允许本组的Node通过Gateway接入网络。
在1403中,Gateway将该ID2发送给包含第六装置的服务端设备。
在1404中,包含第六装置的服务端设备对接收到的ID2进行认证。
本步骤中,包含第六装置的服务端设备在进行认证时,可以将ID2提供给包含第三装置的服务端设备,由包含第三装置的服务端设备对该认证码进行认证(例如判断是否为合法终端设备的ID2)后,返回认证结果给包含第六装置的服务端设备。
在1405中,如果认证通过,则包含第六装置的服务端设备将该ID2对应的公钥返回给Gateway。
在本步骤中,包含第六装置的服务端设备预先配置有各ID2对应的公钥,也可以从包含第三装置的服务端设备获取该ID2对应的公钥。
在1406中,Gateway利用接收到的公钥对网络接入参数进行加密,将加密后的网络接入参数发送给Node。
由于Gateway已具备接入网络的能力,即获取到网络接入参数,在本步骤中,Gateway就将此“能力”通过加密的方式提供给Node。
在1407中,Node利用ID2对应的私钥对网络接入参数进行解密。
在1408中,Node利用解密得到的网路接入参数接入网络。
上述流程可以应用于诸如wifi等网络连接方式,此时上述广播帧可以为wifibeacon帧,网络接入参数可以包括:ssid(服务集标识)和密码,在1408中,Node利用ssid和密码就能够接入gateway已接入的AP。然后就可以进一步采用图3所示实施例提供的方式建立Node与包含第二装置的服务端设备之间的通道。
通过上述流程,可以实现诸如如下场景:
若用户在家中的局域网中,以使用手机接入AP并与云端设备建立通道,那么可以将该手机作为Gateway,该局域网中的智能音箱作为Node。智能音箱广播wifi beacon帧携带自身ID2,Gateway将该ID2提供给云端进行认证,在认证通过后,返回该ID2对应的公钥。手机利用该公钥对所接入AP的ssid和密码进行加密后返回给智能音箱。智能音箱利用ID2对应的私钥进行解密后,利用获取的ssid和密码接入AP。通过这种方式,无需手工对智能音箱进行ssid和密码的配置,通过已接入AP的手机能够实现智能音箱自动接入AP。
在上述Action机制中已经提到,服务端设备11中存在业务逻辑,并可依据业务逻辑实现终端设备之间的数据流转,或者基于事件对终端设备的控制。在本发明实施例中,该业务逻辑还可以缓存于Gateway中。此时,Gateway的第一装置,接收到node上报的事件消息后,若网络畅通,则转发给包含第二装置的服务端设备11;否则,可以利用在Gateway缓存的业务逻辑,向Node或其他Node发送第一消息,具体向哪个Node发送第一消息以及携带怎样的控制参数,由业务逻辑的内容决定。
其中,Gateway缓存的业务逻辑可以由包含第二装置的服务端设备11下发给Gateway,也可以由开发设备发送给Gateway,还可以由用户配置于Gateway。
图1中所示的终端设备00的第一装置可以体现为一个设备芯片,在该设备芯片的安全存储中写入了通过图2所示流程分配的设备标识,该设备标识唯一标识终端设备00的合法身份,并且该设备芯片的安全存储中也写入了该设备标识对应的私钥。该设备芯片可以包括硬件部分和软件部分。
上述实施例中的终端设备00(互联网设备)的一个例子,可以如图15A所示的逻辑结构,硬件部分可以包括处理器、通信单元和存储器,其中处理器可以是一个或多个,图15A中以一个为例,可以采用诸如MCU(微控制单元)等,通信单元可以采用诸如RF(射频单元),另外,终端设备00的硬件部分还可以包括传感器。对于软件部分而言,主要包括运行于处理器的操作系统和一个或多个程序。其中上述一个或多个程序存储在存储器中,被处理器执行以实现上述实施例中第一装置所执行的操作。上述实施例中的终端设备00(互联网设备)的一个例子,还可以如图15B所示的逻辑结构,包括物联网操作系统、系统硬件适配层HAL、传感器设备,射频单元RF、微控制单元MCU和AP,其中,ID2作为该互联网设备的设备标识被存储在安全芯片上。
另外,上述实施例中,各服务端设备可以是单独存储在的服务器,也可以是任意若干个被设置于一个服务器,也可以是一个服务端设备由多个服务器构成。对于软件程序而言,上述第二装置、第三装置、第四装置、第五装置和第六装置可以统一被整合为服务端(云端)的数据与服务平台,有该数据与服务平台实现与终端设备的通道建立、数据交互、服务提供以及终端设备之间的数据流转。终端设备的功能通过Device Profile进行定义,并开放给数据与服务平台,并通过数据与服务平台的业务逻辑实现对终端设备的控制以及在终端设备间的数据流转。
通过本发明实施例提供的系统,能够通过云端的数据与服务平台实现对各物联终端设备的控制以及各物联终端设备设备之间的数据流转,如图16A中所示的物联网系统。开发者或用户可以需求或使用习惯,在云端的数据与服务平台进行业务逻辑的定制,甚至云端的数据与服务平台可以采用自学习机制,根据用户的使用习惯,自动学习得到业务逻辑。如图16A所示,该的物联网系统包括数据与服务平台(或称为云端设备),以及各种智能硬件设备,例如,智能手机、智能手表、智能汽车(或称为互联网汽车)、平板设备、智能电视等智能硬件设备。
图16B示出了物联网系统的又一逻辑图,各互联网设备可以通过本申请实施例描述的上述通道安全地接入数据与服务平台,并通过数据与服务平台,和其他互联网设备互联。当然,基于本申请上述实施例所描述的方案,互联网设备之间也可以直接进行通信。
图16A和图16B中,数据与服务平台可以具备实现上述实施例中包含第二装置的服务端设备11、包含第三装置的服务端设备12、包含第四装置的服务端设备13、包含第五装置的服务端设备14和包含第六装置的服务端设备15中的部分或全部功能的能力。智能硬件设备(或称为互联网设备)可以具备实现上述实施例中包含第一装置的智能设备的部分或全部功能的能力。
万物互联的基础是所有的设备联网并且具有唯一的身份,根据本申请实施例,通过为各智能设备分配唯一的设备标识ID2(Internet Device ID),并将ID2固化在芯片中,不可篡改、不可预测、全球唯一,以此来解决可信感知的问题。设备与设备之间通过本申请实施例提供的安全通信方式进行发现和连接,形成自主网、自协作的可靠网络,并通过大数据服务平台进行服务的高效流转。
在本发明所提供的几个实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能单元的形式实现。
上述以软件功能单元的形式实现的集成的单元,可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明保护的范围之内。