CN103324095B - 舰船火灾损管推理仿真控制系统 - Google Patents

Abstract

本发明公开了一种舰船火灾损管推理仿真控制系统，包括主控制部、若干舱室传感器、传感器状态检测模块、传感器状态提示模块、手动选择模块、3D模型标示模块、火灾及舱室信息显示模块、数据传输模块、火灾损管推理模块和3D仿真模拟灭火模块。本发明把火灾信息发送到火灾损管推理系统得到灭火处理意见，以帮助控制人员快速的做出准确和安全的灭火决策，从而可以减少由于控制人员延误灭火的时机或者作出不正确的决定而造成不必要的人员危害和经济损失，同时对于做出的决策在3D仿真模拟灭火模块中模拟灭火过程，从而实现在仿真模拟的环境下对舰船发生火灾时控制人员和舱室人员的灭火训练，使得他们非常熟悉自己的任务和操作要求，从而提高灭火的效率。

Description

舰船火灾损管推理仿真控制系统

【技术领域】

本发明涉及舰船火灾损管推理仿真控制系统，既能够在平时进行火灾损管模拟训练，又能够在真实发生火灾时对舰船上的火灾情况进行有效的处理和控制。

【背景技术】

自改革开放以来，中国经济不断迅猛发展，综合国力不断提高，特别是加入世界贸易组织之后，中国和世界其他国家的经济贸易来往越来越多，交流与合作愈加密切。我国长达1.8万多公里的海岸线，拥有6500余个岛屿，并通过第一岛链与马六甲海峡直接与太平洋和印度洋相连，通航贸易逐渐平凡，为我国充分利用、开发海洋资源，运输矿物资源等提供便利，为我国经济发展和文化发展提供有力的自然条件。同时随着近几年中国海军的迅速崛起，逐渐冲出第一岛链，走向远洋，走向世界，保卫祖国国土和领海安全，海军的装备数量越来越多，舰船的体积也越来越大，航行的距离也越来越远，与此同时，舰船火灾事故与损失也呈逐年上升趋势，各种类型舰船火灾、爆炸事故频发，造成大量财产损失与人员伤亡。据统计，世界上每天有5起海上舰船事故，舰船火灾约占舰船事故总数的11%，在舰船火灾中，舰船机舱火灾占舰船火灾总数的75%以上。

舰船是一个相对独立的流动场所，远离海岸航行在渺茫的大海上发生火灾时想要得到及时的救援的可能性非常的小，而且舰船上电气电子设备遍布全船，设备集中环境复杂，起火源增多，一旦发生火灾，火势蔓延速度快，人员疏散不便，使得火灾的扑救难度增大，实施逃生和消防救援更加困难。特别对于一些运载易燃易爆物品的舰船，在舱室内集中了大量易燃易爆品，使得发生火灾的危险性增大，火灾事故造成的损失与危害更加严重。大多数的舰船中的报警系统都非常的简单，过多的依靠人力，特别是在大型的舰船中，舱室和设备数量非常多，一旦发生报警，需要派人去报警区查看，确定火灾位置等情况，然后汇报给控制室，然后控制室才能知道火灾的具体情况，下达控制决策，这样很可能延误了灭火的最佳时间，导致火灾迅速蔓延，范围扩大，而且控制人员对舰船的全局没有一个准确的掌握，这样必然造成不必要的人员危害和经济损失。

自进入21世纪以来，随着计算机技术，网络技术和通信技术的不断发展，我国已经全面进入信息化建设的时代，信息化已经触及到社会的各个领域，信息化建设对于生产力和管理效率有了非常大的提高，现代舰船信息化建设也是刻不容缓的，如何通过信息化实时而全面的监控舰船的各个舱室的状态，一旦发生火灾时控制人员第一时间了解到火灾发生的地点及其具体位置，火灾的大小等级，火灾蔓延的速度以及火灾发生舱室的人员和设备信息，对舰船火灾的整体情况有个全面掌握，以便能够做出更加准确和安全的决策，更好的命令和协调舱室人员和救援人员进行灭火和设备等物品及时转移，对于减少舰船火灾带来的损失有着至关重要的意义。

【发明内容】

本发明的目的就是解决现有技术中的问题，提出一种舰船火灾损管推理仿真控制系统，既能够在平时进行火灾损管模拟训练，又能够在真实发生火灾时对舰船上的火灾情况进行有效的处理和控制，且系统安全可靠，硬件成本低。

为实现上述目的，本发明提出了一种舰船火灾损管推理仿真控制系统，包括主控制部、若干舱室传感器、传感器状态检测模块、传感器状态提示模块、手动选择模块、3D模型标示模块、火灾及舱室信息显示模块、数据传输模块、火灾损管推理模块和3D仿真模拟灭火模块；所述舱室传感器和传感器状态检测模块分别连接到主控制部的输入端，若干舱室传感器分别安装在机舱、货舱、甲板、餐厅和卧室内，传感器状态检测模块对所有舱室传感器进行实时检测，判断舱室传感器是否正常工作；所述传感器状态提示模块、火灾及舱室信息显示模块、3D模型标示模块分别连接到主控制部的输出端，传感器状态检测模块检测到舱室传感器处于不能正常工作的状态时，将舱室传感器的非正常工作信息发送给主控制部，主控制部控制传感器状态提示模块进行提示，主控制部还在3D模型标示模块中标示出不能正常工作的舱室传感器的位置，舱室传感器感应到火灾信息后，传送给主控制部，主控制部在火灾及舱室信息显示模块中显示出火灾信息，在3D模型标示模块中标示出火灾位置和火灾等级；所述主控制部中设有手动选择模块，手动选择模块可模拟舱室传感器的状态；主控制部与火灾损管推理模块之间通过数据传输模块连接，数据传输模块从主控制部接收到火灾信息后，由火灾损管推理模块经过分析后用接收到的火灾信息初始化一个火灾本体实例，用所述火灾本体实例通过基于火灾本体建立起来的推理系统进行推理，得出相对应于所述火灾本体实例的灭火方法，再通过数据传输模块将得出的火灾本体实例的灭火方法返回给主控制部，所述主控制部将接收到的火灾本体实例的灭火方法传输给3D仿真模拟灭火模块，3D仿真模拟灭火模块在界面上显示给灭火方法和灭火策略。

作为优选，所述火灾及舱室信息显示模块中显示出的火灾信息包括火灾的大小等级、火灾的发生时间、火灾的持续时间，火灾的蔓延速度、舱室名称、舱室具体位置、舱室内人员数量和舱室内设备情况。

作为优选，所述火灾本体实例是根据火灾的性质和舱室的性质而建立的。

作为优选，所述过基于火灾本体建立起来的推理系统的推理规则是根据火灾的大小等级、火灾的发生时间、火灾的持续时间，火灾的蔓延速度、舱室名称、舱室具体位置、舱室内人员数量和舱室内设备情况而建立的。

作为优选，所述火灾损管推理模块中火灾本体是使用OWL本体语言在Protege3.4中建立OWL火灾本体，同时使用SWRL规则建立推理规则，然后将OWL火灾本体和SWRL规则通过SWRLJessTab转化为Jess推理机的事实库和规则库，最后进行推理。

作为优选，所述主控制部与数据传输模块之间采用Socket通信方式，数据传输模块作为服务器端进行监听，主控制部作为客户端发送消息给数据传输模块。

本发明的有益效果：本发明通过在主控制部监控各个舱室中的火灾传感器状态，当发生火灾时，在3D模型标示模块中标示火灾发生的位置，并且显示火灾和舱室的具体信息，并把这些信息发送到火灾损管推理系统得到灭火处理意见，以帮助控制人员快速的做出准确和安全的灭火决策，从而可以减少由于控制人员延误灭火的时机或者作出不正确的决定而造成不必要的人员危害和经济损失，同时对于做出的决策在3D仿真模拟灭火模块中模拟灭火过程，同时，通过操作手动选择模块可任意选择模拟各舱室发生火灾的情形，来对相关舰船工作人员进行仿真灭火训练，从而实现在仿真模拟的环境下对舰船发生火灾时控制人员和舱室人员的灭火训练，使得他们非常熟悉自己的任务和操作要求，从而提高灭火的效率。

