<nav id="w0g0m"><code id="w0g0m"></code></nav>
  • <xmp id="w0g0m">
    <xmp id="w0g0m"><nav id="w0g0m"></nav><menu id="w0g0m"><strong id="w0g0m"></strong></menu>
  • <xmp id="w0g0m">
  • <nav id="w0g0m"></nav>
    <menu id="w0g0m"><menu id="w0g0m"></menu></menu>
    1. 網站地圖
    2. 設為首頁
    3. 關于我們
    ?

    氣瓶配送及其信息管理研究

    發布時間:2023-07-25 09:54
    目 錄
    第一章 緒 論 1
    1.1研究背景及意義 1
    1.2國內外研究現狀概述 2
    1.2.1國外研究現狀 2
    1.2.2國內研究現狀 4
    1.3本文研究內容 5
    1.4本文的組織結構 6
    第二章 系統技術選型與總體設計 7
    2.1功能分析 7
    2.1.1配送功能分析 7
    2.1.2其他功能分析 7
    2.2技術選型 9
    2.2.1系統軟件體系結構 9
    2.2.2系統硬件體系結構 11
    2.2.3開發技術選型 12
    2.3系統總體設計 15
    2.3.1系統開發環境 15
    2.3.2系統物理結構設計 16
    2.3.3系統應用功能設計 17
    2.3.4系統集成設計 18
    2.4本章小結 19
    第三章 配送路徑優化 20
    3.1配送問題基本原理 20
    3.1.1配送問題描述 20
    3.1.2配送問題構成要素 20
    3.1.3配送問題優化目標 21
    3.2聚類分析 22
    3.2.1訂單聚類 22
    3.2.2訂單鄰域系統 24
    3.3配送問題數學模型 25
    3.3.1VRP 模型 25
    3.3.2VRPTW 模型 27
    3.3算法設計 29
    3.3.1遺傳算法 29
    3.3.2禁忌搜索算法 30
    3.3.3遺傳禁忌混合算法 32
    3.3.4基于訂單聚類的種群初始化 34
    3.3.5算法的具體實現技術 35
    3.4實驗分析 39
    3.4.1數據選取 39
    3.4.2仿真分析 42
    3.4.3實例驗證 48
    3.5本章小結 48
    第四章 信息管理系統的設計與實現 49
    4.1數據庫設計 49
    4.2銷售管理 53
    4.2.1采購庫存管理 53
    4.2.2銷售配送管理 55
    4.3氣瓶管理 57
    4.3.1加氣信息管理 57
    4.3.2氣瓶信息管理 58
    4.4信息管理 59
    4.4.1用戶設備管理 59
    4.4.2充值信息管理 60
    4.4.3統計報表管理 61
    4.5系統管理 62
    4.6本章小結 64
    第五章 系統的測試 65
    5.1測試環境 65
    5.2配送路徑測試 66
    5.3銷售管理測試 66
    5.3.1采購庫存管理 66
    5.3.2銷售配送管理 67
    5.4氣瓶管理測試 68
    5.4.1加氣信息管理 68
    5.4.2氣瓶信息管理 68
    5.5信息管理測試 69
    5.5.1用戶設備管理 69
    5.5.2充值信息管理 70
    5.5.3統計報表管理 70
    5.6系統管理測試 71
    5.7測試結論 71
    5.8本章小結 72
    第六章 總結與展望 73
    6.1主要工作及結論 73
    6.2研究展望 74
    致 謝 75
    參考文獻 76
    攻讀碩士學位期間的研究成果 80
    第一章 緒 論
    1.1 研究背景及意義
    隨著經濟的發展,物流配送在企業經營中的地位越來越高,對企業經營中其 它方面的影響也越來越大。物流配送與生產、采購、銷售、運輸等環節緊密結合, 它的目的是以盡可能低的成本來為顧客提供盡可能好的服務。據有關統計資料表 明,在不考慮運輸額外成本和意外損失的情況下,物流配送成本大約占到全部 GDP 的 15%左右。并且據相關網站統計,物流成本在企業經營總成本中所占比例越來 越大[1]。
    隨著生活水平的提高,大家對配送服務質量的追求越來越高,主要表現在配 送的準時率上。同時,由于人工時間成本也在增加,企業往往要求在約定服務時 間進行配送,這也就產生了配送規劃的時間窗問題。因此,配送服務需要迎合顧 客的時間需求,顧客才會滿意。隨著加氣站氣瓶配送業務的增長,配送成本居高 不下,同時顧客對于配送時間的要求也越來越高,多車輛帶時間窗口的配送成為 困擾加氣站氣瓶配送的難題。為了節約成本,提高配送質量,滿足顧客的配送需 求,急需對氣瓶配送進行合理規劃。
    近年來,隨著社會對各類氣體的需求量越來越大,隨之產生的問題也越來越 多,目前我國對氣瓶的監管還較為薄弱,氣瓶信息化建設還不夠完善,氣瓶爆炸 的安全性事故時有發生。據不完全統計 2017 年,我國發生的燃氣事故就高達 950 起,共造成 1145 余人受傷,104 余人死亡。其中發生在室內燃氣爆炸事故就高達 680起,發生在室外燃氣爆炸事故約 270起。除此之外,因為施工導致的燃氣事故 同樣高達116 起[2]。2017 年燃氣事故平均每月有79 起,其中 7月份發生燃氣事故 最多,共發生約 112 起,7 月份燃氣事故平均每天就有將近 4 起。特別是 2017 年 杭州 7.21 餐館煤氣瓶爆炸事故,7 月 21 日上午 8 點在杭州市古墩路 1185 號商鋪 發生煤氣瓶爆炸事故,該事故影響嚴重,共造成 2 人死亡,46 人受傷,其中多人 嚴重燒傷。事故不僅造成餐館受損嚴重,還波及路上的公交車以及電瓶車,當時 是早高峰,公交車上乘客較多,車窗全部震碎,多名乘客不同程度受傷,此事件 在社會上引起的反響巨大,社會各界對加強氣瓶安全性管理的呼聲越來越高[3]。 2017年燃氣事故月統計分析如下圖 1-1所示。
    2017年每月燃氣事故統計分析
     
    圖 1-1 2017 年每月燃氣事故統計圖
     
    正因為氣瓶的配送和監管還存在諸多問題,所以研究氣瓶的配送及其信息管 理就顯得非常有意義。傳統的企業管理方式已經不能滿足現代化的市場需求,一 種新的信息化、智能化的管理方式急需研究。當前時代,信息化和智能化成為時 代的主題,各種新技術層出不窮,科技創新給我們帶來了許多好處,科研投入越 來越大,科研成果越來越豐富,所以解決氣瓶監管和配送問題在技術上已經不存 在任何問題。隨著人們安全意識的提高,國家相關部門對氣瓶監管的重視,以及 企業加氣站等對經濟利益的追求,一種創新性的,高效的管理模式急需我們開發, 這就推動我們加快研究氣瓶的配送及信息管理,同時使這一課題研究變得非常有 意義。
    1.2國內外研究現狀概述
    1.2.1 國外研究現狀
    國外學者對路徑規劃VRP (Vehicle Routing Problem)問題研究起步較早,在 1959 年, Dantizig等人第一次提出了路徑規劃問題(VRP),從此眾多專家學者開 始研究路徑規劃問題[4]。在1962年, Balinski 等人提出了配送路徑規劃的集分割方 法,并對解的表示方法進行了改進,建立了該問題的模型[5]。在1964年, Alain Hertz 等提出了一種組合的思想,結合貪婪法的優點和插入法的優點,對解決該問題效 果較好[6]。后來,許多專家學者對該問題進行了大量的研究,并改進了相關算法和 建模。近年來,許多專家提出了基于時間窗口和多車型、多配送點的路徑規劃問 題,形成了 VRPTW(Vehicle Routing Problem With Time Windows)問題⑺。
    從該問題的解法來看,主要有兩類:精確算法和啟發式算法。精確算法主要 有貪婪法、列舉法等算法。這種算法在解決普通配送路徑問題時有一定的效果, 但是大規模問題的求解比較困難。近年來,隨著啟發式算法的發展,標準遺傳算 法、禁忌算法、粒子群算法、蟻群算法等啟發算法大量被應用在帶有時間窗的配 送路徑規劃問題上[8]。由于啟發式算法在解決配送路徑問題效果較好,因此成為路 徑規劃問題和帶有時間窗口的路徑規劃等 NP 難題的主要研究方向。 Willard 第一 個提出用禁忌搜索算法來解決配送路徑難題,并提出簡化配送路徑規劃問題,將 其轉換為旅行商來解決,得出了較為合理的方案[9,10]。 Melvyn 和 Hoong 等人,將 遺傳算法引入帶時間窗口的車輛配送問題上,從而求出了滿意解[11,12]。 2010 年, Braysy 等人提出了一種改進的遺傳算法,解決了標準遺傳算法容易陷入局部最優 的問題[13]。目前各類混合啟發式算法成為 VRP 問題的研究重點。啟發式算法分類 如下圖 1-2 所示。
     
     
    由相關文獻可知,世界上最早的 CNG 加氣站建于意大利北部,國外能源巨頭 在加氣站以及氣瓶的信息化建設方面起步較早。目前,國外加氣站以及氣瓶管理 的自動化程度較高,信息化建設較為全面,各個企業均推出了基于現代化的企業 物流信息化管理的先進理念,并建成了現代化的物流配送體系,氣瓶監管體系也 趨于完善。比如美國安吉公司,加拿大的 IMW 公司,意大利的新比隆公司等,它 們早已經實現了各種工業以及民用氣瓶的全流程跟蹤,從出廠登記到充裝和檢驗, 再到銷售和配送以及報廢都可以追蹤,當出現事故時,可以查找相關記錄,迅速 查明原因并給出解決方案[14]。
    隨著科技、物流以及互聯網技術的發展,關于氣瓶以及加氣站的銷售配送的 智能化程度越來越高,氣瓶銷售配送的效率可以有效提高企業的效率,降低成本, 關于這方面的研究也越來越多,這種銷售配送的隨機性較大,配送的用戶和對象 時常跟隨市場的情況而改變。在如今高度信息化的時代,配送的人性化,智能化 在物流企業中的表現就顯得尤為重要,物流作業過程中的大量策劃和決策既體現 在配送過程中的的各個細節,也體現在企業配送中心的管理,分配方式以及物流 中轉站的選定等。這種智能化的配送方式需要大量自動化的設備作支撐,同時還 需要優秀的配送優化算法以及合適的配送路徑選擇。物流智能化是現在網絡時代 的發展新趨勢,而核心其實就是以顧客為中心。連鎖超市巨頭沃爾瑪,與其競爭 對手相比,至少提前十年以上開始研究物流配送以及倉儲存量。二十世紀七十年 代,沃爾瑪開始研究部署基于物流的信息管理系統,提高了工作效率,提升了管 理水平。接著,沃爾瑪始終在尋求管理創新,在二十世紀八十年代,又引進了 POS 機(銷售點管理系統)、EDI (電子數據交換)和QR (快速反應技術)等技術[15]。 1.2.2 國內研究現狀
    國內對很晚才開始研究VRP問題,主要的研究成果集中在VRPTW問題模型 的建立以及相關算法上。在 1999年,楊西龍等人在改進遺傳算法時,發現染色體 映射的方式可以改善算法效果,實驗表明,改進后可以得到較好的解[16]。袁慶達 和潤昱在 VRP 問題上引進了禁忌搜索算法,并驗證了算法的可行性[17]。郎茂祥和 胡思繼等人在分析了遺傳算法的缺陷后,根據其缺陷特點,提出了結合“爬山算 法”來進行改變,經過實驗表明,該方法可以有效避免局部最優解[18]。 2007 年, 王凌和張亮等人提出了帶時間窗口的改進遺傳算法,使多個變異因子和交叉因子 實現多重搜索,這種方法可以提高局部搜索能力[19]。 2009 年,黃敏等人通過對配 送準時率的研究,提出了一種多目標函數的針對配送準時率的改進方法,這種方 法是加權平均法[20-22]。 2010 年,任杰等人通過設置懲罰時間窗口和最大載重量的 約束條件,從而得到適應度函數,同時對遺傳算法的各類參數進行了改進,設計 出了有時間約束條件的改進遺傳算法[23-25]。 2012 年,高洪波等人在對選址進行探 討時,引入了自適應的遺傳算法,并將地理位置信息技術等引入到VRP中,進行 了選址和路線的統一規劃[26]。
    在我國,早期的加氣站主要業務為部分民用、商用以及工業用氣,管理模式 主要以人工處理為主,信息化和智能化程度都不高;氣瓶配送方式主要以經驗為 主,比較被動地根據訂單來分配配送任務;而倉儲管理也是比較粗放式的管理方 式,往往根據經驗來對存儲量進行決策。雖然目前我國物流行業發展較快,比如 順豐等物流企業的信息化建設已經比較完善,智能化程度也比較高,并且還在不 斷完善中。同時近幾年興起的互聯網行業中,外賣和打車行業中關于配送和路徑 優化等問題也研究比較深入。比如滴滴打車中會根據道路擁堵情況和距離優化行 車路線,美團外賣會根據訂單分布情況給配送人員分配配送訂單等。這些系統結 合電子地圖,運用強大的地理數據功能來完善路徑分析,及時獲取最新的訂單信 息和道路情況,能夠快速合理地分配人力和物力,提供最佳的配送路線,為管理 決策提供可靠地分析與依據。
    雖然我國在物流和打車以及外賣行業的訂單配送和路徑優化方面發展較快, 但是這些技術在其它行業的銷售與配送方面還沒有得到廣泛地應用。特別是氣瓶 管理方面還是較傳統的經驗式的管理方式,很顯然傳統的管理方式已經不能滿足 現代行業的需求。現代物流行業的信息化技術,依靠RFID、GIS、網絡等形成的 現代物流體系為這些企業在行業中競爭提供了核心競爭力。隨著需求的變化,現 有的氣瓶行業管理體系已經無法滿足現代化的需求。
    由此可見,目前國內的氣瓶信息管理系統還有許多需要改變的地方,在未來 還需要投入更多的精力在信息化和智能化方面。結合計算機技術,網絡技術,數 據庫技術等完成對采購、配送、檢驗、倉儲、訂單、配送等環節的優化。
    1.3 本文研究內容
    本文的主要研究內容為:結合加氣站的實際業務需求,將VRPTW(配送路徑 規劃)、GIS (地理信息系統)、RFID (無線射頻技術)、PDA (智能手持終端)、網 絡技術、數據庫技術、物聯網技術等相關技術進行融合,打造一個入庫、檢驗、 倉儲、訂單、調度、配送、銷售、收款、客戶等業務環節為一體的信息化智能化 的管理系統,從而提升企業在業務、管理、銷售、配送等方面的競爭力。本文將 根據企業實際情況,分析企業具體業務需求,并結合國內外相關信息化建設方面 的經驗,根據企業經濟實力選擇目前國內外最先進最合適的技術,從業務細節、 技術選型、整體設計、經濟利益、關鍵技術、用戶體驗、配送準時率等多方面著 手進行深入地研究,最終設計出最合理的方案。本文的研究內容主要包括:
    (1)分析氣瓶配送及其信息管理系統所用到的技術,研究可行技術組合。考 慮到實際情況,根據業務需求,首先需要完成該系統的重點,氣瓶配送的路徑規 劃問題;然后需要完成氣瓶的信息管理。配送路徑規劃這一問題采用帶時間窗口 的遺傳禁忌混合算法來求得配送路徑的最優解。該系統軟件部分采用 B/S 架構, 同時采用目前主流的Java語言進行開發,基于J2EE的開發平臺,數據庫采用MySql 對氣瓶配送及其信息管理系統的數據進行管理。這種組合已經廣泛被用于各大互 聯網企業和各類大型系統中,可以滿足氣瓶配送及其信息管理系統的開發需求。
    (2)系統的設計。首先確定了該系統在技術上可行,然后通過仔細分析企業 的業務需求,考慮到企業經濟利益、用戶體驗、配送準時率等問題,最終確定了 企業的用戶類型,并設計了相應的使用權限。進而將各種業務需求進行模塊化設 計,確定了各個模塊的具體需求,并對其業務細節進行了詳細地設計,其中重點 對配送路徑進行了規劃,減少了企業經營成本。然后根據需求進行數據庫設計, 最后完成編碼工作。
    (3)系統的實現與測試。在完成系統設計以及編碼的基礎上,對軟件部分進 行功能測試,完成軟件部分測試后,結合硬件進行聯合測試,并為相應的功能模 塊設計了測試數據,不斷測試調試直至達到需求。完成功能性測試后,對系統中 的算法部分進行優化,結合實際情況進行調整,最終達到為企業提高管理效率, 提升經濟效益的目的。
    1.4 本文的組織結構
    根據本文對氣瓶配送及其信息管理系統研究的內容,將本文章節安排如下: 第一章是緒論,簡述了配送路徑的發展概況和氣瓶行業的背景,并分析對比了 目前國內外的發展狀況,同時還介紹了本文的研究內容和組織結構。
    第二章針對系統開發的需要,對系統進行了功能分析,并概述了系統技術選型 與相關理論,主要包括系統設計總體技術原則、軟件體系結構、硬件體系結構、 開發技術簡介以及系統總體設計。
    第三章對氣瓶的配送路徑進行了規劃,首先描述了配送問題,然后對該問題建 立了數學模型,接下來提出了基于聚類的遺傳禁忌混合算法,最后結合仿真和實 際運行情況對該問題進行了分析。
    第四章為系統的實現部分,首先規劃了系統數據庫,然后分模塊對各個模塊的 實現以關鍵技術、界面展示等形式進行了敘述。
    第五章講述了系統的測試,主要包括測試環境的介紹,按照測試用例進行測試, 對測試出現的問題進行改進,并分析測試結果。
    第六章為全文的總結和論文后續需要完善的工作。對本文的研究內容加以總結 分析,并展望接下來需要改進和研究的方向。
    第二章 系統技術選型與總體設計
    2.1 功能分析
    該加氣站是一個傳統的加氣站企業,期待轉變企業經營方式,實現現代化的 企業經營管理,需要對氣瓶的配送實現路徑規劃,同時需要實現氣瓶的追蹤溯源。 在系統的設計時不僅要考慮氣瓶的采購、運輸、充裝、存儲、檢驗、銷售、配送 等環節以及這些環節之間的管理,同時還應該考慮到企業經營過程中的人力、物 力、財力等所需要的成本。
    因此,根據實際情況和業務需求,以及考慮到成本和技術難度,下面將氣瓶 配送及其信息管理系統的功能進行分析。
    2.1.1 配送功能分析
    配送路徑優化是本系統的重點,同時也是難點,該部分主要完成根據一定時 間內客戶的訂單情況,合理安排車輛進行氣瓶的配送,降低氣瓶配送的成本,提 高運輸車輛的運輸率,在能夠滿足客戶需求的基礎上進行合理的配送路徑規劃, 在提升服務質量的同時降低運輸成本。車輛的調度和路徑規劃是銷售部門的核心 業務,用戶需要加氣站在指定的時間范圍內將氣瓶送達指定的地點,而加氣站需 要在滿足所有客戶的需求的基礎上降低成本,要滿足這些需求都需要一定的技術 手段來合理安排車輛和路徑。
    本系統中氣瓶的配送存在特殊性,客戶要求在指定的時間窗口內將氣瓶送達, 普通用戶一般僅需要液化石油氣瓶,而企業用戶需要工業氣體如氧氣、乙炔、二 氧化碳、氮氣、氬氣等,考慮到安全性,可燃氣體與氧氣瓶等助燃氣體不能一起 運輸,而其他惰性氣體可以混合運輸,所以在進行配送路徑規劃時應該考慮實際 情況,安排不同車型車輛進行配送。用戶位置信息和各個用戶之間的距離通過地 圖獲取,避免傳統計算方式帶來的誤差。
    2.1.2 其他功能分析
    1、采購庫存管理
    采購庫存管理模塊主要完成對氣體、氣瓶的采購和氣瓶的庫存管理工作,采 購和庫存是企業經營管理的第一個環節,也是最重要的環節之一,通過科學的管 理可以為企業的經營管理帶來巨大的經濟利益,保證企業在經營時不會因為采購 和庫存問題影響正常的經營活動。
    2、 銷售管理
    氣瓶的銷售管理主要完成氣瓶銷售環節的各部分功能,其中配送路徑規劃是 氣瓶銷售環節的一個重要部分,同時配送路徑也是銷售環節的一個難題,合理地 分配路徑和配送車輛可以節約一大筆企業經營管理的費用,所以在配送環節需要 根據當天一定時間內訂單情況,合理規劃配送路徑,安排適當的配送車輛。
    3、 加氣管理
    加氣管理主要針對企業對氣瓶的加氣業務,每個氣瓶都有電子標簽這個唯一 的身份標識,每次加氣前會掃描電子標簽,然后通過手持設備將相關信息在加氣 完成后錄入數據庫。
    4、 氣瓶信息管理
    氣瓶管理業務主要包括對加氣站氣瓶的信息登記、充裝、檢驗等環節進行管 理,同時還包括對報警氣瓶以及報廢氣瓶的處理工作。企業給每個氣瓶貼上電子 標簽,該標簽是氣瓶的唯一身份標識,便于簡單的對氣瓶進行管理,實現氣瓶動 態追蹤。
    5、 用戶設備管理
    用戶設備模塊主要是維護加氣站的客戶信息和各類設備的使用情況,方便管 理人員隨時查看客戶信息,以及查看各類設備信息,具體包括客戶管理、設備管 理、車輛管理三大部分。
    6、 統計報表管理
    統計報表環節主要完成對氣瓶數量、銷售數量、客戶數量和采購數量等數據 的統計,然后形成月報表和年報表,并以折線圖的形式展現,形象地展示各類數 據的變化情況。
    7、 充值信息管理
    充值管理部分主要針對企業會員用戶進行資金管理,提高每次訂單的交易效 率,簡化資金流動環節。這部分業務主要包括充值服務、充值查詢、扣費服務、 賬號余額查詢等。
    8、 系統管理
    系統管理部分主要實現賬戶管理、角色權限管理、日志管理、備份管理等功 能,主要為系統提供輔助保障服務。
    2.2 技術選型
    2.2.1 系統軟件體系結構
    1、B/S 模式
    B/S 體系結構也就是瀏覽器/服務端結構,是目前被使用最多的一種結構,其 核心業務只要集中在服務端,用戶只需要通過瀏覽器訪問就可以了,其具體體系 如下圖2-1 所示:
     
    圖 2-1 B/S 體系結構圖
     
    B/S 模式體系結構可以分為三層。第一層是表現層,主要表現為用戶通過瀏覽 器與后臺服務器之間進行交互,用戶通過在瀏覽器界面上輸入相關信息然后進行 查詢,瀏覽器返回相關結果。第二層是 WEB 服務器和應用服務器層,這一層主要 完成相關業務邏輯。第三層是數據層,這一層主要完成數據的存儲與訪問[27,28]。
    總結而言,B/S模式有優點又有許多缺點,優點主要有:B/S模式具有分布式 的特點,可以隨時進行查詢等操作;開發簡便,共享性較高;通用性和跨平臺性 好;開發集中在服務端,因此開發成本低,節約時間;維護簡單,更新方便。缺 點主要有:由于所有用戶的客戶端通過瀏覽器訪問,個性化降低;基于瀏覽器進 行訪問,開發時需要考慮不同瀏覽器的兼容性;查詢實時性差,需要依賴網絡環 境,安全控制性差。
    2、C/S 模式
    目前 C/S 體系中應用較多的是三層 C/S 體系結構,它是在兩層 C/S 體系結構 中發展起來的,它解決了兩層 C/S 體系的局限性,由用戶界面層,應用服務器層 和數據庫服務器層組成,各個部分獨自完成相應功能。其具體體系結構圖如下圖 2-2 所示:
     
    客戶機
    圖 2-2 C/S 體系結構圖
     
    客戶機是系統的入口,用戶通過客戶機直接完成與應用服務器的交互,這一 點與兩層 C/S 架構不同,在以前的兩層 C/S 架構中,客戶端直接與數據庫服務器 交互,接受用戶的輸入請求并將結果直接反饋給用戶[29-31]。與兩層C/S架構相比, 三層 C/S 結構更加清晰,并且客戶端界面修改更加簡單。在三層 C/S 架構中,應 用服務器是整個業務邏輯處理的核心,具體的業務實現就是在這一層開始實現的, 同時這一層也被稱為中間層,它是連接客戶端與數據庫的橋梁,客戶端的請求經 過應用服務器處理后再發送給數據庫服務器。數據庫服務器主要用于處理與數據 相關的請求[31-33]。
    總結而言,三層 C/S 結構有缺點也有優點,優點主要有:與 B/S 結構模式中 的傳輸協議相比,優點是B/S模式中傳輸協議只能依賴于HTTP協議,而C/S結 構中可以自定義相應的傳輸協議。缺點主要有:每臺機器上都要安裝客戶端,分 布式和兼容性較差;需要針對性的開發,系統不夠靈活,所以擴展性較差。
    3、比較與選擇
    本系統在開發過程中,選擇何種結構時,重點考慮系統的開發效率、可擴展 性、后期維護成本以及用戶的體驗感等因素。根據具體業務的需求,本系統需要 達到用戶隨時通過瀏覽器對系統中相關信息進行查詢的功能, B/S 結構具有分布式 的特點,可以隨時進行相關業務的查詢,而C/S結構需要安裝相應地客戶端程序, 難以滿足要求。考慮到系統后期的業務可能還會有擴展, C/S 模式的系統在擴展時 需要做出大量地修改,而 B/S 模式業務擴展方便,增加相關頁面就可以達到目的。 并且 B/S 模式的體系結構后期維護成本低,開發簡單,易于共享,因此本系統在 開發時選用 B/S 模式進行開發。
    2.2.2 系統硬件體系結構
    1、RFID 技術
    RFID 又稱無線射頻識別技術,是一種目前常用的無線通訊技術,它主要通過 無線電通信的方式來獲取數據,而不需要與獲取目標進行機械接觸,通過讀寫器 對一定范圍的電子標簽內的信息進行存儲[34]°rfid技術與傳統的條形碼技術相比 有很多優勢,讀取標簽時不需要直接接觸,可以讀取一定范圍內的信息,甚至可 以一次讀取多條信息,可以應用在多個場景[35]。例如我們乘車的公交卡和地鐵卡, 學校常用的學生卡等都是RFID的應用。
    (1) RFID 電子標簽
    RFID 電子標簽又稱為應答器,將物體的相關信息存儲在標簽中。根據結構可 以分為主動式和被動式兩種,主動式帶有電池,可以主動按照一定的頻率向外發 送信號;被動式則通過天線接收外來信號[36]。電子標簽的數據存儲一般分為兩部 分,一部分為唯一編號,不可更改;另一部分為可讀寫數據,用來存儲物品信息。
    (2) RFID 讀寫器
    讀寫器主要用來對電子標簽內的信息進行讀寫,起到連接應用系統與電子標 簽的作用。讀寫器一般分為硬件部分和軟件部分,硬件部分一般由高頻接口和發 射天線組成;軟件部分一般由導入軟件和控制軟件組成[37]。
    (3) 天線
    天線是電子標簽和讀書器都必備的設備,起到連接橋梁的作用,建立了電子 標簽和讀寫器之間的連接[38]。讀寫器通過天線發送信號,電子標簽通過天線發出 應答信號。
    2、嵌入式技術
    嵌入式系統主要是用于監視、控制或者輔助操作設備和機器的裝置[39]。在生 活中,帶有數字接口的很多設備都在使用嵌入式系統,隨著物聯網技術的發展, 嵌入式系統利用自身的優勢,與傳感器設備完美結合,擴展了物聯網的支持能力, 已經被廣泛應用于汽車、電子、醫療、物流等行業。嵌入式設備與傳統設備相比 具有很大的優勢,它具有一個微處理器可以移植嵌入式操作系統,進行較復雜的 運算和處理;它還有豐富的接口,可以與各類傳感器設備、GPS設備等連接,提 高了擴展性;同時它還可以與觸摸屏等電子顯示設備連接,提供可視化的界面, 用戶體驗更好[40]。
    本系統的硬件部分采用基于嵌入式系統的 RFID 手持設備方案,以 ARM9 (S3C2440)微處理器為主控制器,根據系統需求擴展了 Flash、SRAM、觸摸屏、 GPRS、WiFi、GPS、RS232串口、RS485串口等模塊,在該平臺上搭建了 Linux 系統,并利用 QT 進行圖形界面開發。
    2.2.3 開發技術選型
    當前國內外關于信息管理系統的開發技術種類眾多,但是比較主流的還是以 JAVA 為主要開發語言,本系統的開發采用以 J2EE 為主要開發平臺,具體技術框 架采用 Spring+SpringMVC+Mybatis 的技術組合,服務端選用 Tomcat 作為服務器, 使用 Eclipse 作為開發工具進行開發,并且使用 JSP、HTML 技術作為頁面進行實 現和展示。
    1、 技術平臺選型
    目前比較流行和成熟的開發方式是以互聯網技術為核心的系統開發方式,然 后以 JavaBeans、Servlet 等為主要技術的 J2EE 平臺,這種模式為保證開發的穩定 性和擴展性提供了基礎。J2EE體系結構可以分為四層結構,分別為客戶層、表示 層、業務邏輯層和企業信息系統層[41]。 J2EE 平臺的體系結構如下圖 2-3 所示:
     
    圖 2-3 J2EE 平臺體系結構
     
    在四層體系結構中,將系統中的各層結構進行了分離,有利于系統后期的拓 展。同時利用軟硬件技術,增強了系統的集群功能,提高了系統的性能。因此在 系統的技術選型時我們選擇 J2EE 作為主要開發技術,充分利用該技術在擴展性、 成熟性和跨平臺性等特點。
     
    J2EE體系結構中各類信息如下表2-1所示:
    表 2-1 體系結構中各層相關信息
    結構 主要功能 涉及技術 環境
    客戶層 用戶操作 Applet、 Swing、 HTML、
    XML等 支持JavaWeb的
    瀏覽器
    表示層 緩存、代理作用 Servlet、 JavaBean、 JSP、
    Ajax、jQuery 等 支持相關技術的 服務器
    業務邏輯層 通過相應的技術進行封
    裝,實現數據庫的存取 Spring、 Struts、
    SpringMVC、 MyBatis、
    Hibernate 等 支持相關平臺的 服務器
    企業信息層 對數據的操作 增刪改查、存儲過程、 索引等 面向對象和關系 數據庫
    J2EE 平臺是 Java2 的企業版,它是一種完全不同于傳統技術的技術架構,它 的核心其實是一組標準的規范,提供了基于組件的方式來幫助我們對系統進行開 發、設計、組裝和部署,進而提高系統的可移植性和兼容性[42]。根據以上的分析 和實際開發過程中的經驗,本系統從J2EE體系中選用的技術如下表2-2所示:
     
     
    表 2-2 主要開發技術
    類別 名稱 功能
    開發語言 Java8 JDK1.8,包含新特性
    開發工具 Eclipse Mars 代碼編寫
    版本控制 SVN 軟件版本控制
    頁面設計 HTML、JSP、jQuery、Ajax、 JavaScript、CSS 等 設計操作界面,美化界面,頁面個性化設
    置,保證界面美觀實用
    主流技術 數據持久化技術、Web、
    XML、 Spring、 SpringMVC、
    MyBatis 等 選用J2EE中主流技術,完成系統各項業
    務邏輯,保證系統高效運行,提高系統擴
    展性,提升用戶體驗感
     
    2、應用服務器選型
    本文中所描述的氣瓶配送及其信息管理系統在開發過程中所采用的是 B/S 架 構,由于各類服務器應用領域和技術特長都不一樣,因此服務器的選型將嚴重影 響系統的性能。
    由于需要設計的氣瓶配送及其信息管理系統需求多樣,對平臺的要求也多樣 化,并且考慮到平臺的移植性,最終選用J2EE作為主要開發平臺,因此在對服務 器進行選擇時參照以下標準來執行:
    (1)操作系統:關于服務器的選擇,選擇合適的操作系統也很關鍵,一般情
    況下系統都不會直接部署在Windows下,目前系統部署在Linux下較多。
    (2) 開發技術:一般使用.NET進行開發時選用IIS服務器,而使用Java語 言進行開發時一般選用 Tomcat 服務器。
    (3) 穩定性和安全性:如果重點考慮系統的穩定性和安全性,盡量選擇有較 好的技術支持,非開源的服務器。
    本系統考慮到實際情況,根據J2EE平臺的兼容性,操作系統的穩定性,目前 主流服務器的使用情況,以及服務器的技術支撐等情況,系統在開發時選用 Tomcat 作為應用程序服務器。如果后期根據業務調整的需要,也可以考慮其它類型的服 務器,系統在其它方面設計時會考慮到后期更換服務器的可能,會有保證代碼平 滑過渡的措施。
    3、數據庫選型 數據庫技術是現在信息處理技術的核心,它是一門專門用于研究數據的管理、 存儲、應用的一門科學,具體功能包括利用數據庫的常見功能和常見技術手段對 數據進行統一管理從而實現對系統數據的增加、刪除、修改、查詢以及簡單數據 分析等功能。隨著數據量的逐漸增大和大數據處理技術的需要,數據庫技術越來 越被重視。考慮到氣瓶配送及其信息管理系統需要存儲大量的數據,如氣瓶數據、 訂單信息等,因此數據庫的選型對系統的性能影響也很大。目前主流的數據庫有: Oracle、MySQL、SQLServer、DB2 等。
    (1) MySQL數據庫:MySQL數據庫是目前最受歡迎的開源數據庫之一,當 前多家大型互聯網公司都是采用的MySQL數據庫。它是一個關系型數據庫,同時 它是開源的,有大量的相關軟件可以對它進行開發,因為它性能良好、操作方便、 平臺兼容性好、安全可靠和易于使用等優良性能,目前使用量很大,所以該數據 庫的技術支撐也較好[43]。
    (2) Oracle 數據庫: Oracle 數據庫是甲骨文公司開發的一款大型數據庫,由 于在開發過程中該公司投入了大量的人力物力,所以該數據庫也是一款付費的數 據庫。Oracle數據庫的兼容性、可移植性、可聯結性都較好,但是由于該數據庫定 位為大型數據庫,軟件本身較大,對硬件要求較高[44]。
    (3) SQL Server數據庫:SQL Server數據庫是由微軟公司開發的一款數據庫, 也是比較流行的一款用于存儲的數據庫,它目前廣泛應用于各個領域。這款數據 庫對電子商務和 Web 支持較好,具有訪問靈活、易于操作、操作界面友好等優點, 但是SQL Server數據庫只能部署在Windows環境下,因此對操作系統的要求很高, 并且處理數據能力有限,隨著用戶數和數據量增加,伸縮性有限[45]。
    (4)DB2數據庫:DB2數據庫是一種由硬件支持,內嵌在IBM系統上的數 據庫,它支持標準的SQL語言。它具有速度快、可靠性高、高性能等優點,DB2 數據庫適用于所有主流平臺,適合海量數據處理的數據庫。但是 DB2 數據庫對硬 件平臺的要求高,只有 IBM 的硬件平臺才可以使用,這也成為它發展的一個瓶頸。
    根據企業的業務需要,從數據規模、開發成本、數據庫的可靠性以及數據庫 的技術支撐等方面考慮,本系統在開發時選用MySQL數據庫。其優點如下:MySQL 數據庫采用C和C++語言進行編寫,可以保證系統的較好的移植性;同時它也支 持多種操作系統,對平臺的要求低;支持多線程編程,CPU利用率高;對于SQL 的查詢效率較高,提供多語言支持;MySQL數據庫是開源數據庫,在滿足開發需 要的情況下節約開發成本。綜合考慮以上情況,在數據庫選型時最終確定MySQL 數據庫為本系統的數據庫。
    4、開發工具選型
    目前存在多種 J ava 編譯器,常見的有 Eclipse、MyEclipse、JBuilder、JDK、NetBases 等,其中JDK是初學者時用的,使用起來比較麻煩,它是java的底層工具。JBuilder 主要用于開發Web應用程序,之前流行過,但是近些年來使用者不多。MyEclipse 使用者也比較多,它包括了 Eclipse,并且它還自帶常見框架,比如:Hibernate、 Struts、Spring等,功能強大,所以它的使用者很多,但是它是收費的,并且較Eclipse 軟件較大,占用內存大。目前最流行的Java編譯器是Eclipse,因為它是免費的, 開源的。Eclipse與MyEclipse相比,運行速度快,占用內存少,雖然軟件本身不 帶一些插件,但是裝插件也很簡單,其它功能與MyEclipse相比沒有很大的差別。
    本系統根據業務需要,根據使用方便和高效率原則,在開發時最終選用開源 免費的 Eclipse 軟件,由于本系統開發人員使用時習慣使用 Eclipse 軟件,并且 Eclipse軟件完全可以滿足系統開發需要,同時Eclipse軟件也是開源免費的,節約 成本,相關技術資料齊全,查閱資料方便,所以在使用時選擇Eclipse o
    2.3 系統總體設計
    2.3.1 系統開發環境
    本系統選用Java作為主要開發語言,版本為JDK8,應用服務器選用Tomcat8, 選用MySql5.7數據庫作為存儲工具對數據進行存儲,采用Eclipse作為開發工具, 選擇Shiro技術進行權限管理,采用Maven對項目進行管理。后臺系統主要結構 采用 MVC (Model View Controller)架構,利用 Spring> SpringMVC、Mybatis 等 開源框架技術,在開發過程中充分利用MVC分層設計的思想,完成后臺系統的搭
    建;前端系統主要采用開源框架Bootstrap,并配合JavaScript、JQuery等前端技術 完成前端系統搭建。
    2.3.2 系統物理結構設計
    物理架構描述了系統在最終完成測試后進行部署的時候與企業當前網絡之間
    的關系。該系統涉及到的物理設備有服務器、電話、物理隔離設備、防火墻、手
    持設備、配送車輛車載設備以及各個用戶終端等。下圖 2-4 所示為物理結構圖。
     
    氣瓶配送及其信息管理系統集中部署于企業總部,通過注冊一個專用域名,
    企業內部員工可以通過內網進行訪問,而企業客戶和普通用戶可以通過互聯網進 行訪問。系統集中部署具有以下優點:
    部署快速方便:這種部署方式只需要在固定一個地方進行部署,其他地方通 過瀏覽器訪問就可以了,方便快捷。
    信息共享集中:由于公司的氣瓶管理統一在一起,信息共享集中,各種文檔 和銷售庫存信息等查閱方便,通過權限管理的方式可以控制不同用戶查閱不同信 息,公司信息共享有利于提高管理效率。
    維護方便:系統只部署在一個地方,方便維護,出現問題時只需要一個地方 維護所有問題都可以解決。
    下面分別介紹服務器和網絡的相關配置。
    (1)服務器:數據庫服務器主要部署 MySQL 數據庫,實現對數據的存儲; 應用服務器主要部署Java虛擬機和Tomcat等環境支持軟件,以及代碼的部署等。 同時還應有文件服務用于專用文檔資料的處理。
    (2)網絡:為了增加系統的安全性,可以在系統中加入防火墻等安全保護措
    施,對網絡的訪問進行監管。企業的內網進行訪問一般不會出現很大的問題,外 網進行訪問時可以根據訪問量適量調整帶寬。
    2.3.3 系統應用功能設計
    氣瓶配送及其信息管理系統主要由采購業務員、采購管理員、充裝人員、檢 驗人員、銷售人員、主管領導、普通用戶、企業客戶等用戶組成。同時在對系統 的功能進行規劃時,在保證各項業務專業的情況下,充分考慮了不同用戶的使用 習慣,盡量開發出符合用戶習慣的系統,保證界面友好。下圖2-5所示為氣瓶配送 及其信息管理系統的應用功能設計圖:
     
    圖 2-5 系統應用功能設計圖
    從該圖來看,氣瓶配送及其信息管理系統可以分為以下幾個部分:
    手持設備應用部分:該部分的主要功能是對手持設備進行管理,手持設備主 要完成入庫、庫存、銷售、配送、加氣、檢驗等環節對氣瓶的掃描并記錄相應信 息的工作。
    主要業務部分:為了對氣瓶相關業務實現自動化和智能化的管理,本系統根 據具體業務將系統大致分為采購庫存、氣瓶管理、銷售管理、用戶設備、加氣管 理、充值管理等部分。
    接口服務管理:為主要業務的實現提供相應的接口,這里的接口主要分為地 圖接口、手持終端接口和短信接口三部分。
    基礎平臺部分:這部分主要是非主要業務的輔助性功能,為系統提供報表、 權限管理、日志管理、備份管理以及打印服務和短信服務,為系統的主要業務的 開發提供便利。
    體系部分:這部分主要是為系統提供完備的安全保障體系和運行維護體系, 保證系統運行穩定。
    2.3.4 系統集成設計
    氣瓶配送及其信息管理系統涉及的業務復雜,需要和多個不同的終端設備之 間進行數據交互,因此在進行系統整體設計的時候需要對系統進行集成,綜合系 統中需要的接口和各個平臺等,涉及到的傳輸方式有短信、郵件、互聯網、無線 網絡和通信線路等,具體的集成關系圖如下圖 2-6 所示:
     
     
    (1)車載GPS:單向通信,車載GPS不斷向系統發送配送車輛的位置信息, 以便實現氣瓶的追蹤。
    (2)手持設備:雙向通信,手持設備將采集的數據傳輸給系統,系統將業務 處理的數據發送給手持設備。
    (3) 銷售電話:單向通信,銷售人員接到訂單后會將信息會被錄入系統,在 公司內部網絡中完成。
    (4) 地圖服務系統:雙向通信,系統將得到的經緯度信息在地圖系統顯示, 也可以從地圖系統獲取經緯度信息。
    (5) 短信、郵件:單向通信,系統通過相關接口向指定號碼或者郵箱發送短 信或者郵件,短信通過專用網絡完成,郵件通過互聯網完成。
    (6) 網站:雙向通信,系統中的公司主頁網站向外界展示公司信息,同時用 戶也可以在公司網站留言,通過互聯網完成雙向通信。
    2.4 本章小結
    本章主要闡述了如何保證氣瓶配送及其信息管理系統設計和開發的系統功能 完善、系統可靠、運行穩定、性能良好以及后期維護方便等,系統在開發設計過 程中必須要遵循的一些原則。另外,本章還對相關技術選型進行了說明,具體包 括:選用了 B/S模式系統結構,方便用戶隨時查詢系統;選擇了 J2EE平臺,采用 主流技術框架,保證良好技術支持;使用Tomcat作為應用服務器,保證系統兼容 性以及性能可靠;以及選用MySQL數據庫,確保系統穩定;采用Eclipse軟件進 行代碼編譯。最后,對系統的功能實現分別以物理結構、應用功能和系統集成三 部分進行了總體設計。
    第三章 配送路徑優化
    本章主要對該系統配送功能的實現進行詳細介紹,該部分為系統銷售配送模 塊的一部分。首先介紹配送問題的基本原理,對相關基礎理論進行介紹;然后為 氣瓶配送建立了數學模型,并設計了相應的約束條件;接著對配送問題的算法進 行了設計,針對標準算法的缺陷提出了改進方法,并結合實際需求設計了基于聚 類的遺傳禁忌混合算法;最后對氣瓶配送路徑進行了 Matlab分析,并實際驗證。
    3.1配送問題基本原理
    3.1.1 配送問題描述
    配送車輛路徑問題(VRPTW)是指為了達到一定的配送目標(例如總里程最 短、總成本最小、總時間最短等),在不同的約束條件(例如運輸車輛最大載重量 限制、運輸車輛最遠行駛距離限制、送達最早時間、送達最晚時間、氣瓶種類要 求、次數限制等)下,對于有不同種類和數量的特定客戶需求,合理安排車輛進 行配送,滿足客戶要求[46]。實際上配送問題是一個N-P難題,是在實際生活中常 見的一個組合優化問題。根據國內外經驗,配送路徑問題與背包問題、旅行商(TSP) 問題等有著密切的聯系,TSP問題實際上是配送路徑問題的特殊情況[47]o因此, 配送路徑問題相對于傳統的旅行商問題更加復雜,特別是有時間窗口限制的配送 路徑問題,對于解決實際問題更有意義。
    3.1.2 配送問題構成要素
    配送路徑模塊是該系統的一個重點和難點,其難點主要體現在根據客戶要求 的配送地點和配送時間進行配送路徑的選擇和優化,一般路徑規劃問題由配送中 心、車輛、貨物、顧客、目標函數和約束條件等要素構成。
    (1)配送中心:配送中心主要是指加氣站的氣瓶倉庫,負責整個配送環節 的調度,是每輛配送車的起點也是終點。
    (2)車輛:車輛主要是配送氣瓶的車輛,包括車型、最大載重量、最遠行 駛距離、數量等。
    (3)貨物:貨物主要為氣瓶,氣瓶的種類有液化石油氣、氧氣、氮氣、二 氧化碳、氬氣、乙炔等。它是配送服務的主要對象,在氣瓶配送問題 上,一般既需要配送又需要收集氣瓶。
    (4)目標函數:目標函數分為配送成本最低、配送總行程最短等麗。
    (5)客戶:客戶分為民用和工業兩部分,民用部分需求主要為液化石油氣, 工業部分主要為工業用氣需求。客戶一般具有需求量和配送時間等要 求,其中按照要求一般有軟時間窗和硬時間窗兩種,其中要求氣瓶盡 量在規定時間內送達,提前或者滯后都會有一定的懲罰系數,這種方 式叫做軟時間窗,懲罰系數根據提前或者滯后時間確定。硬時間窗是 指氣瓶未在指定時間段內送達則用戶不接收貨物[49]。
    (6)約束條件:這些限制包括氣瓶的總數,它不超過每輛車某種氣瓶的最 大可載數量,不能混合運輸的氣瓶不能一起配送,單條路線總長度不 能超過車輛行駛最遠距離,滿足每個客戶的氣瓶需求、交貨時間和數 量要求,每個客戶的一種氣瓶需求只能一次送達。
    3.1.3 配送問題優化目標
    配送路徑優化的目標是在達到一定條件的情況下,盡量減少配送成本。實際 上配送成本有以下三種表現形式,即最小配送距離、最小時間成本、最小車輛數[50]。 本設計通過對這三部分成本系數的不同取值,可以實現目標函數,并建立相應的 數學模型。這三部分優化目標如下所示:
    (1)最小配送距離 在氣瓶的配送服務中,配送的單位距離運輸成本可知,配送距離越短,
    配送運輸成本越低,通過合理配置資源,可以更為有效的控制配送成本,以 獲取更多利益,實現企業經營降本增收。
    (2)最小時間成本
    本設計結合加氣站的氣瓶配送情況,將配送準時率轉換為偏離時間窗口 的懲罰系數,且作為目標函數組成中的一項,以此來提高配送準時率,提升 服務質量,為企業打造良好的企業形象。
    (3)最小車輛數 由于每輛配送車輛需要消耗一定的固定派送成本,派送車輛越少,車輛
    固定成本越少。通過減少派送車輛可以在一定程度上減少總運輸成本,從而 達到降低配送成本的目的。
    本設計將根據以上三種配送成本綜合考慮,構建以總配送成本最小為目標函 數的數學模型。若只選擇以上三種的一種作為目標函數,都會影響其他優化目標。 若以最小配送距離為目標,運輸成本最低,但是會忽略客戶對配送時間的要求, 經常不在服務時間內配送,影響企業信譽,反而會影響企業后期利益;若以時間 懲罰窗口成本最小為目標函數,在配送時優先考慮顧客的配送服務時間,往往會 增加配送總里程或者安排更多配送車輛。因此,犧牲運輸成本來換取配送準時率, 最終導致企業經營成本增加;若以最小車輛數為目標函數,則時間成本和運輸成 本都會增加,既降低了配送準時率,又導致運輸成本增加,導致配送服務達不到 最好效果。
    綜上所述,本系統配送模塊設計時建立以最小總配送成本為目標函數的數學 模型,平衡最小配送距離、最小時間成本、最小車輛數之間的關系。通過合理考 慮配送準時率和配送成本之間的關系,最終達到配送總成本最低的目的。
    3.2 聚類分析
    3.2.1 訂單聚類
    (1)聚類 氣瓶配送問題具有很明顯的時空分布特性,首先,每個客戶點都有具體的地 理位置坐標,因此氣瓶配送問題具有空間分布特性;而每個客戶都有要求配送的 時間窗{e,,li},因此氣瓶配送具有時間分布特性;除此之外,不同客戶對氣瓶的需 求不同,相同種類的氣瓶盡量同車運輸。圖3-1用三維空間坐標系表示了氣瓶配送 的時間、空間以及配送項目特性,圖中x、y分別表示客戶點的經緯度坐標;t表 示氣瓶配送的時間特性。A、B、C、D、E分別表示客戶點的位置,O表示加氣站, 每個配送點的時間、空間和配送項目特性都有區別。訂單屬性圖如下圖3-1所示。
     
    在對氣瓶的配送路徑進行規劃前,先對氣瓶的配送訂單進行聚類,根據氣瓶 配送問題的空間、時間以及配送項目三個特性進行聚類。將配送位置相近、配送 時間相似和配送項目相似的氣瓶配送訂單盡量安排在同一輛車的同一條配送線路 中進行配送,這樣能在一定程度上減少成本,提高氣瓶配送效率。傳統的配送路 徑規劃一般僅考慮空間特性對配送成本的影響,本系統在設計時同時考慮了空間、 時間以及配送項目特性,先將這三個特性根據訂單進行聚類,產生訂單鄰域系統, 將產生的初始聚類訂單作為算法的初始解,再結合遺傳禁忌算法進行路徑規劃, 這種方式有利于提高尋得最優解的概率,減少算法迭代次數,最終得到較好的規 劃效果。聚類后訂單如下圖 3-2 所示。
     
     
    (2)時空距離度量
    時間、空間是氣瓶配送問題的兩個不同特性,雖然二者之間有區別,但是也 存在較相近的聯系。在三維坐標系中,我們可以用一個具體的表達式來表示各個 客戶之間的鄰近關系,也就是客戶點的時空距離。在氣瓶的配送問題上,兩點之 間的時空距離越近,表示越可能被安排在同一條路線中進行配送。合理定義客戶 點之間的時空距離是構造鄰域系統的關鍵,對氣瓶配送的后期路線規劃起到決定 作用。考慮到時間和空間屬性的不一致性,本系統先將時間屬性和空間屬性進行 歸一化處理,然后分別賦予權值,得到兩個客戶點之間的時空距離公式,本文提 出的時空距離公式如下:
    DS = w1 Ds + w2 Dt (3-1)
     
    式(3-1)中:DS為客戶點i與客戶點j之間的空間距離;DT為客戶點之間的 時間距離;其中w1 > 0,w2 > 0,w1 + w2 = 1 ; DS可以直接通過計算訂單空間位置 間的距離獲得,Dt時間距離通過百度地圖的開源API獲取。
    (3)訂單配送項目相似度 每個客戶的氣瓶配送需求可能不止一種氣瓶,同時加氣站的氣瓶配送車輛也 有多種,每種車型的不同種類的氣瓶裝載數量不一樣。設置氣瓶配送項目相似度 的關鍵是為了保證配送安全,有的氣瓶不同同車配送。所以,配送項目相似度實 際上就是確定配送的氣瓶是否具有同車配送的可能性。根據實際情況,配送項目 相似度大致可以分為三種情況,第一種:相同種類的氣瓶;第二種:不同種類的 氣瓶但是可以同車配送;第三種:不同種類的氣瓶,不能同車配送。第一種與第 二種情況氣瓶可以同車配送,顯然配送項目相似度可以設定為1,第三種情況配送 項目相似度設為0o
    本系統在設計時考慮到氣瓶配送的特殊性,同時考慮了氣瓶種類和氣瓶配送 車輛車型兩個約束條件,設定的配送項目相似度公式為:
    其他
    由式(3-2)可以看出, 的數量和氣瓶種類可以達到配送要求,就可以把配送項目相似度設為1;對于配送 的氣瓶不能同車運輸或者超過氣瓶配送車輛的裝載量時,就可以把配送項目的相 似度設為0由式(3-1)可知這樣的配送需求時空距離為無限大。
    3.2.2 訂單鄰域系統
    在對氣瓶配送問題建立了時間、空間以及配送項目相似度的概念后,又提出 了時空距離度量和配送項目相似度的公式。將時空距離相近或者配送項目相似度 一致的氣瓶安排在同一輛氣瓶配送車同一路線中進行配送,能夠提高氣瓶配送效 率,減少配送成本;反之,若相似度為 0 的氣瓶配送訂單被安排一起配送,則得 到的路徑規劃不符合要求;將配送距離較遠,配送時間不一致的訂單安排同一輛 車進行配送,則會增加配送成本,甚至可能產生不可行解。因此,本文提出了氣 瓶配送訂單鄰域系統的概念。
    首先,分別定義時間鄰域NT、空間鄰域N^.和配送項目鄰域NC,如式(3-3)、 式(3-4)和式(3-5)所示,其中0為所有氣瓶配送訂單的集合。
    ={ jlj e Q-{i} Qt (i j)< Tmax} (3-3)
     
    NSj ={jU e Od -,Od( i J )< Dmax}
    NC ={jU e Oc -{/}, Cj = 1} (3-5)
    在完成以上式(3-3)、式(3-4)和式(3-5)定義后,設計訂單鄰域系統 D 的 定義公式為:
    Dj ={/, j | i, j e NJ j e N^i, j e NC^, Dt] < Dmax, Tt] < ?_,j e D -{/}} (3-6)
    式(3-6)中Dj < Dmax表示配送距離Dj小于距離閾值Dmax,T< g表示配送 時間T小于時間閾值Tmax。由式(3-6)可以看出,綜合考慮訂單的時間特性、空 間特性和配送項目相似度特性,將配送項目相似度為 1 的訂單,以及時間鄰域和 空間鄰域相關的訂單組成訂單鄰域系統,在進行路徑規劃時,位于同一訂單鄰域 系統的訂單被安排一起配送的可能性較大。
    3.3配送問題數學模型
    3.3.1 VRP 模型
    傳統VRP問題在加氣站中應用的數學模型可以描述為:氣瓶配送車輛k從加 氣站出發向用戶i配送氣瓶,每個客戶經過一次,最終回到加氣站,形成一個循環 回路,保證所經過的路線的總長度Z最短。設加氣站的配送車輛有K臺,配送車k 固定派送成本為vk,vk e R ;氣瓶配送車輛k單位時間內的運輸成本hk,hk e R ; 配送車輛出發一次能夠承載的最大氣瓶數量為Qk,配送車輛出發一次能夠行駛的 最遠距離為Dk,需要配送的客戶數量為L,每個客戶的氣瓶需求量為q’,客戶i到 客戶j之間的距離為d,加氣站到各客戶點的距離為d°j,設珥為第K輛氣瓶運輸 車的客戶數量(nk = 0表示該氣瓶運輸車未被使用),集合Rk表示第K條氣瓶配送 路線,其中Rk表示該客戶點在氣瓶配送路線K中的序號為i,加氣站用Rko = 0表 示,若以氣瓶配送路線總長度的最小值為目標函數,建立氣瓶配送路線問題的模 型如下所示:
    目標函數為式(3-7),即要求各條配送路徑之和最短;
    K
    minZ =工
    k=1
    式(3-8)保證每條路線上所有配送點要求配送的氣瓶 總數不 能超過 配送車出 發一次所承載的最大氣瓶數量;
    nk
    工q VQk (3-8)
    i=1
     
    式(3-9)保證規劃出的每條線路里程的總和不能達到運輸車輛出發一次的里 程限制;
    nk
    工 dij + dj •如(nk ) V Dk ( 3-9)
    i=1
    式(3-10)表明每條配送路線上的配送客戶數量小于總的氣瓶配送客戶數;
    0 V nk V L
    式(3-11)保證每個客戶的配送需求必須滿足;
    Rk ={Rki |Rki e{1,2,...,L},i =1,2,...,nk}
    式(3-12)表示每條路徑的客戶組成;
    K
    亍 nk = L
    k=1
    式(3-13)保證每個客戶的訂單需求只由一輛配送車輛送達
    Rk1 cRk2=0,Pk\ 豐 k2 (3-13)
    式(3-14)表示當第k輛氣瓶配送車所送達的客戶數量習時,說明該氣瓶運 輸車參加了氣瓶配送任務,則取sign(nk) = 1,當第k輛氣瓶配送車送達的客戶數 <1時,,表示未使用該氣瓶運輸車,則取sign(nk) = 0。
     
     
     
    VRP 問題路線示意圖如下圖 3-3 所示。
     
    3.3.2 VRPTW 模型
    VRPTW問題在加氣站中應用的數學模型可以描述為:設節點集合為N , N = {n|n = 0,1,…,|N|},0表示配送中心,1,2,…,N為客戶編號;兩節點的運輸時間 為t,i, j e N ,(ty. = j ;配送車輛數為K,K = {k|k = 0,1,…,|K |},配送車k固定派 送成本為Vk,vk e R+ ;配送車輛k最大行駛時間為Tk ;氣瓶配送種類集合為P, P = { p|p = 0丄…,|P |};氣瓶配送車輛k單位時間內的運輸成本hk,hk e R+ ;配送 車輛k第p種氣瓶的最大載重氣瓶數量為QP,p e P ;用戶i對第p種氣瓶的需求 量為qp ;用戶i的配送時間窗為{et,l};配送車輛k到達用戶i的時間為心;時間等 待成本為W1 ;時間延遲成本為W2 ;若配送車輛k經過線段(i, j)則%k取值為1,否 則取值為0;若用戶i的氣瓶配送需求p由車輛k配送,則yipk取值為1,否則yipk 取值為 0。
    若以配送總成本的最小值為目標函數,建立配送路徑問題的數學模型如下所 示:
    Min 工 Xjktjhk + w 工叫kmax (e. - tki ,0) + w2 工 Xjkmax(tu - 3)+ 工 Wk(3-15)
    (i, j,k) (i, j,k) (i, j,k) (i=0, j,k)
    式(3-15)為目標函數,即配送總成本最小值,包括運輸車輛成本、時間懲罰 成本和固定派送成本;
    工 yipkqp VQK,vkeK,pep (3-16)
    ieN \{0}
    工工 j V Tk,Fk e K (3-17)
    i e N j e N
    式(3-16)(3-17)表示氣瓶配送車所載氣瓶數量最大值和最長配送時間約束 條件;
    工ytpk =1, Vi e N\{0},p e P (3-18)
    keK
    式(3-18)表示任一用戶的同一種氣瓶需求只能由一輛車進行配送,即用戶的 需求不能拆分配送;
    Dj 乞 y’pkNj e N\{°},k e K,p e P (3-19)
    ieN
    式(3-19)表示當弧(i, j)這條線路可以行駛時,才可以對用戶j進行配送服務; 工Xj =工 j,Fj e N\ {0},k e K (3-20)
    ieN ieN
    式( 3-20)表示一條線路配送車輛進出次數一致;
    Xjk + Xjk V1, Vi G N\{0}, j G N\{0},k g K (3-21)
    式(3-21)表示每條線路不能有子回路;
    工 x0jk =工 x0ik =1,VkGK (3-22)
    jGN \{0} iGN \{0}
    式( 3-22)表示氣瓶配送車輛從加氣站出發進行配送業務,氣瓶配送完成后最
    終都返回加氣站;
    toki = tok(i-1)+ ti(i-1),Vk G K, iG N\{0} (3-23)
    式( 3-23)表示每輛配送車輛到達用戶的時間;
    xijk (1- xijk ) = 0,Vi G N, j G N, k G K ( 3-24)
    式(3-24 )表示車輛k經過路線(i,j)時的取值為1;
    yipk (1- yipk ) = 0,Vi G N, p G P,k G K ( 3-25)
    式(3-25)表示用戶i•的配送需求由車輛k配送則取值為1;
    工工 Xjk =1, Vj g N\ {0} (3-26)
    kGK iGN \{0}
    式( 3-26)表示對用戶 i 的同一種氣瓶配送只進行一次;
    工 y’pk =|P l,Vi g N \ {0}, 3k g K (3-27)
    pGP
    式( 3-27)表示所有用戶的配送氣瓶種類數為 P 。
    VRPTW 配送模型圖如下圖 3-4 所示。
     
    3.4 算法設計
    對于配送路徑優化常見的算法主要分為精確算法和啟發式算法,其中前者主 要有標號法、整數規劃算法等,精確式算法一般是針對局部和小規模的路徑規劃。 啟發式算法分為早期和現代啟發式算法,早期的啟發式算法主要指:節約法、掃 描法、插入法和最近鄰法等;現代啟發算法指:遺傳算法、禁忌搜索算法、模擬 退火算法、粒子群算法和蟻群算法等。啟發式算法對于大規模的路徑規劃應用較 多,同時也能在較短時間內找到最優解。
    由于精確算法目前還無法有效解決 N-P 問題,同時在數量增長后計算能力有 限,而啟發式算法在解決配送路徑問題時可以很快找到最優解,所以目前被大量 應用于配送路徑規劃中。本系統在設計時根據氣瓶配送的實際情況,再結合上述 啟發式算法的特點和實際運用效果,在算法設計上采用組合算法的方式來彌補單 一算法帶來的缺陷。
    3.4.1 遺傳算法
    遺傳算法(GA)是模擬達爾文的生物進化理論而發展起來的一種算法。它通 過模擬“適者生存”和“優勝劣汰”的生物進化中的繁殖、雜交、變異等過程來 搜索最優解。遺傳算法求解的基本思路是:將問題的一個解用染色體(即個體) 來表示,從一組可行解(即種群)開始,經過復制(即繁殖)、交叉(雜即交)、 變異(即突變)等操作,然后逐代迭代,最終得到一組可行解(即新的種群),在 流程結束后,得到最優解(最優個體)。遺傳算法在求解問題時,復制操作保留自 身優良特性,交叉和變異操作得到更好的結果,通過這種方式,極大地增強了該 算法的求解最優解能力。
    標準遺傳算法的主要步驟為:
    Step1 編碼。對于所解決問題解確定一種適當的編碼方式。
    Step2 種群初始化。對于所解決問題產生一類初始解,用染色體表示每一個解。
    Step3 計算適應度函數值。通過設計合理的適應度函數,然后分別得到各個函數 值。
    Step4 判斷進化終止條件。如果達到了算法的終止條件則終止搜索,輸出得到的 結果。否則,進行后續操作。
    Step5 選擇操作。通過選用一定的選擇策略,選擇性能優良的個體復制進入下一 代進行后面交叉過程。
    Step6 交叉操作。通過選用一定的交叉策略,對種群間的個體進行基因雜交,產 生新的個體。
    Step7 變異操作。通過選用一定的變異方法,對種群中的個體進行基因突變,產 生新的個體。
    Step8通過Step5 Step6 Step7操作后形成一個新的種群,然后繼續執行Step3,直 至找到最優解。
    下圖 3-5 所示為標準遺傳算法的流程圖。
     
    圖 3-5 標準遺傳算法流程圖
     
    3.4.2 禁忌搜索算法
    禁忌搜索(TS)是一種模擬人類智能過程的算法。它是一種通過記憶功能, 利用禁忌表來避免重復搜索,所以該算法小范圍的搜索能力很強。該算法的基本 思路是:在進行鄰域解的搜索過程中,為了提高“爬山”能力,解決容易陷入局 部最優的問題,模仿人類智能過程,通過一定的禁忌準則來禁止重復搜索,為了 跳出局部最優進行全局搜索,通過藐視準則來避免好個體被禁忌,達到得到最優 解的目的。
    禁忌搜索算法主要步驟如下:
    Step1 初始化。設定禁忌搜索算法的初始參數,并通過一定的方式產生初始解, 將禁忌表中內容清空。
    Step2 判斷搜索終止條件。當達到終止條件時,則完成搜索過程,并將當前解作 為最優輸出;未達到終止條件時進行后續操作。
    Step3 確定合適的鄰域搜索結構,增強局部搜索能力,并得到相應的鄰域解。再 從鄰域解中通過一定的規則選擇合適的候選解。
    Step4 判斷藐視準則。當達到該規則時,則用達到要求的解替換之前的解,并替 換之前的禁忌對象,并執行 Step6 。若未到達該規則,則接著下面的步驟。
    Step5 判斷候選解的禁忌屬性,確定非禁忌對象及其對應的最佳狀態的解,并替 換之前的解,用產生的新解對應的禁忌對象替換之前禁忌表中的禁忌對象。
    Step6 轉到 Step2 繼續迭代。
    下圖 3-6 所示為標準禁忌搜索算法流程圖。
     
    圖 3-6 標準禁忌搜索算法流程圖
    3.4.3 遺傳禁忌混合算法
    遺傳算法的優點是搜索能力很強,一般情況下都能找到全局最優解,可以應 用在大規模的優化問題上。但是標準遺傳算法的缺點也很明顯,其一是“早熟”, “早熟”的原因主要有兩個:一是交叉操作,遺傳算法中的交叉算子在交叉操作 時使得部分染色體很相似,這就導致父代染色體之間的信息交換較少,從而父代 染色體與子代染色體相似度過高,搜索過程變慢;二是變異操作,變異操作中的 變異概率普遍較低,從而導致多樣性降低,相似度過高,使得搜索停滯不前。其 二是“爬山”能力較差,導致這個問題的原因是變異操作效果不佳。遺傳算法的 這些缺點導致其局部搜索能力偏弱,在進行小規模搜索時效率低下,需要進行改 進。
    禁忌搜索算法對于處理簡單問題時效率很高,在搜索過程中“爬山”能力很 強,獲取最優解的概率較大。同樣禁忌搜索算法的缺點很明顯,初始解對于禁忌 搜索特別重要,禁忌搜索算法的搜索能力嚴重依賴于初始解,若初始解設置恰當, 該算法的尋優能力將會大大增強,很快收斂找到最優解,若初始解設置不恰當, 則收斂速度會嚴重下降。由于禁忌搜索算法是串行的搜索過程,所以它全局搜索 能力較弱。
    遺傳算法的優勢是局部搜索能力較弱,缺點是全局搜索能力較強,而禁忌搜 索算法的優勢是局部搜索能力較強,缺點是全局搜索能力較弱,如果結合這兩個 算法的優缺點,將這兩種算法結合起來,構成一種混合算法,將會大大增強求解 最優解的能力。先利用遺傳算法的全局尋優能力進行全局搜索,使得解空間的的 各個位置都可能會有個體存在,再將遺傳算法得到的當前解作為禁忌搜索算法的 初始解,用禁忌搜索算法對個體進行局部搜索,這樣就既保留了遺傳算法的全局 尋優能力,又提升了其局部尋優能力,提高了搜索效率,最終找到最優解的概率 更大。
    遺傳禁忌搜索混合算法的主要步驟如下:
    Step1設置配送路徑問題的原始數據:客戶的數量N,各個客戶的坐標(x,,y),配 送車輛數量K,配送車輛最大行駛時間Tk,配送車輛最大載重量Qp,用戶 的配送時間窗{e>,l},每輛車固定派送成本V,各個客戶對氣瓶的需求量及 其種類qi,各個客戶點之間的運行時間%,配送車輛k到達用戶i的時間為
    tki,時間等待成本為嗎;時間延遲成本為叫等。
    Step2設置混合算法的初始參數:種群規模n、終止條件、禁忌長度、交叉概率Pc、 變異概率Pm。
    遺傳算法操作過程:
    Step3 對于所解決問題解確定一種適當的編碼方式進行編碼。
    Step4當t = 0時,按照隨機的方式產生初始種群為n的初始種群P(0),該種群有n 條染色體,一條可行的配送路徑對應一條染色體。
    Step5計算P(t)中每條染色體的適應度函數值。
    Step6 根據計算的適應度函數值,采用輪賭和最優策略保留法相結合的方式進行 染色體的選擇,同時復制下一代染色體P (t)。
    Step7 將種群 P'(t) 采用隨機的方式進行配對,并執行最大保留方式的交叉操作, 產生P (t)。
    Step8對P(t)采用2-交換的方式進行變異操作。產生P (t)。
    Step9判斷遺傳算法進化終止條件。如果達到了進化終止條件,則繼續后面步驟; 否則,令t = t +1,轉向Step5。
    禁忌搜索算法操作步驟:
    Step10將上面步驟中得到的當前最優解作為當前算法的初解X0,記作X閔=X0 ; 并將禁忌表清空H=0。
    Stepll對當前解隨機進行變換,變換后得到鄰域結構N(x)。
    Step12求出N(x)-H的最優解。令x =兒若j優于Xbest,則Xbest = y ;否則,跳 轉到下一步。
    Step13 判斷是否達到了禁忌搜索終止條件,若滿足,則退出循環,得到最優解; 否則,更新H,轉向Stepll。
    遺傳禁忌混合算法流程圖如下圖3-7 所示。
     
     
    圖 3-7 遺傳禁忌混合算法流程圖
     
    3.4.4 基于訂單聚類的種群初始化
    本系統在遺傳禁忌算法的基礎上對氣瓶配送訂單進行聚類,建立氣瓶配送鄰 域系統,對遺傳禁忌算法初始化種群Q(t)進行優化,同時改進算法的流程,在此基 礎上提出基于訂單聚類的改進遺傳禁忌算法,提高了尋得最優解的概率。種群初 始化分為兩個階段,第一階段為確定初始配送車輛數目,第二階段為構建初始訂 單。
    第一階段:首先確定初始訂單的配送車輛數目,即氣瓶配送訂單鄰域系統數 目K,可以通過氣瓶配送總數以及氣瓶配送種類大致進行估算,并在訂單指派階 段進行調整。配送車輛數目 K 的估算公式為:
    K=[Z qp/ Qp ] (3-28)
    式(3-28)中:工qp表示所有氣瓶中配送量最大氣瓶的配送總量;Qkp表示氣瓶配 送車中能夠裝載該種氣瓶的最大裝載數量;
    第二階段:構建初始訂單,即構建初始種群Q(t),初始種群Q(t)的構建基于氣 瓶配送訂單鄰域系統,訂單鄰域系統的構建主要包括確定種子訂單、分配訂單兩 個步驟。其流程如下圖 3-8 所示。
     
    圖 3-8 訂單聚類流程圖
     
    (1)確定種子訂單
    首先根據配送項目相似度初步確定路線數目,然后根據時空距離 度量公式得到各個客戶點到加氣站之間的距離,將距離加氣站最遠的 訂單加入到其中一條路線中,依次為每一條路線確立種子訂單。
    (2)分配訂單
    將剩下的訂單按照距離種子訂單距離較近的原則安排到相應的配 送路線中,并檢查是否達到配送車輛的該種氣瓶配送最大裝載數目和 總裝載數目,若未達到,則繼續安排到已有路線中;若達到,則 K=K+1, 將剩余訂單安排到新增路線中。
    3.4.5 算法的具體實現技術
    1、染色體的描述
    為了方便遺傳算法與禁忌搜索算法的結合,在設計編碼時采用自然數編碼,
    用長度為K + N +1的自然數來描述解,配送點總數為N,氣瓶配送車輛數目為K, 配送中心為{0},并分成 K 段自然數編碼,表示 K 條路徑,客戶的配送順序就是基 因在染色體中的順序。
    例如:若染色體為“0145027903680”,則表示配送方案為 3 臺車為 9 個客戶 配送氣瓶,配送路線分別為“加氣站---客戶 1---客戶 4---客戶 5---加氣站”,“加氣 站---客戶 2---客戶 7---客戶 9---加氣站”,“加氣站---客戶 3---客戶 6---客戶 8---加氣 站”。染色體的描述如下圖3-9所示。
    014502790368 0
     
    圖 3-9 染色體的描述
    2、 適應度函數的確定
    本系統的適應度函數選擇由目標函數轉化得到:f = zmin,f是需要的適應度 函數,zmin是在同一代種群中成本最低的染色體。適應度函數判定的目標是最小值 即是配送成本最小的配送路徑方案。
    3、 選擇算子
    選擇即選用當前種群中適應度值較大的個體來進行下一步交叉操作。在目前 的配送路徑規劃問題的研究中,大多數采用輪賭的方式來進行選擇,但是采用這 種選擇方式會導致被選擇的全是最佳個體,導致種群的多樣性降低,喪失算法的 進化能力。為了保持全局搜索能力,根據氣瓶配送問題的特點,這里采用最佳個 體保留與輪賭方式相結合的方式進行選擇。其流程如下所示:
    Step1 按照最優個體保留法,將本代中狀態最好的個體直接復制下來。
    Step2 按照輪賭法選擇本代中的 m 個個體復制到下一步操作。
    Step3從上一代中隨機選擇n-m-1個個體到下一代,使種群規模仍舊保持為n。
    選擇概率值為:P(i) = f /工f,其中工f表示整個個體的適應度值的和,f表 示某個個體的適應度值, P(i) 表示單體的適應度占整個群體的百分比。從這里可 以看出適應度值越大,被選中的可能性越大,從而將優秀的基因遺傳到下一代, 充分體現“優勝劣汰”的生物進化理論。
    4、 交叉操作
    對于氣瓶配送路徑規劃問題,它的交叉操作要求任意兩條路徑進行交叉后得 到兩條新的路徑,并且這兩條路徑必須具有實際意義。本算法中采用最大保留交
    叉方法,具體的實現思想是:若兩個染色體交叉處的基因都是 0,則采用部分匹配 交叉運算;若兩個染色體交叉處的基因不全是 0,則將兩個交叉點左移或者右移, 直至兩個染色體的交叉處都是 0,然后執行部分匹配交叉操作。
    部分匹配交叉舉例為:如果兩個父代染色體串及其匹配區域為:
    A = 984|567|320和 B = 871| 230 | 9546 ,首先把 A 和 B 的兩個區域中匹配部分進行 交換,得到 A' = 984|230|320和 B' = 871|567|9546,然后對 A' 和 B' 匹配區域以外的 位置根據映射關系進行交換,對 A' 于匹配區域 2、3、0 分別對應 5、6、7,然后進 行替換得到 A'' = 984230657,同理對于 B' 替換后得到 B'' = 8015679243。
    5、變異操作
    變異操作是按照一定的變異概率對染色體上的基因進行改變,在配送路徑規 劃問題上,變異操作起著交換路徑或者轉換路徑的作用。本算法采用的方法是 2- 交換方法,即任意確定染色體基因中兩個非零的位置,然后進行交換。
    例如:P0160504320 tR0160503420
    上述兩個染色體串中,帶有下劃線的兩個數字被選中用來交換。變異前后路 徑變化對比如下圖 3-10 所示。
     
    6、 參數與終止條件
    參數的選擇對算法的影響很大,要想遺傳算法的性能最優,必須對參數的設 置進行調優。同時參數的設置與所解決問題的類型以及所建的數學模型關系很大, 根據配送路徑規劃方面的經驗數據,一般種群規模取 n = 30 -100,交叉概率取 Pc = 0.6 - 0.8,變異概率取 Pm = 0 - 0.05。
    本算法設計中終止條件采用:
    1、 算法迭代達到 400 代。
    2、 染色體最佳保持 20 代。 以上條件滿足任意一個即結束運算。
    7、 鄰域結構
    禁忌搜索算法的鄰域結構很多,國內外很多知名學者對此研究改進也很多, 本算法中采用的是一種組合方法,根據情況不同選擇不同的交換策略。同時改進 了執行規則,鄰域結構交換只對非零節點進行,采用這種方式來達到避開不可行 路徑的目的,從而提高搜索效率。隨機選擇兩個客戶點執行如下交換策略:
    1 、頂點交換
    交換所挑選的兩個頂點的位置。
    例如:p = (012304560789) TP2 = (014302560789)
    2、 2-opt
    若挑選的兩個頂點在同一路徑內,則逆轉這兩個頂點及其之間的點的順序。
    例如:p = (01239456078) TP2 = (01493256078)
    3、 “尾巴”交換
    若挑選的兩個頂點不在同一路徑內,則將該條路徑中的自該點之后的“尾巴” 進行交換。
    例如: P1=(012340567089)TP2 =(012670534089)
    8、 解的評價
    在本算法的實現過程中適配值通過目標函數及其約束值來實現,并用此來對 解進行評價。鄰域結構中最佳適配值的個數由禁忌表的長度來決定,并將最佳適 配值作為候選解。
    9、 禁忌表
    本算法的禁忌表根據鄰域結構來確定,通過構造(n +1) x(n + 1)的矩陣來進行記 錄。若兩點i, j進行頂點互換,則將禁忌情況存入矩陣元素(i, j),其他類似,禁忌 表中將記錄每一次交換記錄。禁忌表的長度根據經驗數據,客戶數量超過50時長 度取100,未超過則取 30。
    10 、終止準則與釋放準則
    本算法采用的“終止準則”為:結合頻率控制和最大迭代步數規則作為終止 準則。迭代步數不超過N步,N為一個正整數;在迭代過程中記錄當前最優值, 在迭代的N步內,若當前最優解連續M(M為頻率控制)次未變,則認為繼續循 環下去已經沒有意義了。否則,繼續循環直至N步結束。
    本算法采用的“釋放準則”為:如果對當前解進行改變后得到的解比之前得 到的所有解都要好,就說明這次改變滿足了釋放準則。
    3.5 實驗分析
    3.5.1 數據選取
    1、位置信息
    根據加氣站的實際運營情況,客戶通過電話訂單居多,工作人員接到訂單后 會統計客戶需要氣瓶的數量種類以及配送地點和配送時間。其中客戶的配送地點 坐標需要通過系統中的地圖獲取。坐標位置信息主要包括各個配送點的位置信息 以及各個位置之間的距離。同時利用 GIS 地圖提供的數據來進行任意兩個配送點 之間的距離計算,這樣做有利于準確定位兩點之間的距離,避免因某些路線不適 合配送車輛行走出現的距離偏差。車輛在兩點之間的行駛距離和時間對路線規劃 的質量和準確度起著關鍵作用。
    本系統的地圖服務選用的是百度地圖,百度地圖有開源的 API 可以供大家根 據自己的需求進行調用,通過一些函數可以獲取配送點的經緯度。并獲得兩個坐 標之間的距離和各種交通工具到達該地點的預計時間,這里我們選擇駕車模式。 具體方式為調用百度地圖的路線服務V1.0接口,它是百度開發者平臺為廣大開發 者提供的免費API,這個接口訪問的協議為http/https,它可以實現公交、駕車、騎 行、步行等方式的線路規劃功能,返回的數據格式為xml或者json。通過該方式 可以根據檢索到起點和終點之間的駕駛距離和時間,還可以躲避交通擁堵。調用 該接口涉及到的關鍵參數如下表3-1 所示。
    表 3-1 路線服務關鍵參數介紹
    參數 含義 備注
    Distance 距離 單位:米
    Duration 時間 單位:秒
    Direction 角度 "0"代表 345 度到 15 度,以此類推
    Instruction 路況描述 例如: "良好"
    Path 坐標描述 示例: "116.308151,40.057096"
    Traffic_condition 路況評價 0:無路況;1:暢通;2:緩行;3:擁堵
    Origin Location 起點坐標 坐標系由 ret_coordtype 設置
    Destination Location 終點坐標 坐標系由 ret_coordtype 設置
    Status 狀態碼 0:成功;2:參數錯誤;
    Message 狀態碼信息 例如: message: "ok"
    Area 是否城市內部 0表示不在城市內部;1表示城市內部
    2、客戶訂單信息表
     
    根據客戶對氣瓶的數量、種類、配送地點以及配送時間窗口要求,選取了廣
    元市某加氣站一段時間內客戶的氣瓶需求,得到客戶信息表如下表3-2所示。
    表 3-2 客戶信息表
    編號 種類/數量 位置坐標 時間窗
    A B 經度坐標 緯度坐標 EI EL
    1 0 0 105.832112 32.427339 0 1000
    2 1 0 105.836164 32.426338 8:00 12:00
    3 0 3 105.837251 32.426844 8:00 10:00
    4 3 0 105.835813 32.428162 8:00 10:00
    5 0 5 105.835813 32.428162 8:00 10:00
    6 1 0 105.833028 32.426072 14:00 16:00
    7 3 0 105.830926 32.426223 12:00 15:00
    8 3 0 105.838921 32.431524 10:00 12:00
    9 3 0 105.827967 32.429034 10:00 12:00
    10 4 0 105.828921 32.426621 8:00 10:00
    11 0 1 105.830747 32.428192 12:00 17:00
    12 5 0 105.835322 32.431562 10:00 12:00
    13 0 2 105.835322 32.431562 10:00 15:00
    14 0 1 105.826507 32.426546 12:00 17:00
    15 5 0 105.828735 32.432642 8:00 12:00
    16 6 0 105.827792 32.425609 10:00 12:00
    17 0 2 105.829543 32.424735 13:00 17:00
    18 3 0 105.831361 32.422293 10:00 12:00
    19 0 1 105.829875 32.421211 13:00 16:00
    20 4 0 105.828654 32.423691 8:00 10:00
    21 0 3 105.828654 32.423691 8:00 10:00
    22 5 0 105.826947 32.420007 14:00 16:00
    23 0 1 105.833636 32.430512 10:00 14:00
    24 5 0 105.826809 32.423495 9:00 11:00
    25 3 0 105.828133 32.421586 10:00 12:00
    26 6 0 105.832193 32.422582 8:00 10:00
    27 0 5 105.833729 32.432407 10:00 11:00
    28 3 0 105.829687 32.427361 15:00 17:00
    29 4 0 105.834648 32.423786 9:00 11:00
    30 0 2 105.834648 32.423786 9:00 12:00
    3、 終止條件
    算法的終止條件為:
    1、 當算法迭代的次數有500 次時;
    2、 染色體最佳狀態25 代不變;
    4、 控制參數
    針對遺傳禁忌混合算法設計情況,再結合配送路徑問題的數學模型以及約束 條件,本文根據經驗值和實際調試情況,選取了合適的參數值,具體控制參數如 下表3-3、表 3-4和表 3-5所示:
    表 3-3 控制參數介紹
    類型 參數 單位
    種群規模 n 60
    迭代次數 t 500
    交叉概率 Pc % 60
    變異概率 Pm % 2
    禁忌長度 L 5
    客戶數 N 30
    車輛數 K 8
    單車最大行駛時間 Tk 小時 8
    單位時間運輸成本 hk 30
    時間等待成本 w1 10
    時間延遲成本 w 30
     
     
    表 3-4 配送車輛容量表
    氣瓶類型 配送車型/容量
    X Y Z
    A 30 25 20
    B 20 18 15
     
    表 3-5 配送車輛使用成本
    配送車型/成本
    使用成本
    X Y Z
    固定成本/元 230 220 200
    單位運輸成本/(元• 100 km1) 160 150 110
     
     
    3.5.2 仿真分析
    1、模型比較
    針對遺傳禁忌算法按照VRP模型和VRPTW模型得到的仿真運行結果如下圖
    3-1 1所示:
    /優解為,
    1->3->30->20->14->1->5->2->2S->18->28->1->4->29->17->11->1->19->22->2S->24->21->1-->16->13->1->10->9->15->2?->23->1->12->8->6->1
    1 5 3 30 21 1 4 26 20 24 10 1 2 29 18 25 1$ 1 9 15 12 8 1 23 27 13 T 6 1 11 14 17 19 22 28 1 鄭誠>為.2257.7085
    120.2608
    Elapsed tiae is 16.941575 seconds.
    Ito-
    l->5->3->30->21->l->4->26->20->24->10->l->2->29->18->25->16->1->5->15->12->8->l->23->2T->13->7->S->l->ll->14->17->19->22->28->1
    .1 3 30 20 14 1 5 2 26 18 28 1 4 29 17 11 1 19 22 25 24 21 1 7 16 13 1 10 9 15 27 23 1 12 8 6 1 為’ 2059.3838
    I 106.0293
    Elapsed tiae is 11.213752 seconds.
    圖 3-11 仿真運行結果圖
    按照VRP模型進行路徑規劃時,氣瓶配送路徑總和達到了 120.2608km,但是 成本達到了 2257.7085元 運行時間為16.94秒。按照VRPTW模型進行路徑規劃 時,氣瓶配送路徑總和為106.0293km,但是成本僅為2059.3838元,運行時間僅 為11.21秒,同時VRPTW模型得到最短路徑的時間最短,說明VRPTW模型性能 比VRP模型具有一定的優勢。
    將選取的數據參數結合VRP模型根據遺傳禁忌算法進行Matlab仿真,得到該 模型的優化過程仿真圖如下圖3-12 所示:
    優化過程
    3800 1 1 1 1 1 1 1 1 1
    3600 「 -
    3400 「 -
    3200 f -
    員 3000 I -
    喘 2800 -I -
    2600 -I -
    2400 -''i -
    一「
    22nn 1 1 1 1 1 1 1 1 1
    0 50 100 150 200 250 300 350 400 450 500
    迭代次數
    圖 3-12 VRP 模型優化過程圖
     
    從上圖 3-12 可以看出,橫坐標表示迭代次數,縱坐標表示最優適應度值。該 模型前期收斂速度較快,得到最優解的時間也較快,但是后期尋優能力較弱,最 終在156代左右得到最優解,最終得到的配送成本大約在2257元左右。
    將選取的數據參數結合VRPTW模型根據遺傳禁忌算法進行Matlab仿真,得 到該模型的優化過程仿真圖如下圖 3-13 所示:
     
    50 100 150 200 250 300 350 400 450 500
    迭代次數
    圖 3-13 VRPTW 模型優化過程圖
    從圖3-13 可以看出,該模型收斂速度較快,收斂速度與算法和模型的設計相 關,雖然 VRPTW 模型約束條件眾多,但是該模型設計較為合理,且參數選取合 適,所以后期收斂速度也較快,最終在 146 代左右得到最優解。
    從圖3-13中得到的優化過程是基于遺傳禁忌算法進行的仿真。VRP模型是傳 統配送路徑常用的數學模型,VRPTW模型考慮了配送時間窗口的限制,算法模型 設計更加復雜,約束條件更多,最終按照VRPTW模型得到的配送成本大約在2059 元左右,由于VRPTW模型規劃的路徑由6輛車配送,比VRP模型少使用一輛車, 而每輛車都有固定配送成本,故而實際成本更低。
    將VRP模型和VRPTW模型分別按照相同的輸入數據進行仿真得到以上仿真 結果,將以上結果進行整理,得到兩種不同模型下的各項數據對比如下表 3-6所示。
    表 3-6 不同模型數據對比
    模型 種群規模 運行時間(s) 迭代次數 里程數(km) 最小成本(元) 準時率
    VRP 60 16.94 156 120.2608 2257.70 69.2%
    VRPTW 60 11.21 146 106.0293 2059.38 86.7%
    從圖3-12、圖3-13和表3-6可以看出,VRP模型未考慮時間窗口,配送準時 率較差,配送總里程較長,同時成本更高,且算法時間較長,迭代次數更多;VRPTW 模型增加了車型以及氣瓶種類等條件,總里程數較短,降低了成本,算法運行時 間短,最重要的是配送準時率達到了 86.7%,滿足了大部分客戶的配送時間需求, 有利于企業長期發展。經過對比,發現 VRPTW 模型性能優于 VRP 模型,說明 VRPTW模型設計有效,可以達到優化目的,本設計最終選用的是VRPTW模型。 2、算法比較
    將選取的數據參數結合 VRPTW 模型根據遺傳算法進行 Matlab 仿真,得到遺 傳算法路徑軌跡仿真圖如下圖 3-14 所示。
     
    圖 3-14 遺傳算法路徑軌跡圖
     
    從圖 3-14可以看出,“1”表示加氣站,其余2至30數字表示客戶點的坐標, 橫坐標表示緯度坐標,縱坐標表示經度坐標。為了便于區分,每條配送路線用不 同的顏色的線條標記,圖 3-14中 6條不同顏色的線表示6條配送路徑。圖 3-14中 得到的路徑規劃是基于VRPTW模型進行的仿真,考慮配送時間窗口的限制。
    將選取的數據參數結合 VRPTW 模型根據遺傳算法進行 Matlab 仿真,得到遺 傳算法優化過程仿真圖如下圖 3-15 所示。
     
    50 100 150 200 250 300 350 400 450 500
    迭代次數
    圖 3-15 遺傳算法優化過程圖
    從圖 3-15 可以看出,橫坐標表示迭代次數,縱坐標表示最優適應度值。該算 法前期收斂速度較快,得到最優解的時間也較快,但是后期尋優能力較弱,最終 在370 代左右得到最優解,最終得到的配送成本大約在 2736元左右。標準遺傳算 法最終得出的路徑規劃運行時間較長,迭代次數較多,且最終得出的路線安排了8 輛車進行配送,配送成本較高,規劃效果一般。
    將選取的數據參數結合 VRPTW 模型根據禁忌搜索算法進行 Matlab 仿真,得 到禁忌搜索算法路徑軌跡圖如下圖3-16 所示。
     
    圖 3-16 圖例與圖 3-14 中的圖例一致。從圖 3-16 中得到的路徑規劃軌跡圖是 基于VRPTW模型進行的仿真,采用禁忌搜索算法,考慮了配送時間窗口的限制。
    禁忌搜索算法優化過程圖如下圖 3-17所示。
     
     
     
    圖 3-17圖例與圖 3-15 中的圖例一致。該算法得到最優解的時間比遺傳算法稍 快,但是后期尋優能力較弱,最終在 192 代左右得到最優解,最終得到的配送成 本大約在2558 元左右。禁忌搜索算法最終得出的路徑規劃運行時間較長,迭代次 數也較多,且最終得出的路線安排了 7 輛車進行配送,配送成本較遺傳算法有提 升,規劃效果比遺傳算法稍好。
    聚類遺傳禁忌算法路徑軌跡圖如下圖 3-18所示。
     
    圖 3-18 圖例與圖 3-14 中的圖例一致。從上圖 3-18 中得到的路徑規劃同樣是 基于VRPTW模型進行的仿真,采用聚類遺傳禁忌算法,考慮配送時間窗口限制。
    聚類遺傳禁忌算法優化過程圖如下圖 3-19 所示。
    優化過程
    -J4UU I I I I I I I I I
    3200 -
    3000 -I -
    ® 2800 -; -
    J 2600 - I -
    2400 - | -
    22U0 - -
    2nno 1 1 1 1 1 1 1 1 1
    0 50 100 150 200 250 300 350 400 450 500
    迭代次數
    圖 3-19 聚類遺傳禁忌算法優化過程圖
    圖 3-19 圖例與圖 3-15 中的圖例一致。該算法得到最優解的時間最快,迭代次 數最少,尋優能力最強,最終在 146 代左右得到最優解,最終得到的配送成本大 約在2059 元左右。基于訂單聚類的遺傳禁忌算法最終得出的路徑規劃運行時間最 短,尋優能力最強,迭代次數較最少,且最終得出的路線安排了 6輛車進行配送, 配送成本最低,規劃效果最好。
    通過對 VRPTW 模型應用相同的參數但是不同的算法進行仿真分析,得到的 各項仿真結果如下表 3-7 所示。
    表 3-7 不同算法性能比較
    名稱 種群規模 運行時間(s) 迭代次數 最小成本(元) 準時率
    遺傳算法 60 38.85 370 2736.87 70.6%
    禁忌搜索算法 60 20.35 192 2558.54 75.3%
    聚類遺傳禁忌算法 60 11.21 146 2059.38 86.7%
    從以上三種算法的對比數據可以看出,遺傳算法在當前數學模型中表現最差, 運行時間較長,迭代次數較多,得到的配送路線成本相比其它算法也較高,當然 配送準時率也不會很高。禁忌搜索算法雖然運行時間較短,但是在成本和配送準 時率方面仍然不如聚類遺傳禁忌算法。而基于訂單聚類的遺傳禁忌算法不管是在 運行時間和迭代次數,還是在成本和配送準時率方面都能得到較好的結果,性能 明顯優于前面兩種算法,因此本設計采用基于訂單聚類的遺傳禁忌搜索算法。
    因此,針對加氣站的單配送中心多車輛帶有時間窗口的氣瓶配送問題,本設 計最終選用 VRPTW 模型,算法采用基于訂單聚類的遺傳禁忌算法。經過分析, 這種方式在解決加氣站的氣瓶配送問題時有較好效果,有利于減少加氣站的氣瓶 配送成本,提高配送準時率。
    3.5.3 實例驗證
    通過仿真分析得到了以最小成本為目標的配送路徑規劃,通過將算法程序集 成到系統中,工作人員將一段時間內的氣瓶配送需求統計到 EXCEL 表格中;然后 在路徑規劃界面點擊“導入數據”,將客戶的氣瓶需求數量、氣瓶種類、配送地點 坐標、配送時間窗等信息導入系統;接下來點擊“查詢線路”,系統生成配送路線 并在下方地圖顯示;最后點擊打印可以將配送路線打印出來,工作人員按照規劃 的路線安排車輛和人員進行氣瓶的配送。
    按照 VRPTW 模型和聚類遺傳禁忌算法得到的實際線路規劃界面如下圖 3-20 所示。
     
    圖 3-20 配送路線界面圖
     
    3.6 本章小結
    本章主要闡述了系統配送路徑規劃的實現過程。首先講述了氣瓶配送問題的 基本原理,對氣瓶配送路線問題進行了描述,明確了該問題的構成元素和目標; 然后對氣瓶配送問題建立了相應的模型,并對普通模型進行了改進,提出了帶有 時間窗的氣瓶配送路徑規劃模型;接下來對算法進行了設計,通過訂單聚類以及 將遺傳算法和禁忌搜素算法相結合的方式避免普通算法的缺陷;最后結合實際情 景進行了仿真和實例結果分析。
    第四章 信息管理系統的設計與實現
    本章主要是對該系統信息管理部分的實現過程進行詳細說明。信息管理部分 的業務分為銷售管理、氣瓶管理、信息管理和系統管理四大部分,由于各個模塊 實現的功能復雜,本章僅對該模塊的實現的關鍵技術進行敘述。
    4.1 數據庫設計
    1、采購庫存管理 本模塊主要完成加氣站采購和氣瓶庫存兩方面的業務。采購部分主要完成加 氣站采購計劃、采購計劃審核、完成采購計劃以及采購計劃的查詢工作,涉及到 的數據表為:采購計劃表、采購訂單表;庫存部分主要完成加氣站氣瓶的庫存管 理工作,主要包含氣瓶入庫信息和出庫信息以及庫存量的管理,涉及到的數據表 為:氣瓶入庫信息表、氣瓶庫存信息表、氣瓶出庫信息表。各表中實體名稱及相 互關系如下圖4-1 所示。
     
     
     
     
    圖 4-1 采購庫存數據庫設計圖
    2、銷售配送管理
    本模塊主要完成氣瓶的銷售和氣瓶配送路徑優化業務。銷售配送部分主要完 成氣瓶的銷售工作,涉及到的數據表為:訂單信息表、配送表、配送域表、配送 明細表、回單消息表;配送路徑規劃部分主要完成配送路徑規劃的工作,涉及到 的數據表為:線路信息表、線路排序表、預定線路表。各表中實體名稱及相互關
    系如下圖4-2所示。
     
     
     
    圖 4-2 銷售管理數據庫設計圖
    3、加氣信息管理 本模塊主要完成加氣站的對外加氣業務和對氣瓶充裝業務。對外加氣業務相 應的數據表為:車輛加氣信息表。對氣瓶加氣業務相應的數據表為:氣瓶充裝信 息表。各表中實體名稱及相互關系如下圖4-3 所示。
     
     
    4、氣瓶信息管理 本模塊主要完成氣瓶流通各個環節的相關的業務。氣瓶信息表部分相應的數 據表為:氣瓶信息表;氣瓶充裝部分相應的數據表為:氣瓶充裝信息表;氣瓶檢 驗部分相應的數據表為:氣瓶檢驗信息表;氣瓶報廢部分相應的數據表為:報廢 氣瓶信息表。各表中實體名稱及相互關系如下圖 4-4 所示。
     
     
     
    圖 4-4 氣瓶信息管理數據庫設計圖
    5、用戶設備管理
    本模塊主要是存放用戶和設備信息等系統公共的表。用戶信息部分相應的數
    據表為:客戶信息表、員工信息表、供應商信息表;設備信息部分相應的數據表
    為:設備信息表、車輛信息表。各表中實體名稱及相互關系如下圖 4-5 所示。
     
    6、充值信息管理 本模塊主要完成會員用戶的會員充值管理和氣價設定相關的業務。充值管理 部分主要完成會員IC卡充值以及扣費等相關管理,相應的數據表為:會員信息表、 充值管理表、扣費管理表;氣價設定部分主要完成當前氣價設定工作以及氣價的 公示,相應的數據表為:氣體價格表。各表中實體名稱及相互關系如下圖4-6所示。
     
     
     
    圖 4-6 充值管理數據庫設計圖
    7、統計報表管理
    本模塊主要完成加氣站的數據統計匯總,并按照月份以折線圖等形式展現。 統計報表部分相應的數據表為:采購統計表、氣瓶銷售統計表、氣瓶充裝統計表、 氣瓶數量統計表、氣瓶報廢統計表、客戶統計表。各表中實體名稱及相互關系如 下圖4-7 所示。
     
    8、系統管理 本模塊主要完成系統賬戶登錄以及角色管理相關的業務。賬戶管理部分相應 的數據表為:賬戶管理表;角色權限部分相應的數據表為:角色權限表。各表中 實體名稱及相互關系如下圖4-8 所示。
    賬戶管理表 角色權限表
    PK 賬戶編號 PK 角色編號
    登錄名
    密碼 角色 角色名稱 類型
    管理權限
    圖 4-8 系統管理數據庫設計圖
     
    4.2 銷售管理
    4.2.1 采購庫存管理
    1、采購管理 采購管理部分主要完成采購計劃制定、采購計劃審核、采購記錄的查詢以及 打印功能。采購計劃制定由采購業務員根據近期銷售情況和當前庫存量,制定出 采購計劃書交給相關部門進行審批。
    采購計劃表如下圖4-9 所示。
     
    圖 4-9 采購計劃圖
     
    采購計劃部分的關鍵技術是將Excel表格中的數據導入到網頁中,具體實現步 驟如下:
    (1)創建Excel表格,設置與界面上表格一致的屬性列,填寫相關數據。
    (2)編寫前端JSP頁面,設置頁面布局,設置表格需要的數據字段、操作按鈕、 操作提示等。
    (3)Controller 層:新建 ExcelController 文件,具體內容包括設置文件路徑,驗 證文件格式,創建 head 頭信息,創建 title 信息,創建 content 數據信息, 設置頁面表格與 Excel 表格對應的屬性值。
    (4)Service 層:新建 ExcelService 文件,具體內容包括字符串判空操作,獲取 字段存放信息,新建集合List,將excel表中數據存放在info對象中,建 立與數據庫聯系方法。
    (5)實體層:表中每一個字段定義為String類型的變量,為每一個變量生成get、 set 和 toString 方法。
    (6)Dao層:編寫Mapper文件,實現業務到數據庫的連接,在XML文件中將 java 與數據庫連接起來。
    (7)調試完成功能測試。
    2、庫存管理 庫存管理模塊主要負責庫存清點、氣瓶入庫、氣瓶出庫、庫存預警以及查詢 打印功能。氣瓶入庫部分又根據不同情況分為采購入庫、空瓶回收入庫、其它入 庫方式等。氣瓶出庫部分根據不同情況分為銷售出庫、報廢出庫等。
    庫存部分庫存不足消息提示采用 java 定時器定時檢查庫存數據,發現庫存數 量不足時彈出消息界面,提示“庫存不足”,消息提示利用 Ajax 技術實現頁面刷 新,實現該功能主要步驟為:
    (1)準備。下載并加載 Ajax 文件。
    (2)修改配置文件 WEB-INF。
    (3)完成前端頁面MessageRemind.jsp以及js代碼的編寫,設置標志位(flag)、 提醒內容(msg),若出現庫存不足,則提示:“庫存不足”
    (4)編寫后臺代碼 MessageRemindController.java,創建一個定時器 addTimer, 設置觸發器 Tigger 以及觸發機制 StartTigger 和執行細節 TiggerDetail。
    (5)完成測試。 庫存管理中提示庫存不足界面如下圖 4-10 所示。
     
    圖 4-10 提示庫存不足圖
    4.2.2 銷售配送管理
    1、銷售管理 銷售管理主要包括配送訂單、配送路徑選擇和配送回執三部分組成。客戶下 單后生成訂單,系統根據客戶要求送達的地址和時間,合理規劃配送路徑并安排 相應車輛,工作人員打印配送訂單,通知配送人員將氣瓶按照配送訂單地址送至 客戶處,到達后客戶驗收氣瓶,完成氣瓶交付。
    該模塊的關鍵技術是實現獲取 GPS 定位信息以便準確定位配送軌跡,位置信 息可以根據手持設備的 GPS 模塊傳回的定位信息進行定位然后通過百度地圖顯示 地圖位置,系統與設備之間采用 Socket 進行通信,通信過程分為監聽和接發送兩 個過程。該過程的實現流程為:
    (1)獲取 GPS 定位系統數據,通過服務器將獲取的定位信息保存到相應的數 據庫中。
    (2)客戶端向服務器發送獲取數據的請求,通信協議采用TCP/IP,服務端接 收到請求后判斷是否可以進行數據傳輸。
    (3)若可以傳輸則提取之前保存的 GPS 數據,通過約定的數據格式以網絡的 方式將數據傳輸給客戶端。
    (4)客戶端接收到數據后根據約定的數據格式以及傳輸協議對獲取的數據進 行解析。
    (5)最后將獲取的地理位置信息通過調用百度地圖開源接口在電子地圖上顯
    示。
    Socket服務端與客戶端之間的通信過程以及涉及到的函數名如下圖4-11所示。
     
     
    GPS定位信息具體字段信息及所代表的內容如表4-1所示。
    表4-1 GPS格式表
    字段名稱 格式 備注 對應內容
    日期 char 8位數字,依次為“年、月、日” 20170427
    時間 char 24 小時制,依次為“時”“分”“秒” 111432
    設備標識 char 設備的標識號 135****8386
    經度 float 有效位取小數點后 6 位,單位為“度” 105.832112
    緯度 float 有效位取小數點后 6 位,單位為“度” 32.427339
    速度 int 不存在則置-1,單位為“km/h” 56
    方位角 int 不存在則置-1,單位為“度” 9
    狀態 int 0 表示在線,1 表示離線 1
    可用標識 int 0代表可用,1代表不可用 1
    2、配送管理 配送路徑管理是該系統的一個創新點,同時也是一個難點,配送路徑的規劃 對于加氣站的銷售環節意義重大,配送路徑的優化有利于提高配送效率和減少配 送成本。對于客戶下單后的配送主要有兩種處理方式:第一種是利用GPS傳回的 定位信息,在地圖上找出離配送點最近的配送車輛進行配送,由于本系統對定位 信息進行了優化,所以該方案可行,通過驗證,該方案效率很高。第二種是對一 段時間內的訂單數量進行匯總,然后根據配送點的分布信息對本段時間內的所有 配送點進行路線規劃,安排合適的車輛和路線進行配送。關于第二種方案的配送 路線規劃前面已經進行了詳細的介紹。
    配送訂單管理界面如下圖4-12所示。
     
    4.3 氣瓶管理
    4.3.1 加氣信息管理
    加氣信息管理主要完成加氣站加氣機的加氣信息管理工作,加氣信息又分為 車輛加氣信息和氣瓶加氣信息。
    氣瓶充裝時,會有手持設備掃描氣瓶上唯一身份標識,經過外觀檢查氣瓶合 格后對氣瓶進行加氣,同時會將相關信息通過手持設備進行錄入,手持設備會記 錄充裝人員、充裝介質、充裝氣體質量以及日期等信息,加氣完成后通過通信線 路將充裝信息傳至系統數據庫,通過管理系統充裝模塊可以對充裝信息進行查詢, 讓氣瓶充裝都有據可查。
    該部分的關鍵技術是讀取本地文件然后對數據進行解析并處理,利用I/O流進
    行讀數據流程如下圖4-13 所示。
     
    圖 4-13 文件讀取流程圖
     
    >讀數據:從外部讀取數據到程序中,只能讀數據。建立數據文件連接 (Connect),新建FilelnputStream方法,定義存放數據文件緩沖區(Char), 調用Read方法讀取數據,關閉數據流(Close),編寫異常處理方法 (IOException)。
    >寫數據:將數據文件傳到外部目標,只能寫數據。建立數據文件連接 (Connect),新建FileOutputStream方法,定義存放數據文件緩沖區(Char), 調用Write方法寫數據,關閉數據流(Close),編寫異常處理方法 (IOException)。
    4.3.2 氣瓶信息管理
    氣瓶管理模塊由氣瓶基礎信息、充裝管理、檢驗管理和報廢處理等四部分組 成,由于部分模塊相似,下面僅對基礎信息模塊和報廢處理模塊的進行介紹。 1、氣瓶基礎信息管理
    氣瓶基礎信息管理是指對加氣站采購的新氣瓶或者第一次進入加氣站的非新 氣瓶進行信息登記。在氣瓶上植入RFID標簽,通過初始化平臺(讀寫器),將RFID 標簽與氣瓶原來的鋼印數字編號綁定,讀寫器將初始信息寫入電子標簽,并上傳 系統,給該氣瓶唯一的身份ID,就可以正式流轉應用。RFID與系統之間的數據通 過json格式的數據進行傳輸,氣瓶初始化推送參數傳輸格式為:
    {“scanType”:1, { “tagId”:“2342144dddc”,
    “rfid”:“E123456”, “scanTime”:“2017-04-28 19:02:02”,
    “tags”:[{“tagId”:“12345abc”, “pushTime”:“2017-04-28 19:02:50”}]
    “scanTime”:“2017-04-28 19:02:02”, }
    “pushTime”:“2017-04-28 19:02:50”},
    氣瓶初始化相關參數說明如下表4-2 所示。
     
     
    表 4-2 氣瓶初始化參數說明
    參數名稱 參數類型 參數說明 是否必填 示例值
    rfid String 讀寫器編號 E123456
    waregouseId String 倉庫編號 20170428190202234655
    scanType Int 區分類別 1:氣瓶初始化 2:倉儲掃描
    scanTime DateTime 掃描時間 2017-04-28 19:02:02
    pushTime DateTime 推送時間 2017-04-28 19:02:50
    氣瓶信息登記界面如下圖4-14所示。
     
     
    代瓶初始化完成憤;兄
    mafeJKJKiotun: o t- ar ta
    ■- r -r arta
     
    «*«nMikaia
    Mf*
    3*006319
    r2<x>»i«7»aoo<n23090oeoo€
     
    圖 4-14 基礎信息登記界面圖
    2、氣瓶報廢信息管理 報廢管理主要完成對達到報廢要求的氣瓶進行集中管理,防止這些高危氣瓶 再次流入市場。達到報廢年限的氣瓶直接進入報廢氣瓶數據庫,這些氣瓶不能再 進行充氣和檢驗操作,檢驗環節不合格的氣瓶也將進入報廢氣瓶數據庫,達到報 廢條件的氣瓶會有短信通知。報廢處理只有部分擁有權限的人員才可以進行操作, 保證報廢氣瓶得到妥善處理,防止高危氣瓶再次流入市場危害社會群眾安全。報 廢環節程序流程圖與充裝環節類似,這里不再敘述。
    報廢管理的短信功能主要調用第三方 API 來實現,由于目前短信平臺監管較 為嚴格,為了保證質量這里采用付費的短信平臺來完成,完成該功能的基礎信息 有:用戶名:name;密鑰:key;接收方電話號碼:SMSMob;具體內容:SMSText;}。 實現該功能需要先下載該平臺的jar包,實現步驟如下:
    (1)下載并加載實現該功能需要的 jar 包, commons-loggong-1.1.1.jar 、 commons-httpclient-3.1.jar 、commons-codec-1.4.jar 。
    (2)編寫前端JSP代碼SMSmessage.jsp,設置頁面布局、短信發送界面、需要 發送信息格式等信息。
    (3)編寫后端業務代碼SMSmessageController.java,調用SMS平臺接口,設置 轉碼格式(charset)、注冊時使用的用戶名(uid)、注冊成功后得到的密鑰
    (key)、發送手機號碼(smsmob)、短信具體內容(smstext)等。
    (4)調試測試完成功能。
    報廢氣瓶管理界面如下圖4-15 所示。
     
    ™ ■ W'l'i■― 報廢處理 • ■« «m*w
    ■ WB H eSU-lM —佝蘇1皀張懺 C7MiK Qes&i Afiro
     
    w® * 叭,
    mrna
    a
    r pm 巳 n*a» an人 *su>« air cm MfM HMM ■ft
    <
    O 9JMP9 > 701KMMMOXM2MBM : «s(23
    圖 4-15 報廢氣瓶查詢界面
     
    4.4 信息管理
    4.4.1 用戶設備管理
    客戶是企業生存的根本,因此客戶信息要盡量完善,對于客戶資源的管理,
    要建立詳細的檔案。客戶又分為企業客戶和普通客戶,客戶信息主要包括客戶的 姓名、聯系方式、公司信息、車輛信息等內容。員工信息管理主要針對企業內部 員工,包括加氣站人員、倉儲人員、檢驗人員、配送人員、訂單處理人員等工作 人員的個人信息,記錄員工的工作時間,統計員工的工作量,為后期員工的績效
    評定提供依據。其中客戶管理包含客戶留言信息,該部分界面如下圖 4-16 所示。
     
     
     
    實現客戶留言功能主要使用富文本編輯器來實現,通過該功能可以實現文字、 圖片、視頻等傳輸。實現該部分主要步驟如下:
    (1)下載并加載UEditor相關js文件。
    (2)編寫前端代碼UEditorjsp,設置富文本編輯器所在區域以及排版布局。
    (3)配置文件上傳下載工具 commons-fileupload-121.jar 和 commons-io-1.4.jar。
    (4)新建上傳工具類UploadController.java,編寫文件上傳(UploadFile)下載
    (DownloadFile)功能代碼。
    (5)新建 UEditorController.java 文件,編寫接口(LeaveMessageController),實 現留言功能(LeaveMessage )具體業務需求。
    (6)完成測試。
    設備管理和車輛管理模塊主要是將企業配送車輛和設備信息錄入系統,具體 信息包括車輛型號、購買日期、檢驗日期、車牌號、司機、負責人等信息。該部 分功能和所用技術與之前類似,這里不再敘述。
    4.4.2 充值信息管理
    充值管理部分主要針對企業會員用戶進行資金管理,提高每次訂單的交易效 率,簡化資金流動環節。這部分業務主要包括充值登記、充值查詢、賬號余額查 詢等。充值登記時會錄入姓名、充值金額、充值日期、剩余金額、充值站點、收 款人等信息,這部分主要是管理人員操作。同時還設有非會員賬戶,沒有進行會 員登記的用戶可以使用公用賬戶,公用賬號每完成一次交易進行一次充值和消費 記錄,方便進行氣體量和資金管理,提高企業經營管理效率。
    充值管理部分主要是加氣完成后的付費服務,會員用戶通過 IC 卡進行付費,
     
    非會員用戶通過現金、支付寶、微信等形式進行付費,并在加氣站公共賬戶里扣 除相應余額,在備注欄注明。這樣做的好處是讓加氣環節的每一筆資金流轉在系 統都有記錄,方便進行數據統計。扣費查詢界面圖如下圖4-17 所示。
     
    充值部分需要 IC 卡相關設備與系統進行交互,將 IC 卡的充值扣費等操作記 錄在系統中,IC卡與系統的交互需要安裝相關的驅動程序,通過調用dll鏈接庫, 對 IC 卡進行讀寫操作。實現該部分功能的主要步驟為:
    (1) 初始化。通過Auto_Init函數完成初始化功能,設置端口號(port)、波特 率(baud)、返回值。
    (2) 設置密碼模式。通過Setsc_md函數完成密碼設置,設置設備句柄(icdev)、 密碼模式(mode)、返回值。
    (3) 獲取當前設備狀態。通過函數 Get_Status 獲得當前設備的狀態,設置設備 句柄(icdev)、狀態返回結果(state)、返回值。
    (4) 核對 IC 卡密碼。通過函數 Csc_Check 實現核對卡密碼,設置設備句柄
    (icdev)、密碼長度(len)、設置的密碼(m_string)、返回值。
    (5) 寫數據。通過函數Swr_card向卡中寫入數據,設置設備句柄(icdev)、地 址偏移量(Ofset)、字符串長度(len)、寫入數據標識號(w_string)、返 回值。
    (6) 關閉設備端口。通過函數IC_Exit關閉設備端口,設置設備句柄(icdev)、 返回值。
    4.4.3 統計報表管理 統計報表環節主要完成對氣瓶數量、銷售數量、客戶數量和采購數量等數據 的統計,然后形成月報表和年報表,并以折線圖的形式展現,形象地展示各類數 據的變化情況。
    采購數據根據實際情況會分析出采購年度表,將該年度采購數據分氣種進行 統計分析,并與上一年度的采購總量和價格等進行對比,形成直觀地對比折線圖。 同時可以查詢每一次采購明細。銷售數據可以分為氣瓶銷售匯總表、氣瓶銷售日 報表。并將每月數據進行統計,同樣形成折線圖對比,方便企業進行數據分析。 氣瓶銷售數據的月報表統計圖如下圖4-18 所示。
     
    圖 4-18 氣瓶銷售統計圖
     
    為了保證界面友好,系統兼容性強,由于系統前臺界面采用的是Bootstrop框 架,所以這里在做統計報表時也采用該框架的圖表插件,該插件為Chart.js,這個 插件可以提供豐富的統計報表,例如曲線圖、折線圖、餅狀圖等。該技術的實現 需要依賴于前端技術jQuery,首先需要在前端文件中引入js文件,這里主要需要 引入Chart.js和jQuery.min.js這兩個文件。
    實現統計報表部分功能主要步驟如下:
    (1)下載并加載 Chart.js 和 jQuery.min.js 文件。
    ⑵新建Chart.jsp前端頁面,設置圖表區域和頁面布局。
    (3)編寫 js 代碼,實例化對象,設置參數(type、data、labels、datasets、background、 Color、boradColor、options 等)。
    (4)新建統計工具類Chart.java,完成統計類的方法。
    (5)新建ChartController.java文件,編寫接口,完成具體業務需求。
    (6)完成測試。
    4.5 系統管理
    賬戶管理部分包括用戶名、密碼和角色服務,每個用戶都有一個唯一編號 并且每個用戶都有一個對應角色。角色權限管理具體角色分類包括:系統管理員、 采購員、采購審核員、銷售管理員、充裝員、庫存管理員、普通用戶等。日志管 理部分主要是對每一個用戶的操作實現可以追蹤追查,為出現故障或者意外情況 時提供依據,提高系統的安全性能。備份管理主要是為系統制定出一個符合實際 需要的備份策略,定期對數據庫進行備份,在數據庫出現故障后可以對數據進行 恢復,防止數據丟失,提高系統的安全級別。
    系統管理模塊主要包括角色管理、系統賬號管理、系統日志、系統維護等部 分。這里僅說明角色管理部分,其他部分類似。權限管理界面如下圖 4-19 所示。
     
     
    1 QJ訴有 WCIT53 1 采購業好員 宋購$S;I!Dra 的£5蛙 迎員 走裝人場 1 豚療15•理扇 彗適用盧 1 «5酗卿用戶
     
     
    圖 4-19 角色權限管理界面圖
     
    1、角色管理
    角色管理部分主要完成對該系統所有用戶的角色分類,每個角色都有自己的 權限,不同權限的用戶可以訪問不同的頁面,同時部分操作只有部分角色成員才 能操作。角色管理部分采用Shiro技術實現,Shiro是目前被廣泛使用的一種安全 框架,它在登錄密碼驗證、角色權限管理等方面使用較多。它的關鍵技術是用 javaservlet中的filter,通過對攔截器進行配置,當有請求時,首先進行驗證,若驗 證通過,則可以訪問;若不通過,會有錯誤信息提示。
    在該技術實現時最重要的是 Realm 中兩個方法的實現,分別是授權 ( doGetAuthorizationInfo )和認證( doGetAuthenticationInfo ) ,保證系統安全。其 中認證過程如下所示:
    (1)倉ll建 securityManager。
    (2)通過subject.login函數提交認證處理,并提交token。
    (3)提交securityManager進行認證,最終通過RealmAuthenticator進行認證。
    (4)RealmAuthenticator 調用 iniRealm (通過 realm 傳入 token 的方式)去 ini 配置 文件中查詢相關信息。
    (5)iniRealm根據輸入的 token ( UsernamePasswordToken )從shiro.ini 查詢用戶 信息,根據賬號查詢用戶信息(賬號和密碼)。
    ①如果查詢到用戶信息,就給 RealmAuthenticator 返回用戶信息(賬號和 密碼)。
    ②如果查詢不到,就給 RealmAuthenticator 返回 null。
    (6)RealmAuthenticator 接收 IniRealm 返回 Authentication 認證信息。
    ①如果返回的認證信息是 null, RealmAuthenticator 拋出異常 ( org. apache. shiro. authc.UnknownAccountException )。
    ②如果返回的認證信息不是 nul(l 說明 inirealm 找到了用戶),對 IniRealm 返回用戶密碼(在 ini 文件中存在)和 token 中的密碼進行對比,如果 不一致拋出異常( org. apache. shiro. authc.IncorrectCredentialsException )。
    2、日志管理 日志管理部分主要是服務器在運行時后臺記錄相關的業務操作,日志管理對 于系統的運行維護起著至關重要的作用,本系統的日志管理提供日志的查看、刪 除以及日志的打印操作,這里的日志主要是實現日志接口 log,由于每個模塊都有 涉及,這里不再詳細敘述。
    3、備份管理 備份管理部分主要是對系統進行備份,本系統采用的是全部備份和 binlog 的 方式,其中全備分為邏輯備份和物理備份。
    >邏輯備份選擇每日凌晨3:30在從庫上備份的方式,將備份文件放在從庫 上的data/backup/fullbackup,采用mysqldump進行全庫備份,通過定時任 務,定時執行 shell 備份腳本;
    >物理備份選擇每周二凌晨3:30在主庫上備份的方式,將備份文件存放在 遠程服務器目錄下,這里采用 percona 的 innobackupex 工具進行,該工具 的優點是可以在線熱備,同時線上的業務可以正常運行。
    > binlog備份實時將主庫上binlog同步到遠程服務器上,mysqlbinlog工具進 行日志的拉取,執行shell腳本,經過以上三種方式,基本可以確保數據 在異常情況下的恢復。
    4.6 本章小結 本章的主要內容是系統數據庫的設計和系統功能模塊的實現,由于氣瓶配送
    及其信息管理系統的模塊眾多,這里僅對重點模塊進行了介紹。并對各個模塊相 應的數據表和實現通過界面展示、流程圖分析、關鍵技術實現步驟等方式進行了 簡要說明。
    第五章 系統的測試
    在成功實現氣瓶配送及其信息管理系統的基礎上,有必要為系統建立相應的 測試用例,發現氣瓶配送及其信息管理系統中存在的問題,并進一步完善該系統。 功能測試主要是指測試系統中各個模塊的主要功能的運行效果是否達到需求分析 時要求的效果,采用測試用例表的形式對以上模塊的功能進行測試,下面將分別 介紹各個模塊的測試情況。
    5.1 測試環境
    對于測試環境,在測試時測試環境應該盡量接近實際部署環境,確保測試得 到的結果對于實際部署運行結果具有較強的參考價值。根據氣瓶配送及其信息管 理系統預計部署情況,在實驗室搭建了模擬環境,測試環境分為數據庫服務器部 署環境、應用服務器部署環境和客戶端測試機環境,具體部署情況見表 5-1:
    表 5-1 測試環境說明
    數據庫服務器物理機
    硬件配置 軟件配置
    CPU Inter i3-2330M 2.2GHz 操作系統 CentOS Linux 6.5 64bit
    內存 4GB 數據庫 MySql 5.7
    硬盤 500GB
    描述 氣瓶配送及其信息管理系統數據存儲
    應用服務器物理機
    硬件配置 軟件配置
    CPU Inter i3-2330M 2.2GHz 操作系統 CentOS Linux 6.5 64bit
    內存 4GB 應用服務器 Tomcat7
    硬盤 500GB Java版本 JDK8
    描述 氣瓶配送及其信息管理系統服務器部署
    測試物理機
    CPU Inter i5-2330M 3.2GHz 操作系統 Windows 7 64bit
    內存 8GB 瀏覽器 Mozilla Firefox 5& 0.2
    硬盤 1TB
    5.2 配送路徑測試
    根據加氣站一段時間內的氣瓶配送需求,結合客戶要求的氣瓶配送時間窗口, 對加氣站8輛配送車輛安排氣瓶配送,客戶點為30個。按照基于聚類的遺傳禁忌 算法和 VRPTW 模型進行路線規劃,得到 6 條配送路線及其預計到達客戶點的配 送時間如下表5-2 所示。其中“1”表示加氣站,其他數字表示各個客戶氣瓶配送 訂單編號。
    表 5-2 實際線路表
    序號 行駛路線 車型 發車和到達客戶時間表
    1 1-5-3-30-21-1 Z 8:30--8:54--9:10--9:46--10:12--10:36
    2 1-4-26-20-24-10-1 X 8:30--8:52--9:23--9:54--10:22--10:54--11:33
    3 1-2-29-18-25-16-1 X 9:00--9:33--9:44--10:26--10:57--11:38--12:08
    4 1-9-15-12-8-1 Y 10:00--10:34--11:04--11:49--12:06--12:32
    5 1-23-27-13-7-6-1 X 10:00--10:33--11:17--12:36--14:38--15:39--16:04
    6 1-11-14-17-19-22-28-1 Y 13:00--13:34--14:04--14:36--15:05--15:34--16:21--16:47
    通過測試,完成了路線規劃功能,客戶要求的氣瓶配送數量可以全部滿足, 客戶要求的配送時間絕大部分都可以滿足。經過計算,該部分的路線規劃可以能 夠達到有效減少配送成本的目的,該部分功能測試成功。
    5.3 銷售管理測試
    5.3.1 采購庫存管理
    表 5-3 采購模塊測試用例表
    測試用例 米購模塊
    用例說明 采購模塊功能測試 測試結果
    采購計劃 1、 采購業務員登錄系統,新增采購計劃單, 修改、查看、刪除采購計劃單
    2、 采購管理員登錄系統,采購計劃單審核, 采購計劃單狀態改變
    3、 采購計劃單打印 正常
    采購訂單 1、 采購管理員登錄系統,采購訂單增刪改查
    2、 采購記錄多條件查詢
    3、 采購記錄打印 正常
     
     
    表 5-4 庫存模塊測試用例表
    測試用例 庫存模塊
    用例說明 庫存模塊功能測試 測試結果
    庫存管理 1、 庫存管理員登錄系統,進入庫存信息查詢
    2、 庫存信息分類條件查詢
    3、 庫存信息打印 正常
    入庫管理 1、 讀取手持設備數據文件,入庫信息錄入, 更新庫存信息
    2、 庫存管理員登錄系統,入庫信息增刪改查
    3、 入庫信息打印 正常
    出庫管理 1、 讀取手持設備數據文件,岀庫信息錄入, 更新庫存信息
    2、 庫存管理員登錄系統,岀庫信息增刪改查
    3、 岀庫信息打印 正常
     
    5.3.2 銷售配送管理
    表 5-5 銷售模塊測試用例表
    測試用例 銷售模塊
    用例說明 銷售模塊功能測試 測試結果
    新增訂單 1、 銷售員登錄系統,錄入新增訂單信息
    對訂單信息進行修改,刪除
    2、 訂單打印 正常
    訂單查詢 1、 銷售管理員登錄系統,查詢銷售訂單
    2、 對銷售訂單進行修改、刪除、多條件查詢
    3、 銷售訂單打印 正常
    訂單配送 1、 銷售管理員登錄系統,錄入該時段所有配 送訂單地址,點擊生成路線按鈕,生成配送 路線
    2、 對配送路線和訂單信息進行查看和修改
    3、 配送訂單打印 正常
    配送回執 1、 讀取手持設備配送回執數據文件
    2、 配送訂單信息完整查詢
    3、 配送信息打印 正常
     
     
    表 5-6 配送路線模塊測試用例表
    測試用例 配送路線模塊
    用例說明 配送路線模塊功能測試 測試結果
    位置信息 1、 輸入配送地址,獲取各個地址位置信息
    2、 計算各個配送地之間的距離 正常
    生成路線 1、 生成配送訂單路線,確認配送路線
    2、 打印配送訂單 正常
     
    5.4 氣瓶管理測試
    5.4.1 加氣信息管理
    表 5-7 加氣信息模塊測試用例表
    測試用例 加氣信息模塊
    用例說明 加氣信息模塊功能測試 測試結果
    車輛加氣信息 1、 獲取加氣機數據文件,更新加氣信息
    2、 管理員登錄系統,查看加氣信息
    3、 打印車輛加氣信息 正常
    氣瓶加氣信息 1、 管理員登錄系統,查看氣瓶加氣信息
    2、 打印氣瓶加氣信息 正常
     
    5.4.2 氣瓶信息管理
    表 5-8 氣瓶信息模塊測試用例表
    測試用例 氣瓶信息模塊
    用例說明 氣瓶信息模塊功能 測試結果
    氣瓶信息管理 1、 管理員登錄系統,查看氣瓶信息
    2、 點擊獲取位置,查看氣瓶位置信息
    3、 氣瓶信息增刪改查
    4、 打印氣瓶信息 正常
    氣瓶充裝信息 1、 管理員登錄系統,通過手持設備獲取充 裝信息,讀取充裝設備數據文件
    2、 更新充裝記錄,分類多條件查詢
    3、 打印充裝信息 正常
    氣瓶檢驗信息 1、管理員登錄系統,通過手持設備獲取檢 驗信息,讀取充裝設備數據文件 正常
     
     
    2、 更新檢驗記錄,分類多條件查詢
    3、 打印充裝信息
    氣瓶報廢信息 1、 管理員登錄系統,更新報廢氣瓶信息
    2、 分類多條件查詢
    3、 短信通知用戶報廢信息
    4、 打印充裝信息 正常
     
    5.5 信息管理測試
    5.5.1 用戶設備管理
    表 5-9 用戶模塊測試用例表
    測試用例 客戶模塊
    用例說明 客戶功能測試 測試結果
    客戶信息 1、 以系統管理員身份進入系統,查看客戶信 息,對客戶信息進行增刪改查操作,多條件 分類查詢
    2、 打印客戶信息 正常
    員工信息 1、 管理員登錄系統,查看員工信息,對員工 信息進行增刪改查工作,多條件分類查詢
    2、 打印員工信息 正常
    供應商信息 1、 管理員登錄系統,查看供應商信息,對信 息進行增刪改查,多條件分類查詢
    2、 打印供應商信息 正常
     
     
    表 5-10 設備模塊測試用例表
    測試用例 設備模塊
    用例說明 設備模塊功能測試 測試結果
    設備信息 1、 管理員登錄系統,對設備信息進行增刪改 查,多條件分類查詢
    2、 獲取設備位置信息
    3、 數據傳輸試驗 正常
    車輛信息 1、 管理員登錄系統,對車輛信息進行增刪改 查,多條件分類查詢
    2、 獲取車輛位置信息 正常
     
     
    5.5.2 充值信息管理
    表 5-11 充值信息管理模塊測試用例表
    測試用例 用戶模塊
    用例說明 用戶模塊功能測試 測試結果
    會員信息 1、 管理員登錄系統,查看會員信息,對會員 信息進行增刪改查操作,多條件分類查詢
    2、 打印會員信息 正常
    充值信息 1、 管理員登錄系統,查看充值信息,對充值 信息進行增刪改查工作,多條件分類查詢
    2、 聯合IC卡對管理員賬戶進行充值,驗證 充值操作正確性
    3、 打印充值信息 正常
    扣費信息 1、 管理員登錄系統,查看扣費信息,對信息 進行增刪改查,多條件分類查詢
    2、 聯合 IC 卡對管理員賬戶進行扣費,驗證 扣費操作正確性
    3、 打印扣費信息 正常
     
    5.5.3 統計報表管理
    表 5-12 統計報表模塊測試用例表
    測試用例 統計報表模塊
    用例說明 統計報表模塊功能測試 測試結果
    銷售 1、 管理員登錄系統,查看會員信息,對會員 信息進行增刪改查操作,多條件分類查詢
    2、 打印會員信息 正常
    庫存報表 1、 管理員登錄系統,查看充值信息,對充值 信息進行增刪改查工作,多條件分類查詢
    2、 聯合 IC 卡對管理員賬戶進行充值,驗證 充值操作正確性
    3、 打印充值信息 正常
    扣費信息 1、 管理員登錄系統,查看扣費信息,對信息 進行增刪改查,多條件分類查詢
    2、 聯合 IC 卡對管理員賬戶進行扣費,驗證 扣費操作正確性 正常
     
     
    5.6 系統管理測試
    表 5-13 系統管理模塊測試用例表
    測試用例 系統管理模塊
    用例說明 系統管理模塊功能測試 測試結果
    賬戶信息 1、 管理員登錄系統,查看賬戶信息,對賬戶 信息進行增刪改查操作
    2、 個人用戶登錄系統,對賬戶信息進行查看 和修改 正常
    角色管理 1、 管理員登錄系統,查看系統角色
    2、 根據不同職務,賦予不同職務人相應角色
    3、 驗證不同用戶登錄時,訪問模塊和操作是
    否與角色權限一致 正常
     
    5.7 測試結論
    按照缺陷對系統的BUG影響程度可以將缺陷分為五類:一級缺陷(致命錯誤)、
    二級缺陷(嚴重錯誤)、三級缺陷(簡單錯誤)、四級缺陷(微小錯誤)、五級缺陷
    (建議修改)。統計測試結果,對測試數據統計如下表 5-14 所示:
    表 5-14 測試數據統計說明
    測試缺陷以及處理統計 合計
    缺陷類型 一級缺陷 二級缺陷 三級缺陷 四級缺陷 五級缺陷
    發現問題數 0 5 56 7 0 68
    累計缺陷數 0 5 56 7 0 68
    缺陷修復數 0 5 55 7 0 67
    修復率 - 100% 98.21% 100% - 98.52%
     
    在本次測試中,達到了全部測試需求,二級缺陷和四級缺陷修復率均達到了
    100%,缺陷嚴重程度分布圖如下圖 5-1 所示。
    缺陷嚴重程度分布圖
    10% 7% ■一級缺陷
    ■二級缺陷
    ■三級缺陷
    ■四級缺陷
    ■五級缺陷
    圖 5-1 缺陷嚴重程度分布圖
    本次測試對氣瓶配送及其信息管理系統的基礎功能進行了全面測試,經過嚴 格的測試,現在該系統主要功能已經全部實現,目前系統運行穩定,本次測試達 到了測試目的,測試通過。
    5.8 本章小結
    本章首先根據系統部署情況,描述了系統測試的環境,然后按照系統主要模 塊(配送路徑管理、銷售管理、氣瓶管理、信息管理、系統管理)列出了測試表, 測試表中包括測試用例、測試過程、測試結果。最后對測試結論通過表格和分布 圖的形式進行了分析。
    第六章 總結與展望
    6.1 主要工作及結論
    加氣站的氣瓶配送成本一直是困擾氣瓶配送的難題,傳統的氣瓶配送方式主 要靠配送人員的經驗進行安排。同時氣瓶的安全管理工作一直是氣瓶行業的重點, 但氣瓶爆炸事故仍時有發生,因此研究氣瓶的配送及其安全管理工作就十分有意 義。結合加氣站的業務需要,利用目前最新的配送路徑方面的算法、互聯網技術 以及物聯網技術,緊密結合氣瓶流通的每一個環節,實現氣瓶配送路徑優化以及 流通的追蹤,在此基礎上開發了一套氣瓶配送及其信息管理系統,減少配送成本, 加強氣瓶的監管。
    本文總體從三個方面進行總結如下:
    (1)加氣站傳統的配送方式較為落后,主要依靠配送人員的經驗安排配送, 導致配送成本居高不下,隨著氣瓶配送量的增長,迫切需要對配送路徑進行優化。 本系統根據客戶需求,建立了帶有時間窗口的多車輛氣瓶配送數學模型,并針對 傳統物流配送算法容易陷入局部最優等缺點,提出了以最小成本為目標函數的基 于聚類的遺傳禁忌混合算法完成配送路徑的規劃,節約了企業經營成本。
    (2)隨著社會對各類氣體的需要,越來越多的民營加氣站出現,但是目前許 多加氣站的管理方式還比較落后,還是粗放式的的管理方式,氣瓶的監管工作還 比較落后,還未進行信息化建設,結合加氣站實際情況,對加氣站的業務進行了 仔細分析,充分考慮了氣瓶流通的每一個環節,讓氣瓶的采購、入庫、充裝、出 庫、銷售、配送、回收、報廢等每一個環節都有記錄可以查詢、全面實現氣瓶的 追蹤。
    (3)對氣瓶配送及其信息管理系統進行測試。首先為每一個部分設計測試用 例,然后分別進行測試,并記錄測試數據,對測試過程中出現的數據傳輸、界面 友好等問題進行了改進,以便提供更好的用戶體驗。
    本文的工作重點是:
    (1) 在氣瓶的銷售配送環節,結合氣瓶配送的特殊性,改進了配送問題數學模 型,并且加入訂單聚類處理,改進了遺傳禁忌算法,達到了節約企業氣瓶配送成 本的目的。
    (2) 在氣瓶的流通環節上增加了定位處理,可以追蹤到氣瓶的位置,對氣瓶流 通的每一個環節進行信息化處理,實現了對氣瓶的追蹤溯源。
    6.2 研究展望
    氣瓶配送及其信息管理系統基于加氣站的管理需要,實現了對氣瓶的配送路 徑規劃和氣瓶信息化的管理,由于類似加氣站還有很多,并且業務大多相似,因 此本系統可以推廣到其他加氣站使用。同時本系統設計之初就對擴展性進行了考 慮,所以推廣到其他加氣站相對比較容易。但由于本人能力有限,氣瓶配送及其 信息管理系統還有諸多地方考慮不夠完善,因此,許多地方還有待進一步研究:
    (1) 手機端問題
    隨著移動互聯網的發展,相關的系統不僅僅局限于 PC 端,還要開發移動端, 基于Android、IOS平臺開發,實現管理更加靈活,提高工作效率,同時使系統使 用更加方便。
    (2) 配送動態需求問題 本系統中氣瓶銷售環節主要是客戶提前預定訂單,然后企業安排集中配送, 在數學模型上比較固定,未考慮在配送過程中的動態需求,未來可以考慮在配送 過程中根據需求變化及時調整配送策略。
    致 謝
    時光荏苒,我的碩士生涯已接進尾聲。這幾年的時光既漫長又短暫,其中充 滿了酸甜苦辣,更有收獲和成長。三年來,感謝陪我一起度過美好時光的每位尊 敬的老師和親愛的同學,正是你們的幫助,我才能克服困難,正是你們的指導, 我才能解決疑惑,直到學業的順利完成。
    感謝我的導師楊忠孝老師,感謝楊老師對我的淳淳教誨和悉心關懷。從課題 的選擇、項目的實施,直至論文的最終完成,楊老師都始終給予我耐心的指導和 支持,我取得的每一點成績都凝聚著楊老師的汗水和心血。楊老師開闊的視野、 嚴謹的治學態度、精益求精的工作作風,深深地感染和激勵著我,在此謹向楊老 師致以衷心的感謝和崇高的敬意。
    感謝模式識別與智能控制團隊的所有老師,因為有你們的教導,讓我能夠在 一個溫馨和睦的環境中學習。感謝朱宏老師為我們提供了一個良好的學習平臺。 感謝曾老師對每一個學生的關愛,您愛生如子的精神深深感染者每一個人。感謝 張榆平老師,很榮幸能夠進入您的課題組學習,感謝您的悉心指導,為我們指明 了學習的方向。感謝胡江平老師,您嚴謹治學的學術態度和刻苦專研的科研精神, 讓大家受益匪淺,是我們學習的榜樣。
    感謝教研室的所有同學,我的成長了離不開教研室的兄弟姐妹們,感謝你們 三年來的陪伴,我們作為一個團隊,一起共同奮斗、共同前進。你們給了我太多 幫助,我們一起成長,一起學習,共同進步,其樂融融,沒有你們,就沒有我的 美好校園生活。
    感謝趙天齊、周鑫、羅安源、張二超、胡玖、黃子城、李巧玲、游梨譽、陶 田、孫怡心、李繼樂等同學,從研一大家一起上課到研三找工作到畢業論文的完 成,你們的每一次陪伴都給我帶來莫大的溫暖。
    感謝李朋、菅壟、謝文倩等師兄師姐,感謝你們在畢業設計上悉心為我指導 學習問題,耐心解答我的各種疑惑。感謝你們為我提供的慷慨幫助。衷心的希望 大家都能實現自己的夢想,生活美好!
    感謝我的父母和親朋好友,感謝你們一直的鼓勵與支持,你們是我永恒的動 力和避風的港灣!
    感謝電子科技大學的培養,讓我能夠在這么好的平臺去開闊眼界,認識世界。
    最后,同時感謝百忙之中抽空參加評閱工作的老師們,你們辛苦了!
    參考文獻
    [1]鄧必年.基于蟻群優化算法的物流配送路徑研究J].現代電子技術,2017(15)
    [2]管義鋒,房善釗,趙世超,等.艙內氣體爆炸載荷下 CNG 運輸船貨艙結構動態響應研究
    (英文)[J].船舶力學,2018(3)
    ⑶趙保頔,張博,胡熙玉,等.長管拖車氣瓶火災分析及局部起火超壓泄放試驗研究J].壓 力容器,2018(1):57-62
    [4]黃浩.供應鏈環境下物流配送路徑的蟻群算法優化J].物流技術,2015(06)
    [5]申燕光,張玲玉,劉永紅.基于混合遺傳算法的物流路徑優化方法研究J].計算機技術與 發展,2017,12(6)
    [6]Abdulkader M M S, Gajpal Y, Elmekkawy T Y. Hybridized ant colony algorithm for the Multi Compartment Vehicle Routing Problem[M]. Elsevier Science Publishers B. V. 2015
    [7]李思國,郭宇,王益聰,吳旗,葛研嬌.基于改進遺傳算法的物料配送路徑實時規劃方法 [J].南京航天航空大學校學報,2017,(12):786-792
    [8]Talibi M, Balachandran R, Ladommatos N. Influence of combusting methane-hydrogen mixtures on compression-ignition engine exhaust emissions and in-cylinder gas composition[J]. International Journal of Hydrogen Energy, 2017, 42(4):2381-2396
    [9]石建力,張錦.行駛時間隨機的分批配送車輛路徑問題模型與算法J].計算機應 用,2018,38(2):573-581
    [10]邱晗光,周愉峰.基于嵌套Logit選擇模型的城市配送自提柜選址-路徑問題[J].計算機 應用,2018,38(2):582-588
    [11]廖大強,鄔依林,印鑒.基于禁忌搜索算法的線路規劃方案求解[J].計算機工程與設 計,2015(5):1368-1374
    [12]Gallo Y, Malmborg V B, Simonsson J, et al. Investigation of late-cycle soot oxidation using laser extinction and in-cylinder gas sampling at varying inlet oxygen concentrations in diesel engines[J]. Fuel, 2017, 193:308-314
    [13]張立峰,易萬里,劉曉蘭.基于兩階段算法的大規模成品油二次配送優化J].系統工程理 論與實踐,2016,36(11):2951-2963
    [14]王茜,吉清凱,胡祥培.多車型多車槽VRP的混合導引反應式禁忌搜索算法[J].管理工 程學報,2016(3):179-187
    [15]殷文正,姜衛東,陶金.基于禁忌搜索算法的AUV動態路徑規劃策略[J].南京大學學報 (自然科學),2017,53(1):144-150.Vermesan O, Friess P, Guillemin P, et al. Internet of things strategic research roadmap. Internet of Things-Global Technological and Societal Trends. 2016
    [16]黎宙.基于混合智能算法的物流配送優化的研究[D].華南理工大學,2016
    [17]Yu B, Qin Y. Generating test case for algebraic specification based on Tabu search and genetic algorithm[M]. Kluwer Academic Publishers, 2017
    [18]Popovic D, Vidovic M, Radivojevic G. Variable neithborhood search heuristic for the inventory routing problem in the fuel delivery[J]. Expert Systems with Applications, 2012, 39(18): 13390-13398
    [19]吳瑤,馬祖軍.時變路網下帶時間窗的易腐食品生產-配送問題J].系統工程理論與實 踐,2017,37(1):172-181
    [20]Avella P, Boccia M, Sforza A. Solving a fuel delivery problem by heuristic and exact approaches[J]. European Journal of Operational Research, 2014, 152(1):170-179
    [21]王志堅,王曉博,李一軍.一體化集貨和配送車輛路徑問題的混合遺傳啟發式算法J].系 統管理學報,2015,18(3):338-343
    [22]余璇,梁工謙,董仲慧.基于混合遺傳禁忌搜索算法的多目標柔性作業車間調度[J].機 械制造, 2016, 54(8):90-93
    [23]葉威惠,張飛舟.真實路況下的快遞配送路徑優化研究[J].計算機工程與科 學,2017,39(8):1530-1537
    [24]馬義飛,孫曉燕.成品油二次配送調度優化模型及其遺傳算法求解[J].運籌與管 理,2016,19(6):73-78
    [25]Hitacontreras F. Traditional body mass index cut-offs in older people: Time for a rethink with altered fat distribution, sarcopenia and shrinking height.[J]. Maturitas, 2018
    [26]Zak G, Wylomanska A, Zimroz R. Local damage detection method based on distribution distances applied to time-frequency map of vibration signal[J]. IEEE Transactions on Industry Applications, 2018, PP(99):1-1
    [27]王毅敏•云計算環境下軟件架構恢復系統設計[J].現代電子技術,2017, 40(23):27-29
    [28]Hao Z, Novak E, Yi S, et al. Challenges and Software Architecture for Fog Computing[J]. IEEE Internet Computing, 2017, 21(2):44-53
    [29]Zhang B L. Migration and Optimization of C/S Model Network Management System to B/S Model[J]. Computer Systems & Applications, 2017
    [30]Yang S. Towards a hybrid software architecture and multi-agent approach for autonomous robot software[J]. International Journal of Advanced Robotic Systems, 2017
    [31]Tamburri D A, Kazman R. General methods for software architecture recovery: a potential approach and its evaluation[J]. Empirical Software Engineering, 2017(4):1-33
    [32]胡應坤,湯才,趙文龍,等•基于B/S架構的智能家居控制系統設計與實現J]•科技與創新, 2017(4):118-119
    [33]趙可可,柴志雷,吳東.一種基于Zynq的ROS軟硬件協同計算架構設計與實現[J].微電 子學與計算機, 2017, 34(9):87-91
    [34]Le N N, Blanc E F, Phan H C T, et al. A RFID-based wireless NH3 gas detector using spin coated carbon nanotubes as sensitive layer[J]. International Journal of Nanotechnology, 2018, 15(1/2/3):3
    [35]Brandao F B, Ferreira J C E, Schwanke D, et al. RFID Technology as a Life Cycle Management Tool in the Liquefied Petroleum Gas Industry[J]. IEEE Latin America Transactions, 2018, 16(2):391-397
    [36]Tschirschwitz R, Krentel D, Kluge M, et al. Mobile gas cylinders in fire: Consequences in case of failure[J]. Fire Safety Journal, 2017, 91
    [37]Garcia F, Guijarro F, Oliver J. Index tracking optimization with cardinality constraint: a performance comparison of genetic algorithms and tabu search heuristics[J]. Neural Computing & Applications, 2017:1-17
    [38]李娟,郭新鵬,劉麗梅.RFID技術在液化石油氣瓶安全管理中的應用[J].工業安全與環 保,2017,3:55-58
    [39]Mi E K, Ji H K, Yong D K, et al. Development of accurate dimethyl sulphide primary standard gas mixtures at low nanomole per mole levels in high-pressure aluminium cylinders for ambient measurements[J]. Metrologia, 2018
    [40]萬軍,蔣燕蓉,王洪元,等•基于ZigBee技術的新型液化氣灌裝系統[J].儀表技術與傳感 器, 2013(6):82-85
    [41]魏鳳,劉志碩.物聯網與現代物流[M].電子工業岀版社,2012年8月
    [42]Samini Subramaniam, Su-Cheng Haw, Pool Kuan Hoong.S-XML:An efficient mapping scheme to bridge XML and relational database[J].Knowledge-based systems,2016,(27): 45-60
    [43]王吉茂,尹平•軟件測試用例執行優化研究J] •計算機工程與設計,2013,34(12):345-349
    [44]Kirk, D.Tempero, E.A lightweight framework for describing software practices[J].The Journal of Systems and Software,2012,85(3):67-71
    [45]Chunguo Xu, Guangsheng Ren, Yongqiang Guo, et al. Tube Necking Extrusion Principle
    and Forming Process of Trailer Rear Axle[J]. Procedia Engineering . 2014
    [46]李敏,倪少權,周凌等.基于訂單鄰域的成品油二次配送中帶時間窗車輛路徑規劃問題 [J].計算機集成制造系統,2015,21(8):2158-2169
    [47]戚銘堯,張金金,任麗.基于時空聚類的帶時間窗車輛路徑規劃算法J].計算機科 學,2014,41(3):218-222
    [48]馬義飛,孫曉燕•成品油二次配送調度優化模型及其遺傳算法求解[J].運籌與管 理,2010,19(6):73-78
    [49]葛顯龍,王旭,代應.基于混合量子遺傳算法的隨機需求車輛調度問題[J].系統工 程,2011(3):53-59
    [50]王文蕊,吳耀華•考慮變動成本的車輛路徑問題建模及求解[J].計算機集成制造系 統,2014,20(4):979-987
    【本文地址:http://www.bzhlmm.com//guanlilei/gongshangguanli/xixinguanli/8975.html

    上一篇:安陽市中小企業客戶信息管理系統的設計

    下一篇:沒有了

    相關標簽: