物联网平台设计(物联网平台前端设计与实现)

 

作者：人月神话，新浪博客同名

简介：多年SOA规划建设，私有云PaaS平台架构设计经验，长期从事一线项目实践

今天整理下我最近2到3年对物联网云平台，智慧家庭和物联网开放生态体系建设方面的文章。实际上我们看到从传统的软件云平台到物联网云平台构建，整体思路虽然一致，但是仍然存在较大的差异，特别是在软硬件环境的整合上面。

物联网PaaS云平台概述

对于物联网云平台可以先参考下机智云或氦氪科技两家的IOT云服务平台的一下参考介绍。

传统硬件升级为智能硬件，会在已有的近端控制，已有的传感器信息采集能力上增加远程控制和信息采集能力。常见的在传统硬件上增加wifi模组，4G或GPRS，Zigbee等远程控制能力芯片。同时增加对设备的远程控制APP应用。

一个设备的智能化升级并不一定就需要网关，而对于一个涉及到多个智能硬件组成的完整解决方案（例如智慧安防）则一定会涉及到服务网关这个硬件设备。这个网关不仅仅是很好解决了安全隔离的问题，同时更加重要的是实现了多硬件Drvier层API能力的聚合，只有在聚合后才能够更好的实现多个智能设备之间的联动和协同，转发和路由等能力。

在整个IOT大生态环境下，单个智能硬件本身能发挥的价值会越来越小，而更加重要的是硬件和硬件之间的链接，通过这种链接后衍生了各种基于业务和需求场景的增值类物联网应用。

一个最简单的智能硬件，需要有APP应用，公有云端Server和服务提供，升级了智慧硬件芯片的硬件这三个部分的内容。

把这个思考清楚后就可以看到一个物联网的PaaS平台应该是：

硬件+软件能力聚合的一个平台

简单的说就是在将一个传统硬件升级为一个智能硬件的过程中，平台层提供了更多的硬件+软件层面的服务能力帮助你快速的完成一个硬件的升级改造。

从硬件层面：

提供本地化的开发环境，开发包等，协助你完成Driver驱动和驱动能力的暴露。即首先你在接入一个硬件的时候，首先你要注册一个硬件设备ID，同时再将这硬件的Drvier层能力注册和发布出来。

从软件层面：

我们需要开发一个控制类APP或应用类的APP，那么平台需要提供一些开发框架和环境，开发工具包，同时更加重要的是提供平台层共性和标准技术能力，这个技术能力包括了安全，数据库和缓存服务，消息，存储，CT能力调用等。提供这些技术服务能力的目的很简单，让我们能够更加快速的开发和构建自己的APP应用。技术服务+Driver层暴露的API服务，两者结合起来才能构建一个完整应用。

一个好的物联网PaaS平台一定是包括了开发平台和运行平台两方面能力提供，首先是提供开发环境，框架和工具，协助快速开发和本地化调测，其次是提供运行平台能够将开发完成服务或应用进行托管和部署。同时在整个过程中我们需要提供DevOps的完整一体化从开发态到运行态（本身又包括了测试环境和生产环境）的迁移能力。再进一步，我们还可以提供运维阶段的运维监控，数据统计和分析接口和能力。

传统的软件PaaS平台强调的是APPID，而物联网PaaS平台关注的是设备ID，而APP本身归属到设备上。传统的软件PaaS平台不会太关注服务的单独注册和发布，服务的管理，而物联网PaaS平台则必须包括服务API的全生命周期管理能力。服务API是衔接硬件Driver和智慧应用APP间的重要桥梁。即物联网PaaS平台必须包括了类似OpenAPI平台，云服务总线或微服务网关等的相关能力并进行了整合。

物联网云平台和传统软件云平台区别

对于物联网云平台暂时没有找到一个权威标准的定义，但是可以将其简单理解为实现物联网应用从传统的客户端转移到云端统一集成和管理的平台。物联网云平台和传统的软件云平台一个最大的区别就是物联网应用不是单纯的软件，而是软件+硬件设备的结合，正是由于该原因，云平台必须提供设备层的接入和资源管控能力。

物联网软件平台最关键的功能：设备管理、集成、安全性、数据收集协议、分析类型以及支持可视化，有个网站对主流的物联网云平台做个一个对比可以参考上图。

可以看到，其中集成方式以Http Rest接口服务为主流，同时对于设备信息采集和消息处理以MQTT为主流。当前对于阿里云，百度，中国移动，包括类似京东，乐视，还有机智云等都推出由自己的物联网云平台。

