复杂事件处理

2024-10-11

复杂事件处理（精选7篇）

复杂事件处理篇1

复杂事件处理 (Complex Event Processing, CEP) [1]是一种新兴的事件处理技术, 它将系统数据看作不同类型的事件, 通过分析事件间关联关系建立不同的事件关系序列, 利用过滤、关联、聚合等技术, 由众多简单事件产生少量复杂事件, 供其它系统应用。CEP目标是从软件系统各个层次的事件流中获取信息, 理解这些信息对上层管理目标和业务过程的影响, 并做出实时响应。

本文设计并实现了一个高性能复杂事件处理引擎—Ceper。它使用自定义的灵活易扩展的类数据库事件处理语言 (SQL Event Processing Language, SEPL) , 支持序列、否、克林闭包和合取等不同的事件间关系, 具有较强的事件表达能力。经过测试, Ceper的性能是主流开源复杂事件处理引擎Esper[2]的3~6倍。

1 相关工作

复杂事件处理是主动数据库、流事件处理等技术的延伸和发展。它将传统的先存储静态数据再处理的数据处理方法, 转变为实时处理动态的连续事件流, 能高效及时地从数据洪流中过滤出相对少量的具有应用价值的数据。

SASE[3]是马萨诸塞大学开发的高效复杂事件处理引擎, 它基于非确定性有限状态自动机 (Nondeterministic Finite Automata, NFA) 进行事件处理, 利用丰富的事件处理语言并描述了形式化的语义, 使用查询计划来检测复杂事件。

Cayuga[4]是康奈尔大学利用事件代数的概念设计的发布/订阅系统, 使用有限状态自动机进行复杂事件处理, 并通过合并不同查询需求的中间状态进行性能优化。

ZStream[5]是麻省理工学院设计的复杂事件处理引擎, 采用了树结构作为模式匹配模型, 将合取、析取和克林闭包等操作统一到树中。

SASE利用NFA进行复杂事件处理, 具有良好的性能, 但SASE没有克服NFA模型在否、合取操作实现上的固有不足;Cayuga提出了基于NFA模型的优化方案。ZStream采用树模型进行模式匹配, 弥补了NFA模型的不足, 但它先将事件存储在树节点中再进行处理, 增大了系统开销, 降低了引擎的实时性和执行性能。其它典型的研究工作包括斯坦福的STREAM[6]、伯克利的Telegraph CQ[7]等。

复杂事件处理也得到了企业界的广泛关注, Coral[8]、Stream Base[9]、Sybase[10]、IBM[11]、Oracle[12]等纷纷推出了自己的复杂事件处理产品。Esper Tech[13]公司也开发了开源的复杂事件处理引擎Esepr和NEsper, 得到了广泛的应用。

2 事件处理模型

本节给出了Ceper中的事件定义, 介绍了Ceper的事件处理语言 (SEPL) 和它支持的事件操作及事件筛选策略。

2.1 事件

事件是复杂事件处理技术的基本概念, 分为事件类型和事件实例两个概念:事件类型描述系统的状态变化, 将相关状态信息映射为一系列属性, 常用大写字母或大写字母加下标 (如A、B或En) 来表示不同的事件类型;事件实例是某一事件类型的实例对象, 表示具体发生在某一时刻的系统状态变化, 常用对应事件类型的小写字母加下标 (如a1、a2和b1, a1和a2是事件类型A的不同实例) 表示。

在Ceper中, 事件分为原子事件和复合事件:原子事件具有原子性, 不可再分割为其它事件;复合事件由CEP引擎加工原子事件得到。

Ceper中的事件采用三元组描述, 表示事件的起始时间、结束时间以及事件的属性集合。对于原子事件, starttime等于endtime。

2.2 事件处理语言SEPL

CEP最重要的是能使用户简单、直观地表达信息。类似于数据流查询语言MYCQL (My Continue Query Language) [14], 对数据流模型作了形式化, Ceper使用SQL-like事件处理语言SEPL来描述事件。

SEPL的作用是将用户的事件处理需求转换为形式化的查询表达式, 它的基本语言结构如下:

SELECT Selection Query

PATTERN Pattern Query

WHERE Where Query

WITHIN Global Window

OUTPUT Out Frequency

SELECT子句指定查询语句的输出, 用于筛选出用户关注的属性。令P为WHERE子句指定的谓词, 例如下:

PATTERN子句定义了事件序列, 不同的事件序列关系在2.3详细介绍。例如下:

WHERE子句定义了事件的谓词约束条件, 支持算术、不等式、逻辑等运算。令Pi为事件流Ai涉及的谓词, 例如下:

WITHIN子句定义了查询事件需满足的时间范围 (时间约束条件) , 只有处于滑动窗口内的事件才会被处理。例如下:

OUTPUT子句定义了结果的输出频率。如OUT-PUT 60s, 表示每60秒输出一次;OUTPUT everytime, 表示立即输出。SEPL查询语句示例如图1所示:

以图1为例, 从连续的输入事件流中查找PAT-TERN子句中指定的事件序列, 要求A.id等于C.id并且C.b大于E.b。事件需在10分钟内出现, 当出现这样的事件序列后, 将事件A的id属性、B的name属性组成一个新的事件立即输出。

2.3 事件操作及事件筛选策略

Ceper支持五种不同语义的事件间时序关系, 它们是事件的时序约束条件, 通常称为事件操作。

序列操作 (Sequence (A→B) ) :表示B事件在A事件之后发生。

否操作 (Negative (!B) ) :表示某一时间段内事件B没有发生。

克林操作 (Kleene (A[n…m]) ) :支持克林闭包语义, 表示事件A重复发生n至m次 (含n和m) 。

合取操作 (Conjunction (A&&B) ) :表示在某一时间区间内, 事件A和事件B都发生。

析取操作 (Disjunction (A||B) ) :表示在某一时间区间内, 事件A或事件B发生或者两者都发生。

Ceper用each修饰符描述事件筛选策略。被each修饰的事件操作对应的事件实例都会被选入Ceper处理引擎。且有如下四种情况:

A→B只选择第一组满足条件的事件A和B的组合输出。

each A→B查找每一个A事件后紧跟的B事件。

A→each B只选取第一个到达系统的A事件, 并为其查找后面跟着的每一个B事件, 再将其复合输出。

each A→each B任意一个A事件与其后出现的任意B事件均组合输出。

对于同一事件序列, 使用不同事件筛选策略的不同结果, 如图2所示。

3 Ceper系统结构

本节介绍Ceper的系统结构以及模式匹配树 (Pattern Match Tree, PMT) 。

3.1 Ceper系统结构

Ceper引擎结构如图3所示。它包括的各个模块主要功能如下:

事件输入:从其它模块或者网络方式接受流入Ceper的事件, 支持进程内通信、JMS、Jabber等多种类型的事件来源。

语法解析:将SEPL编译为抽象语法树 (Abstract Syntax Tree, AST) , 翻译成处理引擎能理解的语言。

PMT构建:根据抽象语法树构建相应的PMT。

Ceper运行时:利用PMT对连续的输入事件流进行事件处理, 提供线程调度、内存管理、滑动窗口以及聚合函数处理等运行时支持。

处理行为:符合某种前提条件的事件序列出现以后, Ceper引擎将触发处理行为, 执行用户定义的处理逻辑。

Ceper引擎执行过程中, 用户利用SEPL描述事件处理需求, 引擎通过解析SEPL语句构建PMT, 处理从事件输入接收到的事件, 完成相应的处理行为。

3.2 PMT

PMT是一种基于二叉树的复杂事件处理模式匹配方法, 支持丰富的事件操作 (包括否、克林、析取等) , 满足复杂事件处理引擎的实时性、高吞吐量、可扩展性、鲁棒性等。

PMT结构图如图4所示, 基于二叉树结构, 分为叶节点、连接节点和终端节点三类。

