CN102360357B - Scada系统网状关系数据库节点的数据同步组件 - Google Patents

Abstract

本发明公开了SCADA系统网状关系数据库节点的数据同步组件，它从现有技术基础出发，设计实现新的同步组件Sycom，包括跨关系数据库平台同步支持；与SCADA系统平台的低耦合性；支持多个业务节点间的网状结构的数据交互；通过界面组态的友好方式设定数据源、数据终点、发布过滤条件，并细化到记录级。通过简单易用的配置界面表达用户的多样化业务数据复制需求，实现双机、多机间更为灵活的数据同步和发布复制工作，以适应SCADA平台在多个行业里越来越细化的市场和用户需求。

Description

SCADA 系统网状关系数据库节点的数据同步组件

技术领域

本发明涉及SCADA系统平台所应用的专业技术领域，涵盖电力监控、水利监控、油气化工、轨道交通、煤炭矿井等需要实施实时数据采集和环境设备监控业务的工控行业。同时由于后台数据库存储、多节点冗余策略特别是主备冗余机制的广泛业务需求，且具有组件在设计模式上与系统的低耦合性，也可推广到功能需求类似的专业和商业应用。

背景技术

SCADA(Supervisory Control And Data Acquisition)系统即数据采集与监视控制系统。可广泛应用于电力系统、水利监控系统、石油、化工、轨道交通等行业的数据采集与监视控制以及过程控制等诸多领域。SCADA系统是以计算机为基础的生产过程控制与调度自动化系统。它可以对各类运行环境、多种运行设备进行监视和控制，以实现数据采集、设备控制、测量、参数调节、各类信号报警、历史数据存储等各项功能。

以主备冗余的商用关系数据库为主要数据管理手段，统一管理历史和配置数据（系统参数、开关量状态、模拟量值、脉冲累计量、计算结果，报警/事件记录，故障报告等）的存储、维护，以支撑查询、统计报表、历史曲线、追忆重演等上层业务应用，是各类SCADA系统不可或缺的重要模块。为保证数据一致性和完整性，不可避免地要实现冗余双机的历史/配置数据实时/准实时同步，即使在配置了共享磁盘阵列的系统构架中，作为完整SCADA系统的功能模块之一，仍需提供该项功能。

除主备双机冗余的结构外，越来越多的行业应用将子业务数据从“胖而全”的集中历史数据库中分离出来，以满足运营和监控人员对查询实时性、特定数据安全、数据管理责任划分等定向的业务需求，如轨道交通中的设备维修管理数据、用电管理数据等。

因此要求数据同步模块既能满足双机数据的完备同步，又能有效地实现按既定条件进行数据过滤和数据转储到其他机器节点上，形成类似网状的多个存储节点间的数据自由复制流动。

目前节点数据同步设计主要包括两种方式：

1．绝大多数SCADA系统平台采用的是同步模块和系统紧密结合的高耦合方式，即依据运行操作系统、采用的商用数据库平台及特点、系统内模块间的交互设计模式等设计、开发、优化适应自身系统运行的同步模型。

此种设计方式能较好地满足自身SCADA系统的运行需求，但存在一定局限性，对跨关系数据库平台缺少支持；对业务数据的部分分离存储需要重新设计开发应用程序；仅限于行业内应用。

2．采用关系数据库自身的发布订阅机制，设定发布服务器、分发服务器、订阅服务器，然后选择某种订阅方式实现节点同步。主流商用关系数据库一般都提供此项功能，如MS SQLServer的发布订阅；Oracle的高级复制、流技术；Sybase的RSM复制管理，MySQL的同步复制机制等等。

此种方式利用商用数据库内置一体化的成熟数据分发技术，通过配置方式代替了绝大部分专用程序的开发测试工作，节省了系统实施的工作量，具有较好的适应性。但面向SCADA平台数据的实际使用过程中需要较多的限制条件，如账户要求、故障还原模型、数据表建立的主键要求、服务器名称限制等；配置较为繁琐，节点越多，复杂度越高；对数据表增加了很多额外字段和同步专用数据量，对同步过程中新建数据表的处理不佳；对于特殊的业务数据需求，较难实现多节点间的数据自由流动。

