CN103765411A - 数据分析系统 - Google Patents

Abstract

用于分析来自多个设备的数据的数据分析系统具有数据库服务模块，其包括存储从不同的设备收集的数据的数据存储子系统。数据存储在使用基元来对数据分类的元结构中。分析引擎分析数据以根据所存储的一组规则确定由元结构定义的数据是否满足预定标准。系统例如在铁路基础设备中的故障的检测中是有用的。

Description

数据分析系统

技术领域

本发明涉及数据分析的领域，且更具体地涉及对从多个设备收集的数据的分析，这些设备可以是相同的或不同的，例如在铁路基础设施中存在的。

背景技术

铁路基础设施使用很多不同的系统，其中每个系统配置很多不同的设备类型，每种设备类型具有其自己的诊断能力。这些能力是很少相同的，且它们的提供数据的方法甚至更不可能是相同的。然而为了测试、诊断和维修目的，存在收集、比较和关联这个数据的需要。目前使所产生的数据和它被提供的方法协调是不可能或不实际的（由于在每个区域中的不同的导轨布局，区域控制器具有不同的数据集）。

当前的技术例如每个设备类型的独立数据收集太繁重，所以它们将需要一些人力来聚集所有数据用于交叉比较目的。此外，用于网络数据收集的现有解决方案例如SNMP是不实际的，因为a）它对这些设备强加可能不可实现的协议，b）SNMP协议仅基于事件通知，且因此作为数据收集系统是不够的，以及c）它假设产生数据的设备具有到网络和NMS服务器的连接，并不总是这种情况。

甚至SCADA（监督控制和数据获取）也被认为不是实际的解决方案，因为可被产生的数据集可能潜在地使SCADA协议的开销使整个系统变得不可工作。所采纳的当前解决方案具有向中央系统（ATS）报告任何故障的联网设备（VOBC、ZC）。这是不够的，因为只有当前在网络上的那些设备能够传输数据，来自未联网的设备的数据未被解释，且甚至那些设备也产生从测试和诊断观点看是合乎需要的数据。此外，那些联网设备的可靠性要求往往与诊断能力不一致（根据定义增强可靠性的透明投票和数据平滑的概念破坏预测性诊断能力所需的数据）。

发明内容

根据本发明，提供了用于分析来自多个设备的数据的数据分析系统，其包括：数据库服务模块，其包括存储从不同的设备收集的数据的数据存储子系统，且其中数据存储在使用基元来对数据分类的元结构中；以及分析引擎，其用于分析数据以根据所存储的一组规则确定由元结构定义的数据是否满足预定标准。

本发明的基本理念是设计并发展从机制提取数据如何被存储、比较和分析的覆盖系统以及数据从目标设备导出的方式。这允许在收集、存储和分析系统的所有级别处使用的广义数据结构的创建，除了物理地连接到目标设备的层以外。这不同于现有的解决方案的方面是，它不在目标设备上强加任何要求，并允许用户以常见方式处理来自所有设备的所有数据。

该方法因此收集以其“自然”形式的所有诊断数据，并以允许数据的分析和交叉比较的方式将它集合在一起。它还提供了集中式自动存储机制，因为所有设备可散布在很多千米的导轨上。该方法还以一种方式操作以便能够满足所有技术要求，而不影响系统的极重要的或操作方面。

本发明的实施方式允许能够产生诊断数据的任何设备能够被包括在诊断系统中。当解决方案作为覆盖物操作时，它从所产生的数据或机制（数据通过该机制被取回）方面来说不对任何设备类型强加要求。这确保COTS（商用现货）或任何其它部件（其中没有方法来影响设计）可合并在诊断系统中。类似地，它从部件（其设计可被影响）移除了任意要求。在这些情况下需要的是定义什么数据具有诊断值，而不涉及物理或逻辑机制，数据通过该机制从设备导出。可以想象地，本发明可甚至被部署为竞争者的系统上的覆盖层，只要所产生的数据的类型和机制（它通过该机制是可访问的）是已知的。

因为本发明没有做出关于数据率的假设，也不强加任何最低要求，它也可部署在任何系统中并适合于系统的约束（例如，数据收集率可被调谐以允许在具有非常小的可用带宽的系统中的操作）。本发明将继续在这些条件中工作，虽然所收集的数据的值可降低。

在另一方面中，本发明提供了分析来自多个设备的数据的方法，其包括：在正在进行的基础上收集来自不同设备的数据；将所收集的数据以使用基元来对数据分类的元结构存储在数据库服务模块的数据存储子系统中；以及分析数据以根据所存储的一组规则来确定由元结构定义的数据是否满足预定标准。

附图说明

现在将参考附图仅作为例子更详细地描述本发明，其中：

图1是根据本发明的一个实施方式的数据分析系统的概述图；

图2是数据库服务模块的方框图；

图3是分析引擎的方框图；

图4是数据收集器的方框图；

图5是在较低提取级别处的系统的方框图；

图6是示出规则同步的图示；

图7是示出数据/观察器/分析器逻辑的图示；

图8是示出数据分析过程的图示；以及

图9是示出数据收集服务的图示。

具体实施方式

参考图1，数据分析系统将首先在顶部提取级别处被描述。数据分析系统包括数据库服务模块10。这个部件充当中央数据仓库，并负责应用于所有数据的元结构的定义，其允许数据以常见方式被处理。本发明的实施方式可具有一个或多个数据库服务，且每个数据库服务将是活动的，使得任何其它部件可与任何部署的数据库服务通信。

分析引擎11负责由数据库服务10所存储的数据的关联和比较，并充当解决方案的诊断部件。这个部件定义控制数据是“好”还是“坏”的规则的结构以及当“坏”数据被检测到时采取的行动（如果有的话）。在该实施方式中，规则由数据库服务存储，虽然这不是要求。然而，以这种方式实现规则存储被认为是好的实践，因为它提供规则数据的单个仓库，因为解决方案的部署可具有零个或更多分析引擎。

