CN106776854B - 一种适应地铁综合监控系统的数据黏合结构及处理方法 - Google Patents

Abstract

本发明公开了一种适应地铁综合监控系统的数据黏合结构，关系实时数据库采用面向对象技术构造，每个物理设备在关系实时数据库中均表示为一个数据对象，具有唯一标识ID，数据对象的多维度刻画则用该对象的一系列属性来表示，每一个属性亦具有唯一标识ID；黏合器根据应用需求设计，屏蔽现有结构组织，消除车站、专业、数据类型数据之间的分割界限，从应用需求出发，把应用感兴趣的数据通过数据关联的方式重新编排为一个有序结构，并配置新结构的辅助信息，最终呈现给高级应用最为精准的数据组织形态；同时，对每个黏合器预置计算辅助，将可预知的有规律可循的逻辑处理提前为应用准备好，最大化地为上层高级应用提供数据、逻辑支撑的便利。

Description

一种适应地铁综合监控系统的数据黏合结构及处理方法

技术领域

本发明涉及面向地铁/轻轨/单轨/有轨电车等轨道交通领域实时综合监视控制系统的数据黏合结构及处理方法。

背景技术

地铁/轻轨/单轨/有轨电车综合监控系统(ISCS Integrated SupervisoryControl System)采用一体化软硬件平台和专用通信网络采集诸如供电系统、环境与设备监控系统、火灾报警系统、信号系统、广播系统、乘客信息系统等数个专业的实时数据和环境参数，并远程控制各专业系统的运行；这其中，不可避免地涉及到对成千上万个运行设备及动辄几十万数据测点的编制配置、结构组织及逻辑应用。同时，随着地铁运营管控智能化要求的提高和行业大数据分析挖掘技术的不断渗透应用，运营对工程测点容量和数据深层分析的需求继续呈现不断快速上涨的趋势。由此，高效易用的数据组织架构对工程实施工作量、系统实际运行效率、系统应用扩展性都具有至关重要的影响。

现有技术的缺点：目前现有综合监控系统数据库一般按“地点+专业+数据类型”为单元维度进行数据组织，保持与地铁线路物理设备对象分布的映射一致性，配置易于理解；但随着地铁运营对设备和数据管理精细化、智能化水平的需求与日俱增，面对大数据关联抽取分析日益兴起的趋势，现有结构无法体现多类设备及测点之间的关联性、互动性，而这种关联性在综合监控系统中又是必然广泛存在的，从而面对越来越多的新的高级应用开发扩展时，往往在数据支撑层面成为软肋。每个模块的开发人员在思考本身应用特有逻辑的同时，不得不抽出精力来考虑在现有结构维持不变的情况下如何开展数据的二次组织以满足自身的程序需求；同时，许多常规可重复利用的类似逻辑代码得不到共享，增加了开发难度和周期，额外的代码也降低了资源使用的效率。

发明内容

针对现有技术中存在的不足，本发明通过一种独特的构架于现有数据库结构之上的黏合结构设计，通过组态方式将关联测点及关系按应用开发的特殊需求精准组织起来，屏蔽既有车站、专业、数据类型的分割固化限制，将高级应用开发在数据支撑层面变得更加清晰、简单、易用；同时可内置强大的编程支撑，将可预知的有规律可循的常用逻辑处理在黏合器内部实现完毕；从而可在维持现有数据结构不变的基础上，直接替代高级应用开发或为应用开发提供灵活的贴切的数据和逻辑准备，大大提升了开发效率，并对系统成型后的应用扩展提供了较高的设计弹性和便捷化解决方案。

为了实现上述发明目的，本发明采用的技术方案为：一种适应地铁综合监控系统的数据黏合结构，其特征在于：它包括高级应用、关系实时数据库、黏合器，所述关系实时数据库采用面向对象技术构造，每个物理设备在关系实时数据库中均表示为一个数据对象，具有唯一标识ID，数据对象的多维度刻画则用该对象的一系列属性来表示，每一个属性亦具有唯一标识ID；所述黏合器根据应用需求设计，它屏蔽现有结构组织，消除车站、专业、数据类型数据之间的分割界限，一切从应用需求出发，只把应用感兴趣的数据通过数据关联的方式重新编排为一个有序结构，并配置新结构的辅助信息，最终呈现给高级应用最为精准的数据组织形态；同时，对每个黏合器预置计算辅助，将可预知的有规律可循的逻辑处理提前为应用准备好，最大化地为上层高级应用提供数据、逻辑支撑的便利；所述高级应用既包含地铁综合监控系统基础平台的扩展高级应用，同时也包括地铁运维不断积累和发掘的各个专业、各种类型的新开发需求。

