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

篇(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)

關鍵詞：CPUIC卡TDA8007ISO7816

IC卡（IntegratedCircuitcard）即集成電路卡，是將一個集成電路芯片鑲嵌于朔料基片中，封裝成卡的形式，外形與常用的覆蓋磁條的磁卡相似。IC卡芯片具有寫入和存儲數據的能力。IC卡存儲器中的內容根據需要可以有條件地供外部讀取，或供內部信息處理和判定。根據卡中所鑲嵌的集成電路的不同，可以分成存儲器卡、邏輯加密卡、CPU卡三類。其中CPU卡即為由中央處理器CPU、EEPROM、隨機存儲器RAM以及固化在只讀存儲器ROM中的片內操作系統COS（ChipOperationSystem）組成的IC卡。IC卡按與外界數據傳送的形式來分，有接觸式和非接觸式兩種。

圖1T=0的CPU卡APDU指令實現流程

1CPUIC卡T=0的協議介紹

目前大多數CPUIC卡采用T=0模式。所謂T=0，即CPUIC卡與接口設備（即讀寫器）中數據傳輸方式為異步半雙工字符傳輸模式。

從T=0協議的功能出發，該協議的實現可以分為物理層、數據鏈路層、終端傳輸層和應用層。其中物理層和數據鏈路層可以具體參看ISO7816標準。在T=0協議應用，終端傳輸層和應用層實際上是不易分割來說明的，下面簡單說明。

終端傳輸層根據卡片返回的過程字符和狀態字節執行相應的操作，使讀寫器對數據的處理過程明朗清晰。卡片返回的過程字節和狀態字節跟應用層發送給卡的APDU（ApplicationProtocolDataUnit，應用協議數據單元）和VPP使用等有關。表1為VPP未用時的終端傳輸層中返回的過程字節。

表1

字節值結果

ACKINSVPP空閑，所有其余的數據字節相繼續被傳送

INS+''''FF''''VPP空閑，下一個數據字節隨后被傳送

SW1SW2VPP空閑，接口設備等待SW2字節

應用層即為由CLA、INS、P1、P2、P3作為命令頭組成的命令消息體的APDU響應和應答處理層。其中CLA為指令類別，INS為指令碼，P1、P2為參數，P3為根據APDU的不同格式為發送給卡的數據長度或期望響應的數據長度。APDU的幾種情況如表2所列。

表2

命令頭發送數據長度發送的數據期望應答的數據長度

通用APDUCLAINSP1PLCDataLE

情況一CLAINSP1P

情況二CLAINSP1PLE

情況三CLAINSP1PLCData

情況四CLAINSP1P2LCDataLE

CPU卡對接口設備（即讀寫器）的應答APDU情況如表3所列。

表3

體尾

數據DataSW1SW2

其中體中的數據字節數由命令APDU中的LE指出；SW1、SW2是必備的，可以指明命令APDU執行正確或執行出錯的錯誤類型。

2基于T=0傳輸協議的CPUIC的APDU指令流程

根據目前CPU卡的常用T=0協議、自帶編程升壓電路的應用情況，以及本讀寫器接收IC卡數據報文直接發送PC機處理的特點，本讀寫器可行的APDU命令和響應的處理流程如圖1所示。

3讀寫器的硬件組成

讀寫器的硬件部分主要由IC接口管理芯片TDA8007、MCUAT89C52、外部數據存儲器W24257S、串口電平轉換芯片MAX3226、安全IC卡座（即SAM卡座）、應用IC卡座、鍵盤口供電的串口通信線及其它相關元器件組成。

圖2所示為通過PC機控制管理的外置于PC機的接觸式CPUIC卡讀寫器。通過定制的數據線，該讀寫器的5V直流電源可直接由鍵盤口提供，同時數據線還負責PC機與讀寫器的串行數據交換。在大部分IC卡讀寫應用中，都涉及到IC卡的認證和數據讀寫的國解密問題，所以本讀寫器除了提供一個供用戶使用的IC卡接口卡座外，還內置了一個SAM卡，即安全IC卡卡座，以方便安裝SAM卡，保證應用IC卡讀寫時的數據安全，保護用戶的利益。

