基于B/S结构的虚拟应急演练系统设计

张学锋， 李文兵， 储岳中， 何胜方， 汤亚玲

(1.安徽工业大学 计算机科学与技术学院,安徽 马鞍山 243000；2.马鞍山钢铁公司港务原料总厂,安徽 马鞍山 243000)

0 引 言

近年来，我国的化工企业生产事故频发，造成了巨大的生命和财产损失，从国家到个人，都越来越关注化工企业的生产安全，如何防范事故的发生。但是目前大多数的企业对于安全事故的预防还停留在单纯的事故原因分析与总结，以及对员工的一些文字或视频形式的教学培训，效果一般[1]。目前,国内外在应急演练仿真系统研究方面均有着不少成果，国外如美国应急演练模拟中心(National Exercise Simulation Center，NESC) 对虚拟环境下各类灾害进行了仿真演练，构建了情景模型、能力模型以及决策模型[2]，参演者通过决策模型的选项进行决策演练，这种方式缺乏了仿真演练的沉浸感，更多的是针对上层决策人员。国内如朱新平等[3]提出的基于虚拟现实的机场消防救援虚拟演练平台，平台主要针对与机场的消防救援虚拟演练，其场景、流程单一化，缺乏变化性。鲁道毅等[4]提出的船舶三维及VR沉浸式海事监管业务培训平台，平台主要针对LNG船舶，建立了PSC检查素材库，解决了船舶PSC检查的培训问题，提高了执法人员的监督检查能力。祁超等[5]提出了面向高层指挥人员的应急演练仿真平台设计，该平台以动态演练为基础，提出了一个面向高层指挥人员的分布式交互应急演练仿真服务平台，相比较静态演练，动态演练极大提高了演练的灵活性，但该平台主要针对高层指挥人员，忽略了下级人员实际操作的重要性。

以上研究都有各自的特点，但研究都有一些共同的问题就是强调定制化、使用场景单一化以及系统使用有着诸多条件限制。在现实条件下，事故是随着环境因素不断变化的，不管是指挥人员还是下级救援人员都会随着这个变化不断调整方案，同时传统三维模拟仿真系统大多采用C/S的架构，限制了用户的使用条件。为了突破传统应急仿真演练平台的局限性，设计了基于B/S架构和Unity 3D技术的虚拟应急演练仿真系统，应急演练仿真与场景配置相结合，通过多种优化技术保证系统运行的流畅性，同时内部设计的通信框架很好地实现了网络数据的同步以及演练数据的存储。指挥层可以设置灾害形式、天气环境条件以及下发任务与问答题，下级人员执行具体操作，不仅突出了指挥层对于事故处理的领导作用，同时可以用于基层员工的日常安全培训。

1 系统设计

在结合前人研究成果以及考虑实际需求，以多个实际项目为参考，在支持基本的多人协同演练的基础上，加入了场景二次自定义配置等新的元素。系统包括应急演练和场景配置两部分，采用B/S架构，极大地提升了整个应急演练仿真系统的灵活性与可配置化程度。图1为系统整体框架。

图1 系统框架Fig. 1 System framework

1.1 场景编辑模块

场景编辑及预案推演模块实现了在基本场景下的二次自定义编辑。提供的二次自定义编辑的场景元素有：灾难点、角色的出生点、事件触发器、车辆以及场景中的特殊模型如储罐、消防水炮等。

主要功能包括场景的编辑、保存，物体的复制、删除、移动和旋转，以及对物体相关信息的编辑、关联，比如阀门与灾难点通过两者的ID进行关联，实现阀门控制灾难的进程，并且支持灾难的预览，系统支持配置各种类型的事件触发器，这些触发器常常与模型相结合从而实现了人物与场景之间的各种互动。场景编辑完成后，服务端接收相关场景自定义物体的数据会在云端生成相关的xml文件，用以记录物体的位置、属性等信息。图2为编辑模块界面部分。

1.2 演练仿真模块

演练仿真模块，客户端首先会从云端下载基本场景以及读取配置场景物体所保存的xml信息文件，两者结合构建新的场景。系统采用无固定预案设计，采用下发任务命令的形式，并且指挥层作为整个演练中权限最高的角色，能够对演练人员进行实时监控，观看演练人员的操作是否符合规定，并且可以下发相关问题对参与人员进行考核。在事故控制方面，指挥层可以控制事故的发生，以及天气时间。图3为演练模块指挥端界面。

图2 编辑模块界面Fig. 2 Edit module interface

图3 演练模块指挥端界面Fig. 3 Command interface of drill module

2 系统关键技术

