信息系統設計論文匯總十篇

序論：好文章的創作是一個不斷探索和完善的過程，我們為您推薦十篇信息系統設計論文范例，希望它們能助您一臂之力，提升您的閱讀品質，帶來更深刻的閱讀感受。

篇（1）

2系統設計

2.1系統總體設計民政服務信息系統包括三個子系統，分別是民政內部辦公系統、社會服務平臺和社會家園網。三個子系統協作示意圖如圖1所示。圖1中實線表示業務申報，虛線表示審核結果回復，數字表示民政業務類型（1表示社區申報的業務，2表示社區家園網直接申報的業務，3表示通過社區家園網向社區申報并且最終由社區提交到民政局的業務）。智慧社區服務平臺是由社區的辦公人員使用，主要完成社區基本情況登記與查詢，民政業務上傳與下達。民政內部辦公系統是提供給民政局辦公人員使用的，民政局辦公人員通過該系統能夠審批社區上報的申請和管理的民政業務信息。社區家園網是一個論壇，為群眾提供一個咨詢、辦事和交流的平臺，不需要進行證件真實性審核的業務都通過社區家園網申報。

2.2架構設計民政服務信息系統采用ExtJS和JSP實現前臺頁面，通過Struts2、Spring和Hibernate實現后臺業務處理，并通過ExtJS和SSH整合搭建一個實現了MVC設計模式的系統架構。ExtJS+SSH架構中ExtJS實現了從用戶界面向后臺提交請求。控制層使用Struts2來實現MVC模式。業務邏輯層細化為Service層和DAO層，通過Spring來管理Service和DAO之間的耦合關系。數據持久層使用Hibernate框架。實現時為了提高系統的擴展性，Service層和DAO層使用抽象接口，將具體的實現類和接口分離，并通過Spring指定Service接口和DAO接口的具體實現類，在需求變化后，只需更改Spring的配置文件就可以適應新的需求，符合“開閉原則”。系統架構圖如圖2所示。控制層通過Struts2的servlet來完成，Action層由Struts2中的自定義action類實現。Action層中的對象使用Struts-Spring插件管理，而Service層和Dao層及相應實現層的對象統一由Spring管理。表現層通過JSP和ExtJS實現。

2.3功能設計

2.3.1民政內部辦公系統的設計民政內部辦公系統按組織機構來劃分功能模塊，主要包括區劃地名科、社會福利與社會事務科、最低生活保障局、民間組織管理科、救災救濟科、局辦公室和人事科。根據通用信息系統的需求，添加了權限管理和登錄管理。由于每個模塊都有相應的政策法規，將政策法規提取出來作為一個模塊，局長監督模塊體現了民政服務信息系統比手動辦公的優勢，局長通過該系統就可以了解下屬的工作情況而不會打擾到下屬辦公。民政內部辦公系統的功能結構圖如圖3所示。由于篇幅所限，圖3中的第三級模塊只列出具有代表性的功能模塊，并對部分有代表性的第二級模塊功能作了說明。區劃地名科的功能是對地名普查等基本信息進行管理，主要包括：地名更改審批和行政區劃，自然村和建筑物等地名信息的查詢/添加/刪除/修改和歷史信息查詢。社會福利與社會事務科是對兒童收養、社會福利機構、婚姻登記、殯葬及墓地和社會救助的管理。審批類業務主要包括兒童收養審批和社會福利機構審批，管理類業務主要是對兒童收養信息、婚姻登記信息、社會救助信息和殯葬及墓地信息的添加/刪除/修改。民間組織管理科的主要功能是民間組織的審核、民間組織信息管理和民間組織年檢。民政內部辦公系統具有權限驗證的功能，用戶登錄后只能處理本科室的業務。

2.3.2社區服務平臺的設計社區服務平臺是以業務功能來劃分模塊的，將社區的辦公作為辦公系統模塊，其他模塊都是對業務數據進行管理。社區服務平臺的功能模塊還有社區基本信息、社區組織、社會救助、社區服務、災害數據管理和社區居委會管理。社區服務平臺的功能結構圖如圖4所示。圖4中的三級模塊都是二級模塊的核心功能，其他功能由于篇幅所限暫未列出。社區服務平臺的主要功能模塊分析如下。社區基本信息、社區組織、社會救助、社區服務都屬于信息管理模塊，主要功能是對相應信息進行查詢。災害數據管理的主要功能是提交災害數據到民政局和對該社區的災害數據進行管理。2.3.3社區家園網的設計社區家園網的實質是論壇，社區家園網實現時使用一個開源的論壇框架，然后添加一個二級模塊民政業務來完成所有在社區家園網提交的民政業務。社區家園網的功能結構圖如圖5所示。由于篇幅所限，圖5中的民政業務模塊的部分功能模塊未列出。

3系統的關鍵技術

民政服務信息系統是以Struts2為實現架構的基礎，通過Spring來整合相應的框架。Struts2和Spring整合來完成對Action的管理，Spring和Hibernate整合來實現持久化的工作。ExtJS作為Struts2的視圖的實現。

3.1系統核心配置文件的實現民政服務信息系統在web.xml中定義Struts2和Spring的配置文件路徑。該系統中Struts2的Action對象由Struts-Spring插件來管理，該插件需要在web.xml中配置相應的監聽器。web.xml文件核心內容。

3.2Spring和Hibernate整合的實現Hibernate完成系統業務數據持久化的操作，提供了save、delete、update等方法，在DAO層只需調用這些方法就可以存儲業務數據。Spring對Hibernate支持非常完善，在Spring的配置文件daoContext.xml中配置一個id為dataSource的bean和一個sessionFactory的bean,在程序中使用注入的sessionFactory對象來實例化Spring框架提供的HibernateTemplate模板，DAO通過HibernateTemplate來調用持久化方法進行業務數據存儲。

3.3整合ExtJS的實現ExtJS框架只需要在JSP頁面導入ExtJS的核心JS文件和CSS樣式，就可以在自定義JS文件中使用ExtJS提供的頁面組件和表單組件，而不必使用HTML標簽來編寫Web界面。在主界面的JSP中整合ExtJS的代碼如下。

篇（2）

一、新會計準則核心理念對現有會計信息系統的沖擊

新會計準則與原準則相比,在很多方面都有變化。對此,財會軟件的生產廠家以及財會軟件的用戶采取了相應的應對措施,如預制新準則下的全新科目體系和財務報表,制定存貨成本的全新計價策略、固定資產折舊及減值準備計提的全新控制策略、滿足新準則要求的合并報表生成策略,全面支持職工福利費的靈活計提等。但以上措施只是針對新舊會計準則的具體變化對軟件功能所做的修補,并沒有充分體現新會計準則的核心理念。下面就現有會計信息系統對新會計準則的不適應性進行分析。

(一)原則導向理念對現有會計信息系統的沖擊

會計準則的制定存在著兩種不同的理念,一種是“規則導向說”;另一種是“原則導向說”。我國新會計準則的制定范式已由舊準則的規則導向轉變為原則導向。雖然現行主流會計信息系統都已完成了適應新會計準則的一些功能調整,但并沒有充分體現原則導向核心理念。由于舊準則采用規則導向理念,為每一類交易事項的會計處理和財務報告提供唯一的、特定的規則,即使這種規則已不能真實、合理地反映當前經濟環境下的業務活動,會計信息系統的處理流程也須遵循這種一成不變的規則。現階段推行的新準則采用原則導向理念,不再為每一具體的交易事項和財務報告制定詳細不變的規則,只就交易事項的會計處理及財務報告提出應遵循的原則,具體的操作處理方法需要依據準則對該經濟業務活動制定的原則和該經濟業務活動特點及會計人員的職業判斷來決定。導致企業對各個交易和事項的記錄與處理有更廣泛的選擇權,每個企業對相同會計事項可能會基于不同的職業判斷而選用不同的會計處理方法。現有會計信息系統的功能還不能與此相適應。

(二)公允價值計量理念對現有會計信息系統的沖擊

與原會計準則相比,新準則不僅具備更為完整的體系和更為豐富的內容,而且在會計計量上再次引入和強調了“公允價值”計量屬性。在38項具體會計準則中,有17項具體會計準則直接或間接地運用了公允價值進行會計計量。盡管我國本著審慎的態度,強調在公允價值的運用中遵循“適度運用”的原則,但我國會計準則體系中公允價值運用比例之高,使我們完全可以得到這樣一個結論:公允價值的引入是我國新會計準則最突出的特點,它豐富了會計計量模式。

現有的會計信息系統是與以往會計準則相適應的產物。新準則體系的變化所帶來的影響,會對現有的會計信息系統帶來沖擊和挑戰。公允價值可行的計量及運用方式成為現有會計信息系統的難題。

