boa嵌入式應用

引言
數字化變電站是建立在網路通訊技術和電子技術基礎上的一種新型變電站自動化系統，其中一個重要特徵就是二次裝置的網路化。目前在國內的數字化變電站試驗中，已經出現了大批支援乙太網路和TCP／IP協議的嵌入式IED，在具體開發和應用中發現，由於現場環境的複雜多變以及客戶需求的多樣性，經常需要對這些IED進行參數的配置和修改。但廠家多採用專門的配置軟體來進行，操作介面不夠統一，給現場操作帶來諸多不便。而採用Web伺服器技術，則只需要瀏覽器便可實現對IED參數的線上修改與配置，從而極大地方便了對裝置的維護和管理。目前，Web伺服器功能在數字化變電站中，多用於調度與監控端設計，單純在IED上實現Web伺服器功能的報道尚不多見。本文通過對Linux平台上啟動並執行BoA
Web伺服器和CGIC的研究，將原本兩個獨立啟動並執行程式整合為多任務系統中的一個任務實體，並對其進行相應的精簡和修改；設計並實現了一種可在一般嵌入式系統上啟動並執行，既相對簡單又響應快速的嵌入式Web伺服器。目前已在相關裝置上得到應用，取得了較好的使用效果。
BOA和CGIC是兩個基於Linux的開源軟體，代碼採用C語言實現，程式小巧靈活、執行高效，非常適合於嵌入式系統的應用環境。但目前多用於Linux或μClinux的系統平台上。鮮見有用於其他系統的相關報道。
其中BOA是一個單任務的HTTP伺服器，它的設計目標主要是速度和安全。因此，它不像傳統的Web伺服器，為每個訪問串連單獨開啟一個進程，也不會為處理多個串連而開啟多個自身的拷貝。BOA對所有活動的HTTP在內部進行串連處理，只為每個CGI串連啟動新的進程，在同等硬體下相比其他伺服器具有更快的訪問速度。而CGIC是一個為支援通用閘道介面CGI(Common GatewayInterface)而開發的C語言庫，通常和BOA聯合使用，它可接收由瀏覽器通過GET或POST方法傳輸過來的表單及檔案資料，並提供了對這些資料進行解析的方法，使用非常方便，且源碼也易通過網際網路獲得。
基於以上原因，本文主要基於這兩種技術來實現IED裝置內部的嵌入式web伺服器功能。

1 系統概述
嵌入式Web伺服器EWS(Embedded Web Server)是指將Web伺服器引入到現場測試和控制裝置中，在相應的硬體平台和軟體系統的支援下，使傳統的測試和控制裝置轉變為具備了以TCP／IP為底層通訊協定，Web技術為核心的基於互連網的網路測試和控制裝置。其中，Web瀏覽器和EWS的互動過程1所示。

首先由Web瀏覽器發出HTTP請求報文，並建立TCP串連，然後由EWS根據其請求報文來提供相應的狀態和頁面資訊，若只是請求靜態頁面，則無需通過CGI，直接返回該對應頁面即可；反之則需要通過CGI來進行相關報文資料的解析，並根據解析結果來產生動態網頁面以返回給用戶端瀏覽器。這樣，完成一次互動過程後，即可釋放該TCP串連。
本文的設計目標是將Web伺服器的功能僅作為DSP／BROS中的一個任務，只在監聽到HTTP協議對應連接埠(通常為80)上的TCP串連請求時，才運行該任務。但是傳統的BOA並沒有對使用者存取權限的控制對頁面的管理也依賴於Linux系統，因此，結合變電站啟動並執行特殊性，本文所設計的EWS系統結構框圖2所示。

系統運行時，由HTTP串連管理模組負責對網路連接埠進行監聽，當監聽到有串連請求到達後，即進入HTTP報文解析模組進行處理，如果解析錯誤，則直接返回HTTP串連管理模組，發出相應的響應報文並關閉該串連；否則，則根據對報文解析的結果，提取出本次要訪問的URL，並將其交給存取權限管理模組，以查看該用戶端是否具有足夠的許可權；然後再轉由頁面文件管理模組進行處理，根據對報文的初步解析以及對存取權限的判斷，由頁面文件管理模組來決定是否調用CGI，以實現檔案的下載上傳及響應文檔的產生，從而將正確的響應報文及頁面文檔轉交給HTTP串連管理模組進行網路資料的應答回送。

2 功能實現
2．1 HTTP串連管理的功能實現
所謂HTTP串連管理，主要是指對串連到伺服器連接埠的socket進行監聽、捕獲、讀寫、關閉，以及對HTTP請求報文協議欄位的解析和響應報文的產生等操作。其中，BOA可提供完整的HTTP協議資料解析及響應報文產生的功能。因此，對和HTTP串連管理中相關的操作，基本上可直接採用BOA的相關代碼，實現起來難度不大。
BOA中的串連狀態切換3所示。

