CN109447390A - 机场应急救援的任务管理系统 - Google Patents

Abstract

本公开涉及一种机场应急救援的任务管理系统，包括：服务器，分别与第一终端和第二终端通信；第一终端能够与第二终端通信；服务器接收第一终端发送的第一任务状态，第一任务状态表示第一基元任务的状态，第一基元任务为机场应急救援的基本步骤；若服务器判断记录的第一基元任务的状态不同于第一任务状态，则服务器将记录的第一基元任务的状态更新为第一任务状态；服务器向第二终端发送第一任务状态，以使第二终端将第一基元任务的任务状态更新为第一任务状态，能够使得持有第二终端指挥人员能够及时获得持有第一终端基层应急人员的任务处置状态，从而有效协助机场决策层指挥人员组织针对突发事件的应急救援工作的指挥效率。

Description

机场应急救援的任务管理系统

技术领域

本公开涉及计算机技术领域，尤其涉及一种机场应急救援的任务管理系 统。

背景技术

随着我国民航运输量的不断增大，民航局在发布的进一步深化民航改革 工作意见中，将“提升应急处置能力”作为主要改革目标。

从相关机场对突发事件的应急救援工作和经验来看，机场应急救援工作 组织实施的效果主要取决于日常管理、培训和演练，由此保障机场相关部门 在面对机场紧急突发事件时能够快速有效的实施应急救援工作。

然而近年来，机场突发事件更趋复杂，日常的培训和演练已经无法满足 愈发增加的应急工作的难度，应急处置已成为制约中国民航发展的短板。如 何及时高效地组织针对突发事件的应急救援工作，成为民航业亟待深入研究 的重要问题，关乎民航业的声誉和发展。

发明内容

有鉴于此，本公开提出了一种机场应急救援的任务管理系统。

根据本公开的一方面，提供了一种机场应急救援的任务管理系统，所述 系统包括：

服务器，分别与第一终端和第二终端通信；

第一终端能够与第二终端通信；

所述服务器接收所述第一终端发送的第一任务状态，所述第一任务状态 表示第一基元任务的状态，所述第一基元任务为机场应急救援的基本步骤；

若所述服务器判断记录的第一基元任务的状态不同于所述第一任务状 态，则所述服务器将记录的第一基元任务的状态更新为所述第一任务状态；

所述服务器向所述第二终端发送所述第一任务状态，以使所述第二终端 将所述第一基元任务的任务状态更新为第一任务状态。

在一种可能的实现方式中，

所述服务器接收所述第二终端发送的第二任务状态，所述第二任务状态 表示第二基元任务的状态，第二基元任务为机场应急救援的基本步骤；

若所述服务器判断记录的第二基元任务的状态不同于所述第二任务状 态，则所述服务器将记录的第二基元任务的状态更新为所述第二任务状态。

在一种可能的实现方式中，

若所述服务器判断记录的第二基元任务的状态不同于所述第二任务状 态，则向所述第一终端发送所述第二任务状态，以使所述第一终端将所述第 二基元任务的任务状态更新为第二任务状态。

在一种可能的实现方式中，

所述服务器接收所述第一终端发送的用于新建基元任务的第一请求，所 述第一请求携带新建的第三基元任务；

所述服务器在判断所述第一终端的岗位标识对应的基元任务集中不包 括所述第三基元任务时，将所述第三基元任务添加到所述第一终端的岗位标 识对应的基元任务集中；

所述服务器将所述第三基元任务发送至所述第二终端，以使所述第二终 端将所述第三基元任务添加到所述第一终端的岗位标识对应的基元任务集 中。

在一种可能的实现方式中，

所述服务器接收所述第二终端发送的第二请求，其中，所述第二请求用 于指示所述服务器向第二终端发送目标应急救援任务集合，所述第二请求携 带事故类型，目标应急救援任务集合与事故类型一一对应，所述目标应急救 援任务集合包括多个互不相同的基元任务、各基元任务的任务状态、所述第 一终端的岗位标识与多个基元任务中的一个或多个基元任务的对应关系、以 及所述第二终端的岗位标识与多个基元任务中的一个或多个基元任务的对 应关系；

所述服务器获取所述事故类型对应的目标应急救援任务集合，并向所述 第二终端发送所述目标应急救援任务集合；

所述服务器向所述目标应急救援任务集合对应的第一终端发送与所述 第一终端的岗位标识对应的基元任务集。

在一种可能的实现方式中，

所述第一终端接收并存储所述第一终端的岗位标识对应的基元任务集。

在一种可能的实现方式中，

所述第二终端接收并存储所述目标应急救援任务集合。

在一种可能的实现方式中，所述系统包括一个或多个第一终端。

在一种可能的实现方式中，所述第一终端为用于应急救援现场使用的终 端。

在一种可能的实现方式中，所述第二终端为用于应急救援指挥部使用的 终端。

本公开通过服务器在判断第一终端发送的第一任务状态不同于服务器 记录的第一基元任务的状态时，将记录的第一基元任务的状态更新为第一任 务状态并向第二终端发送第一任务状态，以使第二终端将第一基元任务的任 务状态更新为第一任务状态。由此能够使得持有第二终端指挥人员能够及时 获得持有第一终端基层应急人员的任务处置状态，使得应急指挥人员能够对 应急事件的处置进度和状态有直观的把握，从而有效协助机场决策层指挥人 员组织针对突发事件的应急救援工作的指挥效率，有效减少应急状况下的人 员、财产损失，对机场的日常安全与持续发展起到了保障作用。

根据下面参考附图对示例性实施例的详细说明，本公开的其它特征及方 面将变得清楚。

附图说明

包含在说明书中并且构成说明书的一部分的附图与说明书一起示出了 本公开的示例性实施例、特征和方面，并且用于解释本公开的原理。

图1是根据一示例性实施例示出的一种机场应急救援的任务管理系统的 示意图。

图2是根据一应用示例示出的一种机场应急救援的任务管理系统的系统 架构示意图。

图3是根据一应用示例示出的基元任务库的示意图。

图4是根据一应用示例示出的第一终端的任务管理界面的示意图。

图5是根据一应用示例示出的第二终端的任务管理界面的示意图。

图6是根据一应用示例示出的第二终端的任务管理界面的示意图。

图7是根据一应用示例示出的第二终端的任务管理界面的示意图。

具体实施方式

以下将参考附图详细说明本公开的各种示例性实施例、特征和方面。附 图中相同的附图标记表示功能相同或相似的元件。尽管在附图中示出了实施 例的各种方面，但是除非特别指出，不必按比例绘制附图。

在这里专用的词“示例性”意为“用作例子、实施例或说明性”。这里作为 “示例性”所说明的任何实施例不必解释为优于或好于其它实施例。

另外，为了更好的说明本公开，在下文的具体实施方式中给出了众多的 具体细节。本领域技术人员应当理解，没有某些具体细节，本公开同样可以 实施。在一些实例中，对于本领域技术人员熟知的方法、手段、元件和电路 未作详细描述，以便于凸显本公开的主旨。

图1是根据一示例性实施例示出的一种机场应急救援的任务管理系统的 示意图。如图1所示，所述系统可以包括：

服务器，分别与第一终端和第二终端通信。

第一终端能够与第二终端通信。

所述服务器接收所述第一终端发送的第一任务状态，所述第一任务状态 表示第一基元任务的状态，所述第一基元任务为机场应急救援的基本步骤。

若所述服务器判断记录的第一基元任务的状态不同于所述第一任务状 态，则所述服务器将记录的第一基元任务的状态更新为所述第一任务状态。

所述服务器向所述第二终端发送所述第一任务状态，以使所述第二终端 将所述第一基元任务的任务状态更新为第一任务状态。

在本示例中，第一终端可以为在应急救援现场参与应急救援的基层应急 人员所使用的终端，第一终端可以为移动终端，可以采用无线通信的方式与 服务器进行通信，第一终端可以包括以下任意一种或多种：智能手机、平板 电脑、笔记本电脑、智能眼镜、智能手表等，在此不做限定。第一终端可以 为一个或多个，在此不做限定。

