本發(fā)明涉及一種不停車收費系統(tǒng)，具體的說是基于HIEP支付標準的不停車收費系統(tǒng)。
背景技術：
：隨著科學技術水平的發(fā)展，視頻領域已進入高清時代，目前傳統(tǒng)的停車場大多采以下兩種方式：①近距離讀卡方式，必須停車伸手刷卡，上下坡道停車刷卡容易造成溜車、碰撞等事故，并且停車場卡片屬于一種耗材，后期添加需要購買，還涉及丟卡、壞卡等情況引發(fā)的經(jīng)濟糾紛。②射屏讀卡模式（如高速公路收費的ETC系統(tǒng)），需預先向收費管理方申請購買安裝射屏物理設備，同時向指定帳戶充值預存一定額度的費用。當發(fā)生消費時，在指定帳戶中扣除。這種模式需先購買安裝物理硬件設備，讓客戶造成不必要的資源浪費，多次預存后消費，占用客戶資金，消費體驗感差。無法實現(xiàn)車輛停車及收費的多個場景的互聯(lián)互通。技術實現(xiàn)要素：本發(fā)明旨在克服現(xiàn)有技術的缺陷，提供一種基于HIEP支付標準的不停車收費系統(tǒng)，實現(xiàn)無卡出入停車場，銀行自動扣費。為了解決上述技術問題，本發(fā)明是這樣實現(xiàn)的：一種基于HIEP支付標準的不停車收費系統(tǒng)，其特征在于：它包括道閘、中心服務器、攝像單元、至少一個入口崗亭終端和至少一個出口崗亭終端，攝像單元包括入口攝像機組和出口攝像機組，入口攝像機組和出口攝像機組均包括攝像主機和攝像從機；入口攝像機組中的攝像主機自動識別并抓拍車牌信息，攝像從機輔助識別車牌信息，攝像主機和攝像從機之間通過網(wǎng)絡交換信息，攝像主機通過網(wǎng)絡連接入口崗亭終端和中心服務器，攝像主機控制道閘打開；中心服務器上裝有停車管理軟件以及與銀行后臺連接的HIEP支付標準；入口處掃描的車牌信息同時發(fā)送到中心服務器上的停車場收費系統(tǒng)及銀行后臺的HIEP支付標準的系統(tǒng)內(nèi)；出口攝像機組中的攝像主機自動識別并抓拍車牌信息，攝像從機輔助識別車牌信息，攝像主機和攝像從機之間通過網(wǎng)絡交換信息，攝像主機通過網(wǎng)絡連接出口崗亭終端和中心服務器，通過中心服務器上的HIEP支付標準收取費用，出口處掃描車牌信息后顯示的收費金額與銀行后臺生成的收費金額比對，比對成功后扣費，攝像主機控制道閘打開；入口崗亭終端和出口崗亭終端顯示車牌識別信息、歷史信息、收費金額、攝像單元及道閘狀態(tài)、剩余車位和報表查詢；所述的基于HIEP支付標準的不停車收費系統(tǒng)，其特征在于：還包括入口顯示屏和出口顯示屏，入口顯示屏顯示剩余停車位數(shù)量，出口顯示屏顯示收費金額。所述的基于HIEP支付標準的不停車收費系統(tǒng)，其特征在于：入口和出口處還包括相互連通以及與入口崗亭終端和出口崗亭終端連通的語音對講機。所述的基于HIEP支付標準的不停車收費系統(tǒng)，其特征在于：出口處還包括與入口崗亭終端和出口崗亭終端連接的票據(jù)打印機。所述的基于HIEP支付標準的不停車收費系統(tǒng)，其特征在于：出口處的票據(jù)打印機還直接與國家財稅系統(tǒng)相連接，直接進行相應部分收款的稅務申報。所述的基于HIEP支付標準的不停車收費系統(tǒng)，其特征在于：所述中心服務器和攝像單元均配備有備用電源。本發(fā)明的有益效果是：整套系統(tǒng)使用簡單、維護方便、穩(wěn)定性強，采用TCP\IP網(wǎng)絡通訊，布線簡單、方便，大大減少了施工難度，便于設備的調(diào)試及維護。此外，系統(tǒng)還將車牌的人工比對升級到自動識別，提升了立體高清車牌識別攝像機圖像的清晰度、處理速度和圖像智能分析能力，有效控制了一卡多用和保安亂收費等現(xiàn)象。附圖說明下面結合附圖和實施方式對本發(fā)明作進一步的詳細說明：圖1為遠程控制機（銀行前置交易系統(tǒng)）和現(xiàn)場監(jiān)控設備的互聯(lián)的示意圖。圖2為EPC前置平臺工業(yè)遠程監(jiān)控系統(tǒng)圖。圖3為EPC系統(tǒng)監(jiān)控系統(tǒng)模型實現(xiàn)結構示意圖。圖4為EPC計費系統(tǒng)結構表。圖5為EPC數(shù)據(jù)庫關系表。圖6為多重證書示意圖。圖7為NBFS的分布并行計算結構圖。圖8為NBFS應用結構模型圖。圖9為服務器組機構圖。圖10為XML模型的MVC模式實現(xiàn)方式示意圖。圖11為XML虛擬數(shù)據(jù)庫設計與實現(xiàn)的示意圖。圖12為EPC手機用戶界面演示圖。圖13為本發(fā)明入口處的結構示意圖。圖14為本發(fā)明出口處的結構示意圖。具體實施方式如圖13和圖14所示：一種基于HIEP支付標準的不停車收費系統(tǒng)，它包括道閘1、中心服務器2、攝像單元、一個入口崗亭終端3、一個出口崗亭終端4、入口顯示屏、出口顯示屏5，攝像單元包括入口攝像機組6和出口攝像機組7，入口攝像機組和出口攝像機組均包括攝像主機和攝像從機；入口攝像機組中的攝像主機自動識別并抓拍車牌信息，攝像從機輔助識別車牌信息，攝像主機和攝像從機之間通過網(wǎng)絡交換信息，加入智能仲裁算法選取最優(yōu)識別結果進行控制，主機接收從機的識別結果，并進行分析、處理，確認車牌信息，攝像主機將車牌信息通過路由器8傳輸?shù)饺肟趰復そK端和中心服務器，攝像主機控制道閘打開；中心服務器上裝有停車管理軟件以及與銀行后臺連接的HIEP支付標準；入口處掃描的車牌信息同時發(fā)送到中心服務器上的停車場收費系統(tǒng)及銀行后臺的HIEP支付標準的系統(tǒng)內(nèi)；出口攝像機組中的攝像主機自動識別并抓拍車牌信息，攝像從機輔助識別車牌信息，攝像主機和攝像從機之間通過網(wǎng)絡交換信息，攝像主機將車牌信息通過網(wǎng)絡傳輸?shù)匠隹趰復そK端和中心服務器，通過中心服務器上的HIEP支付標準收取費用，出口處掃描車牌信息后顯示的收費金額與銀行后臺生成的收費金額比對，比對成功后扣費，攝像主機控制道閘打開；入口崗亭終端和出口崗亭終端顯示車牌識別信息、歷史信息、收費金額、攝像單元及道閘狀態(tài)、剩余車位和報表查詢；入口顯示屏顯示剩余停車位數(shù)量，出口顯示屏顯示收費金額；入口和出口處還包括相互連通以及與入口崗亭終端和出口崗亭終端連通的語音對講機；出口處還包括與入口崗亭終端和出口崗亭終端連接的票據(jù)打印機；出口處的票據(jù)打印機還直接與國家財稅系統(tǒng)相連接，直接進行相應部分收款的稅務申報；所述中心服務器和攝像單元均配備有備用電源。一、攝像單元能夠?qū)崟r準確地自動識別出車牌的數(shù)字、字母、漢字字符，并直接給出識別結果。同時管理者還可以通過抓拍到的圖片識別出車輛特征，如車型、顏色等。立體高清車牌識別攝像機采用百萬像素高清識別技術，可在室外惡劣環(huán)境下使用，穩(wěn)定可靠。立體高清車牌識別，可脫機工作，提供H.264、MPEG4、MJPEG的實時碼流，結合高性能的視頻壓縮算法，使圖片傳輸更加流暢。立體高清車牌識別攝像機調(diào)試可結合IE瀏覽器來完成，操作簡單方便，可實現(xiàn)不停車通行。一體化：立體高清車牌識別攝像機內(nèi)部集成了所需的硬件和軟件，不需輔助的設備即可完成其功能。一體化的結構形式使得立體高清車牌識別攝像機增加了系統(tǒng)的的適應性、穩(wěn)定性，方便了安裝、調(diào)試及維護。嵌入式：立體高清車牌識別攝像機內(nèi)部將所有算法固化在硬件之中，因此可以脫離計算機實現(xiàn)獨立工作，得到了更廣闊的應用空間。車牌識別：立體高清車牌識別系統(tǒng)將出入車輛的車牌信息作為車輛管理的唯一考證，自動抓拍出入車輛的圖像，自動識別車牌信息，通過對出入車輛的識別結果比對來判斷車輛是否為有效車輛。受現(xiàn)場環(huán)境制約，車牌表面和攝像軸線無法做到垂直，導致車牌發(fā)生畸變，遠離攝像機的位置字符變小，對識別造成一定的困難。立體高清車牌識別攝像機畸變校準算法采用多色彩空間進行車牌底色檢測，準確定位車牌區(qū)域，獲取車牌傾斜角度及橫向變形比例，最大傾斜角度達到25°，安全角度15°內(nèi)的準確校準率達到99%以上。二、攝像單元在每個出入口聯(lián)網(wǎng)工作，上位機識別方式聯(lián)網(wǎng)收費，并以車牌號作為唯一的數(shù)據(jù)標識進行車輛的管理。通過對各個出入口的攝像單元識別結果的比對來進行判斷和收費，停車時間和停車費用根據(jù)對應的收費方案計算并顯示在崗亭終端的管理程序界面上；由于整個系統(tǒng)是網(wǎng)絡結構，對于固定車輛來說斷網(wǎng)是沒有影響的，因為固定車輛的車牌號都已經(jīng)下載到攝像單元內(nèi)，內(nèi)部將所有算法固化在硬件之中?！扒度胧健弊R別方式支持脫離計算機實現(xiàn)獨立工作。對于臨時車輛，如果一個路口的設備之間沒有斷網(wǎng)，也是不影響的；只有當該臨時車從A路口的入口進，又要從B路口的出口出，而中心服務器處于斷網(wǎng)情況，才會影響對該臨時車輛的收費管理；攝像單元可以脫機存儲500張照片，2萬條識別記錄。還可以在崗亭終端配置“條碼打印機”和“條碼掃描槍”，當中心服務器斷網(wǎng)時，崗亭終端程序會提醒工作人員使用“條碼打印機”對臨時車輛發(fā)一個條碼，條碼上記錄了入場時間；那么該臨時車輛從任何路口出場時，若“中心服務器”已經(jīng)“恢復聯(lián)網(wǎng)”，會將存儲的500張照片，2萬條識別記錄上傳，則按“臨時車車牌識別收費管理規(guī)則”通行；該臨時車輛從任何路口出場時，若“中心服務器”還沒有“恢復聯(lián)網(wǎng)”，工作人員可以向該臨時車索要條形碼，按“臨時車條形碼識別收費管理規(guī)則”通行；無卡出入停車場、臨時車收費：針對某大型商場，對固定（內(nèi)部車）車輛與臨時車輛共用同一個出口或入口進行聯(lián)網(wǎng)統(tǒng)一管理。我公司提供的方案只需在入口和出口安裝攝像單元，固定車輛，可以在軟件中建立固定用戶信息，車牌識別免費通行。臨時車輛分為三種類型，A一般用戶采用商場停車場的標準收費執(zhí)行;B商場可以對用戶實施優(yōu)惠策略“按時間優(yōu)惠”“按金額優(yōu)惠”，在出口崗亭軟件上有“輸入優(yōu)惠”按鈕，只要是需要優(yōu)惠的車輛，保安，按下“輸入優(yōu)惠”即可進行收費處理；C“條碼打印機”和“條碼掃描槍”還可以應對“無車牌”或“車牌難以辨識”的臨時車輛，無牌車輛采用入口發(fā)小票，出口處用掃描槍對入場時的小票進行掃碼，從而統(tǒng)計車輛的停車時間，計算車輛的收費金額。固定用戶和臨時用戶都通過車牌識別自動判斷車牌是固定用戶還是臨時用戶。在車輛入場時得到識別結果并通過TCP/IP網(wǎng)絡將識別出的車輛信息傳送到停車場各出口，出口將識別結果和基礎信息顯示出入口實時監(jiān)控：系統(tǒng)崗亭程序上實時顯示出入口的監(jiān)控圖像，使停車場的管理形成方便，安全，高效的控制體系。出口自動計費：此項功能必須保證網(wǎng)絡的暢通，停車場出入口設備實時在線，主要用于停車場出入口處已安裝“立體高清車牌識別攝像機”的停車場收費系統(tǒng)，通過收費系統(tǒng)軟件，入口處的“立體高清車牌識別攝像機”將識別的結果傳遞給出口，出口處的攝像單元得到識別結果并根據(jù)收費方案自動計算出應繳納的收費金額，防止內(nèi)部工作人員作弊，有效的避免了應收款的流失。數(shù)據(jù)自動統(tǒng)計及車牌模糊查詢：此項功能必須保證網(wǎng)絡的暢通，停車場出入口設備實時在線，隨時可以用來統(tǒng)計收費金額，進行車牌的模糊查詢。車牌圖像匹配：1、相同車牌完全相同的車牌直接匹配，崗亭程序“出口通道”與“對應入場”窗口顯示匹配的圖片結果。2、近似車牌完全在客觀條件影響下如（暴雨、暴雪、大霧天氣等）造成的車牌識別不匹配，在對應入場圖片下方是自動列出的近似車牌信息條，管理人員可以人工查找系統(tǒng)沒有識別上的相似的車牌，在近似車牌信息條上快速找到對應的車牌，進行車牌匹配。以供管理人員進行人工比對保證車輛的安全。3、無牌車輛當無牌車輛入場時，車輛進入車場出入口區(qū)域時觸發(fā)地感線圈，“立體高清車牌識別攝像機”自動抓拍車輛的圖像，并將車輛信息傳至服務中心無牌車輛數(shù)據(jù)庫，顯示在崗亭程序屏幕無牌車信息條上，管理人員可人工根據(jù)車輛圖像調(diào)出該車對應入場的信息。以供管理人員進行人工比對保證車輛的安全。注：本公司為保證無牌車輛的收費準確，節(jié)省人工查找的速度，同時增加“條碼打印機”和“條碼掃描槍”做輔助功能采用入口發(fā)小票，出口處用掃描槍對入場時的小票進行掃碼，從而統(tǒng)計車輛的停車時間，計算車輛的收費金額。系統(tǒng)管理功能由管理計算機實現(xiàn)。系統(tǒng)采用全網(wǎng)絡化設計，為了保證系統(tǒng)的可靠性，必須保證網(wǎng)絡的安全和暢通。出入口的“立體高清車牌識別攝像機”與控制管理計算機之間采用網(wǎng)絡的方式來實現(xiàn)數(shù)據(jù)和圖像的傳送。三、工作原理臨時客戶車輛：當車輛進場時，車輛駛入車牌識別攝像機抓拍區(qū)域，觸發(fā)地感線圈，攝像單元自動抓拍入場車輛的圖像并自動識別車牌號、記錄入場時間并將車輛信息傳至服務中心，檢索數(shù)據(jù)庫得出車輛類別，顯示在崗亭中心屏幕上，管理人員可隨時監(jiān)控入口的車輛情況，并可校正識別結果。顯示屏顯示該車的有效期或車位信息顯示，歡迎光臨等提示語。當車輛出場時，車輛駛入車牌識別攝像機抓拍區(qū)域，觸發(fā)地感線圈，攝像單元自動抓拍入場車輛的圖像并自動識別車牌號，記錄出場時間并將車輛信息傳至服務中心，服務中心根據(jù)比對自動判斷車輛性質(zhì)，自動統(tǒng)計調(diào)出相關信息顯示。車輛出場時系統(tǒng)將該車輛的入場信息顯示在崗亭計算機屏幕上，根據(jù)軟件制定的收費方案進行收費金額的統(tǒng)計，以供管理人員對臨時車輛的管理。固定客戶車輛：在入口和出口安裝攝像單元，管理計算機將對應授權通道的車牌信息下載到攝像單元內(nèi)。車輛駛入或駛出停車場時需地感觸發(fā)立體高清車牌識別攝像機抓拍、識別、處理車輛的車牌信息，并將識別結果傳送到管理計算機，管理計算機利用識別結果查詢數(shù)據(jù)庫，如果攝像機與管理計算機斷開連接，攝像機可以脫機工作，不會造成車流的堵塞達到不停車通行。整個停車場系統(tǒng)實行管理中心計算機集中管理，并采用立體高清車牌識別攝像機對進入停車場的車輛進行圖像抓拍，自動識別，引導車輛進入停車場指定的區(qū)域，在停車場出口立體高清車牌識別攝像機對駛出停車場的車輛進行識別，對于固定客戶自動放行，對于臨時客戶根據(jù)停車時間計費，繳費后方可離開，管理中心計算機對整個停車場進行統(tǒng)一的管理，使停車場的管理形成方便，安全，高效的控制體系。道閘采用先進的直流變頻技術，抬桿和落桿速度可以獨立調(diào)節(jié)，可以實現(xiàn)高速抬桿，實現(xiàn)快速通行；慢速落桿，防止砸車、砸人，更安全，避免了傳統(tǒng)道閘抬桿落桿速度相同造成的高速不安全，低速不方便的缺陷。停車場管理軟件主要有SQLServer數(shù)據(jù)庫、服務中心、管理程序、出口崗亭程序、入口崗亭程序及相關硬件設備組成，可以實現(xiàn)車出入停車場自動判斷該車牌的主人是固定用戶還是臨時用戶，根據(jù)收費規(guī)則計算費用及開閘放行，實現(xiàn)不停車通行。1、服務中心：主要是接收所有攝像機的圖片，接收入口通道的記錄，下載車牌等通訊功能。注意：服務中心必須與SQLServer數(shù)據(jù)庫在同一臺計算機上。2、管理程序：進行車牌、通道、權限、收費方案等設置，查詢統(tǒng)計各種報表。3、出口崗亭收費程序：接收出口通道的記錄，顯示出口圖片，查找相應的入口圖片、入場時間，計算停留時間及費用，收費；可以最多監(jiān)控一個入口圖片，遠程開閘。4、入口崗亭監(jiān)控程序：監(jiān)控多個入口的圖片，并可修改車牌，遠程開閘?；ヂ?lián)網(wǎng)金融支付領域，EPC交通支付系統(tǒng)：EPC（ElectronicPicture-catchingCollecting）即電子支付抓拍系統(tǒng)。是指車輛在通過收費站時，通過車輛識別系統(tǒng)實現(xiàn)車輛識別、信息寫入（入口）并自動從預先綁定的哈特支付空間上扣除相應資金（出口），是基于HIEP協(xié)議的一種用于道路、大橋、隧道和車場管理的電子收費系統(tǒng)。電子支付抓拍系統(tǒng)（EPC）是世界上最先進的收費系統(tǒng)，是智能交通系統(tǒng)的服務功能之一，過往車輛通過公路、大橋、隧道等道口時無須停車，即能夠?qū)崿F(xiàn)車輛身份自動識別、自動繳費。在車場管理中，為提高出入口車輛通行效率，建設無人值守的快速通道，免取卡、不停車的出入體驗，正改變出入停車場的管理模式。結合HIEP、HTTP通信協(xié)議上，通過WEB服務，實現(xiàn)車輛電子支付的技術。基于HIEP（HTBInternetE-walletProtocol）哈特支付空間的EPC（ElectronicPicture-catchingCollecting）的設計和實現(xiàn)。哈特支付空間應用于HTML（數(shù)據(jù)外觀顯示互聯(lián)網(wǎng)標準協(xié)議）,它有一套有關于接口的行為規(guī)則，包括全局命名與引用、注冊、通信、信息處理、生命周期等；在整個系統(tǒng)中，我們采用了B/S架構WEB遠程監(jiān)控的方式，通過JAVA語言的跨平臺及其網(wǎng)絡編程的特性，以JNI和SOCKET編程的遠程控制方法，使用編程的方法來實現(xiàn)對廣域網(wǎng)內(nèi)的監(jiān)控節(jié)點的遠程控制，使主機能夠?qū)崿F(xiàn)對遠程設備的監(jiān)控。設計開發(fā)基于三層結構分布式系統(tǒng)的過程；并以壓縮機遠程監(jiān)控系統(tǒng)為背景，運用DCOM、ActiveX和遠程腳本等技術，實現(xiàn)一個EPC具體運用。1.WEB遠程控制的實現(xiàn)1.1遠程控制機（銀行前置交易系統(tǒng)）和現(xiàn)場監(jiān)控設備的互聯(lián)在已有局域網(wǎng)絡基礎上，構成的互聯(lián)系統(tǒng)如圖1所示，實現(xiàn)遠程控制，再由一個基于窄帶多協(xié)議環(huán)境的監(jiān)控系統(tǒng)模型。通過幀率自調(diào)整適應帶寬，并依靠協(xié)議網(wǎng)關進行IPX和TCP/IP之間的數(shù)據(jù)交換，實現(xiàn)遠程監(jiān)控。SHAPE\*MERGEFORMATSSClient首先創(chuàng)建一個客戶端Socket對象，與運行在主機端口10000的服務程序連接，注意端口應大于1024，以免與系統(tǒng)的端口號發(fā)生沖突；主機的IP地址有host變量確定，圍繞BufferedReader的輸入流和PrintWriter的輸出流對字符串進行讀寫操作，用于把服務器傳過來的命令和參數(shù)與其他程序進行交互。在整個程序段中用trycatch語句進行異常捕獲。服務器端的程序編制應與客戶端程序的編制相適應。由于一個遠程控制機可以控制多個現(xiàn)場監(jiān)控設備，所以服務器程序必須采用多線程機制，這也是Java語言的一大特色。該程序段由兩個類組成：主類和線程類。主類負責建立服務器套接字ServerSocket，端口號必須與客戶機的端口號一致，然后通過ServerSocket的accept方法創(chuàng)建一個套接字接口，專門處理與客戶機的通信；線程類用于創(chuàng)建一個新的線程，負責處理各個現(xiàn)場監(jiān)控設備的輸入和輸出請求。當然各個客戶端也可以采用不同的端口號向服務器發(fā)出請求，服務器相應的也創(chuàng)建不同端口號的線程與端口號一致的客戶端進行通信。遠程控制主機服務器程序必須具有與數(shù)據(jù)庫進行動態(tài)交互的能力。數(shù)據(jù)庫中存放著大量的現(xiàn)場數(shù)據(jù)以及控制現(xiàn)場操作的參數(shù)和命令等。服務器程序中的某一線程體負責對數(shù)據(jù)庫的存取、修改和維護等操作，Java語言通過JDBC實現(xiàn)與數(shù)據(jù)庫的連接；使得Java語言能夠通過驅(qū)動程序訪問數(shù)據(jù)庫。1.2JNI具體實現(xiàn)Java語言對監(jiān)控節(jié)點的控制只能采用第三方語言進行，例如C或匯編語言。由于控制機的通信部分用Java語言編寫，為實現(xiàn)對監(jiān)控節(jié)點的控制，Java語言的JNI技術就可以實現(xiàn)與C和C++語言完美無缺地結合，這雖然在某種程度上犧牲了移植性，卻使Java語言能夠和具體的環(huán)境打交道，具備了驅(qū)動硬件的能力。在本系統(tǒng)實現(xiàn)的例子中，EPC的應用和驅(qū)動程序用C語言開發(fā)的，Java語言把C語言編制的程序做成本地方法體。從而實現(xiàn)本系統(tǒng)的控制。對監(jiān)控節(jié)點的驅(qū)動程序用C語言編寫，程序中所采用的函數(shù)大部分是研華公司開發(fā)的C庫函數(shù)，利用這些庫函數(shù)驅(qū)動監(jiān)控設備完成各種功能。把這些程序集成為Java本地方法體，成為用Java語言實現(xiàn)遠程控制的關鍵技術。對于控制機，利用Java集成本地方法。該段程序由主類和本地方法類組成，主類除完成通信部分的程序外，還必須實例化本地方法類，并且調(diào)用本地方法；在定義本地方法類時，必須加上關鍵詞native，并且程序段中有一段靜態(tài)代碼，該靜態(tài)代碼通過系統(tǒng)函數(shù)為本地方法類加載drive庫，再通過本地方法的執(zhí)行去獲取監(jiān)控節(jié)點或數(shù)據(jù)采集器中的數(shù)據(jù)，傳到數(shù)據(jù)服務器。至此，遠端監(jiān)控設備的代碼就基本實現(xiàn)了，其主要包括運行在控制機一端的Socket服務器和本地方法應用，有服務器監(jiān)聽來自遠端（Browser）發(fā)送來的“RUN”命令，Socket服務器根據(jù)傳來的“RUN”命令再調(diào)用由本地方法或運行服務器端的EXE程序控制相應的操作。在數(shù)據(jù)采集應用中，采用JNI方法把讀取采集的數(shù)據(jù)直接插入到后臺數(shù)據(jù)庫，然后采用JDBC訪問數(shù)據(jù)庫顯示在Browse端，由于系統(tǒng)必須先驅(qū)動讀取數(shù)據(jù)，采用線程方法實現(xiàn)延時，保證能在數(shù)據(jù)傳遞完后在Browse端顯示。對于其它嵌入式系統(tǒng)諸如監(jiān)控系統(tǒng)，同樣可以采用本地方法的集成和Socket網(wǎng)絡的通信機制，有效地把控制機和遠程主機通過網(wǎng)絡連接起來，以實現(xiàn)遠程控制。通過底層Socket通信機制發(fā)送不同命令道伺服器端進行對應的處理。由于Java語言的平臺無關性，使得Java在與本地方法的集成中隱藏了大量的技術細節(jié)。2.系統(tǒng)的設計2.1針對EPC前置平臺工業(yè)遠程監(jiān)控系統(tǒng)，系統(tǒng)的結構設計如圖2所示SHAPE\*MERGEFORMAT由于歷史的原因，監(jiān)控設備并不能直接與信息網(wǎng)絡進行通訊，所以在系統(tǒng)的設計過程中，在中間層與監(jiān)控設備層之間增加了工控站，作為三層結構的數(shù)據(jù)服務層。這樣的設計結構可以使得中間層和表示層的開發(fā)完全獨立于工控網(wǎng)絡的具體類型和結構，而工控站在工控網(wǎng)絡與信息網(wǎng)絡的連接中起到了智能網(wǎng)關的作用，屏蔽了工業(yè)控制網(wǎng)。從而，可以完全發(fā)揮三層C/S結構在Internet/Intranet應用中的各種優(yōu)勢。2.2系統(tǒng)實現(xiàn)的關鍵技術根據(jù)以上的設計架構，以壓縮機遠程監(jiān)控系統(tǒng)為實例，該系統(tǒng)以B/S結構實現(xiàn)分布式三層結構，并運用了Microsoft的ASP、DCOM、ActiveX技術和遠程腳本等技術。2.3基于窄帶多協(xié)議EPC監(jiān)控系統(tǒng)實現(xiàn)模型系統(tǒng)可以采用帶寬僅有64Kbps，并且在此信道上還需要運行少量的數(shù)據(jù)傳送應用，因而有效帶寬十分有限。用戶對單幀圖像的要求較高，為了更好地進行動態(tài)幀率和幀圖像調(diào)整，我們采用了定制的Motion-JPEG格式。另外，用戶為了網(wǎng)絡的安全，采用協(xié)議分隔方式，前段運行在一個IPX協(xié)議局域網(wǎng)絡，遠端則是基于TCP/IP的Intranet，所傳輸?shù)臄?shù)據(jù)需要在IPX和TCP/IP間轉(zhuǎn)換。這樣，前端采集和遠端監(jiān)控之間還必須建構一個協(xié)議網(wǎng)關。該系統(tǒng)物理結構上可以劃分為5個部分：1）前端視頻設備；2）前端控制PC；3）通信線路；4）協(xié)議網(wǎng)關；5）遠端控制器。整個系統(tǒng)包含了采集、壓縮、保存、網(wǎng)絡傳送、遠程監(jiān)控等模塊，結構如圖3所示：由于本模型的信源編碼、解碼、傳輸、回放和存儲都是基于軟件實現(xiàn)的，幀率和圖像質(zhì)量因子等參數(shù)都允許用戶動態(tài)調(diào)整，并能通過系統(tǒng)應答實現(xiàn)一定的帶寬自適應，所以可以保證基本的QoS。2.4車輛牌照定位算法本系統(tǒng)對于普通CCD攝像機抓拍圖像進行局部圖像增強處理，獲得理想的車牌特征描述，結合遺傳算法高效，快速的特點在全圖范圍搜索最滿足車牌特征的區(qū)域位置，從而準確定位車牌。1）圖像預處理；2）局部圖像處理；3）特征表述。（二）計費系統(tǒng)的設計1.EPC計費系統(tǒng)的功能：在本項目運營管理中，銀行前置系統(tǒng)（BFS）的網(wǎng)管人員通過EPC計算管理系統(tǒng)對整個EPC計算進行管理，包括所有EPC計算系統(tǒng)中所有的設備或設施的當前工作狀態(tài)和工作參數(shù)、對設備或設施的工作狀態(tài)進行控制（如啟動、關閉）、對工作參數(shù)進行修改等操作。EPC計算系統(tǒng)為了計算EPC用戶提交的用戶作業(yè)，需要在EPC用戶和本地用戶之間，EPC資源和本地資源之間建立聯(lián)系，也就是需要將EPC用戶映射為本地用戶，將EPC資源映射為本地資源，將EPC用戶對EPC資源的使用映射為本地用戶對本地資源的使用。（參考文獻7《Thegrid:BlueprintforaNewComputingInfrastructure》）。這一系列的映射過程將抽象的EPC計算轉(zhuǎn)化為具體的本地計算，EPC系統(tǒng)通過執(zhí)行具體的本地計算以完成抽象的云計算，通過特定的傳輸線路和控制協(xié)議對遠程的網(wǎng)絡設備或設施進行具體的操作。2.EPC計費系統(tǒng)結構為圖4所示：2.1認證模塊：計算機EPC系統(tǒng)中對已實體身份的證明模塊。實體包括資源或用戶，通過HIEP信息認證證書來實現(xiàn)對其認證，HIEP信息認證由可信任的機構進行簽發(fā)，表現(xiàn)為一段信息，這段信息包括了證書擁有者的信息，證書的有效時間和認證模塊的數(shù)字簽名。對所有訪問的用戶或資源，將其信息記錄到記賬模塊中。2.2用戶代理模塊：當用戶需要使用EPC資源進行EPC計算的時候，用戶首先登陸一臺連接到HIEP銀行前置系統(tǒng)的計算機，并連接用戶代理模塊，然后用戶將需要申請的資源信息和需要計算的用戶作業(yè)為他給用戶代理，用戶代理模塊代替用戶完成雙向認證、申請資源、提交作業(yè)、得到結果等工作。2.3資源代理模塊：當一組資源加入EPC計算系統(tǒng)時，資源管理者首先要連接資源代理模塊，該資源代理負責這組資源的雙向認證、分配和回收的工作。資源代理不一定運行在這組資源所屬的節(jié)點上，但是資源代理和它管理的這組資源要在同一個局部信任域內(nèi)。2.4資源分配模塊：一個由EPC計算系統(tǒng)創(chuàng)建的進程，負責資源的管理工作，為了方便對大量動態(tài)資源進行管理，同時簡化復雜的資源分配過程。資源分配模塊向資源代理發(fā)送資源需求信息。所有的資源代理將其所管理的信息發(fā)給資源分配模塊，并在資源更新的時候?qū)①Y源的更新信息發(fā)送給資源分配模塊。該模塊對收到的資源信息進行整理，形成抽象的、邏輯的資源信息。因此，資源分配模塊是個模塊之間信息交流的核心。2.5記賬模塊：該模塊記錄集處理用戶和資源的信息，認證模塊把所有申請加入到該EPC計算系統(tǒng)的用戶和資源的信息寫入記賬模塊，資源分配模塊在用戶完成計算后把提交作業(yè)的信息也寫入該模塊，由該模塊對其進行記錄。3.EPC計費系統(tǒng)的實現(xiàn)3.1計費的流程3.1.1EPC計算系統(tǒng)對資源進行管理，并根據(jù)用戶的情況對資源進行分配，以及各個實體獲得實體證書的過程；3.1.2用戶創(chuàng)建用戶代理與用戶代理提交用戶作業(yè)的過程；3.1.3用戶作業(yè)的計算流程；3.1.4資源的釋放過程。3.2EPC計算數(shù)據(jù)庫的設計與實現(xiàn)：如果我們要管理一個小規(guī)模的EPC，在記賬模塊數(shù)據(jù)庫中記錄用戶信息、資源信息、用戶使用資源的信息。我們不僅要保證數(shù)據(jù)存儲的方便快捷，更要保證數(shù)據(jù)的一致性和完整性，整個計費系統(tǒng)是由多個線程組成的，他們通過一個共享內(nèi)存交換信息，由于多個進程要同時訪問共享的內(nèi)存區(qū)，就會產(chǎn)生共享訪問的沖突。解決共享訪問沖突的一般方法是采用加鎖機制來解決，然而對共享內(nèi)存的加鎖解鎖必定會占用很大系統(tǒng)資源，從而會影響EPC系統(tǒng)的性能，因此我們通過合理安排系統(tǒng)中各進程的讀寫區(qū)域，避免兩個進程同時修改一個內(nèi)存單元，就可以防止共享沖突并且不需要進行加鎖解鎖操作。我們設計數(shù)據(jù)庫內(nèi)的數(shù)據(jù)格式如下表1-3所示：表1:htb用戶信息表名稱類型字節(jié)數(shù)含義htbuser_idString16用戶代號，是該用戶登錄EPC的標志，是唯一的主關鍵字user_typeChar1用戶類型，是一般用戶還是特殊用戶usercer_idString16用戶證書號，記錄用戶的認證信息stateChar1當前狀態(tài)，是合法用戶還是非法用戶表2：htb資源信息表名稱類型字節(jié)數(shù)含義htbres_idString16資源代號，該資源加入到EPC代號，是唯一的主關鍵字res_typeChar1資源類型，是普通資源還是專屬資源rescer_idString16資源證書號，記錄資源的認證信息in_timeTimestamp8資源加入到云系統(tǒng)的時刻out-timeTimestamp8資源退出該云系統(tǒng)的時刻表3：htb用戶資源映射表名稱類型字節(jié)數(shù)含義htbuser_idString16用戶代號，使用EPC用戶的代號，是候選關鍵字之一htbres_idString16資源代號，在該進程中資源的代號，是候選關鍵字之一fluxLong32用戶使用資源進行計算時的流量start_timeTimestamp8用戶開始使用資源的時刻end_timeTimestamp8用戶結束使用資源的時刻timeTime8當前狀態(tài)，是合法用戶還是非法用戶為避免內(nèi)存共享沖突，各個表之間的關系如圖5所示：為了預防共享訪問沖突，我們安排不同的進程寫不同的區(qū)域，其中，htbuser_id，user_type由用戶代理進程只寫的；htbres_id,res_type,in_time,out_time由資源代理進程只寫的；usercer_id,state,rescer_id是由認證進程只寫的；flux,start_time,end_time是由資源分配進程只寫的。這些區(qū)域只會在一個進程中執(zhí)行寫操作，其他進程只讀，所以不會出現(xiàn)共享沖突，在一定程度上保證了數(shù)據(jù)庫的安全性。（三）逃費抓拍系統(tǒng)第一種情況：車輛為合法身份，使用正常繳費第二種情況：車輛為合法身份，但不能正常繳費（包括抗拒繳費），則記錄到黑名單服務器CRLs；第三種情況：車輛為不合法身份，強行通過EPC通道的，將記錄到黑名單服務器CRLs；在本項目中逃費抓拍系統(tǒng)是在發(fā)生后兩種情況下的客戶端行為記錄到黑名單服務器。當發(fā)生第二種情況是，由該哈特支付地址的結算銀行自動進行扣費或處罰；當發(fā)生第三種情況時，將該車輛信息移交交警部門處理。在本項目實施中，根據(jù)XHSI（X.509V3私有擴展項HIEP信息認證體系），用于提供支持HIEP的基礎安全服務。HIEP擴展項中使用X.509數(shù)字證書提供認證和消息保護。對第二種情況采用的是證書撤銷列表CRL的方式。這里采用的是基于XHSI單向哈希鏈、HIEP擴展項和CRLs共享模式的聯(lián)合撤銷方案，其優(yōu)點是：證書撤銷時不需要CA的參與，能較好地解決單點失敗和CA交叉認證的問題，可以避免通信擁塞和確保證書撤銷的實時性。1.HIEP擴展項聯(lián)合證書撤銷方案：證書撤銷的情況有兩類：第一類是與公鑰對應的私鑰丟失或泄露；第二類是證書合同可能終止，或者證書中描述的持有者的身份改變或業(yè)務信息被撤銷。本方案使用的單向哈希鏈，對于上述的第一類情況，可以不需要CA的參與而使證書暫時或永久失效。對于第二類情況，可以使用HIEP擴展項和CRLs共享模式來實現(xiàn)違法計費。2.基于單向哈希鏈的新型證書哈希鏈基于一個公開的函數(shù)H，該函數(shù)在現(xiàn)有的計算環(huán)境下很容易進行正向計算但幾乎不可能進行反向計算。如果單向函數(shù)的輸入是定長的，這就是單向哈希函數(shù)（OWHF）。我們把一個證書的最大的生命值分成多個小段。證書可以在任何一個時間段結束時過期，過期可以由證書的所有者或者其管理者控制。證書驗證者不用從CA獲取撤銷信息就能驗證證書的有效性。因此，這種撤銷機制簡單而安全。單向哈希鏈通過輸入一個字符串到一個單向哈希函數(shù)進行遞推來建立，可以表示為Hi(r)=H(Hi-1(r))(i=1,2,…)，在這里H0(r)=r是哈希鏈根。證書更新時間點定義為：D1=D+L,D2=D+2*L…,Dj=D+j*L，并產(chǎn)生一個單向哈希鏈Hi(r)=H(Hi-1(r))(i=1,2,…j)，H0(r)=r且r是一個僅為用戶U所知的隨機數(shù)。最后用戶發(fā)送請求（PK1,D,Hj(r),j,L）到CA。CA認證用戶的請求并生成證書（PK1,D,Hj(r),j,L）。與傳統(tǒng)的公鑰證書相比較，證書CERTu包含額外的數(shù)據(jù)（Hj(r),j,L）。如圖6所示，用戶從CA接受證書后可以釋放Hj-1(r)來初始化證書的有效性。如果用戶因為某種原因需要撤銷證書，可以停止釋放哈希值使證書在下個更新點過期。用戶甚至可以使證書暫時失效，然后在需要時重新釋放相應的哈希值來更新證書。3.HIEP多重證書描述為了解決單點失敗和CA交叉認證的問題，我們提出了一個叫做多重證書的新的證書機制。我們把幾個CA組成一個虛擬的組織（VO）。一個CA頒發(fā)證書時，該虛擬組織中的其他成員根據(jù)預定的順序?qū)ψC書的內(nèi)容簽名，并各自產(chǎn)生一個包含原始證書內(nèi)容和CA自身簽名的輔助證書。例如，如上圖所示，用戶發(fā)送其證書請求道CA。如果CA認證了該請求，將頒發(fā)一個證書。同時，輔助CA1也將對該證書簽名產(chǎn)生輔助證書1，然后輔助CA2對輔助證書1簽名產(chǎn)生輔助證書2，依次類推。因此，只需要獲得任何一個輔助證書就可以驗證一個證書的有效性，而不需要直接和頒發(fā)該證書CA直接通信。4.CRLs共享模式EPC應用中有數(shù)量巨大的用戶和資源。每個用戶和資源都持有一個證書。當他們的證書需要撤銷時，會給CA帶來龐大的CRLs。CA的服務器將成為整個系統(tǒng)的瓶頸，網(wǎng)絡時延增加，用戶無法及時獲得證書撤銷信息。另外，由于EPC節(jié)點是動態(tài)的，必須確保所有的節(jié)點在即使列表服務器暫時不可用的情況下也能可靠地獲得最新的CRLs。根據(jù)EPC的這一特性，本項目提出CRLs共享模式。每個EPC節(jié)點從CA的目錄服務器下載CRLs，然后以EPC服務的形式發(fā)布。EPC節(jié)點根據(jù)按照先其他節(jié)點后CA的規(guī)則查找和獲取CRLs。CA用自己的私鑰對CRLs簽名，以確保CRLs不被篡改。5.結論針對第一種車輛情況，可以使用單向哈希鏈的新型證書來實現(xiàn)。針對第二和第三種車輛情況，可以使用HIEP多重證書來實現(xiàn)。整個方案，是通過CRLs共享模式來實現(xiàn)?；谠摲桨傅膬?yōu)點：5.1證書撤銷自主實時因為證書基于單向哈希鏈頒發(fā)，用戶可以用停止釋放哈希值的方法使證書暫時或永久失效。這將給用戶使用證書帶來更好的自主性和安全性。同時也減輕了CA在通信和處理上的負擔，可以提高撤銷的實時性。再加上采用了CRL共享模式，可以更好地適應EPC計算分布、動態(tài)的特點，保證所有節(jié)點都能及時獲得最新的撤銷信息。5.2證書管理簡單可靠由于采用了HIEP多重證書頒發(fā)機制，不同CA頒發(fā)的證書可以進行相互認證，而且用戶不直接訪問證書的頒發(fā)CA就可以驗證該證書的有效性，避免了EPC系統(tǒng)的單點失敗。（四）EPC銀行前置系統(tǒng)BFS1基于Scilab的分布式BFS并行計算方法的實現(xiàn)。基于Schab[3]運算引擎，以OpenBFS/webBFS為背景，涉及BFS環(huán)境下分布式并行計算工具（NetbutterflyhtbBFSComputingSystemNBFS）以支持BFS進行大規(guī)模科學計算的實現(xiàn)平臺。1.1NBFS的分布并行計算結構如圖7所示：由多個提供BFS服務的BFS計算機節(jié)點組成一個虛擬的并行機。它可以完成由BFS客戶提交的并行計算任務。每個BFS計算節(jié)點即并行計算的一個節(jié)點，提供一個或一些可以并行執(zhí)行等任務的并行BFS服務。作為對運算資源的完整封裝，BFS計算節(jié)點用來完成具體的計算任務，他使用Scilab作為算法描述語言?？梢越档褪褂谜呙枋隹茖W計算問題的難度。計算服務層（虛擬并行機）抽象了計算能力，當計算任務被接受時，它就會自動尋找合適的計算資源來完成。應用層主要是用來對計算服務進行有效使用和管理，處理多應用協(xié)調(diào)等問題。通過WEBHTB（哈特支付空間）并行的調(diào)用OPENHTB（哈特支付空間）的服務實例。1.2NBFS設計構架1.2.1NBFS應用結構模型如圖8所示：數(shù)據(jù)容器主要存放在并行程序和應用數(shù)據(jù)。運算容器包括N個資源節(jié)點，為系統(tǒng)提供計算能力，資源目錄服務包括運算資源服務和數(shù)據(jù)資源服務，NBFS運行時節(jié)點把編輯好的任務交到數(shù)據(jù)容器，數(shù)據(jù)容器與運算容器通過目錄服務來發(fā)現(xiàn)所需資源，直到運算完成。1.2.2服務器系統(tǒng)設計NBFS在無力實現(xiàn)行采用了核心服務器組結構?？蛻舳思仁琴Y源提供者又是資源調(diào)用者，系統(tǒng)內(nèi)的計算資源來自于客戶端資源的有效聚集。NBFS的服務器采用擴展的集群設計，各個模塊可以分別運行。服務器組結構如圖9所示。1.2.3客戶節(jié)點設計NBFS的客戶節(jié)點包括任務接入界面和ScilabBFS計算虛擬機。任務接入界面是用戶申請進入NBFS的接口，用戶通過任務接入界面把任務提交到NHCS系統(tǒng)，ScilabBFS計算虛擬機是NBFS的運行節(jié)點，它為系統(tǒng)提供運算能力?？蛻艄?jié)點分任務模式和計算模式。前者為節(jié)點向系統(tǒng)提交計算任務并等待完成過程，后者為節(jié)點向系統(tǒng)提供計算服務。所以，它支持從微機到巨型機的任何機種，從Windows到Unix和Linus以及將來可能出現(xiàn)的任何操作系統(tǒng)，極大地便利了異種機之間的網(wǎng)絡并行，從而可以充分的利用現(xiàn)有的網(wǎng)絡資源進行分布并行計算。1.2.4系統(tǒng)編碼設計本系統(tǒng)采用了Scilab語言作為科學計算腳本描述語言。Scilab是由法國成立自動化研究院（INRIA）和EBFS開發(fā)的“開放源碼”軟件，使用Scilab作為應用腳本語言有利于計算任務的快捷描述和使用者快速掌握，從而提高了使用者對科學計算問題的描述效率。由于NBFS的應用程序采用了解釋為執(zhí)行的方式，使得NBFS的應用腳本可以在不同平臺的NBFS節(jié)點直接運行，在不同操作系統(tǒng)節(jié)點中共同運行一個并行程序，具有良好的異構擴展特性。為了使Scilab適用于網(wǎng)絡化的并行計算，系統(tǒng)增加了遠程數(shù)據(jù)讀寫指令NBFS-RD和NBFS-WS，去掉了磁盤操作等可能危害客戶機的危險指令，整個運算并程序的入口是Mainnhcs文件，其他程序作為過程被調(diào)用。Mainnhcs是一個描述任務流的文件。語法上只有兩個關鍵字NBFS-CX和NBFS-END。NBFS-CX:程序的條件執(zhí)行，當表達式X為真時，系統(tǒng)并行執(zhí)行NBFS-CX語句內(nèi)的所有函數(shù)。NBFS-END運算結束，此條指令一般用來結束系統(tǒng)任務，系統(tǒng)執(zhí)行到此語句時對所分配資源進行釋放，應用完成。當表達式X為真時，整個運算任務結束。向任務提交者發(fā)出結束標志。1.3.關鍵技術1.3.1任務并行NBFS并行調(diào)度語言，對任務關系描述，將人們對問題的分解自然的對應程序中的各級任務，并行編程自然、清晰，同時，任務并行綜合了數(shù)據(jù)并行和功能并行的優(yōu)勢，在支持較高并行度的前提下，能夠有效的處理不規(guī)則問題。可以較方便的將串行程序改寫為并行程序。系統(tǒng)把數(shù)據(jù)和操作封裝成不同的任務以實現(xiàn)并行化。當多個任務具有相同操作，不同數(shù)據(jù)實現(xiàn)數(shù)據(jù)并行，當多個任務具有不同操作時實現(xiàn)功能并行。每個任務分不到一個BFS節(jié)點，基于Scilab的分布并行計算可以擴展并性計算環(huán)境到OPENHTB（開發(fā)式HTB哈特支付空間）網(wǎng)絡節(jié)點為并行計算節(jié)點的廣域網(wǎng)絡中，這樣，可并行計算的任務能被分布到BFS上多個計算資源上，系統(tǒng)性能將大大提高。1.3.2系統(tǒng)通信系統(tǒng)通信涉及兩個方面：一是并行計算節(jié)點之間的通信，主要是完成并行計算的各BFS計算節(jié)點上的BFS服務之間的數(shù)據(jù)通信和同步信息交流，另一個是BFS服務于客戶之間通信?？梢杂脕韺崿F(xiàn)BFS服務之間通信和BFS服務與客戶的通信。通信機制有兩種實現(xiàn)方法：PUII方法和PUSH方法。其中push方法允許數(shù)據(jù)和通知一起傳輸，這種通信方式效率高，對于并行計算這種性能優(yōu)點需求來說，可以采用這種方式。此外，由于BFS服務是基于TCP/IP這種底層通信方式，因此，通信效率較高。為了實現(xiàn)NBFS在internet下的通信，NBFS采用了SOAPV1.2標準并對其進行封裝。SOAPV1.2為在一個松散的，分布的環(huán)境中使用XML對等的交換結構化和類型化的信息提供了一個簡單且輕量級的機制。SOAP本身并不是定義任何應用語言，他只是定義了一種簡單的機制，通過一模塊化的包裝的這項能力使得它可以被很多類型的系統(tǒng)用于從消息系統(tǒng)到RPC(RemoteProcedureCall)的延伸。NBFS擴展了Scilab對SOAP進行了封裝，在Scilab中加入了SOAP-EH的數(shù)據(jù)操作指令，NHCS-SOAPEH,使得用戶可以訪問系統(tǒng)各數(shù)據(jù)緩存中的數(shù)據(jù)信息，實現(xiàn)分布式內(nèi)存對用戶的透明性。NHCS-SOAP指令NHCS-SOAEH.有兩個參數(shù)：【TYPE】決定了系統(tǒng)執(zhí)行的操作模型：數(shù)據(jù)讀取或者數(shù)據(jù)寫入：【Name】為需要處理的變量名稱，由以字母打頭的字符串表示，當前面加“#”時表示為數(shù)據(jù)指針操作，前面無“#”時表示值操作。1.3.3容錯機制理想狀態(tài)下網(wǎng)絡具有以下特征：較短的通信延時，較高的通信帶寬，極低下的錯誤率，較好的擴展性。而現(xiàn)實情況是難以容忍的延時，有限的帶寬，隨機可能的出錯，因此建立基于互聯(lián)網(wǎng)的分布并行運算膝蓋痛必須有一套與元相對應的容錯機制來適應。該計算環(huán)境是由分布的若干臺計算機用Internet連接而成。一個單元或資源的故障不影響其他資源的正常功能理論上，可以通過全局的檢查來實現(xiàn)BFS的容錯。但實現(xiàn)難度大。可行的方法是通過應用程序本身來實現(xiàn)容錯的功能，可以再發(fā)生故障的情況下，使用不可靠的故障檢測器無法解決NB-AC問題，所以對減弱他的非平凡性條件，得到NB-WAC問題，然后用HB將他歸約到一致合意問題，再用HB求解一致合意問題，從而完成對NB-WAC問題的求解。使用HB進行求解，能夠在包含進程故障和鏈路故障的異步消息傳遞系統(tǒng)中解決NB-WAC問題，而目前所知道的其他傳統(tǒng)的故障檢測器只能解決僅包含進程故障的NB-WAC問題。該方法適用于每對不同的正確進程都通過一條BFS通道連接情況，從而實現(xiàn)BFS容錯目的。1.3.4安全問題由于采用SOAP進行底層通信，NBFS應用可以部署的范圍大為擴大，但在運行過程中暴露節(jié)點地址在所難免，節(jié)點安全問題和數(shù)據(jù)安全問題成為制約系統(tǒng)部署的主要問題。目前可以采用的策略是有限的不可傳遞的信任原則，節(jié)點對主控系統(tǒng)的信任以任務為單位分配，并且任務腳本不能訪問節(jié)點的文件系統(tǒng)，只能對系統(tǒng)規(guī)定的內(nèi)存進行讀寫。2.其余XML模型的支持多終端的MVC模式實現(xiàn)方式目前最典型的一種MVC模式實現(xiàn)方式，是利用了SUN公司的J2EE技術。J2EE技術主要包括Servlet.JSP.JavaBean.EJB,Filter等部分。在MVC模式實現(xiàn)中，一般JSP對應視圖，系統(tǒng)通過JSP提供的界面來與用戶交互。JavaBean或EJB對應模型，處理業(yè)務邏輯，控制器由于Servlet來實現(xiàn)，作為模型與視圖間的樞紐。不過，這種實現(xiàn)方式有以下不足之處：由于JSP在頁面中嵌入Java語言，造成視圖和控制器的混合，破壞了MCG設計模式的風格，這種方式的缺陷使得開發(fā)和維護變得很困難。該實現(xiàn)方式可以支持多種客戶端瀏覽器類型，但針對每一種特定的客戶端類型都要一個表示層接口。例如相同的業(yè)務邏輯，針對單面瀏覽器，需要一套JSP頁面形成HTML格式的表示層視圖。而對于使用哈特支付空間的手機，則需另外一套JSP頁面生成HIEP格式的表示層視圖。代碼冗余，不易擴散。JavaBean或EJB一般都是與特定的數(shù)據(jù)庫相關的，如果改變或添加數(shù)據(jù)資源類型或需要多種異構數(shù)據(jù)資源集成，則可能需要重新改寫代碼，可重用性和擴展性比較差。為此，考慮到BFS所面對的是一個物理上分散的，異源的，異構的數(shù)據(jù)環(huán)境和不同的終端用戶，為了使其能夠勝任不同應用系統(tǒng)之間或者不同數(shù)據(jù)源之間實現(xiàn)數(shù)據(jù)共享與交互，即客戶端和服務器端雙向數(shù)據(jù)交流。采用一種基于XML模型的實現(xiàn)方式，即使用XML虛擬數(shù)據(jù)庫代替JavaBean/EJB作為MVC模式的模型實現(xiàn)，同時，由終端識別模塊J2MEMIDP（移動中間件平臺）識別終端類型，并通過XSLT樣式表轉(zhuǎn)換處理器來統(tǒng)一動態(tài)生成適合終端顯示的最終視圖。系統(tǒng)體系結構如圖10所示，給予XML模型的MVC模式實現(xiàn)方式。2.1設計與實現(xiàn)2.1.1控制器部分設計控制器仍然由Servlet來完成，其實現(xiàn)過程如下：獲取來自客戶端的請求（客戶端可以為桌面瀏覽器，收集或PDA產(chǎn)品等等）終端識別模塊J2ME（手機平臺）通過捕獲HTTP請求頭來判斷終端類型。在HTTP請求中，UserAgentHTB（MIDP移動信息設備間表）Accept（用戶終端可以接受的MIME文件類型）這兩個消息頭與終端類型有關。通過維護一個User-Agent和可接受的MIME類型的字典來完成對終端的識別。訪問模型數(shù)據(jù)XML虛擬數(shù)據(jù)庫。將終端類型識別結果及對XML虛擬數(shù)據(jù)庫訪問的結果數(shù)據(jù)置context對象或請求session中，供視圖部分來訪問。控制權轉(zhuǎn)交給視圖來處理。2.1.2模型設計圖11所示是一個XML虛擬數(shù)據(jù)庫設計與實現(xiàn)。由XML虛擬數(shù)據(jù)庫來實現(xiàn)XML虛擬數(shù)據(jù)庫充當數(shù)據(jù)總線，完成與實際數(shù)據(jù)資源（可以為各種傳統(tǒng)關系數(shù)據(jù)庫，純XML文檔或其他資源類型）交互，屏蔽掉各數(shù)據(jù)源的差異，提供一致的數(shù)據(jù)視圖。設XML虛擬數(shù)據(jù)庫提供必要的數(shù)據(jù)轉(zhuǎn)換功能或工具，進行各資源與XML格式數(shù)據(jù)的相互轉(zhuǎn)換，并維持XML數(shù)據(jù)與各異構數(shù)據(jù)源之間的映射關系。XML虛擬數(shù)據(jù)庫從控制接受XML格式請求，并生成XML格式相應，供視圖部分使用。其核心部分為：虛擬數(shù)據(jù)庫引擎和數(shù)據(jù)集成配置文檔。數(shù)據(jù)集成配置文檔數(shù)據(jù)集成配置文檔是一個自定義的XML格式配置文件，它在虛擬數(shù)據(jù)中占有非常重要的位置，它定義了請求，響應文檔的語法結構，動態(tài)查詢分解，合并規(guī)則及對數(shù)據(jù)庫的相關操作。該配置文檔的主要元素與屬性值如下表1所示：在表中，</htbdate元素與/HTBQUERY>元素相類似。虛擬數(shù)據(jù)庫引擎解析數(shù)據(jù)集成配置文檔，并根據(jù)解析后的配置信息對請求進行驗證，分解、執(zhí)行、合并，并最終形成格式規(guī)范的XML文檔。屏蔽各異構數(shù)據(jù)源的差異主要在這里完成。2.2視圖視圖是模型的外表在表現(xiàn)，通過XSLT處理器，并結合XSLT（ExtensibleStylesheetLanguage，可擴展樣式語言）樣式來統(tǒng)一動態(tài)生成適合終端顯示的視圖。XSL樣式表用于定義一系列的轉(zhuǎn)換規(guī)則，描述如何顯示XML文檔。XSLT處理器提供了一種通用的方法，可以將源XML文檔轉(zhuǎn)換成為各種客戶終端能識別的輸出格式，包括HTML-HIEP的格式。XSLT處理器的輸出格式是由XSL樣式定義的轉(zhuǎn)換規(guī)則決定。不同的客戶端類型，對應的XSL樣式表不同。生成最終提供給用戶的視圖的過程如下：從context或session中獲取XML業(yè)務數(shù)據(jù)和用戶終端瀏覽器類型。根據(jù)瀏覽器終端類型選擇適當?shù)腦SL樣式表，并經(jīng)過XSLT處理器對XML業(yè)務數(shù)據(jù)進行格式轉(zhuǎn)換處理后，形成最終的HTML-HIEP的格式視圖。向客戶端設備提交視圖。2.3該結構優(yōu)勢模型使用XML虛擬數(shù)據(jù)庫，如果需要添加資源類型，那么只需增加XML虛擬數(shù)據(jù)庫與該種數(shù)據(jù)資源的映射和轉(zhuǎn)換即可，實現(xiàn)了數(shù)據(jù)資源即播即用。同目前典型的MVC模式實現(xiàn)方式中JSP內(nèi)嵌入Java代碼，從而造成控制器與視圖混合不同。該結構種，視圖中的XML樣式表只用來定義顯示格式，實現(xiàn)用戶界面設計，從而實現(xiàn)了模型，控制器，視圖的徹底分離。這樣開發(fā)人員可以清晰角色劃分，各部分得重要性金額可維護性大大提高。另外，這種構架采用統(tǒng)一的方式有XSLT處理器進行轉(zhuǎn)換處理，生成最終適合終端顯示的視圖。這樣系統(tǒng)表示層接口就可以支持多種客戶終端。當需要加入新的客戶端類型時，無需改變表示層接口，只需增加相應的XSL樣式表即可，代碼非常簡潔清晰，而且可以獲得更好的模塊化和伸縮性。開通EPC服務工作界面的演示如圖12所示。當前第1頁1 2 3