本发明的特征及优点将通过实施例结合附图进行详细说明。

【附图说明】

图1是本发明舰船火灾损管推理仿真控制系统的示意图。

【具体实施方式】

参阅图1，舰船火灾损管推理仿真控制系统，包括主控制部1、若干舱室传感器2、传感器状态检测模块6、传感器状态提示模块7、手动选择模块3、3D模型标示模块4、火灾及舱室信息显示模块5、数据传输模块8、火灾损管推理模块9和3D仿真模拟灭火模块10；所述舱室传感器2和传感器状态检测模块6分别连接到主控制部1的输入端，若干舱室传感器2分别安装在机舱、货舱、甲板、餐厅和卧室内，传感器状态检测模块6对所有舱室传感器2进行实时检测，判断舱室传感器2是否正常工作；所述传感器状态提示模块7、火灾及舱室信息显示模块5、3D模型标示模块4分别连接到主控制部1的输出端，传感器状态检测模块6检测到舱室传感器2处于不能正常工作的状态时，将舱室传感器2的非正常工作信息发送给主控制部1，主控制部1控制传感器状态提示模块7进行提示，主控制部1还在3D模型标示模块4中标示出不能正常工作的舱室传感器2的位置，舱室传感器2感应到火灾信息后，传送给主控制部1，主控制部1在火灾及舱室信息显示模块5中显示出火灾信息，在3D模型标示模块4中标示出火灾位置和火灾等级；所述主控制部1中设有手动选择模块3，手动选择模块3可模拟舱室传感器2的状态；主控制部1与火灾损管推理模块9之间通过数据传输模块8连接，数据传输模块8从主控制部1接收到火灾信息后，由火灾损管推理模块9经过分析后用接收到的火灾信息初始化一个火灾本体实例，用所述火灾本体实例通过基于火灾本体建立起来的推理系统进行推理，得出相对应于所述火灾本体实例的灭火方法，再通过数据传输模块8将得出的火灾本体实例的灭火方法返回给主控制部1，所述主控制部1将接收到的火灾本体实例的灭火方法传输给3D仿真模拟灭火模块10，3D仿真模拟灭火模块10在界面上显示给灭火方法和灭火策略。

主控制部1：主要实时监控各个舱室的火灾传感器状态，因为是对火灾的监控，所以传感器都是火灾传感器，主要是通过舱室内温度来测量和判断，舱室我们主要选取了几个经常会发生火灾的地点，如：机舱，货舱，甲板，餐厅，卧室，仅仅是作为例子，当检测到状态不正常的传感器会进行红色标示，并且将传感器所在舱室对应在3D模型中的位置用红色闪烁显示，以示警告，能让控制人员非常直观的看到火灾在整个舰船中的位置，同时显示火灾和舱室的具体信息，如：火灾的大小等级，火灾的发生时间和持续时间，火灾蔓延速度，舱室名称和具体位置，舱室内人员数量和舱室内设备情况等，将获取到的火灾信息传送到数据传输端中的火灾损管推理系统中得到推理结果，并返回给主控制端。

数据传输模块8：是处于主控制部1和火灾损管推理模块9之间，主要负责接受主控制部1发送过来的火灾信息以及返回火灾处理意见和发送火灾处理命令到3D仿真端以及返回的处理结果信息，这个部分主要涉及到数据的通信方式和数据的接收、分析和转化处理。数据传输模块8的数据接收与转化是Socket与OPC两种通信方式，OPC服务器到数据传输端是OPC的数据通信方式，数据传输端时刻监听OPC服务器中每个传感器的数据值，一旦有变化即激发数据变化事件执行相应的操作；Socket通信方式是主控制部1和数据传输端以及数据传输端和3D仿真端的通信方式。通信的方式为Socket通信方式，主控制端作为Socket服务器端，通过设置的端口号进行监听，如果收到数据传输端这个端口的连接请求则建立连接，并可以接受数据，同时主控制端也要向数据传输端发送数据，IP地址中设置的地址就是数据传输端的IP地址。

火灾损管推理模块9：数据传输模块8从主控制部1接收到火灾信息经过分析之后用这些信息初始化一个火灾本体实例，用这个火灾实例通过基于火灾本体建立起来的推理系统进行推理，得出相对于这个火灾实例的灭火方法，然后将推理结果作为灭火意见返回给主控制端，以帮助控制人员做出合理的灭火决策。火灾本体的的建立需要分析火灾的性质，仓库的性质，即需要了解基本的消防专业知识。然后需要建立推理规则，在各种情况下应该采取何种措施，如：不同的火灾大小等级，火灾持续时间，火灾的蔓延速度，发生在不同的地点，仓库不同的灭火设备，应该执行不同的灭火措施，这个规则是可以动态建立的，可以更改、增加和删除。然后将推理规则加入到推理机中，初始化火灾实例就可以推理出结果。使用KEPServerEx4.0作为OPC服务器用来接收传感器端发送过来的数据，接收之后可以传送给火灾损管推理模块9，同时数据传输模块8可以直接接收主控端的火灾的仿真数据同样传送给火灾推理系统（即：火灾损管推理模块9），主控制部1也可以将数据直接写入到OPC服务器中；火灾推理系统中火灾本体使用OWL本体语言在Protege3.4中建立，同时使用SWRL建立推理规则，然后将OWL火灾本体和SWRL规则通过SWRLJessTab转化为Jess推理机的事实库和规则库，最后进行推理，推理需要先建立一些火灾实例，比如：不同的火灾等级，不同的地点，不同的蔓延速度和持续时间等进行推理出执行的不同的灭火措施。

3D仿真模拟灭火模块10：这个部分就是接收到数据传输端发送过来的灭火处理指令执行相应的灭火行为，在三维虚拟环境中模拟灭火过程。

一、基于OGRE与QT的主控制端（即：主控制部1）。

主控制端是本系统的最前端，位于控制室，主要用于控制人员监控舰船的各个舱室的传感器状态，当发生火灾时能够第一时间了解火灾具体信息，如：舱室(舱室里面设备以及人员信息)，具体地点，火灾发生时间和持续时间，火灾等级等详细信息，并且能够在舰船的三维模型中用红色闪烁来标示火灾发生的位置，使得更加直观和更加全面了解舰船的火灾情况，有利于控制人员做出更加安全准确的灭火措施。主控端传感器数据的来源有两种：一是来自OPC服务器中变化的数据，OPC服务器的数据是通过直接和传感器相连的监控组态软件得到的，本文使用InTouch。二是我们可以直接模拟传感器数据，即在状态栏中直接选中某一个传感器，模拟火灾的发生。检测到火灾之后可以将火灾的具体信息发送到火灾损管推理系统进行消防措施的推理，并且推理结果返回主控制端显示。

1.1OGRE引擎

OGRE（Object-Oriented Graphics Rendering Engine，即：面向对象图形渲染引擎）是一个用C++开发的面向场景、非常灵活的3D引擎，它旨在让开发人员更容易、更直接地利用硬件加速的3D图形系统开发应用。这个类库隐藏了底层系统库（如：Direct3D和OpenGL）的所有细节，提供了一个基于世界对象和其他直观类的接口。OGRE是一个开源的3D引擎，并且只是一个图形渲染引擎，被设计成世界级的图形解决方案，对于音效，网络，粒子系统，物理，用户界面等子系统OGRE提供了非常友好的API，能够很好的整合到一起，从而能够开发出功能强大的系统。这也是OGRE为什么能够可以成为世界级的图形引擎，她具有非常好的内聚性和灵活性，对于开发人员没有过多的限制，相对于其他的引擎来说OGRE没有限制开发人员一定要使用某一种内置的音效，界面或者其他子系统，用户选择的空间很大，可以根据每个人的熟悉程度和喜好来选择。