叶节点:根据事件类型转发到相应父节点, 可看作事件分类器。

连接节点:进行事件复合运算的节点, Ceper支持上述的五种事件操作。

终端节点:用于输出复合事件处理结果, 如:定时输出、批处理输出等。

在PMT中, 各种类型的事件是初始输入节点, 每个叶节点代表一种事件类型。

4 Ceper关键技术

借助利用事件为组件的智能家居监控系统[15]中事件驱动概念, Ceper也是以阶段事件驱动架构 (Staged-Event Driven Architecture, SEDA) [16]为基础, 通过管道方式支持各种类型处理需求, 满足系统动态扩展性的需求。下面分别介绍Ceper的两个关键技术:PMT构建和Ceper运行时。

4.1 PMT构建

PMT构建过程中, 先根据事件类型封装成不同叶节点, 然后用时序等事件操作, 封装成连接节点, 再根据节点连接方式连接各节点, 最终组成终端节点进行输出。

节点连接过程中, 每次与它左侧或右侧另一个节点结合。以2.2节中的查询示例为例, 可以得到如图5所示PMT结构。

图例, 将查询条件划分为 (A) 、 (!B→C) 和 (D[3…5]→E) 。从右侧最后一个节点开始, 每次将其与它左侧节点组合成一个新节点, 并重复这一操作直到所有节点均结合完毕, PMT构建完成 (这种结合方式称为右结合) 。相反, 自然就有左结合。如果每个节点随机选择左右节点结合, 则可构建更多不同的PMT。

生成PMT后, 须将WINTHIN子句和WHERE子句指定的滑动窗口和谓词约束条件放置在PMT的节点上。如何放置约束条件对Ceper的效率有较大影响。

一般情况下, 将全局滑动窗口和谓词约束条件判断下推, 尽早进行判断, 可以过滤掉不满足条件的中间数据, 减少PMT匹配过程节点间传递的数据量和缓存的中间结果, 是一种有效的优化策略。

4.2 Ceper运行时

Ceper运行时是Ceper引擎通过PMT对连续事件流进行复杂事件处理的过程。

PMT的每个节点的运行时分为三个组件:事件接收、处理、传递。如图6所示。

不同类型的连接节点的事件接收和事件传递组件功能基本一致。事件接收组件接收左子节点传来的复合事件, 交给事件处理组件。事件传递组件将处理后的事件封装成一个新的复合事件, 传给父节点继续进行模式匹配。

事件处理组件是Ceper的主要组件。对于不同的事件, 事件处理组件主要有两种不同的处理策略:缓存和验证处理。缓存是将输入事件暂存在连接节点的左、右缓存中;验证处理将事件与缓存中的事件结合后进行时序约束、谓词约束和滑动窗口条件的验证。若验证成功则交给事件传递组件。下面分别介绍各类连接节点对的事件处理方法。

序列节点:

序列节点描述左右子节点间顺序时间关系, 除了右子节点为否节点的情况外, 要保证在将左侧和右侧输入事件合并时, 右侧事件的结束时间小于左侧事件的起始时间。它有左、右两个缓存, 分别用于存储从左、右子节点接收的事件。

否节点:

否节点判断某一事件在特定时间内没有发生, 需要外部条件作为参考以确定时间范围。

克林节点:

克林节点内部只有一个缓存, 用于存储特定事件。以B[low…high]→C为例, 左侧输入为特定的事件, 即B类型的事件;右侧输入为结束事件, 即以一个C事件到达作为结束点。

合取节点:

合取节点有左、右两个缓存, 且存储长度均为1。因为对于有序事件序列, 只需各存储左右两边的一个事件即可。

析取节点:

析取节点有左、右两个子节点, 但不需要缓存存储, 因为只要有满足约束条件的输入即向上一层节点传播。

运行时示例:

2.2中查询语句的运行示例如图7所示。前四个事件 (a1、b1、a2、d1) 都是作为节点的左输入, 故直接存入对应节点的左缓存。当c1到来时, 触发序列 (!B→C) 处理事件, 它结合左缓存中已存在b1, 封装成新的复合事件传给父节点序列 (each A→ (!B→C) ) 。因为只有a2的开始时间小于c1的结束时间, 封装成复合事件输出, 再存入其左缓存中。e1到达时, 克林 (D[3…6]→E) 封装新克林事件传给父节点。最后一个时序节点接收到右侧传来的复合事件后, 因为的结束时间为t5, 同时需要满足克林事件个数为3-6, 故满足的克林事件序列为{d2, d3, d4}, 因此最后输出的复合事件为。

5 性能评测

5.1 实验准备

实验采用事件生成器来生成各种类型、顺序以及比例事件, 相关参数见表1。通过控制事件序列生成顺序和事件属性值生成范围等方式来达到控制产生匹配结果的概率。

5.2 性能测试

本节先测试了下推约束条件对Ceper性能的影响, 然后将其作为测试变量, 与Esper进行对比测试。

约束条件下推:

如图8所示, 在没有谓词约束条件情况下, 下推与未下推的处理时间基本一致;而查询条件包含的谓词约束条件数量和满足概率对下推的效率有较大影响。

查询语句长度:

查询语句长度指查询语句中涉及的事件类型数量。

如图9所示, 随着事件序列长度增加, Ceper引擎吞吐量有所下降而Esper引擎吞吐量有所上升, 但Ceper引擎基本稳定。但整体来看, Ceper引擎吞吐量仍比Esper引擎高出约3倍。

查询语句类型:

查询语句类型指查询语句的PATTERN子句中涉及事件操作类型, 由于不同事件操作进行事件处理的开销不一样, 查询语句类型对复杂事件处理引擎的吞吐量有影响。

Ceper和Esper的吞吐量与查询语句类型的关系如图10所示。在随机情况下, PMT运行效率最高为合取操作 (A&&B) , 最低为析取操作 (A||B) , 其它几个操作效率介于两者之间, Esper情况类似。这是因为, 与A→B等操作相比, A&&B比减少了A、B时间关系判断和遍历次数, 只需保存最近且未被使用的A或B事件;而A||B有一个事件A或B就可以向上传播, 事件中间结果较多, 导致处理时间较长。

6 结论

本文设计并实现了一个高性能复杂事件处理引擎—Ceper。Ceper使用事件处理语言SEPL, 基于PMT进行复杂事件模式匹配, 支持时序、否、克林、合取、析取等多种事件操作, 具有实时性、高吞吐量、可扩展性和鲁棒性等特点。

由于复杂事件处理在实时处理大量连续事件流上的高效性能, 它可被研究应用于监控业务活动、发掘群众智能、避免网络攻击、预防金融犯罪、实施系统动态校验等领域。

摘要：复杂事件处理技术从连续的输入事件流中分析并提取出满足特定模式的事件序列。它将传统先存储静态数据再进行处理和挖掘的数据处理方法, 转变为实时处理动态事件流, 更加符合真实世界的数据处理模式, 能够高效及时地从数据流中过滤出相对少量的具有应用价值的数据。文章设计并实现了一个高性能复杂事件处理引擎——Ceper, 提出了Ceper的事件处理模型, 展示了它的系统结构和模式匹配树的方法 PMT, 介绍了Ceper的实现的关键技术, 并进行了一定的测试。

关键词：复杂事件处理,模式匹配,树

复杂事件处理篇2

当前在房管信息系统建设中如何及时地发现攻击且有效防范, 已成为一项重要的课题。

复杂事件处理 (Complex Event Processing, 以下简称CEP) 以事件驱动 (Event Driven) 的观点来处理信息系统中产生的海量数据, 可用于检测系统中的异常行为或者感兴趣的行为模式, 预测未来事件等。事件可以是已经发生或者正在发生的任何事物可以来自于真实世界或者虚拟世界, 复杂事件处理技术已经逐渐成熟, 在大规模数据管理系统, 尤其是房管信息系统中的应用已是大势所趋。

