KR20140051173A - 데이터 분석 시스템 - Google Patents

Abstract

본 발명은 다수의 장치들로부터의 데이터를 분석하기 위한 데이터 분석 시스템으로서, 상이한 장치들로부터 수집된 데이터를 저장하는 데이터 저장 서브시스템을 포함하는 데이터베이스 서비스 모듈을 구비한다. 상기 데이터는 그 데이터를 분류하기 위한 프리미티브(primitive)들을 이용하여 메타 구조(meta-structure)로 저장된다. 분석 엔진은 상기 메타 구조에 의해 정의되는 데이터가 저장된 규칙 세트에 따라서 소정의 기준을 만족하는지의 여부를 결정하기 위해 상기 데이터를 분석한다. 상기 시스템은, 예를 들면, 철도 기반시설에서 결함들의 검출에 있어 유용하다.

Description

데이터 분석 시스템{DATA ANALYSIS SYSTEM}

본 발명은 데이터 분석 분야에 관한 것으로서, 더 상세하게는, 철도 기반시설에서 볼 수 있는 것과 같은, 동종 또는 이종의 다수의 장치들로부터 수집되는 데이터의 분석에 관한 것이다.

철도 기반시설은 수많은 다양한 시스템들을 활용하고 있는데, 그 각각의 시스템은 그 자체의 진단 능력을 갖는 다수의 상이한 종류의 장치들을 적재적소에 사용하고 있다. 이러한 능력들은 거의 동일하지는 않으며 또한 그것들의 데이터를 제공하는 방법들은 더욱더 동일하지 않을 것이다. 그러나, 테스트, 진단 및 유지보수의 목적을 위해 이러한 데이터를 수집하고, 비교하고, 그리고 상호연관을 수행할 필요성이 존재한다. 현재에는 발생 된 데이터와 그것이 제공되는 방법을 일치시키는 것은 불가능하거나 또는 비현실적이다(지역별 컨트롤러들은 일반적으로 각 지역에서의 가이드웨이(guideway)의 상이한 구조로 인해 상이한 데이터 세트들을 갖는다).

각각의 장치 유형(디바이스 타입)에 대한 독립적인 데이터 수집과 같은 현재의 기술들은, 상호비교의 목적을 위해서는 모든 데이터를 중앙집중화하는 다소의 수동적인 노고를 필요로 하기 때문에 매우 성가신 실정이다. 더욱이, SNMP와 같은 네트워크 데이터 수집을 위한 기존의 해결책은 하기의 이유로, 즉,

a) 구현 불가능할지도 모르는 프로토콜을 이들 장치들에 부과하고 있고,

b) SNMP 프로토콜은 이벤트 통보(event notification)에만 근거하고 있기 때문에 데이터 수집 시스템으로서는 부적절하고, 그리고

c) 데이터 발생 장치들은 네트워크 및 NMS 서버에 접속하고 있다고(항상 그렇지는 않음) 가정하기 때문에 비현실적이다.

SCADA(Supervisory Control and Data Acquisition) 조차도, 생성될 수 있는 데이터 세트들이 잠재적으로는 SCADA 프로토콜의 오버헤드가 전체 시스템을 작동 불가능하게 만들기도 하기 때문에 현실적인 해결책으로 고려되지는 않았다. 현재 사용되고 있는 해결책은 네트워크 장치들(VOBC, ZC)이 중앙시스템(ATS)에 결함들을 보고하게끔 하는 것이다. 이 방법은, 현재 네트워크상에 존재하는 장치들만 데이터를 전송할 수가 있어서 비-네트워크 장치들로부터의 데이터는 보고되지 않은 채로 놓아둘 뿐만 아니라, 그 장치들은 테스트 및 진단의 관점에서 바람직한 데이터를 생성할 수도 있기 때문에, 여전히 충분치 못하다. 게다가, 그러한 네트워크화 장치들의 신뢰성에 대한 요구사양은 대개 진단기능들과 힘겨루기를 하는 경향이 있다(명확한 정의에 의해 신뢰성을 향상시키기 위한 투명투표(transparent voting) 및 데이터 평활화(data smoothing)와 같은 개념들은 일반적으로 예보적 진단 기능들에 요구되는 데이터를 파괴한다).

본 발명에 따르면, 다수의 장치들로부터의 데이터를 분석하기 위한 데이터 분석 시스템이 제공되는바, 상기 시스템은, 상이한 장치들로부터 수집된 데이터를 저장하는 데이터 저장 서브시스템을 포함하되, 상기 데이터는 그 데이터를 분류하기 위해 프리미티브(primitive)들을 이용하여 메타 구조(meta-structure)로 저장되는, 데이터베이스 서비스 모듈과, 그리고 상기 메타 구조에 의해 정의되는 데이터가 저장된 규칙 세트에 따라서 소정의 기준을 만족하는지 여부를 결정하기 위하여 상기 데이터를 분석하기 위한 분석 엔진을 포함하고 있다.

본 발명의 기본적인 사상은 목표 장치들로부터 데이터가 전달되는 구조와 방식으로부터 그 데이터가 어떻게 저장, 대조 및 분석되는지를 추출하는 하나의 오버레이(overlay) 시스템을 설계 및 개발하기 위한 것이다. 이것은 목표 장치에 물리적으로 접속되는 층을 제외하고 수집, 저장 및 분석 시스템의 모든 레벨들에서 사용되는 일반화된 데이터 구조의 창조를 가능하게 한다. 이것이 기존의 해결책들과 차별화되는 방식은, 그 시스템은 목표 장치들에 대해 여하간에 필요조건을 부과하지 않고 사용자에게 모든 장치들로부터의 모든 데이터를 공통 방식으로 취급하는 것을 가능하게 해준다는 점이다.

따라서 상기 방법은 모든 진단 데이터(diagnostic data)를 그것의 "자연적(natural)" 형태로 수집하고 그것을 데이터의 분석과 상호 비교를 허용하는 방식으로 한데 모은다. 상기 방법은 또한 모든 장치들이 수 킬로미터의 가이드웨이에 걸쳐 퍼져 있을 수도 있으므로 중앙집중화된 자동 저장 구조를 제공한다. 상기 방법은 또한 시스템의 핵심적 또는 운영적 측면에는 영향을 미치지 않고 모든 기술적인 필요조건들을 만족시킬 수 있도록 하는 방식으로 동작한다.

본 발명의 실시예들은 진단 데이터를 발생하는 것이 가능한 임의의 장치가 진단 시스템에 포함되는 것을 가능하게 한다. 본 발명의 해결법은 하나의 오버레이로서 동작하기 때문에, 발생한 데이터 또는 데이터를 가져오는 구조의 견지에서 어떤 타입의 장치들에 대해서도 어떠한 필요조건도 부과하지 않는다. 이것은 COTS(Commercial Off-The-Shelf) 또는 디자인에 영향을 미치지 않는 임의의 타 요소가 본 진단 시스템에 일체화될 수도 있음을 보증하게 된다. 마찬가지로, 상기 해결법은 그의 디자인이 영향받을 수 있는 구성요소들로부터의 임의의 필요조건을 제거하여 준다. 이러한 경우들에 있어 필요로 하는 모든 것은 단지 장치로부터 데이터가 전달되는 물리적 또는 논리적 구조에 대한 걱정 없이 어떤 데이터가 진단적 중요성을 갖는가를 정의하는 것이다. 생각건대, 본 발명은 발생한 데이터의 유형 및 그것이 접속 가능한 구조가 알려져 있는 한 경쟁자의 시스템상에서도 오버레이(overlay)로서 사용될 수도 있을 것이다.

본 발명은 데이터 속도에 대하여 어떠한 전제도 하지 않으며, 또한 어떠한 최소한의 필요조건도 부과하지 않기 때문에, 어떤 시스템에서도 전개될 수가 있고, 또한 시스템의 제약사항들에 대해서도 수월하게 적응될 수도 있다(예컨대, 데이터 수집속도는 매우 좁은 이용가능 대역폭을 갖는 시스템에서도 동작 가능하게 조절될 수 있다). 본 발명은 수집되는 데이터의 중요성이 저하될지라도 이러한 조건들에서 계속해서 동작할 것이다.

본 발명의 다른 측면에 따르면, 본 발명은 다수의 장치들로부터의 데이터를 분석하는 방법을 제공하는바, 상기 방법은, 상이한 장치들로부터 계속 진행형으로 데이터를 수집하는 과정과, 상기 데이터를 분류하기 위해 프리미티브들을 이용하는 메타 구조로써 데이터베이스 서비스 모듈의 데이터 저장 서브시스템에 상기 수집된 데이터를 저장하는 과정, 및 상기 메타 구조에 의해 정의되는 데이터가 저장된 규칙 세트에 따라서 소정의 기준을 만족하는지 여부를 결정하기 위해 상기 데이터를 분석하는 과정을 포함한다.

이하에서 본 발명은 첨부된 도면들을 참조하여 예시적인 방식으로 더욱 상세하게 기술될 것이다:
도 1은 본 발명의 일 실시예에 따른 데이터 분석 시스템의 개관을 도시한다;
도 2는 데이터베이스 서비스 모듈의 블록도이다;
도 3은 분석 엔진의 블록도이다;
도 4는 데이터 수집기(컬렉터)의 블록도이다;
도 5는 저수준의 추출 상태에서 상기 시스템의 블록도이다;
도 6은 규칙 동기화(rules synchronization) 과정을 예시하는 도면이다;
도 7은 데이터/뷰어(viewer)/분석기(애널라이저) 논리를 예시하는 도면이다;
도 8은 데이터 분석 프로세스를 예시하는 도면이다; 그리고
도 9는 데이터 수집 서비스들을 예시하는 도면이다.

도 1을 참조하여, 먼저 최상위 레벨의 추출(abstraction) 상태에서의 데이터 분석 시스템이 설명될 것이다. 상기 데이터 분석 시스템은 데이터베이스 서비스 모듈(10)을 포함한다. 이 구성요소는 중앙 데이터 저장부로서의 역할을 하며 그 데이터가 공통적인 방식으로 처리될 수 있도록 모든 데이터에 적용되는 메타 구조(meta-structure)의 정의에 대하여 역할을 한다. 본 발명의 실시예들은 하나 또는 다수의 데이터베이스 서비스들을 구비할 수도 있으며, 각각의 데이터베이스 서비스는 어떤 다른 구성요소가 임의의 사용된 데이터베이스 서비스와 통신할 수 있도록 활동할 것이다.

분석 엔진(Analysis Engine)(11))은 데이터베이스 서비스(10)에 의해 저장된 데이터의 상호연관(correlation) 및 비교를 위한 역할을 수행한다. 이 구성요소는, 데이터가 "양호(good)"한지 또는 "불량(bad)"한지 그리고 "불량"한 데이터가 검출되면 어떤 동작을 취할지를 결정하는 규칙들(rules)의 구조를 정의한다. 본 실시예에서는, 상기 데이터베이스 서비스에 의해 상기 규칙들이 저장되지만, 이것이 필요조건은 아니다. 그러나, 상기한 해결법의 사용은 영(제로)의 또는 다수 개의 분석 엔진들을 수반할 수도 있기 때문에 규칙 데이터를 위한 하나의 저장부를 제공하는 것과 같은 방식으로 규칙 저장 영역을 구현하는 것은 바람직한 실시인 것으로 간주 된다.