所述黏合器由数据单元、结构单元、计算单元和计算模型组成；

所述数据单元是黏合器运转的触发单元，也是与关系实时数据库的交互单元；数据单元依据结构单元的数据测点储备，向关系实时数据库注册数据变化的通知请求，并提供回调接口，当所关注的数据发生变化并被监听到时，回调接口将被自动调用，并将数据推送给计算单元，由其完成后续的逻辑计算；数据单元内的每一帧数据均为一个固定格式组合：变化数据点ID+变化属性ID+变化值；数据单元为计算单元提供数据准备，计算单元为逻辑的最终执行单元；

所述结构单元为黏合器的数据重构核心，将高级应用感兴趣的测点以一定的数据结构组织起来，形成新的更便于处理的数据模型；完整的结构单元由两类对象构成：黏合器对象(BondingAgent)和计算对象(CalcArgument)，每个黏合器对象(BondingAgent)至少均包含两个重要数据项：UniqueID，黏合器的全局唯一标识，也是提供构建、查找、遍历、命令等操作对象的标识参数；ParticipantList，黏合器管辖的孩子对象列表，列表内为孩子节点的UniqueID有序序列；完成黏合器对象的组织后，在黏合器对象下配置参与内部计算的辅助计算对象(CalcArgument)子节点；

所述计算单元承载黏合器所有的实时计算任务，它接受数据单元的所有数据变化，查找并调用所有与变化数据相关的已配置的计算模型，将计算结果反写至实时数据库中，从而完成一个完整的黏合器运转流程；计算单元包含一张一对多的映射表，“键”为结构单元中InputObjectList涉及到的对象ID集合，“值”为InputAttributeList中属性ID+计算对象CalcArgumentID(可能有多个)的组合；当接收到数据变化时，查找映射表，获取该对象和属性所参与到的所有计算对象CalcArgumentID，然后获得其对应的ModelLink所指向的计算模型，并逐个检验有效后再执行计算过程；计算完成后将结果写入OutputObjectList和OutputAttributeList对应的对象属性值中，完成关系实时数据库的更新；

所述计算模型为黏合器中预置的且可随时在线编程扩充的模块集合；黏合器的定制者可在某个模型中使用高级语言编写计算逻辑，然后编译生成模块库，供计算单元根据需要随时调用；计算模型能够被重复利用，即只要计算逻辑相同，无论多少个黏合器BondingAgent均可采用同一个计算模型，仅需一次编码。

本发明还公开了一种适应地铁综合监控系统的数据黏合处理方法，其特征在于：

第一步：基于既有的数据库结构，按高级应用的要求规划数据的二次组织模式，构造若干新的黏合器(BondingAgent)；

第二步：对每一黏合器(BondingAgent)，配置其ParticipantList数据项，将现有数据测点纳入该对象管辖范围；

第三步：规划计算逻辑及输入输出参数，配置新的计算模型Model，编写逻辑代码，利用计算模型提供的编译功能实现完整代码的生成、编译，生成模块库；若使用既有计算模型，则跳过该步；

第四步：在有计算需求的黏合器(BondingAgent)下配置若干计算对象CalcArgument，有几种计算逻辑即配置几个对象；对每个CalcArgument，配置InputObjectList、InputAttributeList、OutputObjectList、OutputAttributeList，配置ModelLink，将第三步中的计算模型链接至此完成二者的关联；

第五步：启动整个数据黏合结构，实现流程运转，在运行过程中实时控制计算功能的启用或失效。

有益效果：本发明通过一种独特的构架于现有数据库结构之上的黏合结构设计，运用组态方式将关联测点及关系按应用开发的特殊需求精准组织起来，屏蔽车站、专业、数据类型的分割固化限制，将高级应用开发在数据支撑层面变得更加清晰、简单、易用；同时可内置强大的编程支撑，将可预知的有规律可循的逻辑处理在黏合器内部快速实现；从而可在维持现有数据结构不变的基础上，直接替代高级应用开发或为应用开发提供了灵活的贴切的数据和逻辑准备，降低了现有常规二次开发的难度和复杂度，大大提升了开发效率，并对系统成型后的应用扩展提供了较高的设计弹性和便捷化解决方案。

