序論：寫作是一種深度的自我表達。它要求我們深入探索自己的思想和情感，挖掘那些隱藏在內心深處的真相，好投稿為您帶來了七篇接口設計論文范文，愿它們成為您寫作過程中的靈感催化劑，助力您的創作。

篇(1)

1．1接口描述當傳感器網絡的Zigbee網關節點不斷地將網絡節點中監測到的溫度、煙霧等信息發送給上位機時，上位機的通信模塊必須及時響應接收數據。數據監測上位機通信接口采用VB6．0中MSComm控件，利用串行端口傳輸和接收數據，為應用程序提供串行通信功能，具體包括2種處理通訊方式，一種是事件驅動通訊，利用OnComm捕獲并處理通訊時間；另一種是通過檢查CommEvent的值，來查詢事件和錯誤［5］。設計中采用第1種方式，在用戶界面設置好相應的控制參數，如波特率為38400bps、無校驗位、8數據位、1位停止位等。當傳感器網絡節點監測的的溫度、煙霧等信息發送給上位機時，將觸發監測程序中MSComm控件的OnComm事件，進而改變ComEvent的值，程序根據ComEvent的值執行相應的操作，如解析數據、發送數據、錯誤分析等，然后更新內存節點樹中當前節點的實時數據、采集信息（如溫度、煙霧等）存入數據庫。

1．2實現方法MSComm控件可以設置以二進制或者以文本方式接收，若設置為二進制接受，控件會自動將其轉變成十進制。在該系統中，數據幀的數據是十六進制的，設置以二進制方式進行接收，從接收緩存中獲取到的是十進制的數據。

2數據結構與數據解析

2．1內存中節點多叉樹的建立圖2節點數據結構圖通信監測模塊接收數據后，為了便于以圖形方式實時顯示網絡拓撲和節點監測信息，以及提高查詢數據的運行速度，需要在內存中構建一個動態多叉樹，用于存儲節點最新的數據信息。節點數據結構圖如圖2所示。在內存中建立一個關于節點的動態多叉樹，節點的唯一標識是它的自身ID，根據數據幀中包含的父子關系可構建出一棵多叉樹。首先定義一個名為treeNode的類，它的每一個實例都代表著一個節點，里面包含節點的屬性（例如ID、溫度、煙霧等）和方法（例如獲取類中節點數據的getData方法）。為了將節點間的父子關系表現出來，可在類treeNode中定義一個類型為treeNode的動態數組NodeChild（），用于存放子節點。如某節點ID為0000，子節點ID為0001，將子節點0001存放在節點0000的NodeChild（）數組中，即可完成節點間的連接。當需要找某個節點時，從根節點開始查找，若根節點的孩子沒有要找的節點，則查找根節點的孩子的孩子，直到遍歷完所有節點。當某數據幀發送到上位機時，解析出來的原始數據分別放在相應的變量，假設原始的溫度數據是3F4A，數據結構中溫度變量名為Temperature，類型為String，則直接將3F4A轉換為String類型存在Temperature中。按上述方法構建的動態多叉樹能夠適應網絡拓撲動態變化的應用場景，相比于定長的數組，其更為節省內存，不足之處是查詢算法較復雜。

2．2數據解析通信監測模塊接收到Zigbee網關節點發送來的一組數據（數據幀）后，需要對收到的數據進行協議解析，然后根據解析數據建立當前動態多叉樹。由于通信中難以避免數據幀出錯、截斷、丟失等情況，故數據解析部分根據數據幀的格式制定了一套協議，丟棄異常數據幀。數據幀的部分格式如下：FFXXXXXXXXFF01XXXX02XXXX2FF之間，開頭2個字節為節點ID，緊跟的2個字節節點的父ID01代表溫度類型，后面2個字節是溫度數值02代表煙霧類型，后面2個字節是煙霧值，依次類推…。2個FF后的字節都是數據，其格式如下：數據類型（01，溫度類型）＋2個字節的數據（XXXX）。具體操作流程如圖3所示。首先檢驗從串口進來的數據幀開頭一個字節是否FF，若是，則開始解析。直到下一個FF，則節點ID部分解析結束，后面都是數據。繼續讀取下一個字節，若為01，則將后面緊跟的兩個字節存進相應的溫度變量，讀取下一個字符；若該字節所表示的數據類型未定義則跳過該字節及后面緊跟的兩個字節，繼續讀取下一個字符。該過程一直執行直到解析完整個數據幀。由于數據幀是不定長的，而且沒有結束字符，所以每收到一個數據幀程序便立即從緩存中讀取并解析，以避免多個幀合并為一個數據幀導致解析錯誤。當出現多個數據幀并合情況時，則丟棄后繼的幀。在幀解析完畢后，可以對解析出來的監測數據信息進行處理，將數據信息一份存進內存中節點多叉樹，一份存進數據庫，實現實時更新數據和記錄當前信息。以下是有關串口通信事件響應及數據解析的部分代碼：

3數據庫的構建與連接

3．1數據庫關系數據庫關系圖如圖4所示。由于每個節點都有大量歷史數據，所以每一個節點都創建一個表；USERS表用于保存監測系統的用戶信息；NodeTran用于保存數據幀轉發路徑；Nodelist用于保存節點列表；Limit用于保存監測系統的閾值管理設置值；Node＿XXXX為節點XXXX的歷史數據表。除了用戶表，所有數據都采用varchar類型。

3．2存儲過程的創建為了提高通信監測模塊與數據庫之間通信的效率，將一些常用且較為復雜的SQL語句存放在數據庫中，使用時只需要調用存儲過程，輸入必要的參數即可完成相應的SQL語句操作，這樣可以大大減少程序與數據庫之間的通信量。

3．3使用ADO將VB6．0與SQL2005連接ADO是為Microsoft最新和最強大的數據訪問范例OLEDB而設計的，擁有一個易于使用的應用程序層接口。通過使用ADO2．0對象模型中的Recordset和Connection對象實現兩者連接和數據的存取。Connection對象包含關于某個數據提供程序的信息，如數據庫用戶、密碼、數據庫名等；Recordset對象包含某個查詢返回的記錄，可以創建一個Connection對象，在同一個連接上打開多個Recordset對象［8］。操作流程圖如圖5所示。

4結語

篇(2)

地面測試臺的測試對象為某采編存儲器。測試臺的主要功能包括向采編存儲器提供模擬信號供其采集，向采編存儲器下發控制命令，接收采編存儲器下發的高速LVDS實時數據并進行后續處理。測試臺的整體結構如圖1所示。CPCI總線上掛有3個CPCI板卡，分別為CPU卡、接口卡、信源卡。其中，CPU卡為處理系統，接口卡和信源卡為功能卡。本文將以接口卡為主要依據來介紹如何以FPGA邏輯控制來實現CPCI局部總線接口和高速LVDS接口。

2LVDS高速數據接口實現

