????????雙星定位系統是我國自主開發的定位導航系統，它的用戶手持終端對實時性要求高，考慮到價格以及開發周期的因素，用戶機系統軟件的開發選用了具有國內自主知識產權的DeltaOS.

　　本系統的系統軟件在DeltaCORE內核上構建，選擇采用C語言編寫，來提高軟件的執行效率和可讀性;圖形界面基于DeltaGUI設計，采用C++編寫，以縮短開發周期。該系統軟件設計的重點在于穩定性和可靠性，關鍵和難點在于實時性的保證。作為一個完善的系統，軟件功能的可擴展性也是必不可少的。本文從總體設計入手，針對性地解決了以上問題。

　　1 系統功能

　　雙星用戶機是一個定位和通信終端，它除了必須完成定位、通信功能外，還需要有友善的人機交互界面以及測試設備接口。嵌入式系統和外設之間的關系如圖1所示。

?

　　嵌入式系統的硬件平臺是通用性的平臺，算法實現和設備各部分的協調控制都由嵌入式軟件來實現。軟件部分需要完成的具體功能有：界面輸入輸出控制、入站數據段打包、入站信息加密、入站幀打包、出站幀拆包、出站信息解密和提供測試接口。

　　2 提高系統的實時性

　　2.1 任務劃分的優化

　　在設計一個較為復雜的多任務應用時，進行的合理的任務劃分對系統的運行效率、實時性和吞吐量影響極大。任務分解過細會引起任務頻繁切換的開銷增加，而任務分解不夠徹底會造成原本可以并行的操作只能按順序串行完成，從而減少了系統的吞吐量。

　　在將一個軟件系統分解成并行任務時，主要需考慮的是系統功能的異步性。分析數據流圖中的變換，確定哪些變換可以并行，哪些變換在本質上是順序的，通過這種方法，劃分出任務：一個變換對應一個任務，或者一個任務包括幾個變換。一個變換是應該成為一個獨立的任務，還是應該和其他變換一起組成一個任務，本軟件中遵循了H-Gomma原則[1]，即：

　　①I/O依賴性原則

　　②時間關鍵性原則

　　③大計算量原則

　　④功能內聚

　　⑤時間內聚

　　⑥周期性原則

　　本系統的軟件分為應用軟件和系統軟件兩大部份。應用軟件部分位于系統軟件上層，它完成圖形界面的輸入及顯示功能。應用軟件部分具有處理時間長、實時性要求不高和不存在并行性的特點，因此作為一個GUI任務并且賦予最低優先級。系統軟件需要完成所有出入站信息處理，處理過程復雜，實時性要求高，順序處理顯然不能滿足要求，因此必須進行任務劃分優化。

　　圖2為入站信息處理的數據流圖，圖3位出站信息處理的數據流圖。

　　根據I/O依賴性原則，直接和I/O設備打交道的功能都應該成為獨立的任務，因為它的運行速度受制于與它交互的I/O設備的速度。在入站流程中，向IC卡發指令、接收IC卡響應信息和送入站數據幀至基帶均存在I/O操作，應該獨立劃分為一個任務。同理，出站信息處理過程中的主通道數據讀取、次通道數據讀取、向IC卡發指令和接收IC卡響應信息分別劃分為獨立的任務。

?

　　圖2 入站信息處理數據流圖

?

　　圖3 出站信息處理數據流圖

　　根據功能內聚原則，功能緊密相關的變換組成一個任務，它們共享資源或相同事件的驅動。定位數據段打包和通信數據段打包具有相似功能，它們均由有效輸入的指令觸發，可以合并為一個數據段打包任務，針對不同類別的請求使用不同的功能模塊來處理。這樣，當系統需要增加新的功能時只需在該任務中增加相應的處理模塊即可，可擴展性得到了保證。

　　根據時間內聚原則，同一時間內完成的功能，即使這些功能不相關也可組成一個任務。數據段的打包在輸入指令解釋完成之后立即被處理，在時間上具有連續性，合并成一個任務可以減少任務間通信開銷，有利于提高系統實時性。

　　主通道數據幀拆包、次通道數據幀拆包和入站數據幀打包的運算量大，適合作為獨立的任務。然而，主通道和次通道出站數據幀格式相同，完全可以共用一個任務：出站幀數據拆包。

　　雖然加密指令打包和解密指令打包分別處于入站信息處理流程和出站信息處理流程，但是它們同屬IC卡指令打包，具有很強的功能內聚性，合并為一個任務共用IC卡驅動。

　　任務重新劃分如圖4所示。優化之后，不但系統軟件實時性和可擴展性得到增強，而且由于充分的代碼重用，代碼尺寸減小，節省存儲空間。

?

　　圖4 優化后的出入站任務劃分和數據流圖

