如何给物联网项目赋能?——ClearBlade物联网边缘计算平台介绍

作者:与子同袍
首发:物联网前沿技术观察

之前经常听到国内的物联网厂商提到赋能俩字,但是一直没搞明白到底赋了啥能,给谁赋的。最近同袍君正好看了点德州的ClearBlade的资料,好像稍微明白了一点。好东西不敢独乐乐,这篇文章就给大家介绍物联网应用项目赋能平台——ClearBlade物联网边缘计算平台。

1.引子

通常,物联网网关提供商和物联网平台提供商都存在这样的矛盾:网关和平台固定的功能无法满足众多物联网应用客户的多变的需求。例如:

  1. 客户A今天买了1000个网关,但是客户A考虑到传感器成本和可靠性,要求后期对已经部署到现场的网关能够支持其他型号的传感器接入。
  2. 客户B他为了降低风险,要求两家物联网网关产品都要能接入到客户B指定的某厂家物联网平台上。
  3. 客户C规模比较大,集团总部要求所有物联网项目数据都要接入到集团总部的IT部门的数据仓库中。
  4. 客户D要监控的设备是高价值的非标生产线设备,要采集的数据点、告警规则、监控界面等每个设备有部分是相同的,剩下的一部分是不同的。
  5. 客户E是做智慧园区监控的,需要把上传的数据发送给指定的第三方平台。一会是MySQL,一会是mongodb,一会又要求是socket,kakfa。

上面这些需求都是普遍、真实存在的。通常每个物联网客户都会提出些这样那样的定制需求。如果每个客户都给他们去定制,物联网网关和物联网平台就变成了物联网项目开发——表面上卖的是硬件产品和平台软件,实际上卖的是软件定制服务。这样子就很难做大做专做强。用高大上的语言来描述的话,就是物联网平台没有给物联网应用软件开发赋能。

这是目前行业内普遍存在的困境。

为什么会出现这样的困境呢?——本质上,是因为网关和平台的控制权在网关和平台开发商手里。他们没有把控制权开( fu)放( neng)给用户。控制权在网关和平台开发商手里,那有需求,用户没法改。现场边缘计算层面的物联网网关设备的程序都是固定的,无法在云端随时修改更新现场网关设备的业务逻辑代码、数据、配置文件、访问权限、网关与云端传输的消息格式等。不找你找谁?

例如现场的物联网网关接的某型号的振动传感器成本太高,而且快停产了,需要更换传感器厂商。那就需要更新现场物联网网关内的传感器采集程序和配置。传统方式就是派人去现场更新,这样成本很高。高级点的,支持远程升级物联网网关内的一些程序和配置文件,或者整体来远程OTA升级整个固件系统。

但是这样做还是存在问题,为什么?因为业务逻辑开发过程和这个升级部署过程是分离的。对边缘计算物联网网关内的业务逻辑代码、数据、配置文件、访问权限、云端传输消息格式,一般网关厂商和云平台厂商都是定死的,不允许最终使用者去修改。要改个传感器协议采集程序,或者改下MQTT传输的格式,物联网应用程序开发者没法改。

这样,物联网应用程序开发者,只能找物联网网关厂商和物联网平台厂商去提需求,让他们去配合修改。这样物联网应用程序开发者有力使不上,物联网网关厂商和物联网平台厂商也不胜其烦,因为会有很多客户要求他们改这改那。要是不给客户改,那他们就不会用你的东西;要是改吧,整天跟在后面改也来不及。

那为什么不把对网关和平台的控制权放开,把用户关心的东西都开放出来,对用户赋能,让他们可以自己去修改、去配置、去部署呢? 为什么不直接在物联网平台上让最终用户在Web界面上,把修改现场网关的程序、数据、配置之类的都暴露给用户呢?

理想情况下,对边缘计算物联网网关内的业务逻辑代码、数据、配置、权限、云端传输等的配置应该都是灵活的。让物联网平台的二次开发人员可以随时修改,随时部署到已经在现场运行的网关。

这样子一来,网关和平台厂商的定制压力就会小很多。客户可以自己去做想做的事情。

皆大欢喜。

2.ClearBlade平台总体介绍