2．1LVDS接口硬件電路設計由于趨膚效應和介質損耗，高速信號在傳輸過程中會衰減。因此，當傳輸距離較長時，往往要使用電纜驅動器和均衡器來保證高速數據傳輸的準確性。電纜驅動器將信號以最大功率耦合到電纜上［4］，延長信號的傳輸距離，電纜均衡器可以對傳輸的信號進行高頻補償，以至達到標準邏輯電位。本設計中，LVDS串行器/解串器分別選用TI公司的SN65LV1203和SN65LV1224，信號驅動器/電纜均衡器分別選用NS公司的CLC001和CLC014。LVDS接口電路結構如圖2所示，采編存儲器的FPGA控制LVDS串行器將10bit并行數據轉換成差分串行數據，再通過電纜驅動器將信號耦合到電纜上。地面測試臺的電纜均衡器對接收到的信號進行高頻補償之后傳送給解串器，解串器根據參考時鐘將差分串行數據轉換成10bit的并行數據，由FP-GA進行后續的處理。

2．2FPGA邏輯控制LVDS數據接收由于CPCI接口傳輸的時鐘和LVDS數據接收電路的時鐘不匹配，為了保證數據傳輸的可靠性，在編寫VHDL語言程序時FPGA內部調用一個異步時鐘控制的緩存FIFO［8］IP核來對接收到的LVDS高速數據進行緩存，如圖2所示。上位機通過配置PCI9054的傳輸計數寄存器，將一次DMA傳輸的數據量設置為2kbyte。寫FIFO的時鐘為18．432MHz，讀FIFO的時鐘為36．864MHz，當FIFO內數據量達到2kbyte時，FPGA立即通知上位機啟動一次DMA傳輸。經計算，從FIFO內讀走2kbyte數據大約耗時54μs，在這個時間段內寫入FIFO的數據量大約為1kbyte，所以，當DMA傳輸結束時，FIFO內數據不足2kbyte，上位機直到FIFO內數據量再次達到2kbyte時才會啟動下一次的DMA傳輸。為了避免PCI9054不能立即執行DMA傳輸而導致FIFO數據溢出，FIFO容量要大于2kbyte。本設計中選擇容量為4kbyte的FIFO，經驗證，不會出現FIFO溢出現象。

3CPCI局部總線接口實現

實現CPCI接口協議一般有兩種方法。其中一種方法為:利用FPGA實現接口邏輯。這種方法雖然可以充分利用FPGA的資源，減小成本，但PCI邏輯十分復雜，可靠性不能得到保證，且開發周期長。另外一種方法為:采用專用的PCI接口控制芯片。專用接口芯片功能強大，性能穩定，設計方便，很大程度上減少了設計者的工作量，縮短了開發周期。所以，本設計中選擇使用PCI9054接口控制芯片與FPGA配合工作的方式來實現CPCI局部總線接口通信。

3．1EEPROM的配置在Windows環境下，為有效管理多塊CPCI板卡資源，實現多卡協同工作。通過設置EEPROM配置選項中的ClassCode/REV值，解決使用同一驅動情況下，多塊CPCI板卡識別問題。地面測試臺含信源卡和接口卡兩塊CPCI功能板卡，圖3為接口卡的EEPROM配置文件截圖，各板卡需要設置不同的ClassCode/Rev(圖中紅色選框部分)，上位機程序通過識別不同的ClassCode/Rev達到控制不同板卡的目的。ClassCode/Rev為一個32bit數據，規定高8bit作為不同板卡區分標志，低24bit保留。其中D31～D28功能標識，區分是否為信源卡、接口卡等功能卡。D27～D24數量標識，區分當前功能卡的數量，具體約束如下表1所示。

3．2CPCI局部總線實現方法

3．2．1PCI9054工作模式選擇PCI9054總線控制芯片有3種工作模式，即M模式、C模式、J模式。其中，C模式最為簡單，類似于單片機的工作方式，它的地址線和數據線分開使用，可以很方便地控制本地時序。所以本設計中PCI9054工作于C模式，由FPGA邏輯控制本地時序來完成CPCI局部總線與功能板卡之間的通信。

3．2．2CPCI總線訪問本地總線PCI9054的訪問方式選擇DMA方式。PCI9054作為主控設備，通過內部的DMA控制器來實現局部總線上數據與CPCI總線上數據的傳輸。在DMA訪問方式下，一個總線周期的時序如圖4所示。當CPCI總線訪問本地總線時，PCI9054內部的DMA控制器發出LHOLD信號來申請控制局部總線，當其收到響應信號LHOLDA后，才獲得局部總線的控制權。當ADS#信號有效時，局部總線上的地址信號LA為有效地址;當BLAST#信號有效時，代表一次單周期訪問開啟;READY#為本地總線的狀態反饋信號，只有當其有效時，表示本地總線已經準備好，才可以進行訪問;當LW/R#為高時，代表單周期訪問為寫操作，當LW/R#為低時，代表單周期訪問為讀操作。在本設計中，FPGA通過識別地址信號LA來判斷具體的操作類型。當上位機向接口卡下發控制命令時，為CPCI總線到本地總線的數據傳輸，具體的工作流程為:當上位機下發命令時，啟動一次單周期寫訪問，同時下發特定的寫地址LA1，FPGA反饋READY#信號，并判斷到LW/R#信號為高，即得知上位機要下發數據，便從該特定地址LA1將命令代碼讀出，進行解碼之后將命令下發給采編存儲器。當接口卡向上位機傳輸LVDS高速數據時，為本地總線到CPCI總線的數據傳輸，具體的工作流程為:當圖1中所示的LVDS數據緩存FIFO內數據量達到2kbyte，啟動一次DMA傳輸，即一次DMA傳輸將2kbyte的數據上傳給上位機進行實時顯示與處理。上位機通過下發特定地址信號LA2來向FPGA查詢FIFO內數據量是否達到2kbyte，一旦其得到緩存FIFO內數據量滿足要求的信息，立即啟動一次單周期讀訪問，并向FPGA下發數據傳輸地址LA3，FPGA反饋READY#信號，并判斷到LW/R#信號為低，便將LVDS數據通過地址LA3上傳給上位機。

4設計驗證

將信源卡和接口卡分別插到背板上的2號和3號物理槽中，1號物理槽為系統槽，打開計算機系統，安裝驅動之后，兩塊功能板卡均能夠被識別。分別對兩塊板卡進行操作，均能實現各自的功能且互不影響，說明EEPROM的配置正確可行。以接口卡為例，用Chipscope來監測CPCI總線對本地進行讀、寫操作的實際過程，圖5和圖6分別為單周期讀訪問時序截圖和單周期寫訪問截圖。如圖5所示，當FIFO內數據量達到2kbyte時，信號f_fifo_hf變高，此時啟動一次單周期讀訪問，LW/R#為低，通過地址0008h將數據87h上傳給上位機。實際時序與第3節介紹的本地總線向CPCI總線傳輸數據的理論時序一致，對接收到的數據文件進行分析，數據結構完整，數據包計數連續，沒有丟數現象，驗證了本設計中本地總線向CPCI總線傳輸數據的正確性。如圖6所示，上位機向FPGA下發控制信號，此時啟動一次單周期寫訪問，LW/R#為高，FPGA通過地址0004h獲得命令代碼67h。實際通信時序與第3節介紹的CPCI總線向本地總線傳輸數據的理論時序一致，且命令下發正確，驗證了本設計中CPCI總線向本地總線傳輸數據的正確性。