데이터 컬렉터(Data Collector)(12))는 데이터를 목표 장치(들)로부터 수집하고 그 데이터를 데이터베이스 서비스에 의해 사용되는 메타 구조로 변환하는 역할을 수행한다. 본 발명의 일 실시예는 하나 또는 다수의 데이터 컬렉터들을 포함하며, 각각의 데이터 컬렉터는 하나 또는 다수의 장치들 또는 디바이스 타입들로부터 데이터를 수집하는 역할을 수행할 수도 있다.

워크스테이션(13)은 전술한 해결책의 사용자 인터페이스를 위한 역할을 수행하며, 그리고 사용자가 그 데이터를 분석하는 것을 가능케 할 뿐만 아니라 수집된 데이터를 사용자가 보는 것을 가능케 한다. 워크스테이션은 또한 규칙들을 보기(viewing), 생성하기(creating), 수정하기(modifying), 또는 삭제하기(deleting)가 가능하다. 본 발명의 일 실시예는 워크스테이션이 아주 없거나 아니면 복수의 워크스테이션들을 가질 수도 있다.

상기 해결책의 전체에 걸쳐서 모든 데이터에 대해 메타 구조가 이용된다. 이러한 구조는 본질적으로 다른 데이터가 균일화되는(homogenized) 것을 가능케 함으로써 원 데이터의 형태나 소스에 상관없이 데이터가 응집력 있게 저장되고 사용될 수가 있다. 이러한 메타 구조는 데이터를 분류하기 위해 하기와 같은 프리미티브(primitive)들을 이용한다.

- 디바이스 타입(Device Type): 디바이스 타입은 일련의 데이터의 소스에 대한 데이터 컬렉터 정의형 분류이다. 예컨대, 네트워크 스위치 또는 컴퓨터가 각각 디바이스 타입일 수도 있다. 디바이스 타입들은 그들을 정의하였던 데이터 컬렉터와 연관된다.

- 디바이스 인스턴스(Device Instance): 각각의 디바이스 타입은 하나 또는 다수의 디바이스 인스턴스들를 가질 수 있다. '디바이스 인스턴스'란 단순히 데이터가 수집되는 장치의 디바이스 타입의 경우의 수(instance)이다. 예를 들면, "네트워크 스위치들"에 대하여 디바이스 타입이 정의되었다면, 해당 디바이스 타입은 "스위치1", "스위치2" 등의 디바이스 인스턴스를 가질 수도 있다.

- 데이터 타입(Data Type): 데이터 타입은 주어진 디바이스 타입에 대한 데이터 포인트의 정의이다. 한 디바이스 타입은 복수의 정의된 데이터 타입들을 가질 수도 있으며, 또한 그 디바이스 타입의 각각의 디바이스 인스턴스에 대하여 그 디바이스 타입에 대한 상기 정의된 데이터 타입들에 해당하는 데이터가 그 디바이스 인스턴스들 각각으로부터 수집될 것이다. 각각의 데이터 타입에 대한 데이터의 실제의 타입은 또한 그 데이터 타입이 정의될 때 정의된다. 예컨대, 디바이스 타입 "네트워크 스위치들"에 대한 데이터 타입인 "액티브 상태(Active Status)"는 정수로서 정의될 수도 있는 반면, 동일한 디바이스 타입에 대한 데이터 타입 "버젼(Version)"은 문자열로서 정의되어도 좋다. 본 발명은 일련의 타입들이 이용될 수도 있는 실제 구현에서 한 데이터 타입이 취할 수 있는 데이터의 타입에 대한 어떤 제한도 부과하지 않는다. 예를 들면, 철도 신호처리 시설에서 사용되는 장비로부터 데이터를 수집하기 위해서는 데이터 타입들의 유형을 정수(integer), 단정도 부동소수점수(single point precision floating point numbers), 또는 100글자 정도의 최대길이를 갖는 문자열로 한정하여도 충분할 것이다. 데이터 저장 해결법의 유형과 같은 다른 구현 요소들은 부가적인 제약사항들을 부과할 수도 있다. 예를 들면, 상용의 SQL 데이터베이스가 데이터 저장 구조로서 사용된다면, 허용되는 데이터 타입들의 리스트는 SQL 데이터베이스에 의해 지원되는 프리미티브들에 의해 제한될 수도 있다.

데이터베이스 서비스(10)는 도 2에 더 상세히 나타나 있는데, 이것은 데이터 컬렉터(12)로부터 받은 데이터의 수신, 및 위에서 정의된 메타 구조에 기초한 데이터의 저장과 카탈로그화 기능을 수행하는 역할을 수행한다. 이러한 기능들이 수행되는 예시적인 구조가 설명될 것이지만, 당해 기술분야의 전문가의 능력범위 내에 있는 다른 구조가 사용되어도 좋다.

데이터베이스 서비스(10)는 데이터 컬렉터 인터페이스(20)를 포함하는데, 이것은 저장될 데이터를 제공하는 데이터 컬렉터(들)와 통신하는 기능을 수행한다. 이 데이터 컬렉터 인터페이스(20)는 데이터 컬렉터(들)(12)와의 통신을 유지하고 그것들에 의해 수집되는 데이터를 수신하고 처리하는 역할을 한다. 상기 인터페이스(20)는 또한 상기 데이터 컬렉터들(12)이 책임져야할 디바이스 타입, 디바이스 인스턴스, 및 데이터 타입을 상기 데이터 컬렉터(들)(12)이 정의하고 관리하는 것을 가능하게 하는 역할을 수행한다. 데이터 컬렉터 인터페이스(20)는 데이터가 메모리(24)를 포함하는 데이터 저장 시스템(23)에 그때 저장될 수 있는 데이터 관리 프로세스(21)으로 수신된 모든 데이터를 전달하는 역할을 수행한다.

마찬가지로, 만일 접속된 데이터 컬렉터(12)가 그것이 수집하는 데이터에 대한 메타 구조를 수정한다면, 이러한 수정은 데이터 컬렉터 인터페이스(20)에 의해 데이터 관리 프로세스(21)로 전달됨으로써 데이터 관리 프로세스(21)는, 필요 시, 데이터 저장 시스템(22)에 데이터를 저장하는 방식을 업데이트 할 수도 있다.

데이터 컬렉터 인터페이스(20)는 또한 데이터 관리 프로세스(21)로부터 온-디맨드(on-demand) 데이터 수집에 대한 통보(notification)를 수신하는 역할을 수행한다. 그러한 통보가 수신되면, 데이터 컬렉터 인터페이스(20)는 이 요구(request)를 데이터 컬렉터(12))로 중계하여 처리되도록 할 것이다. 데이터 컬렉터 인터페이스(20)는 데이터 컬렉터(12)로부터 수신된 그 데이터를 전처리(pre-process)하거나, 아니면 단순히 데이터 관리 프로세스(21) 상으로 상기 데이터를 전달할 수도 있다. 데이터 관리 프로세스(21)에서 처리하는 모든 데이터를 중앙집중화하기 때문에 단순히 데이터를 전달하는 것이 바람직한데, 이것은 본 발명의 유지와 발전에 도움이 될 수 있다.

마찬가지로, 존재하는 데이터 컬렉터 인터페이스(20)의 수는 구현시 정의된다(implementation defined). 바람직한 구현이 데이터베이스 서비스(10)와 통신하는 각각의 데이터 컬렉터(12)에 대해 책임이 있는 단일한 데이터 컬렉터 인터페이스(20)를 구비할지라도, 상기 시스템은 데이터 컬렉터들(12)에 의해 사용되는 하나의 데이터 컬렉터 인터페이스(20)가 존재하도록 구축될 수 있다.

워크스테이션 인터페이스(25)는 검색할(retrieve) 인터페이스들을 제공하는 것뿐만 아니라 그 워크스테이션(들)에 의해 이용될 데이터를 제공하기 위해 워크스테이션(들)(13)과 통신하고 또한 규칙들을 수정하는 역할을 수행한다. 워크스테이션 인터페이스(25)는 로컬 사용을 위해 데이터를 다운로드 하는 것뿐만 아니라 데이터베이스 서비스(10)에 의해 어떤 데이터가 저장되는지에 대한 상태를 수신하기 위해 워크스테이션(들)(13)에 의해 사용된다. 부가적으로, 워크스테이션 인터페이스는 또한, 새로운 규칙들을 생성하거나 또는 기존의 규칙들을 삭제 또는 수정하는 것뿐만 아니라, 데이터베이스 서비스에 의해 저장되는 규칙 리스트를 검색하여 가져오기 위해 상기한 워크스테이션(들)에 의해 사용된다. 워크스테이션 인터페이스(25)는 또한 그 워크스테이션이 데이터 컬렉터로부터 직접 데이터를 수집했던 경우에 워크스테이션들(32)이 데이터를 저장하는 것을 가능하게 한다. 만일 데이터가 저장을 위해 워크스테이션 인터페이스(25)에 전송된다면, 그 워크스테이션 인터페이스(25)는 그 데이터가 마치 데이터 컬렉터 인터페이스(20)에 의해 수신되었던 처럼 처리될 수 있도록 데이터 관리 프로세스(21)로 상기 데이터를 전달할 것이다.

데이터 컬렉터 인터페이스(20)와 유사하게, 워크스테이션 인터페이스(25)는 데이터 관리 프로세스(21)로의 게이트웨이로서 동작하고, 그리고 데이터 컬렉터 인터페이스(20)에 적용가능한 모든 구현상의 고려사항들은 워크스테이션 인터페이스(25)에도 또한 적용된다.

분석 엔진 인터페이스(26)는 분석 엔진(들)(11)에 의해 사용될 데이터 및 규칙들을 제공하기 위해 분석 엔진(들)(11)과 통신하는 역할을 한다. 분석 엔진 인터페이스(26)는 데이터 관리 프로세스(21)를 경유하여 그 자신의 처리를 위해 분석 엔진(11)에 의해 요구되는 임의의 데이터와 규칙들을 상기 접속된 분석 엔진(11)에 단순히 제공만을 한다. 분석 엔진 인터페이스(26)는 또한, 요구된다면, 어떤 데이터와 규칙들이 이용가능한지에 대한 리스트를 제공할 수도 있다. 분석 엔진 인터페이스(26)는 또한 분석 엔진(들)(11)으로부터의 온-디맨드(on-demand) 데이터 수집을 위한 임의의 요구들을 받아들이는 역할을 수행한다. 온-디맨드 데이터 수집 요구가 특정한 디바이스 타입 및 디바이스 인스턴스에 대해 수신된다면, 분석 엔진 인터페이스(26)는 그것이 적절한 데이터 컬렉터 인터페이스(20)로 급속하게 전달될 수 있도록 데이터 관리 프로세스(21)에 대해 그 통지를 전달하는 역할을 수행한다.

데이터 컬렉터 인터페이스와 유사하게, 분석 엔진 인터페이스는 데이터 관리 프로세스에 대한 하나의 게이트웨이로서 동작하고, 그리고 데이터 컬렉터 인터페이스에 적용가능한 모든 구현상의 고려사항들은 상기한 분석 엔진 인터페이스에도 또한 적용된다.