二、现阶段房管信息系统面临的挑战

1. 大量的监督、监管信息处理

为了对基本农田、矿山、违法用地易发区进行更好的监控, 应大量建设视频监控网点, 使基本农田违法占地易发区实现全部可控;还应监督开发建设单位公布项目房源及销售价格, 对销售情况进行“一户一证一房”对接核查, 从源头上杜绝违规操作;持续开展网络筛查, 及时追踪治理“代售”信息, 对涉及的中介机构进行调查处理。同时, 还应接受来自各种渠道的群众举报。这无疑对房管信息系统的实时处理能力是一个巨大的考验, 也对房管信息系统提出了极高的可靠性要求。

2. 海量信息的汇总与统计

近年来, 经常有新闻报道:房管局与国家统计局的统计结果相差悬殊, 且统计结果单一, 较百姓的亲身体验结果相差甚远。造成这种结果的主要原因是源数据规模过大, 无法对其进行全部统计, 只能采取抽样统计, 而抽样则意味着误差, 误差的大小取决于抽样比。因此, 房管信息系统需要一种减小抽样比 (或者对所有数据进行实时统计) 的解决方案。

此外, 原始数据对象的复杂化和动态化向房管信息系统的数据处理能力提出了新的挑战:来自不同设备、不同格式的数据, 需要汇总至同一数据库中, 大大增加了房管信息系统的复杂度。

另外, 还需要房管信息系统增加统计的维度、精细统计粒度, 实现对数据的全面分析。例如, 对某月房价的统计, 不仅计算出房价的均值, 还需计算房价按不同地区的价格分布、不同价位区间的成交量所占总成交量的比例等。

3. 恶意攻击的识别与处理

随着互联网的普及, 网络攻击事件频繁发生, 且呈现日趋加剧之势, 房管系统被攻击的案例也屡见不鲜。常见的攻击方式有TCP SYN拒绝服务攻击、地址猜测攻击、洪泛攻击等。

因此, 房管信息系统需要具有攻击检测与处理的功能, 该功能需要对大量的网络数据包进行处理, 其引发的实时性与准确性等问题也需要得到妥善解决。

4. 业务逻辑日益复杂

随着系统的终端用户逐渐增多, 用户的需求也会更多更杂, 如何在现有逻辑的基础上迅速扩展出其他逻辑, 对于系统的开发人员来说是一个头疼的问题。即使解决了逻辑扩展问题, 系统的稳定性问题的处理也会变得相当棘手。

三、复杂事件处理技术在房管信息系统中的应用

CEP技术的快速处理、实时统计、高效运算、开发周期短、扩展功能强等特性, 能够帮助房管信息系统解决前述问题。CEP技术与房管信息系统的应用场景如图1所示, 来自各地、各种不同形式的数据源, 在经过CEP处理引擎的加工后, 将最终数据汇总至后台数据库存储, 最终用户可以通过直接访问数据库存储方式得到统计及汇总数据, 也可以通过访问基于数据库存储之上的Web服务器方式间接得到这些数据。

1. 快速的数据处理, 解决大量监控数据的积压

CEP将系统数据看作不同类型的事件, 通过分析事件间的关系, 如成员关系、时间关系、因果关系、包含关系等, 建立不同的事件关系序列库, 即规则库, 利用过滤、关联、聚合等技术, 最终由简单事件产生高级事件或商业流程。经过这一特殊的处理流程, 商业系统的性能, 如响应速度、吞吐量等得到了显著的提升。

将CEP技术应用至房管信息系统中, 将有助于解决监控、监管信息的实时处理, 避免因系统中大批量数据的积压而导致系统瘫痪和数据丢失。

2. 统计数据实时形成, 减小统计误差

目前, 房管信息系统中涉及到大批量数据的监控, 而随着监控、监管的项目增多, 数据规模还会不断增大, 高峰时能够在数分钟内就生成相当规模的数据集。而CEP的如下特性, 使其在大规模数据处理的性能方面具有绝对优势。

(1) 流式数据聚类。CEP可以对历史数据与不断增加更新的数据进行动态的统计处理, 并准确地显示出流式数据在时间上的动态特征, 将系统中有限的资源发挥出最大的性能。

(2) 实时数据筛选。在大规模数据环境下, 可以有选择地提取出业务逻辑所关注的数据, 过滤掉其他无意义的数据。在筛选的同时, 还可以对提取出的数据进行分类, 以加速后期汇总与统计。CEP的此种数据处理特征可以为房管信息系统的性能带来数倍乃至数十倍的提升。

(3) 数据流模式匹配。在数据处理过程中, 可以对不同数据源的数据进行模式识别, 如规定不同数据流中数据的关联 (同时存在或互斥等) 或数据到达的先后顺序。这样, 便将毫无特征的数据变得规律起来, 使数据的后期处理变得更为高效。

(4) 流式数据压缩。这里的数据压缩是指, 在给定的误差设定下, 把历史数据压缩为一个相对较小的概要数据集, 同时保证概要数据集对历史数据的代表性。CEP的数据压缩方法和统计模型的结合较为紧密, 可以将海量的历史数据统计为极具代表性的少量数据, 而又不使总体的统计结果失真。相比于现阶段房管信息统计系统的统计误差大、统计周期长等特点有极为明显的优势。

(5) 数据预处理技术。在数据进行汇总与统计之前, 先对原始数据进行一次预处理, 如排序、合并、转化等操作。这些预处理操作不但简化了后续的业务处理流程, 而且对提升后续逻辑处理的性能也有很大的帮助。

3. 高效的运算能力, 解决系统性能瓶颈

CEP提供了处理复杂逻辑的简单操作符, 使庞杂的业务逻辑变得简单明了;同时, 还提供了基于基本操作符的单机并发, 充分利用CPU资源。

主流的CEP产品支持分布式部署, 不同的数据处理逻辑可以分别部署在寄存于独立硬件设备的节点上, 节点之间只通过数据流进行通信。同时, CEP还支持多节点间的并行, 附加负载均衡技术, 将房管系统中最耗时的操作分流至多台主机上, 从而提升系统的运算性能。

4. 短开发周期及强大的可扩展性, 处理复杂的业务逻辑

目前, 市场上主流的CEP产品均已提供功能齐全的集成开发环境, 帮助应用开发人员快速开发并部署应用逻辑, 并且涵盖了应用逻辑设计、测试和部署等开发流程中的各个阶段。业务逻辑原型在很短时间内完成, 而最终版本也将在几小时至几天时间内形成。

除此之外, CEP产品还提供了一个应用扩展平台, 通过该平台, 开发人员可以自定义基本的逻辑处理单元。开发人员可以使用不同的开发语言、不同的开发平台来开发自己的逻辑处理单元, 并通过统一的接口添加至CEP的项目之中。对于逻辑复杂且涉及领域广泛的房管信息系统来说, 强大的扩展功能在增大系统的逻辑覆盖度的同时, 还减小了系统的维护成本。

总之, CEP快速数据处理的特性可以帮助解决各种监督、监管信息处理的性能问题;实时生成统计数据能够在海量信息汇总统计瓶颈中发挥很大作用;高效的运算能力在解决信息汇总与统计问题的同时, 还能够快速识别出恶意的网络攻击;而高可用性、开发周期的缩短和强大的扩展功能, 不但降低了开发人员的工作难度, 还大大增加了系统的稳定性。

参考文献

[1].卢东明.中国CEP发展的春天.程序员.2010.5

复杂事件处理篇3

射频中间件是一种应用系统软件,位于后台应用软件与数据感知设备之间。中间件能够屏蔽读写器的复杂性和多样性,数据流由读写器采集后,经预处理和逻辑事件的检测工作后,再传给后台应用软件。