数据收集器12负责从目标设备收集数据并将该数据转换成数据库服务所使用的元结构。在本发明的实施方式中，一个或多个数据收集器且每个数据收集器可负责从一个或多个设备或设备类型收集数据。

工作站13负责解决方案的用户界面，并允许用户观看被收集的数据以及允许用户分析该数据。工作站还能够观看、创建、修改或删除规则。本发明的实施方式可具有零个或多个工作站。

在整个解决方案中，所有数据的元结构被使用。这个结构允许不同的数据性质相同，使得它可被存储并以内聚的方式被使用，而不考虑原始数据的形式或源。这个元结构使用下面的基元来对数据分类：

●设备类型：设备类型是一系列数据的源的数据收集器定义的分类。例如，网络开关或计算机可每个为设备类型。设备类型与定义它们的数据收集器相关。

●设备实例：每个设备类型可具有一个或多个设备实例。设备实例仅仅是数据可从其收集的设备类型的实例。例如，如果“网络开关”的设备类型被定义，则该设备类型可具有设备实例“开关1”、“开关2”等。

●数据类型：数据类型是给定的设备类型的数据点的定义。设备类型可具有被定义的多个数据类型，且然后对于该设备类型的每个设备实例，相应于该设备类型的所定义的数据类型的数据将从那些设备实例中的每个收集。当定义数据类型时，也可定义每个数据类型的数据的实际类型。例如，设备类型“网络开关”的数据类型“活动状态”可被定义为整数，而同一设备类型的数据类型“版本”可被定义为字符串。本发明不对数据类型可采用的数据的类型强加限制，虽然实际上一系列类型可被强加。例如，为了从部署在铁路发信号装置中的设备收集数据，将数据类型的类型限制到整数、单点精度浮点数或具有最大长度100个字符的字符串就足够了。其它实现因素例如数据存储解决方案的类型可强加额外的限制。例如，如果商业SQL数据库用作数据存储机制，则可允许的数据类型的列表可由该SQL数据库所支持的基元限制。

数据库服务10在图2中更详细地被示出，并只负责从数据收集器12接收的数据的接收和基于上面定义的元结构来对该数据的存储和分类的功能。虽然将描述示例性机制（这些功能通过这些机制传送），但在本领域中的技术人员的能力内的其它机制可被使用。

数据库服务10包括数据收集器接口20，其负责与提供待存储的数据的数据收集器12通信。该数据收集器接口20负责维持与数据收集器12的通信，并接收和处理它们所收集的数据。该接口20还负责允许数据收集器12定义并管理设备类型、设备实例和那些数据收集器12所负责的数据类型。数据收集器接口20然后负责将接收到的所有数据传递到数据管理过程21，其中数据可接着存储在包括存储器24的数据存储系统23中。

类似地，如果所收集的数据收集器12修改它收集的数据的元结构，则这些修改由数据收集器接口20传递到数据管理过程21，使得数据管理过程21（如果必要）可更新它将数据存储在数据存储系统22中的方式。

数据收集器接口20还负责从数据管理过程21接收立即响应式数据收集的通知。如果这样的通知被接收到，则数据收集器接口20将这个请求转送到数据收集器12用于处理。

数据收集器接口20可预先处理从数据收集器12接收的数据或仅仅将数据传递到数据管理过程21。仅仅传递数据是有利的，因为这集中在数据管理过程21中处理的所有数据，这可帮助本发明的维护和发展。

类似地，存在的多个数据收集器接口20是实现定义的。系统可构造成使得存在由所有数据收集器12使用的一个数据收集器接口20，虽然优选实现具有负责与数据库服务10通信的每个数据收集器12的单个数据收集器接口20。

工作站接口25负责与工作站13通信以提供由工作站使用的数据以及提供接口来取回并修改规则。工作站接口25由工作站13使用来接收什么数据被数据库服务10存储的状态以及下载数据用于本地使用。此外，工作站接口也由工作站使用来取回由数据库服务存储的规则的列表以及创建新规则或删除或修改现有的规则。在工作站直接从数据收集器收集数据的情况下，工作站接口25还允许工作站13存储数据。如果数据被传输到工作站接口25用于存储，工作站接口25将该数据传递到数据管理过程21，使得它可被处理，就好像数据由数据收集器接口20接收到一样。

类似于数据收集器接口20，工作站接口25充当数据管理过程21的网关，且可应用于数据收集器接口20的所有实现考虑因素也应用于工作站接口25。

分析引擎接口26负责与分析引擎11通信以提供由分析引擎11使用的数据和规则。分析引擎接口26经由数据管理过程21向所连接的分析引擎11仅提供由分析引擎11请求的任何数据和规则用于其自己的处理。如果被请求，分析引擎接口26还可提供什么数据和规则是可用的列表。分析引擎接口26还负责从分析引擎11接收对立即响应式数据收集的任何请求。如果立即响应式数据收集请求对特定的设备类型和设备实例被接收，则分析引擎接口26负责将该通知传递到数据管理过程21，使得它可被传输到适当的数据收集器接口20。

类似于数据收集器接口，分析引擎接口充当到数据管理过程的网关，且可应用于数据收集器接口的所有实现考虑因素也应用于分析引擎接口。

数据管理过程21负责向数据库服务10的其它部件提供数据存储子系统24的提取并管理数据存储子系统22的实际实现。数据管理过程21负责构造数据存储子系统22以允许基于本发明所强加的元结构容易访问和存储数据。这个结构化是由数据存储子系统22物理地还是逻辑地完成或由数据管理过程仅仅逻辑地完成是设计选择的问题，只要数据管理过程21的所有用户都经由元结构访问和参考所有数据。