데이터 관리 프로세스(21)는 데이터베이스 서비스(10)의 다른 구성요소들에 데이터 저장 서브시스템(24)의 추출을 제공하고, 그리고 데이터 저장 서브시스템(22)의 실제의 구현을 관리하는 역할을 수행한다. 데이터 관리 프로세스(21)는 본 발명에 의해 부과되는 메타 구조에 기초하여 데이터의 용이한 접속과 저장을 가능하게 하기 위해 데이터 저장 서브시스템(22)을 구성하는 역할을 한다. 이러한 구성이 데이터 저장 서브시스템(22)에 의해 물리적으로 또는 논리적으로, 아니면 단순히 데이터 관리 프로세스에 의해 논리적으로 수행되는지의 여부는, 데이터 관리 프로세스(21)의 모든 사용자들에게 모든 데이터가 메타 구조를 통해 접속되고 참조되는한 디자인 선택의 문제이다.

규칙들의 저장과 접속에도 동일한 조건이 적용된다. 상기한 규칙들이 존재함으로써 메타 구조에 의해 정의되는 데이터가 "양호"한지 아니면 "불량"한지의 여부를 판단할 수가 있다. 결과적으로, 규칙들이 저장되고 참조되는 구조는 단지 선택의 문제이지만, 양호한 구현이라면 데이터 관리 프로세스(21)가 규칙들을 저장하고 그에 대한 접속을 제공하는 역할을 함과 아울러 상기 규칙들이 데이터 저장 서브시스템(22)에 저장되는 것을 지정할 것이다.

데이터 저장 서브시스템(22)은 데이터 관리 프로세스(21)에 의해 추출되는 임의의 종류의 물리적인 데이터 저장 및 검색(retrieval) 시스템일 수도 있다. 데이터 저장 시스템의 예를 들면 SQL 데이터베이스로부터 단순한 플랫형(flat) 데이터 파일 또는 일련의 플랫형 데이터 파일들까지의 임의의 형태일 수도 있다. 데이터 저장 서브시스템(22)의 실제의 구현은 본 발명의 영역에서 벗어나지만, 해결책을 선택할 때에는 하기의 사항을 고려해야할 것이다:

a) 데이터 저장 서브시스템(22)은 다량의 데이터가 매우 고속에서의 저장을 위해 데이터베이스 서비스(10)로 전송될 수도 있다고 상정할 수 있으므로 고속의 쓰기(write) 시간을 확보하여야 한다. 상기한 쓰기 시간은 데이터가 수집되는 속도보다 더 커야만 하거나, 또는 어떤 종류의 캐시(cache) 및 플러시(flush) 시스템이 사용되어야만 한다.

b) 데이터 저장 서브시스템(22)은 데이터에 대한 랜덤 액세스를 허용해야만 한다. 데이터의 다수의 수신기들(워크스테이션(들) 및/또는 분석 엔진(들))은 다량의 상이한 데이터를 동시에 요구할지도 모르기 때문에 데이터 저장 시스템은 시스템의 성능에 최소의 영향을 끼치면서 이것이 발생하는 것을 가능하게 해준다.

c) 데이터 저장 서브시스템(22)은 고장의 경우 데이터 완전성과 시스템 신뢰성을 확보하기 위한 어떤 형태의 리던던시(redundancy)를 제공해야만 한다.

d) 데이터 저장 서브시스템(22)은 복수의 동시 접속을 허용해야만 한다. 사용시 두 개 이상의 데이터베이스 서비스를 가질지도 모르기 때문에 데이터 저장 서브시스템(22)은 데이터베이스 서비스의 모든 인스턴스들이 단일한 데이터 저장공간에 접속하는 것을 가능하게 해야만 한다. 데이터베이스 저장 서브시스템은 또한 복수의 접속들에 의해서도 데이터의 완전성을 손상시키지 않음을 보증하는 구조를 구현해야만 한다.

데이터베이스 서비스(10) 및 데이터 컬렉터(들)(12), 워크스테이션(들)(13), 및 분석 엔진(들)(11) 간의 통신을 위해 사용되는 프로토콜(들)의 구현은 하기의 것들을 충족하여야 한다;

a) 포로토콜은 데이터베이스 서비스(10) 및 타 관여자(party) 모두가 데이터가 액티브하게 전송되고 있지 않을지라도 연결이 상실되는지 여부를 판단할 수 있도록 연결 지향적(connection oriented)이어야 한다. 이것은 고장 처리를 허용하면서 전송중인 데이터가 그 데이터를 수신하는 수신기가 있었다는 잘못된 가정으로 상실되지 않는 것을 보장하도록 이루어져야만 한다.

b) 모든 인터페이스들에 대해 공통의 프로토콜이 사용되어야만 한다. 이것은 본 발명의 필요조건은 아니지만, 개발, 디버깅(debugging) 및 유지보수를 용이하게 할 것이다.

c) 프로토콜은 낮은 오버헤드를 가져야 하고 그리고 데이터가 수집되고 있는 것보다 더 큰 속도로 전송의 송신 및 수신 확인이 가능해야만 한다.

d) 프로토콜은 수신된 데이터를 파싱(parsing)함에 있어 데이터베이스 서비스(10)에 의해 요구되는 변환의 양을 최소화하도록 하는 방식으로 데이터를 전송해야만 한다. 데이터베이스 서비스(10)는 복수의 소스들로부터(소스들로) 동시에 다량의 데이터를 수신 및 전송하고 있는 것으로 생각할 수도 있기 때문에, 각각의 메시지에 대해 데이터베이스 서비스(10)에 의해 요구되는 프로세싱의 양을 제한하는 것이 유리하다.

도 3에 더 상세히 도시된 분석 엔진(11)은 데이터베이스 서비스(10)에 의해 저장된 데이터를 분석하고 그 데이터가 "양호"한지 아니면 "불량"한지를 결정하는 역할을 한다. "불량" 데이터가 검출되는 경우, 분석 엔진(11)은 응답 동작을 트리거링하는 역할을 수행한다. 데이터가 어떻게 분석되는지, "양호" 또는 "불량" 결정이 어떻게 이루어지는지, 그리고 "불량" 데이터의 결과가 나올 경우 어떤 동작이 이루어지는지에 대한 실제의 구조들은 본 발명의 영역에 속하지 않는다.

데이터 서비스 인터페이스(30)는 데이터베이스 서비스(10)의 분석 엔진 인터페이스(26)를 통해서 데이터베이스 서비스(10)와 통신하는 역할을 수행한다. 결과적으로 이러한 구성요소들에 대한 모든 기능적 및 구현상의 고려요소들은 데이터베이스 서비스(10)의 분석 엔진 인터페이스(26)에 대한 것과 동일하다. 분석 엔진의 관점에서 볼 때, 이 구성요소는 데이터베이스 서비스(10)에 저장된 모든 데이터가 그것이 마치 로컬로(locally) 존재하는 것처럼 취급될 수 있도록 분석 엔진에 대한 데이터 소스를 추출하는 역할을 수행한다. 분석 엔진(11)의 나머지 구성요소들에 대해 데이터베이스 서비스 인터페이스(30)는 데이터 그 자체인 것으로 보이게 되어야 한다. 본 발명의 실시예들은 복수의 데이터베이스 서비스들을 사용할 수도 있기 때문에, 이 구성요소는 데이터베이스 서비스(10)의 어느 특정한 인스턴스에 연결될 것인지 판단하는 역할과, 그리고 현재의 것이 이용 불가능하게 될 경우 임의의 다른 이용가능한 데이터베이스 서비스(10)에 연결하는 역할을 또한 수행한다.

데이터 서비스 인터페이스(30)는 또한 분석 엔진(11)이 사용되었던 규칙들의 "저장(storage)"을 위한 역할을 수행한다. 전술한 바와 같이, 규칙들은 데이터베이스 서비스(10)에 저장되는 것이 바람직한 구현일 것이며, 이 경우 이 구성요소는 규칙들을 검색해서 가져오기 위해 단순히 데이터베이스 서비스(10)에 대한 인터페이스를 추출할 것이다. 상기 규칙들이 분석 엔진(11)과는 로컬로 저장될 경우, 이 구성요소는 데이터 소스의 추출의 역할을 하기 위한 그의 책임의 일부로서 그 스스로 상기 규칙들을 위한 저장 위치로서 또한 역할을 할 것이다. 이러한 방식으로, 규칙 저장을 위해 선택된 구현에 상관없이, 분석 엔진(11)의 나머지 구성요소들에 대해서는 규칙을 회수할 인터페이스는 변함없이 유지된다.

분석 엔진 관리부(31)는 분석 엔진(11)의 현재의 인스턴스에 의해 취해지고 있는 동작들을 조정하는 역할을 한다. 분석 엔진 관리부(31)는 어떤 규칙이, 어떤 순서로, 그리고 어떤 디바이스 타입들 또는 디바이스 인스턴스에 대해서 운영될 것인지 뿐만 아니라, 그 규칙들이 어떤 빈도로 처리될지를 결정하는 역할을 한다. 그 규칙들의 실제의 구조와 능력들은 구현에 의해 정의되기는 하지만, 이러한 규칙들은 존재하고, 실행이 가능하고, 그리고 데이터가 "양호" 또는 "불량"인지 여부를 결정하는 것이 가능해야만 한다.

분석 엔진 관리부(31)는 다수의 "큐(queues)들"의 규칙 프로세싱이 존재하는 것을 가능하게 하고, 각각의 "큐"에 대해 분석 큐(Analysis Queue)(32)가 생성되어 그 "큐"를 처리하도록 할 것이다. 예를 들면, 분석 엔진 관리부(31)는 분석 큐(32)를 생성하여 매 30분마다 한 번씩 동작 되도록 디바이스 타입 "네트워크 스위치들"에 대한 모든 규칙들을 처리하고 또한 동시에 매 100 밀리초마다 규칙 "비상 제동 실패 검출(Emergency Brake Failure Detection)"을 동작시키는 또 다른 분석 큐(32)를 갖도록 할 수가 있다.

존재 가능한 분석 큐(32)의 수 또는 최상위 레벨에서 그 각각의 능력들의 수에 대한 어떠한 제한들(즉, 분석 큐에는 단지 "클래스" 또는 규칙들만이 할당될 수 있는지의 여부, 또는 하나의 분석 큐에 단일한 규칙들이 할당되는지, 또는 하나의 분석 큐가 특정한 디바이스 인스턴스 또는 디바이스에 대한 모든 규칙들이 할당될 수 있는지의 여부, 등등)도 부과되지 않는다. 분석 엔진 관리부(31)는 분석 큐들에 임무를 부여해야만 하며, 그리고 분석 엔진 관리부는 하나 또는 다수의 분석 큐들을 관리할 수가 있다. 본 발명은 또한 분석 큐(32)의 수 및 그것들의 할당된 태스크들이 동적으로 할당되고 수정될 수 있도록 하지만, 그것을 반드시 요구하는 것은 아니다.

분석 엔진 관리부(31)가 분석 큐들에 태스크들을 할당하는 방식은 구현상의 세부사항으로 간주 된다. 예를 들면, 분석 큐들의 수 및 그의 태스크들을 정의하는 구성 파일들이 사용되는지 여부, 또는 그래픽 유저 인터페이스를 통해 사용자 입력이 요청될 경우 분석 큐에 할당이 이루어지는 실질적인 구조는 구현에 의해 정의된다.

