基于GIS的旅游团队突发情况管理系统\n技术领域\n[0001] 本发明涉及一种旅游团队管理系统，尤其涉及基于地理信息系统技术（GIS）的旅游团队突发情况管理系统。\n背景技术\n[0002] 近年来，随着科技的发展，众多景区提供随身携带的智能终端服务，在为游客提供景点讲解的同时，获取游客终端位置信息，以实现对游客的动态监控。由于游客对景区地理位置分布缺少认识，又具有不同的年龄、文化背景、兴趣爱好、身体状况等，导致团队中游客行进速度不一，容易走散或掉队；同时，在旅游高峰季节，大量游客涌入，这也为景区的紧急救援服务带来了沉重的负担。为了解决旅游团队突发情况，出现了基于红外感应、内置无线终端、GPS等技术的景区内游客实时监控和定位系统，如专利公告号为CN201974914U的实用新型专利提供了一种基于红外感应的景区游客报警系统，但其效果受到红外通信有效距离的限制；公开号为CN101067654的专利公开了一种基于移动定位技术和ＧＩＳ技术，用户终端借助移动通信网络，实现游客定位、人机对话、旅游团队自能管理的系统；就目前已有的游客监控、团队管理系统来说存在着两个问题：一是单纯的采集和显示游客信息数据，实现监控游客位置，缺少考虑单个游客和整体团队的连续关系以及对游客实时位置信息的深入分析和挖掘；二是手动式的报警、小范围内的设备通讯信号报警以及控制终端目视距离报警具有操作不便、设备的感应距离较短以及操作人员的责任心参差不齐等问题，造成掉队游客的判断缺少准确性和及时性。\n[0003] 而就景区的紧急救援服务来说，现有的移动定位救援系统在处理救援信息时仍大量依靠人工，属于半人工半自动救援。如公开号为CN101448206A的发明专利公开了一种基于GPS的一键求救系统，当用户求救时利用无线网络自动向控制台发送求救者位置；授权号为CN201315615Y的实用新型专利公开了一种基于语音通讯的一键紧急求救系统，当用户连续按动两次求助键后向服务系统发送救援请求，并启动语音服务以便确定用户的基本情况和求助类型。以上专利均未考虑如何根据求助者的位置和求救内容确定救援任务的接收者以及救援的优先级，而是直接将求助信息转发至控制台由人工调度，采用这种方法存在以下缺点：（1）对并发救援请求的处理效率低，无法同时对多个救援任务进行调度；（2）在救援过程中，求助者无法实时了解救援动态，而救助者在前往救援途中也无法知晓求助者的位置移动等信息并做出及时反应和调整。\n发明内容\n[0004] 本发明为了解决现有的旅游团队突发情况处理技术中，掉队游客的监控不到位、救援方法效率低的问题，在移动终端及地理信息系统技术的基础上，通过对游客实时位置信息深入分析，设计出一种能够自动判断及处理旅游团队突发情况的管理系统。\n[0005] 系统包括以下五个部分：移动终端、移动定位系统、移动通信网络、web服务器、GIS管理应用服务器；\n[0006] 移动终端为便携式电脑、WAP手机或者掌上电脑；\n[0007] 移动定位系统是采用GPS技术获取用户经纬度信息，并将此位置信息通过网络发送至移动终端与GIS管理应用服务器的系统；\n[0008] 移动通信网络采用GSM、CDMA或GPRS技术；\n[0009] web服务器是处理与HTTP有关的请求的服务器，用来传输移动终端向GIS管理应用服务器提出的服务请求；\n[0010] GIS管理应用服务器存储了GIS系统模块、旅游团队突发情况管理模块以及详细的道路网、景点信息数据；旅游团队突发情况管理模块包括自动判断掉队游客模块与联动救援模块；\n[0011] 其中，自动判断掉队游客模块包括以下五个部分：\n[0012] （1）距离和生成模块：计算每个游客到其他n-1个游客的n-1个距离值的集合，其中n为团体游客数量；对该集合求和，得到每个游客与其他n-1个游客的距离和；\n[0013] （2）特殊游客生成模块：将每个游客的地理坐标与该游客的距离和组合，生成该团体在该时刻每个游客与团体中其他游客的空间分布距离量值集合，并将其表示在二维笛卡尔坐标系中，根据公开方法“用Origin剔除线性拟合中实验数据的异常值”，得到m个特殊点，m为所述团体中的特殊游客总数，特殊游客是指筛选出来的距离队伍较远或者分布比较离散的游客，将该m个特殊点的地理坐标添加到特殊游客集合中；\n[0014] （3）相对连续区生成模块：对剩下的n-m个游客的距离和求平均值，根据平均值计算团队中两游客间的相对连续距离，以相对连续距离的一半为半径，对每个游客做圆形缓冲区，生成每个游客的相对连续区；\n[0015] （4）主、辅子团体生成模块：对所有的相对连续区做交、并运算，得到若干个子团体，将包含人数最多的子团体作为主子团体，将主子团体以外的所有子团体作为辅子团体；\n[0016] 主、辅子团体生成模块工作流程为：\n[0017] 将某一编号为i的游客的相对连续区设为第一个子团体,游客编号其次累加1；\n[0018] 取编号为i+1的游客的相对连续区，若与已有子团体存在交集，则该相对连续区与子团体求并，替换原来的子团体成为新的子团体；若无交集，则编号为i+1的游客的相对连续区生成新的子团体；添加入已有子团体集合；如此遍历所有相对连续区；\n[0019] 计算每个子团体的游客人数，选择人数最大的子团体作为主子团体，将主子团体以外的所有子团体作为辅子团体；\n[0020] 输出主子团体、辅子团体。\n[0021] （5）掉队游客判断模块：将每个辅子团体与掉队子团体判断条件作比较，得到掉队辅子团体，将该掉队辅子团体中的游客判断为掉队游客并输出结果；\n[0022] 掉队子团体判断条件有三个：\n[0023] 条件一：团体游客人数须大于等于3个；\n[0024] 条件二：主子团体与辅子团体间的最短距离大于等于相对连续距离；\n[0025] 条件三：辅子团体游客人数至少为1，且小于等于主子团体游客人数的1/x，1/x为子团体间游客人数的比值，可根据实际情况设置。\n[0026] 联动救援模块包括以下四个部分：\n[0027] （1）存储模块：用于存储用户及工作人员的注册信息，建立可用工作人员集合与救援请求队列；\n[0028] （2）接收救援请求模块：接收来自移动终端的救援请求，并通过以下几种方式触发对救援请求的处理：\n[0029] 当没有新救援请求发出时，服务器每隔一段特定时间检查一次，若可用工作人员集合与救援请求队列均不为空，则取出队列顶部的请求进行处理；\n[0030] 当有新工作人员上线后，服务器得到工作人员上线通知后检查救援请求队列，若不为空，则取出队列顶部的请求进行处理；\n[0031] 当工作人员完成某项任务后，服务器得到任务完成通知后检查救援请求队列，若不为空，则取出队列顶部的请求进行处理；\n[0032] 服务器接收到新救援请求后，先检查请求的有效性：首先，检查救援请求队列中是否已存在一个救援请求，其求助用户与提出该新请求的用户相同；若相同，再检查两请求的类型是否相同；若两请求的类型也相同，则判断已存在救援请求的求救时间是否小于设定的时间，求救时间等于当前时间减去已存在救援请求的发出救援的时间；若小于设定的时间，则该新救援请求为无效重复请求，否则为有效请求，生成新的救援任务；检查可用工作人员集合是否为空，若为空则根据救援请求事件类型对应的优先级，将其插入救援请求队列中等待调度；若不为空，则再检查救援请求队列是否为空，若救援请求队列为空，则立即对该救援请求进行处理，否则将其插入救援请求队列中，并从队列中取出顶部任务进行处理；\n[0033] （3）救援请求处理模块：根据救援请求的事件类型，检查可用工作人员集合中是否存在符合该救援请求事件类型的工作人员，若存在，建立符合条件的工作人员集合；若不存在，则将该救援请求重新放回救援请求队列；计算符合条件的工作人员集合中每个工作人员的当前位置与该求助用户的实时位置的距离，将结果按升序排列并取出前p个，p为用户预设数值，将其对应的p个工作人员的信息按顺序生成候选工作人员集合；向第一个候选工作人员发送救援任务，若该任务被工作人员拒绝或等待超过设定的时间以后仍无响应，则向下一位候选工作人员发送任务；当候选工作人员均拒绝该救援任务或者等待均超过设定的时间后，将该任务重新放回救援请求队列中；\n[0034] （4）安全救援链模块：工作人员接受救援任务后通知服务器，服务器将该工作人员从可用工作人员集合中移出，并建立起求助用户与该工作人员的一对一双向安全救援链，由服务器每隔特定时间向求助用户发送施救工作人员动态，向施救工作人员发送求助用户动态。\n[0035] 本发明系统主要设计了一个旅游团队突发情况管理模块，又包括自动判断掉队游客模块与联动救援模块；自动判断掉队游客模块采用空间连续距离划分子团体，从而能够及时、准确、自动的判断出掉队游客，确保每位游客在跟团观赏过程中的人身安全，为游客提供高质量的服务；联动救援模块依据救援请求的优先级建立救援请求队列，使求助请求按优先级自动排队等待调度，并将接受任务的工作人员与该求助用户绑定，由服务器向双方传送对方的位置，使双方可以及时了解对方的位置变化等动态信息，能大大节约人力成本，并高效处理救援请求，实现救援系统的智能自动调度。\n附图说明\n[0036] 图1是本发明系统的组成及服务流程。\n[0037] 图2是自动判断掉队游客模块的工作流程图。\n[0038] 图3是自动判断掉队游客模块实施例数据分布图。\n[0039] 图4是自动判断掉队游客模块中，团体所有游客的空间分布距离量值集合在二维笛卡尔坐标系中的表示图，其中，坐标轴X表示游客，坐标轴Y表示每个游客与其他n-1个游客的距离和。\n[0040] 图5是自动判断掉队游客模块实施例数据分析结果图。\n[0041] 图6是联动救援模块中，接收救援请求模块接收新救援请求后的处理流程图。\n[0042] 图7是联动救援模块中，救援请求处理模块任务调度流程图。\n[0043] 图8是联动救援模块中，安全救援链模块工作流程图。\n[0044] 图9是联动救援模块的实施例景区用户分布图。\n具体实施方式\n[0045] 下面结合附图和实施例对本发明作进一步详细说明。\n[0046] 自动判断掉队游客模块的组成部分及工作流程（如图2所示）：\n[0047] 本模块的基本构思是：获取团队中每个游客地理坐标Pi（Xi,Yi），计算每个游客与其他n-1个游客的欧式距离dij（欧式距离也称欧几里得度量，是在m维空间中两个点之间的真实距离，本模块采用二维空间欧式距离计算方法）、距离和Di；分析统计Di大小分布，筛选出m个特殊点SPm，求剩下n-m个游客距离和Di的平均值K；计算团队中两游客间的相对连续距离Dia，Dia在一定程度上是整个团队当前状态下离散程度的反应；以相对连续距离Dia的一半为半径R，对每个游客做圆形缓冲区，生成每个游客的相对连续区RCSi；\n对所有RCSi求交、合并计算，得到子团体集合PG，找到主子团体MPG和辅子团体APG；判断特殊点集合SP与所属子团体的包含关系，比对掉队游客判断条件，最终判断输出当前掉队游客LDT及当前团队的空间离散程度Dia。本模块中计算特殊游客的部分需要用到公开方法：“用Origin剔除线性拟合中实验数据的异常值”（王鑫与吴先球等(2003).山西师范大学学报(自然科学版)(1):45-49）。其他要用到的名词概念有：\n[0048] （1）相对连续距离：在当前团队成员分布状态下，相对整个团队而言，设置一定的距离值Dia。若两游客间距离Dia，表示两人保持连续状态。\n[0049] （2）相对连续区：以相对连续距离的一半为半径，为每个游客生成的圆形缓冲区成为该游客的相对连续区。\n[0050] （3）主子团体：团队子团体中，包含人数最多的子团体。\n[0051] （4）辅子团体：子团体中除主子团体以外的子团体。\n[0052] 掉队游客判断条件：整个团体游客集合G，分散成N个子团体PGi,（i=1…N），游客人数最大的子团体为主子团体MPG，其他N-1个为辅子团体APG，判断游客掉队需满足条件\n1-3：\n[0053] 条件1：CountG≥3（CountG为团队游客人数，条件表示团队游客人数大于等于3个；）\n[0054] 条件2：(MinDis(APG，MPG))≥Dia（MinDis表示最短距离。条件表示主子团体与辅子团体间的最短距离大于等于相对连续距离）\n[0055] 条件3：1≤CountAPG≤1/XCountMPG，（1/X为子团体间游客人数的比值，可根据实际情况设置。CountAPG表示辅子团体游客人数，CountMPG表示主子团体游客人数，条件表示辅子团体人数至少为1，且小于等于主子团体游客人数的1/X）\n[0056] （1）距离和生成模块：\n[0057] 获取到团队游客集合G的游客地理坐标数据集合G：\n[0058] G＝{Pi＝(Xi，Yi)|i＝1……n，n为团队游客数}\n[0059] 计算游客Pi到其他n-1个游客的n-1个距离值集合：\n[0060] \n[0061] 对dij求和得到游客Pi与所有其他n-1个游客的距离和D i：\n[0062] \n[0063] （2）特殊游客生成模块：\n[0064] 将所得每个Pi与对应Di值组合，生成该团队在该时刻每个游客与团体同伴间的空间分布距离量值集合D：\n[0065] D＝{PD(Pi,Di)|i＝1……n，n为团队游客数}\n[0066] 在二维笛卡尔坐标系表示团队每个游客的PD(Pi，Di),坐标轴X表示游客Pi，坐标轴Y表示游客Pi的距离和Di（如图4所示）；找到m个特殊游客SPi，添加到特殊游客集合SP:\n[0067] SP＝{SPi＝(Xi，Yi)|i＝1……m，\n[0068] m≤n，下标i与集合G中保持一致}\n[0069] （3）相对连续区生成模块：\n[0070] 对剩下n-m个游客Pi的Di求平均：\n[0071] \n[0072] 根据K，计算相对连续距离：\n[0073] \n[0074] 得到团队游客当前相对连续区计算阈值R：\n[0075] \n[0076] 对每个游客Pi以R为半径，做缓冲区，生成每个游客的相对连续区RCSi，空间连续区集合：\n[0077] RCS＝{RCSi|i＝1……n，n为团队游客数}\n[0078] （4）主、辅子团体生成模块：\n[0079] 依次取RCSi，与已有子团体求交、合并，生成主子团体MPG、辅子团体APG，具体方法流程：\n[0080] （a）初始化：P1点对应的RCS1为子团体PG1；\n[0081] （b）遍历集合RCS，依次i+1，若i+1≤n为假，跳至（3）；若i+1≤n为真，取i+1点Pi+1，计算RCSi+1与已有子团体PGi交集，若有交集，RCSi与RCSi+1求并(融合构成集合PGi)；无交集，则Pi+1对应的RCSi+1生成新的子团体PGi+1；\n[0082] （c）计算所有子团体中人数最多的团体MaxCountPG，得到MPG，其余剩下均为APG；\n[0083] （d）输出主子团体MPG、辅子团体APG；\n[0084] （5）掉队游客判断模块：\n[0085] 判读特殊点集合SP每个游客SPm与所属MPG、APG包含关系，比对掉队游客判读条件，得出结果；输出掉队游客结果，团队当前离散程度；\n[0086] 自动判断游客掉队模块实施例：\n[0087] 图3为实施例中的团队游客分布图，在实施例中，团队由10个游客组成，图中点为游客地理坐标分布位置，注记为游客点标号。坐标数据为WGS84球形坐标。游客地理坐标数据集合：\n[0088] G={P1(120.681120,31.640250),P2(120.678854,31.641379),P3(120.678941,31.641103),P4(120.679415,31.641050),P5(120.679346,31.641268),P6(120.679396,31.\n641499),P7(120.679651,31.641422),P8(120.679994,31.641250),P9(120.679217,31.64\n1541),P10(120.681476,31.640055)}。\n[0089] 根据本发明方法工作流程步骤,得到MAG、APG，\n[0090] MAG={P2，P3，P4,P5，P6，P7，P8，P9}；\n[0091] APG={P1，P10}；\n[0092] 输出结果（如图5所示）：\n[0093] 团队离散程度值为44米；\n[0094] 主子团体MPG={P2,P3,P4,P5,P6,P7,P8,P9}；\n[0095] 辅子团体APG={P1,P10}；\n[0096] 掉队游客为LDT={P1、P10}，P1∈APG1，P10∈APG1；\n[0097] 联动救援模块组成部分及工作流程为：\n[0098] 本模块利用GIS将经度和纬度转化为特定地图投影中的坐标，记录为（X,Y），其中X为经度在特定地图投影中的坐标，Y为纬度在特定地图投影中的坐标（下文中的X均为经度在特定地图投影中的坐标，Y均为纬度在特定地图投影中的坐标）。采用的现有方法有：\n公开方法一：二叉堆优先级队列算法（殷人昆等，数据结构（用面向对象方法与C++描述），清华大学出版社）；公开方法二：快速排序法（殷人昆等，数据结构（用面向对象方法与C++描述），清华大学出版社）。\n[0099] 存储模块：利用GIS模块的地图投影与坐标变换功能将用户实时坐标点的经纬坐标转化为特定地图投影中的坐标；利用服务器存储求助用户、工作人员的基本资料与动态信息；基本资料通过账号注册等方式人工预先录入数据库中，而动态信息则在使用移动终端过程中实时获取并存储在数据库中。设定普通用户集合T={ti=(Id，Username，Pwd,Name，Gender,Age，Contact,Status，X,Y,Speed)|i=1……n，n为普通用户数量}，其中，Id为用户唯一标示符，Username为用户登录账户名，Pwd为用户登录密码，Name为姓名，Gender为性别，Age为年龄，Contact为联系电话，Status为用户当前状态Speed为用户当前运动速度；工作人员集合S={si={WorkId，Name，Pwd,Gender，Duty,Contact,Status，X,Y,Speed|i=1……n，n为工作人员数量}，其中，WorkId为工作人员工号，Name为姓名，Pwd为登录密码，Gender为性别，Duty为工作人员的救援职责，Status为工作人员当前状态，Speed为工作人员当前运动速度。用户通过普通用户移动终端使用已注册的账号与密码登陆系统，按自定义通信协议1（同步头%%功能码%%登录账户名%%密码）向服务器发送上线信息，工作人员通过工作人员移动终端使用工号与密码登陆系统，按自定义通信协议2（同步头%%功能码%%工号%%密码）向服务器发送上线信息；由服务器匹配数据库中相关字段进行身份验证，验证通过后将该普通用户标记为在线状态，将工作人员标记为在线状态并加入救援可用工作人员列表中。服务器根据上线工作人员的基本资料与动态信息，建立可用工作人员集合；服务器根据救援请求中的救援请求事件类型，建立救援请求的优先级队列，保证队列顶端为优先级最高的救援请求；\n[0100] 接收救援请求模块：接收来自移动终端的救援请求，服务器通过以下几种方式触发对救援请求的处理：\n[0101] （1）当没有新救援请求发出时，服务器每隔90秒检查一次，若可用工作人员集合ASL与救援请求队列RQ均不为空，则取出队列顶部的请求r进行处理；\n[0102] （2）当有新工作人员上线后，服务器得到工作人员上线通知后检查救援请求队列RQ，若RQ不为空，则取出队列顶部的请求r进行处理；\n[0103] （3）当工作人员完成某项任务后，服务器得到任务完成通知后检查救援请求队列RQ，若RQ不为空，则取出队列顶部的请求r进行处理；\n[0104] （4）有新救援请求时的处理（如图6所示）：服务器中保存救援可用工作人员列表，设定可用工作人员列表集合为ASL={si|i＝1……n}，ASL为所有工作人员集合S的一个子集，其中n表示可用工作人员人数；救援请求队列RQ={ri=(Id，Xi,Yi,Leveli,Catalogi,Timei)|i＝1……m}，其中m为救援请求数量,Id为用户唯一标示符，Level为请求优先级，Catalog为请求类型，Time为求救时间，RQ为优先级队列，保证队列顶端为优先级最高的任务。当服务器接收到请求后，首先检查请求有效性，有效性验证流程为：\n[0105] （a）对请求R1，检查救援队列RQ中是否存在用户请求R2,使得R1.Id=R2.Id；\n[0106] （b）若存在满足（a）条件请求R2，检查两者请求类型是否相同，即R1.Catalog=R2.Catalog是否满足；\n[0107] （c）若存在满足（b）条件请求R2，则检查当前时间减去R2.Time<10分钟是否满足，若满足则该请求为无效重复请求；不满足（a）（b）（c）的请求均为有效请求，生成新救援任务；\n[0108] 检查可用工作人员集合ASL是否为空，若ASL为空则根据救援请求的事件类型对应的优先级，按照公开方法一“二叉堆优先级队列算法”将其插入救援请求队列RQ中等待调度；若ASL非空，则再检查RQ是否为空，若RQ为空则立即处理该请求，否则按照公开方法一将其插入救援请求队列RQ中，并从RQ中取出顶部任务进行处理；\n[0109] 救援请求处理模块（如图7所示）：（1）根据救援请求r的事件类型，检查可用工作人员集合ASL中是否存在符合该救援请求事件类型的工作人员，若存在，建立符合条件的工作人员集合SA；若不存在，则将该救援请求重新放回救援请求队列；\n[0110] （2）对Si∈SA，计算其当前位置（Xi,Yi）与救援请求的发送位置(X,Y)的距离 并将所有的dis添加到集合DA中，添加完成后对\nDA中的元素按照dis升序排列；从DA中取出距离最短的5个，生成候选工作人员表CList={si|i=1,p,p<=5}；\n[0111] （3）按照自定义通信协议6(同步头%%功能码%%任务号%%求救用户唯一标示符%%求救用户经度%%求救用户纬度%%求救时间%%请求类型码)，首先向第一位候选工作人员（距离最近）发送救援任务，工作人员接收到该任务消息后，由求救用户的唯一标示符查询数据库得到用户的姓名、性别、年龄等基本资料。\n[0112] 若该任务被工作人员拒绝或等待超过1分钟以后仍无响应，则向下一位候选工作人员发送任务；当候选工作人员均拒绝该救援任务或者等待均超过设定的时间后，将该任务重新放回救援请求队列RQ中，检查救援请求队列是否存在下一请求，若存在则循环步骤五；\n[0113] 安全救援链模块（如图8所示）：当工作人员接受服务器调度前往救援时，即按照自定义通信协议7（同步头%%功能码%%任务号%%工作人员工号）发送消息通知服务器，服务器接到消息后将其从ASL集合中移出，并建立起求助用户与该工作人员的一对一双向安全救援链；每隔30秒钟按照自定义通信协议8（同步头%%功能码%%工作人员姓名%%工作人员当前经度%%工作人员当前纬度%%工作人员当前速度）向求救用户终端发送工作人员动态，按照自定义通信协议9（同步头%%功能码%%求助用户姓名%%求助用户当前经度%%求助用户当前纬度%%求助用户当前速度）向工作人员发送求助用户的动态；\n[0114] 联动救援模块实施例：\n[0115] 本例以旅游景区紧急安全救援调度进行详细描述，在本例中求救终端即为游客移动终端，救援终端为景区工作人员移动终端。游客首先在服务台提供姓名、年龄、性别等信息办理导游终端设备租赁，从而使服务器可以获取游客基本资料；工作人员基本资料由人工预先录入数据库中。\n[0116] GIS模块基于ESRI公司的ArcGIS Mobile软件进行二次开发完成，GPS获取模块的GPS设备为智能手机中自带的设备，使用ESRI公司的ArcGIS Mobile软件中的GPS接口驱动此设备，从而获取用户经纬坐标和用户运动速度等信息。\n[0117] 图9是 实施 例 景 区用 户 分布 图，游客 由 符 号 表 示,游 客 集 合T={ti=(Id,Username,Pwd,Name，Gender,Age，Contact,Status，X,Y,Speed)\ni=1,4}={T1,T2,T3,T4}\n[0118] T1={“t00001”,“t1120001”,“123456”，“张三”,“男”，35，“1351234567”,1,1\n18.90487,32.10195,0}，\n[0119] T2={“t00002”,“t1120002”,“123456”，“李四”,“男”，28，“1361234567”,1,1\n18.90489,32.10603,2.24}，\n[0120] T3={“t00003”,“t1120003”,“123456”，“王五”,“女”，30，“1371234567”1,11\n8.90583,32.10389，0}，\n[0121] T4={“t00004”,“t1120004”,“123456”，“赵六”,“女”，22，“1381234567”1,11\n8.91010,32.10372,0}；\n[0122] 工作人员由符号 表示，工作人员集合S={si={WorkId，Name，Pwd,Gender，Duty，Contact,Status，X,Y,Speed|i=1,5}={S1,S2,S3,S4,S5}\n[0123] S1={“210001”，“小 吴”，“123456”，“1301111111”，“保 安 员”，1，\n118.90787,32.10113,10.2}，\n[0124] S2={“210002”，“小 孙”，“123456”，“1302222222”，“保 安 员”，0，\n118.90329,32.10059,2.2}，\n[0125] S3={“210003”，“小 于”，“123456”，“1303333333”，“保 安 员”，2，\n118.90215,32.10256,10.8}，\n[0126] S4={“220001”，“小 蒋”，“123456”，“1304444444”，“医 疗 员”，0，\n118.90775,32.10113，2.6}，\n[0127] S5={“220002”，“小 刘”，“123456”，“1305555555”，“医 疗 员”，1，\n118.90792,32.10817,5.5}。\n[0128] 本联动救援系统的工作流程为：\n[0129] （1）S1、S2、S5此时为在线状态，在线可用工作人员列表ASL={S1,S2,S5}，S4为离线状态，S3为忙碌状态。\n[0130] （2）游客T3在当前位置请求帮助，并在求救终端屏幕上选择求救原因“游客物品被盗”，将按照自定义通讯协议5将其用户标示符，以及所在位置（118.90583,32.10389），求助原因发送至服务器。\n[0131] （3）服务器接收救援请求，首先检查请求有效性，防止重复请求。遍历队列RQ检查是否存在相同用户的任务请求，设定此时救援队列RQ为空，因此没有相同用户任务请求，该请求有效，生成新的任务R1；若救援队列RQ此时为空，则立即处理R1；否则，根据R1的求助原因对应的优先级以及求助时间，按照公开方法一将该任务插入救援队列RQ中等待处理。\n[0132] （4）因为RQ为空，立即处理任务R1。R1的请求类型为“游客物品被盗”，对应职责为“保安员”的工作人员。从可用工作人员列表ASL中查找Duty为“保安员”，S1,S2符合，根据R1的位置（118.90583,32.10389）计算其与S1（118.90787,32.10113）和S2（118.90329,32.10059）的距离关系，得到DA={410,392},根据公开方法二对DA排序，得到候选工作人员列表CList={S2,S1}。\n[0133] 根据CList顺序，首先向S2发送救援任务R1，S2所携带的工作人员救援终端发出声音报警，并且工作人员终端屏幕上出现文字提示“王五，女，30岁，物品被盗请求帮助”并在屏幕的地图界面标示出求助位置。收到任务请求后1分钟内未接受该任务，服务器继续向CList中下一名候选工作人员S1发送R1。S1,S2均未接受该任务，则该任务被放回队列RQ中。\n[0134] （5）此时，T1也发起了救援请求,求救原因为“游客受伤”，因为事件紧急该用户重复多次点击了救助按钮并向服务器发送了救援请求。\n[0135] （6）服务器接收到T1的多次救援请求，当第一次接收到T1请求时，遍历队列RQ无该T1的其他请求任务，因此生成新的任务R2。在此时RQ中已有任务R1，但R2任务的求助原因“游客受伤”级别高于“游客物品被盗”，因此根据公开方法一将该任务提前至R1之前，并取出R2执行调度。而再次接受到T1的救援请求时，由于RQ中已存在任务R2，R2与新的救援请求：（1）用户ID相同（2）请求类型相同（3）R2请求时间未超过10分钟，因此这几次请求将被自动判定为重复请求。\n[0136] （7）R2任务类型对应职责为“医疗员”的工作人员，从ASL中查找，S5唯一符合，因此向其派送任务R2。\n[0137] （8）工作人员S5接收该任务，将其从ASL集合中移出，并建立起T1——S5的双向安全救援链，此时每隔30秒T1端将收到1次由自定义通信协议8发送的S5位置信息，S5端也将收到由自定义通信协议9发送的T1位置信息。\n[0138] （9）服务器每隔90秒检查一次救援请求队列RQ，若ASL非空且RQ非空则取出队列顶部的救援请求r进行调度；因此90秒后将R1取出再次进行调度，过程与步骤4类似，将按照此时S1、S2的当前位置，按距离远近依次向其派送任务。\n[0139] （10）R2任务完成后S5通知服务器任务完成，将S5其重新放入ASL列表中。该任务调度结束。
快申报：023-88392959
工作日：9:00-12:00/13:30-18:00
