基于“互聯網+”的智能導游調度管理系統

張 新， 季偉男， 龐勝利

(西安郵電大學 電子工程學院，西安 710121)

0 引 言

隨著“互聯網+”技術快速發展，以及物聯網技術與信息技術的不斷融合，智慧旅游已經成為“互聯網+”應用的新興熱點行業，為提升旅游產業的經營管理模式，加快旅游經濟發展，提升游客客戶體驗，“互聯網+”提供了新的技術和服務平臺[1-2]。

根據研究，旅游產生的噪聲污染對旅游體驗產生了不可彌補的傷害，因此進行降低噪聲游覽就成未來導游發展的趨勢；同時對景區導游實時在線進行管理也非常迫切，可大大提升景區的管理水平[3-4]。

智能導游調度管理系統設計的提出，對景區導游調度以及管理進行了智能化的規范、實時監測以及評價。設計了完善的景區工作人員的行為規范，保障了景區的管理秩序，解決了上述的問題。

1 智能導游調度管理系統的綜述

1.1 系統功能設計

導游調度管理系統功能結構包括管理員權限管理、導游機管理、導游管理、評價信息、獎懲信息、操作員管理、游客機管理、系統設置、導游分組、數據分析、操作日志、藍牙設備管理?？傮w框圖如圖1所示。

圖1 智能導游調度管理系統功能框圖

1.2 部分功能模塊及說明

(1) 管理員模塊。系統管理時操作員分為兩種管理角色，一個為普通管理員、一個為超級管理員，超級管理員具有管理導游機、導游、進行所有操作的權限，普通管理員只具有查看以及分配的權限，沒有增加、刪除或修改的權限。

(2) 導游機管理。導游機主要將需要的數據采集后上傳至服務器，在導游機管理中，后臺管理員將導游機指派給導游，同時錄入導游機、導游編號,游客機數量作為數據備份。且分派時立即打印其派遣單。在導游機狀態管理中，后臺可以實時更新并且查看所有導游機的使用情況，便于對導游機進行維護操作。

(3) 導游管理。管理員進行導游管理時，針對本月導游的游客評價情況對導游進行請假、借調、停職等操作；基本信息欄中，可以查看、修改、刪除導游基本信息。在線導游模塊中可以直接查看導游當前的實時地圖位置以及導游本次帶團的實際人數的熱力圖。路徑詳情模塊可以查看歷史導游每一次的帶團的地圖路徑圖。判斷導游是否路徑符合其景區范圍要求。帶團覽圖記錄了導游帶團路徑、本月/本日各時間段客流分析圖、評價星級占比和帶團時間比例的柱狀圖以及餅圖。管理人員可為在線導游實時推送語音及文字消息，后臺可直接進行遠程控制，來實時監聽導游的講解情況。該模塊成為約束景區規范較為重要的模塊。

(4) 評價信息。評價信息功能列出游客對導游評價明細，包括初始評分(導游本屬性:學歷，語言等)和帶團評分詳情，通過內部自身算法計算出本月導游的總評分。通過該評分對導游的業績進行獎勵或懲罰。規范了景區的導游制度，塑造了良好的景區環境。

(5) 數據分析。數據分析功能中數據由系統中導游機上傳至數據庫數據提供，通過提供的數據繪制了4種圖，分別為：目前在線導游熱力圖、各時間段客流分析圖(柱狀圖)、評價星級占比圖(餅圖)、帶團時間比例圖(餅圖)。其中各時間段客流分析圖、評價星級占比圖、帶團時間比例圖可以在本月和本日進行切換。通過該圖，可直觀分析景區的各個情況，通過這些圖制作相對應的景區管理計劃[5-6]。

(6) 導游分組。在景區中需要分配多個模塊，來進行高效的導游指派，導游分組模塊主要針對導游所在區域劃分及分配設計，分組模塊可設置導游所在景區的區域(景區被分為若干個區)某個組中，這樣進行管理導游區域與分組時，管理就會變得比較靈活。

1.3 系統體系結構

根據系統設計的相關流程，整個系統的設計模型如圖2所示。

