物聯網產品設計中的裝置升級功能

物聯網產品設計中的裝置升級功能

目錄

• 物聯網產品設計中的裝置升級功能
  • 一、背景
  • 二、韌體升級對裝置的重要性
  • 三、遠端韌體升級整體框架圖
  • 四、TFTP變種協議及遠端韌體升級流程
    • 1. TFTP協議
      • 1.1 協議簡介
      • 1.2 傳輸模式
      • 1.3 協議格式
      • 1.4 TFTP 通訊流程
      • 1.5 TFTP協議的缺陷
      • 1.6 TFTP客戶端/伺服器設計注意事項
    • 2.遠端韌體升級流程
  • 五、IBMS 端程式設計流程圖
    • 1. webApi程式設計
    • 2.升級訊息通知定時任務程式設計
      • 2.1 Redis訊息結構
      • 2.2 平臺與裝置之間的Modbus定製升級命令及其響應格式
    • 3.升級日誌回寫Mysql定時任務程式設計
  • 六、幾個重要模型
    • 1.UpgradeCluster
    • 2.UpgradeTask
    • 3.UpgradeResult
    • 4.升級裝置表
  • 七、升級功能測試
  • 八、網頁原型圖設計
    • 1.叢集管理
      • 1.1 在裝置基礎上點選或者多選新增叢集
      • 1.2 根據硬體版本或者軟體版本或者區域編碼（區域中文名稱）來建立叢集
    • 2.升級任務管理
      • 2.1 上傳升級檔案
      • 2.2 選擇升級叢集
      • 2.3 選擇升級時間段
      • 2.4 輸入升級策略
      • 2.5 輸入管理員密碼以確認升級任務
      • 2.6 確認之後的升級任務
    • 3.升級日誌管理

一、背景

在迅速變化和發展的物聯網市場，新的產品需求不斷湧現，因此對於智慧硬體裝置的更新需求就變得空前高漲，裝置不再像傳統裝置一樣一經出售就不再變更。

物聯網平臺支援通過線上升級方式進行裝置韌體升級，是智慧裝置修復系統漏洞、實現系統升級的手段，為使用者通過韌體升級提供更好的服務。韌體升級功能不僅能夠更新韌體，而且還能重新配置片上硬體資源。同時，線上升級也是嵌入式裝置端的敏捷式開發的新型產品化方式。

二、韌體升級對裝置的重要性

物聯網領域具有多樣性，應用和最終解決方案需求也是如此。面對和傳統裝置的需求差異，OTA升級顯得尤其重要，主要體現在以下幾方面：

1. 市場端的快速上線需求
   天下武功唯快不破，物聯網裝置產品往往留給設計者的時間不長，並且市場需要持續不斷地創新和更新功能。在裝置設計時，往往會預留一些後載入的需求，先期快速實現一些功能即開始上線，上線後可以通過線上升級的方式更新更多功能，實現漸進式部署，有那麼一點類似於網際網路的敏捷研發了。只要在架構設計階段，在硬體層面考慮到了未來的足夠需求，就不可以源源不斷地優化完善裝置功能。

2. 裝置部署需求的多樣性
   在物聯網產品應用過程中，裝置需要確定推送資訊的雲主機。那麼問題就來了，有可能是一個通用的雲主機，也有可能因為部署需要又需要更新推送的雲主機，這個時候如果裝置已經生產出來了，已經在渠道或者客戶手中，那麼遠端韌體升級就顯得很重要了。

還有一個比較常見的現象，一些裝置在安裝以後，對於輸入輸出部件的控制模式需要變更，那麼可能需要對部分裝置進行韌體升級。比如，一開始在一個城市部署了相同智慧路燈的裝置，但是某些區域的裝置關於燈光強度或者時間性需要做變更，那麼遠端韌體升級也可以幫助解決燈光控制方式的變更。

備註：如果預留了遠端下行控制指令，且已經支援的，也可以不用升級韌體。