相同的条件应用于规则的存储和访问。规则存在并可确定由元结构定义的数据是“好的”还是“坏的”。作为结果，机制（规则通过该机制被存储和参考）是选择的问题，虽然良好的实现将指定数据管理过程21负责存储并提供对规则的访问，以及规则存储在数据存储子系统22中。

数据存储子系统22可以是由数据管理过程21提取的任何类型的物理数据存储和取回系统。数据存储系统的例子可以是从SQL数据库到简单的平面数据文件或平面数据文件的系列的任何东西。数据存储子系统22的实际实现在本发明的范围之外，但下文应在选择解决方案时被考虑：

a）数据存储子系统22应确保快速的写时间，因为可设想大量数据可被传输到数据库服务10用于以非常快的速率存储。写时间应大于数据被收集的速率，或某种高速缓存存储器和闪存系统应被使用。

b）数据存储子系统22应允许对数据的随机访问。因为数据的多个接收器（工作站和/或分析引擎）可以同时请求大量不同的数据，数据存储系统应允许这以对系统性能的最低影响而出现。

c）数据存储子系统22应提供某种形式的冗余以在故障的情况下确保数据整体性和系统可靠性。

d）数据存储子系统22应允许多个同时的访问。因为部署可具有多于一个数据库服务，数据存储子系统22应允许数据库服务的所有实例访问单个数据仓库。数据库存储子系统也应实现机制以确保多个访问不破坏数据整体性。

用于数据库服务10和数据收集器12、工作站13和分析引擎11之间的通信的协议的实现应满足下列条件：

a）协议应是定向成使得数据库服务10和另一方都可确定连接是否失去的连接，即使数据未主动被传输。这应完成来允许故障处理，并确保被传输的数据不失去，错误地假设存在接收数据的接收器。

b）公共协议应用于所有接口。虽然不是本发明的要求，但这使发展、调试和维护容易。

c）协议应具有低开销并能够以比数据被收集时的速率大的速率传输和接收传输的确认。

d）协议应传输数据，以便最小化数据服务10在解析接收到的数据时所需的转换的量。因为数据库服务10可以想得到地同时将大量数据发送到多个源并从多个源接收大量数据，限制数据库服务10对每个消息所需的处理的量是有利的。

在图3中更详细示出的分析引擎11负责分析数据库服务10所存储的数据并确定数据是“好的”还是“坏的”。在“坏”数据被检测到的情况下，分析引擎11负责触发响应行动。数据如何被分析、“好的”或“坏的”确定如何被做出以及作为“坏”数据的结果什么行动（如果有的话）被采取的实际机制不是本发明的范围。

数据库服务接口30负责通过数据库服务10的分析引擎接口26与数据库服务10通信。作为结果，对这个部件的所有功能和实现考虑因素与对数据库服务10的分析引擎接口26的相同。从分析引擎观点看，这个部件负责提取分析引擎的数据源，使得存储在数据库服务10上的所有数据可被处理，好像它存在于本地一样。对于分析引擎11的其余部件，数据库服务接口30应表现为数据本身。因为本发明的实施方式可具有多个数据库服务部署，这个部件负责确定数据库服务10的哪个特定实例连接到并且在当前数据库服务不可用的情况下还负责连接到任何其它可用的数据库服务10。

这个数据库服务接口30还负责分析引擎11使用的规则的“存储”。如上面详述的，优选实现是使规则存储在数据库服务10中，在这种情况下这个部件将仅提取数据库服务10的接口以取回规则。在规则与分析引擎11一起存储在本地的情况下，则这个部件，作为其充当数据源的提取的责任的部分，也将充当规则本身的存储位置。以这种方式，不考虑对规则存储选择的实现，对于分析引擎11的其余部件，取回规则的接口保持不变。

分析引擎管理器31负责协调由分析引擎11的当前实例采取的行动。分析引擎管理器31负责确定什么规则将运行，以什么顺序，和对照什么设备类型或设备实例，以及那些规则被处理时的频率。规则的实际结构和能力是实现定义的，但这样的规则应存在、是可执行的、并能够确定数据是“好的”还是“坏的”。

分析引擎管理器31允许规则处理的多个“队列”存在，且对于每个“队列”，分析队列32将被创建以处理该“队列”。例如，分析管理器31可创建分析队列32以每30分钟处理一次使设备类型“网络开关”运行的所有规则，并同时具有每100毫秒运行规则“紧急制动故障检测”的另一分析队列32。

没有限制被强加在可存在的分析队列32或能力的数量上，每个能力在顶级处（即，分析队列是否只被分配“类”或规则，或如果单个规则可被分配给分析队列，或如果分析队列可被分配特定设备实例或设备类型的所有规则，等等）。分析引擎管理器31应将责任分配给分析对列，以及分析引擎管理器可管理一个或多个分析队列。本发明还允许但不需要多个分析队列32，且其被分派的任务可动态地被分配和改变。

分析引擎管理器31将任务分配给分析队列的方式被考虑为实现细节。例如，定义多个分析队列及其任务的配置文件是否被使用，或如果用户输入通过图形用户接口被要求，则实际机制（通过该机制对分配队列进行分配）是实现定义的。

分析队列32负责处理通过分析引擎管理器31分配给它的规则。分析队列32还负责在“坏”数据被检测到时采取行动。所采取的实际行动被考虑为实现定义的，且应由规则定义，但系统应允许下面的功能：

a）分析队列32应向分析管理器通知故障和所有可得到的细微问题，使得它可通过数据库服务接口登录到数据库服务。

