基于知识的试油方案协同设计方法应用研究

尚福华，戴语涵，解红涛，杜睿山

(东北石油大学 计算机与信息技术学院，黑龙江 大庆 163318)

0 引 言

试油方案设计是由地质、工程、施工三个大队协同合作将试油阶段所取得的海量丰富的数据信息整合到一起的研究报告。试油试采公司为此建立了各种试油信息管理系统[1-2]，其中有的系统利用工作流技术，提高了试油方案设计的效率，降低了运行成本，但发现过去的信息通常都是基于关系型数据库实现的，在实际应用中，每个领域对同样事务的认知水平和信息表示方法存在不同：知识水平不同，导致对同一事务的认知程度存在差异；实际需要不同，导致对事务的信息表示方法和文件存储格式不同，导致设计人员在设计方案时出现差异，难以达到知识共享。正是因为以上问题的存在，工作流在实际应用时优势不能得到很好的发挥。

为了解决这一问题，引进基于知识的方法来表示数据。知识模型能够将大量的、分散的、异构的试油试采信息实现标准化表示和有效集成。目前知识表示方法有很多，例如ontology、基于XML的表示法、知识产生式、知识图谱等[3-5]。其中本体在很多领域的应用研究已经较为成熟，国内比较著名的通用本体库系统是How Net[6]、浙江大学人工智能研究所基于本体论的产品信息集成研究等[7]。笔者曾在《石油学报》上发表了《基于知识库的解释模型智能优选测井数据处理方法》，对本体在油田领域的应用进行了大量的研究[8]，积累了大量的经验，研究成果较为成功。所以该文利用ontology，能够提高试油领域知识表示的准确性[9-11]，很好贴合本系统的实际需求。

该文根据试油方案管理系统的实际应用需要，利用领域本体作为知识库改进协同工作流模型[12-14]，开发了基于知识的试油方案协同设计管理系统，该系统的开发能够对试油方案领域知识进行高效的组织和管理，可以避免跨部门之间对同一事物的分类及特性认知的差异以及不同设计人员对同一方案描述的差异等问题。其方案设计的逻辑结构更加接近于人的思考，使试油方案协同设计系统具有了一定的智能性，并在一定程度上减少了由于工作人员经验不足所造成的设计方案结果不准确、差异大等问题，其次能够有效判断试油方案设计流程，将文档、信息或任务按照预定的规则传递，确定协同过程和状态，保证了协同的有效性，实现试油三项设计的整体目标。

1 试油领域本体构建

1.1 试油领域本体构建方法

试油井数据中蕴含着大量的试油信息知识，是构成试油领域本体的重要数据来源。该文主要利用试油井数据构建试油领域本体。根据笔者之前的研究[15]，在骨架法以及“七步法”的基础上，结合试油方案协同设计业务流程提出一种本体构建方法，构建了试油方案设计领域本体模型，具体过程如图1所示。

图1 本体构建方法

1.2 试油领域本体概念层级结构及相互关系

试油领域本体模型以方案为中心，方案归属于部门，方案利用井的信息，方案包含配置信息。

试油方案协同设计管理系统必然有的服务就是部门管理。部门可以分为以下几种：地质、工程、施工大队。部门下又分为不同用户，例如地质大队部门下包含管理员、设计人员、审核人员等。

方案设计管理系统还应该有对方案的管理，也就是方案配置信息，包括该方案的油气类型、所属部门，设计人员、审核状态等基础信息。最后方案设计管理系统还应该有对井的信息管理，包含该口井的测井信息、录井信息、邻井信息，层位信息等。

方案设计管理以方案为中心，概念之间满足的关系如下：一个方案利用一口井，一个方案在某一时间段内只归属于一个部门(即地质设计未完成时，方案处于地质部门阶段，当地质设计完成时，方案流转到工程部门，此时，方案归属于工程部门)，每个部门有不用权限用户，如审核人员、设计人员，每个用户可以设计多个方案。

1.3 本体建构和表示

通过上述对试油领域本体类以及相互关系的分析，可以建立试油领域本体，部分本体展示如图2所示。

根据本体定义，构建本体概念集、属性集后，需要利用向本体OWL映射，其中类映射主要采用“”标签表示，例如：