분석 큐(32)는 분석 엔진 관리부(31)에 의해 그것에 할당되는 규칙들을 처리하는 역할을 수행한다. 분석 큐(32)는 또한 "불량" 데이터가 검출될 때 동작을 취하는 역할을 한다. 취하여지는 실제의 동작은 구현에 의해 정의되는 것으로 간주 되며 규칙에 의해 정의되어야만 하지만, 상기 시스템은 아래의 기능을 허용하여야 한다;

a) 분석 큐(32)는 분석 관리자에게 실패 및 모든 이용 가능한 세부사항들에 대해 통지하여야 하는데, 이로써 데이터베이스 서비스 인터페이스를 통해 데이터베이스 서비스에 기록될 수도 있다.

b) 다수 레벨의 동작들이 정의될 수도 있다. 예를 들면, 어떤 고장들은 다른 조건하에서는 일반적으로는 처리되지 않을 소정의 규칙들이 처리되게 하는 "경고(warning)" 조건을 유발할 수도 있는 반면(이러한 방식으로, 규칙들의 정상적인 프로세싱은 더 높은 레벨에서 이루어질 수 있고, 그리고 어떤 경우에는 문제의 정확한 원인을 찾기 위해 특정한 데이터 포인트들이 확인될 것이다), 다른 고장들은 "경보(alarm)"를 유발할 수도 있다.

c) 분석 큐(32)는 분석 엔진 관리부에 통지하여 온-디맨드(On-Demand) 데이터 수집을 가능하게 할 수가 있다. 분석 엔진 관리부는 이 통지를 데이터베이스 서비스 인터페이스를 통해 데이터베이스 서비스에 중계할 것이다. 이러한 방식으로, 분석 큐는 현재 이용가능하지도 모르는 더 최신의 데이터를 사용하여 의심스러운 규칙을 프로세싱하기를 계속할 수가 있을 것이다.

d) 분석 큐(32)는 그의 할당된 프로세싱 빈도를 일시적으로 증가시킬 수 있다. 예를 들면, 만일 어떤 경계 조건이 검출되면, 분석 큐는 온-디맨드 데이터 수집을 트리거할 수 있고 그리고 실제의 고장이 발생하는지 여부를 확인하기 위해 할당된 것보다 더 높은 비율로 의심스러운 규칙을 처리할 수도 있는데, 그 경계 조건이 더 이상 존재하지 않거나 또는 소정의 시간 제한이 만료된다면, 할당된 빈도로 디폴트에 의해 다시 돌아가 프로세싱하게 된다.

e) 분석 큐(32)는 외부 인터페이스(들)(33)를 통해 어떤 외부 인터페이스로 경보를 발생할 수도 있다. 예를 들면, 철도 신호 시스템에 있어서, 분석 큐는 고장이 검출될 때 중앙제어센터에 경보(알람)를 유발할 수도 있고 아니면 정비 인원에게 이메일을 보낼 수도 있다.

외부 인터페이스(들)(33)는 구현에 의해 정의된다(implementation defined). 그것들은 분석 엔진 관리부(31) 및 분석 큐(32)에 의해 외부 시스템들과의 통신을 가능하게 한다. 통신의 구조 및 그의 정확한 목적은 구현에 의해 정의되지만, 그것의 예를 들면, 외부 시스템에 경보를 중계하고, 정비 작업들을 개시하기 위한 메시지들을 발생하고, 부가적인 정보를 검색해 가져오고(이러한 사용이 가능하기는 하지만, 이것은 진단 값을 갖는 어떤 데이터가 분석 엔진에 의해 직접이 아니라 데이터 컬렉터에 의해 수집되어야 하기 때문에 바람직하지 않다), 해결책의 모든 구성요소들이 기능을 발휘하고 있다는 것("심장박동(heartbeat)" 메시지)을 외부 시스템에 통지하고, 그리고 분석 엔진(11)의 다수의 인스턴스들 간에 조정하는 것을 포함한다.

전술한 바와 같이, 상기한 해결책의 사용은 분석 엔진(11)의 다수의 인스턴스들이 사용되게 할 수도 있으며, 또한 상기 해결책은 각 인스턴스가 독립적으로 동작하는 것을 가능하게 한다. 분석 엔진(11)의 모든 인스턴스들이 그들의 작업들을 조정하도록 하는 것이 어떤 구현에서는 바람직할 수도 있는데, 그럼으로써 본 발명은 이것을 허용하기는 하지만 본 발명은 이러한 기능을 필요로 하지 않기 때문에 그것을 외부 인터페이스로서 취급한다.

도 4에 더 상세하게 도시된 데이터 컬렉터(12)는 데이터 소스들로부터 데이터를 수집하고 그리고 그것을 저장하고 더 나아가 그것을 분석하기 위해 데이터베이스 서비스(10)로 전달하는 역할을 수행한다. 이 구성요소는 수집되고 있는 데이터의 네이티브 포맷(native format) 및 그 데이터를 수집하는 물리적인 방법을 이해하는 역할을 한다.

데이터 컬렉터(12)는 데이터베이스 서비스(10)에 인터페이스 하기 위한 데이터베이스 서비스 인터페이스(40), 다양한 장치들에 인터페이스 하기 위한 장치 인터페이스(41), 데이터베이스 서비스(10)에 전송하기 전에 데이터를 스테이지(staging)하기 위한 데이터 스테이지 모듈(42), 및 다양한 장치들로부터의 데이터의 수집을 관리하고 데이터베이스 서비스(10)에 전송하기 위한 데이터 컬렉션 관리자를 포함한다.

워크스테이션(13)은 단말 사용자 인터페이스를 표현한다. 사용자 인터페이스로서 워크스테이션(13)의 기능의 대다수는 구현형으로 정의되고, 그리고 정말로 본 발명은 전술한 제약사항들과 다른 워크스테이션에 대한 어떠한 구조도 부과하지 않는다. 워크스테이션(13)에서 구현되어야 하는 기능들은 데이터베이스 서비스에 의해 저장되는 데이터를 사용자가 볼 수 있게 하는 것, 분석 엔진에 의해 사용되는 규칙들을 사용자가 보고, 수정하고, 생성하고, 또는 삭제하는 것을 가능하게 하는 것, 그리고 데이터베이스 서비스에 의해 저장된 데이터에 대해 사용자가 규칙들을 동작시키는 것을 포함한다. 처리중인 이러한 규칙들의 결과가 경보를 발생하는지 아닌지의 여부는 그 결과들이 보고되지 않게 하는 것에 대한 장점이 존재하기는 하지만 구현 지정형(implementation specific)이다. 이러한 방식으로, 사용자는 라이브 데이터에 대해 새로운 규칙들을 "테스트"할 수 있다. 상기 워크스테이션은 부가적인 유지보수 특성들을 편입할 수 있어야만 한다. 이러한 특성들은 사용의 관점에서 해결책의 일부는 아닐지라도, 모든 유지보수 동작들에 대해 중앙집중화된 도구를 구비하는 것은 바람직하다.

상기 워크스테이션은 또한 모든 기능들의 실행을 위한 사용자 로그인 및 접속 레벨을 이용하여야 한다. 이것은, 상기 워크스테이션은 중심 세트의 규칙들을 수정하는 것과 같은 기능들을 수행하기 위해 사용될 수 있지만 이러한 기능들을 어떤 사용자들에게만 펼쳐질 수 있어야 한다는 것을 확실하게 해준다.

마지막으로, 상기 워크스테이션은 목표로부터 직접 데이터를 수집하고 그것이 마치 데이터 컬렉터로부터 도달된 것처럼 그 데이터를 데이터베이스 서비스에 중계하는 기능을 지원해야 한다. 이것에 대한 이유는, 데이터 컬렉터가 목표로부터 더 이상 자동으로 데이터를 수집할 수가 없을 경우에도 데이터가 수집되고 분석될 수 있음을 보증하기 위함이다.

도 5에는 소프트웨어 구성요소들에 대한 더 상세한 도면이 도시된다. 데이터 컬렉터(12)는 모니터 중인 장치들로부터 데이터를 가져오고, 그 데이터를 포맷하고, 그리고 진단 데이터베이스 서비스에 그 데이터를 저장하기 위해 사용된다. 임의의 수의 데이터 컬렉터 서비스들이 존재할 수 있으며, 각각의 데이터 컬렉터 서비스는 임의의 수의 장치들로부터 데이터를 수집할 수도 있다. 다수의 데이터 컬렉터들이 동일한 진단 서버(Diagnostics Server)에 설치될 수 있지만, 각각의 데이터 컬렉터 서비스가 하나의 진단 서버에 설치될 것이다.

이러한 데이터 컬렉터(12)는 그의 승인으로써 동작하는 오퍼레이팅 시스템 서비스의 형태를 취할 것이다. 각각의 데이터 컬렉터 서비스는 다음의 구성요소들을 구현하고 지원할 것이다: 목표 데이터 컬렉션 프로세스(62), 데이터베이스 서버 인터페이스(60) 및 온-디맨드 데이터 컬렉션 프로세스(59).

데이터 컬렉션 프로세스는 모니터 중인 장치(들)로부터 데이터를 수신하고 그 데이터를 상기 데이터 컬렉터 서비스에 대해 특정한 로컬 저장영역에 배치하는 역할을 수행한다. 목표 장치(들)와 통신하고 그로부터 진단 정보를 검색하여 가져오는 방법을 이해하는 것은 이 구성요소의 책임이다. 예를 들면, 데이터 컬렉션 프로세스는 SNMP 서버의 형태를 취할 수도 있으며 그리고 SNMP 프로토콜을 이용하여 라우터들과 AP들로부터 진단 정보를 수신할 수도 있다.

모니터 되고 있는 디바이스 타입에 따라서는 데이터 컬렉션 프로세스는 리모트 데이터 컬렉션/연결 장치(Romote Data Collection/Concatenation Device: DCCD)의 사용을 필요로 할지도 모른다. 이 장치는 진단 정보를 원거리에서 수집하고 그것을 데이터 컬렉션 프로세스에 전송하기 위해 사용되는 본질적으로 소형의 서브시스템이다. 이것이 필요하게 되는 예는 드라이버 없는 트레인들에서 사용되는 VOBC(Very intelligent On-board Controller)로부터 정보를 수집하는 경우이다. VOBC는 진단 정보를 발생하지만 그것을 전송할 수는 없는 여러 가지의 구성요소들을 구비한다. 이 경우, DCCD는 VOBC와 함께 존재하고 그리고 MPU, PICC, ECAN, 및 CDU들로부터 정보를 수집하기 위해 진단 프로토콜을 사용할 것이며, 그 다음에는 그것을 데이터 컬렉션 프로세스로 전송하기 전에 이 데이터를 연결(concatenate) 및 압축할 것이다. DCCD는 또한, 통신 실패가 존재한다면 데이터를 수동으로 가져올 수 있도록 전송 중인 데이터의 로컬 백업(local backup)을 탈착 가능한 저장장치(removable staorage)에 보존할 것이다. 이러한 이유로 DCCD를 활용하는 각각의 데이터 컬렉터 서비스는 또한 탈착 가능한 저장장치로부터 데이터를 다시 가져와서 그것을 DCCD로부터 직접 가져온 것처럼 처리하기 위한 구조를 가질 것이다. 상기한 DCCD가 독립된 물리적 장치일 수도 있지만, 그것은 구조의 관점에서 보면, 데이터 컬렉터 서비스의 데이터 컬렉션 프로세스의 일부로 간주 된다.