5總結

篇(3)

現場總線是安裝在生產過程區域的現場設備/儀表與控制室內的自動控制裝置/系統之間的一種串行數字式多點雙向通信的數據總線，多用于工空等領域，應用現場總線技術不僅可以降低系統的布線成本，還具有設計簡單、調試方便等優點，同時，由于現場總線本身還提供了靈活而又功能強大的協議，這就使得用戶對系統配置，設備選型具有強大的自，可以任意組合多種功能模塊擴充系統的功能。在眾多的現場工業總線中，CAN總線是一種具有國際標準而且性能價格比又較高的現場總線，它在當今自動控制領域中的應用極為廣泛，并發揮著重要的作用。一個由CAN總線構成的單一網絡中，理論上可以掛接無數個節點。實際應用中，節點數目受網絡硬件的電氣特性所限制。CAN可提供高達1Mbit/s的數據傳輸速率，這使實時控制變得非常容易。另外，硬件的錯誤檢定特性也增強了CAN的抗電磁干擾能力。

CAN通訊協議描述了在設備之間信息如何傳遞。它對層的定義與開放系統互連模型(OSI)一致。每一層與另一設備上相同的那一層通訊。實際的通訊是發生在每一設備上相鄰的兩層，而設備只通過模型物理層的物理介質互連。CAN的結構定義了模型的最下面的兩層：數據鏈路層和物理層。應用層通過不同的新型協議層（專門用于特殊的工業領域加上由個別CAN用戶定義的任何合適的方案）和物理層連接。物理層和數據鏈路層對于設計者來說是透明的，并包含在所有執行CAN協議的部件中。

實際中，許多設備是RS-232接口，為了實現CAN總線數據和RS-232接口設備數據的傳輸，設計完成了CAN總線與RS-232轉換接口電路設計。

1.CAN總線協議分析

1.1CAN總線主要特點

CAN總線是一種多主式的串行通信總線，具有極高的實時性和可靠行，最高通信速率可以達到1Mbit/s，是一種十分優秀的現場工業總線。CAN總線具有如下特點：

結構簡單，只有2根線與外部相連，且內部集成錯誤探測和管理模塊。

通信方式靈活。可以多主方式工作，網絡上的其他節點發送信息，而不分主從。

可以點對點、點對多點或者全局廣播方式發送和接收數據。

網絡上的節點信息可分成不同的優先級，以滿足不同的實時要求。

CAN總線通信格式采用短幀格式，每幀字節最多為8個，可滿足通常工業領域中控制命令、工作狀態及測試數據的一般要求。同時，8字節也不會占用總線時間過長，從而保證了通信的實時性。

采用非破壞性總線仲裁技術。當兩個節點同時向總線上發送數據時，優先級低的節點主動停止數據發送，而優先級高的節點可不受影響地繼續傳送數據。這大大的節省了總線仲裁沖突的時間，雜網絡負載很重的情況下也不會出現網絡癱瘓。

直接通信距離最大可達10Km（速率5Kbit/s以下），最高通信速率可達1Mbit/s（此時距離最長為40Km），節點數可達110個，通信介質可以是雙絞線、同軸電纜或光導纖維。

CAN總線通信接口中集成了CAN協議的物理層和數據鏈路層功能，可完成對通信數據的成幀處理，包括位填充、數據塊編碼、循環冗余檢測、優先級判別等多項工作。

CAN總線采用CRC進行數據檢測并可提供相應的錯誤處理功能，保證了數據通信的可靠性。

1.2CAN總線協議

CAN總線協議主要描述設備之間的信息傳遞方式，從結構上可分成3個層次，分別對應OSI網絡模型的最低兩層數據鏈路層和物理層。CAN總線協議層次結構由高到低如表1-1所示。

表1-1CAN總線協議層次結構

協議層

對應OSI模型

說明

LLC

數據鏈路層

邏輯鏈路控制子層，用于為鏈路中的數據傳輸提供上層控制手段

MAC

媒體訪問控制子層，用于控制幀結構、仲裁、錯誤界定等數據傳輸的具體實現

物理層

物理層

物理層的作用是在不同節點之間根據所有的電氣屬性進行位的實際傳輸

LLC層和MAC層也可以看作是CAN總線數據鏈路層的兩個子層。其中LLC層接收MAC層傳遞的報文，主要完成報文濾波、過載通知以及恢復管理等工作。而MAC層則為數據報文的傳輸進行具體的控制，包括幀結構控制、總線仲裁、錯誤檢測、出錯界定、報文收發控制等工作。

物理層定義了信號是如何實際傳輸的，因此涉及到位時間、位編碼、同步的解釋，CAN總線協議并未對物理層部分進行具體的規定。

1.3CAN總線報文傳輸結構

報文傳輸由以下4個不同的幀類型所表示

1．數據幀：數據幀攜帶數據從發送器至接收器。

數據幀由7個不同的位場組成：幀起始、仲裁場、控制場、數據場、CRC場、應答場、幀結尾。數據場的長度可以為0。數據幀（或遠程幀）通過幀間空間與前述的各幀分開。

2．遠程幀：總線單元發出遠程幀，請求發送具有同一識別符的數據幀。

遠程幀由6個不同的位場組成：幀起始、仲裁場、控制場、CRC場、應答場、幀末尾。通過發送遠程幀，作為某數據接收器的站通過其資源節點對不同的數據傳送進行初始化設置。

3．錯誤幀：任何單元檢測到總線錯誤就發出錯誤幀。

錯誤幀由兩個不同的場組成。第一個場用作為不同站提供的錯誤標志（ERRORFLAG）的疊加。第二個場是錯誤界定符。

為了能正確地終止錯誤幀，"錯誤被動"的節點要求總線至少有長度為3個位時間的總線空閑（如果"錯誤被動"的接收器有本地錯誤的話）。因此，總線的載荷不應為100%。有兩種形式的錯誤標志，主動錯誤標志（Activeerrorflag）和被動錯誤標志（Passiveerrorflag）。

4．過載幀：過載幀用以在先行的和后續的數據幀（或遠程幀）之間提供一附加的延時。

過載幀包括兩個位場：過載標志和過載界定符。

有兩種過載條件都會導致過載標志的傳送：

（1）接收器的內部條件（此接收器對于下一數據幀或遠程幀需要有一延時）。

（2）間歇場期間檢測到一"顯性"位。

由過載條件1而引發的過載幀只允許起始于所期望的間歇場的第一個位時間開始。而由過載條件2引發的過載幀應起始于所檢測到"顯性"位之后的位。

1.4CAN總線錯誤處理

1.4.1錯誤檢測

有以下5種不同的錯誤類型（這5種錯誤不會相互排斥）

1．位錯誤（BitError）