附图说明

图1为本发明实施例的黏合器的上下位关系及内部结构示意图。

图2为本发明实施例的黏合器配置叠加后的结构网络示意图。

图3为本发明实施例的计算模型构成示例图。

具体实施方式

以下内容将描述黏合器的系统构成和处理流程，并对流程工作原理做详细阐述，最后给出应用实例。

本发明面向地铁/轻轨/单轨/有轨电车等轨道交通领域实时综合监视控制系统，针对系统中出现的集成多专业的大量数据组织管理和建模的需求，为被监控设备及测点提供一种极其灵活的自由组织的数据结构，即采用黏合器技术在现有数据库结构上重构出新的且能贴切符合高级应用的数据组织系统，从而在保持原有数据组织稳定的前提下，轻松实现各类新应用开发的数据准备，提升主控系统的自动化、多维度管控智能化水平。

1.系统框架，如图1所示，本实施例的黏合器的上下位关系及内部结构示意图。

关系/实时数据库

商用关系数据库(或文件系统)及由此衍生而来的实时内存数据库是监控系统的数据核心，为既有结构配置，采用面向对象技术构造，每个物理设备在数据库中均表示为一个数据对象(测点)，具有唯一标识ID，对象的多维度刻画则用该对象的一系列属性来表示，每一个属性亦具有唯一标识ID。如“温湿度传感器H-8”在数据库中表示为一个对象，ID标识为“32905856”，并具有名称(ID：3)、位置(ID：5)、温度测量值(ID：12)、湿度测量值(ID：57)、手动置位值(ID：26)、故障状态(ID：20)、报警状态(ID：68)、责任区(ID：18)等等几十个属性来详细描述它。这样使用两个ID即可准确定位所描述数据点及维度的详细信息。

面向对象结构提供了地铁全线所有监控范围内的数据测点，通常按“地点+专业+数据类型”为单元进行数据组织。这种存储结构的优点是与现实物理线路对象分布完全映射，方便工程配置和管理；与此同时，这种结构也天生弱化甚至忽视众多专业、设备以及数据之间的关联性，不利于深层数据开发工作的开展。

黏合器

黏合器为根据应用需求设计的新型结构，它屏蔽现有结构组织，消除车站、专业、数据类型等数据之间的分割界限，一切从应用需求出发，只把应用感兴趣的数据通过数据关联的方式重新编排为一个有序结构，并配置新结构的辅助信息，最终呈现给高级应用最为精准的数据组织形态；同时，对每个黏合器预置计算辅助(可选、可扩充)，将可预知的有规律可循的逻辑处理提前为应用准备好，最大化地为上层高级应用提供数据、逻辑支撑的便利。

高级应用

高级应用既包含地铁综合监控系统基础平台的扩展高级应用，同时也包括地铁运维不断积累和发掘的各个专业、各种类型的新开发需求，由黏合结构为之提供一揽子的数据重构方案。

2.黏合器原理

如图1所示，黏合器共包含4种关键工作部件：

2.1数据单元

数据单元是黏合器运转的触发单元，也是与实时数据库的交互单元。数据单元的主要工作是依据结构单元的数据测点储备，向实时数据库注册(订阅)数据变化的通知请求，并提供回调接口，当所关注的数据发生变化并被监听到时，回调接口将被自动调用，并将数据推送给计算单元，由其完成后续的逻辑计算。

数据变化存在以下几种情形：

1)测点状态的改变：如某个表示断路器开关状态的测点由“合闸”变为“分闸”；

2)上层应用命令下发：如某个通风模式被时间表启动，代表关联设备需要执行该模式；

3)实时配置管理：在线修改结构单元的数据，如添加或删除黏合器所管理的测点。

数据单元内的每一帧数据均为一个固定格式组合：变化数据点ID+变化属性ID+变化值。

数据单元为计算单元提供数据准备，计算单元为逻辑的最终执行单元，将二者功能切分开来以确保不会因计算单元的复杂执行过程和资源消耗导致数据单元与实时库的交互受阻(如监听超时或错过变化推送)。

2.2结构单元

结构单元为黏合器的数据重构核心，将应用感兴趣的测点以一定的数据结构组织起来，形成新的更便于处理的数据模型。