b）可定义多个级别的行动。例如一些故障可触发“警告”条件，其使否则将不被正常处理的某些规则被处理（以这种方式，规则的正常处理可出现在较高的级别，且然后只有在某些情况下特定的数据点将被检查以找出问题的确切原因），而其它故障可触发“警报”。

c）分析队列32可通知分析引擎管理器以实现立即响应式数据收集。分析引擎管理器通过数据库服务接口将这个通知转发到数据库服务。以这种方式，分析队列可使用比可能当前可用的更多的最新数据来继续处理可疑的规则。

d）分析队列32可暂时增加其分配的处理频率。例如，如果边界条件被检测到，则分析队列可触发立即响应式数据收集，并以比所分配的更高的速率处理可疑的规则以查看实际故障是否出现，一旦边界条件不再存在或如果某个时间限制到期，处理就默认回到所分配的频率。注意，时间限制的到期本身可使用其自己定义的行动被解释为故障。

e）分析队列32可通过外部接口产生对外部接口的警报。例如，在铁路发信号系统中，当故障被检测到或到维护人员的电子邮件可产生时，分析队列可触发对中心控制中心的警报。

外部接口33是实现定义的。它们通过分析引擎管理器31和分析队列32允许与外部系统的通信。通信的机制及其确切的目的是实现定义的，但例子包括将警报转发到外部系统，产生消息来触发维护行动，取回额外的信息（虽然这个用途是可能的，但它是令人沮丧的，因为具有诊断值的任何数据应由数据收集器而不是直接由分析引擎收集），对外部系统的通知、解决方案的所有部件和在分析引擎11的多个实例之间的协调起作用（“心跳”消息）。

如上所述，解决方案的部署可具有被部署的分析引擎11的多个实例，且解决方案允许每个实例独立地工作。使分析引擎11的所有实例协调其成果在某些实现中可能是有利的，且因此本发明允许这，但将它处理为外部接口，因为本发明不需要这个功能。

在图4中更详细示出的数据收集器12负责收集来自数据源的数据并将它传递到数据库服务10用于存储和进一步分析。这个部件负责理解被收集的数据的固有格式和收集该数据的物理方法。

数据收集器12包括用于通过接口连接到数据库10的数据库服务接口40、用于通过接口连接到各种设备的设备接口41、用于在转发到数据库服务模块10之前对数据分级的数据分级模块42和用于管理来自各种设备的数据的集合并转发到数据库服务模块10的数据收集管理器。

工作站13代表最终用户接口。作为用户接口，工作站13的绝大部分功能是实现定义的，且实际上本发明不对工作站强加结构，除了上面列出的那些约束以外。应在工作站13中实现的功能包括允许用户观察由数据库服务存储的数据，允许用户观察、修改、创建或删除由分析引擎使用的规则，并允许用户对照由数据库服务存储的数据来运行规则。被处理的这些规则的结果是否产生警报是实现特定的，虽然有使结果不被报告的优点。以这种方式，用户可对照活数据“测试”新规则。

工作站应合并额外的维护特征。虽然这些特征从部署观点看不是解决方案的部分，有用于所有维护操作的集中式工具是有利的。

工作站也应利用用于执行所有功能的用户登录和访问级别。这是确保虽然工作站可用于执行功能例如修改规则的中央集合，这个能力应仅扩展到某些用户。

最后，工作站应支持直接从目标收集数据并将该数据转发到数据服务的能力，好像它从数据收集器到达一样。对于此的原因是确保该数据可被收集并在数据收集器可能不再自动从目标收集数据的情况下被分析。

在图5中示出软件部件的更详细的视图。数据收集服务12用于从被监控的设备取回数据，格式化数据，并将数据存储在诊断数据库服务中。可能有任何数量的数据收集器服务存在，且每个数据收集器服务可从任何数量的设备收集数据。每个数据收集器服务将安装在诊断服务器上，虽然多个数据收集器可安装在同一诊断服务器上。

这些数据收集器服务12将采取与其许可一起运行的操作系统服务的形式。每个数据收集器服务将实现并支持下面的部件：目标数据收集过程62、数据库服务器接口60和立即响应式数据收集过程59。

数据收集过程负责从被监控的设备接收数据并将该数据放置在数据收集器服务特定的本地存储器中。这个部件的责任是知道如何与目标设备通信并从它/它们取回诊断信息。例如，对此的数据收集过程可采取SNMP服务器的形式并使用SNMP协议从路由器和AP接收诊断信息。

根据被监控的设备类型，数据收集过程可能需要远程数据收集/并置设备（DCCD）的使用。这个设备本质上是小的子系统，其用于远程地收集诊断信息并接着将它传输到数据收集过程。这将是必要的例子是在无人驾驶列车中使用的VOBC（非常智能的记载控制器）收集信息。VOBC具有可产生诊断信息但不能传输它的很多部件。在这种情况下，DCCD将与VOBC一起存在并将使用诊断协议来收集来自MPU、PICC、ECAN和CDU的信息，并将接着在将该数据传输到数据收集过程之前连接并压缩它。DCCD还将维持在可移动存储器上传输的数据的本地备份，使得如果有通信故障，则数据可被手动地取回。为了这个原因，利用DCCD的每个数据收集器服务也将具有用于从可移动存储器取回数据并处理它的机制，好像它直接从DCCD取回一样。即使DCCD可以是单独的物理设备，从体系结构观点看，考虑数据收集器服务的数据收集过程的一部分。

数据库服务器接口负责从数据收集器服务的内部存储器取回数据并将它格式化用于传输到诊断数据库服务10。需要这个过程来将数据收集过程所接收的原始数据转换成诊断数据库服务所需要的标准格式。这个方法允许在经处理的数据和原始诊断数据之间的清楚分离，且因此不将任何约束置于从所监控的设备接收的诊断信息上。