單元在發送位的同時也對總線進行監視。如果所發送的位值與所監視的位值不相合，則在此位時間里檢測到一個位錯誤。但是在仲裁場（ARBITRATIONFIELD）的填充位流期間或應答間隙（ACKSLOT）發送一"隱性"位的情況是例外的。此時，當監視到一"顯性"位時，不會發出位錯誤。當發送器發送一個被動錯誤標志但檢測到"顯性"位時，也不視為位錯誤。

2．填充錯誤（StruffError）

如果在使用位填充法進行編碼的信息中，出現了第6個連續相同的位電平時，將檢測到一個填充錯誤。

3．CRC錯誤（CRCError）

CRC序列包括發送器的CRC計算結果。接收器計算CRC的方法與發送器相同。如果計算結果與接收到CRC序列的結果不相符，則檢測到一個CRC錯誤。

4．形式錯誤（FormError）

當一個固定形式的位場含有1個或多個非法位，則檢測到一個形式錯誤。(備注：接收器的幀末尾最后一位期間的顯性位不被當作幀錯誤)

5．應答錯誤（AcknowledgmentError）

只要在應答間隙（ACKSLOT）期間所監視的位不為"顯性"，則發送器會檢測到一個應答錯誤。

1.4.2錯誤標定

檢測到錯誤條件的站通過發送錯誤標志指示錯誤。對于"錯誤主動"的節點，錯誤信息為"主動錯誤標志"，對于"錯誤被動"的節點，錯誤信息為"被動錯誤標志"。站檢測到無論是位錯誤、填充錯誤、形式錯誤，還是應答錯誤，這個站會在下一位時發出錯誤標志信息。只要檢測到的錯誤的條件是CRC錯誤，錯誤標志的發送開始于ACK界定符之后的位（其他的錯誤條件除外）。

2.CAN控制器SJA1000分析

2.1CAN節點結構與SJA1000操作模式

SJA1000獨立的CAN控制器有2個不同的操作模式：

BasicCAN模式（和PCA82C200兼容）；

PeliCAN模式

BasicCAN模式是上電后默認的操作模式。因此用PCA82C200開發的已有硬件和軟件可以直接在SJA1000上使用，而不用作任何修改。

PeliCAN模式是新的操作模式，它能夠處理所有CAN2.0B規范的幀類型。而且它還提供一些增強功能，例如，SJA1000支持一些錯誤分析功能，支持系統診斷、系統維護和系統優化，而且這個模式里也加入了對一般CPU的支持和系統自身測試的功能。使SJA1000能應用于更寬的領域。

本設計采用PeliCAN模式，因此只給出PeliCAN模式增強功能。如表2-1所示。

表2-1PeliCAN模式的增強功能

CAN2.0B(active)

CAN2.0Bactive支持帶有29位標識符的網絡擴展應用

發送緩沖器

有11位或29位標識符的報文的單報文發送緩沖器

增強的驗收濾波器

兩個驗收濾波器模式支持11位和29位標識符的濾波

可讀的錯誤計數器

支持錯誤分析在原型階段和在正常操作期間可用于：診斷、系統維護、系統優化

可編程的出錯警告界限

錯誤代碼捕捉寄存器

出錯中斷

仲裁丟失捕捉中斷

支持系統優化包括報文延遲時間的分析

單次發送

使軟件命令最小化和允許快速重載發送緩沖器

僅聽模式

SJA1000能夠作為一個認可的CAN監控器操作，可以分析CAN總線通信或進行自動位速率檢測

自測試模式

支持全部CAN節點的功能自測試或在一個系統內的自接收

通常，每個CAN模塊能夠被分成不同的功能塊，如圖2-1所示。

CAN控制器執行在CAN規范里規定的完整CAN協議。它通常用于報文緩沖和驗收濾波。

通用CAN收發器實現從CAN控制器到CAN總線物理層的電氣連接。

而所有這些CAN功能都由一個模塊控制器控制，它負責執行應用層的功能。

元器件清單

表3-3CAN總線與RS-2232接口電路設計元氣件清單

序號

元件名稱

數量（個）

單價（元）

總價（元）

1

AT89C51

1

7.50

7.50

2

SJA1000

1

25.00

25.00

3

HM6116

1

1.00

1.00

4

MAX232

1

5.00

5.00

5

74HC373

1

1.00

1.00

6

PCA82C250

1

6.50

6.50

7

X25045

1

1.00

1.00

8

TLP113

2

3.00

6.00

合計

53.00

結論

本設計完成了CAN總線與RS-232轉換接口設計。由于CAN總線與RS-232接口數據通信速率以及通信幀格式都不同，本設計最大優點是解決了這兩點不同，實現了數據在CAN總線與RS-232接口之間的傳輸。且設計中由于使用了CAN總線進行數據傳輸這就使得通信方式多主性。網絡上任意節點可以任意時刻主動地向網絡上其他節點發送信息而不分主從。可以點對點，點對多點或全局廣播方式發送和接收數據。

由于CAN總線標準沒有定義應用層，數據鏈路層提供與信息內容相應的尋址能力，消息的內容完全由應用解釋。且CAN總線的每個數據幀最多只能承載8個字節的數據，因而只適應提供短的變量服務。許多功能還需要擴展。

綜上所述，通過此次設計，我們感受到CAN總線帶來的各種便利。而且，由于CAN總線具有結構簡單、實時性極高、可靠性強且本身具有強大的糾錯能力。使得它在當今自動控制領域中的應用極為廣泛。由于CAN協議參考OSI開放系統互聯模型，可由用戶定義應用層協議，通過相關的CAN轉接設備，將CAN與計算機相連，利用CAN232B轉換器組建一個CAN控制網絡，能夠很方便的實現RS-232多點組網、遠程通訊，并且，不需要更改原有RS-232通訊軟件，用戶可直接嵌入原有的應用領域，使系統設計達到更先進的水平。

摘要............................................................................................................Ι

ABSTRACT..................................................................................................................................ΙΙ

引言1

1.CAN總線協議分析2

1.1CAN總線主要特點2

1.2CAN總線協議2

1.3CAN總線報文傳輸結構3

1.4CAN總線錯誤處理3

1.4.1錯誤檢測3

1.4.2錯誤標定4

2.CAN控制器SJA1000分析5

2.1CAN節點結構與SJA1000操作模式5

2.2SJA1000內部結構及其功能分析6

3.CAN總線與RS-232轉換接口電路設計11

3.1CAN總線與RS-232轉換接口電路總體設計11

3.2主控制模塊電路設計12

3.2.1AT89C51與6116電路設計13

3.2.2看門狗電路設計14

3.3AT89C51與RS-232轉換接口電路設計16

3.3.1RS-232-C標準分析16

3.3.2RS-232與AT89C51接口電路設計18

3.4SJA1000與AT89C51接口電路設計19

3.4.1SJA1000與AT89C51接口電路設計19

3.4.2物理層接口電路設計21

3.5元器件清單22

結論22

篇(4)

關鍵詞：PCI總線TM1300以太網通信接口pSOS+內核pNA+

1概述