從公允價值的應用要求可以看出,會計信息系統與外界保持動態的數據連接,是對運用公允價值的會計系統的基本功能要求。現有的會計信息系統在外部信息的數據接口,信息數據共享方面沒有達到這一要求。目前這項工作是通過人工取得信息,再錄入到電腦中進行下一步的信息處理。由于缺乏外部信息的數據接口,數據的采集質量取決于人。另外在會計信息的加工過程中,由基本數據向高度綜合數據的歸集過程可能造成信息的丟失和扭曲。這種扭曲或產生于信息處理過程中的無意錯誤,或可能是被有意篡改所致,但更多的是由于信息提供者采用了有利于自身利益的會計選擇。這就是說,由于歸集過程完全控制在信息提供者手中,因此對于信息使用者來講,會計信息的生成類似于一個“黑箱”,他們只能得到最終的結果,而無法了解會計信息的生產過程,這就難免為企業管理者舞弊留下很大的空間。這種將公允價值的計量結果簡單地引入系統的做法,形成了現有會計系統應對新準則實施的軟肋。

公允價值的使用需要依靠活躍的交易市場和估值技術。對企業而言,如何確定公允價值,特別是在沒有活躍市場的交易報價時,企業必須懂得應用估價技術,這并不容易。這就要求重構的會計信息系統從技術上支持公允價值一級、二級估計數據的取得并納入會計核算系統。

總之,無論是估價方法的技術實現,還是市場價格數據的導入等公允價值的具體處理等問題的應對,都需要對現有會計信息系統進行優化。

(三)國際趨同理念對現有會計信息系統的沖擊

20世紀90年代以后,世界經濟全球化的趨勢明顯加快,國際貿易、國際投融資以及跨國公司均呈現良好的發展態勢,跨國兼并活動日益頻繁,國際資本流動也日漸迅速,各國經濟比以往任何時候都更加緊密地聯系在一起。在此背景下,國與國之間會計準則的差異使各國間的會計信息不具備可比性,妨礙了國際投資的發展和資本市場的國際化,妨礙了國際貿易各方對成本的衡量,不利于貿易糾紛的解決,已明顯成為國際資源有效配置的障礙。在此背景下我國了新的會計準則。新會計準則與“國際財務報告準則”不僅整體架構保持了一致,實現了內涵和實質上的統一,而且大多數項目都做到了相互對應,得到了國際會計準則理事會的認可。

XBRL可從財務信息分類規范的角度促進各國會計準則國際趨同。XBRL是一種開放式的、不局限于特定操作平臺的、在互聯網上披露企業財務報告的國際標準和技術。XBRL的標準體系包括兩部分內容:技術規范(Specification)和分類標準(Taxonomy)。前者是XBRL的核心,它規定了XBRL的理念和原則;后者是技術規范在各國財務報告的具體應用,必須基于特定版本的技術規范制定,這樣保證了各國財務報告的技術手段的一致性。對于分類標準的制定,主要是對財務報告披露的信息按一定的規范要求進行整理、分級和分解,直到信息分解成為可以獨立傳達一種含義的信息單位,并對其賦予一個唯一“標簽”,按照一定的規范進行描述。也就是說,分類標準更加規范了財務報告披露的可操作性。目前XBRL國際組織和發達國家都出臺了一些分類標準,如美國頒布的“GAAP工商業分類標準”;國際會計準則委員會基金會頒布的“基本財務報表分類標準”等。財務報告分類標準的制定過程就是各國會計標準化過程,會計準則的差異會造成財務信息分類的差異,將影響XBRL財務報告的應用效果。因此,XBRL的發展應用必定會推動各國財務信息分類的統一性,從而推進會計準則的國際趨同。

二、會計信息系統的設計思路應體現新準則導向

會計準則對會計信息系統的設計和構建具有指導意義,因此應從以下幾個方面作出努力,充分發揮新會計準則在會計信息系統構建方面的導向作用。

(一)建立開放型應用平臺

現階段推行的新準則采用原則導向理念,會計信息系統的功能必須與此相適應,提供一種開放型財務軟件應用平臺,為各經濟業務活動提供在新準則下的各種可行的操作處理方法,會計人員在新準則的指導下,根據經濟業務活動的特點,判斷經濟業務活動的實質,選擇和配置處理模塊和處理方法。

新準則最突出的特點是引入公允價值計量體系,增加會計計量模式。公允價值計量模式更能體現會計信息的相關性,而且有些資產如衍生金融資產,只能采用公允價值計量,采用歷史成本計量無法反映經濟活動的實質,無法反映該資產的真實價值及價值變動對損益的影響。但是,大量的資產因各種原因,還須用歷史成本進行計量。因此,會計信息系統要提供一種開放型應用平臺,財會人員可進行計量模式的選擇。

(二)完善數據接口,實現與外部數據的對接

公允價值的使用需要依靠活躍的交易市場和估值技術。對企業而言,如何確定公允價值,特別是在沒有活躍市場的交易報價時,企業必須懂得應用估價技術,這并不容易。

對于存在活躍市場報價的公允價值計量,則按照活躍市場中的報價確定相應資產的公允價值,比如金融資產中股票收盤價格的取得,以及相關資產的減值測試數據。最佳的模型應該是通過信息技術聯機實時提供最新的市場報價。將有關的證券交易軟件與會計軟件進行銜接,就可以比較便利地實現這一公允價值計量的技術支持。這對于軟件的接口、報價數據傳輸的及時性和準確性提出了切實的要求。股票市場價格數據的對接難度相對較小,其他資產交易市場的報價數據接入的標準化問題難度較大,有的市場甚至沒有標準的報價系統,這就需要完成許多配套工作。

公允價值的計量中,對于不存在活躍市場的資產的價值,應采用合理的估值技術確定。如果是企業自行估價的,在其會計信息系統中設定備選的估價技術模塊,并將估價參數的輸入權提供給客戶,不過估價參數的輸入也需要信息技術的輔助;如果是外部專家進行估價并提供估價數據,則應將其關鍵的數據和模型納入企業的會計信息系統中,也可以由授權專家按模塊自行輸入到估價系統,經內部系統確認并納入計量系統。

將證券市場的活躍價格數據通過接口直接導入核算系統,可以保障數據的客觀性,降低人為操作的主觀性和非主觀偏差。其次,在公允價值二級估價中,由系統從外部市場將多個市場報價一并引入到系統中,使得資產價格信息比較全面地呈現在會計信息系統中,而核算結果的選擇就在其中。再次,將企業使用的外部專家及其估價過程引入核算系統,并保留其將來作為審計程序中的可驗證的估價過程、估價參數以及采用的假設條件。這些會計信息系統中的安排,將公允價值計量的過程和計量的依據盡可能地透明化,從而使得新的核算系統能一定程度上降低公允價值被人為操縱的機會。

(三)加強XBRL的研究和應用

XBRL于1998年在美國誕生,已經在世界各地得到了迅猛發展,應用領域涵蓋了資本市場、金融監管、稅務稽查、工商管理、保險和審計等諸多方面。國際上許多大型軟件公司與證券交易所、會計師事務所等部門聯合正在加緊研發基于XBRL的軟件系統。新會計準則的實施將加速我國企業的國際化進程,也為XBRL在企業財務報告中的應用提供了一個契機。同時,XBRL的發展應用必定會推動各國財務信息分類的統一性,從而推進會計準則的國際趨同。

因此必須借助于我國會計準則指導委員會的組織架構,建立我國的XBRL組織,制定相關準則和規范,指導和監控我國XBRL研發的整體框架,加強理論和實務研究,并在此基礎上推廣應用XBRL。XBRL將從根本上改變企業編制和報告財務信息的方式,它為企業在互聯網上編制、存儲、財務報告和其他信息提供了一種標準和規范的技術體系,解決了財務信息披露與財務數據采集一體化以及跨平臺使用的根本問題,方便全球各地的信息使用者通過互聯網快速檢索、按需自動采集和分析企業財務信息。

主要參與文獻

[1]財政部企業會計準則[S].2006.

[2]歐陽電平,向玲玲論信息化背景下新會計準則與XBRL的作用[J].財會通訊:學術版,2008(7).

[3]阿尼塔•S•霍蘭德,等.現代會計信息系統[M].楊周南,譯.北京:經濟科學出版社,1999.

[4]謝詩芬論公允價值會計審計理論與實務中的若干重大問題[J].財經理論與實踐,2006(6).

篇（3）

2關鍵技術

本文研究了基于社交媒體突發事件應急系統的多個關鍵技術:情景再現、應急信息提取、趨勢分析等。情景再現:可整合社交媒體數據的直接信息，結合時間、空間對突發事件的圖片文字等信息進行查詢，展示事件發生情景;應急信息提取:利用實時應急信息分類方法，提取、分類出突發事件的狀況、救援等應急信息，標注在地圖上;趨勢分析:通過分析微博的數量變化和空間分布，揭示突發事件趨勢和公眾關注點。