OGRE是面向对象的c++开发的图形引擎，所以OGRE中每一个物体都是一个现实事物的抽象，都是当作对象来设计的，如：摄像机，灯光，场景，场景管理器，资源管理器，实体，节点等，每个部分都是独立的对象，层次结构非常清楚，相对于更加底层的Direct3D和OpenGL来说更加的灵活，开发的效率更加的高。OGRE的渲染过程如下：

（1）初始化资源和插件系统：Ogre中所有要用到的资源的路径信息都保存在resource.cfg文件中，以及所有的插件子系统保存在plugins.cfg文件中，渲染开始先导入这些文件，以便资源管理器从这些路径处导入所需的资源。

（2）系统配置：主要配置底层渲染系统，主要为Direct3D和OpenGL，选其一即可，以及是否全屏，渲染设备，视频模式，资源创建模式等，这些配置信息保存在ogre.cfg文件中。

（3）创建场景管理器：在OGRE中场景管理器有多个不同用途的场景管理器，主要为：八叉树场景管理器OctreeSceneManager和地形管理器TerrainSceneManager，OctreeSceneManager是通用的场景管理器，而TerrainSceneManager是高度场场景优化的管理器。

（4）创建摄像机以及视口：Ogre中摄像机决定了我们看到的3D场景的视角和位置，主要通过SetPosition和LookAt来设置，同时视口决定了我们看到的窗口的大小，以及场景的背景颜色。

（5）导入资源：根据资源文件的路径导入需要的资源，包括模型的纹理图片、材质、网格模型等。

（6）创建场景：这个部分是整个渲染中最重要的部分，我们能够看到的所有东西都是在这里创建的，包括灯光，人物，地形，天空，建筑物，所有你想创建的物体，我们可以设置物体的位置，灯光的颜色，同时对一些数据的处理都可以在这里完成。

（7）创建帧监听：Ogre中的渲染是一帧一帧做的，每一帧都要去重新渲染场景，更新渲染对象，对于在视口范围内的物体加入渲染队列，视口范围之外的退出渲染队列，所以对于需要对场景需要更新和变化的都是在这里处理，并且可以设置一些变量，比如:在计时器到达某一个设定值后进行清零，以周期性的在场景中显示某个物体或者动作。

（8）开始渲染：到此开始最后的渲染过程，把渲染队列中的所有物体进行一一渲染，显示在窗体中，并且进入无限循环，随着每一帧不停的反复。

1.2QT开发框架

QT是一个跨平台的C++图形用户界面应用程序开发框架，支持windows，linux以及Mac OSX等主流操作系统，面向对象的QT具体非常好的封装性，模块化程度高，可重用性好，而且支持组件开发，一般常用的工具都以组件对象的形式插入到QT中，使得开发进程大大提高，而且支持底层图形引擎OpenGL和高级引擎Ogre，本论文中就是用到QT和Ogre的整合开发。

QT Creator是一个用于Qt开发的轻量级跨平台集成开发环境，是首个提供跨平台的集成开发环境，使得开发用户界面非常快速，并且非常容易上手，缩短开发时间，同时QT Creator创建的UI可以转化为相应的c++代码，自动生成.h文件供其他工程使用，重用性好，本实施例中的主控制端的界面就是QT Creator创建的。

1.3主控制端功能模块

主控制端主要包含以下4个模块：传感器状态模块，3D模型展示模块，火灾具体信息模块和数据传输模块，传感器状态模块主要是显示舰船各个舱室中的火灾传感器的状态信息，3D模型展示模块展示一艘舰船的三维模型，并且当某个舱室发生火灾时在相应的位置上用红色闪烁来标示，能够更加直观的展示火灾部位，火灾具体信息显示火灾本身及火灾方式地点等信息，并且当发生火灾时可以将这些信息发送到数据传输端的火灾推理系统进行推理得到消防措施，返回显示在底部的消防措施和反馈结果栏中，最后一个是数据传输端连接模块，这个模块为主控制端和数据传输端数据通信建立连接。

1.3.1传感器状态模块

这个模块主要有两部分内容：一、传感器状态显示以及触发的Label颜色的改变与Textbox内容的变化，二、传感器所在相应舱室在3D模型中的顶点范围的查询。

（1）传感器状态显示:在本论文中只是选取了舰船的几个典型的部位的传感器来显示，在实际应用中可以随具体情况而扩展和缩减，主要有机舱温度传感器2个，卧室温度传感器2个，餐厅温度传感器2个，甲板温度传感器2个，弹药库温度传感器3个，还有3个仓库温度传感器，主要是为和推理系统中我们设定的舱室相对应。传感器的状态有正常和不正常两种，这两种状态之间有个阀值，处在这个阀值之下的是正常状态，超过这个阀值就是不正常状态，传感器数据来源有个两种：一是传感器监控组态软件InTouch端直接从传感器中获得的数据，然后传送到OPC服务器中，然后将OPC服务器和主控端相连接从而得到传感器数据。本文只讲述OPC服务器和主控端的连接，组态软件InTouch与OPC服务器连接由于本文涉及范围有限，我们不作介绍，而OPC服务器和主控端的连接我们放在数据传输端作为数据传输部分来详细讲解。二是我们直接设置好某个传感器的状态，作为测试来引起一场火灾，通过仿真测试按钮将激发一系列的反应：相应传感器颜色变为红色以示警告，3D模型展示中相应传感器所在位置出现红色闪烁，火灾具体信息区中显示火灾所在舱室名称，火灾具体位置等具体信息。

（2）舱室顶点范围的查询：3D模型展示区中出现闪烁需要我们事先建立好每个传感器所在舱室在舰船中的位置信息，这个就涉及到舱室在3D模型中相应的顶点的范围，根据这些顶点我们可以按照这些顶点手动绘制一个对象模型并设置纹理颜色为红色与黑色每个一段时间进行转化，从而实现闪烁。

1.3.23D模型展示模块

3D模型展示模块是本章中最重要的部分，涉及到QT与OGRE的整合问题，OGRE中对于火灾发生舱室对应到3D模型中闪烁显示的问题，还有就是OGRE的渲染过程，这个在前面OGRE的介绍中已经有介绍，在这一部分我们使用具体实现函数进行更详细的描述。

（1）QT与OGRE的整合：QT是一个用户界面应用程序框架，用户界面是由QWidget组成的，而OGRE是一个图形引擎，要把一个图形引擎的渲染窗口与QT整合，关键在于把这个窗口作为QWidget的子类，并在子类中重写OGRE所有渲染过程，即把渲染窗口作为QWidget整合到QT中。

（2）3D模型相应部分闪烁：要使得火灾所在位置的3D模型闪烁，首先要知道相应部分的顶点位置，在上一节中我们可以通过查询传感器名称与3D中相应部分顶点索引的关系得到顶点信息，得到顶点索引之后我们可以取每三个顶点为一组建立一个三角形，从而可以把所有的相关的顶点连接在一起，并可以设置材质的颜色来标示。根据顶点索引手动创建一个ManualObject对象来作为闪烁区域。

1.3.3数据传输端连接模块