當程式每次監聽到新的socket串連訪問接入時，首先對空閑隊列進行判斷，如果為空白，則申請一個request結構空間，並將其插入就緒隊列的隊頭，否則可直接將一個結構空間從空閑隊列轉入；對當前正在處理的就緒隊列成員，當網路阻塞時則將其移入阻塞隊列的隊頭，當訪問結束中斷連線時，則將該成員的空間資訊移入空閑隊列；而當對阻塞隊列進行輪詢時，根據其成員所對應的socket上是有讀寫請求還是該串連已逾時，分別將其移入就緒隊列或中斷連線移入空閑隊列。
以上過程在BOA中主要是通過get_request、fdset_update和process_requests這三個函數來實現的，它們也是實現移植的重點，其他函數則相對簡單。在移植過程中，為了適應嵌入式的應用環境，在系統初始化時，給空閑隊列分配了足夠大的隊列空間，並對操作時所涉及的一些動態記憶體分配的語句和結構進行修改，從而盡量減少串連過程中頻繁的記憶體申請。另外，傳統的BOA對每個CGI串連啟動新的任務，在此考慮到配置資料的即時生效以及系統資源的節約，仍然在EWS的任務環境中處理該CGI串連。實驗證明，這種處理方法簡單可行，而且在裝置的應用環境中對伺服器的效能並無太大影響。
2．2 存取權限管理的功能實現
為了應用時操作的安全性，本文將訪問的頁面分成兩類：一類為配置操作頁面，儀供認證使用者訪問；另一類為裝置狀態頁面，可供任何使用者訪問。其控制主要是通過對使用者IP的判別及訪問頁面的分類來實現的。首先對使用者訪問的URL進行解析，如果訪問對象為配置操作頁面，則需要進行認證，在此通過一個使用者權限控制管理結構來對通過許可權認證的使用者進行維護，並提供一個時間摔制機制，使通過認證的使用者在一定時間段內可持續有效對伺服器進行訪問。如果當前用戶端(訪問者IP)在使用者權限控制結構內，且未逾時，則通過認證，由伺服器根據本次申請的URL返回相應頁面；若逾時則需要對本次訪問的URL進行複位向，返回密碼校正頁面，給使用者提供密碼輸入的介面。如果訪問頁面為裝置狀態頁面，則無需進行認證，直接由URL返回相應頁面即可。存取權限認證程式流程4所示。

通過以上過程的處理，即可實現對存取權限的控制與管理。
2．3 頁面文件管理及產生的功能實現
由於配置環境的需要，設計頁面較多，如果將所有頁面均儲存在Flash上，檔案讀寫的問題將更為突出。為此，本文設計了一個5所示的網頁分頁檔管理結構來對分頁檔進行管理。

下面介紹具體處理過程。
首先，對所有頁面無論是靜態還是動態網頁面，均建立一個對應的模板檔案，並將該模板檔案的內容以全域靜態字串的形式直接寫在程式中。在系統初始化時對各模板內容的大小進行統計，並按下式對各檔案的最大容量進行粗略的估算：
mS=sizeof(pT)×1．2
其中：mS為估算的頁面內容最大尺寸，sizeof(pT)則為該頁面對應模板的實際大小(以上兩者均以位元組為單位)。
按上式估算出頁面的最大尺寸後，為保證對頁面分配記憶體時空間的連續性，根據所有頁面的最大尺寸和，一次性分配一個較大的記憶體空間，並將該空間按各個頁面所對應的最大尺寸依次與該頁面對應的管理結構內的檔案內容指標相關聯。這樣，每次因配置的修改導致頁面內容發生變化時，僅需對該指標所指向的空間內容進行修改即可，而僅在儲存配置資料時，通過設定檔更新函數將其儲存在Flash中。這樣既避免了為修改分頁檔內容而申請記憶體的操作，又避免了為儲存頁面內容而頻繁進行的Flash讀寫操作，從而提高了該EWS的效率。