现有技术的缺点：1.根据厂家自身SCADA平台设计开发的同步模块缺少跨关系数据库平台的支持，一般是专库专系统专用；对用户指定的部分业务数据分离存储则需要较多的额外开发测试工作量；

2.采用商用关系数据库类似发布订阅的复制机制配置较为复杂，需要较多的额外磁盘空间开销；很难满足SCADA平台特定节点间的特殊数据复制需求。

发明内容

针对现有技术的不足，本发明从现有技术基础出发，设计实现新的同步组件Sycom，包括跨关系数据库平台同步支持；与SCADA系统平台的低耦合性；支持多个业务节点间的网状结构的数据交互；通过界面组态的友好方式设定数据源、数据终点、发布过滤条件，并细化到记录级。目的是通过简单易用的配置界面表达用户的多样化业务数据复制需求，实现双机、多机间更为灵活的数据同步和发布复制工作，以适应SCADA平台在多个行业里越来越细化的市场和用户需求。

本发明有益效果：本发明支持多业务节点间网状的数据交互模型，满足SCADA用户对各类业务数据自由分离、合并的同步分发需求，适应运营管理流程优化和专业分工精细化需求和发展趋势；采用组态方式确定及控制节点关系、同步过程实现，减少了开发工作量和使用复杂度，提高了系统对多类需求的适应性；通过对跨操作系统、主流关系数据库平台的支持，与SCADA系统平台低耦合性的设计，使得整个系统相比较现有技术具有较高的开发效率、适用性和设计弹性。

附图说明

图1为本发明实施例的主要构成和数据流原理示意图。

图2为本发明实施例的路径标签原理图。

图3为本发明实施例的单个调度周期时间划分示意图。

具体实施方式

以下结合附图和具体实施例对本发明创造作进一步详细说明。

系统采用相对SCADA平台独立的组件设计模式，降低系统与组件模块间的耦合程度，支持主站和子站组成分布式网络。主要构成和数据流原理如图1所示。

同步网络模型

如上图所示，Sycom支持形如网状的多节点同步模型，着力解决以下三类网络模型：

1) 双机模型

常用于控制中心(主站)的主备数据库同步。考虑服务器作为数据处理和系统运行的核心，通常SCADA系统都会配置冗余主备IO处理实时数据库和历史存储关系数据库。即便配置了共享磁盘阵列，基于系统设计完整性和普适性考虑，仍然需要设计主备库的同步策略，目的是将发生冗余切换后分离存储的数据进行并集式整合，再差异复制到双方数据库中，以保证主备节点的数据一致性、完整性和对外部查询利用的透明性。

2) 分布式模型

常用于子站和主站间的数据交互，通过骨干的通信网络实现数据传输。适应子站有数据存储需求的工程应用，如轨道交通的多专业综合监控自动化系统，每个车站都需要支持一段时间内的独立数据磁盘存储，且相互之间无交集，并要求将所有数据最终汇集到中央数据中心。

3) 业务数据分发模型

面向用户管理流程的优化和专业分工的精细化，对数据的利用已经不仅仅局限于条件查询及各类HMI显示(报表、曲线)，越来越多的面向行业的高级应用被提出，如历史数据挖掘应用、DSS、预期提醒报警、历史重演等等；有些还需要较高的查询效率，因此把符合需求的数据复制到专门的业务服务器节点并保持同步，不仅满足了应用也方便了业务扩展。

此外，在若干跨广域网的商业模型上，也可具体分析数据流向及存储需求，定制同步模型。

同步规则组态

同步组态通过HMI的方式接受用户的同步需求，形成.INI配置文件，进而形成同步规则；规则用于定制Sycom的实际数据流向、数据选择、同步机制等同步关键项。