完整的结构单元由两类对象构成：黏合器对象(BondingAgent)和计算对象(CalcArgument)。

每个BondingAgent均包含2个重要数据项，其他数据项可根据需要添加：

1)UniqueID

黏合器的全局唯一标识，也是提供构建、查找、遍历、命令等操作对象的标识参数。

2)ParticipantList

本黏合器管辖的孩子对象列表，列表内为孩子节点的UniqueID有序序列，形如(A₁,b₂,C₁,D₃,e₂….)。

孩子对象可以是：

a)嵌套黏合器：即下一级已经组织好的黏合器整体作为本对象的孩子；

b)独立测点：现有数据库中已配置好的实际工程数据点。由于本实施例中工程数据配置采用面向对象技术构建，每个设备、每个测量参数均表示为一个对象，具备唯一的UniqueID；当采用其他方式构建基础配置数据库时，方法类似，只要将孩子数据测点的唯一索引标识填入黏合器的ParticipantList即可。

图2为一个案例示意，展示了多个应用配置叠加后的黏合器及测点的组织结构以及与原有数据库结构的对应关系，新建黏合器以大写字母表示(形如A₁,C₁…)，既有数据测点以小写字母表示(形如b₁,h₅…)，可以看出一个黏合器可以包含多个黏合器及测点，而一个测点也可以根据需要隶属于多个黏合器，从而形成新的完全根据应用构造的结构网络。

图2为本实施例的黏合器配置叠加后的结构网络示意图。

完成黏合器对象的组织后，在黏合器对象下配置参与内部计算的辅助计算对象(CalcArgument)子节点：

每个CalcArgument计算对象包含如下重要配置项：

1)InputObjectList：参与计算单元执行所需的输入数据点有序序列，个数不受限制，这些对象与数据单元注册和推送过来的发生变化的数据点对应，亦即数据单元推送的变化信息必然能在InputObjectList中找到对应项，由此才能完成后续一系列调用过程；当无需输入参数时该配置可以为空；

2)InputAttributeList：InputObjectList数据点各自对应的属性有序序列，个数与InputObjectList一致，由于同一个对象可以有多个动态属性变化，所以需明确究竟对象的哪个属性参与计算；当无需输入参数时该配置可以为空；

3)OutputObjectList：参与计算单元执行所需的输出数据点有序序列，计算单元触发执行后的结果保存处，个数不受限制。这些对象在实时库中的更新数值是整个计算流程的最终结果体现，上层高级应用由此判断其逻辑需求是否被正确执行；当无需输出参数时该配置可以为空；

4)OutputAttributeList：OutputObjectList数据点各自对应的属性有序序列，个数与OutputObjectList一致；当无需输出参数时该配置可以为空；

5)ModelLink：该计算对象所使用的计算过程，即连接预置(或扩展)的计算模型。模型以上述参数作为输入输出项进行计算代码执行。当无需计算逻辑时该配置可以为空；

6)Locked：计算功能被启用/禁用，由此可根据需要自由控制所有计算功能的实时执行。

2.3计算单元

计算单元承载黏合器所有的实时计算任务，它接受数据单元的所有数据变化，查找并调用所有与变化数据相关的已配置的计算模型，将计算结果反写至实时数据库中，从而完成一个完整的黏合器运转流程。

计算单元包含一张一对多的映射表，“键”为结构单元中InputObjectList涉及到的对象ID集合，“值”为InputAttributeList中属性ID+计算对象CalcArgumentID(可能有多个)的组合。当接收到数据变化时，查找映射表，获取该对象和属性所参与到的所有计算对象CalcArgumentID，然后获得其对应的ModelLink所指向的计算模型，并逐个检验有效后再执行计算过程；计算完成后将结果写入OutputObjectList和OutputAttributeList对应的对象属性值中，完成实时数据库的更新。

2.4计算模型

计算模型为黏合器中预置的且可随时在线编程扩充的模块集合。黏合器的定制者可在某个模型中使用C语言编写计算逻辑，然后编译生成模块库，供计算单元根据需要随时调用。计算模型可以被重复利用，即只要计算逻辑相同，无论多少个黏合器BondingAgent均可采用同一个计算模型，仅需一次编码。

计算模型(Model)包含如下组成部分：

