发明内容
有鉴于此,本申请实施例提供一种设备侧智能网关系统、嵌入式设备适配控制方法、设备侧智能网关以及计算机可读存储介质。
第一方面,本申请实施例提供一种设备侧智能网关系统,包括:业务对接层和支持层,所述业务对接层用于对接业务插件,所述支持层包括多个基础插件,并且向所述业务对接层提供有用于访问所述基础插件的访问接口;
所述多个基础插件包括:驱动管理插件、通信插件、系统功能管理插件、数据库管理插件、三方库管理插件以及远程升级插件;
所述设备侧智能网关系统用于通过协作站机制和业务层协作机制管理所述业务插件以及所述多个基础插件之间的协同运作。
在一些实施例中,所述驱动管理插件用于对挂载到所述设备侧智能网关系统的硬件设备进行驱动管理;所述驱动管理插件包括三层级结构,分别为:驱动管理层、单一类别管理层和设备信道驱动对接层;
所述驱动管理层用于控制所述单一类别管理层的驱动数据的输入输出、以及对目标驱动数据请求的应答;
所述单一类别管理层中包括多个类别驱动管理器,每个所述类别驱动管理器用于根据配置文件选取所属驱动类别的相应设备信道驱动对接层以进行设备挂载;
所述设备信道驱动对接层提供设备注册功能,用于对接所述硬件设备。
在一些实施例中,所述通信插件用于根据配置文件中的通信通道策略进行通信通道装配,所述通信插件包括二层级结构,分别为:路径管理层和数据传输管理层;
所述路径管理层用于根据对接的通信彼端确定数据传输通道,所述数据传输通道包括数据目的地和所述通信彼端的数据解析格式;
所述数据传输管理层中包括传输数据封装控制器和数据传输控制器,所述传输数据封装控制器用于基于所述数据解析格式对传输数据进行格式封装,所述数据传输控制器用于选取匹配所述通信彼端的传输协议,以用于将封装后的数据传输至所述数据目的地。
在一些实施例中,设备侧智能网关系统还包括:人机交互接口插件,所述人机交互接口插件作为子插件挂载于所述支持层中的所述通信插件中,并根据所述配置文件确定是否启用,以实现本地网卡中的进程间通信;其中,所述人机交互接口插件仅包括所述传输数据封装控制器和TCP传输控制器。
在一些实施例中,所述数据库管理插件用于进行数据库管理;所述数据库管理插件包括三层级结构,分别为:数据库管理层、数据库挂载决策层和数据库对接层;
所述数据库管理层用于根据需求控制对数据库的数据操作,并提供对数据库类型的指定配置;其中,所述数据操作包括增加、删除、修改和查找中的一种或多种组合,所述数据库的类型至少包括自定义数据库、内存数据库和关系型数据库;
所述数据挂载决策层用于根据所述指定配置将相应数据对接到指定类型的数据库,并对接所述数据库管理层与所述数据库对接层两者的所述数据操作;
所述数据库对接层中包括若干类型的数据库,所述数据库对接层用于基于数据的驱动封装或自定义封装对目标数据库进行所述数据操作。
在一些实施例中,所述协作站机制用于根据配置文件将指定的业务相关数据或业务无关数据广播到每个所述基础插件和所述业务插件,以使对应插件根据自身需求获取所述业务相关数据或业务无关数据并进行相应操作;
所述业务层协作机制用于在所述业务对接层中实现不同所述业务插件之间的业务交互。
在一些实施例中,所述设备侧智能网关系统还支持扩展功能配置,所述扩展功能配置的封装包括三层级结构,分别为:配置文件读写控制层、动态递归抓取层和数据定向外送控制层;
所述配置文件读写控制层用于从JSON配置文件中读取数据到万用图数据结构中;所述动态递归抓取层用于从所述万用图数据结构中以递归方式进行配置数据抓取;所述数据定向外送控制层用于对抓取的配置数据进行数据格式简化及转换,然后发送到相应插件。
第二方面,本申请实施例还提供一种嵌入式设备适配控制方法,包括:
将按照预设格式封装的目标设备对接层注册到上述的设备侧智能网关系统的所述驱动管理插件中,并由所述驱动管理插件为所述目标设备分配唯一的设备ID;
在所述目标设备进行数据上报期间,利用所述协作站机制将带有所述设备ID的上报数据广播到系统内的所有插件,以使所述业务对接层中的业务插件或相应基础插件根据所述设备ID获得所述目标设备的所述上报数据。
第三方面,本申请实施例还提供一种设备侧智能网关,所述设备侧智能网关包括处理器和存储器,所述存储器存储有计算机程序,所述处理器用于执行所述计算机程序以实施上述的设备侧智能网关系统的功能。
第四方面,本申请实施例还提供一种可读存储介质,其存储有计算机程序,所述计算机程序在处理器上执行时,实施上述的设备侧智能网关系统的功能。
本申请的实施例具有如下有益效果:
本申请实施例的设备侧智能网关系统通过从逻辑封装层面划分为业务对接层和支持层,其中,业务对接层用于对接业务插件,而支持层中包括多个基础插件,每个基础插件具有各自的作用,这些基础插件作为实现该智能网关系统具有通用性的基础支撑;同时支持层向对业务对接层提供有用于访问诸多基础插件的访问接口,并且,设备侧智能网关系统通过协作站机制和业务层协作机制管理业务插件以及多个基础插件之间的协同运作。该智能网关系统可以跨越多种硬件平台,实现对不同多个设备的集群管理,以及满足对多种业务的管理、方便业务动态更换等。
具体实施方式
下面将结合本申请实施例中附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。
通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此,以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围,而是仅仅表示本申请的选定实施例。基于本申请的实施例,本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本申请保护的范围。
在下文中,可在本申请的各种实施例中使用的术语“包括”、“具有”及其同源词仅意在表示特定特征、数字、步骤、操作、元件、组件或前述项的组合,并且不应被理解为首先排除一个或更多个其它特征、数字、步骤、操作、元件、组件或前述项的组合的存在或增加一个或更多个特征、数字、步骤、操作、元件、组件或前述项的组合的可能性。此外,术语“第一”、“第二”、“第三”等仅用于区分描述,而不能理解为指示或暗示相对重要性。
除非另有限定,否则这里使用的所有术语(包括技术术语和科学术语)具有与本申请的各种实施例所属领域普通技术人员通常理解的含义相同的含义。所述术语(诸如在一般使用的词典中限定的术语)将被解释为具有与在相关技术领域中的语境含义相同的含义并且将不被解释为具有理想化的含义或过于正式的含义,除非在本申请的各种实施例中被清楚地限定。
下面结合附图,对本申请的一些实施方式作详细说明。在不冲突的情况下,下述的实施例及实施例中的特征可以相互结合。
现有的如车载设备、智能家电等小型设备往往与硬件厂商的嵌入式系统存在较深的耦合,导致较难实现与其他平台、外设的对接,不易于远程维护等,对此,本申请设计了一种用于设备侧的通用型智能网关系统,可以跨越硬件平台,对接任意通信协议类型的外设、服务器平台,还可以套接任意业务,可支持模块的配置型开发,可支持对附着设备的远程遥控、远程升级、远程调试等。值得注意的是,本申请的设备侧智能网关通过对不同硬件设备的挂载,可以方便对这些硬件设备实现集群化管理,而对这些硬件设备的依赖仅为可运行嵌入式系统即可。可以理解,目前市场中大部分小体量设备能够支持嵌入式系统的运行,其中,这些设备裹挟的嵌入式系统主要为ARM内核的linux系统等,这是由于低版本的linux系统性能需求低,源码可选择的余地大,BSP(Board Support Package,板级支持包)开发工作量小等。基于此,本申请的设备侧智能网关系统的设计可以实现目前大部分主流的嵌入式设备的适配,具有广泛的运用场景。下面结合具体的实施例来说明本申请的设备侧智能网关系统的设计方式。
请参照图1,示范性地,该设备侧智能网关系统从逻辑封装层面划分为两大层,分别是业务对接层和支持层,其中,业务对接层用于对接业务插件,而支持层中包括多个基础插件,每个基础插件具有各自的作用,这些基础插件作为实现该智能网关系统具有通用性的基础支撑。同时,支持层还向对业务对接层提供有用于访问诸多基础插件的访问接口(即API),如可包括辅助业务对接层访问系统的驱动接口、管理文件系统资源的接口、数据库服务接口、OTA(远程升级)服务接口、系统管理服务(如时间获取,配置数据获取,log管理,网络状态监控等)接口,以及传输层通信服务接口等。通过结构分层的设计并且支持层只对业务对接层暴露API接口,不仅可以有效的明确分工的界限,可以大大降低业务层编程人员的工作量和工作难度,进而提升迭代产品时对需求变更的贴合速度等。
可以理解,本实施例的设备侧智能网关系统主要采用插件化开发,例如,对于上述的业务对接层,整个业务对接层可以被认为是一个大插件,而其中对接的各个业务逻辑同样以插件的形式进行设置,这样可以提升整个系统软件的可维护性、业务独立性、对接外设的可扩展性等。
本实施例中,该设备侧智能网关系统中还提出了协作站机制和业务层协作机制的概念,这两种机制用于管理业务插件以及上述多个基础插件之间的协同运作,以保证该设备侧智能网关的通用性。
在一种实施方式中,协作站用于组织业务对接层与智能网关的咬合、以及支持层中各个基础插件之间的业务无关协作;业务层协作机制用于在业务对接层中实现不同业务插件之间的业务交互。
例如,在网关系统进行初始化期间,由协作站将系统配置文件(业务无关数据)通过广播形式向外发送,使得所有插件都能接收到该系统配置文件并进行存储,进而相应插件可以根据自身配置需求依据配置文件进行相应配置操作。又例如,在智能网关挂载有硬件设备的情况下,当驱动插件将硬件设备上报的数据进行如消噪、转化为系统可识别等处理后,同样由协作站将该处理后的业务相关数据进行广播,使得系统中的相应插件可根据实际需求进行数据接收以及进行相应操作等,例如,数据库管理插件可以接收并存储作为硬件设备的上报数据;或者,通信插件可以接收到数据后,进一步发送到对接的预设平台等。对于业务层协作机制,其主要在业务对接层中进行协同交互。例如,若业务插件A与业务插件B存在业务交互,由业务层协作机制将管理业务插件A从支持层中获取相应的数据,并在业务对接层中将获取的数据发送给业务插件B等。
可以理解,通过协作站机制和业务层协作机制可以实现系统中不同层的各个插件的协同运作,加上两种机制的职责明确,使得系统中各个插件之间能够有序协作,同时在开发过程中还能够提高排错效率等。
下面对上述提及的插件化开发及相关插件的结构设计进行说明。
在一种实施方式中,为满足网关对多种业务的通用性,本实施例中的每个业务可采用插件形式对接到业务对接层中,这样在更换业务时,只需在业务对接层,以规定代码封装标准对接或者扩展业务即可。示范性地,该可扩展的业务插件通过划分为二层级结构进行业务对接,如图2所示,包括:业务管理层(对应于图2中的业务管理器BusinessManager)、业务服务对接层,其中,业务服务对接层包括服务工厂(对应于图2中的ServiceHandler)和业务编解码处理器(对应于图2中的EncodeHandler)。具体地,业务管理层主要负责协调服务工厂和业务编/解码处理器的数据处理接力,以及对接与其他插件的数据往来,此外,还可负责管理接收到的配置数据等,即实现业务统筹管理。而服务工厂则可以根据业务管理层下放的业务数据中的身份信息,调取对应的服务逻辑对数据进行处理(例如,当对接一辆农用车辆设备时,可根据经度、纬度、高度及速度等信息,获得其当前的作业状态等);业务编解码处理器由业务管理层协调,获取经服务工厂下管理的具体业务逻辑处理过的数据,然后按其携带的数据身份信息,对数据进行编解码,待完成编解码后,将数据返还给业务管理层。之后,经由业务管理层发送至其他插件。其中,服务工厂中可包括多个不同的服务,如图2中的深度任务服务、全球导航服务等;而编解码处理器中同样可包括多个对象,如图2中的正常字节对象、数据格式对象等。
可以理解的是,改变解码逻辑会预制多套,根据数据的身份信息调取对应的编解码逻辑,当对驱动模块呈递数据时,往往会将数据编码为特定字符串,当对通信插件呈递数据时候,往往将数据编码为特定序列的字节流。通常地,客户可以根据实际需求进行业务插件的定制化、特异化开发,其中,业务管理层、服务工厂、编解码处理器的协作模式会固化为几个可通过继承方式来支持可二次开发的基类以形成面向用户的业务插件开发模板。
示范性地,该支持层的诸多基础插件包括六大基础型插件,如图1所示,分别为:驱动管理插件、通信插件、系统功能管理插件、数据库管理插件、三方库管理插件以及远程升级(OTA)插件,其中,驱动管理插件可以用于挂载到该智能网关中的所有硬件设备的驱动管理;通信插件可以用于实现该智能网关与任意其他平台之间的通信;系统功能管理插件可以用于该智能网关的系统相关功能的管理;数据库管理插件可以用于该智能网关支持的多个类型的数据库管理;三方库管理插件可以用于该智能网关支持的第三方应用的管理;远程升级插件则可以用于实现该智能网关的多层次的远程升级。可以理解,通过对这些插件的调用及协同工作,可以实现该通用型的智能网关系统对任意平台的对接、不同硬件设备的适配等。
在一种实施方式中,驱动管理插件通过三层级结构进行外接设备的驱动管理,所述三层级结构包括:驱动管理层(对应于图3中的DriverManager)、单一类别管理层(对应于图3中的多个Handler)和设备信道/驱动对接层(对应于图3中的多个Connector)。具体地,驱动管理层主要用于控制单一类别管理层的驱动数据的输入输出、以及控制对目标驱动数据请求的应答。可以理解为,驱动管理层负责所有驱动数据的进出控制,对单一类别管理层中的每一类别驱动器进行管理及功能委托;此外,当其他插件发出目标驱动数据时,由该驱动管理层来进行对外应答。接着,对于单一类别管理层,该层级中可包括不同类别的驱动管理器,例如,可包括但不限于包括,设备节点驱动管理器(DeviceNodeHandler)、串行接口驱动管理器(SerialPortHandler)、CAN总线驱动管理器(CanHandler)等,每个类别驱动管理器分别用于根据配置文件选择所属驱动类别的位于设备信道/驱动对接层中的设备挂载;最后,设备信道/驱动对接层用于对接具体的硬件设备,并且提供有注册功能。可以理解的是,当硬件设备需要挂载到该智能网关时,需要先在设备对接层进行注册,才能使系统能够识别到该硬件设备并进行设备管理。
如图3所示,每个类别驱动管理器下可以挂接多个设备信道或驱动,例如,对于设备节点这一类别,在设备信道/驱动对接层中,可包括但不限于为GPS、I/O端口、Wifi等驱动,当实际挂载时,需要将对应的硬件设备对接到适配的驱动模块上。又例如,对于CAN总线驱动管理,可挂载有如第一CAN总线连接(即Can0Connector)、第二CAN总线连接(即Can1Connector)等。可以理解,图3中的单一类别管理层及设备信道/驱动对接层中的这些驱动结构仅为一种可行示例,技术人员可以根据相应的格式标准进行单一类别驱动器的配置,还可以替换设备信道/驱动对接层中的相应驱动结构等,这里不作限定。
在一种实施方式中,通信插件通过二层级结构进行通信管理,这里主要包括根据配置文件中的通信通道策略进行通信通道装配等。示范性地,该通信插件划分为二层级,分别为:路径管理层(对应于图4中的通讯管理器CommunicationManager)和数据传输管理层,其中,路径管理层用于根据对接的通信彼端确定数据传输通道,例如,数据传输通道主要包括两部分,即数据目的地和通信彼端的数据解析格式。在确定数据传输通道后,则在数据传输管理层中确定具体的封装格式以及传输协议。在一种实施方式中,如图3所示,数据传输管理层中包括传输数据封装控制器(对应于图4中的多个平台Handler)和数据传输控制器(对应于图4中的多个协议Connector),其中,传输数据封装控制器用于基于通信彼端的数据解析格式对传输数据进行格式封装,通常地,一个Handler对应一个服务顺的数据解析逻辑。而数据传输控制器用于选取匹配该通信彼端的传输层协议,以用于将封装后的数据传输至数据目的地。通常地,一个连接器(Connector)对应一个传输层协议。例如,这些传输层协议可包括但不限于包括Mqtt、UDP、TCP、FTP等。可以理解,图4所示的这些Handler和Connector仅为一些示例,具体可根据实际对接的平台类型进行预先配置。
在一种实施方式中,上述数据库管理插件通过三层级结构进行数据库管理,示范性地,该三层级结构包括:数据库管理层、数据库挂载决策层和数据库对接层;其中,数据库管理层用于根据数据处理请求控制对数据库的数据操作,并提供对数据库类型的指定配置。可以理解,可使用对业务层暴露的数据库类别指定函数对目标数据库进行配置,之后即可对目标数据库进行增删改查操作。例如,在一种实施方式中,该数据操作可包括但不限于为增加、删除、修改和查找等中的一种或多种组合。在一种实施方式中,该数据库管理插件可以至少支持三种类型数据库,具体包括依托xml,ini,json等格式文件的自定义数据库,类似redis的内存数据库,以及如mysql,sqlite,sqlServer等的关系型数据库,当然还可以包括其他的数据库,这里不作限定。接着,数据挂载决策层用于根据所述指定配置指定相应数据对接的其中一种数据库,并对接上下两层的所述数据操作;最后,数据库对接层则用于基于数据的驱动封装或自定义封装进行上述的等数据操作。
本实施例中,上述系统功能管理插件主要负责嵌入式系统的系统相关功能管理,例如,可包括但不限于包括Log功能管理、对目标终端的遥控功能等,在一种实施方式中,该Log功能管理可包括遥控Log开关的持久化动作,即确定将Log是否写入Log文件中;还可以包括控制Log的过滤等级,例如,可根据实际需求将不同等级的Log信息进行打印及上报等;又或者,还可以遥控上传Log文件,以便进行远程调试等。而对于目标终端的遥控功能,例如,可以基于目标终端的系统,进行控制命令自定义等。
本实施例中,对于远程升级(OTA)插件,其主要实现远程升级管理。在一种实施方式中,示范性地,该OTA插件包括采用升级任务状态回环设计,用于响应用户在升级过程中不同阶段的操作,保证升级的连续性;以及包括对不同版本的升级路径的管理、多层次的分离式升级等。具体地,该OTA插件支持三个层次的远程升级,分别是:1)升级对单片机内部烧录的程序;2)升级嵌入式操作系统;3)升级网关应用。值得注意的是,不仅仅可以是对系统文件、网关应用等的远程升级,本实施例的OTA插件还可以添加对配置文件、数据库表结构的升级功能。例如,需要进行配置文件升级时,远程服务器可通过查找挂载终端绑定的归属地及设备侧智能网关的版本号,可以索引到目标配置文件,然后将目标配置文件下载到目标终端,并通过覆盖方式覆盖掉原来的配置文件,以此实现配置文件的升级。又例如,还可以借助OTA插件利用远程SQL命令来遥控修改或新建数据表结构,以便适应不同对接平台的积压数据处理需求等。
此外,作为一种可选的方案,考虑到设备侧智能网关的硬件平台跨越性,外设对接任意性,数据库对接任意性,服务器网关对接的任意性,业务套接的任意性,故在实际应用中,对配置的需求往往是动态的,因此,该设备侧智能网关系统还支持扩展功能配置,以为系统自身提供一些扩展功能等。
示范性地,扩展功能配置的封装包括三层结构,分别为:配置文件读写控制层、动态递归抓取层和数据定向外送控制层。具体地,配置文件读写控制层用于控制从Json配置文件中读取数据到万用图数据结构中;动态递归抓取层用于以递归方式从万用图数据结构中进行配置数据抓取,例如,这些配置数据可划分为属性数据(即具体参数)和通信组元(即对接对象);数据定向外送控制层用于对抓取的配置数据进行数据格式简化并发送到相应插件。可以理解,万用图数据结构中是所有数据的全集,数据量较大,通过递归式抓取数据并以一个固定的结构体进行重组,以便供其他插件使用。
作为一种可选的方案,该智能网关系统还同时支持无界面部署及有界面部署,并进一步支持不同类型的界面接入。示范性地,该智能网关系统还包括人机交互接口(HMI)插件,值得注意的是,该人机交互接口插件将作为子插件挂载于支持层中的通信插件中,并根据配置文件确定是否启用。由于人机交互接口插件主要用于实现本地网卡中的进程间通信,与上述通信插件的区别在于,其结构仅包括传输数据封装控制器和TCP传输控制器。
进一步地,在人机交互场景中,通常需要进行送显操作,基于数据格式兼容性的考虑,在一种实施方式中,将使用JSON作为通信数据格式,并且为了在迭代业务的过程中减少协议的改动量,在依托JSON的基础上将对HMI的通信协议统一规划为两级,即总协议层和子协议层,其中,总协议层主要负责需要通信的服务以子协议的映射清单;而子协议层则负责业务类型、服务版本、数据大小、业务数据等。
可以理解,基于硬件厂商提供的嵌入式系统源码生成嵌入式系统后,只需要按标准模板编写设备对阶层,即可快速与该智能网关系统进行适配。同样,开发新业务时,按标准编写相应的业务插件即可,并对接到业务对接层,使得该智能网关能快速形成产品原型。在对接服务器平台时,可通过修改装配通信通道的配置文件,同样可与任意平台进行数据通信。此外,该智能网关系统的部署与测试均可以远程实现,大大降低了生产人力成本和时间成本等。
基于上述实施例的设备侧智能网关系统,本实施例还提出一种嵌入式设备适配控制方法,其中,该嵌入式设备是指可运行或支持嵌入式操作系统的小体量硬件设备,例如,对于智能穿戴设备,如智能手环等;对于家用电器,如智能冰箱、智能洗衣机、智能彩电、智能可控电饭锅、燃气安全检测设备等;对于电力设备,如电站大量部署的小型监控设备等;对于交通方面,如地铁票务设备等;甚至是农业用车载设备,如拖拉机、收割机、耕田机等。可以理解,上述设备侧智能网关系统能够实现对不同类型设备的适配,这里不再一一列举,而该设备的硬件平台依赖仅可运行嵌入式系统即可。在一种实施方式中,该嵌入式操作系统可包括但不限为linux系统等。
如图5所示,示范性地,该嵌入式设备适配控制方法包括:
S110,将按照预设格式封装的目标设备对接层注册到上述的设备侧智能网关系统中的驱动管理插件中,并为所述目标设备分配相应的设备ID。
S120,在目标设备进行数据上报期间,通过协作站机制将带有所述设备ID的上报数据广播到系统内的所有插件,以使业务对接层中的业务插件根据所述设备ID获得所述目标设备的上报数据。
其中,关于设备侧智能网关系统的相关描述具体参见上述实施例,这里不再重复说明。上述实施例中的关于该设备侧智能网关系统的可选项同样适用于本实施例,故这里不再重复描述。
为方便理解及该设备侧智能网关系统的通用性验证,这里以通常采用嵌入式操作系统进行控制的拖拉机为例,图6所示为设备侧智能网关对一个拖拉机作业检测的适配示例。示范性地,该农用智能拖拉机上包括不同的构成,如犁具,以及可以监测犁具状态的摄像头、相应传感器(如射频标签、倾角传感器等),为检测拖拉机的作业情况,需要将这些硬件挂载到智能网关系统中。如图6所示,该智能网关系统中包括上述的六大基础插件,业务插件则可根据实际需求进行添加,例如,这里主要是对拖拉机进行作业检测,故可按照预定的格式封装出作业检测的业务插件。此外,这里还可添加HMI插件,以将对拖拉机的操作数据进行反馈显示。为对拖拉机进行作业检测,具体地,可按照上述设备的类型封装出不同设备节点的对接层逻辑,如图6所示,如犁具识别器采用串口驱动,摄像头采用V4L2视频设备内核驱动,以及倾角传感器采用CAN总线对接等,然后注册到驱动管理插件的设备信道/驱动对接层,此时,驱动管理插件会为各个设备分配唯一的身份标识(ID),以便当这些设备进行数据上报时,可根据各自的ID来获取目标设备的上报数据,例如,这些上报的数据可以包括通过摄像头拍摄的视频数据、倾角传感器采集到的角度数据,以及是否感应到犁具等。进一步地,这些数据可以在交互界面中实时显示,此外,还可以利用通信插件发送到指定的服务器平台等。
本申请实施例还提出一种设备侧智能网关,例如,设备侧智能网关可以为车载智能网关等。示范性地,其包括存储器和处理器,其中,存储器存储有计算机程序,处理器用于执行所述计算机程序以实施本申请实施例上述的设备侧智能网关系统的功能。
其中,存储器可以是,但不限于,随机存取存储器(Random Access Memory,RAM),只读存储器(Read Only Memory,ROM),可编程只读存储器(Programmable Read-OnlyMemory,PROM),可擦除只读存储器(Erasable Programmable Read-Only Memory,EPROM),电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory,EEPROM)等。其中,存储器用于存储计算机程序,处理器在接收到执行指令后,可相应地执行所述计算机程序。
其中,处理器可以是一种具有信号的处理能力的集成电路芯片。处理器可以是通用处理器,包括中央处理器(Central Processing Unit,CPU)、图形处理器(GraphicsProcessing Unit,GPU)及网络处理器(Network Processor,NP)、数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件中的至少一种。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等,可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。
本申请还提供了一种可读存储介质,用于储存上述设备侧智能网关中使用的所述计算机程序。
在本申请所提供的几个实施例中,应该理解到,所揭露的装置和方法,也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,附图中的流程图和结构图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分,所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在作为替换的实现方式中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个连续的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,结构图和/或流程图中的每个方框、以及结构图和/或流程图中的方框的组合,可以用执行规定的功能或动作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
另外,在本申请各个实施例中的各功能模块或单元可以集成在一起形成一个独立的部分,也可以是各个模块单独存在,也可以两个或更多个模块集成形成一个独立的部分。
所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是智能手机、个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。