在本示例中，第二终端可以为应急救援工作中后方指挥所的指挥人员所 使用的终端，第二终端可以采用有线通信或无线通信的方式与服务器进行通 信，第二终端可以包括以下任意一种或多种：台式电脑、平板电脑、笔记本 电脑等，在此不做限定。第二终端可以为一个或多个，在此不做限定。

在一种可能的实现方式中，第一终端还可以采用无线通信的方式与第二 终端进行通信。

第一终端可以对应一个或多个基元任务，第一终端对应的基元任务可以 表示持有第一终端的基层应急人员在执行应急救援任务所需要执行的任务， 一个基元任务可以包括所需要执行的基本步骤和基本步骤的说明。例如，如 表1所示，第一终端可以为手机，持有第一终端的基层应急人员的岗位可以 为机场航务部的气象预报员，则该气象预报员对应的基元任务可以包括名称 为“发布信息”，内容为“进行气象观测和预报，并实时向指挥中心和其他 救援单位发布：风向，风速，温度、能见度、天气现象，未来天气趋势预报”，以及名称为“封存资料”，内容为“对气象资料进行封存”等两个基元任务。

在一种可能的实现方式中，如表1所示，基元任务还可以包括执行该基 元任务的前置条件，这样可以通过基元任务的前置条件提醒基层应急人员完 成处置该基元任务的前提和时机。例如，名称为“发布信息”，内容为“进 行气象观测和预报，并实时向指挥中心和其他救援单位发布：风向，风速， 温度、能见度、天气现象，未来天气趋势预报”的前置条件可以为“收到应 急救援指挥中心通知”。这样，可以提醒该气象预报员在“收到指挥中心通 知”之后再执行名称为“发布信息”的基元任务。

表1

在一种可能的实现方式中，基元任务的状态可以表示为基层应急人员处 置该基元任务的状态，其中，如果基层应急人员未处置该基元任务，则该基 元任务的状态可以为待处置；如果基层应急人员正在处置该基元任务，则该 基元任务的状态可以为处置中，如果基层应急人员已经处置完毕该基元任 务，则该基元任务的状态可以为处置完毕。本领域技术人员可以根据需要选 择合适的基元任务状态，在此不做限定。如表1所示，名称为“发布信息” 的基元任务的状态可以为“处置中”，名称为“封存信息”的状态可以为“待 处置”。这样，携带基元任务的第一终端可以引导基层应急人员根据其岗位 对应的基元任务和基元任务的状态有条不紊的执行应急救援任务，有效避免 基层应急人员出现任务漏处置以及任务重复处置等问题，有利于提高应急救 援效率。

作为本实施例的一个示例，服务器和第二终端可以预存全部基元任务， 以及每个基元任务对应的状态。每个第一终端可以分别预存各自对应的基元 任务，以及每个基元任务的状态。第一终端可以在检测到将第一基元任务的 状态更新为第一任务状态的操作时，向服务器发送携带第一任务状态的第一 更新指令。服务器接收该第一更新指令并获取第一更新指令包含的第一任务 状态。服务器若判断记录的第一基元任务的状态不同于所述第一任务状态， 则服务器将记录的第一基元任务的状态更新为所述第一任务状态。并向第二 终端发送携带第一任务状态的第二更新指令，以使第二终端将第一基元任务 的任务状态更新为第一任务状态。

本公开通过服务器在判断第一终端发送的第一任务状态不同于服务器 记录的第一基元任务的状态时，将记录的第一基元任务的状态更新为第一任 务状态并向第二终端发送第一任务状态，以使第二终端将第一基元任务的任 务状态更新为第一任务状态。由此能够使得持有第二终端指挥人员能够实时 获得持有第一终端基层应急人员对应的基元任务的任务处置状态，使得应急 指挥人员能够对每个基层应急人员对应急事件的处置进度和状态有直观的 把握，从而有效协助机场决策层指挥人员组织针对突发事件的应急救援工作 的指挥效率，有效减少应急状况下的人员、财产损失，对机场的日常安全与 持续发展起到了保障作用。