充当数据收集过程和数据库服务接口之间的媒介物的内部数据分级/存储实现两个作用。首先，它允许数据收集过程通过它花费多长时间来格式化而不受阻碍地取回数据，并存储该数据，且其次它允许接收到的原始数据的物理存储存在。这个第二点是重要的，因为它允许原始诊断信息的存储和存档。这在下列情况下是有用的：为了论证起见，只有85%的取回的诊断数据实际上存储在数据库中（例如，一些数据被认为是无关的或没有分析值）。通过使这个数据被备份，如果在未来额外的15%的数据变得有真实价值，则它将仍然被收集且没有历史数据将丢失。

立即响应式数据收集过程59负责目标设备的带外询问。数据收集过程在不断取回数据时将对某种计划这么做（例如，如果有20个VOBC，数据需要从其被收集，不能想象看到某种循环轮询将被使用或网络带宽限制可强加一点利率上限和因而收集速率限制）。当需要立即诊断数据时，使用立即响应式数据收集过程。如果分析引擎服务（稍后描述）在其故障检测的过程中确定直接诊断数据被需要，则它可要求相关的数据收集器服务（经由诊断数据库服务）的立即响应式数据收集过程以直接从规定的目标设备收集数据用于处理。该数据将通过如上所述的数据收集器服务的标准机制被捕获，但立即响应式数据收集过程将确保请求数据被连续地收集，而不考虑由数据收集过程使用的标准调度，直到当立即响应式数据收集过程从立即响应式收集不再需要的诊断数据库服务接收到通知时的时间为止。

诊断数据库服务10负责存储、管理并保护所有收集的诊断数据。部署可以有任何数量的诊断数据库服务存在，且它们中的每个将能够独立于彼此运行。诊断数据库服务将采取与其许可一起运行的操作系统服务的形式。诊断数据库服务包含下面的软件部件：工作站接口58、数据收集器接口56、分析引擎接口55、连接管理器过程57和数据管理过程54。

数据管理过程54负责维护SQL数据库中的数据，使得它容易被分析并有效地存储。这个过程在可配置的调度上运行，并负责老数据的存档。为可配置的滑动窗口维护由数据收集器接口（且在较小的程度上，由工作站接口）存储在SQL数据库70中的数据。位于窗口之外的在SQL数据库中找到的数据被转储到文件并从数据库清除。概念是该数据在设定量的时间内只有诊断值，其后提供任何中间值就太老了。数据管理过程还负责将转储的数据重新插入到SQL数据库中。这个功能存在以允许历史数据的重新插入，使得它可被重新分析，如果需要。因为被重新插入的数据默认地将位于可配置的滑动窗口之外，该数据将最可能在数据管理过程的下一运行时被再次清除。

连接管理器过程57负责监督由诊断数据库服务提供的各种接口的操作。这个部件负责检测并消除双重连接并负责确保一个连接不危害或干扰另一连接的操作。这个部件还负责处理由对另一接口有影响的任何接口接收的请求。例如，如果分析引擎接口11从分析引擎服务接收对立即响应式数据收集的请求，则连接管理器过程57负责确定将该数据路由到哪个数据收集器接口，如果有的话。

数据收集器接口负责维护诊断数据库服务和任何数量的数据收集器服务之间的通信。这个部件存在以提供在数据收集器服务和实际物理数据存储器（SQL数据库）之间的分离的水平。这个部件负责验证对数据收集器服务所产生的对存储的所有请求，以确保只有数据收集器服务所负责的数据被存储。这被完成以确保多个数据收集器服务不无意地破坏每个其它数据。这个接口还负责通过数据收集器服务验证任何请求以定义新的设备类型、设备实例或数据类型。该接口还处理数据收集器服务的通知，每当分析引擎接口接收到对立即响应式数据收集的请求时。

分析引擎接口55负责维护诊断数据库服务和任何数量的分析引擎服务之间的通信。这个部件存在以提供在分析引擎服务和实际物理数据存储器（SQL数据库）之间的分离的水平。这个部件负责验证对分析引擎所做出的规则和数据的所有请求，并接着在适当时提供那些请求。此外，这个接口负责接收立即响应式数据收集通知并将它们传递到连接管理器过程用于处置以及负责接收故障的通知，使得它们可在SQL数据库中被登录。

工作站接口58负责维护诊断数据库服务和任何数量的诊断工作站之间的通信。这个部件存在以确保诊断数据库服务所保持的数据不由诊断工作站意外组成。该部件在其运行的过程中将满足通过诊断工作站发送给它的请求。这些请求由下列项组成：

●从诊断数据库服务取回数据集用于在工作站上观察或分析。

●规则上传到诊断工作站的本地存储器（工作站的规则与通过诊断数据库服务加强的规则的同步）。

●新规则从诊断工作站下载到诊断数据库服务。

●用于存储的新维护记录的上传和在诊断数据库服务上的存档。

●用于观察的存档的维护记录的取回。

●由诊断工作站直接收集的数据上传到诊断数据库服务器。

处理规则的请求存在以允许一个“核心”规则组存在于诊断数据库服务上，同时允许每个诊断工作站具有其自己的一组规则（其可以与主要规则再次同步）。以这种方式，由分析引擎服务执行的在线数据分析的整体性被维护，同时允许使用诊断工作站的维护人员离线地创建并测试新的规则。如果新的规则被发现具有分析值，则这个规则可接着被发送到诊断数据库服务用于包括在主要规则中，且在线数据分析和其它诊断工作站可接着通过执行同步来挑选该规则。每当新规则被上传到诊断数据库服务时，备份拷贝由现有的规则组成，且修改被记录在SQL数据库中。