复杂事件处理是一种信息处理新技术,将信息系统中产生的海量数据通过事件驱动的观点进行处理,不仅可用于检测系统中的非常规行为,还可以检测特定的行为模式等。事件处理技术可以使用于存在数据流的大多数领域,并且可进行原有处理方式的改进,例如网络管理、传感器环境、金融系统等方面。随着射频技术的发展,感知设备的应用越来越广,所支持的协议也有差异;而且,采集的数据量越来越庞大,中间件在企业应用程序中的重要性也越来越明显[1]。

综上所述,本文提出了一种基于复杂事件处理的射频中间件的研究。在抽象层对读写器的原始数据流采集建立了统一的平台,通过服务层对复杂事件数据进行预处理和逻辑事件的检测工作,再提供准确性、实时性的相关数据给上层应用系统。

2 复杂事件处理

2.1 事件层次模型

如何高效地将庞大的原始数据流复合成为包含高级语义信息的、对上层应用有意义的复杂事件是复杂事件处理的关键。可将复杂事件的处理过程分为以下几个层次。

2.1.1 事件清洗

复杂事件处理引擎需要减少干扰数据的影响,清洗不准确的原始数据,从而提高数据采集的质量,将可靠的数据提供给企业应用程序。

2.1.2 事件压缩

随着服务器部署的大规模应用,将产生海量的数据,使得一种高效的事件压缩算法对如此庞大的数据流处理非常关键。

2.1.3 事件检测

原始事件只能反映事件的简单发生情况,达不到对业务含义的完整表达,上层企业应用的需求无法得到满足。事件检测至关重要,将原始数据流进行检测、聚集等一系列操作,复合成更高层次的复杂事件后传递给上层应用。

2.2 射频复杂事件处理

基于射频技术的应用包括产品的生产、储存、运输、销售,并发展到售后服务,逐渐形成基于射频技术的WSN(Wireless Sensor Network)及物联网,射频技术将推动智能化管理。标签数据在这些应用中,具有如下特点:①事件的语义信息。②由于标签读取的重复读、漏读等造成数据的异构性。③事件发生轨迹的时空相关性及事件的时间属性。

复杂事件处理技术的应用,使射频应用系统处理大规模数据间复杂关系时满足实时性要求。例如,在供应链管理中,当物件库存量或者停留时间大于设定的时间阈值时,配送中心会收到一条警告信息。

复杂事件处理技术在云计算、海量实时数据处理和物联网领域中具有重要的研究价值和广阔的应用前景[2]。

3 射频中间件设计

中间件体系结构如图1所示,可以看出设计的射频中间件架构包括抽象层、服务层和应用层3部分。

3.1 抽象层

适配器的配置文件由射频中间件抽象层使用JAXB (Java Architecture for XML Binding)来存储。适配器由服务组件的形式进行表示。每个服务组件都有一个factoryID号和一个serviceID。factoryID是工厂ID,它可以创建一个服务。使用服务时将由ServiceID唯一确定,此ID是服务的唯一名称。当中间件服务器停止并重新启动时,这些配置将被自动加载,并回到所保存的状态。读取配置文件后,服务器将尝试连接在该文件中指定的所有服务。如果中间件不能提供所需要的工厂,该服务将被跳过并在重新建立工厂时可用[3]。

3.2 服务层

复杂事件处理引擎是服务层的核心组件。复杂事件处理引擎将由下层采集来的原始数据进行过滤、聚集等相关处理,形成更高层次的复杂事件信息,再传递给上层应用系统。

3.3 应用层

本文射频中间件的最高层部分是应用层与企业应用系统集成,提供这一层与上层应用系统的接口,各自所需要的射频数据通过这些接口提供给用户。数据从处理服务层传过来,在处理引擎上得到业务事件的具体信息,集成处理的数据和企业应用系统。

4 应用举例

4.1 场景描述

射频提供实时信息给供应链,使各个环节的供应链管理变成一个高速反应体系。射频的仓库管理场景模型中,一般包括对物件的卸货、入库、质检、更新、盘点和出库等环节,质检读写器、出入库读写器、手持读写器及货位读写器构成了一个射频读写器网络。射频标签黏贴在包装箱、物件和托盘上,自动化管理配送、入库、盘点、质检、出库等环节[4]。

4.2 复杂事件语言描述

入库口读写器、装货读写器、卸货读写器、质检读写器、货位读写器出库读写器和手持读写器构成射频读写器。有关的几种基本的简单事件如下:卸货事件、入库事件、装货事件、出库事件、质检事件、货位事件。下面通过EPL语言,对上述场景模型提取出复杂事件。

4.2.1 判断物件入库或出库

在仓库出入口处安装2台读写器,取名为R1和R2,物件出入的方向可以通过R1和R2进行判断。贴有标签的物件首先通过R1读取,再被R2读取,则表示为入库;正好相反的过程,被R2读取后,再被R1读取,则表示为出库。通过事件的时间顺序关系来设置相应场景的模式匹配。用EPL判断入库表达如下:

4.2.2 设定值

设定时间阈值进行物流配送的判断,只要在某个环节,出现物件停留的时间大于设定的阈值时,配送中心会收到相应的警告信息。这样,加快了物件的配送速度,物流效率就得到提高。例如,设定的时间阈值为shipping_dwelltime,相应的EPL表达如下:

4.3 场景模型性能

场景模型性能指通过实验对比采用事件处理引擎和传统数据库的实现方式的实时性能。实验数据见表1。

通过实验数据比较可得出:事件数量小的情况下,传统数据库和复杂事件处理引擎处理方式的实时性能接近;但事件数量增加的情况下,后者具有明显优势。而实际应用将更为复杂,因此对数据进行有效的复杂事件检测是推动射频中间件应用的一个关键点。

5 结论

本文研究设计了基于复杂事件处理的射频中间件,针对该中间件抽象层屏蔽读写设备的差异,建立统一的平台;服务层对原始标签事件进行复杂事件处理,如模式匹配、关联分析等;通过应用层与上层应用系统进行集成整合。本文以供应链管理为例,说明复杂事件处理技术在RFID应用中的重要性。

复杂事件处理篇4

复杂事件处理(Complex Event Processing),简称CEP技术,它是近年在信息数据高速增长的条件下,结合主动数据库、数据流处理等一系列技术所产生的新的数据处理技术。CEP技术的核心是以事件为驱动的基础模式,其将各种信息数据抽象为事件,而用户只需要针对自己所关心的事件进行检测或查询,例如查询加工车间中某一道工序所耗费的平均时间。CEP技术现已被广泛运用于商业、制造业和金融业等领域,这完全得益于其对事件的描述机制,它可以针对不同的应用场景业务做出相对应的描述,完整地将事件之间的逻辑关系抽象出来,进一步根据用户定义的条件规则过滤和聚合出所需要的高级事件,从而从众多的基础数据中抽取出用户所需的数据信息。

近年来,关于对复杂事件处理的研究和应用有许多,例如黄毅、郑力等人根据企业的生产情况,结合RFID技术,将复杂事件处理技术运用到生产的实时监控上[1];李想、王建仑等人将复杂事件处理技术同物联网相结合,面向农田事件建立时空事件模型[2];而戚湧、胡军等人则根据RFID数据的特点,提出了针对RFID数据处理的事件模式匹配方法[3]李想、高红菊等人根据物联网的现状特点,提出了针对物联网的实时复杂事件引擎[4]。

本文结合现有的CEP技术,根据制造业生产场景的质量成本控制问题,提出了应用CEP技术解决该问题的方法,并做出相应的应用分析。

2 复杂事件处理技术

复杂事件处理,简称CEP技术,其最早是由史丹佛大学的David Luckham与Brian Fraseca在20世纪90年代初所提出的[5]。CEP技术是目前最为主流的事件处理技术之一,其最大的作用是能从一堆繁琐复杂的事件中根据用户的要求提取出所需的有价值的信息,这得益于CEP技术是在主动数据库的基础上发展而来。

