1. 程式人生 > >【IOT APP】 車聯網應用開發技術及過程深度剖析

【IOT APP】 車聯網應用開發技術及過程深度剖析

app 客戶端 位置 targe ket 來源 底層 協議封裝 通道

 在上篇文章新興的IoT行業風口,能夠把握的機會有哪些?中,我們介紹了目前六大常見的IOT移動應用開發類型。今天以APICloud開發的車聯網項目為例,剖析其開發過程中的相關項目經驗和通信技術架構!

技術分享圖片

  ▌項目介紹

  最初新能源汽車車主充電的方式只能通過使用充值卡進行充電,找樁也不是特別方便,開發一款能夠解決這一系列問題的APP很有必要。本次分享的充電樁項目解決了用戶找樁難、充電繁瑣的問題,通過APP內的地圖導航找到附近的充電站,APP內可實時查看充電站內所有充電樁的使用狀態、充電信息等,還可提前預約指定充電樁。車主通過地圖導航找到對應樁的位置,插槍後在APP內遙控開啟充電,可操作且可視化的應用體驗,解決了新能源車主充電找樁的首要難題。

  ▌技術實現

  ● 確定智能設備的通訊方式

  首先需要確定充電樁設備支持的通訊方式,APICloud支持多種物聯方式,如通過socketManager模塊實現socket通訊、通過ble模塊實現藍牙通訊,以及第三方的機智雲gizWifiSDK模塊和慶科mico等。本項目中,運營商的充電樁設備內部采用socket方式與充電樁廠家的內部server端進行通訊。

  ● 確定業務流程

  每一個物聯設備都有相應的開啟、關閉及運行中的相關業務流程,第二步需要確定整個業務流程,本項目充電樁業務流程為:預約-插槍-開始設備充電-充電中顯示充電信息-結束設備充電-生成充電訂單-訂單支付-完成充電。

  ● 確定項目的物聯架構

  運營商要求充電樁設備必須連接至自有服務器,將充電樁的相關控制邏輯無縫集成到整個項目APP的業務流程中。充電樁廠商負責提供的可與充電樁設備進行內部通訊的server端SDK對外提供封裝好的業務接口,最終安裝至運營商的服務器。在項目的服務端底層抽象封裝好可與SDK對外接口進行通訊的相關業務接口,在與APP通訊的相關業務接口中調用封裝好的底層接口,最終實現APP控制充電樁的效果。

  項目的整個物聯架構:充電樁設備<->設備server <->項目server<->APP client

  ,即智能硬件+數據通信平臺+業務服務端+手機客戶端的四方通信技術架構。

  這種四方通信的架構不需要實現智能設備跟數據通信平臺之間的協議,以及客戶端跟智能設備之間的協議,APICloud平臺提供的SDK已經幫助開發者將協議封裝過了。四方通信架構可分為Wi-Fi或者GPRS模式與藍牙模式兩種,以下分別為兩種模式的詳細介紹。

  Wi-Fi或者GPRS模式:當客戶端去操控智能設備時,會通過Http或者Socket協議發送指令到業務服務端,服務端接收到指令後將該指令下發到智能設備端,智能設備接收到指令並做出反饋,通過UDP或者TCP協議將信息上報到業務端,業務端接收到反饋的數據下發到客戶端進行展示。

  藍牙模式:智能設備跟客戶端通過藍牙或者Beacon協議建立連接通道,智能設備通過該連接通道將數據上報給客戶端,客戶端通過Http或者Socket將數據提交到業務服務端,業務服務端通過分析處理,將數據下發到客戶端進行展示,用戶可以通過客戶端的數據展示,發送指令到智能設備,對設備進行操控。

  ▌項目總結

  智能設備物聯的技術難點在於如何解決APP與設備之間的實時通信及APP與不同廠家的樁對接,本項目服務端與智能硬件之間的通信,交由智能硬件廠家封裝的服務端SDK自行處理。SDK對外提供統一的業務接口。項目服務端采用sever層對接sever層的方式進行通訊,通過api接口的抽象封裝,完成APP的sever層對接廠商充電樁的sever層的直接業務通訊。采用這種方式,規避了不同設備廠家設備通訊方式、通訊協議不同導致的聯調不便的問題。

  項目服務端不再關心智能硬件的內部通訊細節,專註於業務功能、業務邏輯的實現。APP僅需調用封裝好的固定API接口,即可調用智能硬件服務端與智能硬件進行通訊,實現服務端底層控制智能硬件,以及在不進行APP版本更新的情況下,同一APP客戶端對接多個廠家的充電樁的效果。

  作為將真實世界和數字世界連接起來的媒介,IoT越來越多被各大公司重視。APICloud認為物聯網不是一個行業,而是一種新的企業架構形式,並沒有行業的限制,唯一限制的只有人類的想象力。

  *作者註:以上技術框架基於移動應用開發平臺APICloud實現,來源http://www.apicloud.com/。

【IOT APP】 車聯網應用開發技術及過程深度剖析