TM1300是Philips公司推出的新一代高性能多媒體數字信號處理器芯片。基于TM1300的DSP應用系統適合于實時聲音、圖像處理，可廣泛應用于會議電視、可視電話、數字電視等應用場合。它不僅具有強大的處理能力,同時還具有非常友好的音頻和視頻以及SSI和PCI等I／O接口，因此可以根據應用的需要靈活地構造各種視頻通信系統。鑒于目前計算機網絡的普及和網上視頻業務的發展，很有必要為TM1300視頻編碼系統開發一個以太網接口以拓寬其應用范圍。開發以太網接口的一種合理思路是利用TM1300集成的PCI接口來驅動專用的以太網接口芯片。由于目前多數以太網接口芯片（如Real-tek8029，Realtek8139等）都采用PCI接口，因此，可以用PCI總線將數據從TM1300傳輸到這些專用的以太網接口芯片后，再由它們發送數據，而且TM1300可以在嵌入式操作系統pSOS中運行，同時由于系統pSOS帶有TCP／IP協議棧因此可以方便地完成編碼碼流的TCP／IP封裝。

根據以上思路筆者在進行了前期測試的基礎上進行了電路板的設計并順利完成了調試。目前這個以太網接口已經基本開發成功。本文將對這個設計的技術要點從硬件和軟件兩個方面進行詳細介紹。

2TM1300及PCI總線接口

該系統的硬件結構框圖如圖1所示。本系統硬件設計的重點是PCI總線接口。PCI總線根據數據位的寬度有32位和64位之分,64位的數據線與32位是兼容的。PC機中常見的是32位PCI總線,它的有用引腳總數是110個,可以分成3組。第一組是基本功能信號線,包括32位共享數據地址線AD〔00．．31〕、接口控制線、仲裁線、時鐘線、系統復位線、中斷線;第二組是附加功能信號線,包括錯誤報告線、cache功能支持線、JTAG邊界掃描線;第三組是電源線,包括設備耗電量標識線、3．3V電源線(12根)、5V電源線(13根)、地線(22根)。

因為Realtek8029不具備PCI的附加功能信號線所支持的cache功能和JTAG邊界掃描功能,同時雖然它具有奇偶校驗錯誤報告功能引腳,但該腳可以懸空不用。所以,設計時只需考慮第一組功能信號線的連接即可。

PCI接口的設計有以下幾個要點：

(1)PCI總線的仲裁

這里先說明兩個概念。首先，PCI總線是多設備共享的，由于PC機里可以有多個PCI設備，所以需要使用仲裁器;其次，PCI設備有主設備和從設備之分，主設備可以發起PCI數據的傳送從設備只能被動地響應主設備的操作以對讀操作和寫操作做出響應。PCI的仲裁引腳是REQ和GNT，分別為請求線和授權線，而且只有PCI主設備有這兩個引腳。一般情況下，REQ通常和GNT成對地連到仲裁器，而設備與設備的REQ和GNT通常是互不相連的。

PCI總線的仲裁過程是這樣的：PCI主設備把REQ電平拉低以表示向仲裁器請求占用總線。經仲裁獲準后，仲裁器把這個設備的GNT電平拉低以表示請求獲準，此后該設備便可以使用總線了。當它不再使用總線時，應使REQ信號變為高電平仲裁器就不再給它分配總線資源。在本系統中，TM1300是PCI主設備，而Realtek8029是PCI從設備。由于它們不存在共享總線的問題，所以不需要仲裁器，而只是簡單地把REQ和GNT短接即可，這就相當于TM1300自己給自己授權。

（2）PCI_IDSEL信號線在設備的PCI配置讀寫中的作用

PCI有一種特殊的讀寫周期，稱為配置讀寫。這是因為在系統引導時，如果沒有給設備配置I／O或內存地址，軟件就只能通過配置來讀寫訪問設備。配置讀寫有兩種，分別稱為0型和1型具體采用哪一種取決于總線的硬件連接。配置讀寫操作不經過PCI橋時，使用0型，當需要經過PCI橋時，則要用1型，0型讀寫的地址直接就是總線上的地址，1型讀寫的地址則要經過PCI橋的譯碼才能成為最終的總線地址。本設計中，TM1300和Realtek8029是用PCI總線直連的，所以使用0型配置讀寫。

AD〔00．．31〕是PCI總線的共享地址和數據線，每一次PCI傳送都分為地址周期和數據周期。在地址周期，采用0型讀寫時，AD〔00．．31〕的內容如下，AD〔00〕和AD〔01〕總為“00”，因為配置讀寫是以雙字為單位的，AD〔02〕～AD〔07〕是要讀寫的PCI配置空間的寄存器號AD〔08〕～AD〔10〕是設備的功能號在一塊PCI卡上有多個功能設備時，為了進一步區分不同的設備就要用到這幾位，由于Realtek8029是單功能設備，故這幾位全為0，AD〔11〕～AD〔31〕是設備選擇位，其中必須有且僅有一位為“1”，如圖2所示，這在物理上表現為總線的AD〔11〕～AD〔31〕中有一根為高電平如果輸出高電平的這根線與某塊PCI卡的PCIIDSEL引腳相連，這塊卡就會被激活，這樣，在緊接著的數據周期中，它就會將其PCI配置空間相應寄存器中的內容放到總線上以供讀取。

（3）PCI_FRAME、PCI_DEVSEL、PCI_IRDY、PCI_TRDY引腳的處理

上述四個引腳均是低電平有效，因此需要接上拉電阻，以保證在設備未驅動該引腳時處于穩定的無效狀態，上拉電阻的阻值在1kΩ～10kΩ范圍內，阻值越小，則將該信號驅動為有效的時間越短，但太小又會導致電流過大，所以，要權衡考慮，本設計選用4．7kΩ。

上述三點對脫機情況下PCI設備的互連具有較普遍的參考意義，除此之外，本設計還有以下比較特殊的幾點：

應將TM1300的PCI，INTA引腳配置為輸入，以便接收Realtek8029的中斷；

PCI時鐘由TM1300提供；

Realtek8029的復位信號也就是TM1300的復位信號，該信號由外部電路提供；

TM1300的PCISTOP、PCISERR引腳懸空，表示Realtek8029不具備相應的附加功能。另外，TM1300的PCIINTB、PCIINTC、PCIINTD引腳可以用作用戶中斷。

3軟件設計

該接口設計的軟件結構框圖如圖3所示。其中TM1300運行于pSOS，它是一個簡單的實時多任務嵌入式操作系統，帶有pNA＋網絡組件，其pNA＋相當于TCP／IP協議棧的擴展，它向上可提供應用程序編程的socket接口，向下可定義一個與網絡接口層交互的接口，其中包括8個函數，分別是：ni_init（接口芯片初始化）、ni_broad－cast（發送廣播分組）、ni_send（發送普通分組）、ni_getpkb（申請發送緩沖區）、ni_retpkb（歸還接收緩沖區）、ni_ioctl（I／O控制操作）、ni_pool（統計量查詢）、Announce（網絡接口驅動調用它把接收到的數據包提交給pSOS）。其中網絡接口層在本應用中就是Realtek8029的驅動程序，它通過硬件抽象層來驅動Realtek8029（硬件抽象層是PCI總線的配置讀寫和I／O讀寫指令集的總稱）。