데이터베이스 서버 인터페이스는 데이터 컬렉터 서비스의 내부 저장장치로부터 데이터를 가져와서 진단 데이터베이스 서비스(10)로의 전송을 위해 그것을 포맷하는 역할을 수행한다. 이 프로세스는 데이터 컬렉션 프로세스에 의해 수신된 원시 데이터를 진단 데이터베이스 서비스에 의해 요구되는 표준화 포맷으로 변환하는 것을 필요로 한다. 이 방법론은 처리된 데이터와 원시 진단 데이터 간의 명료한 분리를 가능케 하고, 따라서 모니터 된 장치들로부터 수신된 진단 정보에 대해 어떠한 제약도 두지 않는다.

데이터 컬렉션 프로세스와 데이터베이스 서비스 인터페이스 사이의 매개자로서 동작하는 내부 데이터 스테이징/저장부는 두 개의 역할을 충족한다. 첫째로, 그것은 데이터 컬렉션 프로세스가 상기 데이터를 포맷하고 저장하기 위해 얼마나 긴 시간이 걸리는지에 의해 지연 없이(unhindered) 데이터를 가져오는 것을 가능하게 하고, 둘째로는 수신된 원시 데이터의 물리적 저장을 가능하게 한다. 이러한 두 번째 포인트는 원시 진단 정보의 저장 및 기록보관(archiving)을 가능하게 하기 때문에 중요하다. 이것은, 논의의 목적상, 가져온 진단 데이터의 단지 85%만이 데이터베이스에 실제로 저장되는 경우에 유용하다(예를 들어, 어떤 데이터는 본질과 관계없는 것이거나 어떤 분석적 중요성을 갖지 않는다). 이러한 데이터가 백업 되게 함으로써 나머지 15%의 데이터가 가치있게 될 미래 시점에서도 그것은 계속해서 수집되어왔을 것이므로 어떤 경과적 데이터도 상실되지 않을 것이다.

온-디맨드 데이터 컬렉션 프로세스(59)는 목표 장치들의 아웃-오브-밴드(out-of-band) 질문에 대해 역할을 수행한다. 데이터 컬렉션 프로세스는 계속해서 데이터를 가져오는 동안 어떤 종류의 스케줄 상에서 그렇게 할 것이다(예를 들어, 그로부터 데이터가 수집될 필요가 있는 20개의 VOBC들이 존재한다면, 어떤 종류의 라운드-로빈 폴링(round-robin polling)이 사용될 것이라거나 아니면 네트워크 대역폭 제한이 비트 속도 캡(bit rate cap), 따라서 수집 속도 제한을 부과할 수도 있다는 것을 이해하기가 상상할 수 없는 것은 아니다).

온-디맨드 데이터 컬렉션 프로세스는 즉각적인 진단 데이터가 요구될 때 사용된다. 만일 분석 엔진 서비스(후술함)가 즉각적인 진단 데이터가 필요한 것으로 그것의 오류 검출 과정에서 판단한다면, 그것은 프로세싱할 특정한 목표 장치로부터의 즉시로 수집된 데이터에 대해 적절한 데이터 컬렉션 서비스의 온-디맨드 데이터 컬렉션 프로세스를 (진단 데이터베이스를 경유하여) 요구할 수 있다. 이 데이터는 전술한 것과 같은 데이터 컬렉터 서비스의 표준 구조를 통해서 획득될 것이나, 온-디맨드 데이터 컬렉션 프로세스는, 온-디맨드 데이터 컬렉션 프로세스가 온-디맨드 컬렉션이 더 이상 필요치 않다는 통지를 진단 데이터베이스로부터 수신하는 그러한 시간까지 데이터 컬렉션 프로세스에 의해 이용되는 표준 스케줄과는 관계없이 요구 데이터가 계속해서 수집되는 것을 보증할 것이다.

진단 데이터베이스 서비스(10)는 모든 수집된 진단 데이터를 저장하고, 관리하고, 그리고 보호하는 역할을 한다. 사용시 임의의 수의 진단 데이터베이스 서비스들이 존재하도록 할 수 있으며, 그 각각은 서로 독립적으로 동작하는 것이 가능할 것이다.

진단 데이터베이스 서비스는 그것의 승인(permission)으로써 동작하는 오퍼레이팅 시스템 서비스의 형태를 취할 것이다. 진단 데이터베이스 서비스는 다음과 같은 소프트웨어 요소들을 포함하고 있다: 워크스테이션 인터페이스(58), 데이터 컬렉터 인터페이스(56), 분석 엔진 인터페이스(55), 연결 관리자 프로세스(57) 및 데이터 관리 프로세스(54).

데이터 관리 프로세스(54)는 데이터가 용이하게 분석되고 효율적으로 저장되도록 SQL 데이터베이스에 그 데이터를 유지하는 역할을 수행한다. 이 프로세스는 구성 가능한 스케줄로 동작하고 오래된 데이터의 기록보관(archiving)의 역할을 한다. 데이터 컬렉터 인터페이스(그리고 더 좁은 범위로는 워크스테이션 인터페이스)에 의해 SQL 데이터베이스(70)에 저장되는 데이터는 구성가능한(configurable) 슬라이딩 윈도우에 대해 유지된다. 상기 윈도우 바깥에 존재하는 SQL 데이터베이스에서 발견되는 데이터는 한 파일로 덤프(dump) 되고 그 데이터베이스로부터 제거된다. 이 개념은, 데이터는 일정 양의 시간에 대해서만 진단 유용성을 가지며, 그 시간 후에는 너무 오래되어서 어떤 즉각적인 가치를 제공하지 않는다는 것이다. 데이터 관리 프로세스는 또한 덤프된 데이터를 다시 SQL 데이터베이스에 재삽입하는 역할을 수행한다. 이러한 기능은 필요시 데이터가 재분석되도록 경과 데이터의 재삽입을 가능케 하기 위해 존재한다. 재삽입되는 데이터는 구성가능한 슬라이딩 윈도우의 외부에 디폴트로 존재할 것이기 때문에 이 데이터는 데이터 관리 프로세스의 다음 동작시에도 아마도 다시 제거될 것이다.

연결 관리자 프로세스(57)은 진단 데이터베이스 서비스에 의해 제공되는 다양한 인터페이스들의 동작을 감독하는 역할을 수행한다. 이 구성요소는 중복적인 연결들을 검출하고 제거하는 역할과, 그리고 하나의 연결이 또 다른 연결의 동작에 양보하거나 또는 간섭하지 않도록 함을 보장하는 역할을 한다. 이 구성요소는 또한 또 다른 인터페이스에 대해 영향을 미치는 인터페이스들 중의 어느 것에 의해 수신되는 요구(request)들을 처리하는 역할을 수행한다. 예컨대, 분석 엔진(11)이 분석 엔진 서비스로부터 온-디맨드 데이터 수집을 위한 요구를 수령한다면, 어느 데이터 컬렉터 인터페이스로 그 요구를 보낼지를 결정하는 역할을 하는 것은 연결 관리자 프로세스(57)이다.

데이터 컬렉터 인터페이스는 진단 데이터베이스 서비스와 임의의 수의 데이터 컬렉터 서비스들 간의 통신을 유지하는 역할을 한다. 이 구성요소는 데이터 컬렉터 서비스들과 실제의 물리적 데이터 저장부(SQL 데이터베이스) 간의 분리 층을 제공하기 위해 존재한다. 이 구성요소는 그 데이터 컬렉터 서비스가 책임이 있는 데이터만 저장되고 있는 것을 보장하기 위해 데이터 컬렉터 서비스에 의해 이루어지는 저장에 대한 모든 요구들을 유효하게 하는 역할을 한다. 이것은 복수의 데이터 컬렉터 서비스들이 상호간의 데이터를 비의도적으로 망가뜨리지 않음을 보장하기 위해 이루어진다. 이 인터페이스는 또한 새로운 디바이스 타입들, 디바이스 인스턴스들, 또는 데이터 타입들을 정의하기 위해 데이터 컬렉터 서비스들에 의한 어떤 요구들을 유효하게 하는 역할을 수행한다. 이 인터페이스는 또한 분석 엔진 인터페이스가 온-디맨드 데이터 수집에 대한 요구를 수신할 때는 언제나 데이터 컬렉터 서비스들에 대한 통지를 처리한다.

분석 엔지 인터페이스(55)는 진단 데이터베이스 서비스와 임의의 수의 분석 엔진 서비스 간의 통신을 유지하는 역할을 한다. 이 구성요소는 분석 엔진 서비스들과 실제의 물리적 데이터 저장소(SQL 데이터베이스) 사이의 분리의 층을 제공하기 위해 존재한다. 이 구성요소는 분석 엔진에 의해 이루어지는 데이터와 규칙들에 대한 모든 요구들을 유효하게 하고 또한 그 요구들에 적절한 만큼의 서비스를 하는 역할을 수행한다. 부가적으로, 이 인터페이스는 온-디맨드 데이터 수집 통지들을 수신하고 그 통지들을 처리를 위해 연결 관리자 프로세스로 전달하는 것뿐만 아니라 그것들이 SQL 데이터베이스에 기록될 수 있도록 오류의 통지를 접수하는 역할을 수행한다.

워크스테이션 인터페이스(58)는 진단 데이터베이스 서비스와 임의의 수의 진단 워크스테이션들 간의 통신을 유지하는 역할을 수행한다. 이 구성요소는 진단 데이터베이스 서비스에 의해 유지되는 데이터가 진단 워크스테이션들에 의해 우연히 포함되지 않는 것을 확실히 하기 위해 존재한다. 이 구성요소는 진단 워크스테이션들에 의해 그것들의 동작 도중에 그 자신에 전송되는 모든 요구들을 실행할 것이다. 이러한 요구들은 아래와 같은 것들로 이루어진다;

- 워크스테이션 상에서의 분석 또는 보기를 위해 진단 데이터베이스 서비스로부터 데이터 세트를 가져오기(retrieving).

- 진단 워크스테이션의 로컬 저장소에 규칙들을 업로딩함(진단 데이터베이스 서비스에 의해 강력한 규칙들과 워크스테이션의 규칙들의 동기화).

- 진단 워크스테이션으로부터 진단 데이터베이스 서비스로의 새로운 규칙의 다운로딩.

- 진단 데이터베이스 서비스 상에서의 저장 및 기록보관을 위한 새로운 유지 레코드(maintenance records)들의 업로딩.

- 보기 위해 기록보관된 유지 레코드들을 가져오기.

- 진단 워크스테이션에 의해 직접적으로 수집된 데이터의 진단 데이터베이스 서버로의 업로딩.