这个模块是主控制端和数据传输端通信的桥梁，负责把火灾的具体信息发送给我数据传输端的火灾推理系统，做出推理之后将推理结果返回给主控制端，同时，对于3D仿真端返回的灭火结果也要由这个模块接收并显示在消防措施或反馈结果中。通信的方式为Socket通信方式，主控制端作为Socket服务器端，通过设置的端口号进行监听，如果收到数据传输端这个端口的连接请求则建立连接，并可以接受数据，同时主控制端也要向数据传输端发送数据，IP地址中设置的地址就是数据传输端的IP地址，关于Socket通信的问题在后续的数据传输端进行详细介绍。

1.3.4火灾信息显示模块

当传感器状态中有显示传感器不正常时，在舰船3D模型中闪烁显示火灾所在位置的同时在本模块要显示出这个位置的相关信息以及火灾的详细信息，对于火灾发生的位置信息事先我们要保存在数据库或者文件中，每个传感器对应点舱室名称，具体位置，舱室值班人员的数量，人员基本信息，舱室安全系数等等都要有详细的记录，以供查询；同时火灾的具体情况，如火灾的发生时间，持续时间等信息也可以根据传感器接收信息的时间来得到，至于火灾的等级和火灾蔓延速度可以在发生火灾时和相关舱室的值班人员取得联系了解详细情况。以下表1是关于传感器对应的舱室信息和火灾信息的测试用例，本实施例只是列出了部分船舱信息和火灾信息，具体可以在实际应用中增加、删除和修改，而且只写了甲板，机舱，弹药库仓库和餐厅各一个测试用例：

表1：传感器对应的舱室信息和火灾信息测试用例表

主控端发送给数据传输端的信号有四个：火灾发生的地点，火灾等级，火灾持续时间和火灾蔓延速度，因为这四个信号是火灾推理系统的初始化数据，用这个四个信号建立一个实例，从而推理出对于这个实例应该采取什么样的灭火措施。通过点击按钮“火灾推理系统推理”发送火灾信号给推理系统，信号通过Socket通信的方式发送，推理结果和反馈结果也是通过Socket方式返回到消防措施和反馈结果中，以便主控制端能够采取进一步的判断决策。灭火的结果可能火没有灭掉，反而越来越大则反馈回来的的结果会在火灾等级中显示更高等级，而且对于推理系统推理得到的结果不是非常符合火灾的实际情况，控制人员可以更改消防措施，或者对于火灾等级、火灾蔓延速度等控制人员可以修改然后在重新发送到推理系统推理，得到更准确的意见。

当得到火灾推理系统的推理结果后反馈在消防措施/反馈结果栏中，控制人员可以参考推理结果作为处理意见，做出决策，然后点击发送灭火指令按钮后把灭火策略发送到3D仿真端，接收到灭火指令后3D仿真端会启动灭火系统，执行开启相对应的灭火器和设施进行灭火。

发送的灭火措施有四个：火灾报警器报警、消防员到达火灾现场、启动水成膜消防炮和泡沫喷洒系统。

出现火灾起火，在火灾很小的时候，舱室值班人员发现起火会进行手提式灭火器进行灭火，当一定时间之后火灾没有灭掉时，火灾越来越大，会反馈灭火结果给主控制端，其中包括火灾等级等信息，火灾等级会变大，火灾持续时间也会增大，同时蔓延时间也会变化，所以这时就需要主控制端的控制人员再次发送灭火指令过来，使用更强大的灭火器进行灭火，在值班人员手提式灭火器没有灭掉火灾之后需要启动消防员和消防车用泡沫喷洒系统进行灭火，如果还是不能灭火则会再进一步使用两个消防栓旁边的消防炮进行灭火。

二、基于本体的火灾损管推理系统（火灾损管推理模块9）。

火灾损管推理系统是一个数据分析推理系统，根据输入不同的火灾信息推理得出不同的推理结果即灭火措施，比如火灾发生的地点，火灾的等级，火灾蔓延速度，火灾持续的时间等都会决定具体不同的灭火决策，火灾损管推理系统的推理条件来自主控制端的发送过来的火灾数据，得出的推理结论将返回给主控制端作为灭火意见供控制人员参考，从而提高控制人员做出准确而安全的灭火决策的速度和效率，减少决策时间，从而避免一些由于措施灭火良机造成的人员危害和经济损失。本实施例将构建一个火灾本体，作为损管推理系统的基础，在火灾本体的基础上建立SWRL推理规则，然后将火灾本体和SWRL推理规则转化为Jess推理机的事实库和规则库，对于某一个不同条件下的火灾，根据火灾发生的地点，火灾的等级，火灾蔓延速度，火灾持续的时间建立一个火灾的实例，将这个实例经过Jess推理机推理得出我们想要的推理结果，即灭火措施。

2.1火灾本体的建立

介绍本体(ontology)的定义及其描述语言(OWL)，如何根据本体的构造规则去构建一个火灾的本体，为后续的火灾损管推理做基础。

2.1.1本体的定义及其描述语言

Ontology(本体)的概念源于哲学，即“对世界上客观存在物的系统地描述”。在人工智能界，最早给出Ontology定义的是Neches等人，他们将Ontology定义为“给出构成相关领域词汇的基本术语和关系，以及利用这些术语和关系构成的规定这些词汇外延的规则的定义”。最著名并被引用得最为广泛的定义由Gruber提出“本体是概念模型的明确的规范说明”。相关文献对该定义进行了引申，提出“本体是共享概念模型的形式化规范说明”。相关文献认为本体的概念包括四个主要方面:(1)概念化(conceptua2lization):客观世界的抽象模型;(2)明确(explicit):概念及它们之间联系都被精确定义;(3)形式化(formal):精确的数学描述;(4)共享(share):本体中反映的知识是其使用者共同认可的。在计算机领域讨论Ontology,要点在如何表达共识,即概念的形式化,涉及到Ontology的描述语言和建设方法等。

2.1.2领域本体的构造规则

对于本体的构建并没有一个标准的规则，因为不同领域的特点和各自问题的需求不同，所以现有的很多ontology的构造规则都不尽相同，但是一个好的本体基本都有以下一些特点：

(1)清晰(Clarity)：ontology中的每一个术语表示的含义必须要清晰，并且要加以清晰的注释，并且术语间的层次关系要清晰，不能让人产生混乱。

(2)一致性(Coherence)：ontology定义的类，属性，个体及其公理和注释都应该前后一致，不能产生歧义。

(3)可扩展性(Extendibility)：ontology中定义的类，属性，个体，公理等应该可以随时扩展，而不影响原有的定义，这样对于以后的添加，修改提供方便，使得本体更加灵活。

(4)最小的编码偏置(Minimal Encoding Bias)：概念的描述不应该依赖于某一个特殊的表示，因为实际的系统可能采取不同的表示方法。

(5)(Minimal Ontological Commitment)：ontology具有最小的约束，只要能够满足特定的知识共享需求即可，使用约束最弱的公理和词汇来定义就可以。

2.1.3领域本体的构建方法

领域本体的构建方法大致可以分为三类：1、自上而下，从领域概念出发定义一些通用的类，然后向下不断的细分为更详细的类。2、自下而上，从一些具体详细的对象出发定义具体类，然后把类似的类归为一类，慢慢向上归一化。3、自中间到两边，从间接的概念出发，不断向两边扩展和补充。实际应用中具体使用哪种方法取决于实际工程的特点，大小和目的。如果工程比较小，具体的对象少可以采用自下而上的方法，如果工程量大，底层概念太多则采用自上而下。本文涉及到火灾领域，而且本文建立的本体的目的是通过火灾发生地点、等级、转移速度和发生时间跨度决定应该采取什么消防措施，涉及到的消防工具也比较少，所以可以考虑从下而上去建立本体。本体的开发和完善是一个反复迭代的过程，所以没有一个严格上的说法。在工程上大致可以有一下六个步骤来构造一个本体：

(1)确定本体的领域和范畴。首先要确定本体是属于哪个领域和作用范畴，以及本体的目的，本体是用来描述什么问题的，解决什么问题，这样经过详细的分析建立起来的本体才能准确性更好，层次更加清晰。