在一种可能的实现方式中，所述服务器接收所述第二终端发送的第二任 务状态，所述第二任务状态表示第二基元任务的状态，第二基元任务为机场 应急救援的基本步骤。若所述服务器判断记录的第二基元任务的状态不同于 所述第二任务状态，则所述服务器将记录的第二基元任务的状态更新为所述 第二任务状态。

其中，第二终端对应的基元任务可以包括持有第二终端的指挥人员在执 行应急救援任务所需要执行的基本步骤和基本步骤的说明。

举例来讲，服务器和第二终端均可预存全部的基元任务，以及每个基元 任务的状态。第二终端在检测到其对应的第二基元任务更新为第二任务状态 的操作时，可以向服务器发送携带第二任务状态的第三更新指令。服务器接 收该第三更新指令时，获取第三更新指令包含的第二任务状态。若服务器判 断记录的第二基元任务的状态不同于第二任务状态，则可以将记录的第一基 元任务的状态更新为第二任务状态。这样，服务器可以实时获取第二终端对 应的基元任务的状态。

在一种可能的实现方式中，若所述服务器判断记录的第二基元任务的状 态不同于所述第二任务状态，也可以向所述第一终端发送所述第二任务状 态，以使所述第一终端将所述第二基元任务的任务状态更新为第二任务状 态。

接上例，可以在第一终端预存全部基元任务，服务器可以在判断记录的 第二基元任务的状态不同于第二任务状态时，向第一终端发送携带第二任务 状态的第四更新指令，第一终端根据第四更新指令包含的第二任务状态，将 第一终端记录的第二基元任务的状态更新为第二任务状态。这样，持有第一 终端的基层应急人员和持有第二终端的指挥人员可以互相直观的了解到对 方的应急任务的处置进度，更有利于指挥人员与基层应急人员的协调配合， 从而提高救援效率。

在一种可能的实现方式中，所述服务器接收所述第一终端发送的用于新 建基元任务的第一请求，所述第一请求携带新建的第三基元任务。所述服务 器在判断所述第一终端的岗位标识对应的基元任务集中不包括所述第三基 元任务时，将所述第三基元任务添加到所述第一终端的岗位标识对应的基元 任务集中。所述服务器将所述第三基元任务发送至所述第二终端，以使所述 第二终端将所述第三基元任务添加到所述第一终端的岗位标识对应的基元 任务集中。

在一种可能的实现方式中，第一终端的岗位标识可以标识为持有第一终 端的基层应急人员所就职的岗位，第一终端的岗位标识对应的基元任务集可 以为该基层应急人员在应急救援中所承担的所有基元任务的集合。可以在第 一终端中预存第一终端的岗位标识对应的基元任务集。例如，若第一终端为 机场消防部门的消防员A在执行应急救援任务时所使用的终端，则可以预存 第一终端的岗位标识为消防员，消防员对应的基元任务集为“到达现场”，“灭 火”，“救援被困人员”等。

举例来讲，持有第一终端的基层应急人员可以根据现场的实际情况添加 或删除第一终端的岗位标识对应的基元任务。例如，若基层应急人员在勘察 事故现场之后发现需要新增基元任务，则可以通过第一终端向服务器发送新 建第三基元任务的第一请求，服务器在判断第一终端的岗位标识对应的基元 任务集中不包括该第三基元任务时，可以将第三基元任务添加到第一终端的 岗位标识对应的基元任务集中。服务器将第三基元任务发送至第二终端，以 使第二终端将第三基元任务添加到第一终端的岗位标识对应的基元任务集 中。这样，由于新增的基元任务是基层应急人员根据现场实际情况请求添加 或删除的，这使得添加或删除基元任务之后形成的第一终端的岗位标识对应 的基元任务集能够更加有效的满足事故现场的救援需求，从而进一步提高救 援效率。

作为本实施例的一个示例，所述服务器接收所述第二终端发送的第二请 求，其中，所述第二请求用于指示所述服务器向第二终端发送目标应急救援 任务集合，所述第二请求携带事故类型，目标应急救援任务集合与事故类型 一一对应，所述目标应急救援任务集合包括多个互不相同的基元任务、各基 元任务的任务状态、所述第一终端的岗位标识与多个基元任务中的一个或多 个基元任务的对应关系、以及所述第二终端的岗位标识与多个基元任务中的 一个或多个基元任务的对应关系。