然而只有类是不能够让计算机很好地理解本体的语义信息的，还应该添加类间的关系、数据属性和对象属性来详细描述类的特征。下面以井的信息为例，给出属性描述，例如井包含测井信息，里面属性分为井段、厚度、RXO、RT、ILD、AC、CNL、DEN、SP、GR、CAL、PEF、U、TH、K40、Vsh、PORE、SWE、K、解释结果。

其次是关系映射，OWL已定义了Part-of、Kind-of、Attribute-of和Instance-of四种基本语义关系。其中Part-of表达概念之间整体和局部的关系；Kind-of表达概念之间的继承关系；Attribute-of表达一个概念是另一概念的属性；Instance-of表达概念和概念的实例关系。概念间存在的关系除上述四种基本关系外，还存在等同关系、相邻关系。

标签描述，如：

……

最后根据映射规则，给出相关概念向OWL本体转换的算法，从而实现概念向本体OWL自动转化。

图2 部分本体展示

1.4 试油领域本体存储

根据上节所建立的本体关系，该文设计了OWL本体的映射规则，根据该规则实现了本体到关系数据库表的转换，使本体表示不仅停留在概念层面，而且更符合应用开发的需要，为后续工作流的使用打下了基础。本体映射规则如下：

(1)将本体中的类映射为关系数据库中的表；

(2)将本体中的相关属性转化为Oracle数据的某表中一列，该列的数据类型反映了本体此属性的值域，列明代表了属性的定义域；

(3)将本体中的函数属性映射为对应的实体表中的主键；

(4)OWL中如果类C和类D属于继承关系，那么C继承D的所有数据类型属性，并且拥有D所对应的表的所有列字段；

(5)若OWL中属性P和Q是等价属性，P的定义域是类C，Q的定义域是类D，如果属性P所对应的列是类C所对应的表的主键，且属性Q所对应的列不是类D所对应的表的主键，则属性Q是类D所对应的表的外键。如果属性Q所对应的列是类D所对应的表的主键，且属性P所对应的列不是类C所对应的表的主键，则属性P是类C所对应的表的外键。

根据上述映射规则，该文设计了一套算法将本体描述语言转换为SQL语言，方便开发人员使用。

具体流程描述：首先读入文件之后解析OWL文档，得到本体的结构，并将这些内容转换为JSON数据来表示类之间关系。然后将类关系Class JSON转换为创建表的中间文件Table JSON，在这个结构中存储了创建数据库表必须要的全部属性。然后读取该结构，拼接创建表的语句。算法的输入是OWL本体文件，算法的输出是SQL建表语言，实现了本体到关系数据库模式的映射。

2 基于知识的试油方案协同设计系统应用

基于知识的试油方案协同设计系统的开发是利用上述本体的逻辑层结构，将方案中的每一部分知识作为一个基础本体放入到公共本体中，设计人员进入系统做方案设计时根据自己的需求选择所需的基础本体，作为方案的基础框架，这样设计出来的方案是统一标准的，然后将其设计好的方案内容转化存储到关系数据库。试油领域本体的逻辑层结构更加贴近于人的思考，便于设计人员在试油方案设计时帮助用户决策。

2.1 系统框架设计

系统底层框架是基于B/S结构实现的，采用Spring MVC设计模式和技术开发，在此基础上增加了本体和工作流系统，整体框架如图3所示。

系统主要分为方案设计系统和工作流系统两个部分，同时与系统数据库进行数据交换。方案设计过程是指根据设计人员需求信息和本体知识库映射规则完成方案模板定制，最终在模板中完成设计。方案流转过程则是完成方案后，需要按照工作流传递规则进行流转，进行内部审核和外部审批。

2.2 基于本体的试油方案设计模型框架

在试油方案协同设计系统中，涉及的本体包括部门、设计类别、方案等，其中方案模板是需要共享的核心本体，试油方案协同设计系统中的大部分业务都是基于方案模板的。方案模板就是一个具有层次的树状结构，其中一个类就是一个叶节点，不同类型的井具有不同的属性，例如直井、水平井、油井、气井等都有对应的属性来对其进行描述。某个类下不同的属性取值便组成了方案的实例。每个类对应着一个基础本体，一个实例由多个基础本体组成。