(2)复用现有的本体。如果在现有的本体中能够找到和要构造的本体有相似的可以直接拿过来用，或者做适量的更改，这个是非常有效的方式。

(3)写出本体中所有需要的概念。将所有本体中需要构建的具体概念都全部写出来，即自下而上的方法中全部底层的概念，而不需要考虑他们之间的关系和属性等

(4)定义类及其层次结构。当将所有的概念从最小的类开始划分，相似的概念分为一个类中，然后将小的类划为更大的类，层层向上归为更抽象的类中。

(5)定义类的属性。类的属性有对象属性和数据属性之分，对象属性是描述类与类之间的关系的，每个属性都有他的作用域(ranges)和定义域(domains),定义域指这个对象属性对于那些类是有效的，即那些类有这个对象属性，而作用域指对象作用于哪些类，例如：父类Father，子类Child,属性hasChild的定义域为Father，作用域是Child类，但是两者不能反过来，如果要反过来可以定义一个Inverseof的属性hasParent，即hasParent与hasChild是相反的关系，这样则有hasParent的定义为Child，作用域为Father。数据属性是描述类的数据特征的，也有定义域(domains)和作用域(ranges)，定义域为对于哪些类有效，这个和对象属性是一样的，作用域是数据类型，如：string，int，boolen,float等。

(6)定义实例。给每个类定义一个实例，并给出这个实例的属性值。

2.1.4火灾本体的构建

从本实施例研究的火灾损管推理系统的目的出发，我们是要根据火灾发生时的具体情况通过推理系统得到应该采取的消防措施，供控制人员参考，以及时做出安全正确的灭火决策，，从而达到最好的灭火效果，避免因为难以迅速的决策而延误灭火的最佳时机，造成不必要的人员危害与经济损失，这样对于如何建立火灾本体我们就拥有了一个比较清晰的认识和了解，根据上述领域本体的构建方法以及一般本体的构建步骤，对于火灾本体的构建过程如下：

（1）本体领域：舰船火灾损管领域，目的：做出相应的消防措施。所以我们需要知道基本的舰船，火灾，消防相关领域的基本知识，对这些领域要做一个充分的了解，基本的概念主要是：火灾发生的地点(舰船中的机舱，仓库，甲板等)，火灾的等级(一般火灾，中等火灾，大火灾，特大火灾)，火灾蔓延速度(180m/h,250m/h,300m/h,350m/h等)，火灾持续的时间，灭火器的种类(干粉灭火器，水基灭火器，中倍泡沫灭火器，喷雾系统，高倍泡沫灭火器，1301装置，泡沫喷洒系统，水成膜泡沫消防炮)，舱室设备(火灾报警器，1301报警灯柱，楼梯喷淋系统，门，防火帘，防火帘喷淋系统)，消防员，舱室值班人员，控制室人员等。

（2）本体概念定义

1）舱室设备类：灭火器(干粉灭火器，水基灭火器，中倍泡沫灭火器，喷雾系统，高倍泡沫灭火器，1301装置，泡沫喷洒系统，水成膜泡沫消防炮),火灾报警器，1301报警灯柱，楼梯喷淋系统，门，防火帘，防火帘喷淋系统。

2）火灾类：火灾发生的地点，火灾的等级，火灾蔓延速度，火灾持续的时间，火灾发生时间。

3）人员：消防员，舱室值班人员，控制室人员。

火灾损管领域本体概念如下表2：

表2：火灾损管领域本体概念表

（3）定义属性：火灾本体的属性分为对象属性(Object Property)和数据属性(DatatypeProperty)，对象属性是火灾类、设备类和人员类之间的关系，而数据属性是每个类自身的性质，本论文中只对火灾类建立数据属性，有火灾发生地点、火灾等级、火灾发生时间、火灾持续时间和火灾蔓延速度五个。

（4）建立实例

对于每一个类我们都建立一个实例，其中Fire类下的子类是决定推理结果的，对于每一个子类的取值不同，会导致推理出不同的损管措施，即采用不同的灭火设备，所以是作为初始化条件输入的。所有的实例如下表3：

表3：火灾损管领域本体类实例表

建立的类实例时需要设置每个实例的对象属性的作用实例，根据本论文的目标是根据火灾的信息来推理灭火措施，即使用哪些灭火器去灭火，而灭火器是属于设备类，设备类拥有has-FireHappenDuration、has-FireHappenTime、has-FireLocation、has-FireRating和has-FireSpeed对象属性，所以对于设备类的实例我们可以设置对象属性到火灾类实例的关系，如：设备类有一个实例Device-1，这种设备有以下属性：火灾等级为FireRating-General,火灾蔓延速度为FireSpeed-Q,火灾发生地点为FireLocation-Deck，火灾持续时间为FireHappenDuration-One,则可以判断这个设备是火灾警报类FireAlarm，干粉灭火器类DryPowder，水基型灭火器类WaterBased，也就是说当火灾的信息为上述情况是推理结果为执行火灾警报器报警、干粉灭火器和水基型灭火器灭火。

2.2基于SWRL的推理规则建立

2.2.1SWRL

由于本体本身并没有建立规则的功能，所以使用SWRL来建立火灾推理的规则，SWRL(Semantic Web Language)是集本体和规则于一起的一种语言，SWRL的规则部分由RuleML所演变而来，并结合OWL(Web Ontology Language，Web本体描述语言)，目前已成为W3C规范之一。OWL是W3C推荐的本体描述语言，是由DAML和OIL所结合演变而来，OWL具有较强的表达能力，但是计算复杂度较高，处于对表达能力和可接受的计算复杂度的妥协和折中，OWL有三种表达能力提高的语言：OWL Lite，OWL DL和OWL Full，其中OWL Lite是OWL DL的子集，而OWL DL又是OWL Full的子集。SWRL是在OWL中加入了规则，因为规则能够提供更强的逻辑表达能力。例如：用一阶逻辑表示Uncle。

2.2.2SWRL框架

SWRL规则由Imp组成，Imp中包含Head和Body两部分，Head是规则中的推理结果，而Body是推理规则中的限制条件，由Body推理出Head，即如果某个实例符合Body中的限制条件则可以推理出Head中的结果。

而Head和Body是有Atom组成的，Atom是公理，Head和Body可以同时由几个Atom组成，即在多个限制条件下，如果都符合则可以推理出一系列的推理结果，当然也可以只有一个推理结果。在实际应用中，如果可以的话最好只写一个推理结果，同时出现的推理结果可以使用另外一条规则来实现。

Variable是表示变量，在Atom中可以使用变量，来表示变量满足的一些条件，Atom对这些变量的限制有以下几种情况：

1．C(x)：C是本体中的类，x是一个变量或实例，表示x是C类的实例。

2．P(x,y)：P是本体的属性，而x、y可以是变量、本体中类的实例或是本体的数据值。

3．SameAs(x,y)：表示x和y是一样的，x，y是实例或变量。

4．DifferentFrom(x,y)：x和y是不一样的，x，y是实例或变量。

Built-in是SWRL规则库中的一个规则组件，里面存储的都是SWRL可以直接拿来用的比较常用的逻辑比较关系，我们在实际设计SWRL规则的时候可以直接调用，而无需自己去重复编写，为我们开发工作省下了不必要的时间。这里的Built-in主要借鉴了XQuery和XPath中的Built-ins，例如swrlb:equal是由XQuery的op:equal而来。

SWRL是可以直接使用本体中的类、对象和属性的，而且SWRL中可以编写丰富的推理规则，所以SWRL是规则和本体的结合体，非常有利于在本体的基础上设计我们的推理系统。

例如在本体中定义了下列关系：

hasName(Hangzhou,“杭州”)

hasName(China,“中国”)