所述服务器获取所述事故类型对应的目标应急救援任务集合，并向所述 第二终端发送所述目标应急救援任务集合。

所述服务器向所述目标应急救援任务集合对应的第一终端发送与所述 第一终端的岗位标识对应的基元任务集。

在一种可能的实现方式中，所述第一终端接收并存储所述第一终端的岗 位标识对应的基元任务集。

在一种可能的实现方式中，所述第二终端接收并存储所述目标应急救援 任务集合。

举例来讲，服务器可以预存各事故类型与应急救援任务集合的对应关 系。在事故发生时，持有第二终端的指挥人员可以根据获得的信息判断事故 类型。(例如，事故类型可以包括航空器失事，航空器劫持等)，接着指挥人 员可以通过第二终端向服务器发送新建目标应急救援任务集合的新建指令， 该新建指令可以携带事故类型。服务器可以根据新建指令中包含的事故类型 和各事故类型与应急救援任务集合的对应关系获得事故类型对应的目标应 急救援集合。其中目标应急救援任务集合可以包括多个互不相同的基元任 务、各基元任务的任务状态、第一终端的岗位标识与多个基元任务中的一个 或多个基元任务的对应关系、以及第二终端的岗位标识与多个基元任务中的 一个或多个基元任务的对应关系。

服务器获取事故类型对应的目标应急救援任务集合，并向第二终端发送 目标应急救援任务集合。第二终端可以接收并保存该目标应急救援任务集 合。

服务器可以获取目标应急救援任务集合对应的多个第一终端和该多个 第一终端中每个第一终端的岗位标识对应的基元任务，并向每个第一终端发 送与其岗位标识对应的基元任务集。第一终端接收并存储第一终端的岗位标 识对应的基元任务集。

图2是根据一应用示例示出的一种机场应急救援的任务管理系统的系统 架构示意图。如图2所示，机场应急救援的任务管理系统的总体设计可以采 用B/S(Browser/Server,浏览器/服务器模式)方式设计，通过WebGIS(网络 地理信息系统)技术实现前端的地理可视化呈现，后台采用Postgresql(以加 州大学伯克利分校计算机系开发的POSTGRES，现在已经更名为 PostgreSQL，版本4.2为基础的对象关系型数据库管理系统)空间引擎进行 数据存储和管理。为保障系统灵活可扩展，维护成本低，容错性高。如图2 所示，系统总体框架采用四层架构设计，分别为：

数据访问层(Data access layer)：该层负责数据的访问，通常主要处理 数据库的访问，但也可以处理其他如文本文档、二进制文件或XML文档的访 问。数据访问层负责数据在数据库中的持久化和检索过程，采用ORM数据实 体关系映射部件实现。

业务逻辑层(Business logic layer)：该层负责业务规则的制定、业务流 程的实现等与业务需求有关的系统设计，它处于数据访问层与服务层中间， 起到了数据交换中承上启下的作用。由于该层是一种弱耦合结构，层与层之 间的依赖关系是向下的，底层对于上层而言是“无知”的，改变上层的设计 对于其调用的底层而言没有任何影响。

web服务接口层(Service API layer)：服务接口层是处于应用程序业务层 和应用层之间的应用程序边界，由restful api实现。服务接口层隐藏了业务逻 辑层的细节，提供更宏观，面向表现层的服务逻辑，使得用户不用直接关心 业务逻辑。

用户应用层(Use Interface layer)：最接近用户。用于显示数据和接收用 户输入的数据，为用户提供一种交互式操作的界面。如图2所示，用户应用 层可以包括应急演练时间管理预案管理子系统(第二终端的示例))，该系统 可以执行上文中第二终端执行的方法步骤；移动子系统(第一终端的示例)， 该系统可以执行上文中第一终端执行的方法步骤；应急救援网格图和运维子 系统(服务器的示例)，运维子系统可以执行上文中服务器执行的方法步骤。