규칙들을 처리하는 요구들은 하나의 "핵심적인(core)" 규칙 세트가 진단 데이터베이스 서비스 상에 존재하는 것을 가능케 하기 위해 존재하고, 반면에 각각의 진단 워크스테이션이 그 자신의 규칙 세트(메인 규칙들과 재동기화 될 수 있는)를 갖는 것을 가능하게 한다. 이러한 방식으로 분석 엔진 서비스에 의해 수행되는 온라인 데이터 분석의 완전무결성이 유지되는 한편, 진단 워크스테이션을 이용하는 유지기(maintainer)가 오프라인으로 새로운 규칙들을 생성하고 테스트하는 것을 가능케 한다.

새로운 규칙이 분석적인 가치를 갖는 것으로 판단되면, 이 규칙은 메인 규칙으로의 포함 및 온라인 데이터 분석을 하기 위하여 진단 데이터베이스 서비스로 전송될 수 있으며, 다른 진단 워크스테이션이 동기화를 실행함으로써 그 규칙을 획득할 수가 있다. 새로운 규칙이 진단 데이터베이스 서비스에 업로딩 될 때마다 기존 규칙들의 백업용 사본이 만들어지고 수정사항들은 SQL 데이터베이스에 기록된다.

분석 엔진 서비스(11)는 진단 데이터베이스 서비스에 의해 저장된 데이터를 분석하여 오류 또는 잠재적인 오류를 검출하고 그것에 대해 시스템의 사용자에게 통지하기 위해 사용된다. 상기한 진단 시스템은 임의의 수의 진단 서버들 상에 설치된 임의의 수의 분석 엔지 서비스들을 지원할 수 있다.

분석 엔진 서비스는 세 개의 구성요소들을 갖는다. 즉, 데이터베이스 서버 인터페이스(50), 분석 프로세스(들)(51), 및 분석 쓰레드 관리 프로세스(Analysis Thread Management Process)(53)이다.

데이터베이스 서버 인터페이스(50)는 진단 데이터베이스 서버와의 통신을 설정하고 유지하는 역할을 한다. 이 구성요소는 분석 엔진 서비스의 다른 구성요소들로부터의 모든 데이터 요구들을 처리하고, 또한 그 요구들을 포맷팅하고 그것들을 진단 데이터베이스 서버에 전송하는 역할을 한다. 마찬가지로, 이 구성요소는 그 요구를 일으켰던 구성요소에 진단 데이터베이스 서버에 대한 응답들을 다시 보내주는 역할을 수행한다. 데이터베이스 서버 인터페이스는 또 다른 장치에 이러한 요구들이 이루어지고 있다는 사실을 추출하는 한편 이러한 기능들을 제공하는 역할을 한다. 이때 분석 엔진 서비스의 다른 구성요소들에게는 상기 데이터 요구들이 로컬로 처리되고 있는 것처럼 보일 것이다.

분석 쓰레드 관리 프로세스(53)는 분석 프로세스(들)의 동작 및 동기화를 수행한다. 이 구성요소는 분석 엔진 서비스 내에서 현재 동작 중인 모든 분석 프로세스들을 개시하고 유지하는 역할을 수행한다. 이 구성요소는, 어느 한 분석 프로세스를 생성할 때, 동작시키고자 하는 규칙들 및 데이터 세트들의 큐를 그 프로세스에 제공할 것이다. 규칙들 및 데이터 세트들의 전체 큐가 적시에 분석되는 것을 보장하고 이것이 일어나게 할 충분한 분석 프로세스들 및 시스템들이 존재함을 보장하는 것은 상기한 분석 쓰레드 관리 프로세스의 역할이다.

분석 프로세스(들)(51)는 규칙들에 대한 데이터의 실질적인 분석을 하는 역할을 수행한다. 이 구성요소는 분석 쓰레드 관리 프로세스에 의해 그것에 제공되는 임무를 이행하기 위해 요구되는 대로 데이터베이스 서버 인터페이스로부터 데이터 및 규칙을 요구할 것이다. 분석 프로세스(들)(51)는 그러나 그것이 상기 임무를 어떻게 실행하는가에 대한 자율적인 컨트롤을 갖는다. 분석 프로세스가 문턱 조건이 도달되었다는 것을 검출하거나 또는 온-디맨드 데이터 수집이 요구된다면, 그것의 임무를 수정하고 및/또는 필요한 대로 온-디맨드 데이터 수집을 요구하는 것은 자유영역이다. 만일 분석 프로세스가 오류가 발생하였음을 검출한다면, 분석 프로세스는 ATS에 경보를 유발하고 데이터베이스 서버 인터페이스를 통해 그 경보를 기록하는 역할을 수행한다.

진단 워크스테이션들(13)은 유지보수 및 학술적 목적으로 진단 데이터베이스 서비스들에서 수집되는 데이터를 살펴보고 분석하는 데에 이용된다. 분석 시스템은, 어떤 하나의 물리적 PC 상에 설치된 단지 하나의 진단 워크스테이션만이 존재할지라도, 임의의 숫자의 진단 워크스테이션 인스턴스들을 지원할 수 있다. 진단 워크스테이션은 또한 그러한 PC들에 설치된 임의의 다른 소프트웨어에 추가하여 진단 서버들에 설치될 수도 있다.

이러한 진단 워크스테이션들은 하기의 다섯 개의 구성요소들을 갖는다. 즉, 데이터베이스 서버 인터페이스(63), 유지보수 기록 뷰어(Maintenance Log Viewer)(64), 규칙 편집기(66), 데이터 뷰어/분석기(68), 및 목표 디바이스 인터페이스(69)로 구성된다.

데이터베이스 서버 인터페이스(63)은 진단 데이터베이스 서버와의 통신을 설정하고 유지하는 역할을 한다. 이 구성요소는 진단 워크스테이션의 다른 구성요소들로부터의 모든 데이터 요구들이나 업로드들을 처리하고 그 요구들을 포맷팅하고 진단 데이터베이스 서버에 그 요구들을 전송하는 역할을 수행한다. 마찬가지로, 이 구성요소는 상기한 요구를 일으켰던 구성요소에 진단 데이터베이스 서버에 대한 응답들을 다시 발송하는 역할을 수행한다. 데이터베이스 서버 인터페이스는 또 다른 장치에 이러한 요구들이 이루어지고 있다는 사실을 추출하는 한편, 이러한 기능들을 제공하는 역할을 한다. 이때, 진단 워크스테이션의 다른 구성요소들에게는 상기 데이터 요구들이 로컬로 처리되고 있는 것처럼 보일 것이다.

유지보수 기록 뷰어(64)는 사용자가 진단 데이터베이스 서비스 상에 저장할 유지보수 레코드들을 생성하고 업데이트하는 것을 가능케 하기 위해 사용된다. 유지보수 레코드들은 진단 데이터베이스 서비스 상에 저장되고 어느 한 장치와 연관된다. 상기한 유지보수 기록 뷰어는 또한 보기(view) 위한 특정한 장치에 대해 진단 데이터베이스 서비스로부터 경과적 유지보수 레코드들을 가져오기 위해 사용될 수도 있다.

진단 워크스테이션의 규칙 편집기(66)은 사용자가 워크스테이션의 규칙의 로컬 저장부를 진단 데이터베이스 서비스에 의해 저장된 중앙 규칙 저장부와 동기화하는 것을 가능하게 한다. 진단 워크스테이션은 두 개의 다른 세트의 규칙들을 갖는다. 즉, 로컬에만 단지 존재하는 것들과, 그리고 중앙에 저장된, 로컬용의 사용자 수정형의 규칙들의 사본들이다. 동기화 동작은 상기한 중앙에 저장된 규칙들의 로컬 사본만을 혼합(merge)하는데, 이렇게 하여 동작이 완료될 때 상기 중앙에 저장된 규칙들의 로컬 사본은 진단 데이터베이스 서비스 상에 저장된 것들과 일치할 것이다. 이 구성요소는 또한 중앙 저장부로부터 받은 규칙들의 로컬 사본을 포함하여 진단 워크스테이션 상에 로컬로 저장된 규칙들을 살펴보고 수정하기 위해 사용될 수도 있다. 상기 구성요소는 또한 로컬만의 규칙 저장부 또는 중앙 규칙의 로컬 사본(동기화를 위해 그 규칙을 중앙에 플래그 제공함)에 있는 새로운 규칙들을 생성하기 위해 사용될 수도 있다.

데이터 뷰어/분석기(68) 구성요소는 진단 데이터베이스 서비스에 의해 저장된 데이터 또는 진단 데이터베이스 서비스에 의해 한 파일로 덤프된 데이터를 보기 위해 사용된다. 데이터는 이러한 방식으로 검출된 임의의 경보 또는 에러 조건들이 ATS로 전송되지 않을지라도 로컬 규칙 저장부로부터의 규칙들을 적용함으로써 분석되어도 좋다. 이것은 사용자가 오류성 또는 스퓨리어스성(spurious) 경보들을 유발하지 않고도 새로운 규칙들을 테스트하는 것을 가능하게 하기 위해 수행된다. 진단 데이터베이스 서비스 상의 데이터는 또한 사용자가 데이터 추세를 그래픽으로 볼 수 있게 하기 위해 추세 그래프로서 단순하게 보이게 할 수도 있다. 이러한 기능은 시스템 중의 어떤 요소들이 다소 자주 사용되는지를 분석함으로써 사용자가 예방적인 유지보수 전략을 세우는 것을 가능하게 하기 위해서 설계된다. 이것의 예를 들면, 어느 스위치들이 더 자주 움직이는지를 결정하고 그리고 덜 사용된 스위치 기계장치들은 건너서 해당 스위치 기구장치들에 대한 정비를 목표로 하는 것 등이다. 이 구성요소는 또한 사용자가 분석 엔진 서비스에 의해 진단 데이터베이스 서비스 상에 저장되었던 어떤 경보들을 살펴보는 것을 가능하게 한다. 이러한 경보의 통보들로부터 사용자는 그 경보를 유발하였던 특정 데이터 세트를 볼 수가 있다.

목표 디바이스 인터페이스(69)는 데이터 컬렉터 서비스가 어느 장치로부터 데이터를 가져오는 것이 불가능할 경우 그 장치로부터 데이터를 수집하는 역할을 한다. 이 구성요소는 다른 디바이스 타입으로부터의 데이터의 수집을 가능케 하기 위한 플러그-인(plug-in) 구조를 이용하여 설계된다. 상기한 플러그-인 구조는, 플러그가 데이터 컬렉터 서비스 그 자체가 수행하는 동일한 변환 기능들의 다수를 수행할 필요가 있기 때문에, 특정한 디바이스 타입에 대한 데이터 컬렉터 서비스의 일부로서 개발되기도 한다. 이 구성요소는 연결된 장치로부터 데이터를 수집하고 그리고 그 데이터가 데이터 컬렉터 서비스로부터 직접 나온 것처럼 진단 베이터베이스 서비스로 전송할 데이터를 포맷할 것이다. 데이터 컬렉터 서비스가 DCCD를 이용할 경우에는 목표 장치 인터페이스가 그 장치에 직접 연결되는 대신에 DCCD에 연결되어도 좋다.

규칙 편집기(66)는 두 개의 핵심적인 특징들, 즉 진단 워크스테이션의 로컬 규칙 저장부에 있는 규칙들의 진단 데이터베이스 서비스 상의 주요 규칙 저장부와의 동기화, 및 로컬 규칙들의 오프-라인 생성 및 수정을 제공한다.