hasName(x,”张三”)

liveIn(x,place)

belongTo(place,China)

通过本体的描述我们可以知道x的名字是张三，有个地方叫杭州，x生活在这个地方，所以x生活在杭州，而这个地方是属于中国的，所以此时欲使用SWRL设计一条规则说明张三和中国之间的关系，在何种情形下张三是生活在中国的，规则如下：

Body

hasName(place1,“杭州”)

hasName(place2,“中国”)

hasName(x,”张三”)

liveIn(x,place1)

belongTo(place1,place2)

head

liveIn(x,“中国”)

这时SWRL可以直接使用本体中已经建立好的关系如liveIn(x,place1)，belongTo(place1,place2)和本体中所定义的属性资料例如place1这个地方的名字是“杭州”、place2的名字是“中国”，x的名字是“张三”，进而推理出本体未建立的关系liveIn(x,“中国”)，若是使用RuleML则需将x，place1，place2的关系全部定义在body中，若body未定义的部分则不会有相关的资料，所以SWRL是一种以本体为基础的规则语言，所支持的本体语言为OWL，因为OWL为W3C标准且具有较丰富的关系表示。

2.2.3SWRL的表示方式

SWRL的表示方式有两种，一种是XML，这种方式是以RuleML加上OWLX的方式描述；一种是RDF，这种方式是OWL加上RDF方式来描述。RDF是直接使用语义网的标准语言来描述，因为RDF可以和OWL所建立的本体直接结合，而不用转换，SWRL中规则的变量的定义方式也是以RDF方式来定义的。

文本用的是RDF表示方式，在Protege中所保存的SWRL语法格式也是RDF描述的。

3.2.4Built-Ins

Built-ins中记录了丰富的逻辑比较关系，SWRL的开发者可以直接引用这些逻辑关系，而不需要自己去定义，极大的方便了开发，也使得SWRL的逻辑表达能力极大的增强。

2.2.5火灾损管的推理规则

2.2.5.1示例分析

本节我们根据之前已经建立起来的火灾本体来建立火灾损管推理规则，根据我们自己定义的推理机制得到特定条件下发生火灾时应该采取的消防措施。作为例子我们可以定义几个火灾发生的条件，根据这些条件编写规则得到我们想要的推理结果。在实际应用中规则的定义或许就没有这么简单，要根据实际情况而定，以下是七个例子，接下的所有分析都是基于这里提出的假设：

(1)在机舱中发生一般火灾，火灾的蔓延速度是180m/h，持续时间是1min，这种情况采取的消防措施是火灾报警器报警，舱室值班人员拿手提灭火器灭火。

(2)在机舱中发生大火灾，火灾的蔓延速度是250m/h，持续时间是2min，这种情况采取的消防措施是火灾报警器报警，消防员拿中倍泡沫灭火器，舱室值班人员开启喷雾装置降温。

(3)在机舱中发生特大火灾，火灾的蔓延速度是350m/h，持续时间是3min，这种情况采取的消防措施是火灾报警器报警，封舱，关闭风机，启动水成膜高倍泡沫灭火器

(4)在甲板上发生一般火灾，火灾蔓延速度180m/h，持续时间是1min,这种情况采取的消防措施是火灾报警器报警，船员拿手提式灭火器(水基型灭火器和手提式干粉灭火器)灭火。

(5)在甲板上发生较大火灾，火灾蔓延速度350m/h，持续时间是3min,这种情况采取的消防措施是火灾报警器报警，消防员和消防车到达，水成膜泡沫消防炮启动，泡沫喷洒系统启动。

(6)在仓库发生大火灾，火灾蔓延速度250m/h，持续时间是2min,这种情况采取的消防措施是火灾报警器报警，中倍泡沫灭火报警，降下防火帘同时启动防火帘喷淋降温，关闭应急通风系统，启动中倍泡沫灭火装置。

(7)在仓库发生特大火灾，火灾蔓延速度350m/h，持续时间是3min,这种情况采取的消防措施是火灾报警器报警，封仓门，启动1301装置，1301报警灯柱亮起，启动高倍泡沫灭火装置。

在SWRL的框架中，条件判断的限制式是建立在Atom公理中，而真正的规则是建立在Imp中，在Imp中包含的head和body这两者的限制式来源则是由Atom提供，这些限制式可以被不同的规则重复使用。下面我们将根据以上七个例子来定义我们的推理规则，包括Atom限制式和Imp规则。

2.3JESS推理过程

Jess的推理过程可以分为三步，首先将火灾本体和SWRL推理规则转化为Jess可以使用的事实库和规则库，这个是推理的基础，其次是要建立推理的对象，也就是实例，这个实例是设备类的实例，并且使用主控端发送过来的火灾信息进行初始化，即火灾等级类(FireRating)的实例、火灾发生地点(FireLocation)的实例、火灾蔓延速度(FireSpeed)的实例和火灾持续时间(FireHappenDuration)的实例,初始化的方法是通过类的对象属性进行关联，分别为has-FireRating、has-FireLocation、has-FireSpeed和has-FireHappenDuration，这个在第三步中我们会详细介绍。

2.3.1获取Jess事实库和规则库

SWRL规则可以直接使用本体中的类，实体，属性来编写规则，得到我们自己定义的逻辑推理结果，而且SWRlRules很好的与Protégé结合，从而很方便的在Protégé中编辑SWRL规则，界面化的建立规则提高了我们工程开发的进度，但是SWRL规则只是一个逻辑结构，是个因果关系，并没有推理能力，我们要运行这些规则来对我们的实例进行推理判断还需要外部的推理机，并且这种推理机要能与本体连接，即能够利用到本体中的类，属性，实体以及我们已经定义好的SWRL规则，本文我们将使用Jess推理机作为我们的推理引擎，Jess(javaexpert system shell,Java专家系统外壳)是由美国Sandia国家实验室分布式系统计算机组成员用java编写的基于CLIPS(C Language Integrated Production System,一个用标准C语言编写的向前推理语言^[40])的扩充版，支持正向和逆向推理，核心由事实库、规则库和推理机三大部分组成。因为Jess自身不能解析OWL和SWRL规则，所以需要把OWL本体和SWRL规则转化为Jess能够处理的事实和规则，本文我们用Protégé^[41]的JessTab插件和Jess引擎，JessTab是基于Jess引擎的一个转化工具，可以直接作为Protégé的一个插件嵌入到Protégé中，使用非常的方便，JessTab下有SWRLJessTab，Rules,Classes,Property AssertionAxioms，Individuals，Axiomx,Inferred Individuals,Inferred Axioms几个项，分别可以查看到导入到Jess以后的规则、类、实体，公理以及推理后的推理结果。

2.3.2建立推理实例

根据建立的7条推理规则，下面我们建立9个设备类(Device)实例，作为测试用例，使用火灾信息初始化设备实例，并给出了预想的推理结果，通过实验看看基于SWRL规则的Jess推理机，是否能得到我们想要的推理结果，实例如下表4：

表4：测试实例及其属性和预想推理结果

2.3.3运行推理

建立完9个设备类实例并用火灾信息实例初始化之后，使用SWRLJessTab中的RunJess来运行Jess推理，推理结果在Inferred Individual项中，里面列出的每一行表示一个设备实例是属于哪个一个具体的灭火设备。

本节介绍了火灾损管推理系统的组成部分与构建过程，从火灾本体的建立，到SWRL推理规则的建立，最后基于火灾本体和SWRL推理规则的Jess推理过程，做了一个非常详细的描述，并且通过我们自己建立的火灾实例对火灾推理系统进行了测试，得到了我们想要的推理结果，验证了推理系统的可靠性。本章的推理系统的推理条件是来自主控制端发送过来的火灾信息，通过推理系统的分析和推理得到采取的消防措施，然后把这个消防措施返回给主控制端，提供给控制人员参考做出尽可能安全和决策灭火，以减少必要的人员和经济损失。