在系统投入运行之前需要针对系统进行数据录入和系统设置，由此为之 后的应急管理工作提供支撑，数据录入和系统设置主要包括：预案管理、应 急人员管理、应急资源管理等部分。

为规范机场应急救援工作，及时有效地应对机场突发事件，避免或减少 人员伤亡和财产损失，尽快恢复机场正常生产运营秩序，机场突发事件应急 救援管理手册成为机场应急预案的第一参考规则。随着机场突发事件日趋复 杂化，将纸质预案电子化、电子预案模块化、模块预案智能化成为现代智能 化机场管理成为一个行之有效的应急预案管理方式。

图3是根据一应用示例示出的基元任务库的示意图。如图3所示，预案模 块化拆解的基础是建立基元任务库。基元任务是一个包括分解到具体岗位和 唯一类型的任务，包含了执行该任务时需要执行的工作事项和相关的工作要 求说明。电子预案拆解工作会将预案中的每一个指令都转化为一个包括工作 岗位和具体工作内容的基元任务，不同事故类型的突发事件预案可以由基元 任务库中的若干基元任务配置而成。如基元任务库中的任务不能满足需求， 可以新增或修改基元任务。需要说明的是，电子预案拆解工作可以由机场应 急专家们实施，也可以由人工智能系统(例如可以为神经网络模型)实施， 也可以由机场应急专家和人工智能系统共同实施，在此不做限定。

应急预案管理系统以国际国内各大机场的应急预案为参考，可以根据结 合目标机场的实际状况提供预案模板，预案编制、修订，预案审核，预案发 布等四大功能模块。

建立预案模板：由于不同事件类型的预案会有大量重复的任务(例如突 发事件发生后，塔台第一时间通知消防等)，因此通过建立基本的基元任务 库和事件预案模型(事故类型的示例)，可以方便的进行电子预案的创建和 扩展。在实际工作中，可根据实际情况调用相关预案模型，并可对多个预案 模型合并、扩展，生成处置方案(目标应急救援任务集合的示例)，加强应 急预案的可执行性、实用性和针对性，真正使预案成为可执行、可操作预案。

预案编辑、修订：预案的编辑、修订只需要已有的预案模板中的基元任 务进行重新配置即可。建立新的事件类型则需要自主配置新的预案模板。

预案审核模块能够检索出新增或被修改的数据，审核员对该数据进行判 别以确保修订后预案的合理性以及准确性。审核人员可以查看全部的审核记 录，其他用户可以查询自己提交的审核请求和审核结果。审核通过的数据才 能进入预案数据库；审核不通过的数据注明原因，以便返回数据修改操作者 重新修改。

突发事件发生后，机场应急救援指挥中心人员可以判断突发事件的事故 类型，并通过第二终端向服务器发送携带该事故类型的指令，服务器接收到 该指令，并根据指令中的事故类型生成应急救援任务集合，其中，应急救援 任务集合与事故类型一一对应，应急救援任务集合包括多个互不相同的基元 任务、各基元任务的任务状态、第一终端的岗位标识与多个基元任务中的一 个或多个基元任务的对应关系、以及第二终端的岗位标识与多个基元任务中 的一个或多个基元任务的对应关系。服务器可以向第二终端发送应急救援任 务集合，并向目标应急救援任务集合对应的第一终端发送与第一终端的岗位 标识对应的基元任务集。由此可以建立应急救援小组、通知全体应急处置人 员并根据岗位自动分配任务至各应急处置人员。

当进行应急救援时，第二终端可以根据指挥人员输入的事故类型和事故 地点发送至服务器，服务器根据事故类型和事故地点结合从运行监控系统获 取航行通告、气象报文等机场运行数据，进行自动分析生成包括突发事件分 析、参考救援方案和资源调度方案在内的辅助决策报告，并将决策报告发送 至第二终端帮助指挥中心领导对救援方案和资源调度进行果断、合理的决 策，提高应急指挥的决策质量和应变能力。

现场的各基层应急人员持有的第一终端在检测到基元任务的状态更新 时，可以将更新后的基元任务的状态实时发送至服务器，服务器在检测到更 新后的基元任务的状态不同于存储的该基元任务的状态时，更新该基元任务 的状态并将更新后的基元任务的状态发送至救援指挥中心，以便指挥中心的 领导能够实时地把握应急演练进度。