도 6은 규칙 동기화 이벤트 동안에 일어나는 이벤트들의 시퀀스를 예시하고 있다. 사용자 통지 또는 스케줄이 있을 시, 규칙 편집기는 모든 규칙들 및 데이터 서버 인터페이스를 경유하는 진단 데이터베이스 서비스로부터의 그것들의 계층체계(hierarchy) 리스트를 요구할 것이다. 그 다음에 규칙 편집기는 중앙에 저장된 규칙들 및 그들의 계층체계의 로컬 사본을 가져올 것이다. 상기 규칙 편집기는 그 다음에 각 규칙별로(rule by rule basis) 어느 세트의 규칙들이 더 최근의 것인지를 결정하기 위해 양 세트의 규칙들을 분석할 것이다. 그 다음에는 각 세트로부터의 변화들이 결합되고 그 규칙들의 로컬 사본과 중앙 사본 양자가 업데이트 된다. 이것은 중요한 특징점이다. 중앙 규칙들이 반드시 로컬 규칙 세트 위에 반드시 오버라이트(overwrite) 되지는 않으며, 또한 로컬 세트의 규칙들도 중앙 규칙들 위에 오버라이트 되지는 않는다. 소정의 결합 연산(merge operation)이 어느 한쪽 위치로부터의 가장 최근의 변화가 보존되는 것을 보증하기 위해 수행된다. 규칙의 로컬 사본과 중앙본 사이의 충돌이 검출될 때는 언제든지 상기 중앙 규칙은 그 규칙의 로컬 사본 위에 오버라이트 될 것이다.

데이터 뷰어/분석기(68)은 두 가지의 기능들, 즉 진단 데이터베이스 서비스 상에 저장된 데이터의 그래픽 표현과 동일 데이터의 오프-라인 분석을 제공한다.

도 7은 데이터 뷰어/분석부의 사용시 일어나는 이벤트들의 시퀀스를 예시하고 있다. 사용자 선택시 또는 스케줄에 기초하여 데이터 뷰어/분석부는 이용 가능한 데이터 세트들의 리스트를 가져오기 위해 데이터 서버 인터페이스를 경유해 진단 데이터베이스 서비스에 질문할 것이다. 이 정보가 리턴 될 때 데이터 뷰어/분석부는 그것의 로컬 데이터 저장부에 이용가능한 데이터 세트를 저장할 것이다. 그 다음으로 사용자는 로컬 데이터 저장부에 저장된 정보에 기초하여 보고자 하는 데이터 세트들의 리스트를 선택할 수도 있다. 일단 사용자가 선택을 하고나면, 요구된 데이터 세트들은 데이터 서버 인터페이스를 경유해 진단 데이터베이스 서비스로부터 검색될(retrieved) 것이다. 일단 선택된 데이터가 검색되고나면 이 데이터는 또한 로컬 저장부에 저장될 것이다. 이러한 디자인 결정의 저변에 있는 논리는, 로컬 자원을 사용하면 데이터 조작이 더 빠르다는 것과, 그리고 이러한 데이터가 존재하게 함으로써 미래의 사용자가 그것을 보기를 원한다면 그 데이터는 진단 데이터베이스 서버로부터 다시 전달될 필요가 없다는 것이다.

일단 사용자 선택 데이터가 로컬 데이터 저장부에 삽입되고나면, 데이터 뷰어/분석부는 그 데이터를 가져와서 사용자의 선택에 기초하여 그것을 데이터 리스트 또는 그래프로서 디스플레이할 것이다. 데이터 뷰어/분석부는 또한 사용자가 데이터 세트에 대해서 동작시킬 하나 또는 다수의 규칙들을 선택하는 것을 가능하게 한다. 사용자에게 제공된 규칙들의 리스트는 로컬 규칙 저장부에 현재 존재하는 규칙들에 기초하고 있다. 일단 사용자가 일 세트의 규칙들을 선택하고나면 그 규칙들은 선택된 데이터 세트에 대해 동작 될 것이며 그 분석의 결과가 사용자에게 제공될 것이다.

분석 엔진 서비스는 고장을 검출하고 그 고장들을 보고하기 위한 목적으로 저장된 진단 정보를 온라인으로 분석하는 역할을 수행한다. 도 8에 도시된 분석 쓰레드 관리 프로세스는 그의 구성된 큐들의 규칙 프로세싱 할당(rule processing allotments)들을 통해 계속해서 반복할 것이며 모든 큐들이 분석 프로세스에 할당되고 실행되고 있음을 보장해줄 것이다. 만일 하나의 규칙 큐도 액티브 상태의 프로세스에 할당되지 않는다면, 상기 분석 쓰레드 관리 프로세스는 새로운 분석 프로세스를 예시하고 그것에다가 그 큐를 할당할 것이다.

상기한 새로 생성된 분석 프로세스는 그것에 주어진 큐들을 분석하고 어떤 규칙들과 데이터 세트들이 그 큐에 있는 다음 규칙을 처리하기 위해 필요한지를 결정할 것이다. 그것은 다음으로는 데이터 서버 인터페이스에 적절한 데이터를 가져오도록 통보할 것이다. 일단 상기 데이터가 분석 프로세스에 복귀되고나면 그것은 데이터가 규칙을 패스할 것인지 아니지 여부를 결정하기 위해 규칙들을 실행할 것이다. 이 시점에서 상기 분석 프로세스는 후속되는 많은 분기(branches)들을 갖는다. 만일 상기 데이터가 규칙을 패스한다면, 분석 프로세스는 단순히 작동할 다음 규칙을 결정하고, 이러한 다음 규칙을 위해 취해진 바로 직전의 동작을 반복할 것이다. 만일 데이터 세트가 그 규칙을 패스하지 못하면, 세 개의 일 중의 하나가 일어날 것이다. 만일 그 규칙이 어느 고장이 차일드(child) 규칙들의 프로세싱을 개시할 것이라고 지정한다면, 상기 분석 프로세스는 단순히 그 차일드 규칙 경로를 실행하기를 시작할 것이다. 만일 그 규칙이 온-디맨드 데이터 수집을 유발한다면, 상기 분석 프로세스는 데이터 서버 인터페이스에 그러한 것을 위한 요구를 발생할 것이다. 데이터 서버 인터페이스는 이 요구를 진단 데이터베이스 서비스에 중계할 것이다. 상기 분석 프로세스는 다음에는 그 규칙이 패스 되거나 실패하여 다른 반응을 유발하도록 하는 그러한 시점까지 어떤 새로운 이용가능한 데이터를 이용하여 이 규칙을 계속해서 재분석할 것이다. 만일 그 규칙이 어느 한 고장은 경보로 귀결되어야 한다고 지정한다면, 상기 분석 프로세스는 ATS에 경보를 발생할 뿐만 아니라 그 경보 및 그에 관한 모든 특정사항들을 데이터베이스 서버 인터페이스를 통해 진단 데이터베이스 서비스에 기록할 것이다.

분석 프로세스는 분석 쓰레드 관리 프로세스가 종료를 지시할 때까지 또는 그에 할당된 큐가 종료해야만 한다고 지정할 때까지 계속해서 규칙들의 큐를 실행할 것이다.

데이터 컬렉터 서비스들은 모니터 된 장치들로부터 데이터를 가져와서 그 데이터를 진단 데이터베이스 서비스에 저장하기 위해 사용된다. 이러한 인터페이스 설명은, 어떤 그러한 원거리 데이터 수집도 불필요한 경우에 이벤트들의 시퀀스가 유사할지라도 디스플레이된 데이터 컬렉터 서비스는 데이터 수집/연결 장치(Data Collection/Concatenation Device)를 사용한다고 가정한다. 도 9에 도시된 목표 데이터 컬렉션 프로세스 및 데이터베이스 서비스 인터페이스 각각은 외부 영향에 관계없이 그 자신의 내부 스케줄로 동작한다. 데이터베이스 서버 인터페이스는 어떤 데이터가 포맷팅에 이용가능한지를 알기 위해 정기적으로 내부 데이터 스테이징/저장부를 점검할 것이다. 만일 데이터가 발견되면, 데이터베이스 서비스 인터페이스는 그 데이터를 처리하고 진단 데이터베이스 서비스로의 전송을 위해 그것을 포맷팅 할 것이다. 일단 하나의 데이터 세트가 전송되고나면, 데이터베이스 서비스 인터페이스는 처리된 대로 소스 데이터에 플래그(flag)를 제공함으로써 기록보관을 위해 그것을 표시(marking)할 것이다.

목표 데이터 수집 프로세스는 모니터 되는 장치들로부터 데이터를 가져오기 위해 사용되는 내부 스케줄을 동작시킨다. 이 스케줄은 데이터 컬렉터 서비스의 각각의 구현에 대해 특정적이다. 어떤 시점에서 목표 데이터 컬렉션 프로세스는 진단 정보를 위한 지정된 장치에 질문할 시점이라고 판단할 것이다. 그 시점에서 목표 데이터 컬렉션 프로세스는 모니터 되는 장치로부터 진단 정보를 가져올 것이다. 전술한 도면에서 이것은 상기한 데이터 수집/연결 장치를 통해 수행된다. 그 수행 결과, 목표 데이터 컬렉션 프로세스가 데이터베이스 서비스 인터페이스에 의해 획득될 내부 데이터 스테이징/저장부에 그것이 저장하는 진단 데이터를 가져올 것이다.

진단 데이터베이스 서버는 그 자신의 내부 프로세싱 도중에 데이터베이스 서비스 인터페이스를 경유해 데이터 컬렉터 서비스에 대한 온-디맨드 데이터 수집 통보를 중계할 수도 있다. 이것이 발생할 때, 데이터베이스 서비스 인터페이스는 온-디맨드 데이터 수집 프로세스에 그 통보를 중계할 것이다. 상기한 온-디맨드 데이터 수집 프로세스는 목표 데이터 수집 프로세스에 그것의 내부 스케줄을 정지하고 지정된 장치로부터 진단 데이터를 가져오기를 개시하라고 통보할 것이다. 이 과정은 데이터베이스 서비스 인터페이스가 온-디맨드 데이터 수집을 종료하도록 하는 진단 데이터베이스 서비스로부터의 통보를 수신하는 그러한 시점까지 계속될 것이다.

여기에 개시된 임의의 블록 다이어그램들은 본 발명의 원리를 실시하는 예시적인 회로에 대한 개념적인 도면들을 나타내고 있음을 당해 기술분야의 전문가라면 이해할 것이다. 본 발명은 적절한 소프트웨어와 연합하여 소프트웨어를 실행할 수 있는 하드웨어뿐만 아니라 전용 하드웨어를 이용하여 제공될 수도 있는 하나의 프로세서 상에서 구현될 수도 있을 것이다. 프로세서에 의해 제공될 경우, 그 기능들은 단일-칩 전용 프로세서에 의해, 단일-칩 공유 프로세서에 의해, 또는 다수의 개별 프로세서들(그들 중의 어떤 것은 공유될 수도 있음)에 의해 제공될 수도 있다. 더욱이, 여기서 "프로세서(processor)"라는 용어가 명시적으로 사용된다 하더라고 그것이 소프트웨어를 실행할 수 있는 하드웨어만을 배타적으로 지칭하는 것으로서만 해석되어서는 안 될 것이며, 그것은 디지털 신호처리 프로세서(DSP) 하드웨어 장치, 네트워크 프로세서, 애플리케이션 전용 집적회로(ASIC), 필드 프로그래머블 게이트 어레이(FPGA), 소프트웨어 저장용 읽기전용 메모리(ROM), 랜덤 액세스 메모리(RAM), 및 비휘발성 저장장치 등을 제한 없이 망라할 수도 있을 것이다. 통상적 및/또는 관행적인 여타 하드웨어들도 또한 포함될 수 있을 것이다. 여기서 "회로(circuit)"라는 용어는 실제로 소프트웨어로서 구현될 수도 있는 기능적인 블록들을 모두 포함하는 개념으로 사용된다.