對於EWS中動態網頁面的產生則要經過動態資料解析以及解析資料的模板頁面回填這兩個過程。在通常的Web互動中，大量動態資料是通過表單的形式體現在html頁面設計之中的。而一般上送的表單資料(檔案上傳除外)在GET和POST兩種方法下，除了在HTTP請求報文中小現位置的不同外(GET方法下位於請求行，POST方法下位於實體主體部分)，其組織形式並無差別，如下所示：
e_1-v 1＆e 2=v 2…＆e N=v N
其中e_N代表表單資料中的元素名，v_N代表該元素的取值。
因此，當串連管理模組從請求報文中提取出表單資料後，即可對這兩種方法下的提交資料採用相同的解析方法。CGIC採用以下方法來實現其解析過程。
首先，通過對表單資料字串的節點分析，用一個單向鏈表來對表單資料中的每個元素進行維護，在鏈表成員中包括了對元素名及其值的管理，並針對不同的元素類型提供了一系列介面。解析步驟如下：
①用於擷取列表框取值的函數介面cgiFormSelectSingle。
②用於擷取文字框取值的函數介面cgiFormString。
③用於擷取複選框取值的函數介面cgiFormCheckboxMultiple。
在需要訪問元素時，只需提供相應的元素名，就可方便地使用這些介面對管理鏈表遍曆來獲得相應元素的取值。
當CGIC移植時，只需對相應元素解析對應的函數進行所選系統的修改即可。需要注意的是，對列表和複選框等非字元取值的擷取，還需按照使用者定義的取值設定，對相應的介面進行一定的修改，以適應使用者對元素取值範圍的靈活要求。
所謂解析資料的模板頁面回填，是指在動態網頁面設計中，按照模板中的頁面顯示格式，將頁面中各元素的取值寫入html模板檔案中的對應位置。html標籤代碼如下：
<input name=“devName”type=“text”
value=“***”size=“15”／>
它在頁面上表示一元素名為“devName”，取值為“***”的文字框，在資料回填到模板頁面時，需要根據具體的取值如“devl”寫到原“***”的對應位置上去。結果如下：
<input name=“devName”type=“text”
value=“devl”size=“15”／>
本文採用以下方法來實現這一處理過程。首先，沒計頁面模板時在每個需要進行動態修改的頁面元素前加上不同的備註陳述式，對以上html標籤，可加的備註陳述式如下(單獨一行)：
<!-devName_id->
在每次解析完表單資料並且需要對動態網頁面進行重建時，就可以通過對模板檔案的逐行讀取，來尋找相應的備註陳述式，從而確定資料更新的位置。然後再根據具體的元素取值產生新的html標籤字串，用來對備註陳述式後的標籤字串進行替換。通過以上過程，即可方便地實現解析資料的模板頁面回填，從而產生相應的動態網頁面。
2．4 檔案下載和上傳的功能實現
檔案下載和上傳是伺服器經常具有的一項功能，相對來說檔案下載較為簡單，只需將下載時訪問的URL定位於目標檔案，然後再由伺服器將該檔案的內容直接上送給瀏覽器。而檔案上傳功能的實現則相對複雜，下面對其設計過程進行詳細的說明。
首先，要實現檔案的上傳，在其頁面設計時必須採用POST方法來對表單資料進行提交，並且需要在頁面中將其編碼方式修改為“multipa rt／form-data”，否則將無法在瀏覽器端進行檔案上傳。然後，通過html表單中的檔案元素來進行上傳檔案的選擇。
通過以上設定，上傳給伺服器的http報文資料將以multipart的編碼形式出現。其特點是，在每個表單元素項的前後均加有一行分界字串。以檔案元素為例，其格式如下：
--------------------------------7db01d60ffc
Content-Disposition：form-data；name=“file”； filename=“1．TXT”Content-Type：text／plain
This is a txt file．
--------------------------------7db01d60ffc
其中，“----------------------------7db01d60ffc”為分界字串。CGlC也提供了對該格式的解析支援。它首先提取出分界字串，然後再通過cgiParsePostMultltpartInput函數的操作來實現報文中各表單元素資料以及檔案資料的解析。提取出檔案資料後，即可將檔案內容按指定的路徑儲存在相應的Flash儲存區中。

3 效能測試
通過以上各環節，即可實現一個相對完整的EWS。綜合以上各個模組。
在主頻600 MHz的TMS320DM642處理器上對該EWS從收到請求建立串連到響應結束中斷連線的時間進行測試，EWS效能測試如表1所列。

其中，由於採用了架構結構進行設計，在訪問索引首頁時，涉及的訪問請求次數較多，所以其測試時間相比其他單次請求來說要較長一些。總體來看，該EWS具有比較快速的服務回應時間，能夠滿足具體應用環境的要求。

結語
本文在BOA和CGIC的基礎上，通過對其代碼的修改以及HTTP協議報文的分析，將原本運行於Linux平台上獨立的兩個程式進行有機的結合，成功地將其整合為DSP／BIOS中的一個任務，並提出了一種適合一般嵌入式系統使用的存取權限及對Web頁面的管理及動態產生機制。同時，完成了檔案的上傳與下載功能，成功實現了一個相對完整的EWS。