物联网产品中,经常提到的终端、网关、协议、PaaS、SaaS之间,到底有什么关系?

4 评论 8790 浏览 56 收藏 9 分钟

在互联网产品中,经常提到的终端、网关、协议、PaaS、SaaS之间,到底有什么关系呢?本文作者分享了互联网中频繁出现的一些词汇,以及为初入物联网行业的同学整理了一些坑,希望能给你带来帮助。

本文主要分享物联网频繁出现的词汇进行分享,例如「终端」、「网关」、「协议」等,以及为初入物联网行业的同学整理出笔者过往经历踩过的坑,以及后期如何避雷/排查问题。

一、基本概念

在百度/其他地方搜集的信息中,对于终端、网关、协议、PaaS、SaaS的解释各有不同,整理如下:

  • 终端:物联网产品中的终端是指与物联网云端通信的设备,通常包括智能手机、平板电脑、智能穿戴设备等。终端用户通过终端设备连接到云端,实现物联网的数据采集、传输和处理。
  • 网关:网关是物联网产品中的重要组成部分,主要用于在不同设备和系统之间进行数据交换和转换。网关可以将不同的协议、数据格式和通信方式进行转换,以便终端设备可以与云端进行通信。
  • 协议:协议是在物联网产品中实现数据传输和交换的重要技术。不同的设备和系统之间使用的协议可能不同,因此需要通过协议转换来实现数据的互通。常见的协议包括WiFi、蓝牙、ZigBee等。
  • PaaS:PaaS是指基于云端平台的开发服务,提供开发人员所需的开发环境和工具,帮助开发人员快速构建和部署物联网应用程序。PaaS平台通常包括代码编写、测试、部署和监控等功能。
  • SaaS:SaaS是指基于云端平台的服务,用户无需安装任何软件或硬件,只需通过互联网即可使用物联网应用程序。SaaS服务通常包括应用程序的部署、管理和更新等功能。

用一张图来解释下相关定义信息:

举一个小例子:

小A的妈妈买了一个定位器「设备」安装到他电动车上,小A骑电动车出去上学。有一天小A在路上发生了车祸,发生车祸的时候,小A和他的车被碰倒了,于是「设备」发送“告警信息”给小A的妈妈的手机,说小A在路上出车祸了,你快去救他!

以上信息中,上报给谁?这时候上报的位置是「网关」,但是设备不会像我们人类一样用语言说:“喂,你的儿子/女儿在什么什么时间,在哪里哪里好像被车撞到了,然后摔倒了,触发了我这个告警哦”,他们会和「网关」之间协商好用某一种语言来代表这种信息,这一种语言,就是「协议」。那么「网关」在其中扮演什么角色?网关,就是这个“翻译官”,他把设备上报给他的内容,翻译成另一种语言,来和「PaaS」进行沟通交流。

网关把信息传给「PaaS」之后,「PaaS」经过计算后监测到,这个信息很重要啊,我要赶紧推送给他妈,让他的妈妈知道小A出车祸了,快去救他,于是「PaaS」赶紧把这条信息,推送给了小A妈妈的手机上的设备绑定的软件,也就是「SaaS」所以大家对设备、协议、网关、PaaS、SaaS有了基本了解了吧。有一个小小的疑问,为什么终端到网关,网关到PaaS不用同一套语言呢?

二、不同「角色」之间使用不同「语言」的原因

我们都知道终端到网关之间有对应的协议,网关解析信息后到PaaS又是另外一种语言,主要有以下几个原因:

  • 可扩展性:终端和网关之间需要直接互操作,但PaaS的用户是开发人员,它提供的是工具和组件。因此,直接使用终端和网关之间的语言可能会导致有不同的技术栈和复杂性。如果使用不相同的语言,则可以提供更好的灵活性和可扩展性。
  • 安全性:终端到网关和网关到PaaS之间的信息传递可能涉及到敏感信息,所以需要额外的数据验证来确保信息安全,例如数据加密和身份验证。而使用不同的语言可以提供更好的安全性和保护机制。
  • 可维护性:使用不同的语言可以使下游系统更加具有维护性质,并且更加易于管理,这样的话开发人员可以使用不同的语言框架来编写应用程序,且此类语言框架的安全性易开发性等已经被测试验证。
  • 另外有时还有设备本身的原因,设备的成本较低时,内存也较小,只能通过01序列或简单的机械处理信息,无法做到像PaaS云服务器一样存储庞大的底层语言,当然并非针对全部设备而言。