分析引擎服务11用于分析由诊断数据库服务存储的数据以检测故障或可能的故障，并向用户通知这样的系统。诊断系统可支持安装在任何数量的诊断服务器上的任何数量的分析引擎服务。

分析引擎服务具有三个部件：数据库服务器接口50、分析过程51和分析线程管理过程53。

数据库服务器接口50负责建立并维护与诊断数据库服务器的通信。该部件负责处理来自分析引擎服务的其它部件的所有数据请求，并格式化和传输那些请求到诊断数据库服务器。类似地，该部件负责将对诊断数据库服务器的回复路由回到发起请求的部件。数据库服务器接口负责提供这些功能，同时提取出对另一设备做出这些请求的事实；对于分析引擎服务的其它部件，它将看起来好像数据请求在本地处理一样。

分析线程管理过程53负责分析过程的操作和同步。这个部件负责发起并维护当前在分析引擎服务内运行的所有分析过程。这个部件当创建分析过程时将给该过程提供规则的队列和它将操作的数据集。分析线程管理过程的责任是确保规则的整个队列和数据集以及时的方式被分析，并确保有足够的分析过程和系统资源来使这发生。

分析过程53负责对照规则实际分析数据。这个部件将根据需要请求来自数据库服务器接口的数据和规则，以便满足由分析线程管理过程给它的任务。然而，分析过程53具有对它如何执行任务的自动控制。如果分析过程检测到阈值条件达到或如果立即响应式数据收集被需要，则在必要时自由修改它的任务和/或请求立即响应式数据收集。如果分析过程检测到故障出现，则分析过程负责触发对ATS的警报，并通过数据库服务器接口记录警报。

诊断工作站13用于观察并分析在诊断数据库服务中收集的数据，用于维护和学术目的。诊断系统可支持任何数量的诊断工作站实例，虽然将只有安装在任何一个物理PC上的一个诊断工作站。除了安装在那些PC上的任何其它软件以外，诊断工作站也可安装在诊断服务器上。

这些诊断工作站具有五个部件：数据库服务器接口63、维护日志观察器64、规则编辑器66、数据观察器/分析器68和目标设备接口69。

数据库服务器接口63负责建立并维护与诊断数据库服务器的通信。这个部件负责处理所有数据请求或来自诊断工作站的其它部件的上传，并格式化和传输那些请求到诊断数据库服务器。类似地，这个部件负责将对诊断数据库服务器的回复路由回到发起请求的部件。数据库服务器接口负责提供这些功能，同时提取出对另一设备做出这些请求的事实；对于诊断工作站的其它部件，它将出现为好像数据请求正在本地被处理一样。

维护日志观察器部件64用于允许用户创建并更新维护记录用于存储在诊断数据库服务上。维护记录存储在诊断数据库服务上并与设备相关。维护日志观察器也可用于从特定设备的诊断数据库服务取回历史维护记录用于观察。

诊断工作站的规则编辑器部件66允许用户使工作站的规则本地存储器与诊断数据库服务所存储的中央规则仓库同步。诊断工作站具有两组不同的规则：只在本地存在的规则和在中央存储的规则的本地的、用户可修改的拷贝。同步操作只合并在中央存储的规则的本地拷贝，使得当操作完成时，在中央存储的规则的本地拷贝将匹配存储在诊断数据库服务上的那些规则。这个部件也可用于观察并修改在本地存储在诊断工作站上的规则，包括从中央存储器接收的规则的本地拷贝。该部件也可用于在本地仅规则存储器中或在中央规则的本地拷贝中创建规则（其标志用于同步到中央的规则）。

数据观察器/分析器部件68用于观察由诊断数据库服务存储的数据或由诊断数据库服务转储到文件的数据。数据可使用来自规则本地存储器的规则的应用被分析，虽然以这种方式检测的任何警报或错误条件不传输到ATS。这被完成以允许用户测试新规则，而不触发错误或伪造的警报。关于诊断数据库服务的数据也可简单地被视为趋势曲线以允许用户用图形观察数据趋势。这个功能被设计成允许用户通过分析系统的什么部件被更频繁或更不频繁地使用来策划维护策略。例子将是确定哪个开关移动得更经常，且在那些开关机器处的目标维护优于使用较少的开关机器。该部件还允许用户观察由分析引擎服务存储在诊断数据库服务上的任何警报。从这些警报通知，用户可观察触发警报的特定的数据集。

目标设备接口69负责在数据收集器服务不能从该设备取回数据的情况下从设备收集数据。使用插入式结构来设计该部件以允许来自不同的设备类型的数据的收集。插件将被发展为特定的设备类型的数据收集器服务的部分，因为插头与数据收集器服务本身完成的相同的转换功能很有关。这个部件将从所连接的收集数据，并格式化该数据用于传输到诊断数据库服务，就好像数据直接来自数据收集器服务一样。在数据收集器服务使用DCCD的情况下，可能目标设备接口可连接到DCCD而不是直接到设备。

规则编辑器66提供两个核心特征，在诊断工作站的规则本地存储器中的规则与在诊断数据库服务上的主要规则存储器的同步以及本地规则的离线创建和修改。图6示出在规则同步事件期间发生的事件序列。当用户通知或调度时，规则编辑器将经由数据库服务器接口从诊断数据库服务请求所有规则的列表及其等级结构。规则编辑器将然后取回中央存储的规则的本地拷贝及其等级结构。规则编辑器将接着分析两组规则以在逐个规则的基础上确定哪组规则是更近的。来自每个集合的改变接着被合并，且然后规则的本地拷贝和中心拷贝都被更新。这是重要的差别。这个中心规则不一定盖写本地规则组，且本地规则组也不盖写中心规则。合并操作被执行以确保来自任一位置的最近变化被保存。每当在规则的中心和本地拷贝之间的冲突被检测到时，中心规则将推翻规则的本地拷贝。

