CN102395108B

CN102395108B - 基于移动定位的联动救援方法

Info

Publication number: CN102395108B
Application number: CN 201110382769
Authority: CN
Inventors: 龙毅; 严瑞; 李德鹏; 余明朗
Original assignee: SUZHOU MAIPU INFORMATION TECHNOLOGY Co Ltd
Current assignee: SUZHOU MAIPU INFORMATION TECHNOLOGY Co Ltd
Priority date: 2011-11-28
Filing date: 2011-11-28
Publication date: 2013-01-23
Anticipated expiration: 2031-11-28
Also published as: CN102395108A

Abstract

本发明公开了一种基于移动定位的联动救援方法，以实现对救援请求按优先级顺序自动调度以及对施救、求救人员的实时定位追踪。采用的技术方案主要包括以下步骤：利用服务器存储用户、工作人员的基本资料与动态信息，服务器建立可用工作人员集合、救援请求优先级队列；求助人员点击移动终端的求救按钮发送请求，服务器通过自检、工作人员上线通知与完成任务通知、接收新请求四种方式触发对救援请求的处理；对请求依据优先级排序，按顺序依次处理；将接受任务的工作人员与求助用户绑定，建立一对一救援链。本发明实现了任务调度的自动化，能够高度节约人力成本，高效处理救援请求，实现救援系统的智能自动调度。

Description

基于移动定位的联动救援方法

技术领域

本发明涉及一种联动救援方法，尤其是一种基于移动定位的救援方法。

背景技术

随着卫星定位技术的发展与普及，基于物联网技术进行智能化综合管理成为可能，但目前无论是旅游景区遇到游客求助，或是医院收到紧急医疗救助请求等突发事件救援请求时，都主要依靠人工进行管理、调度，浪费大量的人力、物力。虽然目前出现了基于GPS和移动通信模块的救援报警系统，但仍无法达到智能自动调度和联动救援的要求。

现有的移动定位救援系统在处理救援信息时仍大量依靠人工，属于半人工半自动救援。如公开号为CN101448206A的发明专利公开了一种基于GPS的一键求救系统，当用户求救时利用无线网络自动向控制台发送求救者位置；授权号为CN201315615Y的实用新型专利公开了一种基于语音通讯的一键紧急求救系统，当用户连续按动两次求助键后向服务系统发送救援请求，并启动语音服务以便确定用户的基本情况和求助类型。以上专利均未考虑如何根据求助者的位置和求救内容确定救援任务的接收者以及救援的优先级，而是直接将求助信息转发至控制台由人工调度，采用这种方法存在以下缺点：（1）对并发救援请求的处理效率低，无法同时对多个救援任务进行调度；（2）在救援过程中，求助者无法实时了解救援动态，而救助者在前往救援途中也无法知晓求助者的位置移动等信息并作出及时反应和调整。

发明内容

本发明针对上述现有救援方法的不足，本发明提供一种基于移动定位的联动救援系统实现方法，包括以下步骤：

步骤一：利用GIS模块的地图投影与坐标变换功能将用户实时坐标点的经纬坐标转化为特定地图投影中的坐标；利用服务器存储求助用户、工作人员的基本资料与动态信息；

步骤二：用户通过普通用户移动终端使用已注册的账号与密码登陆系统，工作人员通过工作人员移动终端使用工号与密码登陆系统，并同时向服务器发送上线信息；服务器根据上线工作人员的基本资料与动态信息，建立可用工作人员集合；服务器根据救援请求中的救援请求事件类型，建立救援请求的优先级队列，保证队列顶端为优先级最高的救援请求；

步骤三：求助用户点击移动终端的求救按钮，选择救援事件原因，将该救援事件原因与系统自动获取的用户唯一标示符、用户求救位置经纬度信息一并生成救援请求，通过移动终端的通信模块发送至服务器；

步骤四：服务器通过以下几种方式触发对救援请求的处理：

（1）当没有新救援请求发出时，服务器每隔一段特定时间检查一次，若可用工作人员集合与救援请求队列均不为空，则取出队列顶部的请求执行步骤五；

