- 相關推薦
軌道交通自動售檢票系統網絡性能計算與驗證的論文
1自動售檢票系統概述
軌道交通自動售檢票系統集先進的集成技術、計算機技術、現代通信技術、網絡技術、自動控制技術、IC卡技術、大型數據庫技術、機電一體化技術、模式識別技術、傳感技術、精密機械技術等于一體，是實現軌道交通自動購票、檢票、計費、收費、統計全過程的自動化系統。AFC系統具備多項管理職能，直接面向乘客，是軌道交通運營系統中的重要組成部分。該系統主要處理交易和財務數據，必須保證信息的高度安全。AFC系統平臺必須滿足可靠性、安全性、易用性、可擴展性、互聯互通等需求，并具有準確采集與處理、大批量可靠地傳輸以及統計和管理數據的能力。
2網絡帶寬需求驗證
2.1車站與中央系統間的網絡帶寬
車站計算機系統與中央計算機系統間的網絡由綜合有線傳輸子系統提供的光傳輸網、以太網接口來實現，以太網接口直接接入中央核心交換機，車站計算機也直接與車站交換機連接。
假設車站每日處理不少于20萬客流(1客流≈2.5筆交易)，交易數據記錄長度約為100B，每個車站按最大連接128臺終端設備計算，每2s采集1次設備狀態信息，設備狀態信息長度為200B;在設置參數后，應在5min內下達所有系統設備，假定最大參數文件為10MB;同時，線路上還應留有一定的帶寬，以保證數據的查詢響應速度，分2級下達。據此，車站計算機與中央計算機系統間的網絡帶寬計算為
A=200000×2.53600×8≈18筆/s(1)
B=18×100×8≈15Kbit/s(2)
C=128×200×82≈103Kbit/s(3)
D=10M×25×60≈68Kbit/s(4)
E=B+C+D=184Kbit/s(5)
式中，A為峰值交易量，B為峰值數據傳輸量，C為設備狀態及數據，D為設備參數數據，E為總帶寬。
考慮TCP/IP包頭和其他開銷，以及管理、時鐘同步等其他應用的網絡開銷，雖然式(5)的計算值為184Kbit/s，但是真正為系統所提供的網絡線路帶寬應不小于512Kbit/s。
2.2中央與外部系統間的網絡
中央與外部系統間的網絡，是指線路中央通過專用網絡與軌道交通清分系統通信的網絡。假設每日有300萬人次客流的處理需求，高峰期內25%的客流集中在2h內;考慮極端情況，所有乘客都購票或加值，進站、出站和售票交易的記錄長度為100B。據此，中央計算機系統與清分系統之間所需網絡帶寬的計算公式為
X=3000000×2+3000000≈9000000筆/d(6
Y=9000000×0.253600×2≈312.5筆/s(7)
Z=312.5×100×8≈250Kbit/s(8)
式中，X為日交易量，Y為峰值交易量，Z為峰值數據傳輸量。
考慮參數數據接收的及時性，要求網絡帶寬不小于256Kbit/s，設備狀態等數據約為256Kbit/s;考慮TCP/IP包頭及管理、時鐘同步等其他應用的網絡開銷，中央計算機系統與外部系統間的網絡帶寬應至少為2Mbit/s。
3數據模擬測試
應用數據模擬發生器進行線路模擬測試，以驗證系統的網絡數據傳輸能力、應用程序處理性能，確保數據傳輸與接收的正確性、數據處理的正確性、應用程序的魯棒性。
3.1測試環境
1、硬件環境:中央主機、中央通信前置機、車站計算機(至少1臺)、數據模擬發生器(至少1臺)，實際生產系統所使用的網絡環境、設備之間的網絡通信正常。
2、主機環境:主機為HPRP3440服務器，數據庫為Oracle10g。
3、數據模擬器:模擬器能夠按照地標數據格式模擬生成6000、6002、6003、5041共4類最常出現的交易記錄，并向指定車站計算機發送。模擬器每秒發送60～70條交易記錄，每小時模擬數據超過20萬條。
3.2測試標準
1、車站計算機應能正確接收所有數據，記入數據庫，并實時轉發至中央計算機。
2、設備、車站、中央三者的數據應完全一致。
3、車站系統具有孤島運行能力:當應用故障或網絡中斷時，不影響其運行;當系統或網絡恢復正常時，自動連接中央計算機，并將未上傳的數據全部上傳。
4、中央計算機處理能力不得低于每秒150筆交易。
5、車站計算機處理能力不得低于每秒21筆交易。
3.3正確性測試
將數據模擬發生器上傳的交易數據，與車站、中央接收的數據進行比對，三者應完全一致。
可見，當模擬器發送數據量增大時，模擬器上傳數據與車站接收數據的差異很小，可忽略，但與中央接收數據的差異很大。經查，差異大是由于前置機內數據未及時刪除、存儲空間滿而造成的，修改后可以達到理想的測試要求。
3.4并發測試
并發測試，主要測試多個設備并發時的處理能力、正確性、程序的魯棒性。把3臺模擬器分別設定為不同車站(避免可能出現的流水號重復)，同時運行模擬器模擬發送程序，統計數據模擬發生器上傳的交易數據總數，并與車站、中央接收的數據進行比對，三者應完全一致。
3.5狀態及時延測試
狀態測試，主要測試車站計算機和中央監控工作站對設備狀態監控的正確性，數據模擬器依次模擬設備的各種狀態。
數據模擬器模擬設備的狀態事件代碼采用循環方式，事件發生與清除交替出現，即發生一個事件，在下一周期清除以前的一個事件(模擬程序保持10個事件，即第11個事件到達時，清除第1個事件)。實時查詢數據庫內容，同時在車站計算機和中央監控工作站觀察設備的狀態變化情況(二者應完全一致)。在監控工作站上觀察，應能看到設備狀態事件依次發生、清除，與數據模擬器的數據生成規律吻合。
同時，測試系統的反應速度。將車站計算機、監控工作站時鐘與數據模擬器時鐘設為一致，一臺數據模擬器向車站計算機發送交易數據，另一臺數據模擬器向車站計算機發送狀態數據，觀察故障發生后在中央監控工作站上顯示的時延。
3.6壓力測試
壓力測試，重點測試網絡通信能力、應用程序數據處理能力，判斷系統在極端或異常情況下的處理能力。模擬中央主機應用停止、大量數據積壓等情況，觀察車站/中央數據報文的傳輸和處理，記錄所有數據報文的傳輸和處理完畢所需的時間，觀察系統能在多長時間內處理完畢。
可以看出，系統在規定時間內的處理能力和模擬數據量成正比，足以滿足日客流200萬人次、系統處理能力不小于150筆/s的要求。
3.7網絡性能測試
3.7.1端口連通測試
1、測試目的:測試各端口之間VLAN隔離是否有效。
2、測試方法:在系統中央和站點各連接1臺電腦，電腦IP地址設置在同一網段中，接在相應端口進行互相連通，觀察狀態。
3.7.2最大、最小幀測試
1、測試目的:檢測設備所能處理的最大、最小幀長度。
2、測試方法:在系統中央和遠端站點各接1臺以太網性能分析儀，系統中央以64B的幀長往遠端站點發包，遠端站點以1518B的幀長向系統中央發包，觀察兩邊的收包情況。
3.7.3通道帶寬流量及吞吐量測試
1、測試目的:檢測SDH映射是否正常，通道帶寬是否符合設計要求。
2、測試方法:在系統中央和遠端站點各接1臺以太網性能分析儀，連上設備以后觀察端口速率，兩邊同時按設計要求發包，觀察收包情況和吞吐量。
可見，隨著交易量的增加，網絡吞吐量以穩定的速度增長，然后在某一點趨于穩定。
3.7.4長期丟包及系統CPU性能測試
1、測試目的:驗證在正常負荷情況下、設備長時間(12h)運行時的丟包性能。
2、測試方法:在系統中央和遠端站點各接1臺以太網性能分析儀，系統中央以64B的幀長往遠端站點發包，遠端站點以1518B的幀長向系統中央發包，計時12h，觀察兩邊收包情況，同時觀察系統CPU。
經測試，在網絡不穩定、發生瞬間閃斷時，丟包率在20%左右;網絡穩定時，丟包率為0。由于系統負載不斷變化，因此CPU曲線不是平滑的，會出現波動。
4結語
針對AFC系統設計要求和線路實際情況，對網絡功能進行測算與測試非常關鍵和重要。以上通過公式、圖表對網絡帶寬需求進行了驗證，對數據模擬環境、網絡性能進行了測試，驗證與測試結果均與設計預期吻合，證明設計確實符合要求，能夠實現各項功能。
【軌道交通自動售檢票系統網絡性能計算與驗證的論文】相關文章：
高性能計算機分布式內存文件系統的網絡性能優化方法論文11-08
網絡視頻系統性能測試及優化11-22
軌道交通監控系統聯動模塊設計論文11-20
火災自動報警計算機網絡系統設計03-05
計算機的網絡論文12-03
計算機畢業論文--基于ＡＪＡＸ技術提升Ｗｅｂ考試系統性能的研究03-28
電力系統調度自動化系統技術論文05-16
計算機通信系統的構建論文11-16
計算機網絡畢業論文-綜合布線系統概述03-03
論計算機和網絡控制系統發展趨勢論文11-14