2．1情景再現

在突發事件中，目擊者的照片(尤其是手機拍攝的照片)使得公眾報道在災害應對中越發重要［5］。因為圖片給人們最直觀的感受，特別是在自然災害發生時，圖片能夠描述災害的發生情景，客觀反映災害造成的破壞場面，為應急決策提供直接的證據。情景再現，是采用“圖片+描述”方式，通過圖片、文字描述突發事件在空間上的最新發展狀況。社交媒體具有很強的時效性，加上人們對突發事件的最新動態較為敏感。所以，最近一段時間的圖片適合表現突發事件的發展狀況。另外，突發事件可以抽象為地理空間上的地理現象，社交媒體數據具有位置信息，可利用地圖的可見范圍來約束突發事件情景的范圍。由此可見，情景再現實質上是多維信息查詢，包括時間、空間、圖片信息三個維度。多維度查詢也很好地緩解了在瀏覽器端繪制時的效率問題和壓力問題，特別是空間的限制，大大地提升地圖交互能力。系統采用AJAX技術實現按需加載圖片，加快瀏覽器的響應速度。

2．2應急信息提取與定位

微博的大部分信息以文本的形式存在。從文本自身特點來看，文本短小且信息雜亂，包括事件狀況、求援、救援、評論、商家廣告等多種多樣信息。從信息流來看，微博文本是實時獲取的，具有實時變動性。本文提出了一種從海量、實時的社交媒體數據中提取應急信息的方法，學習過程:系統初始化時，當文本積累一定量后，訓練初步模型。取出數據庫的所有文本，把每條微博文本看成一個文檔，即得到文檔集。文本預處理包括去掉重復微博，采用中文分詞器Ansj分詞、去掉停用詞，獲得分詞后的文檔集，作為話題模型LatentDirichletAllocation(LDA)的一個輸入。設定好主題個數后，采用隨機模擬的GibbsSampling算法，得到各個文檔的主題和各個主題的單詞分布(即詞庫)。如此，文檔集的大部分文檔被標記了。將單詞為特征、主題為類別的文檔集輸入到監督算法SupportVectorMachine(SVM)做訓練，調優并得到初步應急信息分類模型。預測過程:模型訓練好后，新的微博文本經上文相同的文本預處理，得文本的所有特征(單詞)，輸入到訓練好的應急信息分類模型，輸出所屬主題;同時結合LDA生成的主題詞庫，判斷文本的主題類型，并標注在地圖上。更新過程:主要針對模型和主題詞庫的更新。考慮到信息采集速率，與上個模型相隔2個小時后，取出所有文本，重復學習過程重新得到模型和詞庫，以適應微博話題隨時間的變化，提取新的應急信息。

2．3趨勢分析

人們除了關注突發事件的最新情況、應急信息，還想了解事件的發展趨勢。系統從時間趨勢和空間分布兩個方面來表現突發事件的趨勢。研究表明［6］:社交媒體數據可以被用來甄別事件在時間上的發展趨勢，甚至做出預測。為揭示突發事件時間發展趨勢，我們統計每小時的微博總數、用戶參與數、轉發數，通過觀察趨勢線的最高點和拐點來發現趨勢。另外，詞云圖利用中文分詞技術處理一定時間內的微博內容并統計高頻詞匯，找出人們討論的熱點話題以及其隨時間的變化。微博數據攜帶位置信息，反映了突發事件的空間分布。系統使用了聚類分析和核密度估計來發現事件空間分布規律。聚類分析通過對微博點在空間距離上做聚類，以便尋找事件在空間的分布狀態，分配應急資源;核密度估計很好地反映了事件在空間上的熱點區域，有利于發現問題區域所在。

3系統的主要功能

3．1查看、瀏覽圖片功能

1)采用“圖片+描述”形式，通過縮略圖、大圖與地圖聯動來展示突發事件的情景。當點擊圖片時，地圖中心會移動到圖片對應的坐標點，并彈出信息框，包括者、微博內容、時間和經緯度等;當點擊地圖上的點時，該點對應的圖片出現在圖片框中央。2)添加按時間、熱度排序的功能，便于查看最新、最熱的圖片。圖3展示了2012年“7．21北京特大暴雨”中某條微博的圖片、文字、地點等情景。

3．2定位應急信息功能

1)利用實時應急信息分類方法，提取并分類好微博文本的應急信息。采用表格形式展現應急信息，每個表格與一個主題關聯，主題以標簽的形式表現在網頁中。當點擊相應標簽，表格內容隨之發生改變。2)每條文本與地圖聯動。當點擊表格中文本時，地圖中心會移動到文本對應的坐標點，方便定位應急信息，展開救援。圖4展示的是“7．21北京特大暴雨”微博經過應急信息提取后得到“救援信息、天氣預報、損失與影響”等主題，及“救援信息”主題下的救援信息。

3．3時空趨勢分析功能

1)利用Echart圖表，統計每小時的微博總數、用戶參與數、轉發數，以及趨勢線(微博總數減去轉發數)，使用放大窗口查看曲線的局部細節，如圖5所示。在A點和B點前一個小時，北京市氣象臺分別了暴雨橙色預警和暴雨黃色預警。2)當點擊曲線上的拐點時，利用AJAX技術，在地圖上動態加載每個小時的點數據。通過切換不同圖層(熱點圖和聚類圖)，可查看暴雨微博的空間分布情況。圖6左上部分為“7．21北京特大暴雨”微博的熱點圖，暴雨微博在地鐵1號線和首都機場附近出現聚集現象，反映了暴雨事件空間熱點分布。

3．4發現熱點話題功能

另外，系統采用詞云圖和柱狀圖來展現最新微博的高頻詞匯，反映最近時間內突發事件的話題變化。圖6右、下部分展示了截至7月22日10時“7．21北京特大暴雨”的詞云圖和高頻詞匯柱狀圖，直觀地展現人們的討論熱點話題，如“大暴雨、回家、平安、積水”等。除了多種的表現形式，數據可視化還要考慮多圖層繪制效率問題、大數據量的渲染壓力問題。為了解決這些問題，我們可以采用圖層控制、矢量繪制點、使用JSON包裝處理結果等方法。

篇（4）

1．2數據資源管理技術建立數據庫系統，實現對數據的收集、加工、檢索、存儲、傳輸、利用和維護等一系列的數據資源管理。對數據進行合理組織、維護和存取，并處理好應用程序與數據之間的管理。

1．3無線射頻識別技術無線射頻識別（radiofrequencyidentification，RFID）技術主要應用于商品的管理，控制商品的流通過程。能夠精確定位，對商品的各個流通階段進行有效的查詢，以及動態追蹤物品在供應鏈中的位置。同時，RFID技術對物品進行識別和描述，可提高物流服務的效率。

1．4可視化技術主要用于數據的可視化，通過計算機圖形和圖像處理技術，把數據轉換成圖像，從方便信息的處理，進而提高作業效率。其在物流系統中的運用具體體現在貨物的入出庫管理、商品車道位計劃及車輛調度等方面。

1．5物聯網技術紅外感應器、射頻識別、全球定位系統等信息傳感設備，按約定的協議，將物品與互聯網連接起來，進行信息交換和通信，實現智能化識別、定位、監控、跟蹤和管理。

2系統設計

2．1系統模型

設計服務于整車物流的第三方物流企業是為整車廠提供物流服務，一般包括商品車的分撥與倉儲、運輸、配送等。因此，對于以整車運輸業務為主的第三方物流企業來說，其業務環節主要包括客戶填寫及提交訂單、VDC與VSC管理、道位計劃、商品車出庫、轎運車的調度與配送、商品車的運輸、運輸車輛的實時監控、意外情況的應急處理、物流信息動態的反饋等。這些業務環節之間都具有密切的聯系，并通過各個環節的信息交互，形成物流網絡。為了實現物流集成化運作，應建立科學的物流管理機制，優化管理環節，改變傳統的組織結構，消除各部門連接處的重復操作和多余環節，實現各個環節之間的有效銜接，實現信息的自由流通，將各層級的物流服務更好地連接在一起。從信息平臺角度來說，建立在局域網上的物流信息平臺，將相互獨立的信息系統連通，實現部門之間的信息交流與傳輸。同時，各部門所管理、存儲的數據信息根據部門職能的需要實現部分數據的共享。在企業外部，可通過Internet實現與上下游客戶及供應商等多方實體業務的連接。同時，為實現第三方物流信息系統的集成化設計，需要將現代物流技術中的軟件技術和硬件技術相結合。集成化物流系統的架構圖如圖1所示。