軟件執行的流程大致是：系統首先啟動pSOS，并由它加載網絡接口驅動程序，然后調用驅動程序的ni_init函數，同時初始化Realtek8029的PCI配置空間并設置Realtek8029的工作參數，之后啟動用戶任務。在這里，用戶任務為H．263編碼進程。它對VI口讀入的源圖像進行壓縮編碼后，將調用socket的接口函數sendto（sendto是UDP套接口專用的發送函數），然后把碼流發送給pSOS由pSOS根據UDP協議進行封裝后，再調用ni_send函數，并由ni_send完成數據包從系統主內存到Realtek8029片上RAM的拷貝，然后啟動Realtek8029發送數據。在接收情況下，Realtek8029收到一個完整的數據包后會用中斷通知CPU，然后由CPU執行中斷服務程序。當中斷服務程序將數據包從Realtek8029片上RAM中拷貝到系統的主內存后，系統將調用Announce函數并把數據塊的指針、數據長度和其它信息提交pSOS，最后由pSOS將數據包沿協議棧一層層上傳并作出相應的處理。

軟件的設計和pSOS操作系統的關系比較密切，限于篇幅，本文不對pSOS作詳細介紹，。本文接下來重點介紹PCI配置空間的配置過程，這部分對于類似的設計有較普遍的參考意義。PCI配置空間有64個字節，PCI片內的這些寄存器存儲了該芯片的廠商號、設備號、設備類型等重要代碼，還包括命令寄存器、基地址寄存器等控制其總線行為的寄存器，它們必須在設備初始化時正確配置，否則設備不能工作。

對Realtek8029PCI空間的配置需要三個步驟：

首先是掃描總線，這一步的目的是找到Real-tek8029的配置地址，直觀地講，就是找到它的PCI_IDSEL引腳和哪根AD線相連，因為后續的配置寫要根據這個地址來尋址。掃描總線時，要對AD〔11〕到AD〔31〕每根線進行一次掃描，如果哪根AD線連接了一個PCI設備的PCIIDSEL引腳，那么用配置讀函數讀取PCI配置空間的0號寄存器時，應該返回該設備的設備和廠商代碼，如果這根線實際未連接設備，則返回值是0。已知Realtek8029的設備和廠商代碼是“0x802910ec”，如果返回值與之相同，說明找到了Realtek8029，這時要記下這根AD線的序號。例如，在硬件上把Realtek8029的PCIIDSEL和AD〔20〕相連，則掃描到的序號就應該是“20”。

其次，用配置寫函數配置I／O讀寫使能，即在command寄存器中寫入“0x1”。

最后，用配置寫函數配置I／O地址，也就是在I／OBaseAdddress寄存器寫入分配給該設備的I／O地址（例如“0xe400”）。具體程序流程圖如圖4所示。

4調試結果

根據以上設計，筆者在原TM1300視頻編碼硬件系統的基礎上加入了PCI接口，并編寫了pSOS下Realtek8029的驅動程序。然后，在這個硬件平臺上對Realtek8029的驅動部分進行了數據傳送測試。

筆者首先用一個單獨的UDP發送任務進行發送速率測試。這個任務主要是高速地向網絡上的一臺PC發送數據包，數據包的大小是變長的。PC接收并對丟包數進行統計的結果如表1所列。實驗表明，在用網線直連的各種測試速率情況下都沒有出錯，而當接入局域網后，在發送速率為4．5Mbps時有突發的少量錯誤。由于UDP是不可靠的傳輸方式,所以這種錯誤是正常的。測試中，UDP發送的最高速率可以達到5Mbps左右，它與硬件的最高速率（10Mbps）相比還有一定差距，主要原因是數據從系統主內存到Realtek8029片上RAM的拷貝過程目前尚未采用DMA方式，這是需要改進的地方。

表1丟包數統計表（單位：丟包個數/分鐘）

連接方式發送速率

800kbps1.8Mbps4.5Mbps

網絡直連000

接入局域網002.5

接下來筆者進行了編碼和傳送的聯合測試。編碼任務執行H．263數據壓縮后，把碼流從以太網接口發出，然后在網絡上的另一臺PC上接收這個碼流，并進行解碼播放。通過調整編碼器的量化步長可以控制編碼的輸出碼率。在實驗環境下發現在量化步長大于等于5、碼率在700kbps以下時，基本沒有丟包現象，解碼得到的圖像比較穩定，而當量化步長進一步減小，碼率接近1Mbps時，就會出現丟包現象，解碼的圖像會出現彩色方塊。出現這種現象是因為H．263編碼器對CPU資源的消耗很大，而且數據在主內存和Realtek8029片上RAM之間的復制采用I／O讀寫方式也需要一定的CPU資源。這樣，當量化步長小于5時，處理的復雜度超過了CPU的能力從而產生了一定的誤碼。解決的途徑一方面是改進數據的傳送方式（采用DMA），另一方面是需要對編碼任務進行優化。

篇(5)

2:吉林省森工集團信息化發展前景與規劃.

3: 吉林省林業設計院網絡中心網絡改造與發展規劃.

4: 吉林省林業系統生態信息高速公路構建課題.

二、論文撰寫與設計研究的目的:

吉林省的林業分布十分廣泛,以長白山系為主要脈絡的山地廣泛分布各種森林資源,而作為林業及林業環境的發展,林業生態信息則是一個更為龐大的系統,快捷,準確,合理,系統的采集,處理,分析,存儲這些信息是擺在我們面前的十分現實的問題.在信息交流的這個世界中,信息好比貨物,我們需要將這些貨物(信息)進行合理的處理,其中以硬件為主的計算機網絡系統是這些貨物(信息)交流的"公路"和"處理廠",我做這個題目,就是要為它畫出一條"公路"和若干"處理方法"的藍圖.

由于森工集團這樣的特定企業,其一,它是一個統一管理的企業,具有集團化的特點,網絡的構建具有統一性.其二,它又在地理上是一個分散的企業,網絡點也具有分散性.然而,分散中還具有集中的特點,它的網絡系統的設計就應該是板塊化的.從信息的角度來講,信息的種類多,各種信息的采集傳輸處理角度也不盡相同,我們在設計的過程中不僅要考慮硬件的地域布局,也要考慮軟件平臺的配合.

沒有最好,只有更好;更新觀念,大步向前.我相信,在導師的精心指導下,經過我的努力,我將為它們創造出一條平坦,寬闊的"高速公路".

1,論文(設計)研究的對象:

擬訂以吉林省林業系統為地理模型,以林業網絡綜合服務為基本需求,以網絡拓撲結構為設計方向,以軟件整合為應用方法,開發設計一套完整的基于集散集團企業的企業網絡系統.

2,論文(設計)研究預期達到目標:

通過設計,論文的撰寫,預期達到網絡設計全面化,軟件整合合理化,網絡性能最優化,資金應用最低化,工程周期最短化的目標.

3,論文(設計)研究的內容:

一),主要問題:

設計解決網絡地域規范與現有網絡資源的利用和開發.

設計解決集中單位的網絡統一部署.

設計解決多類型網絡的接口部署.