2.1 B/S架构设计与数据交互

虚拟应急演练仿真系统采用B/S结构设计，将功能实现的核心部分集中到服务器，客户机只需要通过浏览器就可以使用系统服务，系统分别由数据服务，应用服务以及资源服务共同为Web服务端提供支持，图4所示系统服务架构图。

(1) Web服务端，是用户使用系统最直观的部分，通过浏览器直接访问Tomcat Web 服务器。客户端三维仿真主要采用了WebGL技术标准[6]。

(2) 应用服务端，其主要功能是实现客户端的网络通信和数据同步，保证在多用户使用时，客户端不会出现掉线，高延迟的状况。

(3) 数据服务端，客户端所使用的大量数据都是存放在云端数据库，通过数据服务相应的接口完成与云端数据库的交互，保障了客户端数据访问的稳定性。

(4) 资源服务端，客户端中所使用的大量的图片、题库文件和各种需要动态加载的模型都是放置在资源服务器中，减轻了系统使用时的带宽压力。

2.2 网络通信与数据同步

对于多人协同演练，网络通信与数据同步是极其重要的，客户端与服务端之间必须做到实时通信才能保证各个客户端的数据的及时同步以及客户端之间的实时通讯。

虚拟应急演练仿真系统的客户端与后端系统服务的通信协议选用WebSocket协议[7]。但有些通信不需要保证实时性，因此系统对资源、对数据库的其他请求依然使用的是HTTP协议。

除了通信协议，数据格式的设计也是核心部分，一个好的通信数据格式，可以提高开发效率、通信效率，有效降低客户端与服务端之间通信时带宽资源的占用。图5为系统的通信数据格式。

图5 系统通信数据格式Fig. 5 System communication data format

图5中，MessageType就是客户端请求应用服务的类型，系统中对同步的数据类型进行了细化，主要有几种类型：演练开始结束、移动、通讯、灾难、天气、装备、技能、任务数据以及答题数据等。对于消息内容，则依据同步动作所需要的变量来决定，为了降低同步数据量，对移动的同步中所用数据做了特殊处理，其中所用到的位移、方向、移动速度、转向速度分别使用vector3、short、sbyte、sbyte数据类型,有效降低了整体同步数据量。同时所有参与网络同步的物体均挂载NetworkSceneObject脚本，脚本中生成并保存了该物体的唯一ID号。图6为网络通信框架。

图6 网络通信框架Fig. 6 Network communication framework

其中，NetworkMessage脚本中主要用于注册各种网络消息，包括消息类型，消息类以及消息内容的序列化、反序列化。客户端发送消息首先对消息进行序列化，服务端接收消息后向其他客户端广播或通过玩家唯一ID发送给指定客户端，客户端接收消息后进行反序列化，然后调用NetMessageHandle进行相应的处理。

2.3 任务与答题机制

系统采用指挥端动态下发任务和答题的机制，任务机制包括了任务的下发、接收，完成与否判断以及任务数据上传云端。图7为任务系统和答题系统。

任务数据的设计依据任务的目标角色，物体，动作而定。比如下发一个将伤员A从危险区域转移到安全区的任务，任务数据就会包含伤员A的唯一的物体ID编号，目标区域触发器的物体编号，以及执行的目标角色。结合这些数据，当用户将角色转移至目标区域时，只需要判断目标伤员有没有触发这个区域触发器就行了。同时加载答题时，会先下载题目html文件，之后在客户端进行解析，完美解决了加载富文本以及图片的问题。

图7 任务系统和答题系统Fig. 7 Task and question system

2.4 事故与天气特效设计

虚拟演练仿真，其仿真的意义就在于对事故以及其他要素的最大限度还原。因此立足于视觉以及实际情况，加入了事故与天气特效，指挥端可以自由控制事故类型以及天气。事故特效包括了立体火、喷射火、环型火以及流淌火。天气特效包括了晴天、阴天、雨天、雷阵雨、多云。图8为部分特效。

3 系统优化

3.1 网格合并与LOD技术

LOD(Level of Detail)技术，也被称为细节层次技术，是根据物体模型的节点在显示环境中所处的位置和重要度，决定物体渲染的资源分配[8]。可以通过Unity中一个重要辅助开发参数Batches看到系统在渲染模型的开销。

CPU和GPU之间的通信是通过命令缓冲区来进行的，而“Draw Call”是其中一种。每次绘制一个物体都需要生成一个绘制指令给图形API，这个过程称为“Draw Call”，图9为“Draw Call”的过程，如果“Draw Call”的数量太多，CPU就会把大量时间花费在提交“Draw Call”命令上，造成CPU的过载。而每一次“Draw Call”会产生一个Batch，因此在三维场景的优化上，可以从减少Batches的角度进行优化。