图3 系统框架

基础本体想要共享和交换信息需要通过公共本体的映射。在做井的方案设计中，设计人员不可能选择相似的知识，而必须是完全符合属性要求的知识。虽然井的各类属性不同，并且一个类型井的信息是有限的，该类型井的私有本体在公共本体空间都能找到对应的公共本体，因此每口类型井的基础本体空间是公共本体空间的子集。基于公共本体的系统集成框架如图4所示。

整个框架分为三个层次：业务系统层是做方案设计的系统层；交换接口层是设计人员进行设计时用于本体信息交换的接口，私有基础本体到公共本体的转换由交换接口完成。公共本体库会提供一个开放的接口，各设计人员可以下载公共本体。两个井的信息需要进行共享时，井A的信息交给交换接口，根据私有和

公共本体库将交互信息转换为公共本体表示，交给井B的交换接口。

图4 基于公共本体的系统集成框架

设计人员在做设计时，先选择该口井配置信息，然后在公共本体库中选择基础本体，在此基础上进行设计，做好的模板如图5所示。

图5 本体模板

2.3 协同工作流模型设计

协同工作流模型的设计是基于本体库转换成的数据库实现的，但逻辑层结构还是本体模型的思想，首先分析三项设计内部审核和外部流转的业务流程，设计工作流模型，由流转级别表、流转链路表、用户表、部门表、工作流日记表等信息组成，如图6所示。根据该模型设计并实现三大部门的顺序办公流程，完成了设计方案传递下一级、回转上一级、删除、审批等功能，达到知识共享和协同工作的效果。

图6 工作流模型

该系统的工作流流程为：试油地质大队申请设计试油方案，设计完成后可选择已有审核流程，或者新建审核流程，如果在某一审核级别时有多人可以进行审核，选择一个空闲的审核人；试油方案成功提交后，被选择的审核人确认后就可以对提交的申请方案进行审批，并对其给出相应的意见。如果审核人同意则可以继续执行下一级的审核或设计工作流程，如果审核人不同意则可以将返回申请提交给上一级。在审核流程与设计流程中必须遵守以下两点：

(1)根据试油方案状态选择继续审核流程还是设计流程；

(2)根据特定的查找算法能快速且准确定位下一级别。

由于该工作流既包含设计过程也包含审核过程，因此将试油方案信息表的状态值分为待设计、待审核、完成三部分，如表1所示。根据试油方案状态与对应的级别层级(SHJB、SJJB)，找到下一级别。

表1 试油方案状态

为了实现设计和审核流程的自定义与灵活性，系统根据设计和审核的先后顺序规定设计流转级别表中上下级关系。试油地质大队进行设计前，选择适合本次设计的部分上下级关系和每个过程需要的处理人数。系统根据地质大队的选择在流转链路表中添加设计和审核流程，形成双向链表，并利用工作流日志表记录试油方案的(SHR、SJR)字段来获取下一处理人。当下一处理人有多个用户满足条件时，根据用户的任务量自动分配到任务少的用户进行处理，减少等待时间，保证各用户工作量基本一致，提高了工作效率。

2.4 系统实现

该系统以基于试油领域本体的试油方案协同设计工作流模型为逻辑底层，结合试油方案设计的实际需求，实现了以下5大功能。

(1)试油三项设计的模板管理，其中对于试油方案的模板可以进行增删改查，重用；

(2)试油三项设计方案在线设计、基础数据智能导入；

(3)地质、工程、施工方案、维护、设计查询下载管理；

(4)三项设计部门内部审核管理，外部流转、协同管理和实时监控；

(5)三项设计的用户和权限的统一管理。

3 结束语

提出了试油方案协同设计方法，介绍了试油领域本体构建、协同工作流构建等技术和方法，有效地解决了实际应用中方案标准统一化以及知识重用性的问题。对本体在试油领域的应用进行了初步的探索，将工作流技术与本体结合起来，设计开发的基于知识的试油方案协同设计管理系统运行良好，提高了方案设计的准确性和设计效率，所建立的本体库为后续试油领域在智能控制和可视自动化技术方面的深入研究及其应用打下了基础。该文对试油领域本体的研究和应用，希望对试油相关领域的国内同行业者有所帮助和借鉴。