硬件的其它組成部分，如處理器，目前采用Atmel的89C52。其4KB的Flash程序存儲器可以滿足讀寫器的程序空間需要。由于PC機與89C52、89C52與TDA8007的數據交換要求的暫存數據空間比較大，89C52提供的256字節不夠，需外加一片數據存儲器。本讀寫器中使用的是華邦的W24257S。其有32KB存儲容量，IC接口部分的主要芯片為Philips的TDA8007。

4IC卡接口芯片應用

下面介紹一下TDA8007及其應用。TDA8007的原理結構如圖3所示。

TDA8007芯片能夠提供兩個能同時滿足ISO7816標準及EMV和GSM11-11標準的IC卡讀寫接口。在本讀寫器中，一個用于與應用IC通信，另一個用于與安全IC卡通信。與上文CPU卡的觸點圖相對應，CLKi、RSTi、VCCi、I/Oi、GNDCi、PRESi、C4i、C8i（其中i=1,2；C4i、C8i未用；PRESi可用于檢測IC卡是否插入。具體應用可參看TDA8007的技術文檔）都直接由TDA8007提供給IC卡接口相連，MCU只需通過其接口控制并行通信來管理TDA8007，便可實現對IC卡的上電、下電及讀寫數據處理。其中，微處理器既可以通過總線復用把TDA8007內部的所有寄存器作為外部存儲器，用MOVX尋址，也可以通過非總線復用方式訪問，此時TDA8007用AD0～AD3來區分內部各寄存器。另外，TDA8007的片選信號和外部中斷信號線可以方便讀寫器處理多個IC卡頭。TDA8007的特別硬件ESD處理、接口短路處理、電源出錯處理等也給IC卡和IC卡讀寫器提供了比較高的安全保護；同時，TDA8007內部集成的電源管理功能允許TDA8007的供電范圍可達2.7～6.0V，并且TDA8007通過電源管理可以給IC卡提供5.0V、3.0V及1.8V的電源，以適合不同工作電壓的IC卡應用。

圖3IC卡接口芯片TDA8007的原理框圖

本讀寫器是通過總線復用對TDA8007的寄存器進行控制的。其中MCU的P1.5為TDA8007的片選，P0口為與之通信的8位數據線，TDA8007的各寄存器預先被宏定義的成微處理器的一個外部數據單元（下面電程序處的定義），從而方便MCU訪問。下面結合TDA8007寄存器的定義和位分配，給出應用TDA8007接口芯片對IC卡進行上電激活和下電的程序。TDA8007的寄存器主要三類。第一類，通用寄存器：①卡槽選擇CSR；②硬件狀態HSR；③定時器TOR1、TOR2、TOR3。第二類，ISO7816串行處理寄存器：①串行狀態USR；②混合狀態MSR；③串行發送UTR；④串行接收URR；⑤隊列控制FCR。第三類，卡專屬寄存器：①可編程分頻PDR；②保護時間GTR；③串行控制UCR1、UCR2；④時鐘配置CCR；⑤上電控制PCR。注意：對于卡專屬的寄存器，即卡接口1、卡接口2分別對應的寄存器，邏輯上具有相同的名及訪問地址，因而，對不同的瞳操作，需要通過CSR選擇對應的卡槽來切換卡專卡屬寄存器的映射的物理空間。所以，接口設備每次從一個卡的上下電或讀寫轉向另一卡，都需要訪CSR設定對應的卡槽。對于每個寄存器的位定義不再多述，主動性者可參看TDA8007的技術文檔。

5上下電過程及具體程序

圖4為IC卡的上電時序圖。要實現之，需對PCR進行寫操作。其中START=PCR.0，RSTIN=PCR.2，VUP上升表示激活了TDA8007中的電壓轉換電路。當START置高時，只要能檢測到選定卡槽中的IC卡存在，且沒有TDA8007能檢測到并在HSR中指示的硬件錯誤出現，則對應IC卡接口的VCC1或VCC2將能被提供響應的電平（5V、3V或1.8V）。隨后對應卡的I/O數據線被置成高狀態（Z狀態），給IC卡提供設定的時鐘信號，常用為3.5712MHz。大約在START置高108ETU后，RSTIN置高。因為RST為RSTIN的拷貝，則對應卡的RST被置高。然后，用TDA8007提供的定時器TOR3、TOR2設定對ATR（AnswerToRequest）即復位應答首字節的最大等待時間120ETU（ElementTimeUnit），TOC設定定時器工作方式，便開始等待ATR首字節到來后做相應處理。至此，IC卡上電激活工作完成，隨后可以根據ATR字節的要求的工作方式對IC卡進行相應的讀寫處理。具體見上電程序。