2．2系統結構設計

通過對系統實體模型的分析，拆分物流服務流程，獲取各環節的具體實施任務，并將這些任務分配給各職能部門，同時根據這些任務的具體實施，設計出物流系統各個功能模塊。再根據各系統模塊的工作性質，將整個系統分為一個4層結構，分別是頂層、應用層、操作層和數據層。第三方集成化物流信息系統結構圖如圖2所示。

2．2．1頂層也叫集成層，將各個單一的模塊集成為一個整體，使之能更好地協同完成任務。同時，頂層也是系統的最高權限管理層，能為系統作出決策性的行為。

2．2．2應用層主要體現為可視化的操作平臺。根據使用系統的內外用戶人群，把該層分為管理登入平臺和客戶登入平臺。在管理平臺中，系統根據內部員工所屬的部門分配其相應子系統的管理權限，例如倉管員擁有倉儲管理的辦公權限；通過客戶平臺，外部客戶能實現與第三方物流公司的信息交流。

．2．3操作層這層是應用層操作的具體實現，對應內外平臺具有的相應管理子系統或是功能模塊。內部管理平臺包含了4個實現物流基本服務的子系統：客戶管理子系統、VDC與VSC管理子系統、配送管理子系統和運輸管理子系統，交由4個職能部門使用。外部客戶登入平臺主要包括查詢功能模塊和訂單生成模塊，查詢各項物流服務的信息和訂單的生成。

2．2．4數據層這是整個物流系統能夠順利運行的基礎，它為各項操作提供所需的數據，包括倉庫信息、車輛信息、訂單詳情等，同時也隨時記錄并管理物流服務各環節產生的信息。

2．3系統業務流程設計

第三方物流企業在客戶（經銷商或直銷客戶）訂單的推動下，為客戶提供全面的物流服務。在第三方物流企業接受訂單之后，通過物流系統自動將訂單拆解，將對應的訂單信息發送到各職能部門。各部門按照一定的操作流程，協調運作，最終完成對客戶的物流服務［5］。在所設計的第三方物流信息系統中，其一般運作流程如下：1）當客戶通過互網絡在第三方物流企業的網絡物流平臺中填寫并提交訂單后，物流系統通過數據資料管理技術對訂單信息拆解，并將訂單中商品的基礎屬性信息傳送給VDC與VSC管理部門。2）VDC與VSC管理部門接到訂單后，通過物流信息系統的分撥和VDC與VSC管理模塊，就近查找該訂單中所需商品車所在的VDC與VSC倉庫，以及商品車的存放位置，然后生成一份發貨單，通過物流系統發送給調度部門。3）在發送過程中，物流系統重新將屏蔽掉的運送信息整合到發貨單中。調度部門接收到發貨單后根據發貨單中的商品車的基本信息和配送信息，以及物流系統數據庫所提供的可用車輛信息，在調度管理模塊中進行VDC道位計劃、配送方法、運輸路徑的設計和優化，最終得到效率高、成本低的最優方案，并將其分別制成道位計劃表和調度配送單，通過物流系統將道位計劃表發給VDC裝運部門，將調度配送單發給運輸管理部門（若目的地的VSC中存放有訂單中所需的商品車，則調度部門可通知運輸部門進行商品車的直接配送）。4）VDC裝運部門根據道位計劃表將商品車調往運送道位上等待配送；同時，運輸管理部門根據調度配送單，挑選合適的司機來駕駛所需的轎運車去相應的停放區提取預定的商品車，并根據調度部門所提供的運輸線路將貨物送往目的VSC，即完成商品車的“一次運輸”。5）在完成商品車的“一次運輸”后，物流系統自動生成由VSC運送到經銷商的“二次運輸”調度單。挑選合適的司機來駕駛所需的轎運車，完成商品車的短駁。6）在運輸途中，調度部門對運輸車輛實時監控；運輸完成后，進行回單處理。若遇到交通阻塞等的突發性狀況，調度部門及時更改運輸方案，例如更改運輸線路、更換運輸車輛等，同時變更調度和運輸信息，并登記到系統中；而對于運輸途中出現商品車丟失、損壞等意外情況，調度部門生成記錄，并登記到系統中。同時，填寫加貨單，通過物流系統發送到VDC與VSC管理部門，重新發貨。7）物流操作完成后，物流系統將各部門的操作記錄合成一張完整的記錄單并保存到數據庫中。基于集成化模式的整車第三方物流信息系統業務流程如圖3所示。

2．4系統功能模塊設計

在集成化的整車第三方物流信息系統中，主要包括VDC與VSC管理、調度管理、運輸管理、客戶管理和公共服務管理等模塊。系統功能模塊結構如圖4所示。

2．4．1客戶管理模塊通過客戶管理模塊，企業員工可以管理服務對象，包括對承運商和經銷商進行注冊登記、信息審核、信息更改、合同管理及訂單管理等。其中運輸商管理和經銷商注冊登記的信息包括單位名稱、聯系方式、單位地址等基礎信息；合同管理包括合同錄入、合作內容查詢及變更、合同期限提醒等；訂單管理對訂單信息進行審核及將信息歸類保存。

2．4．2VDC與VSC管理模塊倉儲管理中主要包括入庫管理和出庫管理，以及一些維護。借助倉儲管理模塊，倉管員根據即將入庫商品車的信息包括編碼、名稱、數量等，完成入庫單的填寫，并安排合理的存放位置；根據訂單信息，查詢所需商品車的存儲情況，安排最優的出庫方案。此外，該模塊也具有倉庫容量預警、日常盤點、報表統計等輔助功能。

2．4．3調度管理模塊通過調度管理，調度員可以完成道位計劃、配送方案制訂、路線規劃和實時監控的業務工作。調度員通過可視化操作界面查找倉庫中所需商品車的位置和道位使用情況，快捷高效地制訂商品車出庫時的道位安排計劃。然后，調度員根據實際情況，選擇合適的轎運車和配送路線，完成配送最優方案規劃。在配送過程中，調度員能實時獲取轎運車和路況信息，并針對具體情況給司機作出實時指示，實現動態調度。

2．4．4運輸管理模塊運輸管理主要實現運輸部門的管理職能，其功能包括轎運車和司機的檔案管理，運輸資源的安排，運輸情況的記錄與反饋。轎運車檔案信息包括車輛類型、服役年限、載重等；司機檔案信息包括姓名、證件類型及聯系方式等。運輸資源安排主要是根據調度單安排轎運車和駕駛司機。另外運輸管理還包括轎運車維護管理，例如車輛年檢安排、車輛事故情況統計等。

2．4．5公共服務管理模塊公共服務管理主要是給企業所服務的對象進行操作的功能模塊，客戶通過該模塊可以完成各項業務信息的查詢。提供回單準時率、回單出錯率、貨物損壞率等指標的物流質量分析功能，以及對物流歷史數據的分析與統計等。

2．5可視化設計

在應用系統的設計中，由于復雜和龐大的功能，給界面設計帶來了負擔，加重了用戶操作的錯亂，可視化設計主要旨在借助于圖形化等直觀手段，清晰有效地傳達與溝通信息，形成高效的功能、使用映射，完成用戶任務目標。系統設計應用StringBuffer和HTML5的拖拽技術，實現了VDC裝運環節的功能可視化與操作可視化設計，界面設計如圖5所示。

篇（5）

1.2總體框架結構設計根據廠區管網綜合管理信息系統項目的建設目標和建設內容，基于SOA規范，將系統總體架構設計如圖1所示：

1.3關鍵技術與技術路線1)基于“一張圖”的區域信息資源共享與應用模式通過這種方式，能夠實現廠區空間地理信息資源的有效整合與集成，統一為廠區提供可視化的決策分析和數據共享服務。2)基于SOA的ServiceGIS建立空間信息共享服務平臺ServiceGIS是高性能全功能的服務式GIS。它可以通過服務的方式提供GIS的全部功能，包括地理空間數據的管理，可視化和分析等。3)多源空間數據無縫集成技術本項目我們將采用SDX+空間數據庫引擎技術來實現廠區交換的多源數據讀取與轉換，避免數據損失和重復建設。4)二三維一體化技術二三維一體化技術體系能保證二維與三維GIS技術無縫融合，包括數據模型、數據存儲方案、數據管理、符號、可視化和分析功能的一體化，提供海量二維數據直接在三維場景中的高性能可視化、二維分析功能在三維場景中的直接操作和越來越豐富的三維分析功能。5)地上地下三維建模技術包括地面景觀建模和地上地下管線的三維建模。

二、系統功能設計