那么知道这些信息,对于初入物联网行业的产品经理而言,已经可以解决很多问题,让我们来看一个案例。

三、如何解决现实中遇到的问题?

背景:在曾经的车联网产品设计生涯中,出现过一个问题,有一天业务部门找到我,说有一个较大的客户购买了n台定位器设备,但是这些设备里其中有80%的设备已经成功导入到saas平台,并且已经开机了,但是平台显示并没有激活,功能却可以正常使用,开发同事查看代码后,发现设备已经正常激活上线。

分析:那么我们从产品的角度分析下,设备正常的工作流程,设备上报信息(登录包、心跳包)给到网关,网关解析后,到达PaaS,PaaS存储相关登录日志/时间等信息后,同步至SaaS,SaaS正常接受登录包,后端将状态调整为激活,看起来是没有什么问题的,按理来说设备是可以正常激活上线。

以上假想是建立在,设备已经导入平台后,再进行开机上线的,上线后可以正常通过协议上报心跳包、登录包等,若设备先开机上线,再导入到平台,此时,设备的心跳包、登录包已经在导入前上报过相关信息,则无法及时通过上报自己的登录包等包体,网关无法进行解析,则自然而然,状态未激活。

写在最后

物联网涉及的范围较为广泛,不同领域对于数据处理、信息上报等方式均不同,若文章中与您有不同理解,也欢迎在评论中留下看法见解。

本文由 @布布的铲屎官 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 我可不可以这么理解:
    (1)设备只和物联网网关联系,然后由物联网平台(网关+PaaS)将信息发送给软件平台(SaaS),由软件平台控制客户端应用。
    (2)所以这个过程中需要两套语言和两套存储,一套是“硬件语言”,一套是“软件语言“。
    (3)大部分情况下,物联网平台可以自己建设也可以用云厂商的。
    (4)设备和物联网网关的联系,可以借助自身的网络模块,也可以借助附近手机的网络(蓝牙连手机),但是最终都是只能联系到网关
    不知道这样理解对不对?

    来自广东 回复
    1. 是这个样子的

      来自北京 回复
  2. 同学你好,看完后受益匪浅,整体比较形象生动,有两个问题:
    1.基本概念中的协议,是否指的是通讯方式,您所说的协议应该是数据传输协议?
    2.设备在线状态的监控问题,是否应该定期通过协议去请求设备端的状态,这样就不会出现你文章中业务部门描述的那个问题?

    来自湖北 回复
    1. Hello,是这样的,基本概念中的协议即为数据传输协议,其实无需定时定期去对设备进行自启,原因如下:
      1、设备使用的场景并不相同,对于轨迹、车辆实时数据的监控比较严格的设备,例如押送罪犯的车辆的设备、运钞车的设备等,定期重启设备期间会有几秒/十几秒的时间设备无法正常上报数据,会有发生事故的可能性。
      2、发生以上行为问题的原因其实是激活判断的条件有误,若要是否是激活状态是按照设备是否上报「登录包」作为判断条件,然则设备是否激活是一个状态,在设备上报登录包后,他的状态已经由「未激活」变为「激活」,所以其实应该按照「心跳包」作为是否激活的判断标准,若以此为判断标准,设备会每隔几秒上报心跳包,上报心跳包后,paas网关解析,存储,后续SaaS去查的时候,状态进行切换,变为「已激活」

      来自广东 回复