上面说了这么多,其实就是ClearBlade要解决的问题。

ClearBlade是2018年的Application Enablement Platform(AEP,应用程序赋能平台)评分卡上榜的厂商之一。为什么能上榜?因为它确实给物联网应用程序开发商赋能了。

下图是ClearBlade物联网平台的总体结构图。

整体上分为两大部分:

  1. IoT Platform(物联网平台):是一个可以根据不同行业定制要求二次开发的物联网云平台。部署在云端,支持多租户。每个租户可以创建多个系统。在每个系统下开发人员可以根据业务需求,创建、配置和管理数据、消息传输、自定义代码、触发器和可视化界面。然后将这些资产下发到边缘平台上执行。同时向上也提供了与其他企业信息系统集成。
  2. IoT Edge Platform(物联网边缘平台):部署在边缘计算设备上,向下与物联网设备交互,向上与物联网平台连接。通过适配器Adapter来接入各种协议的设备。

用户在ClearBlade物联网平台上首先创建一个系统。系统相当于当前租户下创建的一个物联网监控系统。

在系统内,开发人员可以创建业务逻辑代码、物联网设备协议适配器、自定义可视化监控界面、数据集合、定时器、触发器、界面插件、边缘设备等。

创建系统有四种方式:

  • 基于已有的系统模板
  • 从GitHub项目导入
  • 从系统文件导入
  • 创建空的系统

我们选择创建空的系统。然后填写系统名称PlcRemote,就创建好了一个系统:

我们可以看到出现了12个功能模块。这些功能模块都是可以让用户自己创建和定义的。

下面我们来一一介绍这12个功能模块。

3.12个功能模块的介绍

3.1服务Services

为了便于开发人员根据业务逻辑需要,扩展平台功能,ClearBlade提供了Code功能模块。

Code功能模块可以让开发人员实现自定义业务逻辑的代码,然后Web端、移动端等就可以通过ClearBlade的API调用这些代码。

Code分为两种:服务和库。

ClearBlade的服务其实就是生命周期最长30秒的JavaScript微服务。在沙箱中运行,一旦完成调用,就销毁。

服务可以用三种方式调用

  1. RESTful API请求
  2. 触发器Trigger触发
  3. 定时器Timer触发

每个服务有一个名称,这个名称与自动生成的服务函数名相同。

例如创建了一个名称为analyze的服务,系统就会自动生成如下函数:

function analyze(req, resp){}

这个函数有两个参数,与NodeJS 的Express框架类似。

服务可以使用Requires指令导入一个或多个库Library。以便使用ClearBlade提供的或自定义开发的库。

定时器Timer提供了让服务可以定时调用的机制。创建服务时,可以指定一个定时器来告诉系统定时执行这个服务。定时器的调度机制与UNIX的cron job类似。

例如:

  • 从现在开始每隔5分钟运行一次服务
  • 从2019年1月1日的每两周的周五开始,运行26次服务
  • 每天凌晨运行一次服务

除了定时器,还可以在服务上定义触发器Trigger。一旦触发器的触发源Trigger Source对应的事件发生,就会调用该服务。

触发源Trigger Source的分类

  1. 消息:Publish、Upon Subscribe、Upon Unsubscribe、User Connected、User Disconnected、Device Connected、Device Disconnected
  2. 数据:表Created、表Updated、表Deleted、item Created、item Updated、item Deleted
  3. 用户:Created、Updated、Deleted
  4. 设备:Created、Updated、Deleted

3.2库Libraries

库Library也是Code的一种。它是可重用的代码。服务用Requires指令就可以导入使用库。

库分为两种:

  1. Native库
  2. 自定义库

本地Library是ClearBlade自带的JavaScript库,包含了常用的功能。底层是用Go语言实现的,并且每个库都进行了性能优化。

Native库包括:

  1. Clearblade:与集合、消息、用户、边缘、设备等进行交互
  2. Log:日志输出
  3. http:http/https请求
  4. geo:地理信息处理库
  5. crypto:hash算法库
  6. file\_writer:文件写入
  7. jsutil:js辅助函数类库
  8. mailer:邮件发送
  9. net\_cb:网络库
  10. oauth2\_lib:OAuth辅助类库