1)模型名称：模型的唯一标识，不可重复，计算模型需要根据用户编写的代码生成完整的代码文件，并生成对应的模块库。

2)输入参数：与结构单元CalcArgument中的输入对象及属性对应，区别在于，结构单元关心究竟是哪个数据对象实例和哪个属性发生变化，亦即其与数据库对象强烈关联；而计算模型仅关注这些属性都是什么数据类型，个数是多少，最终结构单元的输入项都将作为函数参数被传入计算模型并参与计算。当无需输入参数时可以为空。

3)输出参数：与输入参数原理类似，为模型的最终计算结果，写入结构单元的输出对象中。当无需输出参数时可以为空。

4)引入模块：计算模型本身为可重复使用的逻辑模块，故模块间对已实现部分可嵌套引用，提升代码的利用率。

5)程序代码：模型的逻辑实现，采用适应性及执行效率较强的C语言实现。提供代码模板，用户仅需填写实现逻辑的必要代码，其他的变量定义、统一头文件、统一调用接口等补充代码由模块自动实现。

同时，程序代码中可轻松调用基础系统平台所提供的丰富接口集，如读写(Read/Write)实时数据库，遍历(Retrieval)黏合器BondingAgent的ParticipantList属性中所管辖的对象群等等功能，因此程序块具有的扩展功能异常强大，完全能满足高级应用的复杂需求。

图3展示了一个计算模型构成示例图。

由于程序代码段的参数个数、类型均是动态可变的，为了保证计算单元对其调用便利，计算模型提供了统一的封装调用接口，接口名称为“模型名称”+“_entry”，上例中即为“cm_FaultCleat_entry”，在此函数内实现用户定义代码段的调用，屏蔽了计算单元调用用户代码时对参数个数及类型未知的困惑。

生成的示例代码如下：

3.处理方法

以下给出黏合器构造及使用的流程：

第一步：基于既有的数据库结构，按高级应用的要求规划数据的二次组织模式，构造若干新的黏合器BondingAgent；

第二步：对每一BondingAgent，配置其ParticipantList数据项，将现有数据测点(或其他BondingAgent)纳入该对象管辖范围；

第三步：规划计算逻辑及输入输出参数，配置新的计算模型Model，编写逻辑代码，利用计算模型提供的编译功能实现完整代码的生成、编译，生成模块库；若使用既有计算模型，则跳过该步；

第四步：在有计算需求的BondingAgent下配置若干计算对象CalcArgument，有几种计算逻辑即配置几个对象；对每个CalcArgument，配置InputObjectList、InputAttributeList、OutputObjectList、OutputAttributeList，配置ModelLink，将第三步中的计算模型链接至此完成二者的关联；

第五步：启动整个黏合器模块，实现流程运转，在运行过程中可实时控制计算功能的启用或失效。

4.应用举例

a.车辆在隧道中车头/车中/车尾着火情况下的联动功能：车辆在隧道中发生火灾时，车辆传送火灾信号至控制中心，经确认后启动A、B两个相邻车站区间内的风机排烟疏散，同时启动相邻车站的广播系统和乘客信息系统告知火情。

实现过程：

上述逻辑所涉及实时库测点分布在不同地理位置和专业上，利用黏合器能够很好地解决。

1)配置一个新的BondingAgent，将既有车体火灾测点、火灾位置测点、中心HMI确认测点、A、B区间的关联风机命令测点、广播启动命令测点、乘客信息发布命令测点纳入到该黏合器下；

2)在BondingAgent下添加一个新的CalcArgument，将车体火灾测点、火灾位置测点、中心HMI确认测点配置为CalcArgument输入测点，关联风机命令测点、广播启动命令测点、乘客信息发布命令测点配置为CalcArgument输出测点；配置对应属性；

3)编写一个新的Model，按对应数量配置输入参数和输出参数，在代码中分别实现车头/车中/车尾三种情况下风机的正反转逻辑、广播和乘客信息的命令输出；将Model编译完成后链接至CalcArgument；

4)模拟火灾工况，通过输出结果测试并验证上述功能实现。

b.将多个站点已出现损坏情况的设备的报警闭锁，避免故障状态和正常状态来回切换而频繁显示在报警窗。

实现过程：

1)配置一个新的BondingAgent，将既有已损坏设备测点纳入到该黏合器下，不管它目前隶属于哪个车站或哪类设备；