三、基于OPC与Socket的数据传输端。

本章节中将要讲的数据传输端有三部分内容：一部分是主控制端与3D仿真端间的数据通信，传输的数据为主控制端发送的火灾灭火指令，指令内容为要执行什么样的操作或启动什么灭火器，3D仿真端接收到指令之后会执行相应的模拟灭火过程；另一部分是主控制端与火灾推理系统的数据通信，传输的数据是主控制端发送过来的火灾信息，主要包括火灾等级、火灾发生地点、火灾持续时间和火灾蔓延速度，这几个信息将由数据传输端接收后作为火灾推理系统的实例初始化条件，然后由推理系统推理得出灭火意见，并将数据传输回到主控制端，在消防措施/反馈结果中显示出来作为系统推荐的灭火意见供控制人员参考；还有一部分是主控制端与OPC服务器的数据通信，OPC服务器中存储着实时数据监控端(InTouch^[46]组态软件，用于监控传感器的状态)发送过来的传感器数据，并且不断的更新，当OPC服务器中的数据发生变化时数据传输端会检测到，并且将这个数据信号传送给主控制端，主控制端接收到某个传感器数据后更改传感器状态。

3.1OPC协议

OPC(OLE for Process Control,用于过程控制的OLE)是一个工业标准，基于微软的OLE(现在的Active X)、COM（部件对象模型）和DCOM（分布式部件对象模型）技术，包括一整套接口、属性和方法的标准集，用于过程控制和制造业自动化系统，为基于Windows的应用程序和现场过程控制应用建立了桥梁，为系统集成商和开发商提供了一种具有高效性、可靠性、开放性、可互操作性的即插即用的设备驱动程序。

OPC服务器通常支持两种类型的访问接口，它们分别为不同的编程语言环境提供访问机制。这两种接口是：自动化接口（Automation interface）；自定义接口（Custom interface）。自动化接口通常是为基于脚本编程语言而定义的标准接口，可以使用VisualBasic、Delphi、C#等编程语言开发OPC服务器的客户应用。而自定义接口是专门为C++等高级编程语言而制定的标准接口。本系统中我们用的是自动化接口OPCAutomation,OPC Server透过一组一组的接口提供服务，不过在实作的架构上，OPC Server共分为三层：分别是OPCServer,OPCGroup,OPCItem，其中每一个OPCItem对应到一个实际的硬件装置上的某一个channel或port；每一个OPCGroup则包含了许多的OPCItem，同时并定义这些OPCItem更新的时间、方式，以及提供读取OPCItem值的接口；而每一个OPCServer则包含若干个OPCGroup，同时提供操作这些OPCGroup的接口。

3.2Socket套接口

Socket通常也称作“套接字”，应用程序通常通过“套接字”向网络发出请求或者应答网络请求。根据连接启动的方式以及本地套接字要连接的目标，套接字之间的连接过程可以分为三个步骤：服务器监听，客户端请求，连接确认。

服务器监听：是服务器端套接字并不定位具体的客户端套接字，而是处于等待连接的状态，实时监控网络状态。

客户端请求：是指由客户端的套接字提出连接请求，要连接的目标是服务器端的套接字。为此，客户端的套接字必须首先描述它要连接的服务器的套接字，指出服务器端套接字的地址和端口号，然后就向服务器端套接字提出连接请求。

连接确认：是指当服务器端套接字监听到或者说接收到客户端套接字的连接请求，它就响应客户端套接字的请求，建立一个新的线程，把服务器端套接字的描述发给客户端，一旦客户端确认了此描述，连接就建立好了。而服务器端套接字继续处于监听状态，继续接收其他客户端套接字的连接请求。

数据传输端是Socket服务器端，3D客户端是Socket客户端，数据传输端处于不断监听是否有3D客户端请求连接，如果有则建立一个连接，3D客户端在于数据传输端建立连接之后就可以相互发送数据了。

3.3数据传输端详细设计

数据传输端的三部分内容主要通过OPC标准协议和Socket网络通信协议来实现。OPC服务器中的数据主要通过OPC协议中的数据变化监听函数实时监听，而其他部分使用Socket协议进行相互间的通信。数据传输端是基于Visual Studio 2010平台下c#语言开发的，使用的OPC服务器接口是Interop.OPCAutomation，需要包含头文件using OPCAutomation。

主要包含OPC服务器的获取和连接、客户端监听(这里的客户端分为3D端监听端口和推理系统端监听端口，分别从2个不同的端口与数据传输端连接)和需要监听的OPC服务器中的信号量（蓝色部分，其他是系统部分的不需要），对应为各个火灾温度传感器，当这些传感器信号量的值发生变化时会被检测到，从而将信息传到主控制端的传感器状态模块。下面分别从OPC服务器建立传感器信号量、与OPC服务器建立连接、Socket服务器端和Socket客户端。这里数据传输端作为Socket服务器端不断监听3D仿真端和推理系统的建立请求和发送数据。

3.3.1在KEPServerEX中建立信号量

本系统中选择KEPServerEX V4.0作为OPC服务器，KepserverEx软件为全球工业界领先的超级OPC服务器,它能够提供非常卓越的工业互连通讯能力，并且嵌入了工业市场上广泛范围的超过100多种通讯协议支持数百种以上设备型号的可下载驱动程序，所以KEPServerEx足够满足我们系统的需求。确定好了OPC服务器，我们需要在KEPServerEx中建立我们的信号变量，先后建立NewChannel(通道)，NewDevice(设备)和Tag(标志)，具体见表5，总共我们建立了13个传感器信号量，分别代表机舱、宿舍、餐厅、甲板、弹药库分别为2个和仓库3个：

表5：KEPServerEX中的信号量表

TagName	DataType	Description
			HangerOne	Short	一号机舱温度传感器
HangerTwo	Short	二号机舱温度传感器
			DormitoryOne	Short	一号宿舍温度传感器
DormitoryTwo	Short	二号宿舍温度传感器
			RestaurantOne	Short	一号餐厅温度传感器
RestaurantTwo	Short	二号餐厅温度传感器
			DeckOne	Float	甲板温度传感器一
DeckTwo	Float	甲板温度传感器二
			AmmunitionDepotOne	Float	一号弹药库温度传感器
AmmunitionDepotTwo	Float	二号弹药库温度传感器
			WareHouseOne	Float	一号仓库温度传感器
WareHouseTwo	Float	二号仓库温度传感器
			WareHouseThree	Float	三号仓库温度传感器

组态软件监听到传感器中的不正常信息之后将对应在KEPServerEx中的信号量的值改为1(初始化为0，表示正常)，当这个传感器信号量有变化时，在数据传输端中的数据变化函数就会检测到，然后将变化的传感器数据以参数的形式传送过来，而后我们就可以在主控制端的传感器状态模块将对应的传感器颜色标为红色，并进行其他操作。

3.3.2连接KEPServerEX服务器

(1)获取OPC服务器：本系统中的OPC服务器KEPServerEX和数据传输端是运行在同一台机器中的，所以我们只需获取本地计算机中的OPC服务器即可，如果OPC服务器不在本地计算机中，则需要获取其他计算机的IP地址和主机名称，这样才能得到OPC服务器。本地计算机我们可以用局域网IP，或者直接用127.0.0.1来得到主机名称，根据主机名称可以获取到OPCServer。

(2)连接OPC服务器：本系统连接的是本地的OPC服务器，如果是远程的OPC服务器，则需要配置本地和远程主机的DCOM以及系统安全策略，连接OPC服务器需要OPC服务器所在主机的IP地址和OPC服务器名称。