对于这些物联网云平台可以看到核心仍然是提供两方面的能力：

设备和Driver层API的快速接入，设备性能数据采集和监控物联网应用APP的设计，开发，测试，发布，管理全部云化能力

物联网云平台本身不仅仅提供硬件资源池的Driver相关API的聚合能力，同时还提供对于应用层业务服务和内容服务的聚合能力，这也是和传统云平台的一个区别。传统的软件云平台只涉及到软件APP和云平台两个部分的内容，而对于物联网云平台则涉及到云平台，移动APP，物联网设备三者之间的协同和互动，这也是两个云平台之间的一个差别。

对于一个真实的物联网应用场景，对于在设备端往往是一组设备的管理而不是单个，同时在设备端还需要具备离线和近场的管理能力。正是由于这个原因，往往在一个物联网云平台的协同架构中，在设备端还会增加一个物联网的网关，做设备资源类的API能力的聚合，近场的控制，简单的控制组合等操作。

对于两者的区别可以再看下百度IoT云平台的一个架构图，如下：

在百度IoT框架中，IoT设备启动后要注册到百度IoT云。设备注册成功后，云端将设备管理起来。在设备活跃状态下，云端可以向设备端下发监控命令，设备端也可以主动向云端上报数据。

从这个图可以看到物联网云平台在传统IaaS和PaaS软件服务的基础上，增加了IoT的PaaS平台服务能力，在百度整体架构图里面又将其分为两个框，一个是和硬件设备接入相关的PaaS层服务能力，一个是和移动APP软件接入相关的PaaS层服务能力。

在这里，对于设备的注册，接入，固件Driver的下发和升级，设备信息采集，性能监控，设备认证和安全等都是和物联网场景应用相关的一些能力，这也是物联网云平台和传统云平台不同的一个地方。同时我们也看到一个物联网云平台一定会提供对Open API接口的统一管理和监控能力，这本身就是一个轻量的服务总线，也是物联网云平台必须要提供的内容。

以上内容都搞清楚后，我们基本就把物联网云平台和传统云平台的区别搞明白了。再简单点来说就是物联网云平台需要同时提供资源层（设备接入）和应用服务层（APP+OpenAPI)全部云端管控和治理能力。

物联网云平台关键功能组件

物联网网关

我经常会谈到API网关，也曾经谈过智慧家庭里面的网关设备，但是没有专门谈过物联网网关，实际上对于智慧家庭网关本身也是属于物联网网关的范畴。对于物联网网关，首先还是参考下百度百科给出的一个基础定义，具体如下：

物联网网关，作为一个新的名词，在未来的物联网时代将会扮演非常重要的角色，它将成为连接感知网络与传统通信网络的纽带。作为网关设备，物联网网关可以实现感知网络与通信网络，以及不同类型感知网络之间的协议转换．既可以实现广域互联．也可以实现局域互联。此外物联网网关还需要具备设备管理功能，运营商通过物联网网关设备可以管理底层的各感知节点，了解各节点的相关信息，并实现远程控制。图l示意性地给出了以物联网网关构建的物联网典型拓扑。

在这里面强调了一个关键重点，即物联网网关来实现感知网络和通信网络的互联，但是感知网络存在多种不同的协议，比如Lonworks、ZigBee、 6LowPAN、RUBEE等，那么要实现这种互联网，网关就必须具备协议转换能力。同时网关有两个重点，就是既实现广域互联，同时在广域互联网不可用的时候，往往可以通过网关来实现局域网互联，即近端的相互交互和协同。

对于物联网网关的功能，主要包括：

1.广泛的接入能力

目前用于近程通信的技术标准很多，仅常见的WSNs技术就包括Lonworks、ZigBee、 6LowPAN、RUBEE等。各类技术主要针对某一应用展开，之间缺乏兼容性和体系规划。现在国内、外已经在展开针对物联网网关进行标准化工作，如3GPP、传感器工作组，实现各种通信技术标准的互联互通。

2.可管理能力

强大的管理能力，对于任何大型网络都是必不可少的。首先要对网关进行管理，如注册管理、权限管理、状态监管等。网关实现子网内的节点的管理，如获取节点的标识、状态、属性、能量等，以及远程实现唤醒、控制、诊断、升级和维护等。由于子网的技术标准不同，协议的复杂性不同，所以网关具有的管理性能力不同。提出基于模块化物联网网关方式来管理不同的感知网络、不同的应用，保证能够使用统一的管理接口技术对末梢网络节点进行统一管理。