开发人员也可以创建自定义库,封装常用的业务逻辑,用于重用。

3.3集合Collections

在开发物联网系统时,不同开发人员会选择不同的后台数据库用来存储从物联网设备传输上来的设备实时数据和历史数据。

ClearBlade平台考虑到了这个普遍性的需求,封装了集合这个抽象概念。一个Collection相当于一个数据库。

开发人员通过Collections来存储不同类型的数据到不同的数据库中。

每个Collection可以通过Console、Portals、API和SDK来访问。

Collection分为两种:

  • Cloud
  • Connection

Cloud

ClearBlade提供一个默认的基于Postgresql的cloud Collection。

Connection

Connection类型允许开发人员,集成已有的数据库。目前支持如下几种:

  • MySQL
  • PostgreSQL
  • MongoDB
  • Oracle
  • DB2\_Linux
  • DB2\_zOS
  • DB2\_System\_i
  • Microsoft\_SQL\_Server
  • Cassandra
  • CouchDB

3.4适配器Adapters

适配器是一个开发人员自定义的软件组件,部署在物联网网关设备上运行。它实际上就是相当于边缘计算设备上与设备打交道的协议驱动程序。

每个适配器都有一个名称,若干个管理命令,和一些可执行的程序文件。

这些文件包括可执行的程序和依赖库,以及用来管理适配器的shell脚本。

一旦适配器已经成功部署到边缘设备,就可以在平台的开发人员终端web界面上启动、停止或者重启适配器。

适配器的状态有运行和停止。

如果适配器没有部署到边缘设备,那么这个边缘设备会放在未连接边缘设备界面中。

适配器支持的命令类型有:

  1. 部署命令Deploy Command – 在边缘设备上安装完适配器后运行的命令或shell脚本。可选命令。
  2. 启动命令Start-up Command – 启动适配器的命令或shell脚本。
  3. 停止命令Stop Command –停止适配器的命令或shell脚本。
  4. 状态命令Status Command – 查看适配器当前运行状态的命令或shell脚本。
  5. 取消部署命令Undeploy Command – 在边缘设备上卸载部署好的适配器。
  6. 日志命令Logs Command – 从边缘设备上获取适配器的日志文件。

3.5门户Portals

作为一个物联网监控系统,肯定要有可视化监控界面。ClearBlade通过Portal来让开发人员定制和二次开发可视化界面。

Portal门户是一个Web应用的实例。它是响应式的、移动端友好和可定制的。

Portal可以包括:

  • 多个Page页面
  • 多个数据源
  • 一个Header Pane
  • 一个Flyout Pane

Portal包含的组件有:

Portal界面上可以访问的数据源包括:

  • Collections
  • MQTT消息主题
  • Code Service

Page

用户每次可以看一个页面。默认页面是’Home’页面。

一个页面可以包含多个面板Pane。

Pane

一个面板是一个或多个widget的容器。面板的宽高是根据Bootstrap Grid网格布局。

Widget

Widget控件与一个或多个数据源关联,根据数据源的数据进行可视化渲染或者交互。

Parser

Parser解析器是数据源输出的数据在给widge渲染前进行的处理。转成widget所需的数据格式。

Flyout Pane

这个面板是可定制的面板,位于左侧。

Header Pane

这个面板在Portal中每个页面都会显示,用作header。

External Resource

外部资源代表了一个外部网站的一个js或css文件。

Theme Editor

主题编辑器用于自定义portal的主题颜色样式。

Screen Size Editor

屏幕大小编辑器用于根据不同屏幕大小,调整面板和widget的布局。

3.6插件Plugins

插件是Portal加载的JavaScript文件。它的用途是用于扩展支持当前不支持的数据源和widget控件。

3.7部署Deployments

部署用于指示哪些资源要部署或同步到哪些Edge边缘计算节点。

部署到Edge边缘计算节点的资源,可以是系统中创建的如下内容:

  • Code:包括Service和Library
  • Collections
  • Adapters
  • Portals
  • Roles
  • Users
  • Devices
  • Edges
  • Messages

Edge边缘计算节点上的资源或者物联网平台上的资源可能会发生变更。因此要部署的资源需要配置相应的动作。