图4是根据一应用示例示出的第一终端的任务管理界面的示意图。图5是 根据一应用示例示出的第二终端的任务管理界面的示意图。如图4和图5所 示，可以以顺序排列的形式显示第一终端或第二终端对应的基元任务集中的 各基元任务的名称和状态，并且，第一终端或第二终端可以在检测到用户触 发某个基元任务名称和状态的区域时(例如，触发如图4中的“部门通知” 和如图5中的“赶赴指挥中心”所显示的区域)，则第一终端或第二终端可以 显示该基元任务对应的内容、前置条件以及修改状态的控件等，这样，可以 使得持有第一终端的基层应急人员和持有第二终端的指挥人员能够直观的 了解到各自应当执行的任务和任务执行的状态。

图6是根据一应用示例示出的第二终端的任务管理界面的示意图。如图6 所示，航空器屏跑道事件(事故类型的示例)对应的应急预案拆分后的基元 任务可以以树型结构呈现在第二终端的显示界面上，可以用不同的颜色表示 各基元任务的状态，例如，未处置基元任务的状态为红色，正在处置基元任 务的状态为黄色，处置完毕基元任务的状态为绿色等。指挥人员可以通过第 二终端可查看各基元任务的相关信息(例如，该基元任务的负责部门，执行 人，基元任务的具体内容等)，使得指挥人员能够对应急救援任务的进展一 目了然。

图7是根据一应用示例示出的第二终端的任务管理界面的示意图。如图7 所示，第二终端还可以根据获得的基元任务的数据进行统计分析：根据移动 端通过服务器汇报的信息，对各部门任务进度、执行情况进行实时的汇总分 析以进一步帮助指挥人员直观的掌握应急救援的进度并可以进行事后评估。 需要说明的是，本领域技术人员可以根据需要选择合适的统计分析方法(例 如饼图、甘特图或气泡图等)在此不做限定。

本公开的机场应急救援的任务管理系统通过对纸质的机场应急预案进 行模块化拆解，将复杂的预案电子化并拆分为基元任务并分配至具体工作岗 位，一方面使得应急指挥人员能够对事件整体进度和状态有直观的把握，也 使得基层应急人员能够明晰个人任务，无需事先安排便能够根据提示自主执 行应急任务；同时通过对预案进行建模可检查预案编制的合理性，进一步明 确预案涉及单位的职责、任务，建立该类型突发事件应对流程。

本公开可以是系统、方法和/或计算机程序产品。计算机程序产品可以包 括计算机可读存储介质，其上载有用于使处理器实现本公开的各个方面的计 算机可读程序指令。

计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指 令的有形设备。计算机可读存储介质例如可以是――但不限于――电存储设 备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的 任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包 括：便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、 可擦式可编程只读存储器(EPROM或闪存)、静态随机存取存储器(SRAM)、 便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)、记忆棒、软 盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及 上述的任意合适的组合。这里所使用的计算机可读存储介质不被解释为瞬时 信号本身，诸如无线电波或者其他自由传播的电磁波、通过波导或其他传输 媒介传播的电磁波(例如，通过光纤电缆的光脉冲)、或者通过电线传输的 电信号。

这里所描述的计算机可读程序指令可以从计算机可读存储介质下载到 各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无 线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传 输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每 个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序 指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计 算机可读存储介质中。