组态配置包含如下元素(主要部分)：

Ø RuleID ：规则唯一性标识

Ø Source ：数据源节点，提供数据的机器节点，可以是各种节点；

Ø Login&Password(S) ：源节点安全登录信息，包括访问用户名密码等访问控制信息；

Ø Destination ：数据目的节点，数据复制的目的地，可以是各种节点；

Ø Login&Password(D) ：目的节点安全登录信息，包括访问用户名密码等访问控制信息；

Ø Directory ：同步文件目录，同步文件临时存放目录；

Ø

Ø Login&Password(D) ：目的节点安全登录信息，包括访问用户名密码等访问控制信息；

Ø Directory ：同步文件目录，同步文件临时存放目录；

Ø Log ：日志文件目录；

Ø DBName ：数据库名，同步涉及的数据库，允许多个数据库项，限定同步库级范围；

Ø TableName ：二维数据表名，同步涉及的数据库二维表，允许多个表项，限定同步表级范围；由于历史数据存储的长期性和累积性，不可避免地涉及到数据分割和二维表的动态建立，因此表名支持字符串的模式匹配和正则表达式，能满足有既定规律命名的表集合；

Ø Filter ：过滤器，设定表中记录的过滤条件，限定记录级的同步范围；不设定则为全同步模式；支持通用SQL语句的输入设定；

Ø Comment ：描述，执行此项同步必要的功能描述；

Ø 同步性能参数设置：

PatchSize ：批处理大小，每次同步数据包大小，以记录行数为依据；

SyncType ：调度类型，

1一次，仅一次性同步

4每天，每天固定时刻同步

8 每周，每周固定时刻同步

16 每月，每月固定时刻同步

32 间隔，按固定间隔同步，可精确到秒

SyncInterval ：调度频率，根据调度类型设定频率数值。

规则的编写基于对数据分发需求的逻辑分析，进行合理的拆分或合并。同时需要考虑规则设计给系统效率带来的影响。如多个节点向主备服务器上送节点数据，可将部分站点配置成与主服务器同步，剩余站点与备服务器同步，依靠两台服务器自身同步完成最终数据整合；以此减少单台服务器负责所有任务带来的节点压力。规则配置主要由程序员来完成。

同步过程设计及关键技术

1) 节点编号。网络中所有机器节点的唯一逻辑编码，以“编号+IP地址（组）+描述”的记录方式存放在配置文件中，所有节点都会加载该文件信息以完全掌握自身及其他节点的编号及网络连接信息。需要对网络中涉及的所有机器节点作逻辑上的节点编码，并保证唯一性。形如表1：

表1 节点配置文件示例

编号	IP地址	描述
			1	192.168.1.1	主服务器
2	192.168.1.2	备服务器
			11	192.168.1.11	子站A
12	192.168.1.12	子站B
			…
101	192.168.1.21	业务A
			102	192.168.1.22	业务B
…

2) 路径标签。历史数据有两种状态：新生成态和已同步态。新生成态即为外部应用（如历史进程）写入数据库的历史数据，在直接写入的机器节点上其路径标签为空；已同步态即已经对本数据做了同步动作，而不论同步动作经历过多少次，其经由路径均被记录在路径标签中。

存放于关系数据库中的所有记录(数据点)都有独立的路径标签，此标签附加了来源节点的编号信息，可以有效防止在双向同步中出现“同步环”，即来源节点的数据不会被再次同步回该节点。节点在接收到其他节点的同步数据后如果需要再次将该批数据同步到其他机器，则需要将自身编号添加到标签上。数据可以通过标签作路径追溯，可用作来源检查和数据责任认定。图2描述了网络中4个节点情况下不同数据记录在不同节点上的标签描述。

3) 刻度表。对所有同步任务都有同步刻度的记录，表名为*.scale，即同步过程进展，具体到某个库某张表的一条记录。当任何情况导致的通信中断、同步组件中断、组件退出后，再次启动时将读取刻度表中的同步刻度继续同步任务。