图9 “Draw Call”过程Fig. 9 “Draw call” process

LOD技术是将模型简化成为几个面数层级不同的模型，随着摄像机的远近调用不同层级的模型，这种方式依然无法有效地减少“Draw Call”，采用网格合并优化与LOD技术相结合，在进行LOD优化之前会进行网格、材质合并，这种合并可以大大降低模型的Batches数值，达到有效减少“Draw Call”的目的，图10网格合并优化与LOD技术相结合的处理步骤。

图10 合并网格优化LOD技术处理步骤Fig. 10 LOD optimization by merging grids

相比较单纯LOD技术进行优化，虽然增加了一个合并网格材质的步骤，但合并网格后，生成LOD模型的时间大大降低，因此在处理模型的平均时间上并没有增加多少，而且在性能上提升非常大。图11在一般情况下，传统LOD模型的Batches数值达到694，而使用网格合并优化LOD后如图12降低到了11，随着摄像机的远近，其Batches数值最低可以到4，而优化前的LOD技术的最低值也有522。对于计算机来说，Batches数值的减少，就意味着CPU花在“Draw Call”上的时间减少，极大地提高了系统的稳定性与性能。

图11 未合并网格优化模型Fig. 11 Unconsolidated mesh optimization model

图12 合并网格优化模型Fig. 12 Merging mesh optimization model

3.2 在线生成导航网格寻路

应急演练仿真系统贴合实际，加入了模拟疏散人群，场景中有很多npc的角色，即非玩家角色存在的角色，因此将其疏散至指定地点就需要用到自动寻路。

传统的生成导航网格(NavMesh)[9]大多都在Unity中编辑场景时生成，由于演练仿真系统有着场景编辑的功能，使用传统的方式生成导航网格无法适用于多变的场景。因此支持在线生成导航网格信息。这种方式不需要在编辑器中进行相关操作，减少了场景搭建的工作量以及便于对基本场景的优化调整。其中三角导航网格的生成主要采用了三角剖分算法Delaunay[10]，图13为处理后生成的三角网格。

图13 处理后生成的三角网格Fig. 13 Generated triangular mesh after processing

线上生成导航网格以及寻路流程如下：配置端配置完场景保存后，调用烘焙导航网格信息函数，向该函数传入场景平面和障碍的碰撞体信息，生成导航网格信息，将信息传至云端服务生成xml文件，存储着网格顶点以及三角网格信息。客户端下达疏散命令，向服务端发送疏散消息，该消息包含目标点信息以及疏散命令下达的用户角色的ID，服务端接收消息后执行npc控制脚本中的开始疏散函数并传入目标点信息，在该函数中，npc的状态变为疏散状态，进入疏散状态后，将 npc起始点、疏散目标点传入路径生成函数，该函数加载网格导航信息，执行 A*寻路算法[11]，生成路径点集合。最后反复通过插值将目标移动至下个路径点，同时会一直执行人物移动的网络同步，各个客户端中npc的位置始终与服务端保持一致，直至npc成功到达目标点将其状态变为一般状态停止疏散。

4 实例应用与分析

虚拟应急演练仿真系统开发完成后先后在青岛港、江苏扬子江国际化学工业园、马钢集团进行了上线使用，并已经与广西华谊能源化工有限公司、上海华谊(集团)公司达成合作。虚拟应急演练仿真系统取得了良好的效果，帮助企业完成了数次虚拟仿真演练培训工作，在这些企业的应用中主要取得的效果如下：

企业的演练频率大大提升，参与人员可以更直观地看到灾害的形式、影响，与场景互动的过程，参与人员也更加熟悉设备的操作。

实现了企业应急演练常态化，可以随时发起演练，以此来考核员工的应急反应能力，不断提高员工的综合素质。

演练内容丰富多样化，配置与演练相结合，企业可以根据需要配置出多种灾害场景，提升了企业整体的应急能力，为防灾应急扫清盲点。

5 结 语

提出的虚拟应急演练仿真系统由场景配置模块与应急演练模块组成，使用户在使用时不再拘泥于一种演练预案或事故，并基于B/S架构开发，降低了用户的维护成本，保证了系统的可靠性。有效地提高了企业的综合应急能力，加强了基层职工以及指挥员对现场事故的应急救援与处置能力。该系统能够很好地满足企业对应急仿真演练的各种需求，在需要应急仿真演练的企业及工业园区等具有较好的推广应用价值。