3 服務(wù)器端的軟件設(shè)計
3．1 升級文件傳輸?shù)臄?shù)據(jù)格式
    為了達到快速準確升級的目的，首先對原始的升級代碼(Intel Hex文件)進行打包，然后加人相應(yīng)的數(shù)據(jù)包ID號和校驗碼，并定義數(shù)據(jù)包長度≤256個字節(jié)，以適應(yīng)G：PRS通信方式對數(shù)據(jù)包長度的要求，避免出現(xiàn)頻繁掉線和發(fā)送不出去的問題。具體的數(shù)據(jù)包格式如下：數(shù)據(jù)包格式：PacklD+起始地址+長度+數(shù)據(jù)+校驗碼；PackID：一個完整的數(shù)據(jù)包為一個記錄，下一個數(shù)據(jù)包的記錄號自動加1；起始地址：燒寫數(shù)據(jù)的FLASH首地址。即數(shù)據(jù)部分中包含的第一條數(shù)據(jù)的記錄地址+線性擴展地址；長度：該包數(shù)據(jù)部分的字節(jié)數(shù)；數(shù)據(jù)：同一個擴展線性地址記錄內(nèi)且地址連續(xù)的數(shù)據(jù)記錄的數(shù)據(jù)域。當(dāng)讀到一個擴展線性地址記錄號后，將此擴展線性地址記錄號內(nèi)的數(shù)據(jù)區(qū)域打包成256個字節(jié)之內(nèi)的數(shù)據(jù)包，超過256個字節(jié)或讀到下一個擴展線性記錄號時則另起一個新的數(shù)據(jù)包；校驗碼：CRC循環(huán)冗余校驗碼。
3．2 服務(wù)器端主要程序流程
    服務(wù)器端主要程序流程圖如圖4和圖5所示。服務(wù)器先把升級文件的路徑配置完畢，并將要升級的目標程序代碼按照第3．1節(jié)所示的數(shù)據(jù)包格式進行打包。并對每個數(shù)據(jù)包進行編號。

    接著如圖4所示，服務(wù)器發(fā)送升級指令，并通過GPRS網(wǎng)絡(luò)透明傳輸?shù)竭h程終端。如果當(dāng)前運行的用戶程序代碼在1區(qū)，則將2區(qū)升級數(shù)據(jù)發(fā)送給遠程終端，否則將2區(qū)升級數(shù)據(jù)發(fā)送給遠程終端。由于地形和環(huán)境因素的影響，GPRS網(wǎng)絡(luò)在遠程通信過程中可能出現(xiàn)阻塞或斷開的情況。
    如果服務(wù)器在一定的時間內(nèi)沒有收到遠程終端的應(yīng)答信號，則重發(fā)，如果三次重發(fā)失敗則保存成功接收到的數(shù)據(jù)塊ID號和數(shù)據(jù)校驗碼，進入斷點續(xù)傳。升級文件傳輸完畢則發(fā)送跳轉(zhuǎn)指令，使遠程終端執(zhí)行新的程序代碼。
3．3 服務(wù)器端西己置表
    服務(wù)器端升級配置表中重要字段的配置如下：
    這些字段將服務(wù)器和遠程終端緊密地聯(lián)系起來，使得編程思路更加清晰，Update ID標志了用戶程序目前所在存儲區(qū)；Update User Zone為升級做好文件配置準備工作，LastOrder為斷點續(xù)傳做好準備，保證整個程序的緊密性以及可靠性。

4 結(jié) 語
    該方案采用應(yīng)答機制、斷點續(xù)傳、CRC校驗等技術(shù)，充分利用ARM芯片內(nèi)部FLASH存儲器資源，通過GPRS網(wǎng)絡(luò)，實現(xiàn)對ARM嵌入式終端的系統(tǒng)軟件進行遠程在線升級，解決了大型分布式監(jiān)控系統(tǒng)遠程嵌入式終端系統(tǒng)軟件的在線升級和維護問題。該方案已經(jīng)成功地應(yīng)用在南京航道局的航標自動監(jiān)測系統(tǒng)中，該系統(tǒng)有600多盞安裝有嵌入式終端的航標燈，對該系統(tǒng)進行在線升級僅耗時20 min，且一次性升級成功。實踐證明，該方案的實施可有效降低工程復(fù)雜度，縮短升級時間，節(jié)約升級、維護成本，同時具有升級成功率高和升級速度快的特點。