3.协议转换能力

从不同的感知网络到接入网络的协议转换、将下层的标准格式的数据统一封装、保证不同的感知网络的协议能够变成统一的数据和信令；将上层下发的数据包解析成感知层协议可以识别的信令和控制指令。

这些基本的网关能力总结都没有问题，但是对于物联网网关，其中一个关键的核心就是网关本身是实现感知层和通信层的唯一入口和出口渠道。外部只需要和网关打交道即可，而网关来调度和管控下面接入和注册的各种类型的感知设备。

因此网关有一个关键能力，类似API网关，即对于感知层各种感知设备提供的不同类型的协议的接入和适配，同时在协议接入后能够转化为标准的接口协议和通信层交互，对于实时的接口可以采用类似Http Rest接口，而对于消息集成可以采用类似标准的MQTT消息等。这也是我们原来谈智慧家庭的时候经常会谈到的物联网网关更多的是硬件层的Drvier API的注册和接入，包括后续的管理。

物联网网关一般在架构和实现的过程中会提供一个硬件设备来完成，这个设备来实现协议转换，路由，转发，自动注册管理，接口的北向和南向集成能力。这个网关一般是部署在局域网端的一个设备，对于整体的云架构来说，只需要这个网关设备和云端进行交互即可。

在前面我有文章谈到过边缘计算，可以看到对于边缘计算的最终落地，完全可以在物联网网关层来实现，即进一步提高物联网网关的存储和计算能力。一方面是实现自动采集数据在网关层本地采集后，经过二次加工再采集上传到云端，一方面是云端的关键计算规则和逻辑下发到网关层，支持在网关层来实现本地化的计算。而这也将成为网关层能力的一个关键扩展。

物联网设备模型

物联网系统的基础架构模型，即云+app+端集成架构。

云平台：部署在云端的物联网应用程序，除后台管理外核心是实现数据信息的采集和控制端：即我们常说的近端侧物联网设备，包括物联网设备的近端组网和物联网硬件网关应用APP：方便我们对物联网智慧设备进行管理的APP应用和服务平台

而实际上整个模型里面我们讨论最多的就是近端的组网和联动能力，近端的计算和存储能力。因此会涉及到两个关键，一个就是近端的硬件网关设备，一个就是具备计算和存储能力的边缘计算设备。相对而言，对于云平台和app应用来说并没有太大的变化。

对于云平台端，一定会涉及到一个物联网管理平台，实现对用户，设备等基础数据的管理，因此这篇文章来思考下一个后端的管理平台应该如何抽象一个通用的模型。

对于一个物联网运营平台来说，最基本的该模型应该是一个支持多租户架构的模型，每个租户能够完全实现应用权限，数据方面的资源隔离能力。在这个明确后我们再来看模型的抽象，初步来看，我准备从位置模型，设备模型，组织模型，权限模型几个方面来分开谈。

位置和基础设施模型

可以看到该模型是基于GIS地理信息拓展的一个多层树状模型结构。从最顶端的行政区域模型，再到区域分类->基础设施楼宇->分层分单元->具体的房间号->房内区域。这个层次模型应该要做到相当灵活的可配置能力，简单来说我们推要给智慧校园项目和一个智慧公寓项目两者之间应该是有差异的，但是核心的基于GIS地图和位置信息拓展本身是不变的。

即针对我们实际运营的项目，我们应该去构建这么一个模型，究竟要建几层你自己去定义，每层类别应该扩展哪些熟悉你也自己去定义。这样才可能具备足够的灵活和可配置能力。为何需要这个模型，因为最终的物联网设备我们需要知道究竟安装和部署在哪里的，即设备最终需要和位置模型进行关联，这样设备才具备了位置属性。

组织人员模型

组织人员模型实际上和我们传统业务系统中的模型相似，即这里有两个业务对象，一个是组织结构，一个是人员，人员最终是挂接在组织结构下面的。要分多租户，那么租户就应该是组织结构树的最顶层。组织结构树本身也是树状结构模型，可以做到灵活的多层扩展，层次结构本身也没有限制。

人员最终是挂接在某个组织节点下面，形成人员和组织之间的关系。方便后续的业务功能和数据授权操作。同时也方便对平台的人员和用户进行分组管理。

在智慧家庭的应用里面，我们看到还有一个常规的组织结构模型里面没有的概念，即家庭模型，首先你有一个家庭的概念，家庭里面有多个人，实际上在家庭里面的设备是可以被家庭里面的多个人共享和管控的。因此家庭聚合层实际上是在组织模型里面必须具备的一个组织节点层。

设备模型

设备模型实际上是我们谈到最重要的一个模型，因为各类设备的参数属性配置都不应用，但是针对所有设备有有一些通有的基础配置。因此设备模型本身应该是一个基础配置+扩展配置模式的，对于扩展配置可以做到灵活扩展，自定义属性，按需配置。

其次设备模型里面还需要包括两种关系模型

设备和子设备：类似父子结构，而且我们需要管理到子设备，但是子设备不能脱离父设备设备组合：一套组合的设备，既可以独立存在，也可以形成组合提供更强大的功能

这两种设备关系也需要在我们进行设备模型建模的时候统一考虑。要意识到设备模型本身不仅仅是简单的设备基础元数据管理，更是要用于后续的设备接入，注册，设备能力提供，数据采集，监控等一系列动作。

整体说明

设备属于某一个位置，同时人员本身属于某一个组织，同时位置和组织本身之间也有关联关系。人员操控设备，人员和设备之间本身又建立关联和拥有关系。

物联网云平台-能力聚合和开放

前面谈到，对于物联网云平台可以看到核心仍然是提供两方面的能力：

设备和Driver层API的快速接入， 设备性能数据采集和监控物联网应用APP的设计， 开发， 测试， 发布， 管理全部云化能力

物联网云平台本身不仅仅提供硬件资源池的Driver相关API的聚合能力， 同时还提供对于应用层业务服务和内容服务的聚合能力， 这也是和传统云平台的一个区别。 传统的软件云平台只涉及到软件APP和云平台两个部分的内容， 而对于物联网云平台则涉及到云平台， 移动APP， 物联网设备三者之间的协同和互动， 这也是两个云平台之间的一个差别。

今天重点谈下整个物联网云平台架构中的服务能力聚合层，在一个完整的物联网端到端应用里面，可以看到能力聚合层起到关键的承上启下的作用。即物联网的能力聚合层核心作用就是将底层各种物联网云平台或硬件Driver层，硬件网关层的能力聚合起来，然后统一开放给上层的业务应用使用。或者将将硬件层的能力通过适配和接入后，转变为标准的软件接口服务，并以能力开放，比如OpenAPI接口的方式暴露给上层。

而这种接口服务能力的开放本身又涉及到北向接口和南向接口两个方面的内容：

1. 北向接口：采集硬件层的设备状态，熟悉，健康指标等信息。2. 南向接口：对设备的各种控制信息，Driver更新等通过南向接口服务，写入到设备层。

那这个时候做上层业务系统就简单了，不需要去关注复杂的硬件层接口，而只需要使用标准的软件API接口服务即可。而这个时候的能力聚合和接口能力开放类似标准的OpenAPI平台或微服务网关的能力。简单来说就是这个服务聚合网关需要的关键能力就是：

服务的接入和注册，服务代理和发布，服务安全和访问控制，服务运行监控，消息管理(MQTT)，流量控制，其次包括了最基本的服务元数据。如果是一个可运营的服务能力开放平台，那么就还需要多租户管理，服务订购，产品和订单管理，计费管理等方面的能力。即在能力服务本身标准化后，服务本身也就是产品，是可以发布出去进行订购供外部业务系统消费，并进行计费的。

互联网小常识：综合布线系统设计等级：基本型（1）、增强型（2）和综合性。