4) 批处理。数据同步采用批处理方式，不论是一段较短时间内（如一个调度周期）需同步的少量数据还是长期累积（如单台服务器故障至修复期间）未同步的大量数据，均采用批处理方式。采用大容量数据dump方式先将待同步数据分割到文件名形如*.bt临时文件群中。

批大小根据需求配置，尽管理论上批数值越大吞吐率越高，但实际应用中存在大文件数据交互占用资源持续时间长、同步中断概率增加、同步失败回滚导致的日志空间控制难度增加等问题，故批大小采用按工程实际计算后设定的方式，由文件长度和批记录条数两个因子决定。批处理还需要滚动维护文件的新建与删除操作。此外，还提供对数据分割的处理，比如数据按月度存储时，需要先检测同步对方是否有该月的数据表，否则需要读取表的字段结构及索引、主键等附属信息，新建相同格式的数据库表。

5) 同步调度。同步调度即同步的时机及步进过程。由于历史数据库同步不同于实时数据库同步，不要求完全实时同步，同时又要综合考虑大量历史数据同步给节点CPU、RAM资源以及网络带宽带来的消耗。

Sycom采用双周期调度，包括同步调度周期和线程事务处理周期。同步周期即执行同步的时刻，由同步规则中的SyncType和SyncInterval控制；线程事务处理周期即以较小的时间间隔完成各种标志、状态、数据库连接等实时检测，并可响应外部进程的调度控制需求。同一个节点上的多个规则任务采用串行方式运行，减少多个任务并发运行给数据库和网络带来的负荷，降低对系统正常运行的影响。图3显示了单个同步周期内的时间片划分的示意图。

6) 数据冲突容错处理。对于有主键（单字段如Id或组合字段如ObjectId + AttributeId + Time）的数据表而言，相同主键数据将导致数据插入失败，此时同步策略自动改变为逐条记录插入的方式，在记录遍历过程中，对于相同主键数据，已存在数据优先，欲插入数据将被过滤舍弃；当数据表不存在主键时，不对可能存在冲突的数据做任何处理，最大化保留所有数据，由后续读取数据的应用程序根据需要作进一步处理。

7) 错误处理及日志记录。常见错误处理有：规则配置信息无效(包括用户访问权限项)、通信失败或中断、数据信息异常重复(如同步时检测出主键重复)等情况，详细信息将会被记录到日志文件中。日志文件自动生成、自动维护，其总容量不超过一定的磁盘空间。

跨平台应用

Sycom采用Qt开发包设计开发，Qt跨主流OS平台，提供了丰富的关系数据库访问接口和功能封装、便利的网络访问功能、文件读写及目录操作、线程设计等模块。主要涉及类库包括：

Ø QSqlDatabase，QSqlDriver，QSqlQuery，QSqlRecord，各类DBMS drivers；

Ø QNetworkInterface，QTcpServer，QTcpSocket；

Ø QIODevice，QFile，QFileInfo；

Ø QThread等。

通过对应操作系统平台的动态链接库实现操作系统级的透明运行；通过封装了各关系数据库标准访问接口的驱动程序实现关系数据库的透明访问。对于数据库及二维表操作均采用标准SQL语句实现。

本发明具有实际应用的可行性。

1. 支持多个业务节点间的网状结构的数据交互，满足SCADA平台中越来越复杂的数据流模型的数据同步。设计模型在SCADA平台的部分应用中得到很好的验证。

2. 支持多节点间的数据自由合并、分离和管理使系统具有良好的适应性，也符合用户对SCADA系统日益提高的数据管理和高级应用需求。

3. 通过界面组态的友好方式设定数据源、数据终点、发布过滤条件、性能参数等同步所需配置项，细化到表记录级，以表达用户多样化的业务数据复制需求，实现双机、多机间更为灵活的数据同步和发布复制工作。

4. 跨操作系统平台，支持主流关系数据库平台；组件与SCADA系统平台的低耦合性。