圖4TDA8007產生滿足ISO7816標準訴IC卡上電激活時序

TDA8007寄存器訪問的預定義

#include<absacc.h>

#defineXXXXBYTE[0x8000]//XXX表示CSR等各寄存器上電程序如下：

P1.5=0;//片選TDA8007

CSR&=0xf8；

CSR|=ncard;//選擇卡，ncard=1,2

CSR&=0xf7；

CSR|=0xf7;

CSR|=0x08;//復位UART的寄存器

UCR2&=0xf7；//異步模式，SAN=0

CCR&=0xdf；//時鐘停止于低電平

UCR2|=0x60;//關閉附加中斷及收發中斷

GTR=0xff;//保持時間12ETU

If(v==1)//v為函數變量

PCR|=0x08;//1.8V卡用

elseif(v==3)

PCR|=0x02;//3V卡用

Else

PCR&=0xfd;//5V卡用

UCR2&=0xfc;//CKU=PSC=0,--31

FCR=0x00;//1奇偶校驗1FIFO

PDR=0x0c;//Divider=12

CCR=0x00;//不分頻

PCR&=0xfb;//RSTIN=0

UCR2|=0x04;//不自動轉換

UCR1=0x01;//正向約定

UCR1&=0xf7；//接收模式

flag3=0;//復位定時標志

flagatr=0;//接收ATR首字節定時標志

PCR|=0x01;//激活

TOR2=0x6c;

TOR3=0x00;

TOC=0x61;//RST拉高前等待108ETU

while(flag3==0)；//定時時間到，在中斷中設置flag3=1

TOC=0x00；//關閉定時器

PCR|=0x04;//給復位拉高

TOR2=0x78;

TOR3=0x00;

TOC=0x61;//RST拉高前等待

flagatr=1;

ATR();//復位應答處理函數

圖5為IC卡的下電時序圖。相對于上電時序，下電過程對時間的要求不是很嚴格，只要設計者控制TDA8007按照一定的順序置低START、RSTIN和停止CLK即可，然后TDA8007會自動逐步釋放RST、I/O、Vcc及VUP。具體處理見下電程序。

下電程序：

P15=0；

PCR&=0xfe;//START=0；下電

PCR&=0xfb;//卡的復位腳保持0

CCR&=0xdf；//停止時鐘于低

CCR|=0x10;//停止時鐘

P15=1；

6使用TDA8007應當注意的問題

TDA8007對于Vcc、RST出錯，芯片過熱（如圖IC卡為電源短路卡或金屬片），或IC卡插入拔出時都會產生中斷輸出。每次中斷處理結束，應注意把HSR中的值讀入一個臨時地址，以便清楚HSR中的標志。

每次發送數據到IC前，即接收IC卡的最后一個數據之前，應設置寄存器UCR1中的LCT位，以便接收完IC卡的數據后，自動切換成發送狀態。

對TDA8007部分布線時應注意，時鐘信號線與其它線的隔離：最好被地線包圍。

對于電路板上TDA8007部分的電容應盡量靠近TDA8007，其中電容Cap、Cbp、Cup尤其如此，并最好不要在這些電容連向TDA8007引腳過程中使用過孔；同時，Cap、Cup、Cbp電容的ESR要盡量小。

對TDA8007處理的兩個IC卡座中的任何一個執行上電、下電、讀寫卡操作之前，必須執行選擇卡座的操作函數，以便選中具體的IC卡進行處理。

對IC卡操作中上電時序中的定時，讀寫卡字節間等待定時等都可使用TDA8007中的定時器及定時控制器操作，注意其定時器為向下計數方式。

篇(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.結論