圖2 系統模型

由圖2可以看出，各種設備都具有其特定的功能。各個設備之間的通信，相對獨立。最后將各部分所采集到的數據以特定的協議傳輸到遠程服務器中。管理員通過PC遠程訪問服務器獲取服務器中的數據，將數據呈現到瀏覽器中進行管理。保證了信息的流暢以及管理的便利性[7-8]。

為了詳細反映系統中模塊調用關系和層次關系。本系統結構如圖3所示。由圖3可見，Web端作為終端應用層作為顯示，通過從服務器中獲取采集到的數據源[9]。為景區管理人員提供了操作的數據，保證了信息準確性以及數據的實時性。系統實現層具有3個功能模塊，后臺將收到的數據進行實時評估分析，對景區人群分布進行控制、監聽導游的講解、規劃導游的行走帶團路線、繪制所需要數據的報表、對遠程數據倉庫進行更新保存管理。系統底層提供了系統所使用的各類技術，支持了該系統的實現。

圖3 系統結構

2 系統使用關鍵技術

2.1 Struts2+Spring+Hibernate設計框架

傳統開發中開發人員在建立解決復雜問題方案時會花費大量的時間和精力，而一開始設計的后臺系統代碼可拓展性不是很強，而大量代碼之間存在耦合性，常常遇到軟件開發到一定程度時由于客戶需求發生了變化，使得軟件的實現不得不隨之改變，這樣滿足需求的方式往往需要極大的工作時間消耗。本項目引用SSH框架有效的解決了上述問題。

(1) 表示層。首先通過JSP頁面實現交互界面，負責傳送請求(Request)和接收響應(Response)，然后Struts根據配置文件(struts-config.xml)將ActionServlet接收到的Request委派給相應的Action處理，然后Action進行對請求處理并轉發給JSP頁面[10]。

(2) 業務邏輯層。管理服務組件的Spring IoC容器負責向Struts2提供具體的Action對象[11]，提供業務模型(Model)組件和該組件的協作對象數據處理(DAO)組件完成業務邏輯，并提供事務處理、緩沖池等容器組件以提升系統性能和保證數據的完整性。

(3) 數據訪問層。則依賴于Hibernate的對象化映射和數據庫交互，處理DAO組件請求的數據，并返回處理結果，給業務邏輯層。

按照MVC模式：Jsp對應著表現層，Struts2對應控制層，Spring和Hibernate對應模型層[12]。見圖4。

圖4 MVC架構

2.2 百度地圖API

為實現查看導游帶團的帶團路徑分析，以及當前導游在線地點以及導游攜帶人數做成路徑圖和熱力圖顯示在網頁中。在導游管理中需要實時了解當前在線導游的實時位置以及帶團人數，保證后臺可向傳達景區人口聚集地，方便對導游進行帶團路線的靈活更改。由于當下可供開發者選擇的地圖API目前不多，并且自己制作地圖開發，需要大量的時間以及文檔的學習。分析所需實現的功能本系統采用百度地圖API接口來生成地圖信息[13-14]。

后臺需將由導游機傳遞來的經緯度信息，以及帶隊人數，進行坐標變換后，利用JSP技術將后臺經緯度數據變成JSON格式傳至前端界面。通過調用百度地圖API接口中不同對應功能的地圖模塊的方法來構建相應的功能地圖。

2.3 網頁語音錄制及上傳

傳統推送消息往往只是進行文字的數據傳輸而在輸入方式上，人們總是在追尋一種更高效，門檻更低的方式，來降低用戶使用產品的學習成本。語音輸入也是一種嘗試較多的方式，有些直接使用語音(如微信語音聊天)，有些需要將語音轉化為文字(語音識別)。系統引用語音傳輸信息的思想來進行數據之間的消息通信傳遞。

在管理系統需要從后臺實時向導游機端推送語音消息，這就需要在后臺瀏覽器界面錄音并且上傳。錄音的主要步驟就是使用navigator.getUserMedia來獲取用戶的輸入設備，成功之后使用webkitAudioContext來創建音頻實例。在錄音結束之后，將錄音的流導出為文件，上傳至服務器[15-16]。