2)在BondingAgent下添加一个新的CalcArgument，将BondingAgent对象本身及其闭锁属性(AlarmLocked)配置为CalcArgument的输入测点及输入属性；

3)编写一个新的Model，代码中遍历BondingAgent的ParticipantList属性包含的已损坏设备测点，将这些测点的AlarmLocked置为与BondingAgentAlarmLocked一致状态值；将Model编译完成后链接至CalcArgument；

4)HMI上直接将BondingAgent的AlarmLocked置为“闭锁”或“解锁”状态，黏合器则自动完成所有测点的解闭锁功能实现。

本申请涉及的设计具有实际应用的可行性和成功经验，设计已经应用到地铁综合监控大系统软件平台的数个案例中。

1.本模型代码实现主要采用Qt开发包及C语言编写，具有跨操作系统平台的特点，非常便于移植。

2.本模型的设计思路不受业务逻辑的限制，在地铁综合监控系统应用极为广泛，涉及复杂联动控制、环控模式控制、应急预案设计、能耗综合分析等数个场景，成为诸多需求下可直接替代高级应用程序二次开发的一体化便利方案。

3.以上实施例不可以此限定本发明的保护范围，本发明未涉及的技术均可通过现有的技术加以实现。

Claims (6)

1.一种适应地铁综合监控系统的数据黏合结构，其特征在于：它包括高级应用、关系实时数据库、黏合器，所述关系实时数据库采用面向对象技术构造，每个物理设备在关系实时数据库中均表示为一个数据对象，具有唯一标识ID，数据对象的多维度刻画则用该对象的一系列属性来表示，每一个属性亦具有唯一标识ID；所述黏合器根据应用需求设计，它屏蔽现有结构组织，消除车站、专业、数据类型数据之间的分割界限，一切从应用需求出发，只把应用感兴趣的数据通过数据关联的方式重新编排为一个有序结构，并配置新结构的辅助信息，最终呈现给高级应用最为精准的数据组织形态；同时，对每个黏合器预置计算辅助，将可预知的有规律可循的逻辑处理提前为应用准备好，最大化地为上层高级应用提供数据、逻辑支撑的便利；所述高级应用既包含地铁综合监控系统基础平台的扩展高级应用，同时也包括地铁运维不断积累和发掘的各个专业、各种类型的新开发需求；其特征在于：

所述黏合器由数据单元、结构单元、计算单元和计算模型组成；

所述数据单元是黏合器运转的触发单元，也是与关系实时数据库的交互单元；数据单元依据结构单元的数据测点储备，向关系实时数据库注册数据变化的通知请求，并提供回调接口，当所关注的数据发生变化并被监听到时，回调接口将被自动调用，并将数据推送给计算单元，由其完成后续的逻辑计算；数据单元内的每一帧数据均为一个固定格式组合：变化数据点ID+变化属性ID+变化值；数据单元为计算单元提供数据准备，计算单元为逻辑的最终执行单元；

所述结构单元为黏合器的数据重构核心，将高级应用感兴趣的测点以一定的数据结构组织起来，形成新的更便于处理的数据模型；完整的结构单元由两类对象构成：黏合器对象BondingAgent和计算对象CalcArgument，每个黏合器对象BondingAgent至少均包含两个重要数据项：UniqueID，黏合器的全局唯一标识，也是提供构建、查找、遍历、命令操作对象的标识参数；ParticipantList，黏合器管辖的孩子对象列表，列表内为孩子节点的UniqueID有序序列；完成黏合器对象的组织后，在黏合器对象下配置参与内部计算的辅助计算对象CalcArgument子节点；

所述计算单元承载黏合器所有的实时计算任务，它接受数据单元的所有数据变化，查找并调用所有与变化数据相关的已配置的计算模型，将计算结果反写至实时数据库中，从而完成一个完整的黏合器运转流程；计算单元包含一张一对多的映射表，“键”为结构单元中InputObjectList涉及到的对象ID集合，“值”为InputAttributeList中属性ID+计算对象CalcArgumentID的组合；当接收到数据变化时，查找映射表，获取该对象和属性所参与到的所有计算对象CalcArgumentID，然后获得其对应的ModelLink所指向的计算模型，并逐个检验有效后再执行计算过程；计算完成后将结果写入OutputObjectList和OutputAttributeList对应的对象属性值中，完成关系实时数据库的更新；