2.1數據管理子系統數據管理子系統負責管理廠區全廠的管網及基礎地理空間數據，將管網等各類地理空間數據按統一標準、統一格式、統一坐標的方式，進行入庫管理，建立有效的數據更新機制，今后竣工數據能及時導入數據庫中，保證數據的更新，便于后期的數據維護和對外共享服務工作。主要功能包括數據生成與入庫、數據接邊融合、數據質量檢查和數據批量入庫。

2.2共享服務基礎平臺建立相應的空間數據標準和數據分發、交換和服務機制，實現廠區各職能部門范圍內地理數據的廣泛共享，實現廠區地理空間信息在各部門的應用。主要功能包括地理空間信息共享、共享數據管理和運維管理。

2.3廠區管線管理主要目標是實現廠區所有基礎地理信息資源“一張圖”動態一體化管理模式，為管線管理及廠區運行提供現勢性、準確的地下管線數據，實現管線管理數字化，管線查詢分析一體化，輔助管線規劃設計流程化、智能化，為企業發展提供決策支持信息。主要功能包括廠區三維景觀展示、廠區三維管線展示、管線信息查詢、廠區模型與管線編輯、管線斷面分析、管線碰撞分析、管線連通分析、凈距分析、覆土深度分析、爆管事故分析、緩沖區分析、流向分析、管線設計方案定量比選、管線預警預報、管線及附屬設施統計、圖紙的導入和導出。系統提供完善的用戶權限功能。沒有訪問系統權限的用戶，可以根據系統后臺提供的用戶注冊功能進行注冊，申請訪問系統。注冊成功之后，需要管理員其進行審核，并賦予訪問系統的相關權限，進行訪問系統。

篇（6）

1.1數據訪問層的database.dll組件使用技術訪問Oracle數據庫。是.NETFramework用于和數據源進行交互的面向對象類庫。本系統采用Framework數據類庫，主要使用Connection連接對象連接數據庫、com－mand數據命令對象執行增刪改SQL語句、DataReader數據讀取器對象、DataAdapter數據適配器對象及DataSet數據集對象[3]。

1.2業務層的system.dll組件system.dll組件主要實現系統用戶分組、用戶權限、登錄驗證、頁面加載等功能。當使用者登錄時，Web頁面調用system.dll的usermanager.cs類文件中的userlogin方法。userlogin方法引用database.dll中的runsql和runproc方法，從數據庫中獲取用戶對應權限及密碼驗證，重組Web頁面。

1.3業務層的mission.dll組件mission.dll組件主要實現系統業務功能，包括項目維護、考核成績錄入、人員管理、任務人員篩選及查詢統計等功能。組件中的類文件執行查詢、添加、刪除、更新、維護等操作，通過調用數據訪問層組件的各個方法實現系統的各項功能[4]。

2主要功能實現

2.1動態生成功能模塊設計時考慮系統的拓展性和可移植性，Web導航頁面、任務保障維護和成績錄入模塊均是動態生成的。使用者只需維護好任務字典和考核科目、子科目、項目字典以及考核規則表，表示層Web導航頁面自動刷新，任務保障和成績錄入模塊根據維護好的字典項目調用mission.dll類文件中的bindmis－sion、bindclass、GridViewShow等各種方法自動更新顯示。

2.2衛勤任務人員選拔衛勤任務人員選拔是本系統設計的主要功能。根據歷次參加衛勤任務的情況、日常考核科目的成績、衛勤保障人員的狀態等綜合測評結果進行本次衛勤任務人員的選拔，選拔結果同時反饋至日常任務維護中。此項功能的實現主要采用.NET中的虛擬表技術，調用Oracle數據庫中的createtableproc存儲過程生成虛擬表動態創建綁定gridview顯示，gridview列名為人員信息、任務名稱及考核科目（這幾項從字典表中提取，具體內容和列數不確定，gridview字段值為列名對應人員信息、任務保障次數及考核項目按權重算出的科目成績）。

2.3ajax控件的使用ajax是異步Javascript和XML的縮寫。在傳統的Web網頁中，當瀏覽器向服務器提出訪問請求時，Web頁面的每個服務器控件均與服務器連接一次。而在ajax處理模型中，一些頁面元素可以直接調用ajax引擎實現功能，只有當信息必須從服務器上獲得時才訪問服務器，這樣可節省時間、提高效率。本系統在登錄用戶的驗證碼、時間控件的獲取、同步刷新導航列表等功能中均使用ajax控件，本文中不再贅述。

篇（7）

二、煙草工業物流信息化應用架構設計

a)煙草工業物流戰略架構

根據行業戰略發展規劃，物流將作為支持性的業務進入企業核心價值鏈，與原料、技術、營銷三大核心業務共同構成各工業公司核心競爭力。在這種架構下，要求各工業企業物流提供整體服務，同時與三大中心一樣，作為核心單位，承擔工業物流管理職能，乃至部分供應鏈服務職能。

b)煙草工業物流運作模式

煙草工業物流普遍采用“集中管理、分級實施”的業務運作模式。根據生產、銷售、采購需求，制定物流計劃，物流中心（公司）根據計劃實施運輸、倉儲等物流作業。上述模式要求對工業企業的各類物流信息實現統一管理，并通過物流中心（公司）實現整體運作和管理。通過對工業內部的信息流和物流的統一管理，將采購物流、生產物流、銷售物流環節由物流中心（公司）實行統一組織，打通供應鏈物流環節，構筑成為一體化物流體系。

c)煙草工業物流信息化應用架構設計

基于核心物流業務發展以及物流中心（公司）運行的需要，煙草工業物流信息化建設應充分考慮自身特點和需求。同時，物流信息化系統的規劃及應用與行業系統、工業公司相關系統有著密切的關聯，需要遵循行業和各工業公司的信息化總體規劃和技術標準。依據對相關工業公司信息化現狀的分析，物流信息化總體應用架構可以按下圖進行歸納：整個應用架構可分為工業物流信息化應用架構及相關外部系統兩大部分。就煙草工業物流來說，主要應用應包括決策支持、綜合管理、業務管理、業務協同、作業執行以及自動化支持等六大功能板塊，以實現整個工業物流不斷發展的運營和管理需求。

d)煙草工業物流信息化應用系統設計

基于對物流中心（公司）信息化應用架構的設計內容，整合各項應用之間的關聯要素和共同點，物流中心（公司）的關鍵應用系統設計。整個應用系統設計包括三個主要層次，一是決策管理層：它是針對業務管理及決策支持等應用功能而設計開發的物流綜合管理系統或模塊，可以與國家局行業物流系統實現對接，同時也為工業公司物流運營和管理提供數據支持。二是業務處理層：包括智能運輸調度與數字倉儲管理兩大核心系統，以及相對獨立的商務結算系統。三是物聯網數據采集層，包括GPS/LBS/GIS系統、車載及手持系統、RFID系統、監控系統等。

三、煙草工業物流信息化技術架構設計

a)整體技術架構

按照國家局提出的“統一平臺”要求，煙草工業物流信息化應用系統建設所采用的技術架構應以安全、可維護、易拓展、高效率為設計基礎，促進技術構架與業務的相互融合、協同工作，使得物流應用系統能夠隨需而變，滿足業務部門的需求。通過對相關工業公司的調研和需求分析，整個技術架構通過基礎資源層、數據交換層、信息資源層、服務引擎層、業務應用層、展現層來搭建物流信息體系，并通過信息安全保障、運維保障體系來確保信息系統安全穩定。

b)關鍵技術設計

i.服務引擎層設計。服務引擎層設計主要采用工作流引擎技術，支持BPEL標準，支持SOA架構，支持子流程、流程分支等基本的工作流功能。ii.業務邏輯引擎設計。業務邏輯引擎使用工廠設計模式，通過XML配置文件，運用類反射機制，完成系統業務邏輯部分的定制工作。物流信息系統通過內置的業務邏輯引擎，可以實現業務邏輯部分的高配置性。iii.調度規則引擎設計。采用高效、靈活的調度規則引擎，對于自動配車、自動配載、訂單拆分等核心規則的調整或優化，可通過前臺可視化配置或定義，無需要后臺編程實現，支持熱插拔規則變更，易于維護。iv.持久層管理組件設計。采用Cosconetwork.DAO庫數據庫持久層組件，通過對JDBC進行輕量級的對象封裝，來完成應用程序和數據庫之間的交互操作，使得系統在更換數據庫時將花費更小的代價，也為系統數據權限的實現帶來了很大的方便性。

篇（8）

1 引言

傳統的投稿方式有郵寄和電子郵件兩種。郵寄投稿方式時間長，反饋慢，并有可能郵寄失敗。E-mail投稿方式基于網絡環境下，利用現在網絡社會中提供的各種電子郵件服務投寄郵件。與傳統的郵寄方式相比,這種方式在時效性和安全性上都邁進了一大步，但同時也存在著許多不足之處，如作者本人郵箱容量的限制、編輯郵箱郵件承載量限制等。

