摘要：針對城市消防遠程監控系統中火災自動報警系統的聯網問題，提出一種利用Internet實現火災自動報警系統與城市監控中心的聯接方案，設計了系統的關鍵設備——基于ARM" title="ARM">ARM的嵌入式網關。設備中采用經過剪裁、內核版本2．6的linux" title="linux">linux系統，提高了信息處理和傳輸的實時性和可靠性，并在嵌入式操作系統的基礎上，利用多線程及管道編程，實現了火災探測信息的處理傳輸及上層監控中心和下層網關的信息交互。設備實際運行后的結果表明，該火災信息" title="火災信息">火災信息傳輸網關能夠順利地對相關信息進行處理和轉發，在廣域網內實現了數據的實時、高速、可靠傳輸，滿足基于互聯網的城市消防遠程監控系統要求。
關鍵詞：嵌入式網關；火災探測；消防；信息傳輸；ARM

O 引言
    火災是城市災害中的一種主要形式，它已經日益成為影響社會經濟發展和人民生活的一個重要災害，而目前城市在預防火災方面主要采用的就是在建筑物內安裝火災自動報警系統及其聯動消防裝置，雖然這種裝置在及早發現火情和控制火勢方面發揮了重要作用，但是在目前這種消防設備管理和監督體系下，很多建筑物的所有方不能夠及時地對建筑物內的消防設施進行檢查維修，導致很多火災自動報警系統故障誤報頻發，極大地影響了建筑物內的人員的工作和生活；同時，大部分消防主控室主要通過人工值班、電話報警方式，因受到電話線路、報警方式方法以及報警人情緒的影響，往往造成接警調度處理速度較慢；消防部門在接警時也是依靠電話來傳遞信息的，極易受到報警人或值班員聽覺的影響而導致接傳火警信息有誤，造成不應有的錯誤和無法估量的損失，所以建立基于互聯網的城市消防監控系統具有很重要的實踐意義。在這項工程中，最關鍵的就是處于網絡與自動報警聯動裝置之間的接入網關的設計和研制。利用這種專門的硬件設備以及在這之中
的程序，可以把各個建筑物的消防自動化及其聯動裝置接入Internet，通過互聯網連接到城市中的監控中心。

1 基于互聯網的城市消防遠程監控系統結構
    該系統由三層組成，系統框圖如圖1所示。第一層是建筑物內的消防自動報警及其聯動裝置以及其他一些用戶的消防設施，它們由很多不同廠家和類型的火災探頭、消防主機、手動消防設備組成；第二層是火災信息收集管理處置中心、政府消防部門信息接口、互聯網普通用戶查詢接口等信息使用單位。

2 火災信息傳輸網關的硬件設計
    該嵌入式網關的中央處理單元采用三星公司的16／32位RISC處理器S3C2440A，它基于ARM920T內核，運算速度高達400 MHz，適用于需要聯網應用的嵌入式電子設備。其中的NOR FLASH用于存儲bootloader啟動代碼，NAND FLASH用于存儲操作系統的內核映像和根文件系統映像，SDRAM用于加載操作系統內核及應用程序等可執行代碼和數據，為其運行提供空問。外圍電路包括以太網模塊、串口模塊、人機接口模塊等，如圖2所示。

3 火災信息傳輸網關的軟件設計
3．1 軟件總體設計
    軟件總體設計如圖3所示。