数据观察器/分析器68提供两种功能：存储在诊断数据库服务上的数据的图形表示和该相同数据的离线分析。

图7示出在数据观察器/分析器的使用中发生的事件序列。当用户选择或基于调度时，数据观察器/分析器将经由数据库服务器接口查询诊断数据库服务以取回可用的数据集的列表。当这个信息被返回时，数据观察器/分析器将可用数据集存储在其本地数据存储器中。用户可接着选择数据集的列表以基于存储在本地数据存储器中的信息来观察。一旦用户做出选择，所请求的数据集就将经由数据库服务器接口从诊断数据库服务取回。一旦所选择的数据被取回，这个数据也存储在本地数据存储器中。支持这个设计决定的逻辑是，数据操纵使用本地资源更快，且通过使这个数据存在，如果用户在未来希望观察它，数据不需要再次从诊断数据库服务器转移。

一旦选择了数据的用户被插入到本地数据存储器中，数据观察器/分析器就将取回该数据并显示它作为数据的列表或基于用户选择的图形。数据观察器/分析器还允许用户选择一个或多个规则以对照数据集运行。显现给用户的规则的列表基于目前存在于本地规则存储器中的规则。一旦用户选择了一组规则，那些规则就将对照选定的数据集运行，且该分析的结果将被显现给用户。

为了检测故障和报告那些故障的目的，分析引擎服务负责存储诊断信息的在线分析。图8所示的分析线程管理过程将不断地在规则处理分配的所配置的队列中重复，并确保所有队列被分配给分析过程并被执行。如果规则队列未分配给活动的过程，则分析线程管理过程将例示新的分析过程并将该队列分配给它。

最新创建的分析过程将接着分析它给出的队列，并确定什么规则和数据集被需要来处理队列中的下一规则。它将接着通知数据库服务器接口取回相关的数据。一旦数据返回到分析过程，它就将执行规则以确定数据是否使规则通过。此时，分析过程具有它可遵循的很多分支。如果数据使规则通过，则分析过程将简单地确定要运行的下一规则并将重复对这个下一规则采取的最后行动。如果数据集未能使规则通过，则三个事情之一可能出现。如果规则指定故障将触发子规则的处理，则分析过程将简单地开始执行子规则路径。如果规则触发立即响应式数据收集，则分析过程将产生对数据库服务器接口的请求。数据库服务器接口将接着将这个请求转送到诊断数据库服务。分析过程将接着使用任何最近可用的数据不断地分析这个规则，直到当规则通过时或规则失败时的时间为止，以便触发不同的反应。如果规则指定故障必须导致警报，则分析过程将产生对ATS的警报以及经由数据库服务器接口将警报和所有其细节记录在诊断数据库服务中。

分析过程将不断地执行规则的队列，直到分析线程管理过程指示它终止或直到分配给它的队列规定它应终止为止。

数据收集器服务用于从所监控的设备取回数据，并将该数据存储在诊断数据库服务中。这个接口描述假设所显示的数据收集器服务使用数据收集/并置设备，虽然事件的序列在没有这样的远程数据收集是必要的情况下是类似的。图9所示的目标数据收集过程和数据库服务接口每个独立于外部影响运行其自己的内部调度。数据库服务器接口将周期性地检查内部数据分级/存储以查看任何数据是否可用于格式化。如果数据被找到，数据库服务接口将处理该数据并格式化它用于传输到诊断数据库服务。一旦数据集被发送，则数据库服务接口就将源数据标志为经处理的，因此标记它用于存档。

目标数据收集过程运行用于从所监控的设备取回数据的内部调度。这个调度对数据收集器服务的每次操纵是特定的。在某个点，目标数据收集过程将确定到了查询用于诊断信息的特定设备的时间。此时，目标数据收集过程将从所监控的设备取回诊断信息。在上面的图中，这通过数据收集/并置设备来完成。最终结果是，目标数据收集过程取回它接着存储在内部数据分级/存储器中以由数据库服务接口挑选的诊断数据。

诊断数据库服务器在它自己的内部处理的过程中可经由数据库服务接口将立即响应式数据收集通知转发到数据收集器服务。当这出现时，数据库服务接口将该通知转发到立即响应式数据收集过程。立即响应式数据收集过程将接着通知目标数据收集过程以暂停其内部调度并开始从规定的设备取回诊断数据。这继续，直到当数据库服务接口从诊断数据库服务接收到通知以终止立即响应式数据收集时的时间为止。

本领域中的技术人员应认识到，本文的任何方框图代表体现本发明的原理的例证性电路的概念图。本发明可在处理器上实现，处理器可通过使用专用硬件以及能够执行与适当的软件相关的软件的硬件来提供。当由处理器提供时，功能可由单个专用处理器、由单个共享的处理器或由多个单独的处理器（其中一些可被共享）提供。而且，术语“处理器”的明确使用不应被解释为排他地指能够执行软件的硬件，并可没有限制地隐含地包括数字信号处理器（DSP）硬件、网络处理器、专用集成电路（ASIC）、现场可编程门阵列（FPGA）、用于存储软件的只读存储器（ROM）、随机存取存储器（RAM）和非易失性存储器。常规和/或定制的其它硬件也可被包括。术语“电路”在本文用于包括实际上可在软件中实现的功能块。

Claims (32)

1.一种用于分析来自多个设备的数据的数据分析系统，包括：

数据库服务模块，其包括存储从不同的设备收集的数据的数据存储子系统，且其中所述数据被存储在使用基元来对所述数据分类的元结构中；以及

分析引擎，其用于分析所述数据以根据所存储的一组规则确定由所述元结构定义的所述数据是否满足预定标准。

2.如权利要求1所述的数据分析系统，其中所述基元包括设备类型、设备实例和数据类型，其中设备类型确定作为所述数据的源的设备的类型，设备实例识别在作为所述数据的所述源的设备类型内的特定设备，且数据类型指示所存储的数据的性质。

3.如权利要求2所述的数据分析系统，其中所述设备类型包括构成所述数据的所述源的所述设备的状态。

4.如权利要求1-3中的任一项权利要求所述的数据分析系统，其中所述规则存储在形成部分所述数据库服务模块的数据库中。

5.如权利要求1-4中的任一项权利要求所述的数据分析系统，其中所述数据库服务模块还包括数据收集器接口和数据管理处理模块，所述数据管理处理模块用于经由所述数据收集器从多个设备接收数据并根据所述元结构将所述数据存储在所述数据存储子系统中。

6.如权利要求1-5中的任一项权利要求所述的数据分析系统，其中所述数据存储子系统是SQL数据库。

7.如权利要求1-6中的任一项权利要求所述的数据分析系统，其中所述分析引擎包括分析引擎管理器，该分析引擎管理器用于确定哪些规则运行、以什么顺序和对照什么类型的设备或设备实例以及这些规则被处理的频率。

8.如权利要求7所述的数据分析系统，其中所述分析引擎管理器还包括分析队列模块，该分析队列模块用于处理所述分析引擎管理器分配给它的规则。

9.如权利要求8所述的数据分析系统，其中所述分析队列模块配置成向满足预定标准的经处理的数据发出警告通知。

10.如权利要求9所述的数据分析系统，其中所述分析队列模块配置成响应于满足预定标准的所述经处理的数据而触发其它规则的处理。

11.如权利要求9所述的数据分析系统，其中所述分析队列模块配置成响应于在满足预定标准的预定规则下处理的数据而触发立即响应式数据收集。

12.如权利要求11所述的数据分析系统，其中所述分析队列模块配置成以比在所述预定规则下处理的数据高的频率触发立即响应式数据的处理。

13.如权利要求5所述的数据分析系统，还包括数据收集服务模块，所述数据收集服务模块包括数据收集管理器，该数据收集管理器用于通过设备接口管理来自所述多个设备的数据的集合并通过数据库服务接口与所述数据库服务模块通信。

14.如权利要求13所述的数据分析系统，其中所述数据收集服务模块包括数据分级模块，该数据分级模块用于在转发到所述数据库服务模块之前临时对数据分级。

15.如权利要求13所述的数据分析系统，还包括工作站模块，其用于允许用户观察存储在所述数据库服务模块中的数据并将规则配置成由所述分析引擎使用。

16.如权利要求1-16中的任一项权利要求所述的数据分析系统，其中所述工作站配置成允许所述用户对照由所述数据库服务模块存储的特定数据来运行特定的规则。

17.一种分析来自多个设备的数据的方法，包括：

在正在进行的基础上收集来自不同的设备的数据；

将所收集的数据以使用基元来对所述数据分类的元结构存储在数据库服务模块的数据存储子系统中；以及

分析所述数据以根据所存储的一组规则来确定由所述元结构定义的所述数据是否满足预定标准。

18.如权利要求17所述的方法，其中所述基元包括设备类型、设备实例和数据类型，其中设备类型确定作为所述数据的源的设备的类型，设备实例识别在作为所述数据的所述源的设备类型内的特定设备，且数据类型指示所存储的数据的性质。

19.如权利要求17或18所述的方法，其中所述设备类型包括构成所述数据的所述源的所述设备的状态。

20.如权利要求17-19中的任一项权利要求所述的方法，还包括将所述规则存储在形成部分所述数据库服务模块的数据库中。

21.如权利要求17-20中的任一项权利要求所述的方法，其中所述分析引擎确定哪些规则运行、以什么顺序和对照什么类型的设备或设备实例以及这些规则被处理的频率。

22.如权利要求21所述的方法，其中所述分析引擎模块向满足预定标准的经处理的数据发出警告通知。

23.如权利要求22所述的方法，其中所述分析引擎响应于满足预定标准的所述经处理的数据而触发其它规则的处理。

24.如权利要求22所述的方法，其中所述分析引擎响应于在满足预定标准的预定规则下处理的数据而触发立即响应式数据收集。

25.如权利要求24所述的方法，其中所述分析引擎以比在所述预定规则下处理的数据高的频率触发立即响应式数据的处理。

26.如权利要求17-25中的任一项权利要求所述的方法，其中所收集的数据在转发到所述数据库服务模块之前临时对数据分级。

27.如权利要求17-19中的任一项权利要求所述的方法，还包括提供存储在所述数据库服务模块中的所述数据用于由用户观察。

28.如权利要求17-27中的任一项权利要求所述的方法，还包括通过用户接口配置由所述分析引擎使用的规则。

29.如权利要求28所述的方法，还包括通过用户接口命令对照所述数据库服务模块所存储的特定数据来运行特定的规则。

30.一种用于分析来自多个设备的数据的数据分析系统，包括：

数据收集器，其用于在正在进行的基础上收集来自不同设备的数据；

数据库服务模块，其包括存储从不同的设备收集的数据的数据存储子系统，且其中所述数据存储在使用基元来对所述数据分类的元结构中；

分析引擎，其用于分析所述数据以根据所存储的一组规则确定由所述元结构定义的所述数据是否满足预定标准；以及

工作站，其用于提供用于控制所述系统的操作的用户接口。

31.如权利要求30所述的数据分析系统，其中所述工作站配置成允许所述用户创建及修改所存储的所述一组规则。

32.如权利要求30或31所述的数据分析系统，其中所述工作站配置成允许所述用户运行存储在所述系统中的特定规则。

Images