論文投稿平臺的設計開發，主要是為了能夠合理、高效率和更完善的處理論文投稿過程投遞錯誤、半路遺失和處理不及時等引發的問題。該平臺適用于各種類型編輯部門，其主要目標是實現作者的在線投稿、專家審核、論文、論文下載、論文管理和稿件狀態查詢等。

論文投稿平臺功能包含為作者提供在線投稿功能；為審稿專家提供在線審稿功能；為論文投稿平臺管理人員提供各類信息的添加、刪除、修改、統計和查詢等功能；和自動更新論文投稿平臺的一些常規信息，如有關論文投稿平臺的情況介紹以及近期稿件錄用情況。

2 總體設計

本平臺是針對論文在線投稿、在線審核、在線等相關內容進行設計的，主要是展示網站最新的論文動態，介紹論文在線投稿相關的步驟，專家對論文進行審核的主要流程以及讀者在線閱讀和下載的基本程序。另一方面，平臺具有讀者、作者、專家編輯登錄注冊功能。論文在線投稿平臺分為前臺和后臺兩部分。網站前臺展示了整個論文投稿簡介、最新、編委會以及編讀園地等一系列的相關信息，全面向網站用戶展示了平臺的特色。提供在線投稿功能，滿足了作者通過網絡在線投稿論文的需求。通過網絡對論文編輯流程的管理，大大提高了論文投稿的效率。網站后臺實現了各類型用戶信息的管理、對投稿論文進行管理以及用戶的留言信息等，有效的實現了平臺的主要功能。

文投稿平臺是一個利用PHP+Mysql數據庫相結合開發的應用程序，由前臺基本模塊和后臺管理組成，平臺功能模塊如下。

2.1 前臺展示區

主要內容包括首頁、期刊簡介、編委會、投稿指南、編讀園地、刊文選讀、期刊訂閱、聯系我們、幫助、留言、在線投稿、稿件查詢等。2.2 后臺功能管理

主要功能是更新平臺的基本信息、管理前臺論文信息、最新通知和公告信息、注冊信息管理、在線投稿論文的管理、留言信息管理和系統信息管理等。

3 數據庫設計

分析網站功能模塊，論文投稿平臺需要使用數據庫來存儲投稿論文管理、用戶留言、讀者信息管理、作者信息管理、審核者信息管理、編輯者信息管理和管理員表。采用的數據庫是Mysql，該數據庫中定義如下數據表。

3.1 投稿論文表（表名：tg）

投稿論文表主要用于保存投稿論文基本信息，結構如表1所示。

3.2 作者信息表（表名：zz）

作者信息管理表主要用于保存作者基本信息內容，該表結構如表2所示。

編輯者信息管理表主要用于保存編輯者基本信息內容，該表結構如表3所示。

4 投稿平臺設計實現

論文投稿平臺的前臺主要是期刊的簡介、編委會功能職責、投稿指南、編輯園地、刊文選讀、期刊訂閱的介紹，并且具有在線投稿、在線審核和稿件查詢模塊等模塊。實時更新以及論文檢索頁突顯在網頁的前臺。前臺要求網站界面簡潔、盡量展示在線投稿的方便、實用和快捷，并且要求操作方面，便于用戶注冊登錄和瀏覽下載論文，故整個平臺的文件架構比較重要。

前臺頁面主要包括以下功能模塊：

網站導航：為瀏覽者提供清晰明了的瀏覽路線，也為各類用戶介紹了網站的基本功能。

（1）期刊簡介模塊：介紹論文期刊的基本格式、字數要求、論文類型等相關信息。

（2）編委會模塊：介紹編委會的主要成員以及各自的職責。

（3）投稿指南模塊：介紹在線投稿基本流程以及投稿須知。

（4）刊文選讀模塊：介紹各類型刊文、選讀技巧、提供選題方案。

（5）聯系我們模塊：為讀者、作者、審核者提供在線實時對話幫助。

（6）幫助模塊：為各類型用戶提供幫助。

（7）用戶登錄區模塊：讀者、作者、審稿專家、編輯者可以在此模塊進行注冊登錄。

（8）在線投稿模塊：作者可以通過此模塊進行在線投稿。

（9）稿件查詢模塊：讀者和作者可以通過此模塊對所要查詢的論文進行檢索。

（10）動態模塊：展示平臺最新更新論文、通知、公告以及最新錄用信息。

網站后臺主要使用PHP+Mysql數據庫實現前臺信息的添加、修改、刪除和查詢等功能，在論文中不做展開。

5 小結

文章在對在線投稿的研究和探索的基礎上，結合在線投稿具體流程的要求，設計開發出一個具有在線投稿和稿件的編輯處理功能的投稿平臺，該平臺目前已經在少數幾個雜志社投入使用，平臺運行穩定，取得了較好的經濟效益和社會效益。但在平臺大規模推廣使用之前，應該再對平臺再進行改進，以使平臺能夠更加滿足在線投稿的需求。

參考文獻

[1]隋興芳,薛愛華.全面實行電子稿件管理系統處理稿件的體會[J].中國科技期刊研究,2012(16):25-30.

[2]陳翔.基于B/S的期刊稿件管理系統的設計和實現[J].杭州師范學院學報,2014(10):33-38.

[3]蘇波.基于web應用的性能測試研究[J].中國石油大學學報,2013(09):41-45.

[4]鄭阿奇,湯玫.PHP程序設計教程[M].北京:機械工業出版社,2014(07).

篇（9）

中國鐵路客運專線由很多控制系統構成。通信系統是客運專線重要組成系統之一，武廣客運專線正線全長968.52km雙線，共設18個車站，通信系統建設通過采用先進、成熟、經濟、適用、可靠的系統設備，構建高可靠、數字化的綜合通信網絡平臺，為客運專線行車指揮和運營管理提供語音、數據、圖像等多種通信手段。

一、武廣客運專線通信系統構成

通信系統是客運專線重要系統組成之一，系統由通信承載系統、通信業務系統以及通信支撐系統組成，共14個通信子系統。

通信承載系統由傳輸系統、數據網、通信線路以及車站、段所綜合布線系統組成，為通信系統以及其他各類應用系統提供語音、數據、圖像業務的傳送服務。

通信業務系統由電話交換及接人系統、調度通信系統、專業移動通信系統、會議電視系統、應急救援指揮通信系統、綜合視頻監控系統組成，提供有線、無線相結合的公務通信、調度通信等基本通信業務。

通信支撐系統由通信綜合網管系統、同步和時鐘系統、電源系統、電源及通信信號機房環境監控系統組成，作為上述通信承載網、通信業務網相關子系統的運營支撐，提供電源、時鐘同步、網絡管理等功能。

二、通信各子系統功能

2.1傳輸網

提供對車站間物理層業務、數據鏈路層業務的支持，實現TDM、以太網等業務的接入、處理和傳送。

滿足信號系統、牽引供電系統、客運服務等涉及安全生產、資金往來的應用系統的通信傳送需求，并為通信業務網提供傳送通道。

采用STM-6410Gb／s系統組建多業務傳輸平臺(MSTP)骨干匯聚層；采用STM-4622Mb／s接入網系統組建多業務傳輸平臺(MSTP)接人層；采用STM-6410Gb／s設備組成鏈型網絡，MSP鏈型復用段保護方式；采用STM-4622Mb／s設備，根據業務節點的類型組成多個通道保護環。

2.2數據網

為不涉及安全生產、資金往來的各種應用系統提供網絡層的廣域網互聯服務，包括綜合視頻監控、會議電視、各類信息系統等。采用MPLSVPN技術提供各個業務系統業務數據的隔離和QoS保證，利用本線MSTP傳輸系統作為承載平臺。采用核心、匯聚、接入3層結構。

核心層在客專調度所設置骨干路由器，對全線的數據業務進行轉發；匯聚層在沿線大站設置匯聚路由器，負責區域內數據業務的轉發；接入層在沿線客運站、段所、客專公司設置接人路由交換設備，負責站內數據業務的接人。節點之間通過MSTP系統提供的155Mb／s通道互連，構成環形、星型雙歸。

利用MSTP多業務光接入網提供未設置數據網沒備節點的數據業務的匯聚和接人。

2.3通信線路

在鐵路兩側電纜槽道內各敷設1條主干32芯光纜，形成不同物理路徑的光纜線路，纖芯容量及分配滿足各專業的需求；沿線另敷設8芯短段光纜解決GSM-R光纖直放站的纖芯需求。

2.4車站、段所綜合布線