（2）当有新工作人员上线后，服务器得到工作人员上线通知后检查救援请求队列，若不为空，则取出队列顶部的请求执行步骤五；

（3）当工作人员完成某项任务后，服务器得到任务完成通知后检查救援请求队列，若不为空，则取出队列顶部的请求执行步骤五；

（4）服务器接收到新救援请求后，先检查请求的有效性：首先，检查救援请求队列中是否已存在一个救援请求，其求助用户与提出该新请求的用户相同；若提出该新请求的用户与上述救援请求队列中的某个救援请求的求助用户相同，再检查两请求的类型是否相同；若两请求的类型也相同，则判断已存在救援请求的求救时间是否小于设定的时间，求救时间等于当前时间减去已存在救援请求的发出救援的时间；若小于设定的时间，则该新救援请求为无效重复请求，否则为有效请求，生成新的救援任务；

检查可用工作人员集合是否为空，若为空则根据救援请求事件类型对应的优先级，将其插入救援请求队列中等待调度；若不为空，则再检查救援请求队列是否为空，若救援请求队列为空，则执行步骤五，否则将其插入救援请求队列中，并从队列中取出顶部任务执行步骤五；

步骤五：（1）根据救援请求的事件类型，检查可用工作人员集合中是否存在符合该救援请求事件类型的工作人员，若存在，建立符合条件的工作人员集合；若不存在，则将该救援请求重新放回救援请求队列，检查救援请求队列是否存在下一请求，若存在则循环步骤五；

（2）计算符合条件的工作人员集合中每个工作人员的当前位置与该求助用户的实时位置的距离，将计算结果按升序排列并取出前n个，将其对应的n个工作人员的信息按顺序生成候选工作人员集合；

（3）向第一个候选工作人员发送救援任务，若该任务被工作人员拒绝或等待超过设定的时间以后仍无响应，则向下一位候选工作人员发送任务；当候选工作人员均拒绝该救援任务或者等待均超过设定的时间后，将该任务重新放回救援请求队列中，检查救援请求队列是否存在下一请求，若存在则循环步骤五；

步骤六：工作人员接受救援任务后通知服务器，服务器将该工作人员从可用工作人员集合中移出，并建立起求助用户与该工作人员的一对一双向安全救援链；

步骤七：工作人员完成救援任务，向服务器发送信息。

在本发明方法中，求助用户、工作人员的基本资料可以是人工预先录入数据库中，而动态信息则是通过GPS模块实时获取的；救援请求优先级队列中的每个救援请求可以是一个包括如下元素的集合：用户唯一标示符、请求优先级、请求类型、求救时间；求助用户与工作人员的双向安全救援链，是通过服务器每隔特定时间向求助用户与施救人员发送双方的动态信息实现的。

本发明提出了一种根据救援请求的优先级建立救援请求队列的方法，使求助请求按优先级自动排队等待调度，从而实现任务调度的自动化；本发明也提出了一种基于救援双方的链式救援模式，将接受任务的工作人员与该求助用户绑定，由服务器向双方传送对方的位置，使双方可以及时了解对方的位置变化等动态信息，能大大节约人力成本，并高效处理救援请求，实现救援系统的智能自动调度。

附图说明

图1是本发明的系统结构示意图。

图2是本发明的用户求救流程图。

图3是本发明的服务器接收救援请求后的处理流程图。

图4是本发明的任务自动调度流程图。

图5是本发明的安全救援链建立流程示意图。

图6是实施例景区用户分布图。

具体实施方式

下面结合附图和实施例对本发明作进一步详细说明。

本发明利用已有的GIS模块将经度和纬度转化为特定地图投影中的坐标，记录为（X,Y），其中X为经度在特定地图投影中的坐标，Y为纬度在特定地图投影中的坐标（下文中的X均为经度在特定地图投影中的坐标，Y均为纬度在特定地图投影中的坐标）。

本发明采用的现有方法有：公开方法一：二叉堆优先级队列算法（殷人昆等，数据结构（用面向对象方法与C++描述），清华大学出版社）；公开方法二：快速排序法（殷人昆等，数据结构（用面向对象方法与C++描述），清华大学出版社）。