定义1:简单事件。可表示为E=(ID,Attrs,Time),其中,ID是事件的唯一标识,Attrs则代表该事件的相关属性,通常表示为Attrs(A1,A2,…,An),而Time则表示该事件发生的瞬时时间。

定义2:复杂事件。可表示为CE=(Es,Rule,[T1,T2]),其中,Es表示所包含的众多简单事件,Rule表示对简单事件过滤聚合等规则,[T1,T2]表示该复杂事件发生的时间跨度。

定义3:事件表达式。具体如下。

包含事件源、模式、其他约束条件、时间约束和返回事件等。

定义4:事件运算符。[∧,|,V,。1,<],分别表示事件共同、选择、合并、否定和顺序发生等关系。

3 基于复杂事件的质量成本处理框架

3.1 场景描述

制造企业在产品生产过程中会涉及到车间流水线场景,每个产品在生产之前都会有预防成本的投入,这部分成本的投入旨在产品生产前预防不合格品产生以及避免不必要的故障发生。一般包含质量保证计划制定、员工岗前培训、产品改进措施、新产品的评估鉴定费用以及质检人员相关工资等一系列费用。在投入预防成本之后,在生产线加工产品的过程中,会产生一些损失费用,这部分费用被称为损失费用,主要包括不合格品的损失、返修品的损失等费用。最后涉及到的是鉴定成本,这部分费用是鉴定产品是否符合规定质量水平所花费的,包括工序检验、成品检验和质量审核所产生的费用。

3.2 处理框架

根据CEP技术,面向制造业的质量成本处理框架如图1所示:

该处理框架涉及到了事件源、事件预处理、事件缓存、复杂事件处理、事件查询/反馈、应用、规则库等模块部分。

(1)事件源部分主要是与质量成本相关数据来源部分,包括了生产线上会产生相关数据的众多设备,如RFID读取设备、手持机和传感器等。

(2)事件预处理模块则用于检测规则库定义的事件,同时对收集到的不同格式的数据进行统一的格式处理。

(3)事件缓存模块则是控制相应事件上传到复杂事件处理模块的速度,根据处理模块的处理速度做出相应的调整。

(4)事件查询和反馈模块则用于传递经过处理模块处理后的用户查询信息以及接收用户的信息查询请求。

(5)最上层应用模块则是用户操作模块,包含查询和接收结果的不同应用程序。

(6)规则库则是根据用户查询的事件,生成相应规则传递到相应的模块部分。

4 应用分析

结合以上的处理框架,本文选用一款开源的复杂事件处理引擎Esper进行相应的应用分析,其提供的类SQL的查询语言EPL (Event Process-Language)可以方便地用来作为事件描述语言来描述事件关系[6],系统环境为:Windows 7,IDE为Eclipse 4.5.0版本,Esper复杂事件处理引擎的版本为5.5.0。部分质量成本数据如表1所示,其中包含总质量成本、预防成本、损失成本和合格率等数据。

(1)每隔2小时,扫描预防成本大于1.1时的产品合格率。用Esper的EPL语言描述为:

SELECT YIELD FROM pattern[every(Pcost>1.1)]->timer:interval(2 hour)。

(2)每隔2小时,扫描预防成本在1.1和1.2之间,并且损失成本在1.1和1.2之间时的合格率。用Esper的EPL语言描述为:

SELECT YIELD FROM pattern[every(1.1<Pcost<1.2 and1.1<Lcost)<1.2]->timer:interval(2 hour);

(3)当连续3个预防成本和损失成本平均值分别大于1.2和1.3时,输出相应数据,输出结果如图2所示。用Esper的EPL语言描述为:

select*from pattern.[having avg(Pcost)>1.2 andavg(Lcost)>1.3]->win:length(3);

5 结语

通过结合复杂事件处理技术,将该技术引入到质量成本的控制中,可以有效为企业提供产品质量改善指导,提高企业效益。同时,结合已较为成熟的CEP技术,根据企业的生产场景,建立面向制造业的质量成本的复杂事件处理框架,可以更加有目的和效率地对企业的生产工序进行检测与分析。本文在提出此框架的基础上,结合复杂事件处理引擎Esper进行了相关的应用实验。总之,引入复杂事件处理到质量成本的控制中,能更为高效地改善企业生产质量和收入效益问题。

参考文献

[1]黄毅,郑力,向晴.基于复杂事件处理的RFID辅助实时生产监控[J].清华大学学报(自然科学版),2013(5):721-728.

[2]李想,王建仑,高红菊.面向农田物联网复杂事件处理的时空事件模型[J].农业机械学报,2015(s1).

[3]戚湧,胡军,李千目.面向RFID数据处理的复杂事件模式匹配方法[J].计算机科学,2013,40(1):73-76.

[4]李想,高红菊,乔颖,等.面向物联网的实时复杂事件处理引擎[J].小型微型计算机系统,2015,36(9):2047-2053.

[5]李幸斌.制造物联网中分布式复杂事件处理研究[D].广州:广东工业大学,2015.

复杂事件处理篇5

复杂事件处理 (CEP) 技术被用于从大量低层次事件 (原子事件) 中按照一定模式在截止期内匹配得出高层次事件 (复杂事件) [1,2]。实时CEP技术能满足图书馆无线网络监控的需求。主要是由于CEP技术的复杂事件模式描述语言能够描述复杂情景[3], 同时支持重配置复杂事件模式, 以及近年来CEP的快速发展, 包括高性能的复杂事件处理技术[4]和实时CEP系统框架等。因此, 本文拟构建基于CEP的图书馆无线网络监控系统, 以具备实时性和数据查询能力, 使用无线传感器网络监控图书馆环境状态, 实时CEP引擎根据预定义的复杂事件模式实时检测复杂事件, 为异常情况作出正确的反馈。

1 网络监控系统框架

本图书馆网络监控系统如图1所示, 由无线传输网络、原子事件抽取器、CEP引擎以及动作执行器四个部分构成。

无线传输网络主要是监控图书馆的温度、湿度等环境状态以及火焰情况。所有数据均由无线传感器网络中间层收集处理, 形成数据流并打包输出到原子事件抽取器中。由于图书馆面积较大, 楼层较多, 采用无线传感器发挥了其无布线和易于灵活布置的优点。

原子事件抽取器主要通过对无线传输的数据流进行筛选整理, 抽取已经发生的原子事件来构成原子事件流, 并打包输送到实时CEP引擎中。

实时CEP引擎主要承担根据预设值的复杂事件模式从原子事件流中检测出复杂事件。其中, 原子事件存储内有原子事件流, 复杂事件模式库储存有以中间语言描述的复杂事件模式, 检测模块负责检测复杂事件, 检测到的复杂事件被置于复杂事件存储中, 并打包输送到动作执行器中。

动作执行器根据检测到的复杂事件内容, 可选择声音报警、开启灭火装置、开启空气调节装置及开启排泄装置。

本系统的复杂事件处理描述语言支持各种逻辑操作符, 利用操作符的嵌套, 可对复杂情景进行描述;本系统具有较高的灵活性, 可进行监控内容的调整和修改。

2 关键技术

2.1 复杂事件处理流程

复杂事件处理 (CEP) 的目标就是从软件系统应用各个层次的事件流中, 获取其中所包含的信息, 理解其对上层管理目标和业务过程的影响, 并做出实时的反应。复杂事件处理流程依次为事件生产、事件通道、事件处理以及事件动作的驱动。

事件生成:每一个事件都是由事件源生成的。这个源可能是一个程序、数据存储、服务、业务过程、发射器、传感器, 或者合作工具 (及时消息软件、电子邮件) 。

事件通道:一般是传输消息的主干, 在事件生成、事件处理和下游的订阅者间传输标准格式化的事件。