用于执行本公开操作的计算机程序指令可以是汇编指令、指令集架构 (ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数 据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，编程 语言包括面向对象的编程语言—诸如Smalltalk、C++等，以及常规的过程式 编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完 全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软 件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程 计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过 任意种类的网络—包括局域网(LAN)或广域网(WAN)—连接到用户计算机， 或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连 接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化 定制电子电路，例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编 程逻辑阵列(PLA)，该电子电路可以执行计算机可读程序指令，从而实现 本公开的各个方面。

这里参照根据本公开实施例的方法、装置(系统)和计算机程序产品的 流程图和/或框图描述了本公开的各个方面。应当理解，流程图和/或框图的 每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指 令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可 编程数据处理装置的处理器，从而生产出一种机器，使得这些指令在通过计 算机或其它可编程数据处理装置的处理器执行时，产生了实现流程图和/或框 图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读 程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据 处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介 质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规 定的功能/动作的各个方面的指令。

也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装 置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上 执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其它 可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一 个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本公开的多个实施例的系统、方法和 计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或 框图中的每个方框可以代表一个模块、程序段或指令的一部分，模块、程序 段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。 在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标 注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有 时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用 执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬 件与计算机指令的组合来实现。

以上已经描述了本公开的各实施例，上述说明是示例性的，并非穷尽性 的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和 精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显 而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际 应用或对市场中的技术的技术改进，或者使本技术领域的其它普通技术人员 能理解本文披露的各实施例。

Claims (10)

1.一种机场应急救援的任务管理系统，其特征在于，所述系统包括：

服务器，分别与第一终端和第二终端通信；

第一终端能够与第二终端通信；

所述服务器接收所述第一终端发送的第一任务状态，所述第一任务状态表示第一基元任务的状态，所述第一基元任务为机场应急救援的基本步骤；

若所述服务器判断记录的第一基元任务的状态不同于所述第一任务状态，则所述服务器将记录的第一基元任务的状态更新为所述第一任务状态；

所述服务器向所述第二终端发送所述第一任务状态，以使所述第二终端将所述第一基元任务的任务状态更新为第一任务状态。

2.根据权利要求1所述的系统，其特征在于：

所述服务器接收所述第二终端发送的第二任务状态，所述第二任务状态表示第二基元任务的状态，第二基元任务为机场应急救援的基本步骤；

若所述服务器判断记录的第二基元任务的状态不同于所述第二任务状态，则所述服务器将记录的第二基元任务的状态更新为所述第二任务状态。

3.根据权利要求2所述的系统，其特征在于：

若所述服务器判断记录的第二基元任务的状态不同于所述第二任务状态，则向所述第一终端发送所述第二任务状态，以使所述第一终端将所述第二基元任务的任务状态更新为第二任务状态。

4.根据权利要求1所述的系统，其特征在于：

所述服务器接收所述第一终端发送的用于新建基元任务的第一请求，所述第一请求携带新建的第三基元任务；

所述服务器在判断所述第一终端的岗位标识对应的基元任务集中不包括所述第三基元任务时，将所述第三基元任务添加到所述第一终端的岗位标识对应的基元任务集中；

所述服务器将所述第三基元任务发送至所述第二终端，以使所述第二终端将所述第三基元任务添加到所述第一终端的岗位标识对应的基元任务集中。

5.根据权利要求1所述的系统，其特征在于：

所述服务器接收所述第二终端发送的第二请求，其中，所述第二请求用于指示所述服务器向第二终端发送目标应急救援任务集合，所述第二请求携带事故类型，目标应急救援任务集合与事故类型一一对应，所述目标应急救援任务集合包括多个互不相同的基元任务、各基元任务的任务状态、所述第一终端的岗位标识与多个基元任务中的一个或多个基元任务的对应关系、以及所述第二终端的岗位标识与多个基元任务中的一个或多个基元任务的对应关系；

所述服务器获取所述事故类型对应的目标应急救援任务集合，并向所述第二终端发送所述目标应急救援任务集合；

所述服务器向所述目标应急救援任务集合对应的第一终端发送与所述第一终端的岗位标识对应的基元任务集。

6.根据权利要求5所述的系统，其特征在于：

所述第一终端接收并存储所述第一终端的岗位标识对应的基元任务集。

7.根据权利要求5所述的系统，其特征在于：

所述第二终端接收并存储所述目标应急救援任务集合。

8.根据权利要求1至7中任意一项所述的系统，其特征在于，所述系统包括一个或多个第一终端。

9.根据权利要求1至7中任意一项所述的系统，其特征在于，所述第一终端为用于应急救援现场使用的终端。

10.根据权利要求1至7中任意一项所述的系统，其特征在于，所述第二终端为用于应急救援指挥部使用的终端。