Claims (32)

1. 다수의 장치들로부터의 데이터를 분석하기 위한 데이터 분석 시스템으로서,
   상이한 장치들로부터 수집된 데이터를 저장하는 데이터 저장 서브시스템을 포함하되, 상기 데이터는 그 데이터를 분류하기 위한 프리미티브(primitive)들을 이용하여 메타 구조(meta-structure)로 저장되는 것인 데이터베이스 서비스 모듈; 및
   상기 메타 구조에 의해 정의되는 데이터가 저장된 규칙들의 세트에 따라서 소정의 기준을 만족하는지의 여부를 결정하기 위해 상기 데이터를 분석하기 위한 분석 엔진을 포함하는 데이터 분석 시스템.
2. 제1항에 있어서, 상기 프리미티브들은 디바이스 타입(device type), 디바이스 인스턴스(device instance), 및 데이터 타입(data type)을 포함하되, 상기 디바이스 타입은 상기 데이터의 소스인 장치의 타입을 결정하고, 상기 디바이스 인스턴스는 상기 데이터의 소스인 디바이스 타입 내에서 특정 장치를 식별하고, 그리고 상기 데이터 타입은 저장된 데이터의 특성을 지시하는 것인 데이터 분석 시스템.
3. 제2항에 있어서, 상기 디바이스 타입은 상기 데이터의 소스를 구성하는 장치의 상태를 포함하는 데이터 분석 시스템.
4. 제1항 내지 제3항 중의 어느 한 항에 있어서, 상기 규칙들은 상기 데이터베이스 서비스 모듈의 일부를 형성하는 데이터베이스에 저장되는 것인 데이터 분석 시스템.
5. 제1항 내지 제4항 중의 어느 한 항에 있어서, 상기 데이터베이스 서비스 모듈은 데이터 컬렉터를 경유해 복수의 장치들로부터 데이터를 수신하고 그리고 상기 메타 구조에 따라서 상기 데이터 저장 서브시스템에 상기 데이터를 저장하기 위한 데이터 관리 프로세싱 모듈 및 데이터 컬렉터 인터페이스를 더 포함하는 데이터 분석 시스템.
6. 제1항 내지 제5항 중의 어느 한 항에 있어서, 상기 데이터 저장 서브시스템은 SQL 데이터베이스인 데이터 분석 시스템.
7. 제1항 내지 제6항 중의 어느 한 항에 있어서, 상기 분석 엔진은, 어느 디바이스 타입 또는 디바이스 인스턴스에 대해서 어떤 순서로 어느 규칙들이 동작될 것인지, 그리고 어떤 빈도로 상기 규칙들이 처리될 것인지를 판단하기 위한 분석 엔진 관리부를 포함하는 데이터 분석 시스템.
8. 제7항에 있어서, 상기 분석 엔진 관리부는 상기 분석 엔진 관리부에 의해 그에 할당되는 규칙들을 처리하기 위한 분석 큐 모듈을 더 포함하는 데이터 분석 시스템.
9. 제8항에 있어서, 상기 분석 큐 모듈은 소정의 기준을 충족시키는 상기 처리된 데이터에 경보 통지를 부여하도록 구성되는 것인 데이터 분석 시스템.
10. 제9항에 있어서, 상기 분석 큐 모듈은 소정의 기준을 충족하는 상기 처리된 데이터에 응답하여 다른 규칙들의 프로세싱을 유발하도록 구성되는 것인 데이터 분석 시스템.
11. 제9항에 있어서, 상기 분석 큐 모듈은 소정의 기준을 충족하는 소정의 규칙 하에 처리된 데이터에 응답하여 온-디맨드(on-demand) 데이터 수집을 유발하도록 구성되는 것인 데이터 분석 시스템.
12. 제11항에 있어서, 상기 분석 큐 모듈은 상기한 소정의 규칙 하에 처리된 데이터보다 더 높은 빈도로 상기 온-디맨드 데이터의 프로세싱을 유발하도록 구성되는 것인 데이터 분석 시스템.
13. 제5항에 있어서, 디바이스 인터페이스를 통해 상기 다수의 장치들로부터의 데이터의 수집을 관리하고 그리고 데이터베이스 서비스 인터페이스를 통해 상기 데이터베이스 서비스 모듈과 통신하기 위한 데이터 수집 관리부를 포함하는 데이터 수집 서비스 모듈을 더 포함하는 데이터 분석 시스템.
14. 제13항에 있어서, 상기 데이터 수집 서비스 모듈은 상기 데이터베이스 서비스 모듈로 전송하기 전에 데이터를 일시적으로 스테이징(staging)하기 위한 데이터 스테이지 모듈을 포함하는 데이터 분석 시스템.
15. 제13항에 있어서, 데이터 분석 시스템은 사용자가 상기 데이터베이스 서비스 모듈에 저장된 데이터를 보는 것과 그리고 상기 분석 엔진에 의해 이용될 규칙들을 구성하는 것을 가능하게 하는 워크스테이션 모듈을 더 포함하는 데이터 분석 시스템.
16. 제1항 내지 제15항 중의 어느 한 항에 있어서, 상기 워크스테이션은 사용자가 상기 데이터베이스 서비스 모듈에 의해 저장된 특정 데이터에 대해 지정된 규칙들을 동작시키는 것을 가능하도록 구성된 것인 데이터 분석 시스템.
17. 다수의 장치들로부터의 데이터를 분석하는 방법으로서,
    상이한 장치들로부터 계속 진행형으로 데이터를 수집하는 과정;
    상기 데이터를 분류하기 위해 프리미티브들을 이용하는 메타 구조로 데이터베이스 서비스 모듈의 데이터 저장 서브시스템에 상기 수집된 데이터를 저장하는 과정; 및
    상기 메타 구조에 의해 정의되는 데이터가 저장된 규칙들의 세트에 따라서 소정의 기준을 만족하는지 여부를 판단하기 위해 상기 데이터를 분석하는 과정을 포함하는 데이터 분석 방법.
18. 제17항에 있어서, 상기 프리미티브들은 디바이스 타입(device type), 디바이스 인스턴스(device instance), 및 데이터 타입(data type)을 포함하되, 상기 디바이스 타입은 상기 데이터의 소스인 장치의 타입을 결정하고, 상기 디바이스 인스턴스는 상기 데이터의 소스인 디바이스 타입 내에서의 특정 장치를 식별하고, 그리고 상기 데이터 타입은 상기 저장된 데이터의 특성을 지시하는 것인 데이터 분석 방법.
19. 제17항 또는 제18항에 있어서, 상기 디바이스 타입은 상기 데이터의 소스를 구성하는 장치의 상태를 포함하는 데이터 분석 방법.
20. 제17항 내지 제19항 중의 어느 한 항에 있어서, 상기 데이터베이스 서비스 모듈의 일부를 형성하는 데이터베이스 내에 상기 규칙들을 저장하는 과정을 더 포함하는 데이터 분석 방법.
21. 제17항 내지 제20항 중의 어느 한 항에 있어서, 상기 분석 엔진은, 어느 디바이스 타입 또는 디바이스 인스턴스에 대해서 어떤 순서로 어느 규칙들이 동작 될 것인지, 그리고 어떤 빈도로 상기 규칙들이 처리될 것인지를 판단하는 데이터 분석 방법.
22. 제21항에 있어서, 상기 분석 엔진 모듈은 소정의 기준을 충족시키는 상기 처리된 데이터에 경보 통지를 부여하는 것인 데이터 분석 방법.
23. 제22항에 있어서, 상기 분석 엔진은 소정의 기준을 충족하는 상기 처리된 데이터에 응답하여 다른 규칙들의 프로세싱을 유발하는 것인 데이터 분석 방법.
24. 제22항에 있어서, 상기 분석 엔진은 소정의 기준을 충족하는 소정의 규칙 하에 처리된 데이터에 응답하여 온-디맨드 데이터 수집을 유발하는 것인 데이터 분석 방법.
25. 제24항에 있어서, 상기 분석 엔진은 상기한 소정의 규칙 하에 처리된 데이터보다 더 높은 빈도로 상기 온-디맨드 데이터의 프로세싱을 유발하는 것인 데이터 분석 방법.
26. 제17항 내지 제25항 중의 어느 한 항에 있어서, 상기 수집된 데이터는 상기 데이터베이스 서비스 모듈로 전송하기 전에 데이터를 일시적으로 스테이징(staging)하도록 하는 데이터 분석 방법.
27. 제17항 내지 제19항 중의 어느 한 항에 있어서, 데이터 분석 방법은 사용자가 볼 수 있게 하기 위하여 상기 데이터베이스 서비스 모듈에 저장된 데이터를 제공하는 과정을 더 포함하는 데이터 분석 방법.
28. 제17항 내지 제27항 중의 어느 한 항에 있어서, 데이터 분석 방법은 사용자 인터페이스를 통해 상기 분석 엔진에 의해 사용될 규칙들을 구성하는 과정을 더 포함하는 데이터 분석 방법.
29. 제28항에 있어서, 데이터 분석 방법은 사용자 인터페이스를 통해 상기 데이터베이스 서비스 모듈에 의해 저장된 특정 데이터에 대하여 지정된 규칙들의 작동을 명령하는 과정을 더 포함하는 데이터 분석 방법.
30. 다수의 장치들로부터의 데이터를 분석하기 위한 데이터 분석 시스템으로서,
    상이한 장치들로부터 계속적인 진행형으로 데이터를 수집하기 위한 데이터 컬렉터;
    상이한 장치들로부터 수집된 데이터를 저장하는 데이터 저장 서브시스템을 포함하되, 상기 데이터는 그 데이터를 분류하기 위한 프리미티브(primitive)들을 이용하여 메타 구조(meta-structure)로 저장되는 것인 데이터베이스 서비스 모듈;
    상기 메타 구조에 의해 정의되는 데이터가 저장된 규칙들의 세트에 따라서 소정의 기준을 만족하는지의 여부를 결정하기 위해 상기 데이터를 분석하기 위한 분석 엔진; 및
    상기 시스템의 동작을 컨트롤하기 위한 사용자 인터페이스를 제공하는 워크스테이션을 포함하는 데이터 분석 시스템.
31. 제30항에 있어서, 상기 워크스테이션은 사용자가 상기 저장된 규칙들의 세트를 생성하고 수정하는 것을 가능하게 하도록 구성되는 것인 데이터 분석 시스템.
32. 제30항 또는 제31항에 있어서, 상기 워크스테이션은 상기 시스템에 저장된 특정 규칙들을 사용자가 작동시키는 것을 가능하게 하도록 구성되는 것인 데이터 분석 시스템.

Images