// 資源交換文件標識符

writeString('RIFF'); offset += 4;

// 下個地址開始到文件尾總字節數，即文件大小-8

data.setUint32(Offset, 36 + dataLength, true); offset +=4;

// WAV文件標志

writeString('WAVE'); offset += 4;

// 波形格式標志

writeString('fmt'); offset += 4;

// 過濾字節，一般為0×10=16

data.setUint32(offset, 16, true); offset += 4;

// 格式類別(PCM形式采樣數據)

data.setUint16(offset, 1, true); offset += 2;

// 通道數

data.setUint16(offset, channelCount, true); offset += 2;

// 采樣率,每秒樣本數,表示每個通道的播放速度

data.setUint32(offset, sampleRate, true); offset += 4;

// 波形數據傳輸率(每秒平均字節數) 單聲道×每秒數據位數×每樣本數據位/8

data.setUint32(offset, channelCount * sampleRate * (sampleBits / 8), true); offset += 4;

// 快數據調整數 采樣一次占用字節數 單聲道×每樣本的數據位數/8

data.setUint16(offset, channelCount * (sampleBits / 8), true); offset += 2;

// 每樣本數據位數

data.setUint16(offset, sampleBits, true); offset += 2;

// 數據標識符

writeString('data'); offset += 4;

// 采樣數據總數,即數據總大小-44

data.setUint32(offset, dataLength, true); offset += 4;

2.4 實時語音監聽

為實現遠程監聽導游機的功能，即通過前臺可以實時監聽后臺的語音數據，且后臺無法發覺。而當前普遍的做法是在服務端與客戶端之間建立一個長連接，客戶端A將消息發送給服務端，服務端再將消息轉發給客戶端B。而如何建立一個長連接實現客戶端與服務端的通信，以及保證連接的質量與低耗電，低耗流量是一個難題。而使用運營商公網又是不可進行負擔的。本項目基于上述問題，使用了一種全新的算法來解決當前問題：使用后臺dephi程序一直監聽數據庫某一字段，當后臺需要傳送命令時，dephi監測到字段的變化，向手機端發送啟動監測信號，手機端接收到指令開始錄制語音并且向服務器通過HTTP上傳錄制的語音，為了使得播放流暢，將上傳的音頻文件分成5 s一個分批次的上傳，在服務端監測到數據上傳時開始播放已經上傳的語音文件。巧妙地通過上述方法達到了預期的效果。而監聽效果只會損失4～5 s的第一次上傳時間的延遲。

3 系統測試

目前系統的開發工作已經完成。系統利用導游設備和服務器、PC后臺相互信息的遠程傳遞，體現出了物聯網的概念。該系統已經在秦始皇兵馬俑景區進行了試運行，后臺系統截圖如圖5所示。景區相關工作人員通過佩戴導游機設備，向佩戴游客機設備游客講述景區歷史文化信息。智能導游調度管理系統通過分析當前游客在景區的在線分布位置，對擁擠的地域采用限流或者主動轉移人群策略，減少了景區擁堵事件。在導游講解語音的監控時，景區管理員可以選擇在任意時刻，對當前在線導游，進行語音監聽，通過抽查導游講解情況，對導游進行獎勵與懲罰;智能導游調度管理系統可以分析導游每次帶團路徑以及帶團時間的參數，對導游進行每月自動評分，該評分直接影響其獎金的發放,并對景區的發展起到良好促進作用。

圖5 導游路徑圖

4 結 語

為提升旅游產業的經營管理模式，加快旅游經濟發展，提升游客客戶體驗，構建了“互聯網+”和SSH框架的智能導游調度管理系統。該系統以兵馬俑景區作為試點進行運行測試，智能化管理景區。通過細粒度的抽象對外提供的接口，使得系統更易升級和維護，最大限度保證了系統的功能。智能導游調度管理系統的實現，提高了景區的運作效率，得到了導游和游客的好評。鑒于在實際運行中還可能出現不少問題，系統功能豐富性需進一步分析研究。