动作有两种:

  1. 部署Deploy:当边缘设备启动时,资源会被从云端部署到边缘设备。
  2. 同步Sync:资源已经部署过了,当边缘设备或物联网平台的资源变更了,边缘设备和物联网平台之间就会自动进行同步更新。

最常见的部署应用场景是:开发人员首先在物联网平台上创建好业务相关的code service和collections,然后Snyc部署到多个Edge边缘计算节点上。这样当Edge边缘计算节点上的collections发生变化,物联网平台的collections也会同步变化。

3.8角色Roles

角色是物联网平台上的用户的访问权限的类别分类。默认分为系统管理员、匿名用户和认证用户三类角色。系统管理员权限最高。

每个角色都有对应的权限。下图是系统管理员的部分权限:

3.9用户Users

能够访问这个系统的用户的管理。

用户创建完成后,会让管理员设置该用户的角色。

3.10设备Devices

设备是指物联网传感器和物联网设备。这些设备不一定是通过TCP/IP网络连接的,也可能是通过低功耗蓝牙或ZigBee等方式通讯的。边缘计算网关可以连接一个或多个设备。

3.11边缘设备Edges

Edge就是一个边缘计算设备,例如对应现场的一个网关。

创建完成后,可以设置edge。选择target目标宿主机环境,然后就可以复制Edge程序的安装脚本,执行该脚本就可以在目标边缘计算设备上安装好Edge。

Edge的安装命令

curl -fsSL https://get.clearblade.com -o get-clearblade.sh; sh get-clearblade.sh edge linux-amd64 5.0.5

Edge的启动命令

edge -platform-ip=’platform.clearblade.com’ -parent-system=’a8953ecc0bc8c7b27gcr’ -edge-ip=’localhost’ -edge-id=’edge1′ -edge-cookie=’t6W19QRwG8xK726X9b08C7n9′

3.12消息Messages

边缘计算平台和云平台支持MQTT协议。可以通过触发器触发调用自定义的Service服务,以实现复杂的消息处理流程。

消息发送流程

流程1: 在 publish这个触发源上绑定一个触发器,来用service处理消息,然后再publish

每当有mqtt消息发布到物联网平台,那么触发器就调用相应的Service服务进行处理,然后再发布为另外一个消息。

流程2: 在publish这个触发源上绑定一个触发器,通过Service将这个消息存储到Collections中保存。

ClearBlade平台完整实现了MQTT 3.1.1版本的协议。

4.API接口和SDK

ClearBlade提供RESTful API,可以对系统的各种资源进行管理。

比如通过Code接口,可以直接调用相应的Service服务。

SDK是对上述API的封装,支持有多种语言,如Python、Java、Go、C、C#、NodeJS等。

5.平台的优缺点

缺点:

角色和权限较弱。权限好像更多针对的是开发人员,对最终使用者权限关注不够。

扩展性不够,只是在资源上允许进行简单的字段扩展。

开发起来还是有点繁琐,对开发人员技术要求有一定门槛。

Collections的界面不好用。

资源部署的历史版本没有。

适配器的实现对开发人员约束太少,封装不够。

Portal功能不如开源的Grafana之类的可视化dashboard软件。

缺乏对自身的监控指标的监控。

优点:

抽象的比较细腻。把平台二次开发所需要的功能全部暴露给开发人员,便于开发人员根据行业业务逻辑要求扩展。

可以远程下发适配器之类的到边缘计算节点上。

提供了多种语言的SDK。

资源自动同步。

每个类型的资源都可以扩展自定义字段。

推荐阅读:

  • 十步实现工业互联网数字化车间-看麻省理工学院Tulip车间小程序平台如何快速实现数字化车间
  • 工业革命下的四种生产模式的历史演化过程
  • 你要知道的工业4.0智能工厂的需求,都在这里了!
  • 都想转当码农?No!看工业4.0浪潮下德国机械工程师如何提升自己?

更多物联网,边缘计算相关技术干货请关注我的专栏物联网前沿技术观察
申请加入物联网技术研讨大佬微信群,请加微信号:iot1999

发表评论

邮箱地址不会被公开。 必填项已用*标注