在客運公司、動車段、綜合維修段及各車站設置綜合布線系統，由工作區子系統、水平子系統、干線子系統、設備間子系統、管理子系統組成。

2.5電話交換及接入系統

利用鐵通既有程控交換設備，按照綜合維修段管界分段納人既有鐵路電話交換網統一編號組網。

新沒接入網系統，沿線車站新設ONU設備，分段接入新設OLT設備，OLT設備通過V5.2接人鐵通程控交換設備。

2.6調度通信系統

提供各種具有調度通信特征的語音通信業務，實現固定用戶與移動用戶的統一呼叫。提供鐵路專用通信、站場通信、站間通信。采用固定用戶接人交換系統WAS組織調度通信系統。通過與CSM-R系統互連，實現有線無線調度一體化。在客專調度所、通信站新設調度所FAS設備，互為備用，實現調度所FAS設備的同城異地備用。沿線各車站、動車段、動車運用所新設站段FAS，通過傳輸系統提供的E1接入調度所FAS設備。新設FAS設備通過30B+D接口、DSS1信令與既有部干調、路局數調系統互聯，解決調度臺間聯絡業務。

2.7專用移動通信系統

采用GSM-R系統提供無線列調、ETCS-2列控、車次號跟蹤、調度命令傳輸、區間公務移動通信等業務應用。系統采用GSM-R技術實現，由交換子系統、基站子系統、運行與維護子系統、移動智能網子系統、通用分組無線業務子系統以及GSM-R終端組成。

交換子系統、移動智能網子系統、通用分組無線業務子系統由GSM-R核心網工程建設。

為避免基站子系統部分設備的單點故障提高GSM-R系統的可靠性，基站子系統可采用單網冗余覆蓋建設方案，當某一個基站出現故障時，相鄰兩個小區的覆蓋電平仍然能夠達到系統規定的性能要求。根據行車密度、車站股道數和定員數，結合話務模型進行測算，基站容量按樞紐站四載頻、一般車站三載頻、區間基站兩載頻設計。

2.8會議電視系統

會議電視系統為全線的運營管理提供高質量的視頻會議功能。系統采用H.323架構，H.264壓縮編碼格式，利用數據網進行承載。

2.9應急救援指揮通信系統

應急救援指揮通信系統由應急中心設備以及沿線現場設備組成，緊急情況下為應急中心提供事故現場的實時動態圖像，并建立雙向的語音、數據傳輸。

長大水底隧道(武廣瀏陽河隧道)另設緊急電話系統、隧道視頻監控系統和廣播系統，為隧道的緊急救援提供更多的通信保障。

2.10綜合視頻監控系統

由監控中心、監控分中心、監控終端以及前端設備構成。監控中心設于客專調度所，負責全線視頻監控設備及網絡的統一管理和調度，可以對全線的視頻監控圖像進行調用。監控分中心設于沿線客運站，負責本站及相鄰區間的圖像存儲、后期分析處理以及圖像的分發管理。監控終端設于調度所、綜合維修段、路局相關部門。可以對管內的視頻監控圖像進行調用。前端由攝像機設備、光端機、視頻服務器(編碼器)設備組成，設置于沿線車站、區間現場，實現對監控對象圖像的采集和前期分析處理。

2.11通信綜合網管系統

在客專調度所設置綜合網管系統中心設備，包括數據庫服務器、應用、采集服務器、磁盤陣列、交換機、第三方軟件、應用軟件、管理終端等，實現對客專調度所管轄范圍內通信網絡的管理。前端通過與各通信子系統網元級管理系統互連，實現對通信子系統網管信息的采用。在綜合維修段、路局沒置遠程管理工作終端，滿足相關運營維護人員對其管內通信系統的管理。

2.12同步及時鐘分配系統

為通信系統以及其他信息系統提供時鐘同步、時間同步功能。時鐘同步采用主、從同步方式，沿線設置多個二級節點時鐘BFF$，時鐘同步源取自鐵通既有LPR時鐘信號。在客專調度所設置中央主時鐘(包括GPS)以及NTP分配單元，通過數據網、傳輸系統提供標準時間信號。

2.13電源系統

系統采用直流通信設備提供高可靠性的48v直流電源、交流通信設備提供高可靠性的220V交流電源。

采用組合開關電源設備和閥控式密封鉛酸蓄電池組，電源整流模塊采用N+I方式備份，配置2組蓄電池組，后備時間1h。采用UPS系統和后備電池組，配置1組蓄電池組，后備時間1h。

2.14通信電源及通信信號機房環境監控系統對通信、信號機房的機房運行環境和安全等進行實時監控，可監測的環境量包括溫濕度、煙霧、水浸、門禁、非法入侵、空調的控制；對通信系統所采用的交、直流電源設備進行監測。

由一級監控中心、二級監控中心、前端監測單元SU設備構成。一級監控中心設于客專調度所，負責對全線動力設備和環境的集中監控和管理；二級監控中心沒于沿線通信站、綜合維修段，負責對其管內的動力設備和環境進行監控和管理。

篇（10）

隨著通信網技術的進一步發展，越來越多的互連網設備（如路由器、開關、網關、存取裝置）中的串行接口在廣域網（WideAreaNetwork）中被設計成能夠支持多種物理接口協議或標準。廣域網串行口協議包括RS－232，RS－449，EIA－530，V．35，V．36以及X．21等。圖1所示是一個簡單的串行通信接口示意圖。由圖可知，實現多協議串口通信的關鍵是將連接器送來的不同傳輸方式平衡、非平衡和不同電氣信號通過收發器轉換為終端能夠識別并處理的、具有TTL電平的信號。

1傳統多協議通信的特點和問題

1．1“子板”方式

廣域網串口應用中的通用實現方法是為所需的每一種物理協議提供一個獨立的子板。一個支持EIA－232，EIA－449及V．35協議的系統，通常需要三個獨立的子板以及三個不同的連接器。這種方法由于每種協議要求配置一塊子板，因此系統需要對PCB子板、收發器芯片、連接器等進行管理，這樣既浪費資源，又會使管理工作復雜化。

1．2通用連接器方式

為解決“子板”方式的缺點，可使用一塊母板及通用連接器。一個母板上有多種收發器芯片，可以滿足多串口協議的要求，并可共用一些通用器件，同時可減少資源的浪費。在配置中，應注意因連接器的管腳較少而帶來的問題，較好的辦法是根據信號而不是根據協議來分配管腳，即給每一個信號分配一個通用管腳，而不管其物理協議如何定義。如對EIA－232，EIA－449，EIA－530，V．35和V．36來說，其TxD信號可連至連接器相同的管腳。即SDa信號連接到管腳2，SDb信號連接到管腳14。然后利用這對管腳來描述所有協議的發送信號TxD。

這種方法同樣也會帶來一個問題，即所有收發器的I／O線至通用連接器的管腳必須彼此共用。例如，一個V．28驅動器芯片中的發送數據信號線的接連接器DB－25的管腳2；同時，一個V．11驅動器芯片中的發送數據信號線要接至連接器的管腳2和14；而V．35驅動器芯片中發送數據信號線也會接至連接器的管腳2和14。這樣，通用連接器的管腳2將同時接有三根信號線，管腳14接有兩根信號線。這樣，在這一配置中，所有的驅動器都必須具有三態特性，以禁止不必要的輸出。若收發器沒有三態特性，則需要使用一個多路復用器來選擇相應的輸出端。由此帶來的另一個問題是收發器在禁止使用時會產生漏電電流。如果選擇了V．28協議，其輸出電壓理論值為15V。此時對于V．11協議的驅動器會被禁用，而處于三態時，其輸出漏電電壓就必須足夠低，才能使得連在同一連接器管腳的V．28協議的驅動器信號不受影響。如果在發送器與接收器之間有隔斷開關，則開關也要考慮漏電情況。

1．3串口的DTE／DCE模式切換

DTE／DCE的切換可通過選擇不同的連接器轉換電纜來實現，這樣，在實現DTE／DCE轉換時可最大程度地減小收發器的復雜性，但缺點是需要更換電纜，尤其是設備放置位置不便或DTE／DCE需要頻繁切換時這一點尤為突出。

如果保持傳輸電纜不變，則可將收發器配置為兩套以分別支持DTE、DCE方式。而將DTE收發器的驅動器輸出與DCE收發器的接收器輸入相連，而將接收器輸入端與DCE收發器的驅動器輸出相連。為了控制DTE或DCE方式，驅動器或接收器的輸出必須為三態。當選擇為DTE方式時，DCE芯片禁止，其驅動器和接收器處于三態，反之亦然。

該方法雖然解決了對電纜的頻繁更換問題，但由于多用了一套收發器而使得設計成本大為提高，且串口板的體積也大了很多。

2多協議串口通信的實現原理