　　2.2 中斷優化

　　任務的切換是由操作系統來調度的，操作系統的干預會浪費CPU時間。特別是對于時間關鍵性很強任務，例如基帶主通道數據讀取、次通道數據讀取、向IC卡發指令、接收IC卡相應信息任務，頻繁的任務調度會使系統的效率低下。因此，這些處理直接由中斷服務子程序來完成。

　　雖然中斷服務響應速度快，但是當一個中斷服務執行時，其它同優先級或較低優先級的中斷以及任意優先級的任務均得不到執行。因此如果中斷服務所占用的時間過長，同樣會降低系統的實時性。

　　為了提高系統的實時性，本系統軟件在中斷處理上主要做了以下兩方面的優化：

　　①中斷優先級設置的優化，將觸發頻率高的中斷和重要的中斷設為高優先級來保證其及時響應。

　　②關中斷時間應該盡可能地小，ISRs只完成一些必要的操作，如：輸入數據、輸出數據或將控制信息傳遞給任務，對中斷的進一步處理通過任務來完成[2]。

　　3 可靠性保證和可擴展性的提高

　　對于任何軟件來說，可靠性都是至關重要的。軟件的可靠性在任務內是容易做到，通常問題都是出在任務間的接口之上。接口設計也關系到軟件可擴展性能。在多任務操作系統中，任務間的接口是通過同步和通信機制來實現的，因此同步和通信機制必須認真選取。

　　DeltaCORE提供了消息隊列(message queue)、信號量(semaphore)、異步信號(signal)、事件(event)這四種通信和同步機制。其中，消息隊列和事件機制可以同時實現通信和同步，信號量機制可以實現同步和互斥，異步信號(又叫軟中斷機制)可以實現同步。

　　為了滿足系統通信和同步的需要，可以采用兩種方案：第一種方案是信號量等同步機制實現同步，用全局數組或其他的共享數據結構來實現各任務間的通信，如圖5;另一種是采用消息隊列來同時實現通信和同步，如圖6。

?

　　對比兩種方案，各有優缺點：方案一實時性強，但存在可重入性問題;方案二實現簡單而且可靠，但是消息隊列機制通信的實時性相對較弱。本系統中出站信息的突發性強，如果采用方案一，則可能導致第二個通道的數據失效或者第一個通道的數據被覆蓋;如果采用方案二雖然數據的處理延時稍大，但是數據能夠完整存儲到消息隊列中不被損壞。此外，利用消息隊列為任務提供唯一的入口，能簡化接口設計和方便功能擴展。因此，本文采用消息隊列方案，其實現方法如下：

　　每個任務都對應一個消息隊列，任務只處理與之相對應的消息隊列中的消息。對于發送方(task1)，當它需要將發送緩沖區buffer中的數據交給task2處理時，只須將buffer中的數據發送到與task2對應的消息隊列Q2中就行了。

　　ret = delta_message_queue_send ( Queue_id[ 2 ], buffer, size );

　　其中Queue_id[2]為消息隊列Q2的ID，size為消息大小(單位字節)。

　　對于接收方(task2)，將接收消息函數的等待時間參數設為永久等待，達到當消息隊列為空時阻塞任務的目的。task2的代碼如下：

　　delta_task task1()

　　{

　　delta_status_code ret;

　　…… // 定義其他局部變量

　　while(1)

　　{

　　ret = delta_message_queue_receive(

　　Queue_id[ 2 ], /*消息隊列ID*/

　　RecBuff, /*指向接收緩沖區的指針*/

　　&size,/*接收消息的尺寸(單位字節)*/

　　DELTA_DEFAULT_OPTIONS, /*屬性集*/

　　DELTA_NO_TIMEOUT /*等待時間*/

　　);

　　…… //完成task1功能的代碼

　　}

　　}

　　通過這種方式，任務與任務之間、任務與中斷之間的通信和同步都得以實現。任務的狀態轉換如圖7：

　　4 致命錯誤的防止和解決

　　通常異常是由兩種情況引起的：一種是數組越界或使用指針不當;另一種是任務棧溢出。為避免以上情況發生，數組和任務棧的大小必須設置恰當，修改數組元素的時候要保證下標是在合法范圍內的，使用指針要特別小心。不過，DeltaOS提供了異常處理機制，用戶可以編寫自己的擴展例程，當出現致命錯誤的時候實行一定的挽救措施，比如復位程序整個系統軟件或者重新起動指定任務。

　　DeltaOS是一個強實時性的操作系統，通過優化任務劃分、有效的利用中斷機制滿足了系統的強實時要求。利用本文提出的通信和同步方案，實現了任務的標準化接口，方便地進行了多次功能擴展，并且顯示了它可靠性強的優點。