目錄
物聯網産品設計中的裝置更新功能
一、背景
二、固件更新對裝置的重要性
三、遠端固件更新整體架構圖
四、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更新顯得尤其重要，主要展現在以下幾方面：
市場端的快速上線需求
天下武功唯快不破，物聯網裝置産品往往留給設計者的時間不長，并且市場需要持續不斷地創新和更新功能。在裝置設計時，往往會預留一些後加載的需求，先期快速實作一些功能即開始上線，上線後可以通過線上更新的方式更新更多功能，實作漸進式部署，有那麼一點類似于網際網路的靈活研發了。隻要在架構設計階段，在硬體層面考慮到了未來的足夠需求，就不可以源源不斷地優化完善裝置功能。
裝置部署需求的多樣性
在物聯網産品應用過程中，裝置需要确定推送資訊的雲主機。那麼問題就來了，有可能是一個通用的雲主機，也有可能因為部署需要又需要更新推送的雲主機，這個時候如果裝置已經生産出來了，已經在管道或者客戶手中，那麼遠端固件更新就顯得很重要了。
還有一個比較常見的現象，一些裝置在安裝以後，對于輸入輸出部件的控制模式需要變更，那麼可能需要對部分裝置進行固件更新。比如，一開始在一個城市部署了相同智能路燈的裝置，但是某些區域的裝置關于燈光強度或者時間性需要做變更，那麼遠端固件更新也可以幫助解決燈光控制方式的變更。
備注：如果預留了遠端下行控制指令，且已經支援的，也可以不用更新固件。
裝置安全性及完善性
任何物聯網裝置不外乎都是兩部分組成的：硬體+固件程式。在基于SoC的應用中，遠端固件更新功能不僅能夠更新固件，而且還能重新配置片上硬體資源。
有了遠端固件更新的備案，那麼産品不一定等到完全沒有缺陷再上市，隻要在不存在較為緻命的缺陷下，就可以提前上市，解決問題後在遠端完成更新修補缺陷。同時基于日益嚴峻的安全形勢威脅，備固件可通過遠端固件更新流程獲得最新更新檔和更多安全算法，做到不斷加強的。
本應用的更新服務采用TFTP協定 RFC1350 中文,并且用到了TFTP(RFC2347)，用來支援OACK包格式，可選項應答，支援-tsize選項(RFC2349)。TFTP (Trivial File Transfer Protocol, 簡單檔案傳輸協定也稱小型檔案傳輸協定)。預設基于UDP方式進行實作，但是本應用采用TCP方式進行實作，原因是如果是無線（如4G）組網，UDP無法找到裝置，而TCP基于長連接配接，隻要不釋放連接配接，平台能找到内網中的裝置，裝置需要先連接配接公網平台。
模式名稱
模式含義
說明
netascii
文本傳輸模式，按照一個位元組8位解析
文本模式
octet
二進制模式，資料無需解析
二進制模式
已過時，不使用
已過時
本應用使用octet模式。
TFTP共定義了五種類型的包格式，格式的區分由包資料前兩個位元組的Opcode字段區分，分别是：
opcode operation:
Read request (RRQ)
Write request (WRQ)
Data (DATA)
Acknowledgment (ACK)
Error (ERROR)
即：
讀檔案請求包：Read request，簡寫為RRQ，對應Opcode字段值為1
寫檔案請求包：Write requst，簡寫為WRQ，對應Opcode字段值為2
檔案資料包：Data，簡寫為DATA，對應Opcode字段值為3
回應包：Acknowledgement，簡寫為ACK，對應Opcode字段值為4
錯誤資訊包：Error，簡寫為ERROR，對應Opcode字段值為5
tsize選項：
當讀操作時，tsize選項的參數必須為“0”，伺服器會傳回待讀取的檔案的大小
當寫操作時，tsize選項參數應為待寫入檔案的大小，伺服器會回顯該選項
blksize選項：
修改傳輸檔案時使用的資料塊的大小（範圍：4~65464）
timeout選項：
修改預設的資料傳輸逾時時間（機關：秒）
傳輸效率低
對于逾時機制沒有明确說明
每包長度固定為512位元組，不靈活
隻能是用戶端發送讀寫請求，讀寫請求資料包中可能附帶選項資訊。在讀寫請求資料包中可能有很多個選項，但一個選項隻能出現一次。選項出現的順序并不重要。
當用戶端向伺服器發送帶選項的讀請求資料包，伺服器可能傳回三種響應：
OACK：應答讀請求和選項
DATA：應答讀請求，無選項
ERROR：請求被拒絕
當用戶端向伺服器發送帶選項的寫請求資料包，伺服器可能傳回三種響應：
OACK：應答寫請求和選項
ACK：應答寫請求，無選項
備注：4，5步驟，結束包分兩種情況：1.如果檔案位元組不是512的整數倍，裝置端則收到不足512位元組的包之後，響應ACK，服務端關閉socket；2.如果傳輸檔案剛好是512位元組的整數倍，則最後一個有效包傳輸完成之後，裝置端會傳回兩個ACK。接收到第二個ACK，服務端發空包，ACK傳回有效包号+1，服務端關閉socket。
更新指令及其回應相見《LD_RD_IPDCU800管控協定格式說明書v0.0.12_chengzp20190529》1.4.5
存于Redis中，
ip位址以逗号隔開的集合的字元串，例如："192.168.1.2,192.168.2.3"；
叢集名稱；
裝置總數；
使用者ID（用來做權限）；
key：叢集名稱；
使用增删改查方式；
裝置名稱；裝置IP；
執行時間；DateTime類型；
執行政策：DateTime類型；延時時間；
檔案名稱：string類型
叢集ID；
使用者ID
key：GUID；
增删查
裝置名稱，IP 位址，更新結果，更新時間
儲存到mysql資料庫，自增ID為主鍵；
查
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平台已經設計過此子產品，前端同僚對此比較熟悉。故此處用更新的網頁截圖代替原型圖部分，以作展示。
區域編碼需要支援直接編碼輸入與中文輸入兩種方式來建立叢集。支援增删查。
即輸入更新延時時間。為一個時間段，機關分鐘。
備注：更新日志中的狀态可删除。
版權聲明：本文為部落客原創文章，遵循 CC 4.0 BY-SA 版權協定，轉載請附上原文出處連結和本聲明。 本文連結：https://www.cnblogs.com/JerryMouseLi/p/14148272.html
The Sky is the limit.