事件处理:在事件处理层收到一个事件后, 会根据事件处理规则对这个事件进行评估, 再触发相应动作。事件处理的规则和相应动作是根据事件消费者的兴趣和需求来制定的, 而不是取决于事件生产者。事件由引擎来处理, 复杂的事件处理引擎在处理一个事件的发生时, 会结合其之前已发生或之后将要发生的事件上下文来处理。

事件驱动的动作:一个事件可能会引起在下游的若干个动作发生。一个动作可能由事件处理引擎来直接触发 (启动服务、业务过程触发、通知等等) , 或者由事件的订阅者来发起。订阅者可能是人、应用程序、活动的业务过程等等。事件必须以标准格式发布, 而一般由企业集成主干系统负责将事件或动作触发信息转换成订阅者所需要的格式。

2.2 复杂事件处理模块

CEP工程的EPN (Event Process Network) 如图2所示。该EPN图包括五个模块:事件源模块 (helloworld Adapter) 、事件通道 (helloworld Input Channel和helloworld Output Channel) 、事件处理模块 (helloworld Processor) 、事件输出模块 (helloworld Bean) 。待处理的数据被包装成事件, 从事件源出发, 经事件处理模块处理后由事件输出模块输出。

事件源模块:事件源模块主要负责把数据转换为CEP工程可以理解的格式, 然后输入给事件处理模块。CEP支持多种多样的Adapter:JMS Adapter、HTTP Publish-Subscribe Server Adapter、Custom Adapter、High Available Adapter。通过这些Adapter, CEP能够轻松的读取数据库、EXCEL文档、网络数据流等多种形式的数据。例如, 可以将Adapter配置如下:

此时, Adapter就是一个Java Bean文件 (com.bea.wlevs.adapter.example.helloworld.Hello World-Adapter) , 在该Bean文件中, 可以通过如下代码读取到一个Excel文档中的数据:

通过配置不同的Adapter, 可以读取各种各样的数据源。

事件通道:它的作用很多, 如事件缓冲, 并发查询控制。另外, 实际的CEP工程并不会像图1所示的那样简单, 更多的CEP工程会相当复杂, 有多个事件处理模块, 对事件流进行多步处理, 产生多个事件输出流。事件输入流经过事件处理模块处理后可能产生多条事件输出流, 这时候就需要用通道区分相应的事件流。

事件处理模块:它是CEP的关键部分, 用于处理事件流, 主要用到CQL (Complex Query Language) 语言。CQL语言是一种基于SQL的查询语言, 但是在SQL中加入了用于数据流处理的部分, 因此适合用于CEP的事件流处理。通过CQL语言, 可以轻松的对一个或多个事件流进行复杂的处理并提供一个或多个事件输出流。下面的代码就是一个简单的事件处理模块配置代码:

事件输出模块:主要用于事件流的输出, 把处理后的数据呈现出来。可以把数据保存到数据库、文件或者以界面形式提供给CEP的使用者。

3 系统应用研究

3.1 系统应用环境

本系统拟采用美国Crossbow Technology公司生产的无线传感器网络套件进行数据测量, 包括空气的温度、湿度以及火焰传感器。在Eclipse开发环境下采用Java编程语言实现其他工具。所有工具均在Windows7操作系统下。

3.2 系统情景分析

情景一:电线短路或人为因素着火。火焰传感器把捕捉到的火焰亮度转化为电平信号输入中央处理器, 进行无线网络发送和CEP引擎处理, 发出声音警报, 开启灭火装置, 并切断图书馆电源。

情景二:图书馆内漏水。图书馆内漏水主要为水管漏水、楼板顶层漏水和窗户漏水, 当水都一定高度, 漏水传送器将及时发送信号和声音警报, 并开启排泄装置, 提醒工作人员进行检修。

情景三:图书馆内湿度过大。在空气湿度较大的季节里, 当库房内空气相对含湿量超过a%时, 湿度传感器将信号传递给CEP引擎处理, 开启空气调节设备 (主要为抽湿机) , 当相变含湿量低于b%时, 停止空气调节设备, 这里a大于b。

4 总结

当前我国图书馆的监控系统不能完全市场满足需求, 本文基于复杂事件处理 (CEP) 技术实现了一个针对图书馆无线网络监控系统, 建立了系统的框架流程, 通过无线传感器网络监控图书馆环境事件, 根据预设置的复杂事件模式实时检测复杂事件并执行动作。该系统将在图书馆实时监控中得到广泛的应用, 具有很好的应用前景。

参考文献

[1]李想, 范玉顺, 乔颖, 等.基于实时复杂事件处理的智能家居监控系统[J].计算机研究与发展, 2012, 49 (增刊) :372-376.

[2]Luckham D.C.The power of events:An introduction to complex event processing in distributed enterprise systems[M].Boston:Addision-Wesley Longman Publishing Co.lnc, 2001.

[3]Qiao Ying, Zhong Kang, Wang Hongan, et al.Developing event-condition-action rules in real-time active database[A].Proc of ACM Symp on Applied Computing[C].New York:ACM, 2007:511-516.

复杂事件处理篇6

电力系统互联规模的扩大和运行复杂性的增加，给电网故障的诊断增加了难度。目前投入实际应用较多的电网故障诊断方法主要包括基于专家系统[1,2]的方法和基于解析模型[3,4]的方法。此外，基于人工神经网络[5,6]、粗糙集[7]、模糊理论[8,9]的电网故障诊断方法以及其他一些新方法[10,11]也受到了广泛关注。这些方法大都利用断路器动作信息和保护动作信息作为诊断的基础，但由于保护和断路器存在拒动和误动以及故障信息存在时序畸变或传输丢失等诸多不确定因素，电网故障诊断系统的决策判断受到了影响。

故障诊断是一个逻辑过程，可以从事件处理的本质层面进行研究。复杂事件处理技术是一套理解和控制事件驱动型信息系统的方法，其特点是通过事件之间普遍存在且最为重要的时间、因果及聚合关系对事件进行关联和整合。目前电力领域在该方向上开展了一些类似研究，文献[12,13]分别从信息论和事件角度对故障诊断和事件建模及分析进行了探讨，文献[14]针对故障信息处理中“数据过剩而信息不足”的现状，提出了基于复杂事件处理技术的故障信息分层处理模型。

本文提出了基于复杂事件处理技术的故障诊断方法，将复杂事件处理技术应用于电力系统的故障诊断研究。该方法以保护动作信息和断路器动作信息为数据基础，结合保护、断路器的动作逻辑和电网故障诊断的实际情况，关联和聚类故障信息，做出故障诊断决策。同时，针对以往的故障诊断方法只利用保护和断路器动作信息而忽略电气量信息，导致诊断结果相对片面的问题，从故障录波器信息中提取了故障特征量，对故障诊断决策做出了评价和补充。

1 复杂事件处理技术

复杂事件处理技术是一套理解和控制事件驱动型信息系统的方法，起源于1990—2000年之间斯坦福大学一项名为RAPIDE的仿真研究项目，其核心在于把整个系统分层分级，通过事件之间的时间和因果等普遍存在的关系对事件进行关联和聚类，将低层次的简单事件聚合成高层次的复杂事件。

复杂事件的定义为：“事件是用于系统记录活动的对象”。一个事件含有3个特性：事件形式（form)、事件含义（significance)和事件关联性（relativity)。其中，事件形式是指对象，其包含特定的属性或数据分量；事件含义表征了活动；事件关联性是指事件之间通过时间、因果和聚合性相互关联，而事件与其他事件之间的相互关系称为关联性。

事件与事件之间的关联性包括3种关系：时间、因果、聚合关系。时间关系表述事件与事件之间的排序；因果关系表述事件与事件之间的起因与结果；对于聚合关系，假设事件A所表述的活动由一组事件B、C、D所表述的活动组成，则称A事件是B、C、D事件的聚合事件，也称为复杂事件。

由上述叙述可以看出，利用事件之间的时间、因果、聚合关系，复杂事件处理技术可以建立事件之类的联系，把简单事件聚合为复杂事件，为事件驱动型信息系统提供了一个新的事件处理维度和系统化的处理手段。

