基于“互联网+”的智能导游调度管理系统

张 新， 季伟男， 庞胜利

(西安邮电大学 电子工程学院，西安 710121)

0 引 言

随着“互联网+”技术快速发展，以及物联网技术与信息技术的不断融合，智慧旅游已经成为“互联网+”应用的新兴热点行业，为提升旅游产业的经营管理模式，加快旅游经济发展，提升游客客户体验，“互联网+”提供了新的技术和服务平台[1-2]。

根据研究，旅游产生的噪声污染对旅游体验产生了不可弥补的伤害，因此进行降低噪声游览就成未来导游发展的趋势；同时对景区导游实时在线进行管理也非常迫切，可大大提升景区的管理水平[3-4]。

智能导游调度管理系统设计的提出，对景区导游调度以及管理进行了智能化的规范、实时监测以及评价。设计了完善的景区工作人员的行为规范，保障了景区的管理秩序，解决了上述的问题。

1 智能导游调度管理系统的综述

1.1 系统功能设计

导游调度管理系统功能结构包括管理员权限管理、导游机管理、导游管理、评价信息、奖惩信息、操作员管理、游客机管理、系统设置、导游分组、数据分析、操作日志、蓝牙设备管理。总体框图如图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框架的智能导游调度管理系统。该系统以兵马俑景区作为试点进行运行测试，智能化管理景区。通过细粒度的抽象对外提供的接口，使得系统更易升级和维护，最大限度保证了系统的功能。智能导游调度管理系统的实现，提高了景区的运作效率，得到了导游和游客的好评。鉴于在实际运行中还可能出现不少问题，系统功能丰富性需进一步分析研究。