傳統設計中，針對某種協議通常應選擇相應的收發芯片，如對于RS－232協議，常用DS－1488／DS－1489、MAX232或SP208等收發器芯片；而對于RS－449協議，則常使用SN75179B、MAX488、MAX490等收發器芯片。當同時使用RS－232、RS－422和V．35協議時，就需要多個收發器芯片來支持不同的協議。

現在，一些收發器的生產廠商研制出了多協議收發器芯片。Sipex是第一家生產出RS－232／RS－422軟件可選擇協議芯片SP301的公司。這種芯片可將RS－232和RS－422收發器的電氣特性綜合到一個芯片中實現。其中SP50X系列產品最多可支持8種協議標準。其它生產廠家如Linear公司生產的LTC154x系列、LTC284x系列芯片也具有以上功能。用戶可根據自己的需要選擇適當的芯片。

圖2為采用分立的收發器芯片與采用一片多協議收發器芯片實現多協議串口通信的通信卡。從圖可知，前者實現的復雜度要遠遠大于后者，具體的性能比較如表1所列。

表1兩種方法實現串口通信的性能比較

分立器件板綜合器件板

供電電壓+5V，-5V，+12V，-12V+5V

所需收發器芯片數121

支持的物理層協議RS-232，RS-422，RS-449，EIA-530，V.35，V.36RS-232，RS-422，RS-449，RS-485，EIA-530，EIA-530A，V.35,V.36

協議選擇方式跳線或開關軟件或硬件（通過內部譯碼）

串口板大小除了15個收發器芯片外還需其它硬件支持非常小

功耗大約1W大約100mW～250mW

除此之外，與分立收發器芯片相比，多協議收發器對驅動器使能控制和對輸出漏電電流的處理要容易得多。當通過軟件或硬件方法選擇某一協議時，驅動器和接收器的電氣參數將調整至適當的大小，電路內部將自動控制驅動器的輸出電平、接收器的輸入門限、驅動器和接收器的阻抗值以及每一物理層協議的常用模式范圍。

另外，由于外部網絡終端對V．35的需求，使得與V．35收發器的連接不能象其它協議那么簡單。當使用分立收發器芯片時，常常通過采用昂貴的繼電器開關電阻在選擇其它協議接口時將V．35網絡終端斷開，或者要求用戶每選擇一個新的接口標準就改變一次終端模塊，這樣既浪費資源又會使接口電路變得復雜，因而不是一種理想的實現方法。而多協議串口芯片則自動提供適當的終端和片上開關來符合V．10、V．11、V．28和V．35電氣協議，從而解決了電纜終端轉換問題。

3基于LTC1546／44的多協議通信

為了說明多協議串口芯片的工作原理，現以Linear公司的LTC1546／1544芯片為例進行分析。

3．1LTC1546／LTC1544的性能

LTC1546芯片是一個3驅動器／3接收器的收發器，其主要特點如下：

帶有軟件可選的收發器可支持RS232、RS449、EIA530、EIA530A、V．35、V．36和X．21協議

可提供片上電纜終端

與LTC1543引腳兼容

與LTC1544配合可完成完整的DTE或DCE

工作在5V單電源

占位面積小。

LTC1544芯片是一個4驅動器／4接收器的收發器，其主要特點有：

軟件可選的收發器支持RS232、RS449、EIA530、EIA530A、V．35、V．36和X．21協議

采用LTC1344A作為軟件可選的電纜終端

采用LTC1543、LTC1544A或LTC1546可實現完整的DTE或DCE端口

與LTC1543同樣工作于5V單電源。

這兩種芯片均采用28引線SSOP表面貼封裝，圖3所示為其引腳排列。

由LTC1546／LTC1544可組成一套完整的軟件可選擇DTE或DCE接口，以應用于數據網絡、信息業務單元CSU和數據業務單元(DSU)或數據路由器中，它支持多種協議，電纜終端可在片上提供，因此不再需要單獨的終端設計。其中，LTC1546每個端口的一半用來產生和適當終止時鐘和數據信號。LTC1544則用來產生控制信號及本地環路返回信號(LocalLoop－back，LL)。接口協議通過模式選擇引腳M0、M1和M2來決定，具體選擇方式見表2。

表2通信協議的模式選擇

LTC1546模式名稱M2M1M0DCE/DTED1D2D3R1R2R3

未用（缺省V.11）0000V.11V.11V.11V.11V.11

RS530A0010V.11V.11ZV.11V.11V.11

RS5300100V.11V.11ZV.11V.11V.11

X.210110V.11V.11ZV.11V.11V.11

V.351000V.35V.35ZV.35V.35V.35

RS449/V.361010V.11V.11ZV.11V.11V.11

V.28/RS2321100V.28V.28ZV.28V.28V.28

無電纜1110ZZZZZZ

未用（缺省V.11）0001V.11V.11V.11ZV.11V.11

RS530A0011V.11V.11V.11ZV.11V.11

RS5300101V.11V.11V.11ZV.11V.11

X.210111V.11V.11V.11ZV.11V.11

B.351001V.35V.35V.35ZV.35V.35

RS449/V.361011V.11V.11V.11ZV.11V.11

V.28/RS2321101V.28V.28V.28ZV.28V.28

無電纜1111ZZZZZZ

由表2可知，如果將端口設置為V．35模式，模式選擇引腳應當為M2＝1，M1＝0，M0＝0。此時，對于控制信號，驅動器和接收器將工作在V．28(RS232)模式；而對于時鐘和數據信號，驅動器和接收器將工作在V．35模式。

模式選擇可通過控制電路或利用跳線將模式引腳接至地或Vcc來實現對引腳M0、M1和M2的控制，也可通過適當的接口電纜插入到連接器上實現外部選擇控制。若選用后者，則當移開電纜時，全部模式引腳均不連接，即M0＝M1＝M2＝1，此時LTC1546／LTC1544進入無電纜模式。在這種模式中，LTC1546／1544的供電電流將下降到500μA以下，并且LTC1546／LTC1544驅動器輸出將被強制進入高阻狀態。同時，LTC1546的R2和R3接收器應當分別用103Ω端接，而LTC1546和LTC1544上的其它接收器則應通過30kΩ電阻接到地。

通過DCE／DTE引腳可使能LTC1546中的驅動器3／接收器1、LTC1544中的驅動器3／接收器1和驅動器4／接收器4；LTC1544中的INVERT信號對驅動器4／接收器4起使能作用。可以通過下面兩種方法中的一種將LTC1546／LTC1544設置為DTE或DCE工作模式：一種是將專門配有適當極性的連接器接至DTE或DCE端；另一種是通過專用DTE電纜或專用DCE電纜發送信號給LTC1546／LTC1544，同時使用一個連接器構成一種既適合DTE又適合DCE的工作模式。

3．2典型應用

圖4為一個帶有DB－25連接器端口并可被設置為DTE或DCE工作模式的多協議串口通信電路，圖中LTC1546／LTC1544芯片一邊與連接器相連，另一邊接至HDLC芯片，M0、M1、M2及DCE／DTE引腳接至EPLD硬件控制電路以實現對通信協議和工作模式的選擇。其中DTE或DCE工作模式需要連接對應的電纜以保證正確的信號發送。例如，在DTE模式中，TxD信號通過LTC1546的驅動器1發送到引腳2和14。在DCE模式中，驅動器則將RxD信號發送到引腳2和14。

圖4中，LTC1546采用一個內部容性充電泵來滿足VDD和VEE。其中，VDD為符合V．28的正電源電壓端，該端應連接一只1F的電容到地；VEE為負電源電壓端。一個電壓倍增器在VDD上將產生大約8V電壓，而電壓反相器則將在VEE上產生大約－7．5V的電壓。四只1μF電容均為表面貼裝的鉭或陶瓷電容，VEE端的電容最小應為3．3μF。所有電容耐壓均應為16V，同時應盡可能放置在LTC1546的附近以減少EMI干擾。

圖4用LTC1546/LTC1544芯片實現多協議串口通信（DTE/DCE可選）

在V．35模式中，LTC1546中的開關S1和S2將導通，同時應連接一個T型網絡阻抗，以將接收器的30kΩ輸入阻抗與T網絡終端并聯起來，但不會顯著影響總輸入阻抗，因此對于用戶來說，這種模式下的電路設計與其它模式下完全相同。

由于LTC1546是3驅動器／3接收器的收發器，LTC1546是4驅動器／4接收器的收發器，所以如果同時采用RL、LL和TM信號，則LTC1546／LTC1544就沒有足夠的驅動器和接收器。因此，可用LTC1545來替換LTC1544。LTC1545為5驅動器／5接收器的收發器，它能夠處理多個可選的控制信號，如TM和RL。