(3)创建Group及其属性：每一个OPCServer实例都有一个OPCGroups，里面可以包含多个OPCGroup，而每一个OPCGroup实例也有一个OPCItems，里面又可以包含多个OPCItem，此处我们就是要在OPCGroups中增加一个OPCGroup，并设置这个OPCGroup的组属性以及组内Item数据变化时执行的事件。

(4)列出服务器所有节点。

(5)将相应Item加入组：经上面第四步列出所有服务器中的信号量后，选择我们需要的信号量然后把他们全部加入到OPCItems中，即每一个信号量作为一个OPCItem。

KepItems是OPCItems的对象实例，OPCItems使用AddItem函数增加OPCItem，每一个OPCItem都有一个ItemID和客户端句柄ClientHandle,我们假设从0开始给加入的OPCItem作为客户端句柄，ItemID用信号量的名称来表示。同时加入到OPCItems中的Item都有一个服务器句柄ServerHandle，这个是系统自动分配的，因为在DataChange事件中要用到客户端句柄和服务器端句柄与信号量之间的关系，所以在此我们需要另外服务器句柄和ItemID的映射关系，用数据机构Dictionary来存储，Dictionary<ServerHandle,ItemID>类型的itemIDToServer

Handle和Dictionary<ServerHandle,ItemID>类型的serverHandleToItemID,另外还需要一个存储服务器端句柄的数组，索引为客户端句柄clientToServer。

（6）对于3D仿真端执行了灭火指令之后会返回一个信息，火灾是否被灭了，如果被灭了，则返回传感器名称给数据传输端，数据传输端将把OPC服务器中对应传感器的值写为0，表示这个传感器所在舱室火灾被灭，传感器的值还原。

3.3.3Socket服务器端

数据传输端作为Socket服务器端，不停的在检测是否有客户端（3D仿真端和推理系统端发出请求连接，对于每一个请求连接的客户端，Socket服务器端都会接受并新建一个线程，连接建立之后由这个线程处理与这个客户端的通信。

首先我们设定好与3D仿真端一致的监听端口和消息发送端口，比如都为3001，IPAddress.Any为任何地址,port为我们预先定好的3001端口，定义一个IPEndPoint的对象实例ipEndPoint，定义一个服务器端Socket，地址簇为AddressFamily.InterNetwork因特网地址,Socket类型为SocketType.Stream字节流类型,协议类型为ProtocolType.Tcp类型，以这个服务器端Socket绑定ipEndPoint实例，并进行不断监听，这样就不断监听端口3001，如果有在这个端口有请求连接，则接受返回一个Socket给事先定义的客户端Socket对象clientSocket，并且将这个客户端Socket对象加入Socket数组，之后所有的客户端Socket都保存在这里，然后新建一个线程来处理数据传输端和这个客户端之间的通信，线程开始为doWork函数。这个doWork函数主要是通过Socket函数Receive接收客户端发过来的信息，如果是3D仿真端则里面包含有消防结果，如：采取了相应的消防措施之后，火灾有没有灭掉，把效果返回给数据传输端，经分析将信息发给主控制端，并显示在消防措施/反馈结果中，从而控制者能够读取到这个结果。如果是推理系统端，则信息为推理结果，应该采取的灭火措施。

3.3.4Socket客户端

主控制端和3D仿真端作为Socket客户端，在与Socket服务器端进行通信之前需要请求连接，得到服务器端接受后与服务器端绑定，然后才能开始通信，相互发送消息。

通过ip和port建立一个IPEndPoint，再建立一个socket对象，使用Socket的连接请求函数Connect请求建立连接。如果得到接受则可以进行发送消息和接收消息。

本节主要是介绍了数据传输端的完成的基本功能及其主要组成部分，数据传输端是一个中间层，是各个部分连接的桥梁，他们之间的数据传递就是通过数据传输端来完成的，在数据传输端接收数据之后还需要进行数据的转化，才能发送给其他的部分，数据传输端包含三个部分：一端和3D仿真端进行连接通信，主要是通过Socket发送与监听完成消防措施的执行和反馈，一端与OPC服务器KEPServerEx端进行数据交互，主要通过OPCAutomation接口与服务器端建立数据实时监控，建立OPC服务器对象OPCServer，组OPCGroup和项OPCItem，KEPServerEx中的信号量加入到OPCItem中，还有一端要与火灾推理系统连接通信，主控端发送火灾信息到数据传输端，数据传输端接收后转给火灾推理系统，并将推理结果返回给主控制端。

当然，本发明还可有其他多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。

Claims (6)

1.舰船火灾损管推理仿真控制系统，包括主控制部、若干舱室传感器、火灾及舱室信息显示模块、数据传输模块；所述主控制部的输入端连接有若干舱室传感器，若干舱室传感器分别安装在机舱、货舱、甲板、餐厅和卧室内，其特征在于：还包括传感器状态检测模块、传感器状态提示模块、手动选择模块、3D模型标示模块、火灾损管推理模块和3D仿真模拟灭火模块，主控制部的输入端连接有传感器状态检测模块，传感器状态检测模块对所有舱室传感器进行实时检测，判断舱室传感器是否正常工作；所述传感器状态提示模块、火灾及舱室信息显示模块、3D模型标示模块分别连接到主控制部的输出端，传感器状态检测模块检测到舱室传感器处于不能正常工作的状态时，将舱室传感器的非正常工作信息发送给主控制部，主控制部控制传感器状态提示模块进行提示，主控制部还在3D模型标示模块中标示出不能正常工作的舱室传感器的位置，舱室传感器感应到火灾信息后，传送给主控制部，主控制部在火灾及舱室信息显示模块中显示出火灾信息，在3D模型标示模块中标示出火灾位置和火灾等级；所述主控制部中设有手动选择模块，手动选择模块可模拟舱室传感器的状态；主控制部与火灾损管推理模块之间通过数据传输模块连接，数据传输模块从主控制部接收到火灾信息后，由火灾损管推理模块经过分析后用接收到的火灾信息初始化一个火灾本体实例，用所述火灾本体实例通过基于火灾本体建立起来的推理系统进行推理，得出相对应于所述火灾本体实例的灭火方法，再通过数据传输模块将得出的火灾本体实例的灭火方法返回给主控制部，所述主控制部将接收到的火灾本体实例的灭火方法传输给3D仿真模拟灭火模块，3D仿真模拟灭火模块在界面上显示灭火方法和灭火策略。

2.如权利要求1所述的舰船火灾损管推理仿真控制系统，其特征在于：所述火灾及舱室信息显示模块中显示出的火灾信息包括火灾的大小等级、火灾的发生时间、火灾的持续时间，火灾的蔓延速度、舱室名称、舱室具体位置、舱室内人员数量和舱室内设备情况。

3.如权利要求1所述的舰船火灾损管推理仿真控制系统，其特征在于：所述火灾本体实例是根据火灾的性质和舱室的性质而建立的。

4.如权利要求3所述的舰船火灾损管推理仿真控制系统，其特征在于：所述通过基于火灾本体建立起来的推理系统的推理规则是根据火灾的大小等级、火灾的发生时间、火灾的持续时间，火灾的蔓延速度、舱室名称、舱室具体位置、舱室内人员数量和舱室内设备情况而建立的。

5.如权利要求4所述的舰船火灾损管推理仿真控制系统，其特征在于：所述火灾损管推理模块中火灾本体是使用OWL本体语言在Protege3.4中建立OWL火灾本体，同时使用SWRL规则建立推理规则，然后将OWL火灾本体和SWRL规则通过SWRLJessTab转化为Jess推理机的事实库和规则库，最后进行推理。

6.如权利要求1至5中任一项所述的舰船火灾损管推理仿真控制系统，其特征在于：所述主控制部与数据传输模块之间采用Socket通信方式，数据传输模块作为服务器端进行监听，主控制部作为客户端发送消息给数据传输模块。

Images