3．2 總體概述
    網關軟件系統按照功能分為4個模塊。
    (1)網絡通信模塊
    主要負責信息往網絡上的傳遞，將該網關獲取的火警，故障等信息依照特定的網絡協議準確無誤地傳遞給上層的應用服務器，同時還要負責接收來自服務器的數據，如配置信息，控制指令等。具體來說，網絡通信模塊又可以分為兩個子模塊：數據通信和數據處理。數據通信的工作只是負責從網絡上獲取數據或者將數據發送到網絡。數據處理主要負責組包和解包，涉及到通信協議。當數據區有數據需要網絡通信模塊處理時，數據處理子模塊會首先從數據區取出數據，并分析、判斷數據類型，根據數據類型組包，然后將包交給數據通信子模塊發送。
    (2)串口采集模塊
    主要負責通過串口獲取消防主機的狀態，并進行分析，分離出有用信息，并將其寫入數據區，供其他模塊使用，它是信息傳輸網關的核心。
    由于消防主機眾多，而且協議又各不相同，因此串口采集模塊需要根據消防主機定制。在此，同樣將串口采集模塊分為兩個子模塊：數據采集和數據加工。數據采集通過特定的對話方式(和具體的消防主機有關)從消防主機獲取數據，數據加工讀取這些數據，并按照消防主機協議進行解析，提取初步的信息，如消息類型(火警還是故障)，探頭地址(內部編碼地址)。然后依照內部協議組包，并寫入數據區，以后的工作就交由網絡通信模塊。
    (3)系統控制模塊
    主要用于控制信息傳輸網關的硬件設備，如指示燈、按鍵、燈等。它從數據區讀取控制指令，根據控制指令執行特定的硬件控制。控制指令可能由網絡通信模塊產生，如上層服務器發送查崗請求，網絡通信模塊經過數據處理轉化為響喇叭指令，寫入數據區。當然，控制指令可以由任何模塊產生。系統控制模塊可以返回硬件狀態信息，也是通過寫狀態信息到數據區來實現信息傳遞的。
    (4)系統維護模塊
    主要負責確保系統各個模塊的正常運行，同時記錄及上傳工作日志，供系統維護人員參考，同時收集上來的數據經過分析和挖掘，可以作為產品性能指標制定的依據。各模塊在建立之初將會在數據區注冊，維護模塊通過這個注冊信息實現心跳應答機制來判斷各個模塊的工作狀態。同時，還將數據區中的日志信息提取出來寫入日志文件，并提出發送日志文件請求給網絡通信模塊。
    每個模塊依照分工完成職能之內的工作，不屬于職能內的工作通過寫入數據區交由職能模塊去完成。數據區是各個模塊傳遞信息的媒介，通過格式化的數據寫入和讀取，實現模塊間的信息共享和職能分工。
3．3 各模塊詳細設計
3．3．1 流程分析
    核心管理模塊是嵌入式網關入口，當嵌入式網關加電啟動，嵌入式網關的操作系統負責啟動核心管理模塊。此時，其他模塊還未啟動。核心模塊首先為其他模塊啟動初始化系統環境，如創建管道，共享內存等。接著，核心模塊啟動其他模塊。這時，系統將啟動完成。接著，核心模塊建立定時器，創建定時器是為了定時地檢測其他模塊，以判斷其他模塊的狀態，稱這個過程為“心跳”。
    當以上過程完成后，核心管理模塊開始監視所有管道，當管道有數據時，他讀取定長的數據并分析，找出源地址、目的地址及命令字。根據命令字類型的不同做不同的處理。程序流程圖如圖4所示。

    (1)初始化。初始化的主要工作是為模塊間的通信建立有名管道，每個與核心模塊通信的進程有一個管道。當前系統需要創建四個管道。其他模塊如果想要使用管道，必須首先打開管道。所有與管道的通信都有API供其他用戶使用。
    (2)啟動其他模塊。核心模塊通過子進程調用execl()來啟動其他模塊。每個其他模塊都是一個可執行程序，通常位于一個固定的路徑及固定的文件名。每個模塊在啟動之后需要向核心模塊發送注冊信息，這些信息包括模塊標識、進程ID、進程狀態等。登記信息由核心模塊保留，供以后使用。
    (3)創建定時器。核心模塊需要定時地檢測其他模塊的生存狀況，通過注冊一個定時器，可以定時地觸發檢測功能。
    (4)開始監聽。當所有初始化工作完成以后，核心模塊開始進入工作狀態。它的主要工作就是負責處理管道信息。通過使用select()函數可以實現同時監聽多個管道。當某個管道有數據，核心模塊讀取數據包(格式詳見后文)，并解析出包頭，得到包的源地址，目的地址，及控制字并加以分析，選擇處理流程。處理流程包括：數據中轉，巡檢，系統維護等。當該數據包處理完成以后，核心模塊返回繼續等待下一個數據包。
    (5)處理數據中轉。其他模塊間無法直接通信，都必須通過核心模塊進行中轉。數據包中指明了包的源地址，目的地址及控制字。這里的控制字說明數據需要中轉，核心模塊解析到數據包需要中轉，就將包寫入到給定目的地址的模塊管道。
    (6)處理巡檢。服務器需要定時地檢測前置機各個模塊的狀態，于是發送巡檢請求給網絡模塊，網絡模塊解析后組包發送給核心模塊，核心模塊在分析包發現該包是巡檢請求，于是通過kill()函數及注冊記錄信息，判斷各個模塊的狀態，并組包發送給服務器。
    (7)處理系統維護。系統維護的主要任務是為了保證系統所有模塊的正常運行。前面初始化了一個定時器，通過定時器，可定時地查詢其他模塊的狀態。當發現某個模塊異常，核心模塊將重啟該模塊。