3. 裝置安全性及完善性
   任何物聯網裝置不外乎都是兩部分組成的：硬體+韌體程式。在基於SoC的應用中，遠端韌體升級功能不僅能夠更新韌體，而且還能重新配置片上硬體資源。

有了遠端韌體升級的備案，那麼產品不一定等到完全沒有缺陷再上市，只要在不存在較為致命的缺陷下，就可以提前上市，解決問題後在遠端完成升級修補缺陷。同時基於日益嚴峻的安全形勢威脅，備韌體可通過遠端韌體升級流程獲得最新補丁和更多安全演算法，做到不斷加固的。

三、遠端韌體升級整體框架圖

四、TFTP變種協議及遠端韌體升級流程

1. TFTP協議

1.1 協議簡介

本應用的升級服務採用TFTP協議 RFC1350 中文,並且用到了TFTP(RFC2347)，用來支援OACK包格式，可選項應答，支援-tsize選項(RFC2349)。TFTP (Trivial File Transfer Protocol, 簡單檔案傳輸協議也稱小型檔案傳輸協議)。預設基於UDP方式進行實現，但是本應用採用TCP方式進行實現，原因是如果是無線（如4G）組網，UDP無法找到裝置，而TCP基於長連線，只要不釋放連線，平臺能找到內網中的裝置，裝置需要先連線公網平臺。

1.2 傳輸模式

模式名稱	模式含義	說明
netascii	文字傳輸模式，按照一個位元組8位解析	文字模式
octet	二進位制模式，資料無需解析	二進位制模式
mail	已過時，不使用	已過時

本應用使用octet模式。

1.3 協議格式

TFTP共定義了五種型別的包格式，格式的區分由包資料前兩個位元組的Opcode欄位區分，分別是：

opcode operation:

1. Read request (RRQ)
2. Write request (WRQ)
3. Data (DATA)
4. Acknowledgment (ACK)
5. Error (ERROR)

即：

• 讀檔案請求包：Read request，簡寫為RRQ，對應Opcode欄位值為1
• 寫檔案請求包：Write requst，簡寫為WRQ，對應Opcode欄位值為2
• 檔案資料包：Data，簡寫為DATA，對應Opcode欄位值為3
• 回應包：Acknowledgement，簡寫為ACK，對應Opcode欄位值為4
• 錯誤資訊包：Error，簡寫為ERROR，對應Opcode欄位值為5

1.4 TFTP 通訊流程

• tsize選項：
  當讀操作時，tsize選項的引數必須為“0”，伺服器會返回待讀取的檔案的大小
  當寫操作時，tsize選項引數應為待寫入檔案的大小，伺服器會回顯該選項

• blksize選項：
  修改傳輸檔案時使用的資料塊的大小（範圍：4~65464）

• timeout選項：
  修改預設的資料傳輸超時時間（單位：秒）

1.5 TFTP協議的缺陷

• 傳輸效率低
• 對於超時機制沒有明確說明
• 每包長度固定為512位元組，不靈活

1.6 TFTP客戶端/伺服器設計注意事項

1. 只能是客戶端傳送讀寫請求，讀寫請求資料包中可能附帶選項資訊。在讀寫請求資料包中可能有很多個選項，但一個選項只能出現一次。選項出現的順序並不重要。

2. 當客戶端向伺服器傳送帶選項的讀請求資料包，伺服器可能返回三種響應：

• OACK：應答讀請求和選項
• DATA：應答讀請求，無選項
• ERROR：請求被拒絕

3. 當客戶端向伺服器傳送帶選項的寫請求資料包，伺服器可能返回三種響應：

• OACK：應答寫請求和選項
• ACK：應答寫請求，無選項
• ERROR：請求被拒絕

2.遠端韌體升級流程

備註：4，5步驟，結束包分兩種情況：1.如果檔案位元組不是512的整數倍，裝置端則收到不足512位元組的包之後，響應ACK，服務端關閉socket；2.如果傳輸檔案剛好是512位元組的整數倍，則最後一個有效包傳輸完成之後，裝置端會返回兩個ACK。接收到第二個ACK，服務端發空包，ACK返回有效包號+1，服務端關閉socket。