2 基于复杂事件处理技术的电网故障诊断方法

2.1 故障诊断的数据基础

本文提出的故障诊断方法主要涉及到保护动作信息、断路器动作信息和故障录波器信息。

1）保护动作信息：从SCADA系统获取，主要包括保护的动作情况以及保护动作的时间等信息。

2）断路器动作信息：从SCADA系统获取，主要包括断路器的动作情况以及断路器动作的时间等信息。

3）故障录波器信息：从保护故障信息管理系统获取，主要包括系统节点电压、支路电流以及可以由其导出的有功、无功等信息。

SCADA系统获取的保护动作信息和断路器动作信息主要用于故障元件的判断决策；故障录波器信息用于详细故障诊断，包括对故障决策的评价或补充。

2.2 基于复杂事件处理技术的故障信息关联和聚合

2.2.1 故障信息关联

需要关联的故障信息主要包括保护动作信息和断路器动作信息。故障信息的关联分为2个步骤：第1步是对故障信息进行解析；第2步是根据保护和断路器动作的逻辑，挖掘故障信息之间的联系，形成故障信息之间的关联关系。

2.2.1. 1 故障信息的解析

由于电网调度自动化系统中故障信息的格式存在一定的规律，因此在文献[15]的基础上，将每条故障信息按照以下七元组进行表示：

式中，E表示某条故障信息；S表示该故障信息发生的场景，一般指某个变电站；D表示该遥信信息代表的设备；V表示该设备的电压等级；O表示二次设备，包括保护类和断路器类设备；A为保护类二次设备的动作属性，包括I段、II段等信息；B为保护和断路器的动作行为，包括动作、跳闸等；T表示该故障信息发生的时间。

利用文献[15]中的关键字符串匹配算法，把故障信息和调度自动化平台里的预设模板进行匹配，得到故障信息中场景、设备等关键字符串。遥信信息匹配流程如图1所示。

2.2.1. 2 故障信息的关联

根据保护和断路器动作的逻辑建立故障信息之间的关联关系。定义ATT(ei)为保护动作信息ei中属性A的值，如果ei是主保护动作事件，则ATT(ei)=1；如果ei是近后备保护动作事件，ATT(ei)=2；当ATT(ei)=0时，表示ei为断路器动作信息。

1）主保护。如果主保护动作，则主保护对应的断路器应该在规定的时间内动作。假设在告警信息ei中ATT(ei)=1,ck是ei对应的动作断路器，则可以构成以下关联关系：

式中，ck可以通过接线分析和拓扑分析得到；0.15 s为保护动作后断路器动作的最长时间。该关联关系表示：当主保护ei动作时，断路器ck在0.15 s内动作。

2）近后备保护。如果近后备保护所保护的设备故障且主保护拒动，则近后备保护动作。近后备保护动作后，对应的断路器在规定的时间内动作。假设有故障信息ei和ej，其中si=sj,di=dj,vi=vj,oi=oj,ATT(ei)–ATT(ej)=1,ATT(ej)=1,ej是设备dj的主保护，ei是设备di的近后备保护，则可以构成关联关系(3）和（4):

式中，表示故障信息ej未发生；Δt表示在不同电压等级的电力系统中，不同保护配合动作的整定值，如0.3 s、0.5 s、1 s等。

3）远后备保护。如果远后备保护所保护的设备故障，且主保护和近后备保护都拒动，则远后备保护动作。远后备保护动作后，对应的断路器在规定的时间内动作。

在电网故障中，一条短路路径中的2个相邻电气设备在保护动作上存在配合关系。如果一个电气设备di较另一电气设备dj距离短路电源近，则表示di是dj的上级设备。为了表示这种保护动作的配合关系，利用文献[15]中的深度优先搜索算法建立设备之间的关联矩阵。在关联矩阵中，如果aij=1，表示dj为di的上级设备，其后备保护动作与di的保护动作有配合关系；如果aij=0，表示2个设备的保护动作没有配合关系。

假设有故障信息ei和ej，如果表示ei和ej有关联关系，可以构成关联关系（5）和（6):

4）断路器失灵保护。一般来说，在220 kV及以上的电力系统中，为断路器专门装设了失灵保护。断路器失灵保护的动作逻辑是：当指向断路器ck的保护动作而ck没有动作，则ck的断路器失灵保护动作。失灵保护动作时，会跳开与ck相连接的同一母线的所有断路器以及与该母线相连线路另一侧的断路器。

假设有遥信信息ei,oi=“失灵保护”，则存在以下关联关系：

式中，ct是ck与相连接的同一母线的所有断路器以及与该母线相连线路另一侧的断路器。

2.2.2 故障信息聚合

根据电力系统诊断的实际情况进行故障信息的聚合。从我国的统计资料看，继电保护的正确动作率较高[16]，因此按照保护动作信息全部正确的前提进行故障信息的聚合，即：

1）主保护动作，优先推理主保护所保护的设备发生故障；

2）近后备保护发生故障，优先推理近后备保护所保护的设备发生故障，且该设备的主保护拒动；

3）母线失灵保护动作，优先推理与该母线相连的断路器发生拒动。

按照以上所述的聚合规则，符合电力系统故障诊断的实际情况。对故障信息进行关联和聚合之后，删除其中不合逻辑的关联事件，可以得到多个事件链，事件链以某元件故障为起始事件，后续事件为故障信息。如果某条事件链包含较多的故障信息，表示该元件故障的假说符合故障征兆，该元件为可疑的故障元件。

2.3 基于故障录波信息的诊断决策分析

通过对保护信息和断路器信息的关联和聚合，可以做出初步的故障诊断决策。通过提取故障录波信息中的故障特征量，可以对故障诊断决策做出评价，也可以得到关于故障的更加详细的信息，如故障类型和故障相别等。如果在初步的故障诊断决策中得不到唯一的故障元件，也可以通过故障录波信息进行进一步的判断，以得到唯一的故障元件。

2.3.1 故障特征量的提取

故障录波信息是以时域波形的形式进行离散采样记录的，时域信号不适合特征量的分析和处理，因此在提取故障特征量时，需要用傅立叶方法将时域信号进行变换处理，获得频域信息。故障特征量的提取算法通常可以分为以下3类[16,17]:

1）基于正弦信号模型的算法，该算法假设发生故障后电压、电流波形为正弦信号；

2）基于简单非正弦模型的算法，该算法假设故障后电压、电流信号包含基波正弦信号、各种整次谐波、非整次谐波等分量；

3）基于随机函数模型的算法，该算法假设故障信号包含非周期信号以及随机的高频、低频分量。

利用上述算法，可以获得各次谐波分量的幅值和相角信息。此外，还可以进一步分析得到故障方向、故障突变时间、故障相别、故障持续时间等信息[18]。

2.3.2 故障特征量的分析

对保护信息和断路器信息关联和聚合后，如果得到的故障诊断结果只有唯一的故障元件解，那么对故障特征量的分析可以得到更多关于故障的信息，如输电线路的故障相等信息；如果得到的故障诊断结果有多个故障元件解，需要对故障特征量进行分析以删除某些错误的故障元件解，使诊断结果更加精确。例如，通过分析故障后电流的流向和幅值这2个特征量，可以删除某些不正确的诊断结果。

2.4 基于复杂事件技术的电网故障诊断方法流程

结合上文分析，本文基于复杂事件技术的电网故障诊断方法的具体步骤如下：

1）从SCADA系统获得保护动作信息和断路器动作信息；

2）解析故障信息，建立故障信息之间的关联关系；

3）根据聚合原则，得到故障事件链，做出初步的故障诊断决策；

4）如果故障元件唯一，诊断结束，否则从PRMS中提取故障录波信息；

5）提取故障特征量，进行更加详细的故障分析和诊断。