設計解決分散網絡用戶的接入問題.

設計解決遠程瘦用戶網絡分散點的性能價格合理化問題.

設計解決具有針對性的輸入設備的自動化信息采集問題.

合理部署網絡服務中心的網絡平衡.

優化網絡服務系統,營造合理的網絡平臺.

網絡安全問題.

10,基本應用軟件整合問題.

[nextpage]

二),論文(設計)包含的部分:

1,地理模型與網絡模型的整合.

2,企業內部集中部門網絡設計.

3,企業內部分散單元網絡設計——總體分散.

4,企業內部分散單元網絡設計——遠程結點.

5,企業內部分散單元網絡設計——移動結點.

6,企業網絡窗口(企業外信息交流)設計.

7,企業網絡中心,服務平臺的設計.

8,企業網絡基本應用軟件結構設計.

9,企業網絡特定終端接點設計.

10,企業網絡整合設計.

5,論文(設計)的實驗方法及理由:

由于設計的過程并不是工程的施工過程,在設計過程中詳盡的去現場建設肯定有很大的難度,也不是十分可行的,那么我們在設計的階段就應該進行仿真試驗和科學計算.第一步,通過小型網絡測試軟件平臺,第二步,構建多個小型網絡搭建全局網絡模擬環境,第三步,構建干擾源利用小型網絡集總仿真測試.

6,論文(設計)實施安排表:

1.論文(設計)階段第一周次:相關理論的學習研究,閱讀參考文獻資料,制訂課題研究的實施方案,準備試驗用網絡硬件和軟件形成試驗程序表及試驗細則.

2.論文(設計)階段第二周次:開始第一輪實驗,進行小型網絡構建試驗,模擬網絡服務中心,模擬區域板塊,模擬遠程及移動網絡.

3.論文(設計)階段第三周次:進行接口模擬試驗,測試軟件應用平臺,完善課題研究方案.

4.論文(設計)階段第四周次:完成第一輪實驗,提交中期成果(實驗報告1).

5.論文(設計)階段第五周次:進行第二輪實驗,模擬環境(干擾仿真)實驗,提交實驗報告2.

6.論文(設計)階段第六周次:完成結題報告,形成論文.

三,論文(設計)實施工具及參考資料:

小型網絡環境,模擬干擾環境,軟件平臺.

吳企淵《計算機網絡》.

鄭紀蛟《計算機網絡》.

陳濟彪 丹青 等 《計算機局域網與企業網》.

christian huitema 《因特網路由技術》.

[美]othmar kyas 《網絡安全技術——風險分析,策略與防火墻》.

其他相關設備,軟件的說明書.

1、論文(設計)的創新點:

努力實現網絡資源的全面應用,擺脫將單純的網絡硬件設計為企業網絡設計的模式,大膽實踐將軟件部署與硬件設計階段相整合的網絡設計方法.

題目可行性說明及預期成果:

篇(6)

黃統奎，張艷紅

（廣東技術師范學院 天河學院，廣東 廣州 510540）

摘要：該文研究基于Struts2 + Spring + Hibernate的高校畢業設計管理系統的設計與實現。該系統按照畢業設計工作流程實現管理端，教師端，學生端相應的功能。重點實現了業務流程管理、用戶權限管理、選題管理、文檔管理、文檔在線編輯、成績評定、在線交流、數據備份等功能。該系統具有界面簡潔、易用性強，交互性好、功能完善、同時又考慮到數據安全和系統功能的擴充。

關鍵詞： Struts2；Spring；Hibernate；畢業設計；文檔管理

中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2014）19-4384-03

1 課題背景

隨著大學的擴招，畢業生數量的逐年遞增，高校畢業設計教學活動中需要處理的數據和信息也越來越大，在畢業設計管理工作中遇到工作效率低，交互性差，工作量大等問題，這已經成為高校每年畢業設計管理過程中急需處理的問題。同時課題資源過于零散，容易重復， 進一步加大了課題資源整合的難度。綜上所述，該文研究基于 Java EE的高校畢業設計管理系統，使用該系統實現快捷高效的畢業設計管理工作。

2 系統分析

通過需求分析，系統確定有三種角色：學生、教師、管理員。

2.1功能模塊劃分

在具體設計實現畢業設計管理系統時，主要考慮了系統的以下主要功能和模塊。

1） 公用模塊

（1） 登錄模塊：驗證帳號密碼是否正確。

（2） 修改個人信息模塊：修改賬號密碼。

（3） 師生互動模塊：師生交流平臺。

（4） 瀏覽信息模塊：查看信息。

2） 畢業生模塊

（1） 選報課題模塊：選擇指導老師與課題。

（2） 上傳論文模塊：上傳各階段的論文。

（3） 下載文件模塊：下載指導老師的資料。

3） 指導教師模塊

（1） 申報課題模塊：申報自己的課題。

（2） 分配課題模塊：選擇畢業生與其對應的課題。

（3） 上傳論文模塊：上傳各個階段的論文。

（4） 審批論文模塊：審批上傳的論文。

（5） 下載文件模塊：下載畢業生上傳資料。

4） 管理員模塊

（1） 公告模塊：信息。

（2） 課題管理模塊：管理課題。

（3） 賬號管理模塊：管理畢業生與指導教師賬號。

（4） 日常維護模塊：數據庫備份還原。

2.2業務流程圖

2.2.1 管理員業務流程圖

管理員定期對系統的信息進行更新和維護，可以對公告、課題、帳號信息進行查看、增加、修改、刪除等操作，以及配置系統的參數。業務流程圖如圖1所示。

圖1 管理員業務流程圖

圖2 教師業務流程圖

2.2.2 教師業務流程圖

教師登錄系統后，可以對課題進行管理，審核選題信息。教師可以查看學生的選題情況和學生個人信息，并確定是否錄用學生提交的課題。在選題完畢之后，教師可以在系統中批閱該課題的上交文件，并給出評價及評分。業務流程圖如上圖2所示。

2.2.3 學生業務流程圖

學生登錄系統后，可以查看公告，修改個人資料。學生在選題中，可以自由選擇教師及其提供的課題，也可以自己選取導師并自定義課題。選題后，學生允許提交各個時期的文檔文件，并將上傳信息顯示在教師端界面。學生的業務流程圖如圖3所示。

圖3 學生業務流程圖

3 詳細設計與實現

為了系統開發以及后期的維護更方便和明確，實現對項目的分割，將項目分為DAO、Service、Action層。根據面向對象思想，建立實體類，實現實體關系，將后臺的數據表映射出來到這實體類中，提供給DAO、Service、Action層使用。

在web.xml添加Struts、Spring、Hibernate的filter和listener。在WEB-INF文件夾里面編寫Spring的application.xml，整合Spring和Hibernate，實現Spring的IoC和AOP功能。將spring與struts的整合在一起，使用了自動掃描技術和注解的方式為每個類自動配置映射文件，使得程序的可讀性變強。

利用Hibernate編寫DAO層，為每個模塊建立DAO接口，在接口中實現了增刪改查等方法，實現JAVA與數據庫的數據交互，供Service層調用。