所述计算模型为黏合器中预置的且可随时在线编程扩充的模块集合；黏合器的定制者可在某个模型中使用高级语言编写计算逻辑，然后编译生成模块库，供计算单元根据需要随时调用；计算模型能够被重复利用，即只要计算逻辑相同，无论多少个黏合器BondingAgent均可采用同一个计算模型，仅需一次编码。

2.根据权利要求1所述的数据黏合结构，其特征在于：所述面向对象技术构造提供地铁全线所有监控范围内的数据测点，按“地点+专业+数据类型”为单元进行数据组织。

3.根据权利要求1所述的数据黏合结构，其特征在于，孩子对象是：

（a）嵌套黏合器：即下一级已经组织好的黏合器整体作为本对象的孩子；

（b）独立测点：现有数据库中已配置好的实际工程数据点；由于工程数据配置采用面向对象技术构建，每个设备、每个测量参数均表示为一个对象，具备唯一的UniqueID；当采用其他方式构建基础配置数据库时，方法类似，只要将孩子数据测点的唯一索引标识填入黏合器的ParticipantList即可。

4.根据权利要求1所述的数据黏合结构，其特征在于，计算对象CalcArgument包含如下配置项：

（a）InputObjectList：参与计算单元执行所需的输入数据点有序序列，个数不受限制，这些对象与数据单元注册和推送过来的发生变化的数据点对应，亦即数据单元推送的变化信息必然能在InputObjectList中找到对应项，由此才能完成后续一系列调用过程；当无需输入参数时该配置为空；

（b）InputAttributeList：InputObjectList数据点各自对应的属性有序序列，个数与InputObjectList一致，由于同一个对象可以有多个动态属性变化，所以需明确究竟对象的哪个属性参与计算；当无需输入参数时该配置为空；

（c）OutputObjectList：参与计算单元执行所需的输出数据点有序序列，计算单元触发执行后的结果保存处，个数不受限制；这些对象在实时库中的更新数值是整个计算流程的最终结果体现，上层高级应用由此判断其逻辑需求是否被正确执行；当无需输出参数时该配置为空；

（d）OutputAttributeList：OutputObjectList数据点各自对应的属性有序序列，个数与OutputObjectList一致；当无需输出参数时该配置为空；

（e）ModelLink：该计算对象所使用的计算过程，即连接预置的计算模型；模型以上述参数作为输入输出项进行计算代码执行；当无需计算逻辑时该配置为空；

（f）Locked：计算功能被启用/禁用，由此可根据需要自由控制所有计算功能的实时执行。

5.根据权利要求1所述的数据黏合结构，其特征在于，计算模型Model包含如下组成部分：

（a）模型名称：模型的唯一标识，不可重复，计算模型需要根据用户编写的代码生成完整的代码文件，并生成对应的模块库;

（b）输入参数：与结构单元CalcArgument中的输入对象及属性对应；当无需输入参数时为空；

（c）输出参数：与输入参数原理类似，为模型的最终计算结果，写入结构单元的输出对象中；当无需输出参数时为空；

（d）引入模块：计算模型本身为可重复使用的逻辑模块，故模块间对已实现部分可嵌套引用，提升代码的利用率；

（e）程序代码：模型的逻辑实现，采用适应性及执行效率较强的高级语言实现。

6.一种适应地铁综合监控系统的数据黏合处理方法，构建权利要求1至5之一所述的数据黏合结构，其特征在于：

第一步：基于既有的数据库结构，按高级应用的要求规划数据的二次组织模式，构造若干新的黏合器BondingAgent；

第二步：对每一黏合器BondingAgent，配置其ParticipantList数据项，将现有数据测点纳入黏合器对象BondingAgent管辖范围；

第三步：规划计算逻辑及输入输出参数，配置新的计算模型Model，编写逻辑代码，利用计算模型提供的编译功能实现完整代码的生成、编译，生成模块库；若使用既有计算模型，则跳过该步；

第四步：在有计算需求的黏合器BondingAgent下配置若干计算对象CalcArgument，有几种计算逻辑即配置几个对象；对每个CalcArgument，配置InputObjectList、InputAttributeList、OutputObjectList、OutputAttributeList，配置ModelLink，将第三步中的计算模型链接至此完成二者的关联；

第五步：启动整个数据黏合结构，实现流程运转，在运行过程中实时控制计算功能的启用或失效。

Images