五、IBMS 端程式設計流程圖

1. webApi程式設計

2.升級訊息通知定時任務程式設計

2.1 Redis訊息結構

頻道：FileReceive
{
“fileType”:”upgrade”,
“ips”:
  [
    ”192.168.1.1”,
    “192.168.2.3”
  ]
}

2.2 平臺與裝置之間的Modbus定製升級命令及其響應格式

升級命令及其回應相見《LD_RD_IPDCU800管控協議格式說明書v0.0.12_chengzp20190529》1.4.5

3.升級日誌回寫Mysql定時任務程式設計

六、幾個重要模型

1.UpgradeCluster

存於Redis中，
ip地址以逗號隔開的集合的字串，例如："192.168.1.2,192.168.2.3"；
叢集名稱；
裝置總數；
使用者ID（用來做許可權）；
key：叢集名稱；
使用增刪改查方式；

2.UpgradeTask

裝置名稱；裝置IP；
執行時間；DateTime型別；
執行策略：DateTime型別；延時時間；
檔名稱：string型別
叢集ID；
使用者ID

key：GUID；
增刪查

3.UpgradeResult

裝置名稱，IP 地址，升級結果，更新時間

儲存到mysql資料庫，自增ID為主鍵；
查

4.升級裝置表

key：裝置名稱（或者IP地址）

taskId，devId（資料庫主鍵）,ip，計劃開始時間，內碼

此表位於Redis中

七、升級功能測試

Step1. TCP工具下發指令的升級回應包，包型別為05。

Step2.將裝置升級為1.04版本。
1.04版本指令
f0 aa 55 0f 85 60 a4 c2 ab 78 20 34 01 4C 44 2D 52 44 5F 49 50 44 43 55 38 35 30 5F 41 70 70 6D 64 5F 31 2E 30 34 2E 38 35 30 2E 31 30 34 2E 35 33 35 31 4E 5F 63 68 65 6E 67 7A 70 32 30 32 30 31 32 30 34 2E 62 69 6E 40 31 39 32 2E 31 36 38 2E 31 2E 31 31 3A 31 30 30 36 39 fe 55 aa ef

Step3.將裝置升級為1.05版本。
1.05版本指令
f0 aa 55 0f 85 60 00 a4 c2 ab 78 20 34 01 4C 44 2D 52 44 5F 49 50 44 43 55 38 35 30 5F 41 70 70 6D 64 5F 31 2E 30 35 2E 38 35 30 2E 31 32 30 2E 35 33 35 31 4E 5F 63 68 65 6E 67 7A 70 32 30 32 30 31 32 30 32 2E 62 69 6E 40 31 39 32 2E 31 36 38 2E 31 2E 31 31 3A 31 30 30 36 39 fe 55 aa ef

綜上，升級功能單臺裝置測試成功。

八、網頁原型圖設計

此部分功能本來應使用Axure工具設計升級部分web互動的動態原型圖。但是在另一個OMC平臺已經設計過此模組，前端同事對此比較熟悉。故此處用升級的網頁截圖代替原型圖部分，以作展示。

1.叢集管理

1.1 在裝置基礎上點選或者多選新增叢集

1.2 根據硬體版本或者軟體版本或者區域編碼（區域中文名稱）來建立叢集

區域編碼需要支援直接編碼輸入與中文輸入兩種方式來建立叢集。支援增刪查。

2.升級任務管理

2.1 上傳升級檔案

2.2 選擇升級叢集

2.3 選擇升級時間段

2.4 輸入升級策略

即輸入升級延時時間。為一個時間段，單位分鐘。

2.5 輸入管理員密碼以確認升級任務

2.6 確認之後的升級任務

3.升級日誌管理

備註：升級日誌中的狀態可刪除。

---

版權宣告：本文為博主原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處連結和本宣告。 本文連結：https://www.cnblogs.com/JerryMouseLi/p/14148272.html