為每個模塊建立獨立的Service接口，每個接口將實現不同模塊的邏輯。Service層是實現系統業務邏輯的接口。利用之前編寫的DAO層的接口，編寫Service層，實現業務邏輯。合理規劃Service的分類，在進行系統維護時會非常便利。

Action層用于處理頁面信息，根據不同的處理結果返回不同的頁面到客戶端。設計Action層，調用Service層方法進行邏輯處理，然后根據處理結果為客戶端返回頁面，最后對界面進行美化。實現過程如下：

在創建具體的Action時，應當先創建抽象類BaseAction，繼承Struts2中的ActionSupport抽象類，聲明一個map變量session，這樣以后每當實現一個Action，只要繼承BaseAction，便可使用到session進行權限控制。同時也要創建PageAction，繼承Struts2中的ActionSupport抽象類，并在該類中聲明一個分頁技術所需要的參數，包括了記錄總條目、當前頁碼和總的頁數等參數。

客戶端每向服務器提交一次請求，都會先被相應的攔截器（interceptor）攔截并進行校驗，攔截器會檢驗session中的key為actor保存的對象是哪一個對象（Admin、Teacher、Student），若滿足攔截器的通過條件，將允許繼續進行操作，否則將強制跳轉到登陸頁。不同的Action將根據設計時規劃好的權限設置不同的攔截器。

在線word文件的預覽功能，使用的是PreviewAction里面的默認方法獲取當前的文件內容，通過里面的execute方法將內容在pageOffice的插件上顯示出來，并且如果我們修改里面的內容后直接通過插件的poCtrl1.setSaveFilePage（）方法將數據保存起來。那么下次我們點開文件就可以看到保存后的最新內容。

數據管理功能，所要調用到的是DataManageAction里面的execute方法跳轉到數據管理界面。其中每當我們點擊備份時，我們將數據庫名、登陸賬號、密碼、安裝路徑等參數傳遞給DataManageAction里面的backup方法，將數據進行備份出來并彈出備份是否成功的提醒消息，然后將數據庫還原時，我們需要先選擇備份的文件，最后將頁面的參數傳遞給DataManageAction里面的restore方法，將數據還原并彈出是否還原成功消息。

日志管理功能，所調用到的是LogManageAction里面的execute方法跳轉到日志管理界面。其中當我們點擊“導出日志”時，我們將調用LogManageAction里面的export方法，將服務器上項目的HTK.log日志文件以流的形式將其下載到客戶端，并彈出保存的窗口讓用戶選擇存放的路徑。當我們點擊“清空日志”時，那么程序將會調用LogManageAction里面的clean方法，將服務器上的HTK.log日志文件里面的內容清空并彈出清空成功消息。

4 總結

設計難點：保證上傳信息的導入正確的添加到后臺數據庫中，對導入的xls文件是通過暫存在服務器讀取還是直接從客戶端讀取。評分功能中，如何確定角色并且實現正確評分。在進行系統詳細設計時，必須從一個宏觀的角度，考慮某一功能模塊設計會不會對其他的功能模塊造成不良影響。本系統設計中充分考慮到數據安全性和功能的可擴展性，按照軟件測試流程完成了軟件測試，確保系統最終滿足用戶需求。

參考文獻：

篇(7)

1.1.數據格式

宏觀經濟數據是多樣式顯示功能的基礎數據。就目前來看，宏觀經濟主要的來源是統計報表、城市卡片和縣卡片。另外，基本單位匯總數據、人口普查匯總數據也是宏觀經濟數據的一部分。基本年鑒數據一般是報表數據經過處理后的結果，年鑒數據在統計局的業務位置不是很重要，但年鑒數據也是將來系統中可能需要處理的一部分，應該也作為一種宏觀經濟的數據來源來考慮。

宏觀經濟數據的組織形式是多種多樣的，但透過復雜的數據組織結構，它們也存在著共性，就是每一個統計數據都可以通過空間、時間、指標來確定，用數據庫的語言描述就是可以分為地址碼字段、時間字段、指標字段，只要數據表中存在這幾個字段，就可以完整的描述統計數據。

系統的宏觀經濟數據存儲在SQLServer2005中，表1為典型的宏觀經濟數據表結構，其中的地址碼與空間數據中的地址碼（DZM）相對應，實現空間數據與統計數據的統一。查詢后的宏觀經濟數據如2所示。

1.2.功能需求分析

論文重點研究多地區、多年、多指標的宏觀經濟數據查詢結果的多種表格方式顯示，具體有以下五種。(1)普通樣式：原始表數據顯示(2)地區分類樣式：以地區為主，顯示各個時間的各種指標信息。(3)時間分類樣式：以時間為主，顯示各個地區的各種指標信息。(4)指標分類樣式：以各類指標為主，顯示各個地區、不同時間的信息。(5)時間-指標樣式：以時間加各類指標為主，顯示各個地區的信息。

2.詳細功能設計

2.1.界面設計

多樣式表格顯示模塊需要以上述五種方式顯示數據。其中，普通樣式可以直接顯示，不需要進行復雜處理。論文主要論述其他四種樣式，具體顯示效果如圖3所示。如圖1所示，時間分類樣式為跨時間（年）的多地區、多指標數據顯示；地區分類樣式為跨地區的多時間（年）、多指標數據顯示；指標分類樣式為跨指標的多地區、多時間（年）數據顯示；時間_指標分類樣式為時間+指標的多地區數據顯示。

2.2.核心組件設計

本身提供了一個數據綁定控件DataGrid[3]。可以直接將數據綁定到該控件中來顯示所有數據，這樣就避免的使用for循環實現數據顯示，大大提高了程序的開發效率。總體上DataGrid控件是一個二維的數據網格，用表格形式顯示數據源數據，并且支持選擇、編輯、刪除、分頁顯示和排序等功能。但是DataGrid控件只能顯示單列數據，樣式簡單。SourceGrid組件具有很強的重繪功能，通過簡單的命令，如rowspan=2，就可以實現跨行顯示。系統基于開源組件SourceGrid開發出SuperGrid控件，如圖2所示，可以輕松實現各種表格的跨行、跨列顯示。

該組件提供了四個數據多樣式顯示接口、一個數據處理接口和五個數據輸出接口，詳細功能如下所示。>SpanState是實現跨地區顯示的接口；>SpanYear是實現跨時間顯示的接口；>SpanIndicator是實現跨指標顯示的接口；>IndividualQuery是實現時間指標樣式的顯示接口；>ReduceDumensionality是實現降維處理的接口；>ExporHTML是實現HTML格式輸出的接口；>ExporWord是實現Word格式輸出的接口；>ExporExcell是實現Excel格式輸出的接口；>ExporXML是實現XML格式輸出的接口；>OutPutTable是實現表格輸出的接口。其中，SpanState、SpanYear、SpanIndicator需要提供統一入口參數，即原始表格信息，表格格式為（DZM、MC、YEAR、I1、……、In）。實現時間-指標樣式的顯示效果，需要首先對原始數據進行降維處理，控件提供ReduceDumensionality方法實現此功能。

3.結論