物聯網產品中,經常提到的終端、網關、協議、PaaS、SaaS之間,到底有什么關系?

4 評論 8487 瀏覽 52 收藏 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去查的時候,狀態進行切換,變為「已激活」

      來自廣東 回復