本发明由以下步骤组成：

步骤一：利用GIS模块的地图投影与坐标变换功能将用户实时坐标点的经纬坐标转化为特定地图投影中的坐标；利用服务器存储求助用户、工作人员的基本资料与动态信息；基本资料通过账号注册等方式人工预先录入数据库中，而动态信息则在使用移动终端过程中实时获取并存储在数据库中。设定普通用户集合T={ t_i=( 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={s_i={WorkId, Name, Pwd, Gender, Duty, Contact, Status, X, Y, Speed|i=1……n， n为工作人员数量}，其中，WorkId为工作人员工号，Name为姓名，Pwd为登录密码，Gender为性别，Duty为工作人员的救援职责，Status为工作人员当前状态，Speed为工作人员当前运动速度。

步骤二：用户通过普通用户移动终端使用已注册的账号与密码登陆系统，按自定义通信协议1（同步头%%功能码%%登录账户名%%密码）向服务器发送上线信息，工作人员通过工作人员移动终端使用工号与密码登陆系统，按自定义通信协议2（同步头%%功能码%%工号%%密码）向服务器发送上线信息；由服务器匹配数据库中相关字段进行身份验证，验证通过后将该普通用户标记为在线状态，将工作人员标记为在线状态并加入救援可用工作人员列表中。服务器根据上线工作人员的基本资料与动态信息，建立可用工作人员集合；服务器根据救援请求中的救援请求事件类型，建立救援请求的优先级队列，保证队列顶端为优先级最高的救援请求；

步骤三：求助用户点击移动终端的求救按钮，救援系统将列出常见的救援事件原因选项，用户选择最符合的选项，生成救援请求，按自定义通信协议5（同步头%%功能码%%请求类型码%%用户唯一标示符%%用户求救位置经度%%用户求救位置纬度）由移动终端的通信模块发送至服务器；

步骤四：服务器通过以下几种方式触发对救援请求的处理：

（1）当没有新救援请求发出时，服务器每隔90秒检查一次，若可用工作人员集合ASL与救援请求队列RQ均不为空，则取出队列顶部的请求r执行步骤五；

（2）当有新工作人员上线后，服务器得到工作人员上线通知后检查救援请求队列RQ，若RQ不为空，则取出队列顶部的请求r执行步骤五；

（3）当工作人员完成某项任务后，服务器得到任务完成通知后检查救援请求队列RQ，若RQ不为空，则取出队列顶部的请求r执行步骤五；

（4）有新救援请求时的处理：服务器中保存救援可用工作人员列表，设定可用工作人员列表集合为ASL ={s_i|i=1…… n }，ASL为所有工作人员集合S的一个子集，其中n表示可用工作人员人数；救援请求队列RQ={r_i=( Id, X_i , Y_i , Level_i , Catalog_i, Time_i) |i=1……m }，其中m为救援请求数量, Id为用户唯一标示符，Level为请求优先级，Catalog为请求类型，Time为求救时间，RQ为优先级队列，保证队列顶端为优先级最高的任务。当服务器接收到请求后，首先检查请求有效性，有效性验证流程为（见图3）：（a）对请求R1，检查救援队列RQ中是否存在用户请求R2,使得R1.Id =R2.Id；（b）若存在满足（a）条件请求R2，检查两者请求类型是否相同，即R1.Catalog = R2.Catalog是否满足；（c）若存在满足（b）条件请求R2，则检查当前时间减去R2.Time < 10分钟是否满足，若满足则该请求为无效重复请求；不满足（a）（b）（c）的请求均为有效请求，生成新救援任务；

检查可用工作人员集合ASL是否为空，若ASL为空则根据救援请求的事件类型对应的优先级，按照公开方法一“二叉堆优先级队列算法”将其插入救援请求队列RQ中等待调度；若ASL非空，则再检查RQ是否为空，若RQ为空则执行步骤五，否则按照公开方法一将其插入救援请求队列RQ中，并从RQ中取出顶部任务执行步骤五；

步骤五（见图4）：（1）根据救援请求r的事件类型，检查可用工作人员集合ASL中是否存在符合该救援请求事件类型的工作人员，若存在，建立符合条件的工作人员集合SA；若不存在，则将该救援请求重新放回救援请求队列，检查救援请求队列是否存在下一请求，若存在则循环步骤五；

（2）对S_i∈SA，计算其当前位置（X_i,Y_i）与救援请求的发送位置(X,Y)的距离

，并将所有的dis添加到集合DA中，添加完成后对DA中的元素按照dis升序排列；从DA中取出距离最短的5个，生成候选工作人员表CList={ s_i| i=1, n,n<=5 }；

（3）按照自定义通信协议6(同步头%%功能码%%任务号%%求救用户唯一标示符%%求救用户经度%%求救用户纬度%%求救时间%%请求类型码)，首先向第一位候选工作人员（距离最近）发送救援任务，工作人员接收到该任务消息后，由求救用户的唯一标示符查询数据库得到用户的姓名、性别、年龄等基本资料。

若该任务被工作人员拒绝或等待超过1分钟以后仍无响应，则向下一位候选工作人员发送任务；当候选工作人员均拒绝该救援任务或者等待均超过设定的时间后，将该任务重新放回救援请求队列RQ中，检查救援请求队列是否存在下一请求，若存在则循环步骤五；

步骤六：当工作人员接受服务器调度前往救援时，即按照自定义通信协议7（同步头%%功能码%%任务号%%工作人员工号）发送消息通知服务器，服务器接到消息后将其从ASL集合中移出，并建立起求助用户与该工作人员的一对一双向安全救援链（如图5所示）；每隔30秒钟按照自定义通信协议8（同步头%%功能码%%工作人员姓名%%工作人员当前经度%%工作人员当前纬度%%工作人员当前速度）向求救用户终端发送工作人员动态，按照自定义通信协议9（同步头%%功能码%%求助用户姓名%%求助用户当前经度%%求助用户当前纬度%%求助用户当前速度）向工作人员发送求助用户的动态；

步骤七：工作人员完成救援任务，向服务器发送信息。

实施例：

本例以旅游景区紧急安全救援调度进行详细描述，在本例中求救终端即为游客导游终端，救援终端为景区工作人员智能手机，服务器架设在景区机房。游客首先在服务台提供姓名、年龄、性别等信息办理导游终端设备租赁，从而使服务器可以获取游客基本资料；工作人员基本资料由人工预先录入数据库中。

GIS模块基于ESRI公司的ArcGIS Mobile软件进行二次开发完成，GPS获取模块的GPS设备为智能手机中自带的设备，使用ESRI公司的ArcGIS Mobile软件中的GPS接口驱动此设备，从而获取用户经纬坐标和用户运动速度等信息。

图6是实施例景区用户分布图，游客由符号

表示, 游客集合T={ t_i=( Id, Username, Pwd, Name, Gender, Age, Contact, Status, X, Y, Speed) |i=1,4 }={T1,T2,T3,T4 }

T1={“t00001”,“t1120001”,“123456”，“张三”,“男”，35，“1351234567”,1,118.90487,32.10195,0}，

T2={“t00002”, “t1120002”,“123456”，“李四”,“男”，28，“1361234567”,1,118.90489,32.10603,2.24}，

T3={“t00003”, “t1120003”,“123456”，“王五”,“女”，30，“1371234567”1,118.90583,32.10389，0}，

T4={“t00004”, “t1120004”,“123456”，“赵六”,“女”，22，“1381234567”1,118.91010,32.10372,0}；

工作人员由符号

表示，工作人员集合S={s_i={WorkId, Name, Pwd,Gender, Duty, Contact, Status, X, Y, Speed | i=1,5}={ S1, S2, S3, S4, S5 }

S1={“210001”，“小吴”，“123456”，“1301111111”，“保安员”，1，118.90787,32.10113,10.2}，

S2={“210002”，“小孙”，“123456”，“1302222222”，“保安员”，0，118.90329,32.10059,2.2}，

S3={“210003”，“小于”，“123456”，“1303333333”，“保安员”，2，118.90215,32.10256,10.8}，

S4={“220001”，“小蒋”，“123456”，“1304444444”，“医疗员”，0，118.90775,32.10113，2.6}，

S5={“220002”，“小刘”，“123456”，“1305555555”，“医疗员”，1，118.90792,32.10817,5.5}。

本联动救援系统的工作流程为：

（1）S1、S2、S5此时为在线状态，在线可用工作人员列表ASL={S1,S2,S5}，S4为离线状态，S3为忙碌状态。

（2）游客T3在当前位置请求帮助，并在求救终端屏幕上选择求救原因“游客物品被盗”，将按照自定义通讯协议5将其用户标示符，以及所在位置（118.90583,32.10389），求助原因发送至服务器。

（3）服务器接收救援请求，首先检查请求有效性，防止重复请求。遍历队列RQ检查是否存在相同用户的任务请求，设定此时救援队列RQ为空，因此没有相同用户任务请求，该请求有效，生成新的任务R1；若救援队列RQ此时为空，则立即处理R1；否则，根据R1的求助原因对应的优先级以及求助时间，按照公开方法一将该任务插入救援队列RQ中等待处理。

（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}。

根据CList顺序，首先向S2发送救援任务R1，S2所携带的工作人员救援终端发出声音报警，并且工作人员终端屏幕上出现文字提示“王五，女，30岁，物品被盗请求帮助”并在屏幕的地图界面标示出求助位置。收到任务请求后1分钟内未接受该任务，服务器继续向CList中下一名候选工作人员S1发送R1。S1,S2均未接受该任务，则该任务被放回队列RQ中。

（5）此时，T1也发起了救援请求,求救原因为“游客受伤”，因为事件紧急该用户重复多次点击了救助按钮并向服务器发送了救援请求。

（6）服务器接收到T1的多次救援请求，当第一次接收到T1请求时，遍历队列RQ无该T1的其他请求任务，因此生成新的任务R2。在此时RQ中已有任务R1，但R2任务的求助原因“游客受伤”级别高于“游客物品被盗”，因此根据公开方法一将该任务提前至R1之前，并取出R2执行调度。而再次接受到T1的救援请求时，由于RQ中已存在任务R2，R2与新的救援请求：（1）用户ID相同（2）请求类型相同（3）R2请求时间未超过10分钟，因此这几次请求将被自动判定为重复请求。

（7）R2任务类型对应职责为“医疗员”的工作人员，从ASL中查找，S5唯一符合，因此向其派送任务R2。

（8）工作人员S5接收该任务，将其从ASL集合中移出，并建立起T1——S5的双向安全救援链，此时每隔30秒T1端将收到1次由自定义通信协议8发送的S5位置信息，S5端也将收到由自定义通信协议9发送的T1位置信息。

（9）服务器每隔90秒检查一次救援请求队列RQ，若ASL非空且RQ非空则取出队列顶部的救援请求r进行调度；因此90秒后将R1取出再次进行调度，过程与步骤4类似，将按照此时S1、S2的当前位置，按距离远近依次向其派送任务。

（10）R2任务完成后S5通知服务器任务完成，将S5其重新放入ASL列表中。该任务调度结束。

Claims

1.一种基于移动定位的联动救援方法，其特征在于，包括以下步骤：

步骤四：服务器通过以下几种方式触发对救援请求的处理：

步骤七：工作人员完成救援任务，向服务器发送信息。

2.根据权利要求1所述的基于移动定位的联动救援方法，其特征是：所述求助用户、工作人员的基本资料是通过账号注册等方式人工预先录入数据库中，所述动态信息是在使用移动终端设备过程中实时获取并存储在数据库中。

3.根据权利要求1所述的基于移动定位的联动救援方法，其特征是所述救援请求优先级队列中的每个救援请求是一个包括如下元素的集合：用户唯一标示符、请求优先级、请求类型、求救时间。

4.根据权利要求1所述的基于移动定位的联动救援方法，其特征是：所述求助用户与该工作人员的一对一双向安全救援链，是由服务器每隔特定时间向求助用户发送施救工作人员动态，向施救工作人员发送求助用户动态。