3．3．2 關鍵數據結構
    (1)包格式：

    (2)模塊ID定義
    如表1所示：

    (3)控制字定義
    如表2所示：

        (4)管道初始化
    首先，用戶必須選擇正確地管道初始化函數，通過初始化函數，用戶正確的建立與管道的連接。初始化函數如表3所示。

    (5)管道寫操作
    一旦管道創建完成，用戶就可以通過調用管道寫函數來寫數據。用于必須調用和初始化一致的寫函數。如網絡模塊調用pipe_init_net-work函數初始化管道，必須通過調pipe_write_network來寫，若調用其他函數寫入將失敗，如表4所示。

    表4中目的模塊ID和控制字在eonfig．h文件中定義。msg是要發送數據的首地址，必須注意的是msg所指向的數據必須是字符串類型，必須以“＼O”結束，否則發送函數無法確定msg數據包的長度。對于不是以msg結尾的數據包，必須字符串化，否則發送函數的行為未定義。
    (6)管道讀操作
    管道讀操作從管道讀取一個固定長度的數據包，并解析數據包，從數據包中分離信息。管道的讀操作可以是阻塞模式和非阻塞模式。在阻塞模式下，讀操作將阻塞直到有數據返回。用戶通過設置讀操作中的參數flag可以實現模式選擇。當flag=0時，表示為阻塞模式；當flag= 1時，表示為非阻塞模式。管道讀操作也要求管道必須正確的初始化，否則讀失敗，同時也要求必須選擇正確的管道讀函數，如表5所示。

    表5中，src是unsigned short*類型，如果不要求獲取源地址，可以傳遞NULL。msg用于存放接收數據的內存首地址，msg必須大于或等于251 B。空間必須由用戶分配。函數假定msg的空間已分配且空間足夠大。
     (7)基于TCP／IP的網絡通信
    裝置采用串口采集消防主機上的數據，并且把數據轉換成TCP／IP協議能識別的數據包，因此串口采集的數據源要作為以太網幀的一部分。為了向設備提供透明的接口并區分數據源，需要制定統一的幀格式。幀格式如下：

    其中，串口號字段用來區分數據源；幀頭、幀尾作為一個串口幀的起始分界(可自定義)；數據部分是來自串口的原始數據流。
    以太網方面采用面向連接的網絡通信，采用TCP／IP網絡通信協議。數據包結構描述中控制單元格式如下：

    
    
    消防主機發送的信息一般在10～100 B之間，若選擇TCP協議，會使協議開銷在網絡的吞吐量中占有很大的比例。UDP協議支持實時多播通信，保證了網關向監控中心實時發送火警情報，并能有效地減少用戶信息傳輸裝置的開銷和網絡資源。UDP協議的數據可靠性和完整性問題由應用程序來解決，因此在該系統中使用UDP更合理。
    TCP／IP通信模塊采用SOCKET套接字編程實現。本系統采用服務器／客戶端編程模型，服務器和客戶端分別對應監控中心工作站服務器和用戶信息傳輸裝置。

4 結語
    本文詳細剖析了利用Internet實現火災自動報警系統與城市遠程消防監控中心的連接及相關信息的交互，并設計了該系統的關鍵設備——嵌入式信息傳輸網關，采用已經移植有Linux 2．6內核操作系統的ARM9單片機，在此基礎上進行了應用程序的開發，實現了火災探測信息的處理轉發功能和上位機與嵌入式網關的信息交互功能。設備在實際環境中安裝后的測試結果表明，該嵌入式系統對火災探測數據及交互信息的處理和轉發穩定可靠、實時性好，不僅適用于基于IP的火災信息傳輸網絡中，同時還可應用于其串口和以太網通信的場合中，應用前景廣闊。