熱門論文
最新論文
車輛報修信息管理系統
發布時間：2023-07-20 15:15
摘 要 I
Abstract II
目 錄 III
第一章 緒論 1
1.1研究背景 1
1.2公交車輛維修信息系統的研究現狀 2
1.2.1車輛維修的研究現狀 2
1.2.2管理信息系統的研究現狀 3
1.2.2.1國外的發展及研究現狀 3
1.2.2.2國內的發展及研究現狀 4
1.3開發公交車輛報修信息管理系統的意義 4
1.3.1有助于提高公交公司信息化管理 4
1.3.2有助于促進公交調度管理水平的提高 5
1.3.3有助于提高企業競爭力 5
1.3.4為企業決策提供有效支撐 5
1.4本文的研究內容、技術路線和研究成果 6
1.4.1本文的研究內容 6
1.4.2本文的技術路線 6
1.4.3本文的研究成果 7
1.5本文的章節結構 8
第二章 項目概況及可行性分析 9
2.1項目背景 9
2.1.1廣州市一汽巴士有限公司概況 9
2.1.2一汽巴士公司信息化建設概況 9
2.1.3一汽巴士公司公交車輛報修體系的組織架構 10
2.2項目需求分析 11
2.2.1一汽巴士公司車輛報修體系的業務結構 11
2.2.2一汽公司車輛報修體系的業務流程 14
2.2.2.1車輛報修、檢驗驗車流程 14
2.2.2.2車輛保養維護流程 15
2.2.2.3物資材料領取流程 16
2.3車輛報修信息管理系統的開發目標 17
2.4系統的開發形式 18
2.5項目可行性分析 21
2.5.1技術可行性分析 21
2.5.2經濟可行性分析 23
2.6本章小結 24
第三章 公交車輛報修信息系統設計 25
3.1系統體系結構 25
3.2.1系統運行環境 25
3.2.2系統物理網絡結構 25
3.2.3系統設計結構 26
3.2信息系統結構設計 27
3.2.1車輛報修信息管理系統的顯示層設計 27
3.2.2車輛報修信息管理系統的邏輯層設計 29
3.2.3車輛報修信息管理系統的數據層設計 31
3.3本章小結 33
第四章 車輛報修信息系統模塊設計 34
4.1用戶身份驗證模塊設計 34
4.2用戶權限管理模塊設計 37
4.3報修資料模塊設計 39
4.4基礎數據模塊設計 42
4.5維修知識庫模塊設計 46
4.6車輛報修派工模塊設計 48
4.7報表管理模塊設計 49
4.8系統測試實例演示 53
4.9本章小結 54
第五章 公交車輛報修信息系統關鍵技術研究 55
5.1二級維護作業計劃優化 55
5.1.1數學模型 55
5.1.2效果分析 58
5.2系統更新維護技術優化 58
5.2.1客戶端自動升級功能的實現 59
5.2.2客戶端自動更新功能的效果分析 60
5.3微信企業公眾號的相關技術研究 61
5.4車輛報修信息系統應用后的管理效果分析 63
5.5本章小結 64
總結和展望 65
參考文獻 67
附錄：《故障修理大于2小時車輛》的報表代碼 71
第一章 緒論
1.1研究背景
隨著經濟的快速發展和生活水平的提高，我國的機動車保有量不斷增加，由此帶來 的交通擁堵問題日益嚴重。根據公安部交通管理局公布的信息，截至 2017 年底，全國 機動車保有量達 3.1 億輛，其中汽車保有量達 2.17 億輛。據 2007 年中國社科院數量經 濟與技術經濟研究所測算，北京市因為堵車造成的社會成本達到每天 4000 萬元，相當 于每年 146 億元 ［1］。交通擁堵已經成為亟待解決的“城市病”。公交車作為市民出行的 首要選擇，具有載客量大、運輸效率高的特點。大力發展公共交通，倡導綠色出行，成 為緩解交通擁堵的有效手段。
本文主要以廣州市公交客運企業為研究對象，根據《廣州交通運輸月報〔2017〕第 5 期》［2］統計，2017 年 5 月廣州市公共交通客運量為 4.98 億人次，日均客運量為 1608 萬人次。如圖 1-1 所示：
圖 1-1 2015 年 - 2017 年各月的公共交通客運量情況
其中，常規公交的客運量占比僅次于軌道交通，日均運輸旅客666 萬人次。而軌道 交通日均運輸旅客達到了 769萬人次，而出租車日均運輸旅客人次為172 萬。從公共交 通客運占比看，本月常規公交客運量占 41.46%，軌道交通占 47.87%，出租車占 10.68%。 見圖 1-2：
圖 1-2 2017 年 5 月各公共交通方式的占比情況
從圖 1-1看，公共交通客運量呈現快速增長的勢頭；從圖 1-2看，公共汽車站占比 41.46%，公共汽車依然是市民出行的重要選擇。而公交車輛的技術性能的穩定性決定著 公交車輛能否參加線路運輸，影響著公交線路以及公交系統的正常運行。因此，提高公 交汽車的維修和保養的管理水平，可以提高公交車輛的安全性能，有效控制維修成本， 保證公交車輛的正常運轉，對城市公共交通具有極為重要的意義。
公交行業作為一個特殊服務行業，本身具有社會公益性和企業經濟效益的特征。車 輛的長時間運行，必然會導致維修頻率、維修成本以及維修時間上比普通車輛更高。通 過建立公交車輛的高效及時維修體系，可以確保車輛安全性能和良好技術工況，從而有 利于節省能源和提高運輸效率。這就要求其提高車輛的維修效率。對此，公交企業的管 理者迫切需要更完善的管理體制和更高效的管理工具，從而能有更多的時間和精力去研 究市場競爭的關鍵問題。因此，尋找能實現企業管理信息、高效化的管理工具已成為一 項迫切的任務。
1.2公交車輛維修信息系統的研究現狀
1.2.1車輛維修的研究現狀
車輛維修根據其目的和時機，可分為修復性維修(corrective maintenance, CM)和預 防性維修(preventive maintenance, PM)。修復性維修，是指車輛發生故障后，使其恢復 到維修前的狀態所采取的全部措施。預防性維修，是指依照車輛維護技術規范，對車輛 的各部門性能部件進行檢查測試,尋找故障隱患并采取措施來避免發生故障,從而使得 車輛保持在規定狀態的活動 [3]。
國外對于公交車輛的維修主要著重于數學模型的構建,在維修時間和維修成本上尋 求最優解［4］，從而提高車輛維修的經濟性。早在2004年，美國J.H.Seo和D.S.Bai提 出了車輛大修（Overhaul）影響的數學模型［5］，通過求解修理頻率及間隔，得出最小花 費率的目標期望。而C.Qian則利用積累損壞模型來實現最小維修和替換策略［6］。2006 年，Yeh Lam對幾何單調過程（GP）進行改進，提出了更加合理的混合維修策略［7］，從 而降低單位時間平均成本。針對公交維修的每天排班問題，2001年Haghani和Shafahi 提出建立了數學規劃模型，并通過模擬為期182天的公交維修案例來驗證模型［8］，模型 的目標是維修效率最大化和對線路營運影響最小化。
而國內方面，對公交車輛保修的研究比較多地著重于維修系統的設計與研究 ［9］，對 車輛報修流程等的優化少有涉及。實際上，通過車輛報修信息系統，可以實現預約保養 維修，合理安排車輛進廠，最大化利用技工資源，將有限技工時間按需分配 ［10］，從而 減少對車輛營運的影響，實現最大的經濟效益。
1.2.2管理信息系統的研究現狀
1.2.2.1國外的發展及研究現狀
管理信息系統（MIS: Management Information Systems）是自然科學與社會科學融合 產生的一門新興學科［"I。其最早可追溯至1967年由美國明尼蘇達大學Davis教授所創 立［12］，并隨著計算機技術的持續發展而不斷發展改進。 1946年，世界上第一臺電子計 算機誕生于美國賓夕法尼亞大學 ［13］。此后計算機技術蓬勃發展，并經歷了 4 個發展階 段。而國外的管理信息系統的發展也大體經歷了四個階段［14］。
第一階段為1953-1958年，主要為計算機開始進入大企業，從事單項數據處理［15］。 第二階段為1958-1966年，計算機技術進一步發展，聯機系統開始出現，系統可以進行 更復雜的數據綜合處理［16］。第三階段為1966年-1971 年，集成電路開始出現，計算機 的體積更小，信息處理能力更強。同時受益于電信通訊技術的進步和操作系統的出現， 使得計算機中心處理機構可以收集客戶端的信息進行集中處理［17］。第四階段是1971年 至今，集成電路的大規模運用以及硅晶片加工工藝的演進，使得計算機運行速度有了質 的飛躍。同時，得益于數據庫技術和網絡技術的發展，管理信息系統開始進入數據的系 統處理階段 ［18］。企業可以對生產經營過程中的數據進行收集和存貯［19］，為企業各個部 門改進生產和提高效率提供數據支撐，整個管理系統發生了質的變化。
隨著 IT 技術的迅猛發展，近年來，國外先進企業開始普遍使用各項先進的信息技 術，例如云計算、面向對象（00）技術、C/S、B/S和關系數據庫管理系統（RDBMS） 等 ［20］，使得管理信息系統的應用更廣，實用性更強。
1.2.2.2國內的發展及研究現狀
管理信息系統在我國的應用相對國外要晚。大體可分為 3 個階段。第一階段為 1980-1990年，主要是用作統計數據，基于單機（PC）集中式處理，在財務、工資等方 面應用較多［21］。第二階段是1990-1995年，進入管理信息系統的單項子系統應用，數據 庫開始普及，通過數據的分類和使用，使得子系統具備了一定的功能，分擔了部分工作 人員的工作 ［22］，有力地提高了工作效率。第三階段是 1995 年后至今的綜合應用階段， 結合互聯網和數據庫技術的廣泛應用，打破了時間和空間的限制，加快了信息的交流［23］， 為企業建立MIS提供了充分條件。
國內有部分公交公司初步建立了車輛信息管理系統，但大多數研究都著重于材料成 本控制和技工排班派工的模型優化上 ［24］，對公交車輛保修各個環節因溝通不暢、信息 傳遞延誤產生的時間成本、資源利用低下等問題研究較少。
1.3開發公交車輛報修信息管理系統的意義
由于公交行業的特殊性，尤其是近年來，公交車輛營運調度管理開始向智能化、集 約化轉變 ［25］，而車輛保養維修作為營運調度的后勤保障工作，對其效能和質量的要求 也日趨嚴格。同時，如果能實現公交車輛報修信息管理系統的建立，可以極大地提升企 業管理水平，提高企業效益。
1.3.1有助于提高公交公司信息化管理
傳統的汽車維修管理中，涉及的檢驗員、技工、管理者、車輛等對象眾多，還涉及 到數據錄入、查找和修改，以及維修任務的分配等眾多流程 ［26］，更不用提報表統計和 數據分析等大量繁瑣工作。因此，如果依靠人工來進行維修管理，就會使得公交企業維 修部門的工作效率低下。然而，通過車輛維修管理系統，企業既可以把車輛和維修資料 進行規范化和信息化，使得數據查詢效率大幅提高；還可以使得企業的車輛維修作業的 流水線化。此外，由于基礎數據的規范化，企業可以通過對車輛、維修數據進行統計分 析，從而使得企業的維修工作管理更規范、更快捷、更準確。
1.3.2有助于促進公交調度管理水平的提高
如果說城市公交是城市交通的動脈，那么城市公交調度城市交通的心臟所在，它的 有效組織影響著城市交通的效率。而公交車輛的車質車況，則對調度管理工作有著重要 意義。“巧婦難為無米之炊”，良好的車輛車質車況，可大大增加了線路的可使用運力， 使得大站快車、區間短線以及區域聯運等調度措施可以實施，客觀上有力與促進公交調 度管理水平的提高。
1.3.3有助于提高企業競爭力
改革開放后，社會經濟持續發展，人們收入水平也在逐步提高。而公共交通行業在 員工薪資、工作環境和勞動強度等方面有著先天的不足，導致行業普遍出現駕駛員數量 緊缺的現象 ［27］。與此同時，公交企業作為勞動密集型企業，對人力資源成本的上升尤 為敏感。如何壓降企業的成本，減少浪費。成為擺在企業面前的一大難題。
建立報修信息管理系統，一方面可通過錯位調度、取車頂位等方式，減少車輛保養 維修后的車停人停的情況 ［28］，有利于優化企業的車輛人員配置，有利于提高線路服務 水平，有利于提高企業效益。另一方面，車輛維修信息的規范化，有利于企業尋找維修 保障工作的規律，有利于提高企業維修作業的效率和質量。通過大數據對各車型的各類 故障情況進行統計，有利于企業優化車輛及備件采購 ［29］，壓降企業成本，提高企業競 爭力。
1.3.4為企業決策提供有效支撐
企業決策與決策分析是指一定的階段表現為個體的行為。車輛維修過程中，會產生 大量如故障類型和發生頻率、材料損耗隨車型和季節的變化、技工的工時變化的數據［30］。 并且隨著時間的推移和業務發展，維修數據呈幾何級膨脹趨勢 ［31］。企業決策者需要更 快捷、更方便、更準確的參考大量相關數據，獲取有意義的關鍵信息，從而清晰地了解 企業經營狀況，為下一步企業決策和提升企業競爭優勢提供支持。通過開發車輛報修信 息管理系統，可以有效地將車輛維修數據利用起來，為車輛二級維護、材料采購等決策 提供數據支撐 ［32］。
1.4本文的研究內容、技術路線和研究成果
1.4.1本文的研究內容
本文主要結合廣州市一汽巴士有限公司的車輛維修保養業務需求，結合企業原有的 管理架構，建立基于 C/S 的車輛報修信息管理系統，所研究設計的信息管理系統必須滿 足以下兩方面特性：
（1） 報修信息管理系統必須可以更便捷的應用于各個環節 由于公交行業的特殊性，公交公司通常是采取“養用合一”車輛運營保養方針 ［33］，
而車輛的維修保養，涉及到維修管理、技工派工管理、車輛出入廠記錄、材料管理于一 身，需要提供用戶權限、用戶管理、維修報表、員工管理等一系列功能，以滿足一線生 產需要，從而為其在管理提供了決策依據。
（2） 報修信息管理系統接口必須與現有的企業內部管理系統兼容
如果新開發的報修信息管理系統可以與現有的企業內部管理系統兼容。一方面可以 大大提供數據的共享，避免重復數據采集錄入，節省企業成本；另一方面，也可以提高 實際的操作可行性，做到實時監控，實時反饋信息，提高企業效率。
設計開發公交車輛的報修信息管理系統，是適應時代發展需求的。隨著經濟和科技 的快速發展，數據庫管理技術、云計算等互聯網IT技術逐漸深入和普及［34］，在公交車 輛的維修體系中引入管理信息系統的使用是公交公司實現網絡化建設和智能化建設的 迫切需求，也是提升公交公司車輛保養維修管理水平的必經之路。使用維修系統，可以 解決傳統的維修體系中各個環節銜接中出現的信息斷層或錯誤傳遞等問題 ［35］，而使公 交公司提高維修工作的科學化、合理化管理。因此開發車輛維修管理信息系統具有其實 質性意義。
1.4.2本文的技術路線
1、通過網絡查詢、圖書館文獻借閱等方式，了解目前國內外對車輛報修信息管理 系統的研究情況。同時，收集公交車輛維修保養的技術標準和安全標準，了解相關國家 法律法規。
2、收集企業管理層的要求和企業的信息化思路，明確企業需求，開展項目可行性 研究等前期調研工作。通過對C/S、B/S架構以及Delphi等相關技術的理論研究及優缺 點分析，對系統的經濟可行性和技術可行性進行分析。
3、 確定系統的架構，對系統進行具體模塊開發和設計。
4、 實際應用和完善。通過使用推廣，不斷對存在的問題進行完善，從而使得系統 可以持續適應企業的需求變化。
1.4.3本文的研究成果
本文在詳細調研分析了廣州市一汽巴士有限公司的維修業務流程的基礎上，開發了 基于C/S架構的車輛報修信息管理系統。主要研究成果如下：
1、 分析了車輛維修信息系統的研究背景和現狀，指出了開發車輛報修信息管理系 統，有利于企業提高維修效率，也符合企業“一個引領，兩個提高，三個保障”的企業 戰略。
2、 分析了企業對系統穩定性、運行速度和安全性的具體需求，提出了系統采用 C/S 架構的系統開發方案，并確定采用系統生命周期法進行本項目的開發。
3、 在系統設計階段，確定了系統的體系架構，搭建了企業的數據庫，對各類維修 數據建立了相關的數據表，設計了用戶登陸驗證、報表設計等系統功能模塊，對企業的 維修工作管理起到了很好的規范作用。其中維修知識庫采用了基于層次遞歸查詢算法的 樹形結構，使得系統成為企業車輛維修的“好幫手”。
4、 為了進一步提高系統后期運行維護的成本，對系統進行了優化，增加了系統的 強制更新功能，實現了遠程自動更新。還對系統的擴展性進行了拓展，通過預留接口， 實現了在微信企業微信公眾號查詢車輛報修信息的功能，提高了用戶的查詢系統數據的 便捷性，也大大提高了企業的信息化水平。
總而言之，車輛報修信息系統的開發，有利于企業最大化利用現有維修資源來實現 “養用合一”的企業經營策略，有利于提升企業競爭力，有利于提高企業效益。
1.5本文的章節結構
本文的章節結構組織如下：
第1 章主要介紹了車輛報修信息管理系統項目的研究背景、研究現狀以及對企業的 意義，說明了研究的目的。
第2章主要介紹了廣州市一汽巴士有限公司的公交車輛報修體系的基本情況，從企 業的組織結構角度、業務結構角度和業務流程角度進行分析，從而明確系統開發目標和 系統的開發形式。并對項目的技術可行性和經濟可行性進行了分析。
第3章主要介紹了系統開發的體系結構，包括系統的運行環境、物理網絡環境和軟 件模型。系統設計主要是從顯示層、邏輯層以及數據層三個環節展開，分別闡述了設計 原則、數據處理原則以及數據庫建立方法等內容，并通過實例來展示了顯示層的設計和 數據表結構。
第4章主要介紹了報修管理系統中部分重要模塊。如用戶身份驗證及權限管理模塊、 用戶權限管理模塊、基礎資料模塊以及派工模塊等。該章節對車輛檔案、故障分類等基 本數據的定義進行了規范，也對系統的報表設計、生成和輸出進行了闡述。驗證了系統 開發基本達到了企業需要的效果，能夠有效地指導企業生產，提高企業管理效率，為企 業決策提供有效支撐。
第 5 章主要是在第五章系統開發的基礎上，進一步對如何使用系統和數據庫資源， 對車輛二級維護計劃優化技術進行研究，有力地指導了企業的維修保養作業工作計劃， 提升了企業效益。同時對系統的后期更新維護模塊進行了更新，實現了系統的自動更新 功能，降低了系統維護成本。其次是探索企業微信公眾號查詢車輛報修信息的可行性， 初步實現了查詢 30 天內車輛報修記錄的功能。最后是對系統在企業應用推廣后，對企 業的成本壓降和管理效率提升進行分析。
第6章總結和展望，對整個項目的實施過程中的經驗進行總結，分析了系統的不足 之處，并對未來的系統優化工作方向進行了展望。
第二章 項目概況及可行性分析
在一汽巴士公司的信息化工作規劃中，要求建設與生產實際相符合的車輛報修信息 管理系統。車輛報修信息管理系統的設計開發必須不僅要結合一汽巴士公司的車輛報修、 保養和維護工作的流程，更需要詳細了解企業對系統的業務量、運行速度等需求。本章 將會先對一汽巴士公司的公交車輛維修體系的組織結構、業務結構以及業務流程等進行 詳盡的分析，明確車輛報修信息管理系統開發的具體需求。車輛報修信息管理系統的業 務流程如果可以與一汽巴士公司的實際車輛報修體系業務流程相符合，就可以大大方便 員工掌握和使用系統，有利于系統的快速推廣，也有利于提高維修工作的效率。
2.1項目背景
2.1.1廣州市一汽巴士有限公司概況
廣州市一汽巴士有限公司（下文統一稱一汽巴士公司），其發展歷程可追溯到上個 世紀中旬。 1952 年，廣州市政府成立了解放后的第一家國有公交企業--廣州市第一公共 汽車公司。 2004 年，經市政府批準進行改制，通過增資形式注入民營資本（國有和民營 方各 50%資本），組建成為廣州市一汽巴士有限公司。
公司經營公交線路189條，線路總長度達2500多公里，營運車輛超過2300輛，線 網覆蓋范圍廣，年載客運量達 4.64 億人次，約占廣州公交客運量 19％，實現“東至黃 埔、南至番禺、西至芳村、北至白云”，是我市目前歷史規模最大、最悠久的公交企業 之一。
2.1.2一汽巴士公司信息化建設概況
目前廣州市公交客運市場存在一汽巴士、二巴、三汽等國有公交企業以及新穗、珍 寶等民營公交企業，競爭日趨激烈。為此，一汽巴士公司需要建立更加規范化的信息管 理系統，以提高企業的決策分析能力，從而提高企業的競爭力。其中獎勵車輛報修管理 系統，有利于對管理漏洞查漏補缺，有利于維持公交車輛的良好工作狀態，有利于提高 車輛利用率。公司自 2013年開始，逐步建成并完善信息化管理配套，開發了智庫系統、 生產統計平臺、派替管理系統、報表中心以及車輛報修系統等，不斷提高公司的信息化 水平，走在了廣州市公交行業的前列。
2.1.3一汽巴士公司公交車輛報修體系的組織架構
一汽巴士公司的組織架構設置，釆用的是“總公司--維修廠--臨修站點”的三級架 構模式。其中維修廠的組織架構劃分如表 2-1所示。
表 2-1 一汽巴士公司的維修廠組織結構
維修廠名稱 所在區域 歸屬管理單位
龍溪廠 荔灣芳村 營運一分公司
黃村廠 天河 營運二分公司
車陂廠 天河 營運二分公司
前進路廠（一廠） 海珠 營運三分公司
走馬崗廠（二廠） 荔灣 營運四分公司
維修廠主要特征是建立了二、 三級保養維護車間設施，使得企業可以對公交車進行 二級和三級保養維護；同時，由于一汽巴士公司的公交車輛數量多，為減輕5 個維修廠 的壓力，企業設置了小型的臨修站點，承擔維修廠轉移過來的日常車輛一級保養，同時 承擔車輛的零修工作。一汽巴士公司的維修組織結構如圖 2-1 所示。圖中各個部門的職 責分工如下：
1.總公司：下設技術與信息化部，主要負責提高企業信息化，提升車輛維修技術和 工藝水平；制定車輛在維修、保養等方面的技術規范，管理相關技術檔案，以及在技術 培訓中參與評估工作等。
2.物資經營部：主要負責維修廠需要物料的招標、采購和發放等工作。
3.營運分公司：負責車輛的營運、安全保衛以及維修工作。下設車管科，參與維修 廠的管理。
4.維修廠：負責具體車輛的二、三級保養以及車輛維修。
5.臨修點：各分公司均有管轄若干臨修點，主要負責車輛小故障的零修和一級保養 工作。
圖 2-1 一汽巴士公司的維修組織結構
2.2項目需求分析
根據一汽巴士公司維修業務的運作特點和管理人員的要求，車輛報修信息管理系統 可以實時監控車輛的維修狀態，對車輛維修的工作流程進行記錄；實現對人員資料、車 輛資料、維修規范、技工工時以及培訓知識庫的管理；同時還具備信息提醒、報表統計 功能。系統的具體需求，需要進一步分析一汽巴士公司的維修業務結構和業務流程，想 相關業務進行分類匯總。
2.2.1一汽巴士公司車輛報修體系的業務結構
根據功能分類，可以把一汽巴士公司車輛報修體系的業務結構分為五大板塊，一汽 巴士公司的車輛報修的業務結構圖如圖 2-2所示。
圖 2-2 一汽巴士公司維修業務結構圖
1.維修業務流程管理模塊：屬于維修廠的日常業務流程，也是維修廠的核心功能需 求，對車輛維修的作業流程進行管理。根據常見維修內容，該大模塊中還可分為六個子 模塊，分別是：
（1） 車輛報修模塊：對車輛入廠報修進行記錄，一般車輛出現故障時，需由司機 致電維修廠的前臺管理，報告故障情況。由前臺判斷是否符合繼續安全營運，不符合的 則根據故障類型，安排到臨修點進行修理或者維修廠修理。具體流程圖如圖 2-3所示。
（2） 檢驗驗車模塊：車輛入廠后，檢驗員領取故障表記錄司機反饋故障現象，并 對所述故障進行檢驗。如果檢驗結果表明車輛存在故障并需要報修，則將車輛故障錄入 報修管理系統，并進入下一步維修流程。
（3） 車輛救濟模塊：當車輛在營運過程中出現車輛中途拋錨，導致車輛無法自行 到維修點報修時，由維修廠安排救濟工程車到車輛故障現場處理，并在系統形成記錄。
（4） 車輛維修模塊：車輛維修內容及流程在系統中形成的日志記錄。
圖 2-3 入廠報修前業務流程圖
（5）車輛現場抽檢模塊：為維護車輛的良好運行狀態，由維修廠定期派出技術人 員到車輛停場點和線路總站對車輛的狀態進行抽檢，發現故障隱患的，及時安排車輛進 一步檢驗和維修。
（6）車輛保養模塊：即車輛的一級、二級維護，在系統中記錄車輛的保養維護相 關信息。
此外，車輛維修模塊還有常用的子模塊。如視頻修理模塊，主要是記錄車載視頻 （CAN 總線使用）的維修。而轉廠模塊則是指車輛在臨修點進行臨修時，臨修點工作 人員判斷現有的技術和設備無法完全修復車輛時，需要轉到設備設施更完善的維修廠進 行維修的時候使用。
2.維修業務檔案管理模塊：主要涉及對車輛相關業務檔案信息。包括車輛相關技術 信息和車輛故障類型分類，還有車輛在維修前的故障現象、維修內容以及完工狀態等。
3.用戶、權限管理模塊：對系統的登陸用戶和權限進行管理。包括對用戶的賬號密 碼、用戶組信息進行定義修改。對用戶的權限進行調整，使得不同的用戶可以在系統進 行訪問不同的功能模塊，而不會相互造成干擾，確保車輛維修業務有序進行、。
4.綜合統計模塊：主要是統計車輛維修過程中產生的各項數據，并為公交公司進行 決策和提升管理效率提供有效依據。該模塊管理的內容包括：技工工時統計和車輛維修 報表。
5.物資管理模塊：物資管理主要指對各種生產資料的購買、驗收、存儲和發放使用 等。例如，物資出入庫時需要對其進行登記。此外，還需要定期進行物資盤點，確保物 資的品種、型號、數量等與入庫時相符。由于一汽公司物資經營有獨立的部門和信息系 統進行管理，而車輛維修物資只是物資經營部的部分業務內容。因此，根據業務的歸類， 車輛報修信息系統中僅預留材料情況管理模塊接口，方便日后進一步對接物資管理信息 系統。
2.2.2一汽公司車輛報修體系的業務流程
公交車輛報修信息系統的維修業務管理模塊涉及內容眾多，例如報修過程中的入 廠登記模塊、檢驗、車輛保養和報表統計分析等業務和流程。下面將重點對車輛報修、 檢驗驗車和車輛保養等主要業務流程進行介紹。
2.2.2.1車輛報修、檢驗驗車流程
為方便進一步理解一汽巴士公司的車輛報修業務流程，本文將車輛報修、檢驗驗車 等模塊合并在一起介紹，業務流程圖見圖 2-4所示。
1.司機入廠登記：司機把有故障的公交車輛開到修理廠或臨修點，并填寫故障登記 表。然后由值班車輛檢驗員對車輛進行檢驗。
2.檢驗驗車：當天值班的車輛檢驗員，對車輛的故障情況進行檢驗，并判斷和故障 登記表上描述的故障內容差異。如果檢驗結果顯示不存在相關故障，則車輛退還給司機。 如果檢驗顯示故障存在或存在其它未描述的故障和隱患，則需要進一步判斷故障類型。
3 . 檢驗派工：值班檢驗員對車輛存在故障類型進行派工，安排相應的車間班組進行維 修。這時，系統會錄入車輛故障信息并生產維修業務單據，維修業務單據對車輛維修的 整個過程進行記錄。然后將車輛送到上述安排的維修車間進行下一步作業。
4.接單、維修：負責故障車輛的維修。維修車間的技術人員對車輛進一步分析故障 原因，制訂維修方案。同時根據維修方案，判斷是否需領取物料。如需到物資倉領取物 料，需要填寫領料單，并根據物料價值分別需要技工、技工班長、車間主任以及維修廠 生產科長的權限審批，從而實現對維修成本的控制。物資倉管理員根據領料單審核結果 發放材料后，技工開始維修作業。維修完工后，在系統記錄車輛的維修內容。經車間主 任檢閱后，車輛進入下一步的檢驗。
5.出廠前檢驗：值班車輛檢驗員，對維修完工的車輛進行檢驗，并對比維修業務單， 判斷車輛故障是否依然存在。如果故障未解決，則車輛需要返回車間重新維修；如果問 題解決，則在維修業務單確認檢驗通過，確認車輛維修完工。
6.司機取車：營運分公司的派替員可在報修系統查詢車輛完工信息。根據配員計劃， 派替員安排司機取車，并返回線路參加營運。車輛報修流程結束。
圖 2-4 一汽公司車輛報修流程圖
如圖 2-4可見，車輛報修流程需要三大部門參與，分別是前臺管理，檢驗部和修理 車間。三者相互獨立，實行流水線作業。
2.2.2.2車輛保養維護流程
公交車輛保養包括車輛的一級、二級和三級保養維護。一級維護通常在車輛晚上收 車后或者日間客流低峰時進行。二、三級維護一般在車輛晚上收車后進行。本文以一汽 巴士公司目前在運營的LNG天然氣車型為例，對常見的一級維護和二級維護進行說明。
1.保養工作流程：
（1）保養安排：參考已制定好的車輛保養規范安排保養安排計劃，列出相關的重
要信息。
（2）保養派工：根據公司每月制訂的保養計劃安排，在車輛入廠時將車輛派送給 指定維修車間班組。
（3）保養記錄：車間班組完成所有的保養內容以后，必須填寫相對應的信息，如 入廠時間、完工時間等。
（4）保養驗收：保養工作全部完成以后，需要進行檢驗，待驗收通過后整個流程 才算結束。
2 . 保養基本項目及技術規范
（1）一級維護基本項目及技術規范
車輛一級維護（一般簡稱一保）的技術規范是根據目前在用車輛技術配置不同而分 項編制的。車輛一級維護的周期一般是車輛行駛里程達到 5000公里，或月均進行一次。 一級維護作業一般由具備相關保養設施的臨修點或者維修廠執行。其內容除日常維護作 業外，還需要以清潔、潤滑、密封性檢查（特別是供氣系統檢漏）、調整、緊固為作業 中心內容，并檢查有關制動、操縱、LNG專用裝置［36］（燃氣供氣系統包括LNG儲氣瓶 及相關閥類、燃氣過濾器、低壓電磁閥、汽化器、電控調壓器和混合器）等安全部件 ［37］。
（ 2 ）二級維護項目及規范
車輛二級維護，一般簡稱二保，一般車輛行駛 15000 至 25000 公里時需要進行一次 二級維護。在一級維護作業的基礎上，增加調制動蹄片、懸掛等經過一定時間的使用容 易磨損或變形的安全部件以及LNG專用裝置等項目的維護［38］。為保證車輛維護的質量, 由具備相關保養維護設施的維修廠負責執行車輛維護作業。
無論是一級維護，還是二級維護，如果在維護過程中，發現車輛存在故障隱患，需 進一步維修，則參考車輛維修業務流程進行維修。車輛完工后，都必須經檢驗驗車，確 認車輛無故障后，才能允許放行并由分公司派替安排司機取車。在系統開發過程中，嘗 試引入二級保養優化技術模型，有助于提高企業的維修保養資源利用效率 ［39］。
2.2.2.3物資材料領取流程
車輛維修物資，作為維修廠的后勤部門組成部分，承擔著維持維修廠正常運行的重 要功能。既要提高效率，及時發放生產資料，又要做到完善記錄，壓降企業運營成本。 因此在車輛維修過程中，一汽巴士公司采取了以下的物資管理業務流程，見圖2-5所示。
圖 2-5 車輛報修過程中的物資管理流程圖
由圖 2-5 可見，在車輛維修過程中需要更換零件時，需要根據零件類型和價值進行 審核物資的發放。根據維修方案，車間維修班組需要填寫領料單。
（1） 當領取的零件屬于日常消耗品，且價值較少時，可以直接由技工憑領料單到 物資倉領取，物資倉對物資價值進行評估審核并發放物料。如螺絲等日常消耗品。
（2） 當領取的零件價值位于 50-200 元區間時，需要由技工班長憑領料單到物資倉 領取。
（3） 當領取的零件價值位于 200-800 元區間時，需要由車間主任審批通過后，由 技工班長憑領料單到物資倉領取。
（4） 當領取的零件價值高于 800 元時，需要由維修廠生產科科長審批通過后，由 技工班長憑領料單到物資倉領取。
2.3車輛報修信息管理系統的開發目標
通過公交車輛報修信息系統的開發，完善對車輛的實時狀態跟蹤和監控，并對車輛 的維修數據、技工工時和運營情況等數據進行規范管理。從而使得車輛維修業務實現“無 紙辦公”，提高工作效率。車輛報修信息管理系統采用透明化、標準化的操作，有效地 提高了企業管理水平；同時通過自動對各種數據進行統計，為一汽巴士公司的決策分析 提供依據。為此，對企業建立系統的目標進行歸納總結，具體如下：
1.注重規范性。既要規范系統的數據定義和結構，又要避免系統的臃腫不堪。同時 合理設計系統架構，并預留系統使用運行后的升級和維護需要的空間。
2.系統的安全性和穩定性需要得到保障。車輛維修數據涉及企業的營運競爭力，因 此必須保證數據信息的安全性。同時，需要考慮到一汽巴士公司車輛超過 2300 輛，日 維修業務量較大，對系統的訪問頻繁。系統需要對系統的接口和擴展能力進行優化，從 而確保大量用戶訪問時，系統依然可以穩定運行，確保企業車輛日常維修業務的正常運 轉。由于系統是面向一汽巴士公司的維修廠技工、檢驗員、維修廠管理人員、報表設計 和統計人員以及總公司管理人員而使用的。
3.系統的設計應該以簡潔性和直觀性為主。該系統是面向維修廠基層員工（如技工） 的。由于員工水平參差不齊，因此系統的用戶界面應簡潔、直觀和友好，方便員工快速 熟悉使用。并且，系統的相關操作設計應該以簡單方便為主。
4.系統應該具備數據的統計分析功能，包括車輛保養維護數據、車輛維修數據以及 材料消耗數據。同時應該考慮維修業務的復雜和繁瑣性，企業的報表內容及格式也會隨 時間不斷完善改進，系統應該預留接口，運行統計分析人員自行修改或者設計維修業務 報表。
5.由于一汽巴士公司的各維修廠、臨修點分布比較分散，因此，需要考慮系統的安 裝、維護成本。系統的設計應該使得用戶使用更方便，不需要長期派遣技術人員對每個 用戶終端進行安裝、培訓和維護，從而減輕企業的成本壓力。
6.系統應該具有強大的數據處理能力。作為一汽巴士公司信息化系統的重要組成部 分，對維修業務的相關數據進行統計分析，有助于提高企業的決策分析能力，并為后期 其它基于車輛報修信息管理系統開發的信息系統提供數據支撐。
2.4系統的開發形式
目前系統開發中最為常見的一種開發形式是系統生命周期開發形式 [40]，也可以稱 作結構化系統開發方法，廣泛應用于各類信息系統的開發。
使用系統生命周期法，可以將提出問題、分析問題以及解決問題連接起來，使得系 統開發的目的性和專業性更強，有利于加快系統開發效率。如果以時期和階段為分類依
據，我們可以將系統生命周期開發形式劃分為三個時期八個階段 [41]。如圖2-6 所示：
圖 2-6 系統生命周期開發形式的工作流程圖
其中定義期，主要是指提出需要解決的問題、對用戶的需求進行調研以及可行性 研究。開發期主要是系統的開發過程，包括總體架構設計、具體功能設計以及系統測試 等。而維護期，主要是指系統使用過程中的運行維護。
采用系統生命周期開發形式，有著巨大的優勢。首先是系統設計更加貼合企業需求。
其次是結構化設計思想的運用，使得系統開發更具有一體性。還有就是對各個系統開發 階段精細化管理，使得系統開發更易于控制和管理。因此本文采用系統生命周期開發形 式來開發車輛報修信息管理系統。按系統開發的不同階段，可以分為：
1.項目規劃階段
根據企業管理層的要求和企業的信息化思路，成立項目開發小組，為了明確系統開 發目標，需要開展項目可行性研究等前期調研工作。
2.項目確定階段
在前期的調研工作基礎上，制訂開發方案，確定項目主辦部門。并根據項目的開發、 測試、運營和維護等板塊落實主辦部門和協辦部門的分工，要求必須落實到部門里的具 體個人，制定項目進度時間表，并確定公交車輛報修信息管理系統的項目目標。
3.需求分析階段
車輛維修業務涉及到的部門有維修廠、營運分公司、物資管理部門以及公司技術與 信息化部；涉及人員包括技工、檢驗員、統計人員以及管理人員。因此需要項目組深入 基層，對系統需求進行詳細的摸查。調研摸查內容應該包括系統功能、系統權限管理、 業務流程控制以及報表統計等。通過對各個群體的需求進行匯總分析，明確企業實際需 求，初步在技術層面構建系統設計開發方案。
4.系統設計階段
對系統開發設計方案修改完善，取得一汽巴士公司認可后。開始開展系統的總體設 計，明確系統的總體架構，構建后臺數據庫。然后是進行詳細設計，包括輸出界面、用 戶權限管理等功能模塊的設計，并編寫《系統設計方案書》等資料。系統設計過程中， 項目組應該根據指定的項目進度表推進開發進度。
5.系統編碼階段
程序編碼階段是項目開發人員進行編程，對系統的各個功能模塊的代碼進行書寫， 以及對系統算法進行優化。
6.系統測試階段
測試是為了驗證系統是否達到企業預期需求，以及系統的穩定性能。其測試主要包 括 4個階段。首先是進行單元測試，一般由系統代碼開發人員來實施，通過對軟件中的 最小可驗證單元進行測試，以檢驗所開發的代碼是否符合設計要求。其次是集成測試， 對系統的各個模塊或者子系統進行測試，以檢驗是否實現相應的需求。然后是系統整體 進行測試，在實際運行環境中測試，確保系統整體運行良好。最后是交付測試，系統交 由企業維修廠等相關部門對用戶需求和業務流程進行使用測試，以確定系統是否滿足企 業需求，符合驗收標準。
7.系統維護階段
系統投入正常運行后，需要繼續做好系統維護。這是一件長期而艱巨的工作。其主 要內容包括系統的安裝、調試、培訓以及升級維護等內容。其關鍵任務是系統的預防性 性防護、完善性防護以及適應性防護。其中預防性防護主要是做好相關應急預案，對系 統服務器數據備份，以防系統奔潰時可以快速恢復系統。完善性防護主要是根據使用環 境變化、用戶需求調整來對系統進一步完善和修改 ［42］。
8.項目總結階段 系統開發完成后，總結工作成果，編寫相關的報告文件。
2.5項目可行性分析
本文采用軟件工程開發的思想進行車輛報修信息管理系統的設計與開發，系統整體 基于 C/S 軟件架構，主要包括圖形界面端和數據服務端。其中，數據庫系統采用 SQL Server企業版實現，這也是最常用的企業數據庫之一。系統圖形化界面采用delphi開發 實現，數據庫與delphi的連接通過ADO管理工具完成。接下來，下面將對車輛報修信 息管理系統涉及相關技術的技術和經濟可行性進行分析。
2.5.1技術可行性分析
1.C/S 架構
C/S架構，全稱為Client/Server，屬于軟件系統的一種體系結構，由客戶端和服務 端組成 ［43］。其工作原理是先將任務進行分解，服務器只承擔部分的分解任務，其它的 分解任務由客戶端完成，從而大大降低系統的工作壓力，提高系統運行效率［44］。在C/S 架構中，客戶端是指面對用戶的終端圖形化界面，其功能是處理相關數據的運算。服務 器端由數據庫構成，其作用是負責數據的查詢、讀寫和修改等。用戶可以通過終端的圖 形化界面進行操作，并向服務器端發出處理請求。服務器端接收到客戶端的請求后，執 行相應的指令，將指令結果返回給終端 ［45］。收到返回結果后，終端界面將指令結果展 現給用戶。
從企業需求角度來看，一汽巴士公司的營運車輛數多，因而日常維修業務量必然較 大， 對車輛報修系統的使用和訪問頻繁，系統的開發需要保證系統響應速度可以滿足需 求。此外，車輛報修業務主要涉及到企業的維修廠的相關員工利用車輛報修系統完善管 理，其次是報表人員及企業管理層對報修相關信息的統計和管理。因此報修管理系統本
身就是針對特定人員開發的，用戶群體相對固定。為進一步了解C/S架構的優劣，確認 其是否滿足一汽巴士公司開發車輛報修信息系統的需求，對其優點和缺點進行分析［46］， 見表 2-2 所示。
三是的多樣化的圖形化操作界面；
對客戶端的操作系統有限制，適用面窄；四是受限
由表 2-2 可知， C/S 架構有利于提高企業數據的安全性，結構簡單，響應速度快， 正好滿足企業的特定需求。但 C/S 架構也有安裝維護成本高，用戶群體受限制的缺點。
因此，如果可以在客戶端的安裝和維護上進行優化，使得系統更穩定、更便捷，則 C/S 架構是非常切合企業對系統穩定性、安全性和快速響應的需求的。
2.客戶端圖形化界面開發技術
從上述分析可知，采用 C/S 架構后，如果客戶端軟件體積過大、安裝繁瑣或者對系 統硬件要求高，都會大大增加項目開發成本，也不利于系統的推廣和使用。因此，需要 通過采用更合適的客戶端開發技術來解決客戶端的快速安裝、維護等問題，從而提高系 統的經濟性和實用性。為此，我們選擇Delphi語言技術進行客戶端軟件的開發。其具有 以下優點：
（1） Delphi 作為一種集成開發工具，其集成的代碼編輯器具有編譯速度快的巨大 優勢。得益于其代碼編輯器的選擇鏈接和條件編譯技術［47］,使用Delphi開發的客戶端， 具有運行速度快以及執行文件精煉的特性。
（2） Delphi 支持將存取規則分別交給客戶機或服務器處理的兩種方案 ［48］。因此，
其在處理速度和存取服務器方面，Delphi的性能與其它同類產品有著巨大的優勢［49］。
簡而言之，得益于delphi的強大特性，通過Delphi開發的客戶端應用軟件既具有多 平臺支持，可以在 windows XP、windows 7 等系統上運行；又具有體積小、免安裝運 行和即插即用的優點［50］，提高了系統的可移植性和使用便捷性。
車輛報修信息系統的數據庫采用SQL SERVER技術。SQL SERVER作為一個全面 的關系型數據庫平臺，具有使用方便、適用范圍廣和相關軟件集成度高等特點，這里 不再詳述。而Delphi與SQL SERVER數據庫的連接主要通過ADO動態連接方式。
ADO 出現于 1996 年，是 DAO/RDO 的后繼產物，是一個用于存取數據源的 COM 組件，是Microsoft提出的高層應用程序接口（API）用以實現訪問關系或非關系數據 庫中的數據［51］。其涉及的數據存儲有DSN（數據源名稱）、ODBC （開放式數據連接） 以及OLEDB三種方式［52］。數據庫連接架構圖見圖2-6所示。
圖 2-6 數據庫連接架構圖
由圖2-6可見，ODBC，OLEDB這些系統級的編程接口是底層的，其操作起來相對 困難;而ADO相對來說，更方便開發人員使用，可以把ADO看作是對ODBC和OLEDB 的封裝，并且具有更強的可移植性［53］。由于報修系統要求對數據刷新更快，因此本系 統采用ADO技術連接MySQL驅動。
綜上所述，基于C/S架構、delphi語言開發的客戶端以及ADO動態連接等技術開 發的車輛報修信息系統在技術上是可行的，可以滿足一汽巴士公司的需求。
2.5.2經濟可行性分析
采用 C/S 架構后，通過使用 delphi 開發客戶端，具有很強的可移植性和便捷性，對 客戶端主機要求不高，從而可以有效降低系統安裝成本，符合一汽巴士公司的成本要 求。同時，得益于ADO動態連接技術、delphi的編譯速度以及C/S架構的優秀工作原
理，整體開發出來的系統，將在響應速度、開發周期上具有巨大的優勢。
對一汽巴士公司來說，無須對客戶端主機進行額外的升級，直接利用現有的主機 即可使用系統。同時由于 C/S 架構結構簡單，開發周期短，也有利于企業降低開發成 本。因此該技術方案也同時具有經濟可行性。
2.6本章小結
本章節是對一汽巴士公司的實際報修體系運作進行深入的剖析，包括從組織結構角 度、業務結構角度和業務流程角度來分析， 明確公交車輛維修信息系統的系統開發目標 和系統開發形式。其次是對項目的技術可行性和經濟可行性進行分析，明確了開發方案 是：系統基于C/S架構開發，并利用delphi技術開發客戶端和采用SQL SERVER數據 庫技術來開發車輛報修信息管理系統。
第三章 公交車輛報修信息系統設計
作為系統開發階段的一個關鍵環節，系統設計是否合理，影響著系統的功能實現。 系統設計需要先對系統進行總體設計，確定系統的體系架構，然后才能對系統的具體功 能模塊進行詳細設計。此外，還需要根據系統的運行環境，對系統的各個層次結構進行 設計。
3.1系統體系結構
3.2.1系統運行環境
根據項目需求和可行性分析，為了控制系統開發成本，需要確定合適的系統運行環 境，從而有利于提高項目開發效率和縮短項目開發周期。該公交車輛報修信息系統的運 行環境具體如下:
操作系統： Windows Server/Windows XP
數據庫：SQL Server企業版
數據庫連接技術：動態鏈接 ADO
客戶端： Windows XP/Windows 7
開發軟件： Delphi
使用語言：SQL語言
3.2.2系統物理網絡結構
車輛報修信息系統采用的是基于C/S架構的物理網絡結構，其結構圖見圖3-1所示。 其中系統各部分功能說明如下：
1.服務器
將系統和數據庫安裝在公司的服務器上，用戶在客戶端可以通過網絡訪問系統，通 過用戶驗證后就可以獲得服務。
2.內網車間
在各維修廠車間安放電腦，然后連接上企業的內部局域網，使用人員可以通過電腦
3.內網辦公室
維修廠管理人員在辦公室里登陸系統，就可以在系統上查看相關維修業務報表數據， 查看保養安排，跟蹤某輛故障車輛的維修過程等。公司高層也可以在這里實時了解整個 維修廠的工作情況，對近期的車輛維修業務量、材料損耗量以及技工工時等數據了如指 掌。
4.外網
考慮到企業人員分散等實際情況，允許通過外網連接服務器。企業管理人員可通過 外網訪問系統進行管理工作，哪怕遠在千里之外，依然運籌帷幄之中。
3.2.3系統設計結構
系統體系結構采用模塊化的軟件設計思想，根據項目需求，主要分為“車輛報修”、 “報修資料”、“車輛檔案管理”、“報表管理”以及“通知提醒”等幾個大模塊，實現車 輛報修、車輛維修及完工、統計報表以及系統管理等功能。
如上文所述，本文的車輛報修信息管理系統是基于C/S架構開發的，其可分為服務 器、因特網（局域網）和客戶機三個層次結構，分別對應的邏輯結構為數據層、邏輯層 和顯示層。其中，客戶機作為顯示層，是用戶進入系統進行業務操作的界面，可執行對 車輛維修信息的查詢以及相關維修內容的數據錄入等。數據層的功能是管理數據的，包 括數據信息的更新、維護、存儲等日常管理任務，同時響應邏輯層發送的 SQL 指令。
而邏輯層處于上承顯示層，下接數據層的重要位置，其功能是根據顯示層的處理請求， 對數據層執行相關指令操作，并將數據層返回給顯示層。如圖 3-2 所示。
圖 3-2 系統設計結構圖
3.2信息系統結構設計
3.2.1車輛報修信息管理系統的顯示層設計
顯示層是面向用戶的終端界面，是用戶在系統進行查詢信息、錄入數據等相關操作 的入口。
1. 設計遵循原則
（ 1 ）模塊化設計 根據業務流程結構可將其功能劃分為若干功能模塊。彼此的數據是既相互獨立又相 互關聯的，所以其數據具有規范統一性，提高用戶使用的便捷性。
（2）友好和直觀化的界面設計
應能提高用戶在系統執行信息查詢等操作時的簡便性，系統應根據自身基礎數據， 對數據實現關聯，如：某用戶在系統輸入自編號為 4268 的車輛時，系統后臺對該自編 號的車輛數據進行關聯，相關表格信息實現自動填入。此外，系統的操作應該簡單明了， 以適應企業員工的特性。例如，標題欄安置在界面的頂部放置在顯示層頂部，顯然更符 合人體工程學和日常用戶的閱讀順序習慣。而顯示層界面上方則放置重要的功能模塊會 使得證界面看起來根據簡潔有序。
2.顯示層設計 在公交車輛報修信息系統中，涉及的界面主要為兩種。一種是登陸界面，如圖 3-3 和圖 3-4 所示；另一種是功能主界面，如圖 3-5 所示。
下面為幾個顯示層界面設計情況的展示：
圖 3-3 車輛報修系統登陸界面（網絡鏈接）
圖 3-4 車輛報修系統登陸界面（用戶登陸）
%車輛報修至統 Version 2^0,72 Build 139 In 180T26 硏畫窗
圖 3-5 車輛報修系統功能主界面
值得注意的是，圖 3-5的報修系統功能主界面，由于是車輛報修登記錄入界面，為 了方便一線管理員操作，所以對界面字體作了強制大號字體顯示，以方便基層員工使用， 降低輸入信息的出錯率。
3.2.2車輛報修信息管理系統的邏輯層設計
如上述所說的，邏輯層起著承上啟下的作用，其主要功能是處理代碼，并在顯示層 和數據層之間進行數據交換。此外，邏輯層除了處理數據的功能，還可以通過對數據進 行驗證來提高系統的安全性oC/S架構系統對響應速度的要求高，需要合理設計邏輯層， 以滿足系統的運行要求。為此，可以在系統開發過程中，使用公用函數模塊來對相關的 數據處理規則進行定義，從而提高數據處理能力。例如，對數據層的函數進行定義和設 計后，系統就可以通過調用邏輯層的函數來實現數據層和顯示層的通信。同理，對數據 層的函數進行定義和設計后，系統的邏輯層通過調用數據層的函數來構建與通信層的通 信。可見，系統架構之間的通信，離不開逐層的函數調用。
1.查詢功能的實現
要實現數據信息的查詢，需要系統調用邏輯層的代碼。一般在程序設計過程中，會 對窗體中的TQuery構件的SQL屬性內容值進行設置。一般設置將其為一個字符串數組, 并且數組的每個值和SQL查詢語句是逐一對應的。當然，如果想要動態地對程序中的查 詢語句進行修改，可以通過在程序運行時重新賦值的方法來實現。假設需要改變某程序 窗體中的TQuery構件的SQL查詢語句內容，則可以引用以下程序行：
｛為避免控件沖突先關閉之前查詢｝
AdoQuery1.close;
｛清除以前的查詢語句｝
AdoQuery1.SQL.Clear;
｛增加新的查詢語句內容為 select * from mytable｝
AdoQuery1.SQL.Add('select * from mytable');
AdoQuery1.exesql
AdoQuery1.open;
｛建立新的查詢語句的數據庫連接｝
2.查詢功能實例測試
查詢功能的實現，是通過邏輯層來調用數據層的函數來實現的，這里提供一個查詢 實例，主要代碼如下：
//查詢記錄
procedure Tfbrm2.ButtonlClick(Sender: TObject);
begin
ADOQuery. Close;
ADOQuery.SQL.Clear;
ADOQuery. SQL. Add('select * from Your TABLE where 查詢條件 J;
ADOQuery. Open;
end;
上述代碼是當用戶點擊窗體2的按鍵1的時候，執行上述指令，并在顯示層顯示查 詢結果。
此外，在系統運行過程中，我們也需要插入和修改數據。這也可通過相關語句進行， 以下為一個插入修改的實例：
"插入記錄
procedure Tfdrm2 ?E utton2C lick（S ender: T Object）;
begin
ADOQueiy.Close;
ADOQueiy.SQL.Clear;
ADOQueiy.SQL.Text^^nseilinto YourTABLE（字段 1,字段 2） values（:字段 1?：字段 2）： // ADOQueiy.SQL. Add（rinsert into YourTABLE values（:字段 1）'）;
ADOQueiy.Parameters.PaiamByNameC字段 T）?Value:=tiini（Editl .Text）; ADOQueiy.Parameters.PaiamBvName（'字段 2f）.Value:=trim（Edit2.Text）; ADOQueiy.ExecSQL;
end;
3.2.3車輛報修信息管理系統的數據層設計
數據層的主要功能是：當數據層接收到邏輯層的處理指令時，則做出響應，對數據 庫的數據進行查改增刪等相關操作，并將操作結果返回給邏輯層。數據層是系統的核心 部分，合理地構建數據庫，有利于系統的高效運行。
1.數據庫的建立
本文使用SQL SERVER來構建系統數據庫。其有以下顯著優點：一是具有強大的 數據處理能力，還可以對數據進行備份、同步和還原；二是系統具有較高的安全性，通 過對用戶數據及對象進行分類管理，提高數據的安全性；三是通過提供的 9 種數據挖掘 算法，用戶可以對數據庫的數據進行深入分析。
2.數據庫表設計
在車輛報修管理工作中，涉及的數據量和數據類型眾多。例如車輛的車型和所屬單 位，還有從車輛入廠檢驗，到檢驗派工，再到維修，最后到完工，都會產生數據。而且 相關的數據具有零碎的特點。為了提高數據處理效率，需對數據存儲進行規范，從而提 高系統數據的統一性和可用性。為進一步說明車輛報修信息系統的數據存儲形式，本文 選取了 3個具有代表性的數據表。如表3-1 （用戶權限表）、表3-2 （用戶角色表）以及 表 3-3 （故障表）所示：
表 3-1 用戶權限表
名稱 代碼 數據類型 強制 空值 默認值
ID ID Integer TRUE TRUE Getdate()
權限編號 ACCESS_ID Integer TRUE FALSE Getdate()
用戶 ID USER ID Integer TRUE FALSE Getdate()
表 3-2 用戶角色表
名稱 代碼 數據類型 強制 空值 默認值
ID ID Integer TRUE TRUE Getdate()
用戶 ID USER_ID Integer TRUE FALSE Getdate()
角色 ID JSID Integer TRUE FALSE Getdate()
表 3-3 故障表
名稱 代碼 數據類型 強制 空值 默認值
ID ID Integer TRUE TRUE Getdate()
單據編號 DJ_ID Integer FALSE FALSE Getdate()
車輛編號 CL_ID Varchar(20) TRUE FALSE Getdate()
維修項目 WXXM Varchar(20) FALSE FALSE Getdate()
維修日期 WXDATE Character(20) TRUE FALSE Getdate()
操作人員 CZRY Varchar(20) FALSE FALSE Getdate()
維修站點 WXZD Varchar(20) TRUE FALSE Getdate()
維修狀態 WXZT Tinyint FALSE FALSE Getdate()
3. 數據層訪問的設計策略
在數據層訪問的設計策略主要是分層構建數據層， 一個是負責數據的存儲，另一個 是負責數據的查改增刪。通過數據的分層設計，有利于后期維護數據的準確性，有利于 數據訪問的高效性。
（1）數據存儲的設計策略
SQL語言執行過程中，可以通過回滾、鎖表等操作，確保數據庫的完整性和安全性。 在系統開發中可以在數據層編寫特定的SQL語句集。這樣，通過執行SQL語句，可以 實現數據層的數據存儲。此外，SQL語言可以提高語句執行的效率，有利于數據的正常 有序存儲。
（2）數據查詢、修改過程中的程序編寫
在數據層對數據進行增刪、修改和查詢操作，主要是通過ADO動態連接來實現的。 系統通過ADO動態連接讀取數據后，將其放入到DataReader對象以及Dataset對象中 來進行使用。正是由于 ADO 數據訪問接口的強大和實用，而且可移植性很強，所以本 系統在數據層的數據相關操作過程中使用 ADO 動態連接。其次，通過 ADO 動態連接 引入 Dataset 類，有利于后期數據訪問接口的拓展，也有利于維持數據之間的聯系。最 后就是 ADO 動態連接可以實現數據源和不同的數據庫進行數據交互，使得可以適用于 多種應用層。
ADO 動態連接與數據庫的連接有以下方式：一種是直接與數據庫相連，另一種是 與 OLEDB 相連。本文車輛報修信息系統采用了上述兩種方式。用戶在顯示層的客戶端 進行操作時，會向服務器發出處理請求。服務器接收到處理請求后，執行相應的操作， 返回操作結果給客戶端顯示。然后，服務器斷開與客戶端的連接。當下一個請求發生時， 服務器會重新與客戶端進行連接。在此過程中，Dataset組件在其中承擔著非常重要的作 用，可以把它當成是一個內存中的數據庫，也可以作為用來存儲重要數據信息的數據容 器。簡而言之，Dataset組件是一個不依賴于數據庫的獨立數據集合，通用可使用于數據 的讀取和更新。存儲在 Dataset 組件的各種系統數據表信息，無論關閉數據庫，還是斷 開數據鏈接，Dataset仍然是可用的，并與數據源一一對應。
3.3本章小結
本章進入了系統開發中最為重要的設計環節，主要介紹了系統的總體架構設計，確 定了系統的運行環境和物理網絡結構，并且從顯示層、邏輯層以及數據層三個環節對車 輛報修信息管理系統的顯示層設計、數據處理原則以及數據定義規范等內容進行說明。 最后，本章通過實例來展示了顯示層的設計效果和數據表結構。
第四章 車輛報修信息系統模塊設計
在上一章，我們對信息系統的運行環境和系統設計方面進行了深入研究分析，從本 章開始，我們將進行整個系統的搭建。每個功能模塊將會基于項目需求分析和業務框架 進行開發，為每個功能模塊設計詳細的流程和功能框圖。針對車輛報修信息系統，本文 將將挑選 6 個富有代表性的功能模塊進行分析，分別是：“用戶身份驗證模塊”、“用戶 權限管理模塊”、“報修資料模塊”、“基礎數據模塊”、“車輛報修派工模塊”和“報表管 理模塊”而“報表管理模塊”主要陳述如何使用系統進行報表設計和生產。
4.1用戶身份驗證模塊設計
在項目需求分析中，系統的安全性是企業的需求之一。為此，系統登陸需要進行用 戶信息（賬號和密碼）和權限驗證，并且系統不設置匿名登錄。具體流程圖如圖4-1所 示：
圖 4-1 用戶身份驗證流程圖
用戶登陸時，系統后臺收到用戶賬號密碼信息以及登陸請求，并與數據庫中的用戶
信息進行校驗。校驗通過，用戶才可以成功登錄系統。成功登錄系統并進入系統主要面 后，根據用戶權限，顯示該用戶權限所可以操作的功能模塊。
校驗過程是要與數據庫中的用戶信息數據表進行信息比對，實現該模塊功能的部分 代碼如下：
ADOQuery1.close;
ADOQuery1.sql.clear;
ADOQuery1.sql.add('select * from user where id='''+edit1.text+''' and
pass='''+edit2.text+'''');
ADOQuery1.open;
if ADOQuery1.recrodcount=0 then
begin
showmessage('輸入的用戶名或密碼不正確！’)；
end
Else
Begin
form2.show;
self.hide;
end;
end;
用戶登陸功能是車輛報修系統的最基本功能，是用戶接觸系統的第一媒介。因此, 系統登陸界面力求簡潔明了，便于用戶快速上手。
1•用戶賬號名、密碼的修改 系統可以通過用戶管理模塊實現用戶設置、用戶組定義修改等功能。在用戶信息的 子模塊中，用戶可以修改登錄的賬號、密碼和賬號人姓名。修改完后，點擊保存即可。
如圖 4-2 所示：
圖 4-2 用戶管理界面圖
2.用戶管理以及用戶組定義的修改
Version 2E 10. T2 Build 139 In 180726 [_『□]『）
黃村
J 轉廠 報修資料 計工時 視頻修理 救濟 提醒 查車 評怙指標 拯救車 違規"差"評責枉 培訓 重復報修 材料情況 缺料報告
用戶信息I用戶管理〔偵工管疥嚎路管理〔報表管理I車輛檔案」故障分類 中停車、單班車管込■
部門|二分公司 二］修理點醫冠 3姓名I 登錄姓名I ⑥刷新| 權限管理| ◎新増用戶| ◎編輯
登錄名舔 名fit 部門 修理點 位置 工種 用戶類翌 倉庫 可用標總八 編輯資料——
1 liyn 李燕娜 二分公司 客裝廠 董村 管理員 管理用戶 總倉 可用
2 llusp 劉世平 二分公司 客裝廠 董村 管理員 営理用戶 總倉 可用
3 danjy 鄧結英 二分公司 客裝廠 董村 管理員 普通用戶 可用 姓名 廠
4 feriqw 匚 馮偉成 二分公司 客裝廠 董村 資料員 普通用戶 總倉 可用
5 qincr 秦燦菜 二分公司 客裝廠 車陵 管理員 営理用戶 總倉 可用 登錄密瑪 環改動則留空］
6 fengruoohao 馮若朝 二分公司 客裝廠 董村 資料員 普通用戶 可用
7 fenq 馮若朝 二分公司 客裝廠 螢村 資料員 普通用戶 可用
8 Kenny 李傳健 二分公司 客裝廠 螢村 管理員 管理用戶 總倉 可用 -J
9 zhousk 周韶痍 二分公司 客裝廠 資料員 普通用戶 可用 登錄修理點 |客裝廠~
10 daids 戴籍生 二分公司 客裝廠 資料員 普通用戶 總倉 可用
11 huangzw 堇志偉 二分公司 客裝廠 資料員 普通用戶 可用 位置
12 dengjs 鄧勁生 二分公司 車陂 車陂 資料員 普通用戶 可用
13 曹偉東 caowd 二分公同 客裝廠 客裝廠 統計員 晉通用尸 可用 ZJ
14 caowd 曹偉東 二分公司 客裝廠 客裝廠 蜒計員 晉通用尸 可用 用戶類型 1普通用戶
-
15 jiangym 江穀敏 二分公司 客裝廠 客裝廠 統計員 晉通用尸 可用
16 ruanjy 阮連英 二分公司 客裝廠 客裝廠 統計員 晉通用尸 可用 倉庫
17 suh 蘇輝 二分公司 客裝廠 客裝廠 統計員 晉通用尸 可用 可用否
18 liaozl 犀紫凌 二分公司 客裝廠 龍溪廠 統計員 晉通用尸 可用 ZJ
19 zhong 講農權 二分公司 客裝廠 黃村 資料員 晉通用尸 可用 手機號碼 廠
20 zhangdan 張丹 二分公司 車陂 車陂 嚴檢鉅 普通用戶 總倉 可用
21 luomy 駱茂昱 二分公司 客裝廠 黃村 管理員 管理用戶 可用
22 hejf 何潔芳 二分公司 車陂 車陵 站檜 普通用戶 黃村天平架臨修點 可用 7 日保存 ②取消1
針對用戶組定義的界面則見圖4-3以及圖4-4 所示。點擊右上角的新增用戶和編輯
功能鍵，系統管理員可以增加系統的用戶，也可以對用戶信息進行編輯修改。
圖 4-4 用戶組信息修改界面
4.2用戶權限管理模塊設計
系統需要對登錄用戶，進行權限控制。為實現權限管理，我們在數據庫針對用戶資 料以及用戶權限分別設置了數據表。其中，用戶資料數據表定義為BaseData，其不添加 區分用戶的字段；而UserRightData (見圖4-5所示)是用戶權限表，結構和BaseData 一樣，只是多了用戶字段。增加用戶時，就是從BaseData (見圖4-6所示)表中復制數 據到UserRightData中，并標識用戶ID。然后程序方面則通過定義一系列函數實現這部 分功能［54］：
//根據用戶id創建對應的權限列表
functi on CreateRightLi stByUserID(ui d: Integer): B ool ean;
//根據用戶id取得對應的權限列表
fUncti on GetRi ghtLi stB yU s erID (ui d: Integer):Boolean;
//根據用戶id刪除對應的權限列表
function Del eteRightLi stByUserID(ui d: Integer): B ool ean;
//根據記錄id設置某個功能是否可用,funid:記錄id，uid:用戶ID，issel:是否可以 用
procedure SetFunEnable(funid,uid,issel:Integer);
//判斷某個功能是否可用
function IsRightEnable(uid:Integer;fuccode:string):Boolean;
簡而言之，就是在數據庫中定義一個權限列表，表內有與窗體按鈕空間tag對應的字 段。通過在數據庫中查詢相匹配的記錄，來識別用戶對該模塊的訪問權限。字段說明如 下：
FucCode:該字段與控件tag對應
FucName:功能名稱
IsSel :是否有權限的標志
IsFuc:標識該項是否是可以執行的功能
FucPID:父節點ID，用來生成樹形結構時用
圖 4-5 用戶權限表
系統用戶管理員對使用系統的用戶權限進行分配，從而提高系統數據的安全性和提
高運行速度。系統的用戶權限管理界面如圖 4-7所示：
圖 4-7 用戶權限界面
在系統用戶管理的界面里，點擊權限管理，可以彈出上述用戶權限管理界面，查看 該用戶權限。用戶“lyn”（李燕娜）作為分公司一般管理員。由圖可見其權限分配，打 鉤表示用戶擁有該權限，如圖中的派工、完工記錄、檢驗、轉廠等模塊。打叉的選項表 示該用戶不允許使用該模塊，如圖中的救濟、計工時、技工評估、拯救查詢和違規等模 塊。系統管理員可以對用戶的相關權限進行修改并保存。
4.3報修資料模塊設計
報修資料是整個報修系統的核心所在，無論是預約、派工還是完工記錄，都是對該 模塊內容的補充修改。每輛車每次維修，系統都自動生成對應的維修單號，并記錄相關 信息。需要根據企業實際情況，合理設置報修資料模塊。數據表結構表 4-1所示：
表 4-1 報修資料數據表
名稱 代碼 數據類型 強制 主要的 默認值
ID ID Integer TRUE TRUE Getdate()
單據編號 DJ_ID Integer FALSE FALSE Getdate()
分公司 FGS Varchar(20) TRUE FALSE Getdate()
線路 XL Varchar(4) TRUE FALSE Getdate()
車輛編號 CL_ID Varchar(20) TRUE FALSE Getdate()
車型 CX_ID Varchar(20) FALSE FALSE Getdate()
維修分類 WXFL Varchar(20) TRUE FALSE Getdate()
報修內容 BXNR Varchar(20) TRUE FALSE Getdate()
報修人 BXR Varchar(20) TRUE FALSE Getdate()
報修時間 BXDATE Varchar(20) TRUE FALSE Getdate()
送車人 SCR Varchar(20) TRUE FALSE Getdate()
簽收人 QSR Varchar(20) TRUE FALSE Getdate()
簽收時間 QSSJ Varchar(20) TRUE FALSE Getdate()
派工人 PGR Varchar(20) TRUE FALSE Getdate()
最后派工時間 ZHPGSJ Varchar(20) TRUE FALSE Getdate()
檢驗人員 JYRY Varchar(20) TRUE FALSE Getdate()
維修站點 WXZD Varchar(20) TRUE FALSE Getdate()
取車人 QCR Varchar(20) FALSE FALSE Getdate()
完工時間 WGSJ DATETIME FALSE FALSE Getdate()
車輛完工后，由分公司派替安排車輛司機入廠取車，取車需要刷職工IC卡并通過驗 證才能駕駛車輛出廠。但由于車輛故障往往具有不可預測性，所以車輛入廠維修后，一 般會安排司機休年假或者取其它車輛頂位，因此取車時一般維修廠會采用備用IC卡來協 助司機領取車輛。報修資料模塊如圖 4-8 所示：
« 報修資料計工時觀頻修理救濟提腥查車評估捋標拯救車誼規"差"評責任培訓重復報修材料情說皺料報告 ©8
修理點匪 分公司匡葡 報修日期 何2m8皿03二］~ I卩2m8OM7二］線路性都 二］車號 || 麗U 礬 匡議 三］©查詢|
修理點 分公司 踐越 車號 車型 錐修分類 報修人 報修時間/創建時間 送車人 簽收人 養收時間 滝工人 量"
1 車陂 二分公司 402 4357 安N 收車報修 董慶康 2018-09-03 00:03:00 董慶廉 何燕芬 2018-09-03 00:03:00 何燕芬 201
2 車陂 二分公司 斗0斗 4505 安N 收車報修 車陂備卡1 2018-09-03 00:25:00 車陂備卡1 何燕芬 2018-09-03 00:25:00 何燕芬 201
3 車陂 二分公司 901 4528 安N 臨修 王玉峰 2018-09-03 06:09:53 王玉嵯 何燕芬 2018-09-03 06:09:59 何燕芬 201
4 車陂 二分公司 078 2542 安凱 轉廠臨修 車陂備卡1 2018-09-03 06:54:00 車陂備卡1 何燕芬 2018-09-03 06:54:00 何燕芬 201
5 車陂 二分公司 402 4357 安N 轉廠臨修 車陂備卡1 2018-09-03 06:54:36 車陂備卡1 何燕芬 2018-09-03 06:54:37 何燕芬 201
6 車陂 番禺分公司 051 4311 福L 臨修 李慶祥 2018-09-03 06:55:00 李蔗祥 何燕芬 2018-09-03 06:55:00 何燕芬 201
7 車陂 二分公司 903 3234 混動 轉廠臨修 張偉雄 2018-09-03 07:05:00 張偉雄 何燕芬 2018-09-03 07:05:00 何燕芬 201
8 車陂 番禺分公司 769 3314 福田 事故車 李穗鵬 2018-09-03 07:42:26 李穗鵬 2018-09-03 07:42:31 201
9 車陂 二分公司 773 4519 安N 臨修 曾慶逢 2018-09-03 08:43:00 曾慶遂 粱泳斌 2018-09-03 08:43:00 201
10 車陂 二分公司 775 3292 混動 救濟回廠 樊達植 2018-09-03 09:15:54 樊達植 粱泳斌 2018-09-03 09:15:55 201
11 車陂 二分公司 B19 2531 安凱 臨修 曾曉鴻 2018-09-03 09:32:22 曾曉鴻 粱泳斌 2018-09-03 09:32:32 梁泳就 201
12 車陂 二分公司 039 3048 混動 臨修 許耀榮 2018-09-03 09:37:22 許耀榮 粱泳斌 2018-09-03 09:37:27 201
13 車陂 番禺分公司 051 4248 轉廠臨修 鄧鎬國 2018-09-03 09:40:36 鄧鎬國 粱泳斌 2018-09-03 09:40:37 201
圖 4-8 報修資料界面
1. 工單查詢 在車輛報修資料模塊，通過點擊右下方的工單按鈕，可以對車輛的維修內容，維修 班組、維修項目等內容進行查詢。如圖 4-9 所示。
圖 4-9 車輛維修工單界面
2.車輛報修流水賬查詢
在報修資料中，系統可以查詢該查詢時間段內的維修記錄，以及維修狀態。如圖4-10
所示。點擊流水賬，可以查看車號2542的在 9月3日-9月7日的維修記錄。方便企業
管理人員了解該車輛的技術狀況。此外，該模塊功能提供了數據導出功能，可以查詢并
以excel的形式導出特定時間內的維修資料數據。
圖 4-10 車輛維修流水賬界面
4.4基礎數據模塊設計
如果說報修資料是整個報修系統的核心所在，那么基礎數據就是公交車輛報修系統 的根基所在。完善、規范化的基礎資料管理，才能使得系統正常運作起來。因此，在系 統設計時，必須重視各類型基礎數據定義的標準化和規范化。下面以車輛檔案子模塊作 為例子進行介紹。車輛檔案包括車輛的大牌號、自編號（企業為方便管理對車輛統一編 碼，一般為四位數字）、所屬線路、所屬分公司、燃料類型、登記投產日期以及車架號 等信息。這些信息既關系到車輛維修過程中的材料消耗跟蹤，也關系到車輛的一級維護 和二級維護的作業計劃編排。具體的數據表結構如表4-2所示：
表 4-2 車輛檔案數據表結構
名稱 代碼 數據類型 強制 主要的 默認值
ID ID Integer TRUE TRUE Getdate()
大牌號 DPH Varchar(20) FALSE FALSE Getdate()
分公司 FGS Varchar(20) TRUE FALSE Getdate()
線路 XL Varchar(4) TRUE FALSE Getdate()
車號 CH_ID Varchar(20) TRUE FALSE Getdate()
用途 YTTYPE Varchar(20) TRUE FALSE Getdate()
車型 CX_ID Varchar(20) FALSE FALSE Getdate()
燃料類型 RLLX Varchar(20) TRUE FALSE Getdate()
投產日期 TCDATE Varchar(20) TRUE FALSE Getdate()
結束日期 ENDDATE Varchar(20) FALSE FALSE Getdate()
狀態 STATETYPE Varchar(20) TRUE FALSE Getdate()
報修時間 BXDATE Varchar(20) TRUE FALSE Getdate()
具體車型 JTCARTYPE Varchar(20) TRUE FALSE Getdate()
統計車型1 TJTYPE Varchar(20) TRUE FALSE Getdate()
統計車型2 QSSJ Varchar(20) TRUE FALSE Getdate()
引擎號 ENGINE_ID Varchar(20) TRUE FALSE Getdate()
車架號 FRAME_ID Varchar(20) TRUE FALSE Getdate()
有效 VALID Varchar(10) TRUE FALSE Getdate()
修改人 MODIFY_ID Varchar(20) TRUE FALSE Getdate()
修改時間 MODIFYDATE DATETIME TRUE FALSE Getdate()
由于車輛零件眾多，規范化報修內容，可以為后續的技工工時計算、派工以及報表 設計打下堅實基礎。同時增加基礎資料修改功能。使得系統管理員可以在系統上對未添 加的內容進行增刪修改。
1.車輛檔案資料及報表查詢
車輛檔案資料子模塊的管理界面如圖 4-11 所示，系統管理員在系統直觀地對數據 進行編輯修改，對報表進行生產和導出。
半I小 /修資料丿廠計工時丿廣視頻修理 救濟 提型空至2衛估指標 捉救車薔瓦X"差"評旋/培訓丿廠亙報修丿弔麗況 缺料廻影傳宣
I帝信息 用尸管理 員工管理 線路管理 報表管理 車輛檔案 歆障分類 中停車、單班車管理
有效I激活的 二）分公司 ~3 線路|全部_d車號 '⑥刷新| ◎編輯|
修理廠 用送 車型 燃料類型 投產日期 結束日期 狀態 具體車型 統計車型1 統計車型2 引李"
1 □72 客車裝修廠 營運車 安8 LPG 2005-03-0S 在用 安凱 HFF6113GK50 HFF11L1K1 安11L1K1 YC61
2 775 客車裝修廠 彗運車 安凱 LPG 2010-06-02 在用 安凱牌 HFF6110G50L(LPG) HFF11L1K2 ^11L1K2 G：3G^
3 B15 客車裝修廠 営運車 安B LPG 2005-03-25 在用 LPG-安凱 HFF6113GK50 HFF11L1K1 ^ULIKI YC61
4 B19 客車裝修廠 営運車 安凱 LPG 2010-06-02 在用 安凱牌 HFF6110G50L(LPG) HFF11L1K2 安11L1K2 G3G^
5 775 客車裝修廠 營運車 安凱 LPG 2010-0&-02 在用 安凱牌 HFF6110G50L(LPG) HFF11L1K2 ^11L1K2 G3GC
6 401 客車裝修廠 営運車 冷恒 柴油 2009-01-14 在用 GZK6590DB3 CKZ5D1K3 恒5D2K3 fsooi
7 773 客車裝修廠 営運車 冷恒 柴油 2009-01-14 在用 GZK6590DB3 CKZ5D1K3 恒5D2K3 Fsaoi
8 773 客車裝修廠 營運車 冷恒 柴油 2009-01-15 在用 GZK6590DB3 CKZ5D1K3 恒5D2K3 FSOOi
9 773 客車裝修廠 営運車 冷恒 柴油 2009-01-15 在用 GZK6590DB3 CKZ5D1K3 II5D2K3 Fsaoi
10 773 客車裝修廠 営運車 冷恒 LPG 2009-01-15 在用 tI51CKZ&590DB3 CKZ5D1K3 CKZ5D1K3 Fsaoi
11 785 客車裝修廠 彗運車 冷恒 柴油 2009-01-15 在用 GZK6590DB3 CKZ5D1K3 H5D2K3 F500I
12 401 客車裝修廠 営運車 冷恒 柴油 2009-01-14 在用 GZK6590DB3 CKZ5D1K3 H5D2K3 F500'
13 784 客車裝修廠 營運車 冷恒 柴油 2009-01-15 在用 GZK6590DB3 CKZ5D1K3 恒5D2K3 Fsaoi
圖 4-11 車輛檔案資料界面
2.車輛資料修改日志記錄
系統設計了車輛檔案變動的日志記錄功能，如圖 4-12 所示，提供了操作日志記錄。 點擊左下方的變動記錄按鈕，可以彈出車輛變動日志界面，可以防止車輛數據被隨意篡 改。
圖 4-12 車輛檔案變動記錄日志界面
3.車輛維修及領料明細查詢
系統提供了車輛的故障隱患歷史查詢。通過車輛資料界面的車輛維修及車輛領料明
細模塊。如圖 4-13及圖 4-14所示。
圖 4-13 車輛維修及車輛領料明細界面
圖 4-14 車輛維修及車輛領料明細界面
系統通過開發車輛檔案資料模塊，有助于企業實時跟蹤每一輛車的工況，可根據車 輛的運行狀態，決定車輛是繼續參加營運還是將車輛報廢更新，有效地防范了安全風險。
4.5維修知識庫模塊設計
維修知識庫的作用是提供維修廠技工、檢驗員等提升技術水平使用的。同時，也有 利于維修過程的標準化和規范化。知識庫囊括了車輛日常修理過程中的常見故障，并提 供了相關的維修措施。
1.知識庫算法介紹 由于汽車零部件眾多，可以達到數萬。而對車輛的維修知識庫，相關的資料就更加 龐大。為提高用戶對相關汽車維修知識資料的搜尋效率，根據汽車零部件的分類，系統 采用基于Delphi技術，使用樹形結構展現維修知識庫的方案。部分代碼如下：
function GetNode(pid: String): TIreeNode:
var
i:: Inte呂亡匚
sl:s2: String;
begin
Result :=nil;
index:=0;
for i:=0 toFonnl.IreeViewl.Items.Count-1 do
begin
sk= i d. String s[i]:,
if si = pid then
begin
s.2::= Result .Text:
index:=i;
Break:
end;
end:
end:
其節點分類依據是汽車零部件的分類，總體可以分為底盤類、發動機類、電器類、
車身類、輪胎類，各級保養類以及空調類等。并以此作為父節點，再通過點擊父節點時， 系統自動搜索數據庫，并將搜索結果（即下一子節點內容）展現給用戶。以此類推，通 過層數遞歸查詢數據庫，可以不斷將下一節點的內容展示給用戶。
2.知識庫模塊界面設計
最終設計的界面顯示結果如圖 4-15以及圖 4-16所示。
故障類別 I發動機~
丁確定| 0取消|
圖 4-16 故障分類資料界面
同時，管理員可以定期對維修知識庫的內容進行維護，提高了系統的實用性。此外， 各項維修業務工作的標準化，有利于提高維修效率，也方便企業對技工的工時和績效進 行統計。
4.6車輛報修派工模塊設計
由上文可知，整個報修流程中，派工起到承上啟下的作用。車輛檢驗員判斷車輛故 障類型后，通過派工模塊將車輛分配到對應的車間進行作業，從而實現流水作業。派工 的功能圖如圖 4-17 所示。
圖 4-17 派工功能圖
車輛檢驗員在檢驗車輛后，發現有故障后。需要在報修系統錄入車輛的具體故障信 息，并針對不同的故障類型和內容，將車輛按次序派工給對應的維修車間。其數據表結 構則如表 4-3 所示：
表 4-3 修理過程表
名稱 代碼 數據類型 強制 主要的 默認值
ID ID Integer TRUE TRUE Getdate()
單據編號 DJ_ID Integer FALSE FALSE Getdate()
車輛編號 CL_ID Varchar(20) TRUE FALSE Getdate()
報修內容 BXNR Varchar(20) FALSE FALSE Getdate()
入廠時間 RCDATE Varchar(20) TRUE FALSE Getdate()
檢驗人員 JYRY Varchar(20) FALSE FALSE Getdate()
維修站點 WXZD Varchar(20) TRUE FALSE Getdate()
表 4-3 修理過程表(續)
名稱 代碼 數據類型 強制 主要的 默認值
維修班組 WXZT Varchar(50) TRUE FALSE Getdate()
完工時間 WXSJ DATETIME FALSE FALSE Getdate()
派工程序界面如圖 4-18所示，檢驗人員可以根據車輛類型、車輛故障內容進行派 工，同一輛車可同時派送給幾個班組。可見，派工功能使得車輛的報修流程實現流水作 業，規范了車輛維修管理。
黃村
«r) 港TIE* ■■ »/ MN9U MflMW M VS BrMN MPIK fHV
乍號: 報修內容：
入■理點但h
婕組: BRT班 Q車陂飯焊組 口廣吿班 0輪胎班
「飯焊二班 a車陂漆工組 口海盛回收公 。輪胎二班
u飯焊一班 a車間辦公室 口后勤 a木工班
口辦公室 a車鉗班 口機電班 a漆二班
□保二班 口車廂牟間 口技檢科 □漆一班
口保三班 口低保臨修班 口檢測組 □搶修中心
口朋諒車間 口鹿盤班 口臨二班 口生產組
口保養檢驗 口電工班 口臨三班 □守護二班
口保一班 口動物園點 □ 1藍一班 □司機班
■?聰 | 0” |
圖 4-18 派工模塊界面
4.7報表管理模塊設計
報表管理是公交車輛報修系統的重點模塊之一。開發出合理、功能實用的報表管理 模塊，既可以讓企業清晰了解到維修業務的整體運行狀況，又關乎到系統能否為企業決 策提供有力支持。Delphi的控件庫非常強大，本系統通過使用RM(Report Machine)控件 的設計designreport功能，允許用戶對報表的格式的輸出進行設計，大大提高了程序的 靈活性和便利性，使得該模塊可以更契合企業需求。
1.RM控件概述
作為Delphi報表控件包之一，RM(Report Machine)的功能非常強大，可以使用戶自 由設計并且設計出各種復雜報表。其中最吸引人的有2點：一是數據的來源多樣化，可 以來自數據庫、文件中、內存等任何地方。二是滿足個性化需求，既可以使用用戶預先 設置的報表模板，又可以即時制作新模板。對于數據中的字段個數不定的情況，可以通 過在運行的時候通過代碼生成模板來輸出報表，大大提高了系統統計功能的實用性。
2.報表模板設計
利用 Delphi 的 RM 控件，再結合 AdoConnection 和 AdoQuery 兩個數據庫控件，可 以輕松實現報表設計功能，這也是最簡單快捷的方法。下面給出部分代碼片段：
procedure TBrowseForm.Button5Click(Sender: TObject);
var
RMRe port:TR MRe port;
begin
if ADOQueryl.lsEmpty then
Exit;
try
RMIReport := TRMReport.Create(Self);
RM Report .LoadFromFile(,Match.rmf,);
RMIReport.PrepareReport;
RMIRe port.ShowR e port;
finally
RMIReport.Free;
end;
end;
procedure TForm 1.Button 1CIick(Sender: TObject);
begin
RMIRe portl .Sh owR e port;
end;
//設計報表模板
procedure TForm 1.Button2CIick(Sender: TObject);
begin
RMIReportl.LoadFromFile(cTTTrmfr);
RMIReportl.DesignReport;
end;
其主要實現過程如下：
首先，在窗體上放置上述 2 個數據庫控件，分別對 AdoQuery 的 Connection 指向和
SQL查詢語句進行設置。然后，在窗體上放上兩個RM報表控件：RMDBDataSet和 RMReporto 其中，RMReport 的 DataSet 設置為指向 RMDBDataSet，并將 RMDBDataSet 的DataSet設置為指向ADOQuery。
為了提高程序的報表設計能力，還可以在窗體上增加RMDesigner控件，控件相關 屬性使用默認設置。這樣，就可以使用RMReport控件設計報表模板了。
實現的系統報表管理界面見圖 4-19所示，界面左側是根據一汽巴士公司的生產實 際需要，在系統中設計錄入了《車輛故障分類月報表》、《聯網搶修工時資料》等超過50 種類型報表；界面右側則是報表創建人資料、報表參數以及報表用戶等基本屬性，充分 體現了 RM控件的靈活性和可塑性。
二分公司 連接：外網連接 李燕娜
圖 4-19 報表管理界面
RM 是 Report Machine 根據報表模板，對數據源進行加工處理生成最終的報表。
Report Machine可以通過在設計器中調用所需的頁面，也可以通過點擊“設計”報表調
出設計器新增或修改報表。如圖 4-20所示：
此外，系統同時可對車輛的在修情況進行實時監控，并可以統計圖表的形式進行展
現。如圖 4-21 所示：
該功能設置了每 10 分鐘自動刷新一次的更新頻率，基本可以做到實時監控維修 廠在修車輛的情況，有利于企業管理人員監控早晚高峰的留廠車輛，有利于提高維修廠 的維修作業效率，也有利于提高企業的高峰出車率。
4.8系統測試實例演示
為進一步測試系統的功能，我們對整個系統從登陸到用戶資料、權限修改，再到報
表統計進行了測試。并選取了報表自定義設計以及生成進行了實例測試。下面將簡要介
紹。
圖 4-22 報表 SQL 設計界面
為滿足企業不同層次用戶的需求，報表設計模塊允許用戶利用 SQL 語言自定義從 數據表讀取數據來設計報表。下面是一個《故障修理大于2 小時》的報表設計事例。界 面如圖4-22所示。可以通過報表SQL界面輸入代碼實現報表的格式自定義。代碼見附 錄。
然后通過自定義報表格式輸出結果，報表格式設計見圖 4-23所示：
頁標頭:PageHeaderl
故障報修分析統計總表（修理時間超過2小時）
單位 故障分類 合計 底盤 制動 發動機 燃料系 電器 輪胎 空調 車廂 其他
1+2+... +9 1 2 3 4 5 6 7 8 9
MasterDatal
rl 故障次數 eport."輪］ Report."底 Report."制、 eport. ）ort."燃舉 Report."哇 Report."輪 Report."空 Report."車 Report."其
修理時間〔 小研） Report."電 3ort. 底盤 eport."制亍 mrt. ”發功 Mt."燃料! eport."電I eport. eport."空1 eport."車』 sport.
主項注腳: AasterFooteri
廠合計 故障次數 iReport. IsReport. IsReport. :Report. 【eport燃: IsReport. ?? IsReport.z，： IsReport. IsReport. IsReport."
修理時間【 小時） IsReport." :eport."底 ;Report."帝 bpdrt. ”發: 羽urt."燃慕 :Report. "E :Report."荊 :Report. "W :Report."耳 :Report."爭
孑艮表時間：[adsReport. w開始時間w]~[adsRe
圖 4-23 報表格式設計界面
得到的輸出結果如圖 4-24 所示：
故障報修分析統計總衰（條理時間超過創、時〕
報衰時阿 201S-1! 0-09^2018-10-^
圖 4-24 報表結果輸出界面
4.9本章小結
本章主要對報修管理系統中主要的用戶身份驗證模塊、用戶權限管理模塊、基礎資 料模塊（車輛檔案子模塊）、維修知識庫模塊以及派工模塊進行了介紹，并對車輛檔案、 等基本數據的定義進行了規范。其中，維修知識庫采用了樹形結構展示，提高了知識庫 使用的便捷性。最后，通過實例演示說明了系統的報表設計、生成和輸出，驗證了系統 開發基本達到了企業需要的效果，能夠有效地指導企業生產，提高企業管理效率，為企 業決策提供有效支持。
第五章 公交車輛報修信息系統關鍵技術研究
開發信息管理系統的目的是規范業務流程，提高數據統計分析效率，提高企業管理 水平。隨著業務的發展和調整，信息系統也需要不斷優化。包括對功能的調整，系統的 擴展以及數據的應用等。只有實現利用系統的數據，進一步指導企業生產，從而有助于 企業壓降經營成本，才能算最終實現系統開發的目標。例如，可以利用車輛保養維護數 據，對維修車間的二級車輛維護作業的排班計劃進行優化，可以提高企業維修資源的效 率。
此外，本文所述的車輛報修管理系統采用的是C/S架構。在后期的系統更新維護上，
由于客戶端分散，使得每次客戶端功能的優化更新，都需要耗費大量人力和時間，有必 要進一步對系統進行優化。對此，系統通過增加自動更新模塊功能，從而大大節省了后 期系統的運行維護成本。
最后，隨著移動互聯網的普及，手機也開始逐漸成為了人們的生產工具之一。例如，
通過微信企業公眾號，我們可以查詢到企業的相關信息。如果可以利用車輛報修管理信 息系統預留的接口，從而實現在微信企業公眾號上查詢車輛維修信息。則可以大大提高 企業的信息化水平。綜上，本章主要討論車輛二級維護優化技術、系統更新優化技術以 及微信企業公眾號開發以及進行研究。
5.1二級維護作業計劃優化
在日常車輛管理業務中，維修廠除了需要對車輛故障進行維修外，還需要定期對車 輛進行各級維護保養。及時有效的車輛維護作業，有利于維持車輛的良好工況和確保車 輛性能，有利于減少車輛故障頻率，從而提升企業的經營效益。為此，有必要對車輛的 二級維護排班計劃作進一步研究分析。為此，可以根據公交車輛報修信息系統中的車輛 保養模塊數據以及企業的車輛營運的行駛數據，通過構建數學模型的方式來對車輛二級 維護順序進行調整，以達到最佳效果。
5.1.1數學模型
以企業某維修廠為例，其負責對分公司的若干線路片區的車輛進行維修保養作業。
假設維修廠某個月內：每天維修車輛數為較為平均的固定值，其方差不大于 4，最 大為 6，最小值為 2。
再假設車輛該月內：車輛每天行駛里程都是較為平均的固定值；需進行二級維護的 車輛都能維修；車輛行駛里程在維修后復位為零。每線路片區每天維修車輛不大于2輛。
構建一個月內的二級維護最優模型.
需要求解的目標函數：
Max》j》j(Mij (p)Njj (p)) (5-1)
約束條件為：
a < IjljNij(p) < b (5-2)
IjNij(p) < d (5-3)
I IjljNij(p)-乞必出(P - 1) 1 < v (5-4)
( Mij (p) (p = 1)
My(p) = (p - 1) + mtj (當Nq(p - 1) = 0 且 p>1) (5-5)
I mtj (當竊(p 一 1) = 1 且 p>1)
Nij(p) = 0 (當Ntj(p ― 1) = 0) (5-6)
式中：i-…線路片區編號；
j 車輛編號；
p 第幾天維修；
a 維修廠每天維修車輛的最小數；
b 維修廠每天維修車輛的最大數；
b 每個線路片區每天可維修車輛的最大數；
Mij(p) 第 p 天 i 車隊中 j 車的行駛里程；
Nij(p) 第 p 天 i 車隊中 j 車的維修狀態值，不維修時為0，維修時為 1；
mij i 線路片區中 j 車第一次維修與第二次維修之間的行駛里程；
V 第幾天維修；
a 每天維修廠車輛二級維護之間的差值；
為了檢測優化模型的有效性，需要選取樣本進行對比。選取了 30 個樣本車輛，其 維修前行駛里程見表5-1 ：
表 5-1 車輛維修前行駛里程 S/km
車隊 車號 總行駛里程 每天運行
里程 車隊 車號 每天運行
總行駛里程
里程
a 2269 17920.7 166.5 d 2745 18032.7 168
a 2742 10022.3 127.6 d 2784 11400.3 183
a 2781 20325.8 172.3 d 2746 19581.8 155
a 0702 16311.8 146.8 d 2787 16436.8 165
a 0521 10325.8 152.6 d 2740 10441.8 170
b 0522 17626.3 131.8 e 2747 17743.3 167
b 1444 15115.2 121.8 e 2786 15233.2 147
b 2582 17250.1 168.4 e 0557 17369.1 162
b 2785 12280.4 133.2 e 0044 12400.4 111
b 2782 18437.7 164.0 e 0031 18316.7 119
c 2744 14364.5 145.3 f 0089 14486.5 157
c 2743 17922.9 120.4 f 2263 17799.9 172
c 2783 16873.0 136.3 f 2316 16997 135
c 2741 13316.6 97.8 f 2283 13441.6 131
c 2269 16714.1 179.8 f 2265 16840.1 184
通過模型計算和優化后，維修后行駛里程見表5-2所示：
表 5-2 車輛維修后行駛里程 S/km
日期 車隊 車號 總行駛里程 日期 車隊 車號 總行駛里程
1 b 1444 20223.1 3 f 0089 20249.7
1 c 2743 19922.9 3 c 2744 19364.5
1 d 2787 20421 3 a 0521 20405.8
1 e 557 20303.3 4 b 0522 20126.3
1 f 2263 20479 4 a 2269 20120.7
1 c 2783 20073 4 b 2785 20280.4
表 5-2 車輛維修后行駛里程（續） S/km
日期 車隊 車號 總行駛里程 日期 車隊 車號 總行駛里程
2 d 2746 20478.1 4 c 2741 20116.6
2 e 0044 20494.2 4 e 2747 20173.4
2 a 0702 20341.7 4 d 2740 20268.5
2 b 2582 19250.1 5 f 2316 20462.8
2 d 2784 20443.6 5 c 2269 20414.1
2 e 0031 19798.5 5 a 2781 20325.8
3 b 2782 20437.7 5 d 2745 20138.7
3 f 2283 20241.9 5 f 2265 20385.6
3 a 2742 20022.3 5 e 2786 20411.1
5.1.2效果分析
根據一汽巴士公司的車輛維護操作規范，公交車輛需每次在行駛里程達到2萬公里 左右時，對車輛進行一次二級維護，從而維持公交車輛的良好車輛性能，消除車輛安全 隱患，提高車輛運營的穩定性，有效延長車輛的營運年限。如果沒有系統、合理的二級 維護計劃，就難以按車輛維護操作規范及時安排車輛進行二級維護。同時，維修廠也不 能根據車輛運營里程數合理安排維修時間，不利于維修效率的提高，造成資源的浪費。
通過調整模型參數，優化二級維護作業計劃，可以大大提高企業維修資源的利用率， 也有利于維持公交車輛的良好工況和性能。但隨著車型的增加和業務的調整，如未來車 輛逐步走向純電動化，維修廠的每天維修車輛數會有所變化，模型的求解難度也會增加。 為此，在未來的一段時間內，一汽巴士公司仍會根據企業生產實際情況，結合歷史數據 歸類分析，進一步優化公交車輛二級維護的功能，解決優化維修作業調度的問題，提升 公交車輛維修信息系統的管理效率。
5.2系統更新維護技術優化
C/S 架構雖然有著速度快、架構簡單、安全性高的優點，但是也有著后期更新維護 成本高的問題。在車輛報修信息管理系統投入使用并全面推廣后，也出現了一些問題， 例如，當系統運行維護人員根據企業需求對系統數據庫或者客戶端功能模塊進行升級后， 需要對 5 個營運分公司、維修廠以及相關臨修點的電腦終端上的用戶端軟件進行更新。 如果采用手工升級，龐大而分散的終端使得系統的更新維護成本異常的高。為此，在系 統中增加了“系統版本強制更新”模塊，讓系統的客戶端更新變得自動化。
5.2.1客戶端自動升級功能的實現
為實現客戶端自動升級功能，我們采用了每次用戶登陸，系統檢測客戶端版本并強 制更新的方案。其功能框圖如圖 5-1 所示。
圖 5-1 客戶端自動更新功能圖
1 . 服務器端 每次系統運行維護人員對客戶端進行優化后，將最新版本的客戶端更新文件放置到 服務器的 update 文件夾。
2.客戶端（終端機） 每次終端機上的客戶端程序打開時，程序通過網絡第一次發出請求訪問服務器。服 務器接收請求信息，并對請求信息中的版本信息進行校對。如果客戶端版本低于最新版 本，則強制客戶端下載升級客戶端版本。部分實現代碼如下：
//是否要下載文件
if FileDateTime,'DATETIME','1900-1-1'))&NBSP;THEN begin
result:=true;
break;
end;
except
end;
finally
AppIni.free;
files.Free;
end;
end;
實現的客戶端強制更新功能界面如圖 5-2 所示。
圖 5-2 客戶端自動更新功能圖
5.2.2客戶端自動更新功能的效果分析
通過此次更新，車輛報修信息管理系統實現了客戶端軟件版本的自動更新，大大減 輕了企業后期維護的人力成本和物力成本，既方便了用戶，又提高了系統的便捷性、穩 定性和實用性。
5.3 微信企業公眾號的相關技術研究
隨著移動互聯網的快速發展，以及智能手機廣泛使用，微信成為了繼 QQ 后的又一 大社交平臺。人們使用手機的頻率大大增加，對微信的使用頻率也大幅增加。同時，隨 著微信平臺的相關應用不斷發展，微信公眾號運營也有了很大的發展，企業、機構和個 人紛紛邁入微信公眾號運營的行列。一汽巴士公司，也順應時代的發展，將微信企業公 眾號作為企業信息化發展的一部分，開設了公眾號“一汽之家”。在前期的微信公眾號 開發過程中，公眾號提供了企業0A公文處理功能，實現了對相關企業人員的賬號驗證 和關聯。
為了跟上時代發展的腳步，一汽巴士公司提出了在企業微信公眾號實現查詢報修車 輛信息的需求。下面將簡單介紹如何在企業微信公眾號實現車輛報修信息的查詢。企業 微信公眾號查詢功能流程圖見圖 5-3所示。
返回
圖 5-3 企業微信公眾號查詢功能流程圖
1.企業微信公眾號作為客戶端，通過微信后臺預設的企業服務器地址接口，發出車 輛報修信息的查詢請求。
2.服務器：服務器的數據庫內的用戶數據表內需要提前錄入企業微信公眾號的用戶 信息和權限。當車輛報修信息管理系統服務器接收到查詢請求時，就先對用戶信息和權 限進行驗證。如果驗證不通過，則流程結束。如果驗證通過，則執行預設的 SQL 指令 進行數據查詢，并返回數據給客戶端。其中服務器預設的查詢車輛部分指令代碼為：
select * from fault where busno ='4123' and ReportDatetime between getdate()-30
and getdate()
getdate() ：返回當前時間的函數
getdate()-30 當前時間 減 30日
目前，在企業微信公眾號可以查詢到車輛近30天的報修記錄。以自編號4268車為 例，實例查詢見圖5-4公共信息查詢類型界面和圖5-5報修記錄查詢界面所示。
X 公共信息查詢 •••
請選擇公共信息查詢類型
交通車查詢
實時車輛信息查詢
司機安全業績查詢
最近報修記錄查詢
線路簡圖
圖 5-4 公共信息查詢類型界面圖
可見，基于C/S架構開發的車輛報修信息管理系統，通過預留的接口，可增強其擴 展性。既方便了企業管理人員、司機實時查詢車輛狀態，又大大提高了企業的信息化水 平。此外，還可以使用微信企業公眾號已鏈接的0A賬號對用戶權限進行設置，使得企 業可以設置哪些用戶允許使用車輛報修記錄查詢的功能，提高系統的安全性。
X 報修記錄查詢 …
單位： 隹“ 車號： {4268 ）
查詢
,修理 點 入廠時間 報修 類型 報修內容
門口
崗 2018-10-02
23：47 臨修 安全帶壞I
修配 2018-09-30
21：38 轉廠 臨修 雨刮壞I方向重I
門口
崗 2018-09-29
22：53 一保
門口 崗 2018-09-28
22：36 臨修 水喉漏水I雨刮壞I
門口
崗 2018-09-14
23：08 臨修 方向盤不正I
新窖 南 2018-09-14
07：06 臨修 方向盤不正I
修配 2018-09-10
18：56 轉廠 臨修 怠速不穩I變速箱、波箱 故障I方……
備注： < >
圖 5-5 報修記錄查詢界面
5.4 車輛報修信息系統應用后的管理效果分析
隨著系統自動強制更新等功能的逐步完善，車輛報修信息系統已推廣到一汽巴士公 司的 5 個維修廠，以及維修廠下轄的 13 個臨修點。并在分公司以及公司管理部門進行 應用。系統應用大大地有效提高維修廠的管理效率，降低企業成本，并提升企業效益。 主要表現在以下兩方面：
1.人力資源成本的降低
由于系統及數據庫的大規模應用，相當數量的統計人員和技術運維人員得以減少。 系統投入使用后，企業實際管理人員比投入使用前減少了 9 人，相當于平均每個分公司 減少 1-2名管理人員。假設一汽公司按廣州市2017 年社平工資8218 元，企業應交養老 保險、醫療保險、失業保險及生育險等費用約為 1807.96元（企業應交份額按 22%計算）， 預計每位員工每月成本支出為 10025.96 元。由此可得，企業此后每年可減少 96.25 萬元 的人力成本。
2.完善評價體系，提升管理效率
通過系統的投產使用，可以實現車輛從投產到報廢更新的車輛維修保養信息的可追 溯性，為下一步企業進一步完善車輛及零配件評價體系提供基礎數據，也為完善維修工 作的績效評價指標提供有力支持。例如，通過對同一批次的剎車片使用狀態進行跟蹤， 可以對企業零配件采購提供基礎數據。又例如，對維修技工的同一車輛同一問題三天內 兩次返修的數據分析，可以完善對維修技工的績效評價，使得企業可以有針對性地對維 修技工進行培訓，從而提高維修效率。
5.5本章小結
本章內容主要是在系統現有功能的模塊基礎上，通過研究二級維護優化技術幫助企 業提高維修工作管理水平。同時研究了系統更新維護優化技術，實現了客戶端的自動更 新，大大降低了車輛報修信息管理系統的后期維護成本。其次，本文對基于微信企業公 眾號平臺查詢車輛報修信息的技術進行研究，實現了手機微信公眾號查詢某車輛近 30 天報修記錄的功能，大大提高了企業的信息化水平，也提高了車輛報修信息管理系統的 實用性和便捷性。最后，系統在企業內部大規模推廣應用后，對企業的成本壓降和效率 提升效果進行分析。
總結和展望
總結和展望
1.總結
隨著人民生活水平的提高，私家車的保有量飛速增長，城市道路擁堵加劇，公共交 通出行成為解決城市擁堵的有效措施，因此，公交企業需要不斷提升服務水平來滿足市 民的出行需求。另一方面，隨著人力成本的與日俱增，公交公司面臨著諸多挑戰，也迫 使企業不斷提升管理效能，壓降成本，才能在日益激烈的競爭中存活下來。因此，傳統 的管理方式已經跟不上企業日益發展的需要。一方面公交企業必須借助信息化手段，節 約成本，提升企業管理效率；另一方面。公交企業必須做好公交車輛的維修和維護，避 免“巧婦難為無米之炊”的尷尬情況，提升車輛利用率。對此，本文結合一汽巴士公司 的實際維修業務情況，進行了公交車輛維修信息系統開發可行性研究、系統構建以及二 級模型優化技術的研究，本章將對全文進行總結。
本設計總體上采用C/S體系結構即客戶端服務器結構，客戶端基于Delphi語言開發, 服務器采用SQL SERVER企業版。系統開發和模塊構建是基于一汽巴士公司維修管理 的實際情況，遵循軟件工程方法論，以企業需求為導向，并采用系統生命周期開發形式。 論文以系統開發過程為主線，先介紹了項目背景，闡述了本文需要用的Delphi語言、SQL 數據庫技術以及 AD0 動態連接。本文也對系統 C/S 系統架構開發的系統的技術可行性 和經濟可行性進行了對比,C/S架構具有更大的靈活性和便捷性，更契合企業實際需求， 因此本文采取了 C/S 架構進行開發。
其次，本文對車輛檔案、故障分類等基本數據的定義進行了規范，并對報修管理系 統中用戶身份、權限管理模塊以及維修內容等模塊進行了介紹。其中重點對Delphi的 RM控件運用進行了介紹，通過系統的報表設計、生成和輸出，展示了該信息系統強大 的報表統計功能。此外，本系統還探討了車輛二級維護優化技術，拓展了系統的應用范 圍和應用深度，使得公交車輛報修信息系統不再是數據存儲工具、信息化代工工具，而 是企業維修管理工作決策的重要工具，提高了維修工作的自動化、網絡化和智能化，提 升了維修工作的效率。最后，本文對系統的推廣應用及效果進行了分析，車輛報修信息 系統在企業內部各單位的推廣使用，并有效降低企業人力資源成本和管理效率，說明系
統的開發取得了預期效果。
2.展望
在車輛報修信息管理系統開發過程中，雖然受制于時間緊湊、開發水平有限等因素， 開發過程中遇到了一些問題，但通過加強與一汽巴士公司營運部、技術與信息化部、二 分公司以及其附屬維修廠的溝通，明確企業需求，查閱了大量的相關資料，并對項目方 案進行修正，因此開發工作進展得相對順利。目前車輛報修信息管理系統已經成為一汽 巴士公司信息化架構的重要部分，為企業下一步開發車輛實時監控和跟蹤系統、電子圍 欄應用等信息化工作計劃打下了堅實基礎。由于能力和水平有限，系統仍然存在一些不 完善之處，有繼續優化的空間。例如，隨著系統數據積累，數據庫日益龐大，系統數據 查詢響應速度需繼續優化。此外，未來隨著企業的業務變化和管理方案的不斷完善，企 業生產業務流程也可能會進行調整，系統也就需要對功能模塊進行優化調整。
本次的系統開發工作大大鍛煉了我分析問題、解決問題的能力。在系統的設計過程 中，我學會了如何開展前期調研分析需求工作，如何使用系統生命周期法開發信息系統， 如何查閱文獻資料，如何進行數據庫設計，也對一汽巴士公司車輛維修業務有了更深入 的了解和體會，也鍛煉了我應用所學知識解決特定問題的能力，這些都將成為我今后工 作中的一筆寶貴財富。
參考文獻
參考文獻
[I]李建軍，劉兵，金麗娜，等.基于CMMB的動態交通信息服務J].廣播電視信息，
2008, (9): 56-59
⑵ 廣州市交通委員會.廣州交通運輸月報〔2017〕第5期[EB/OL]. http://zwgk.gz. gov.cn/GZ16/8.2/201706/d64937336f6f4e1b974773798efe548d.shtml， 2017-6-23
[3]呂川.維修性設計分析與驗證[M].北京：國防工業出版社，2012
[4]Haghani A , Shafahi Y . Bus maintenance systems and maintenance scheduling: model
formulations and solutions[J]. Transportation Research, Part A (Policy and Practice), 2002, 36(5): 0-482
[5]Seo J , Bai D S . An optimal maintenance policy for a system under periodic overhaul[M].
Elsevier Science Publishers B. V. 2004, 39: 373-380
[6]Qian C , Nakamura S , Nakagawa T . Replacement and minimal repair policies for a
cumulative damage model with maintenance[J]. Computers & Mathematics with Applications, 2003, 46(7): 1111-1118
[7]Lam Y . A geometric process maintenance model with preventive repair[J]. European Journal of Operational Research, 2007, 182(2): 806-819
[8]Jefrey D, UIIman. A First Course in Database System[M]. 北京：清華大學出版社， 2001：
70-72
[9]王雄.關于公交企業維修管理的思考J].科技視界，2013，(4): 151-152
[10] 孫世華.I/M制度與國內城市公共交通車輛的維修[J].中國高新技術企業，2008, (17): 170-171
[II] 何有世.管理信息系統[M].南京：東南大學出版社，2003
[12]李永平.信息化辦公軟件高級應用[M].北京:科學出版社，2009
[13]王軍.沈陽市出租汽車行業管理信息系統解決方案[D].長春：吉林大學，2010
[14]張海藩.軟件工程導論[M].北京：清華大學出版社，2003: 20-65
[15]王娟.企業信息化建設與管理[J].計算機與網絡，2013，39(23): 58-60
[16]鄒小琴.基于網絡的管理信息系統研究[J].計算機應用研究，2002，19(1):
38-39
[17]黃梯云.管理信息系統[M].北京：高等教育出版社，2005
[18]喻海波.汽車修理管理系統的開發[J].采礦技術，2005, 5(4): 38-39
[19] 吳紅霞.我國企業信息化建設的現狀及對策[J].統計與決策，2005, (17):
142-143
[20]羅耀明.維修信息管理系統在公交企業維修車間的應用[D].成都：西南交通大 學， 2011: 34-46
[21]史永莉，李濤，宋瓊.基于C/S模式MIS系統的技術研究J].南昌航空大學學報 (自然科學版)， 2006， 20(2): 76-79
[22]程國卿，吉國力.企業資源計劃(ERP)教程[M].北京：清華大學出版社，2008
[23]李向波，侯家麟.工業技術經濟學[M].北京：中國鐵道出版社，2006
[24] 陳朝陽，王永寬，張代勝•汽車故障診斷知識庫管理系統的研究[J].汽車維修 與保養， 2004， 12(1)： 82-85
[25]夏銀生.合肥市公交智能調度系統設計與實現[D].大連：大連理工大學，2014：
3-15
[26]邢軍，朱啟林.汽車維修管理[J].環球市場信息導報，2013，(24)： 35-42
[27]王雄.關于公交企業維修管理的思考[J].科技視界，2013，(32)： 36-38
[28]周衛兵.基于案例推理車輛維修專家系統的研究[D].合肥：合肥工業大學，
2004
[29]周燦根.基于C/S體系結構的車輛自動化管理信息系統J].海軍大連艦艇學院學 報， 2002， 25(5)： 60-62
[30]王宏威.淺析我國汽車維修業現狀及發展策略J].工業技術，2007，19(7)：
13-15
[31] 李雁翎. 數據庫技術及應用 SQL Server[M]. 北京： 高等教育出版社， 2008
[32]黃大明，黃偉，舒國云，等.基于總費用的車輛維修班組結構優化J].中國農 機化， 2005， (01)： 45-47
[33] 丁風海，夏偉，邱斌，等. Dephi中基于ADO技術實現定制報表的生成[J].現代 電子技術， 2012， 35(24)： 35-37
參考文獻
[34] 王劍南.軟件B/S前臺開發[M].北京：清華大學出版社，2012
[35]王豐產.基于B/S結構的汽車維修行業管理信息系統設計和開發[D].鄭州：河 南農業大學， 2006
[36]豆丁網.天然氣汽車安裝維護培訓資料[EB/OL]. http://www.docin.com， 2017-12-25
[37]李祥貴，仝曉平.道路運輸車輛安全部件維修工藝[M].北京：人民交通出版社,
2012
[38]王秀倫.現代工藝管理技術[M].北京：中國鐵道出版社，2004
[39] 劉帥.公交車輛維修信息系統及關鍵技術研究[D]，濟南：山東大學，2014
[40]孟憲虎， 馬雪英， 鄧緒斌. 大型數據庫系統管理、設計與實例分析—基于 SQL Server[M]. 北京： 電子工業出版社， 2008
[41]馬至遠.管理信息系統開發方法比較與統一 [J].商場現代化，2009，(16): 13-15
[42]Guida M , Pulcini G , Vianello M. Early inference on reliability of upgraded automotive components by using past data and technical information[C]. Journal of Statistical Planning and Inference, 2009, 139: 1604-1618
[43] 劉桂英.基于C/S架構的信息管理系統設計及實現J].計算機與信息技術，2008, (Z1)： 83-85
[44]Michael L , Gentry B . SQL Server and the NET Client[M]. [S.l.]: Wiley Publishing, Inc. 2009
[45]drdobbs. Using c-tree and ADO in your client/server[J]. Dr Dobbs Journal, 2003, (4): 22-25
[46]尹楠，陳操.基于B/S和C/S架構的學生信息管理系統的設計J].信息系統工程, 2012， (7)： 65-67
[47] 徐莉，段春梅.Delphi+SQL Server數據庫應用系統開發中的數據訪問技術J].電 腦開發與應用， 2008， 21(2)： 78-79
[48]張乾.基于Borland Delphi開發平臺的數據庫應用系統開發的原理與應用研究[D]. 重慶： 重慶大學， 2009
[49] 陳小偉.數據庫系統開發中Delphi的編程應用[J]. 2010，(02): 15-17
[50] 啟明工作室.Delphi+SQL Server數據庫應用系統開發與實例[J]. 2005，(12)：
18-22
[51] 邢文建，馬麗艷，郭子平.Delphi中Ado控件SQL Server數據庫開發[J].遼寧 工程技術大學學報， 2005， 24(3)： 407-409
[52]丁繼武.基于Dephi + Sqlserver建設醫保信息管理系統[J].計算機光盤軟件與應 用， 2011， (14)： 47-48
[53]馮月勛.利用Excel的VBA與ADO和SQL技術相結合實現財務報表自動生成一 —基于用友ERP-U8總賬系統[J].中國管理信息化，2013，(3)： 53-57
[54]黃聰.Delphi實現軟件中登錄用戶的操作權限[EB/OL]. http://www.cnblogs.com
/huangcong/archive/2010/11/09/1872848.html， 2010-11-09
下一篇：沒有了
相關標簽:
