-----軟件升級流程-----
軟件（Software）一般分為系統軟件和應用軟件，系統軟件實現設備最基本的功能，比如編譯工具、系統文件管理等；應用軟件可以根據設備的特點，提供不同的功能，比如采集數據、數據分析處理等。
軟件升級又稱為SOTA（SoftWare Over The Air），是指用戶可以通過OTA的方式支持對LWM2M協議的設備進行軟件升級。軟件升級遵循的協議為PCP協議，設備側需要遵循PCP協議進行軟件升級的適配開發。SOTA流程如下圖所示：
SOTA升級流程的詳細說明：
1～2. 用戶在設備管理服務的控制台上傳軟件包，並在控制台或者應用服務器上創建軟件升級任務。
3. NB-IoT設備上報數據，平台感知設備上線，觸發升級協商流程。
4～5. 物聯網平台向設備下發查詢設備軟件版本的命令，查詢成功后，物聯網平台根據升級的目標版本判斷設備是否需要升級。
-
如果返回的軟件版本信息與升級的目標版本信息相同，則升級流程結束，不做升級處理。
-
如果返回的軟件版本信息與升級的目標版本信息不同，則繼續進行下一步的升級處理。
6. 物聯網平台向設備訂閱軟件升級的狀態。
7～8. 物聯網平台查詢終端設備所在的無線信號覆蓋情況，獲取小區ID、RSRP（Reference Signal Received Power，參考信號接收功率）和SINR（Signal to Interference Plus Noise Ratio，信號干擾噪聲比）信息。
-
查詢成功：則根據如下方式計算可同時升級的並發數計算，並按照步驟10進行處理。
-
如下圖所示，如果設備的RSRP強度和SINR強度均落在等級“0”中，則同時可以對該小區的50個相同信號覆蓋區間的設備進行同時升級。
-
如果設備的RSRP強度和SINR強度分別落在等級“0”和“1”中，則以信號較弱的等級“1”為准，則只能同時對該小區的10個設備進行升級。
-
如果設備的RSRP強度和SINR強度分別落在等級“1”和“2”中，則以信號較弱的等級“2”為准，則只能同時對該小區的1個設備進行升級。
如果設備的RSRP強度和SINR強度不在該3個等級范圍內，且均可以查詢到，則按照信號最弱覆蓋等級“2”處理，則只能同時對1個設備進行升級。
注：如果用戶在軟件升級中發現同時進行升級的設備數較少，則可以聯系當地運營商檢查和優化設備所在小區的無線覆蓋情況。
-
-
查詢失敗：則按照步驟9進行處理。
9. 物聯網平台繼續下發查詢小區ID信息的命令，獲取終端設備所在的小區ID信息。
-
如果查詢成功：物聯網平台支持同時對該小區的10個相同情況的設備進行軟件升級。
-
如果查詢失敗：則升級失敗。
10～12. 物聯網平台通知設備有新的軟件包版本，設備啟動軟件包的下載。軟件包的下載按照分片的方式進行下載，支持斷點續傳功能，通過軟件包分片中攜帶的“versionCheckCode”確定是否屬於同一個軟件包。下載完成后，設備知會物聯網平台軟件包已下載完畢。
13～14. 物聯網平台向設備下發升級的命令，終端設備進行升級操作，升級完成后終端設備向物聯網平台反饋升級的結果。
15. 物聯網平台向控制台/應用服務器通知升級的結果。
-----軟件升級版本包結構------
設備升級的軟件包文件由各設備廠商提供，在物聯網平台上傳設備的軟件升級包前，需要制作軟件升級的版本包，用於修改軟件包的描述文件，如軟件版本、廠商名稱、設備類型、產品模型等信息。下面將詳細介紹版本包的制作方法。
-
新建文件夾命名為“DM”，在DM文件夾下新建文件夾，命名為“linux”。
-
使用Notepad++文本工具新建一個文本文件，拷貝如下內容到文本中，在Notepad++工具的“編碼”菜單中選擇“以UTF-8無BOM格式編碼”，然后將文本進行存儲，存儲路徑選擇步驟1中的“linux”文件夾，文件名稱命名為“UpgradeDesc”，保存類型選擇“.json”。
{
"specVersion": "",
"fileName": "",
"packageType": "",
"version": "",
"deviceType": "",
"manufacturerName": "",
"model": "",
"protocolType":"",
"description":"",
"versionCheckCode":"",
"deviceShard":"",
"platform":"",
"supportSourceVersionList":[],
"date":""
}
打開創建的“UpgradeDesc.json”文件，修改軟件升級描述文件，相關字段如下表所示。
-
在與“DM”同級目錄下創建文件夾，命名為“linux”，該文件夾名稱必須同步驟1中的文件夾命令保持一致，將廠商軟件包（軟件包格式無限制）置於該文件中。
-
選中“DM”和“linux”文件夾，使用壓縮工具打包成ZIP格式的壓縮包，建議命令為“xx_package.zip”。
注：
-
文件“DM”和“linux”的命名是固定的。
-
“xx_package.zip”下不能包含package這層目錄。
-
僅支持ZIP格式的壓縮包，不能壓縮成其他格式后，例如rar，再手動修改文件類型為zip。
-----設備側適配開發概述------
設備的OTA軟件升級是基於華為定義的PCP協議進行的，設備側需根據PCP協議定義的交互流程進行適配開發。下面我們將結合物聯網平台與設備的軟件升級交互流程，介紹終端設備將如何基於PCP協議構建交互過程中的請求消息和應答消息，幫助您更好的根據PCP協議進行終端側的軟件升級功能開發。
下面我們先了解下PCP消息的結構，PCP協議的請求消息和應答消息都遵循相同的消息結構，主要由這幾部分組成：
PCP協議消息由：起始標識位、版本號、消息碼、校驗碼、數據區長度和數據區組成，各字段的要求和描述如下表所示。
物聯網平台發送消息接下來讓我們以查詢設備版本號為例看下平台與設備交互消息的結構。
根據PCP消息結構的定義可以得出，物聯網平台向設備下發查詢版本號時，各消息字段的填寫如下：
-
起始標識：固定為消息流的前2個字節，固定為FFFE。
-
版本號：數據類型為1個字節整數，且固定為1，即在消息流中為01。
-
消息碼：數據類型為1個字節整數，查詢設備版本的消息碼為19，轉換為十六進制為13。
-
校驗碼：數據類型為2個字節整數，先將校驗碼置為0000，然后將完整的消息碼流進行CRC16的算法計算得到校驗碼，再將得到的校驗碼替換原消息中的0000。
-
數據區長度：數據類型為2個字節整數，代表數據區的消息長度，根據數據區的數據結構可以得出該條消息無數據區，即數據區長度為0000。
-
數據區：數據區代表要真正發送給設備的數據，根據查詢版本信息的數據區定義，該條消息是沒有實際要傳送的數據的，即無需數據區字段。
因此將查詢版本消息的碼流組合起來得到：FFFE 01 13 0000 0000。前面的校驗碼時講了，需要將組合后的消息碼流進行CRC16算法得到校驗碼4C9A，然后將該校驗碼替換原碼流中的0000后得到FFFE01134C9A0000，該消息碼流即為物聯網平台發送給設備的查詢版本信息的消息碼流。
設備返回的應答消息
設備收到物聯網平台要查詢設備的軟件版本號消息，設備要向物聯網平台反饋查詢的結果，各消息字段的填寫如下。
-
起始標識固定為：FFFE。
-
版本號固定為：01。
-
消息碼：與請求的消息碼一致，為13。
-
校驗碼：CRC16計算前先用0000替代。
-
數據區長度：根據數據區的字段的數據類型得出數據區長度為17個字節，轉換為十六進制為：0011。
-
數據區：根據數據區的定義可知，處理成功的結果碼為00，版本號信息假設為V0.9，將V0.9進行ASCII轉碼得到56302E39，由於版本號的數據類型為BYTE[16]，即16個字節，當前只有4個字節，因此需要在版本號數據后面補0，得到56302E39000000000000000000000000。因此，數據區合並后為0056302E39000000000000000000000000。
將查詢版本信息的消息流組合起來得到：FFFE 01 13 0000 0011 0056302E39000000000000000000000000。前面講到，還要將消息流進行CRC16算法計算得到校驗碼為8DE3。因此，物聯網平台向設備查詢版本號信息，設備向平台返回的消息流為FFFE01138DE300110056302E39000000000000000000000000。
設備升級期間，物聯網平台和設備交互的其他消息也都遵循PCP協議，此處不再詳細介紹。
看完本文后，您是否對設備軟件升級有了更勝的了解呢？如果您想進一步了解設備軟件升級的原理和操作，可以訪問設備管理服務的幫助中心。
關於華為物聯網可參加學習免費課程視>>>>>《IoT七天開發訓練營》或聯系華為IoT小助手（微信號：huawei-iot）獲取更多課程。