从物联网大生态来说，那么物联网的服务能力聚合平台一定不是简单的接入和聚合硬件和网关Driver层的能力，更加重要的是聚合外围周边生态的软件服务能力。而这些软件服务能力本身包括了围绕硬件层设备的增值服务提供(安装，维修），也包括了内容提供（音乐，视频，食品配送）等。

从最简单的服务能力聚合转变到物联网厚PaaS平台能力提供

一个服务能力聚合平台，发展演进到后面就会越做越厚，核心的原因还是我们前面经常谈到的，你在实际应用场景实现过程中，会发现很多共性的内容，而这些共性内容按云平台的思路都应该是下沉的，即共性能力下沉然后以服务能力的方式向外暴露接口。而对这种共性能力本身又包括了技术共性能力和业务共性能力，业务共性和垂直行业类应用密切相关。

技术平台：技术平台解决技术共性能力，技术共性包括了典型的4A基础能力，流程引擎，地图，搜索，消息，缓存，文件等，这些能力和业务无关，可以在技术平台统一规划和提供。

业务平台：类似于基于垂直行业业务中台的概念，这类共性能力往往基于不同的垂直业务领域单独规划设计，将关键的业务场景和流程中的抽象业务模型提取出来，下沉到业务中台数据模型中，形成共性化的业务接口服务能力后再向上层应用开放。

所有技术平台和业务平台中的各个组件完全可以按照微服务架构思想进行设计，每一个组件就是一个相对独立，高度自治的微服务模块，可以进行独立的设计，开发和部署运维。对于这种组件最终提供的接口服务能力也是接入和注册到服务聚合平台。也就是说对于技术+业务平台，和服务聚合平台之间本身也是一种松耦合的关系。

将物联网能力聚合平台按OpenAPI平台的思路来做，这个OpenAPI平台将成为整个物联网生态里面承上启下的重要纽带，同时开发相应的自服务门户和流程，包括服务的自助接入和订购，真正形成一个围绕整个生态链上下游以聚合为核心的能力平台。

物联网云平台整体架构重新思考

近期会对物联网云平台进行重新思考，首先还是要对整体架构做进一步的梳理。实际上在18年有不少的文章已经谈到了物联网云平台，包括和传统的软件云平台的差别等。

在重构物联网云平台整体思路的时候，有些关键点简要总结如下：

构建一个技术平台容易，但是基于物联网的业务和应用场景来构建一个运营服务平台，或者说构建一个完整的生态则相对难，不仅仅需要技术能力，还需要对业务的深入理解能力，最外围资源的整合能力。构建生态需要的更多的是开放心态，服务化驱动，系统思考。

物联网云平台核心点还是在硬件Driver层的能力接入，即不仅仅是软件能力，也包括了硬件能力接入，而硬件能力最终又转变为软件类的协议和接口，和软件完成协同和控制。所以当我们将物联网云平台的时候，一定是软件+硬件融合的一个生态环境。

同时当我们将物联网云平台提升到一个业务运营和服务平台的时候，这个时候就不仅仅是技术平台，更加重要的就是物联网厂家下的硬件，软件应用，内容服务等各种服务能力的接口抽象和服务能力聚合。即物联网云平台不再单纯是技术平台，而是具备了强大的业务能力和内容服务提供能力的物联网业务中台。而作为这个业务中台面向客户和用户的延伸，则可以是一个泛电商平台。

泛电商平台核心是电商平台，但是将围绕物联网智慧硬件构建一个完整的电商生态，一个是前端的客户关系管理和地推销售，一个是后端的装维和售后服务。电商本身提供产品和服务，而这个产品则是物联网智慧硬件，物联网应用软件，而服务则是各种基于物联网软硬件的内容服务和增值服务能力。一切围绕物联网生态展开。这个生态将具备极强的外围扩展能力。

常规的容器云PaaS，技术中台仍然是物联网云平台的关键内容，这些内容支撑智能硬件从接入到运行到后续运维监控的全生命周期流程。而设备和软件最终上线运行后，将转变为电商平台可以销售的产品或服务。同时电商平台完成产品销售，本地化的安装服务后，将形成真正在线运行的智能产品。

手机APP端+智能产品和网关+公有云服务中心三者本身又形成一个完整的闭环运作流程。而从公有云数据中心本身完成数据采集和处理后，为后续构建增值服务的大数据分析运营中心提供基础。

物联网开放平台整体子系统划分

物联网发展的三个阶段，即连接-感知-智能， 第一阶段是设备接入，大量的内置了WiFi，ZigBee，蓝牙，RFID等的智能终端设备被制造出来并连接入围。第二阶段是设备状态被感知，并产生海量数据，形成物联网大数据，也是我们一直强调的数据形成积累是走向第三阶段基础；第三阶段对产生的数据进行分析和机器学习，形成初始的人工智能能力，实现用户和商业价值。

物联网应用领域相对广泛，比如智慧城市和智慧家庭，车联网，企业资产管理，工业互联网，能源互联网和泛在电力物联网，智能建筑，智慧农业，智慧物流等。物联网应用种类繁多，市场需求巨大。

平台模式是企业主导的经营模式，而生态体系是建立在该模式基础上的企业网络化协同整体图景。Apple和Google的发展思路揭示了搭建开放平台，在此基础上建立生态体系，从而获得巨大成功。

而实际上我们看到真正的重点在于首先平台往往更多是技术层面的内容，而生态体系则涉及到诸多的外围合作伙伴的参与和业务层面内容的提供。平台更多提供的是资源和技术层面的能力，而生态提供的是业务，内容和服务能力。平台提供商和生态提供商本身可以分离，各发挥优势。比如我们可以基于阿里的物联网云平台，构建上层的物联网细分领域的生态体系等。

物联网平台型生态中的用户类型包括平台提供商，设备供应商，应用提供商，内容和服务能力提供商，运营商，最终用户等，相互之间形成一个完整的覆盖物联网硬件产品全生命周期的生态体系。特别要注意物联网能力开放平台包括了硬件设备开发商和软件应用开发商，硬件设备开发商实现智能设备的开发和接入，软件商实现应用，内容和服务的提供。两者可以分离，也可以是同一个厂商。但是对于涉及到诸多物联网设备硬件大集成厂商，设备组合联动的，一般都为独立的集成类开发商来完成。

物联网开放平台应用产品分类-应用类产品，设备类产品，通道类产品，托管资源类产品，功能组件类产品，服务API类产品。

物联网开放平台总体架构

物联网开放平台主要是面向物联网整个生态体系中的所有角色提供物联网设备和应用的快速开发，部署，能力开放，计费结算，服务运营能力的平台。可以将物联网开放平台划分为六大子平台分别为设备管理平台(DMP)，连接管理平台(CMP)，应用使能平台(AEP)，资源管理平台(RMP)，业务分析平台(BAP)和应用中心平台(ACP)。这个分发为作者的一个分发参考，非标准分法。

设备管理平台：对物联网终端的远程监控，设置调整，软件升级，系统升级，故障排查，生命周期管理等，同时还可以实时提供网关和应用状态监控告警反馈。而要做到这些，有两个关键点，一个就是设备模型的抽象，一个就是对设备接口的抽象，这两个是能够实现对设备全生命周期管理的基础。

设备接入过程，比如当前的智慧家庭里面的各种智能设备，一般在家庭WiFi网络下可以实现设备的自发现，在自发现设备后再通过API接口实现在互联网云平台的设备注册和接入，设备注册接入后设备管理平台即可以通过相关的接口API对设备进行各种管理。

设备一般需要同时提供北向接口和南向接口，北向接口实现数据和状态的采集，而南向接口实现云端对设备的状态控制。注意在有物联网网关的场景下，设备一般会先注册接入网关，而不是直接接入到云端平台，这个时候就需要建立设备和网关之间的关系连接。同时云端平台也间接通过网关来实现对设备的管理和控制。

连接管理平台：一般应用于运营商网络上，实现对物联网连接配置和故障管理，保证终端联网通道稳定，网络资源用量管理，连接资费管理等。在这本书里面讲的连接管理平台更多是和运营商相关的，而实际上即使无运营商介入也存在连接管理平台。

应用使能平台：提供应用开发和统一数据存储两大功能的PaaS平台，架构在CMP平台之上，这个和我们通常说的软件PaaS平台是一致的。一般的PaaS平台能力服务层包括数据中心，应用开发测试运行环境，原子服务和能力中心，能力开放API，开发社区，以及安全管理和运营管理。

注意物联网的应用使能平台和传统的PaaS平台最大区别就是增加了和物联网智能设备和终端的联动，否则无法完成一个完整的开发测试工作，因此你首先要进行设备的注册和发现，设备的接入，然后才可能让你的设备能够和你的应用之间形成联动并进行测试验证。这是和传统软件PaaS平台最大的区别，也因此设备管理平台实际上物联网PaaS平台不可分的一部分。

资源管理平台：对应常说的软件云平台里面的IaaS资源池

应用中心平台：该平台为开发者，应用提供商，能力提供商，设备厂商等提供功能组件，能力，应用服务，通道资源，托管资源，商品的发布展示销售，业务营销，计费结算，客户服务。可以理解为是一个产品最终入库上架后的后生命周期管理平台，类似一个物联网电商平台+运营平台+售后服务平台。

业务分析平台：包含基础大数据分析服务和机器学习两大功能

和传统的软件能力开放平台的区别，我们可以看到传统软件PaaS平台一般为两者联动，即软件用户或APP和云端SaaS应用的联动，而在物联网能力开放平台下变成了三者联动，即软件用户APP，云SaaS应用，终端的智能设备三者之间的联动。从子系统层面物联网能力开放平台在传统的PaaS平台基础上增加了设备管理平台和连接平台，其核心关键还是设备管理平台和传统PaaS平台间的集成和协同。

物联网能力开放平台和能力聚合，真正实现物联网整体生态系统中的软硬件一体化，资源内容服务一体化，物联网设备前后生命周期一体化，物联网设备和应用研发，运营和最终的运维管控的一体化。因此基于上面的各个子系统可以看到，设备管理平台和应用使能平台实现软硬件一体化，再加上应用中心平台后实现研发运营交付一体化。这是相对不容易的事情。

物联网开发生态和万物互联

在前面谈物联网云平台的整体框架的时候，实际上一直就在思考不仅仅是整体架构框架的重构，更加重要的是基于业务需求和业务场景对整体生态体系的重构。即通过物联网云平台做为关键的技术能力支撑，泛电商平台做为关键的业务和服务能力支撑来重构整个物联网业务生态链。

这个生态链即需要实现从需求到最终产品交付使用的横向流程贯通，同时又需要实现纵向的从硬件设备层到云平台再到电商应用和APP终端的纵向打通。而所有的外围生态都是围绕横向和纵向业务，数据和流程的全面贯通而展开。既实现了内部的完全整合，又通过服务聚合和能力开放来实现更大外围生态。

前面一直在谈万物互联。一方面是物物连接，一方面是物人连接，同时也包括传统软件应用中的人和人的连接。所有的连接都基于场景驱动，通过连接产生了直接的价值，同时通过连接形成大量的数据积累产生后续的大数据分析价值。

因此物联网生态也可以讲是一个连接生态，而这种连接除了我们常规谈到的软硬件技术，协议和应用外。更加重要的是人工智能，即万物互联是第一，物化智能是第二，没有智能的连接和应用无法灵活的匹配需求和场景，也无法带来更大的增值服务价值。

基于以上关键思路，我们来看需要考虑的关键点如下：

构建面向外围智能设备厂商的，覆盖从设备接入，运行，运营和运维管控的全生命周期支撑平台。这个核心仍然是物联网云平台，这个云平台本身也是物联网云能力开放平台，更加体现了面向设备厂商的自服务能力，设备厂商基于平台提供的标准规范，开发框架，基础插件，标准接口定义，接入流程，测试流程就能够快速的完成自己设备的改造和快速接入。

构建面向智慧平台大B企业的端到端运营平台，云平台完成最终的智能设备接入和上架，而运营平台完成最终智能设备的推广销售，后续的装维上线，上线的完整产品运营和管控。从大B企业到最终的C端客户，从设备订购到最终的安装上线，到后续的运行运维，实现完整的全生命周期管理流程。也实现整体运营平台的端到端管理能力。

构建面向最终的C端客户的从需求到交付的端到端支撑平台，核心仍然是前面谈到的泛电商平台，提供智能设备，应用，内容，服务多方面的增值服务能力。覆盖客户从需求到消费使用的端到端流程，并形成完整闭环。

互联网小常识：SNMP有三个版本版本1是最基本最简单也是当前最主要的。版本2不完善。版本3刚推出还没有完全推广。SNMP采用一种分布式的结构。一个管理站可以管理控制多个代理；反之，一个代理也可以被多个管理站所管理、控制、为此，SNMP采用了“团体”这个概念来实现一些简单的安全控制。

构建基于云平台+服务聚合开放+泛电商形成的外围生态连接平台，其中外围生态包括了智能设备制造商，软件应用开发商，内容提供商，第三方增长服务提供商，金融和支付，第三方物流等。该生态的整合一个关键就是服务聚合和能力开放，开放的能力又支撑外围更多的合作伙伴接入。其次，就是我们看到这个生态里面有三类产品，本身又是一个逐步演进和深入服务的关键。先是智能设备，其次是智慧应用，再次是基于智慧设备和应用提供的各类内容服务和增值服务。

产品->应用->内容，从智慧硬件产品，再到最终的内容和增值服务，将智慧产品从最简单的智能控制功能转化到内容服务提供，才是可持续发展的运营思路。

构建从建设过渡到运营后期的大数据分析增值服务能力平台。平台真正开始运营后，那么一定能够实际的采集到用户使用智能硬件产品的行为数据，消费习惯数据，而这些数据经过大数据采集，数据处理和分析后，形成上层的大数据分析平台。通过大数据分析一方面是为第三方提供增值服务能力，一方面是通过大数据分析来改善我们前面的硬件接入上线，电商产品运营和针对性营销的整个流程。使得整个平台能够保持持续优化和改进。

万物互联和数据赋能

对于万物互联，里面重要的有三点：

连接-万物互联：物物连接，物人连接，硬件和软件的连接，线上和线下的连接都可以纳入智能-数据驱动：连接后不是物本身智能了，而是积累的数据通过分析后具备了智能需求-场景驱动：做任何事情我们都需要有需求驱动，需求一定要依附于实际的用户场景

在百度搜索，我们可以看下对万物互联的一个解释

万物互联（IoE）定义为将人，流程，数据和事物结合一起使得网络连接变得更加相关，更有价值。万物互联将信息转化为行动，给企业，个人和国家创造新的功能，并带来更加丰富的体验和前所未有的经济发展机遇。

在这个解释里面除了谈到的人和物外，还增加了流程和数据，而流程可以理解为前面谈到的关键业务需求和场景驱动，而数据则是真正的为人工智能和分析决策服务。

万物互联仅仅是第一步，数据赋能才是真正的价值体现。

接着我们还是先谈下万物互联里面的一些核心

第一个要谈的就是连接

这个连接大家很容易理解，首先要由物，然后还要由网络，最终就能够形成连接。

这个物本身就包括了人，事物两个方面。人和人，人和事物，事物和事物之间都可以产生连接。而事物本身又包括两个方面，其一是移动事物，类似货车，飞机，贴了条码标签的物品；一种就是静态基础设施事物，类似我们谈到的家庭设备，地下管线等。

而连接核心是网络，包括现在的5G网络和低功耗广域网（LPWAN），能够实现物联网的部分应用需求。目前全球主流技术标准有两个，一是华为主导的NB-IoT，另一个是国外厂商主导的LoRa。万物互联，就一定涉及到数据随时随地的采集和传输，而这就需要高性能高可靠的网络支撑，而这也是为何说5G技术的发展本身是对万物互联的一个巨大支撑。特别是对于实时的视频图像采集和快速决策分析等。

在整个连接里面还有一个关键对象，就是我们常说的物联网采集设备，传感设备等。通过物联网传感设备让物本身具备了可感知的人化能力。但是要注意我们的目标仍然是事物本身，而不是物联网设备，传感设备仅仅是一个辅助我们万物互联实现的一个工具罢了。

第二谈下流程和业务场景驱动

在原来我谈SOA架构咨询和接口服务识别的时候，经常会谈到跨系统交互的端到端业务流程，其原因就是接口本身不是无缘无故就产生的，接口本身是为了满足跨系统交互的业务流程服务的，是跨系统交付的业务流程产生了对接口的需求，产生了对业务系统连接的需求。

简单的说就是，这种连接本身是有业务流程和需求场景支撑的。

在现在的万物互联定义里面增加流程，是相当大的一个进步，即任何一个连接我们都要去思考为何需要存在，这个连接究竟是为哪个业务流程和需求场景服务。不要为了连接而连接，连接本身不是目的，而连接最终产生业务价值才是目的。

这也是我们在做物联网应用和运营服务的时候必须要考虑的点，就是一定是业务和需求场景驱动，去考虑为了满足业务流程和业务场景的需求，究竟需要形成哪些连接，采集哪些数据等。

最后谈下数据赋能

对于物联网和万物互联，连接本身不是目的，通过连接满足业务需求，实现业务价值是目的。而这个业务价值的实现本身又包括两个方面：

低层次价值：实时的满足业务协同的需要，比如完成业务流转，业务控制等流程。高层次价值：基于数据分析给出最佳辅助决策，或者能够完全实现人工智能自动化处理。

而我们这里谈的数据赋能更多的就是指让数据发挥高层次价值，单个数据往往只能体现低层次价值，而大量数据的积累形成大数据后就能够帮助我们进行人工智能和辅助决策。因为只有足够多的数据我们才能够完全我们的机器学习和模型的训练，使我们的决策模型具备更高的准确度。

大数据本身已经提出了很多年，但是人工智能发展明显延后，其原因主要还是体现在网络本身的发展上，数据采集和处理需要有强大的网络支撑，其次就是人工智能本身就需要前期多年的数据积累参与训练，这本身也有一个过程，而最近1到2年，我们也看到物联网人工智能发展的相当快速，因为所有的前提条件都已经具备。

欢迎关注@人月聊IT 分享SOA，微服务，DevOps平台规划和建设。

互联网小常识：IEEE802.3为传统局域网的协议，IEEE802.3u为快速以太网的协议标准，IEEE802.1d为透明网桥的协议标准，IEEE802.1q为VLAN的协议标准，IEEE802.5为令牌环网络的协议标准。

免责声明：本站所有信息均搜集自互联网，并不代表本站观点，本站不对其真实合法性负责。如有信息侵犯了您的权益，请告知，本站将立刻处理。联系QQ：1640731186