故障诊断流程如图2所示。

3 案例分析

某地区局部电网图如图3所示，其中各线路配置有全线速动保护和断路器失灵保护，母线配置有母线差动保护。本文以一个故障案例来解释所提出方法的有效性。

在本故障中，调度中心收到的故障信息见表所列。

对表1的故障信息进行解析，解析结果见表2所列。

利用拓扑分析和接线分析程序，可以得到保护对应的动作断路器。涉及故障信息中的保护，保护对应的动作断路器见表3所列。

3.1 对故障信息进行关联

对于故障信息e1,ATT(e1)=1，表示e1是主保护，因此有关联关系<e1,C9>和<e1,C10>;

由于故障信息e5中的设备是C9，且e1和e5的发生时间满足时间约束，因此形成关联关系<e1,e5>。同理，可以形成关联关系<e2,e5>,<e3,e5>,<e4,e5>。

e6是失灵保护，因此有关联关系<e6,C6>,<e6,C7>,<e6,C10>,<e6,C21>。

由于故障信息e9中的设备为C6，且e6和e9的发生时间满足时间约束，因此形成关联关系<e6,e9>，同理可以形成关联关系<e6,e7>,<e6,e8>。

3.2 对故障信息的聚合

按照聚合规则，对故障事件对进行聚合，可以得到如下的关联关系：

由于e7和e8中的设备为C21和C7，即C21和C7未拒动，因此最终得到的关联关系为：

根据关联关系可以得到故障事件链如图4所示。

从图4中可以得到，在该故障案例中，除了线路L311故障外，断路器C10也发生了拒动。

4 结语

顶管遇复杂地下管线的处理方案篇7

1 工程概况

广州市国际商品展贸城展贸东南路工程, 污水管网工程与展贸城项目第一期工程连接处, 需要穿越十字交叉路口, 总长度为125m, 在展贸东南转折处路口中间的w39位置设置为接收井, w38和w40均设置为工作井, w38~w39管段长72m, w40~w39管段长度为53m, 分别顶管至w39位置附近发现:管道标高位置, 共遇三条100的PE管, 管内分别有通信光缆和高压电缆;管道上方有二条间距800mm的钢筋混凝土管, 钢筋混凝土管的走向与施工的管道几乎平行。受管道标高的地下管线影响, w39位置两侧的管道顶进还剩余7000mm未能贯通。

由于通信电缆和电力电缆的产权单位不明确, 无法进行拆迁, 只能就地妥善处理。据现场分析判断, 通信电缆和电力电缆的PE管, 穿越交通路口是采用“定向钻牵引”[1]工艺施工的, 其在地下的标高变化比较大, 走向也不太稳定, 给处理带来比较大的不确定性。

2 地质情况

根据现场地质情况, 工作井开挖范围内的土层基本上以淤泥、粘土、中砂与砂质粘土为主, 其岩土的特征如下。

(1) 素填土:灰黄色, 湿, 疏松, 成分主要为由粘性土及植物根系组成、1900mm厚。

(2) 淤泥:深灰色, 饱和, 流塑, 局部软塑, 土质较纯, 断续腐植物、3400mm厚。

(3) 粉质粘土:红色, 可塑, 土质不均匀, 为混合岩风化残积土, 遇水易软化, 2500mm厚;底部0.4米含少量粉砂。

(4) 砂质粘土:褐红黄色, 硬塑, 为混合岩风化残积土, 土质粘性一般, 含2mm~3mm石英砾约<5%, 1200mm。

(5) 中砂:灰黑色;较密;饱和;质较纯, 粒径不匀。

3 处理方案比较选择

结合场地地质的情况、周围环境和地下相关管线情况, 我们比较了以下三种措施 (1) 降低 (2m) 标高避开通信电缆和电缆电缆标高, 重新顶管; (2) 少量降低管道标高, 采用钢板桩支护明挖铺管; (3) 人工挖孔、高压水冲枪射水配合掏土, 手拉葫芦牵引挪开通信电缆和电缆电缆管后继续顶进。

通过比较分析得出以下结论。

措施1, 解决措施简单直观有效, 但是重力流管道变成倒虹管不利于管养、已经顶进的118m管道报废, 造成较大的损失。

措施2, 自来水管和排污管的保护, 困难很大, 钢板桩在通信电缆和电力电缆位置不能够封闭, 受自来水管和排污管的影响, 机械作业难度比较大。

措施3, 解决措施简单经济, 但需要专业高压射水设备、作业过程需小心谨慎。

通过比较, 认为在具备专业高压射水设备的情况下, 措施3比较可行。

4 方案的具体做法

4.1 测量放线

准确测放出两个工具头前端在地面的垂直位置, 进一步探明自来水管和排污管。

4.2 人工挖孔浇注钢筋混凝土护壁

在工具头前端, 从地面垂直各挖设一个内空直径为1200钢筋混凝土护壁井, 护壁一直浇注到工具头顶的位置。

4.3 人工挖土射水冲孔

钢筋混凝土护壁达到75%强度后, 顺着护壁井向下挖土, 暴露出阻碍管道的地下管线;做好排水措施的情况下, 采用高压水冲枪, 顺着通信电缆和电力电缆的PE套管射水, 将PE套管周围的土体冲切成泥浆排出, 使PE套管在护壁井两侧各有3m~4m的自由段。

4.4 射水冲孔与手拉葫芦结合牵移地下管线

在PE套管暴露并且有7m~9m的自由段的情况下, 通过井口安装的扁担, 用手拉葫芦向上进行牵引, 使PE套管产生少量延伸, 同时采用高压水冲枪射水、配合手拉葫芦继续牵引, 如此循环几次, 直到PE套管能够绕开管道位置, 临时固定。

4.5 继续顶管

通信电缆和电缆电缆管的PE套管绕开管道位置、进行临时固定后, 往护壁井内回灌触变泥浆, 防止掏土空洞坍塌;再按照原计划继续顶管到w39接收井, 顶进完毕及时采用水泥石屑密实回填人工挖孔护壁井。

5 高压水冲枪射水的使用情况

高压水冲枪射水是高压清洗车进行射水, 喷嘴口直径为2mm~4mm, 射水压力为0~15MPa, 水平射水距离达10m~20m, 清洗车载水容量为8立方, 喷射时由1个人用手抓住水冲抢, 瞄准喷射位置进行射水, 可以轻轻松松地将粘在混凝土路面或者沥青路面的泥土冲切下来, 实现清洗路面的目的。所以用来冲切地下自然土体掏成一个土洞是非常容易的事情。

我们曾经在同一项目的某段管道顶进时临近接收井5m处, 遇障碍物导致管道突然偏高1200mm, 就是采用高压水冲枪射水, 冲切管道底部的土体, 使管道安全降低到设计高程的使用经验, 效果相当良好。

6 关键技术

(1) 工具头前端位置要测放准确。

(2) 人工挖孔护壁经过管道时要做好保护工作。

(3) 高压水冲枪射水前, 做好井底排水工作, 保证射水工作能够持续进行。

(4) 高压水冲枪射水过程中, 尽量让水柱顺着套管喷射, 防止过分掏土。

(5) 牵引套管要均匀加力, 防止操之过急损伤PE套管和套管内的通信电缆和电缆电缆。

(6) 高压水冲枪射水与牵引套管必须密切配合好, 这样既有利于牵引效果良好, 又有利于防止过分掏土。

(7) PE套管被牵移避开管道顶进位置并且临时固定后, 及时往井内回灌泥浆, 防止孔洞坍塌。

(8) 第一段顶进完毕, 马上密实回填护壁井, 减少挖孔对周边土体的扰动, 有利于下一段管道的处理。

7 结语

定向钻牵引工艺施工的PE套管和管内的电力电缆通信电缆均属于柔性管, 有适当的自由段、受到一定拉力的情况下, 能够实现有效的伸缩[2]。