|
本文是針對當前礦業(yè)安全事故頻繁，設計了這樣一個(gè)能在惡劣環(huán)境下正常工作的安全系統。首先介紹了嵌入式系統的相關(guān)概念和軟硬件環(huán)境，闡明煤礦井上監控終端的嵌入式系統需求和Windows CE 嵌入式操作系統選擇;接著(zhù)，從嵌入式數據庫的相關(guān)概念和煤礦井上 監控終端的嵌入式數據庫需求及特點(diǎn)出發(fā)，詳細研究Berkeley DB 數據庫的關(guān)鍵技術(shù)特性以及在煤礦井上監控系統中的適用性，并介紹Berkeley DB 數據庫的基本概念和基本API 函數操作。 嵌入式數據庫不僅在功能概念及系統特點(diǎn)上與傳統的數據庫有著(zhù)很大的差別，而且在它的應用方式上也是不同的。嵌入式數據庫并不是直接銷(xiāo)售給用戶(hù)，而是提供給設備的生產(chǎn)商或應用的開(kāi)發(fā)商，以便直接生成在嵌入式系統和應用之中，嵌入式數據庫在許多領(lǐng)域擁有廣泛的應用前景，如手持式計算和移動(dòng)計算，智能設備，在本文中便提供了較好的應用。 1 系統需求分析 前端數據采集、監控、發(fā)送等嵌入式系統軟件開(kāi)發(fā)工作。為了滿(mǎn)足前端嵌入式監控系統對井下實(shí)時(shí)數據的存儲、查詢(xún)、顯示等大量處理要求，必須安裝數據庫管理系統，而傳統的數據庫管理系統顯然因其資源占用大、數據管理效率低等特點(diǎn)不能適用與嵌入式礦場(chǎng)監控系統，因此，探索一種適用于礦場(chǎng)惡劣環(huán)境下的嵌入式監控終端的數據庫系統成為本文進(jìn)展的關(guān)鍵。 嵌入式數據庫管理系統是隨著(zhù)嵌入式應用的發(fā)展而興起的一類(lèi)嵌入式應用軟件，已經(jīng)成為數據庫技術(shù)研究的一個(gè)重要分支，在移動(dòng)計算平臺(如HPC,PDA)、家庭信息環(huán)境(如機頂盒和數字電視)、通訊計算平臺、汽車(chē)電子平臺、電子商務(wù)平臺(如智能卡應用)等領(lǐng)域得到廣泛的應用。 為解決這些問(wèn)題，提出了嵌入式系統在煤礦井上監控系統中的應用，嵌入式系統技術(shù)的小體積、高可靠性、低功耗和低成本等特點(diǎn)滿(mǎn)足井上監控系統設備的嚴格要求及現場(chǎng)惡劣生產(chǎn)環(huán)境的適應性，并且監控終端移植嵌入式數據庫管理系統，滿(mǎn)足傳統煤礦安全監控系統的主要功能需求: 1.數據通信功能需求。 2.實(shí)時(shí)查詢(xún)及顯示需求。 3.用戶(hù)登錄管理需求。 2 系統總體設計 嵌入式礦場(chǎng)安全系統的核心是數據處理。監控終端實(shí)時(shí)采集礦場(chǎng)各類(lèi)傳感器的模擬信號(如瓦斯濃度、一氧化碳濃度、風(fēng)速、溫度、濕度、粉塵、壓力等)和現場(chǎng)設備控制設備的開(kāi)關(guān)量信號(如風(fēng)機啟、停狀態(tài)等)，實(shí)現數據實(shí)時(shí)顯示、實(shí)時(shí)/歷史曲線(xiàn)顯示、查詢(xún)和報表打印、聲光報警、手動(dòng)/自動(dòng)控制，以及網(wǎng)絡(luò )通信等功能。而所有這些功能的實(shí)現都是以數據管理為基礎的，嵌入式數據庫系統可以有效地組織和管理煤礦場(chǎng)下各類(lèi)數據，從而達到礦場(chǎng)監控系統實(shí)時(shí)查詢(xún)、控制等功能的設計要求。圖1 是一個(gè)典型的采用了嵌入式數據庫的礦場(chǎng)安全系統的結構圖: 系統采用 Windows CE 嵌入式操作系統和Berkeley DB 嵌入式數據庫作為礦場(chǎng)井上監控系統終端應用程序的開(kāi)發(fā)平臺;以現有的礦場(chǎng)安全監測監控系統為數據源，以文件共享的方式實(shí)時(shí)采集現場(chǎng)安全生產(chǎn)數據，進(jìn)行數據的處理和發(fā)送。 3.系統主要功能模塊實(shí)現 3.1 數據采集模塊 數據采集模塊實(shí)現煤礦數據源傳感器實(shí)時(shí)數據的讀取，并設計成一定格式的數據結構，以便數據庫和應用程序操作。本系統以現有的礦場(chǎng)安全系統(MSUS )為數據源，安全系統按照協(xié)議規定的文件格式組織傳感器數據，存儲在指定本地磁盤(pán)路徑中。 1.設備安裝信息文件(dev.xml ) 傳感器設備文件分為數據頭和數據體，數據頭格式規定如下： ＜礦場(chǎng)編號＞＜礦井名稱(chēng)＞＜日期＞＜傳感器個(gè)數＞＜其他＞＜保留＞ 2.實(shí)時(shí)數據文件(rtdata. xml ) 實(shí)時(shí)數據文件分為數據頭和數據體，數據頭格式規定如下： ＜礦場(chǎng)編號＞＜數據上傳時(shí)間＞＜傳感器數目＞ 數據體格式規定如下： ＜傳感器編號＞＜數據值＞＜數據狀態(tài)＞ 其中，數據狀態(tài)按位來(lái)表示數據的狀態(tài)(用二進(jìn)制定義，使用時(shí)轉換為整數)，其文本對應關(guān)系如下： 數據采集程序設計 數據采集模塊程序使用了 ReadFile.h 和ReadFile.cpp 文件,因此本文設計了CReadFile 類(lèi)，該類(lèi)封裝了對dev.xml 和rtdata.xml 交換文件所有的數據采集操作。根據 dev.xml 和rtdata.xml 交換文件的構成，以及數據庫存儲操作上的考慮，程序為每個(gè)傳感器設計了DEVDATA 和REALDATA 結構體，分別用來(lái)保存dev.xml 和rtdata.xml 文件的數據信息。DEVDATA 結構體如下所示: typedef struct devdata { TCHAR m_str_devSubstation[MAXLENGTH];//分站 TCHAR m_str_devID[MAXID];//傳感器編號 TCHAR m_str_devPlace[MAXLENGTH];//安裝地點(diǎn) TCHAR m str_devName[MAX];//檢測類(lèi)別 TCHAR m str_devType[MAX];//傳感器類(lèi)型 TCHAR m str_devUnit[MAX];//單位 float m_data_up;//量程上限 float mes_data_down;//量程下限 float m_alarrn_up;//報警上限 float m_alarm_down;//報警下限 float m_power_off;//斷電值 float m_power_on;//復電值 }DEVDATA; REALDATA 結構體如下所示: typedef struct realdata {TCHAR m_str_devID[MAXID];//傳感器編號 float m_data;//傳感器數值 TCHAR m_str_dataStatus[MAXSTATUS];//數據狀態(tài) }REALDATA; CReadFile 類(lèi)使用了CPtrList 鏈表數據結構，用以管理交換文件的所有傳感器信息，數據節點(diǎn)為DEVDATA 和REALDATA 結構體。 3.2 數據存儲模塊 將傳感器設備上傳時(shí)間作為 key，封裝在DEVDATA 結構體中的設備安裝信息和封裝在REALDATA 結構體中的實(shí)時(shí)數據信息分別構成數據庫的data，從而構成兩組Key 到Data對。因此，該方案將形成兩張表，分別存儲在兩個(gè)數據庫文件中。將傳感器設備安裝信息和實(shí)時(shí)數據信息形成兩個(gè)數據庫文件分別存儲，只在設備安裝信息改變的時(shí)候才會(huì )進(jìn)行設備文件的存儲操作，這樣大大減少了數據庫文件的磁盤(pán)占用空間。 Berkeley DB 用Key/Data(關(guān)鍵詞/數據)來(lái)區分數據庫中的數據，Key/Data 對是BerkeleyDB 用來(lái)進(jìn)行數據庫管理的基礎，由這兩者構成的Key/Data 對組成了數據庫中的一個(gè)基本結構單元，而整個(gè)數據庫實(shí)際上就是由許多這樣的結構單元所構成的。也就是說(shuō)，調用數據庫接口實(shí)際上就是提供了相應的關(guān)鍵詞，通過(guò)該關(guān)鍵詞來(lái)查找要操作的數據。 如果把一組相關(guān)的 Key/Data 對也看作一個(gè)表的話(huà)，那么每一個(gè)數據庫只允許存放一個(gè)table，因此，一般一種類(lèi)型的Key/Data 對構成一個(gè)數據庫文件。數據庫存儲代碼設計主要分為設備安裝信息(key/data 對為設備上傳時(shí)間/DEVDATA 結構體)存儲代碼設計和實(shí)時(shí)數據信息(key/data 對為設備一上傳時(shí)間/REALDATA 結構體)存儲代碼設計。Berkeley DB 是以文件為單位進(jìn)行數據庫管理的，由于設備安裝信息只在數據改變的時(shí)候才進(jìn)行數據庫存儲操作，并且其間隔周期較長(cháng)，因此作者設計了dev.db 文件實(shí)現安裝信息的存儲管理;由于實(shí)時(shí)數據信息的更新周期較短，數據庫存儲操作頻繁，并且每天都會(huì )有數據的采集和更新，因此作者以每天的日期為單位設計了實(shí)時(shí)數據庫文件，系統將會(huì )獲取當天的日期，并以之為文件名形成數據庫文件進(jìn)行數據庫操作，例如當天的日期為2007 年2 月8 日，那么數據庫文件名為 2007-02-08.db 。 設備安裝信息和實(shí)時(shí)數據信息的存儲代碼具有一定的相似性，作者以實(shí)時(shí)數據信息的存儲代碼為例說(shuō)明其設計過(guò)程，程序流程如下所示: 圖 2 設備安裝信息數據庫存儲程序流程 3.3 數據查詢(xún)模塊 實(shí)時(shí)/歷史數據查詢(xún)模塊設計主要就是GetDevKey、DataQueryByRealTime 和DataQuery函數設計。 1. DataQueryByRealTime 函數設計 若用戶(hù)輸入的查詢(xún)時(shí)間段內設備安裝信息沒(méi)有改變，GetDevKey 函數會(huì )直接返回FALSE，程序接著(zhù)會(huì )調用DataQueryByRealTime 函數查詢(xún)實(shí)時(shí)數據庫文件，設備安裝信息直接從m-devList 結構體鏈表中獲得，函數設計包括如下: ①根據用戶(hù)輸入的查詢(xún)日期，形成實(shí)時(shí)數據庫文件如2007-02-09.db，打開(kāi)實(shí)時(shí)數據庫。 ②構建游標cursor，使用get 方法，以查詢(xún)時(shí)間為key,flag 標簽為DB_ SET_ RANGE 游標定位到數據庫文件多重記錄的首一記錄。 ③遍歷數據庫文件擁有相同 kev 的多重記錄，將data 中傳感器ID 號與用戶(hù)輸入ID 號相等的REALDATA 結構體與相應的m devList 鏈表節點(diǎn)DEVDATA 結構體在列表框控件(CC1istCtrl)中顯示出來(lái)。 2. DataQuery 函數設計 若設備查詢(xún)時(shí)間對應的安裝信息相對于當前時(shí)間段己經(jīng)改變，GetDevKey 函數會(huì )返回正確的設備安裝信息查詢(xún)時(shí)間devKey，這個(gè)查詢(xún)時(shí)間可能跟用戶(hù)輸入的傳感器查詢(xún)時(shí)間不同;程序接著(zhù)會(huì )調用DataQuery 函數，并將這個(gè)正確的設備查詢(xún)時(shí)間devKey、用戶(hù)輸入的傳感器實(shí)時(shí)數據查詢(xún)時(shí)間realKey、傳感器ID 號strDevID 以及實(shí)時(shí)數據庫文件名strRealDbName以形參方式傳給DataQuery 函數，其函數設計包括如下： ①打開(kāi)設備數據庫 dev.db 文件，根據形參strRealDbName 打開(kāi)實(shí)時(shí)數據庫文件。 ②構建游標 cursor，使用get 方法，分別以devKey 和realKey 為數據庫的key, flag標簽為DB_ SET_ RANGE，游標定位到設備數據庫文件和實(shí)時(shí)數據庫文件的首記錄。 ③遍歷數據庫文件擁有相同key 的多重記錄，若設備數據庫文件記錄的data 中(DEVDATA 結構體)傳感器ID 號與實(shí)時(shí)數據庫文件記錄的data 中(REALDATA 結構體)傳感器ID 號相等，則將這兩個(gè)data 信息在列表框控件(CC1istCtrl)中顯示出來(lái)。 4．總結 本文的創(chuàng )新點(diǎn)：分析嵌入式煤礦井上監控系統的功能需求，開(kāi)發(fā)設計了基于Berkeley DB數據庫和Windows CE 的礦場(chǎng)安全系統，實(shí)現了窗口登錄、數據采集、系統界面、數據庫存儲、實(shí)時(shí)/歷史數據查詢(xún)、實(shí)時(shí)曲線(xiàn)顯示等功能模塊，深入討論研究了系統的數據采集方法、數據庫KEY/DATA 對存儲方案及實(shí)時(shí)/歷史傳感器數據的數據庫查詢(xún)策略。在實(shí)際生產(chǎn)中工作穩定，查詢(xún)速度快，達到了預期的設計目標。 |