5. Qt开发包接口丰富易用，且版本稳定可靠，并持续更新；主流商用关系数据库技术已相当成熟且在SCADA平台应用中不可或缺。

虽然本发明已以较佳实施例公开如上，但具体实施例和附图并不是用来限定本发明，任何熟习此技艺者，在不脱离本发明之精神和范围内，自当可作各种变化或润饰，但同样在本发明的保护范围之内。因此本发明的保护范围应当以本申请的权利要求保护范围所界定的为准。

Claims (1)

1.数据采集与监视控制SCADA系统网状关系数据库节点的数据同步方法，同步组态通过HMI的方式接受用户的同步需求，形成.INI配置文件，进而形成同步规则；规则用于定制同步组件的实际数据流向、数据选择同步过程；其特征在于：

步骤一、节点编号：其是网络中所有机器节点的唯一逻辑编码，以“编号+IP地址+描述”的记录方式存放在.INI配置文件中，所有节点均加载该.INI配置文件信息以完全掌握自身及其他节点的编号及网络连接信息；对网络中涉及的所有机器节点作逻辑上的节点编码，并保证唯一性；

步骤二、路径标签标注：历史数据有两种状态：新生成态和已同步态，新生成态即为外部应用写入数据库的历史数据，在直接写入的机器节点上其路径标签为空；已同步态即已经对本数据做了同步动作，而不论同步动作经历过多少次，其经由路径均被记录在路径标签中；存放于关系数据库中的所有记录都有独立的路径标签，此标签附加了来源节点的编号信息，防止在双向同步中出现“同步环”，即来源节点的数据不会被再次同步回该节点；节点在接收到其他节点的同步数据后如果需要再次将该同步数据同步到其他机器，则需要将自身编号添加到标签上；数据通过标签作路径追溯，用作来源检查和数据责任认定；

步骤三、刻度表记录与读取：对所有同步任务进行同步刻度的记录，表名为*.scale，即同步过程进展，具体到某个库某张表的一条记录；当任何情况导致的通信中断、同步组件中断、组件退出后，再次启动时将读取刻度表中的同步刻度继续同步任务；

步骤四、批处理：数据同步采用批处理方式，不论是一段较短时间内需同步的少量数据还是长期累积未同步的大量数据，均采用批处理方式；采用大容量数据dump方式先将待同步数据分割到临时文件群中；批大小根据需求配置，采用按工程实际计算后设定的方式，由文件长度和批记录条数两个因子决定；对数据分割的处理，需要先检测同步对方是否有月数据表，否则需要读取表的字段结构及索引、主键附属信息，新建相同格式的数据库表；

步骤五、同步调度：同步调度即同步的时机及步进过程；由于历史数据库同步不同于实时数据库同步，不要求完全实时同步，同时考虑大量历史数据同步给节点CPU、RAM资源以及网络带宽带来的消耗；同步组件Sycom采用双周期调度，包括同步调度周期和线程事务处理周期；同步调度周期即执行同步的时刻，由同步规则中的调度类型SyncType和调度频率SyncInterval控制；线程事务处理周期即以较小的时间间隔完成各种标志、状态、数据库连接实时检测，并可响应外部进程的调度控制需求；同一个节点上的多个规则任务采用串行方式运行，减少多个任务并发运行给数据库和网络带来的负荷，降低对系统正常运行的影响；

步骤六、数据冲突容错处理：对于有主键的数据表而言，相同主键数据将导致数据插入失败，此时同步策略自动改变为逐条记录插入的方式，在记录遍历过程中，对于相同主键数据，已存在数据优先，欲插入数据将被过滤舍弃；当数据表不存在主键时，不对可能存在冲突的数据做任何处理，最大化保留所有数据，由后续读取数据的应用程序根据需要作进一步处理；

步骤七、错误处理及日志记录：规则配置信息无效、通信失败或中断、数据信息异常重复情况，详细信息将会被记录到日志文件中。