KR102166098B1 - 클라이언트에게 현재 데이터 및 과거 데이터를 제공하기 위한 서버 시스템 - Google Patents

Abstract

본 발명은 데이터 서버(124)에서 수신된 서버 요청(122)을 취급하기 위한 방법 및 장치에 관한 것이다. 데이터 서버(124)는 정책 요청 취급자(140)를 구비하여 구성된다. 정책 요청 취급자(140)는 데이터 서버(124)에서 수신되는 서버 요청(122)에 응답하여 데이터 서버(124) 내에서 활성화된다. 정책 요청 취급자(140)는 다수의 비동기 데이터 스트림(801)을 수신하도록 구성된다. 정책 요청 취급자(140)는 시간-순서화된 데이터 포인트(811)를 형성하도록 함께 다수의 비동기 데이터 스트림(801)의 데이터 포인트를 합병하도록 더 구성된다. 정책 요청 취급자(140)는 시간-순서화된 데이터 포인트(811)를 이용해서 서버 요청(122)에서 식별된 서버 정책(128)에 따라 정책-기반 데이터를 형성하도록 더 구성된다.

Description

클라이언트에게 현재 데이터 및 과거 데이터를 제공하기 위한 서버 시스템{SERVER SYSTEM FOR PROVIDING CURRENT DATA AND PAST DATA TO CLIENTS}

본 발명은 일반적으로 서버 시스템에 관한 것으로, 특히 데이터 공급자(data providers) 및 클라이언트(clients) 양쪽과 통신하는 서버 시스템에 관한 것이다. 특히, 본 발명은 클라이언트에 의해 요청된 정책들에 따라 클라이언트에게 데이터를 제공하는 것에 의해 클라이언트로부터 데이터를 위한 동시 요청(concurrent requests)에 응답활 수 있는 서버 시스템에 관한 것이다.

여러 형태의 서버 및 서버의 그룹이 클라이언트 어플리케이션에 데이터를 제공하는데 이용될 수 있다. 특정 서버에 대해 호스트된(hosted) 데이터는 소정 수의 데이터의 소스로부터 수신될 수 있다. 예컨대, 하나 이상의 서버는 비행 동안 항공기 기내의 비행 데이터 레코더(flight data recorder) 및 획득 시스템(acquisition system)으로부터 획득된 데이터를 호스트하는데 이용될 수 있다. 이들 하나 이상의 서버는 소정 수의 라이브 서버(live servers), 이력 서버(historical servers), 라이브/이력 서버, 및/또는 다른 형태의 서버를 포함할 수 있다.

여기서 이용된 바와 같이, "라이브 서버(live server)"는 오직 클라이언트 어플리케이션에 라이브 데이터(live data)를 제공할 수 있는 서버이다. 실시간 데이터(real-time data)로 또한 언급될 수 있는 라이브 데이터는 데이터가 발생 또는 수집된 후 실질적으로 즉각적으로 클라이언트 어플리케이션에 전달되는 데이터일 수 있다. 예컨대, 비행 데이터 레코더로부터 획득된 라이브 서버 호스팅 데이터(live server hosting data)는 데이터가 소정의 심각한 시간 지연 또는 처리 지연 없이 비행 데이터 레코더에 의해 기록됨에 따라 클라이언트 어플리케이션에 이 데이터를 제공할 수 있다.

여기서 이용된 바와 같이, "이력 서버(historical server)"는 오직 클라이언트 어플리케이션에 이력 데이터, 또는 지연된 데이터만을 제공할 수 있는 서버이다. 예컨대, 이력 서버는 날씨 모니터링 시스템으로부터 온도 측정(temperature measurements)을 수신할 수 있다. 클라이언트 어플리케이션에 의한 이들 온도 측정에 대한 요청에 따라, 이력 서버는 30분 지연 후 클라이언트 어플리케이션으로 온도 측정을 제공할 수 있다.

여기서 이용된 바와 같이, "라이브/이력 서버"는 클라이언트 어플리케이션으로 라이브 데이터 및 이력 데이터 양쪽을 동시에 제공할 수 있는 서버이다. 라이브/이력 서버는 라이브 데이터를 수신할 수 있고 이력 데이터로서 라이브 데이터를 저장할 수 있다. 라이브/이력 서버는, 특정 요청이 클라이언트 어플리케이션에 의해 이루어지는 것에 따라, 라이브 데이터가 수신됨에 따라 클라이언트 어플리케이션으로 라이브 데이터를 제공하거나 클라이언트 어플리케이션으로 이력 데이터를 제공할 수 있다.

테스팅 시스템, 모니터링 시스템, 건전성 정보 모니터링 시스템(health information monitoring systems), 및/또는 다른 형태의 데이터 수집 및 분석 시스템은 데이터에 따라 클라이언트 어플리케이션을 서비스하기 위해 라이브 서버, 이력 서버, 라이브/이력 서버, 및/또는 다른 형태의 서버의 소정 조합을 이용할 수 있다. 그러나, 몇몇 현재 이용가능한 서버는 원하는 만큼 빠르게 및/또는 효율적으로 클라이언트 어플리케이션에 의해 선택된 방법으로 동시에 다중 클라이언트 어플리케이션으로 데이터를 제공하는 것이 불가능할 수 있다. 예컨대, 몇몇 현재 이용가능한 서버는 원하는 만큼 빠르게 및/또는 효율적으로 라이브 데이터 및 이력 데이터 양쪽에 대한 동시 요청에 응답하는 것이 불가능할 수 있다.

더욱이, 몇몇 경우에 있어서, 데이터 스트림(data streams)이 비동기적으로 서버에서 수신될 수 있다. 예컨대, 하나의 데이터 스트림이 하나의 데이터 속도(data rate)로 서버에서 수신될 수 있는 반면, 다른 데이터 스트림이 시간 경과에 따라 변하는 다른 데이터 속도로 서버에서 수신될 수 있다. 몇몇 현재 이용가능한 라이브/이력 데이터 서버는 라이브/이력 데이터 서버에 대한 내부적 또는 외부적 클럭에 의해 나타내어진 시간을 기초로 비동기적으로 수신되었던 데이터를 동기화할 수 있다. 즉, 이들 데이터 서버는 데이터와 관련된 타임스탬프(timestamps)를 원래로 유지하는 것이 불가능할 수 있다.

더욱이, 이들 현재 이용가능한 라이브/이력 데이터 서버는 데이터가 클라이언트-특정 데이터 속도(client-specified data rates)로 클라이언트에게 보내짐을 요청하는 클라이언트로부터의 요청을 처리하는 것이 불가능할 수 있다. 부가적으로, 몇몇 현재 이용가능한 라이브/이력 시스템은 여러 개의 다른 하드웨어를 가로질러 가변가능(scalable) 또는 분배가능할 수 없다. 따라서, 상기 논의된 적어도 몇몇 문제뿐만 아니라 다른 가능한 문제를 고려하는 방법 및 장치를 갖는 것이 바람직하다.

본 발명은 상기한 점을 감안하여 발명된 것으로, 클라이언트에게 현재 데이터 및 과거 데이터를 제공하기 위한 서버 시스템을 제공함에 그 목적이 있다.

하나의 실례로 되는 실시예에 있어서, 데이터 서버는 정책 요청 취급자를 포함한다. 정책 요청 취급자는 데이터 서버에서 수신되는 서버 요청에 응답하여 데이터 서버 내에서 활성화된다. 정책 요청 취급자는 다수의 비동기 데이터 스트림을 수신하도록 구성된다. 정책 요청 취급자는 시간-순서화된 데이터 포인트를 형성하도록 함께 다수의 비동기 데이터 스트림으로 데이터 포인트를 합병하도록 더 구성된다. 정책 요청 취급자는 시간-순서화된 데이터 포인트를 이용해서 서버 요청에서 식별된 서버 정책에 따라 정책-기반 데이터를 형성하도록 더 구성된다. 본 발명의 다른 측면에 있어서, 데이터 서버는 바람직하기는 시간-순서화된 데이터 포인트 및 보간을 이용해서 식별된 다수의 데이터 값을 수신할 수 있다. 서버 관리자가 정책 요청 취급자를 활성화시키는 점에서, 바람직하기는 정책 요청 취급자는 정책-기반 데이터를 이용해서 정책 요청 취급자로부터 클라이언트로 전송을 위한 출력 데이터를 형성하는 출력 패킷화기를 더 구비하여 구성되고, 더욱 바람직하기는 정책 요청 취급자는 서버 요청이 형성되었던 정책 요청을 발생시키는 클라이언트에게 정책-기반 데이터를 제공한다. 정책 요청 취급자가 데이터 포인트를 수신하는 점에서, 바람직하기는 다수의 비동기 데이터 스트림의 각 데이터 포인트는 데이터 값이 획득되었던 시간을 나타내는 시간 값 및 데이터 값을 포함한다.

다른 실례로 되는 실시예에 있어서, 서버 시스템은 서버 콘트롤러 및 데이터 서버의 세트를 포함한다. 서버 콘트롤러는 클라이언트로부터 정책 요청을 수신하도록 구성된다. 서버 콘트롤러는 정책 요청을 기초로 다수의 서버 요청을 발생시키기 위해 더 구성된다. 데이터 서버의 세트의 데이터 서버는 서버 관리자 및 정책 요청 취급자를 포함한다. 서버 관리자는 다수의 서버 요청의 서버 요청을 수신하는 것에 응답하여 다수의 정책 요청 취급자를 활성화시킨다. 다수의 정책 요청 취급자의 정책 요청 취급자는 다수의 비동기 데이터 스트림을 수신하도록 구성된다. 다수의 정책 요청 취급자의 정책 요청 취급자는 시간-순서화된 데이터 포인트를 형성하기 위해 함께 다수의 비동기 데이터 스트림의 데이터 포인트를 합병하도록 더 구성된다. 다수의 정책 요청 취급자의 정책 요청 취급자는 시간-순서화된 데이터 포인트를 이용해서 서버 요청에서 식별된 서버 정책에 따라 정책-기반 데이터를 형성하도록 더 구성된다. 다수의 정책 요청 취급자의 정책 요청 취급자는 출력 데이터로서 클라이언트에게 정책-기반 데이터를 보내도록 더 구성된다.

또 다른 실례로 되는 실시예에 있어서, 데이터 서버에서 수신된 서버 요청을 취급하기 위한 방법이 제공된다. 데이터 서버 내의 정책 요청 취급자는 서버 요청을 수신하는 것에 응답하여 활성화된다. 다수의 비동기 데이터 스트림이 정책 요청 취급자에서 수신된다. 다수의 비동기 데이터 스트림의 데이터 포인트는 시간-순서화된 데이터 포인트를 형성하기 위해 정책 요청 취급자에 의해 함께 합병된다. 정책-기반 데이터는 시간-순서화된 데이터 포인트를 이용해서 서버 요청에서 식별된 서버 정책에 따라 정책 요청 취급자에 의해 형성된다.

특징 및 기능은 본 발명의 다양한 실시예에서 독립적으로 달성될 수 있거나 더욱 상세한 내용이 이하의 설명 및 도면을 참조하여 알 수 있는 또 다른 실시예에 결합될 수 있다.

도 1은 실례로 되는 실시예에 따른 블록도 형태의 정보 관리 환경(information management environment)의 실례이다.
도 2는 실례로 되는 실시예에 따른 블록도 형태의 정책 요청(policy request)의 실례이다.
도 3은 실례로 되는 실시예에 따른 정보 관리 환경의 실례이다.
도 4는 실례로 되는 실시예에 따른 데이터 서버 및 서버 콘트롤러의 실례이다.
도 5는 실례로 되는 실시예에 따른 데이터 서버의 더욱 상세한 실례이다.
도 6은 실례로 되는 실시예에 따른 구성 정보(configuration information)의 실례이다.
도 7은 실례로 되는 실시예에 따른 데이터 서버의 서버 관리자(server manager)의 실례이다.
도 8은 실례로 되는 실시예에 따른 정책 요청 취급자(policy request handler)의 실례이다.
도 9은 실례로 되는 실시예에 따른 데이터 합병기(data merger)의 실례이다.
도 10은 실례로 되는 실시예에 따른 정책 기반 데이터 관리자(policy-based data manager)의 실례이다.
도 11은 실례로 되는 실시예에 따른 플로우차트 형태의 클라이언트에게 데이터를 제공하기 위한 프로세스의 실례이다.
도 12는 실례로 되는 실시예에 따른 플로우차트 형태의 서버 요청을 취급하기 위한 프로세스의 실례이다.
도 13은 실례로 되는 실시예에 따른 플로우차트 형태의 정책 기반 데이터를 형성하기 위한 프로세스의 실례이다.
도 14는 실례로 되는 실시예에 따른 블록도 형태의 데이터 처리 시스템의 실례이다.

이하, 예시도면을 참조하면서 본 발명에 따른 각 실시예를 상세히 설명한다.

여러 실례로 되는 실시예는 여러 고려를 인식 및 참작한다. 예컨대, 실례로 되는 실시예는 다중 클라이언트 어플리케이션을 서비스하는 것과 이들 클라이언트 어플리케이션으로부터 라이브 데이터 및/또는 이력 데이터에 대한 동시 요청에 응답하는 것을 가능하게 하는 서버 시스템을 갖는 것이 바람직할 수 있음을 인식 및 참작한다. 더욱이, 실례로 되는 실시예는 시간에 관하여 클라이언트 어플리케이션에 보내진 데이터를 동기화할 수 있는 서버 시스템을 갖는 것, 또는 데이터에 의해 표현된 파라미터 또는 정보 또는 데이터의 콘텐츠에 따라 데이터를 일정한 순서로 배열하는 것이 바람직할 수 있음을 인식 및 참작한다.

예컨대, 서버는 초 당 약 1000개의 샘플의 데이터 속도로 제1 센서 장치에 의해 발생된 제1 출력 신호의 샘플과 초 당 약 500개의 샘플의 데이터 속도로 제2 센서 장치에 의해 발생된 제2 출력 신호의 샘플을 수신할 수 있다. 그러나, 클라이언트 어플리케이션은 초 당 약 100개의 샘플의 데이터 속도로 제1 출력 신호의 샘플과 제2 출력 신호의 샘플 양쪽을 수신하는 것을 원할 수 있다. 실례로 되는 실시예는 이들 샘플을 처리하고 클라이언트 특정 데이터 속도(client-specified data rate)로 일시적으로 동기화된 방식으로 클라이언트 어플리케이션에게 요청된 데이터를 보내는 것이 가능한 서버를 갖는 것이 바람직할 수 있음을 인식 및 참작한다. 따라서, 실례로 되는 실시예는 클라이언트로부터 데이터 요청을 취급하기 위해 서버 시스템을 제공한다. 이러한 서버 시스템이 이하 도 1에서 설명된다.

도면, 특히 도 1을 참조하면, 정보 관리 환경의 실례가 실례로 되는 실시예에 따라 블록도의 형태로 도시된다. 정보 관리 환경(information management environment; 100)은 서버 시스템(server system; 102), 클라이언트의 세트(set of clients; 104), 및 데이터 공급자의 세트(set of clients; 106)를 포함한다. 여기서 이용된 바와 같이, 아이템의 "세트"("set of" items)는 하나 이상의 아이템일 수 있다. 이러한 방식에서, 클라이언트의 세트(104)는 하나 이상의 클라이언트일 수 있고, 데이터 공급자의 세트(106)는 하나 이상의 데이터 공급자일 수 있다.

서버 시스템(102)은 데이터 공급자의 세트(106)로부터 데이터를 수신 및 저장한다. 이어, 서버 시스템(102)은 요청에 따라 클라이언트의 세트(104)로 이 데이터를 서비스한다. 데이터 공급자의 세트(106)의 데이터 공급자는 하드웨어, 소프트웨어, 또는 둘의 조합을 구비할 수 있다. 예컨대, 여기서 이용된 바와 같이, 데이터 공급자의 세트(106)의 데이터 공급자는 모니터링 시스템, 건전성 모니터링 시스템(health monitoring system), 분배된 데이터 획득 시스템(distributed data acquisition system), 센서장치, 다중 센서 장치로 이루어진 센서 시스템(sensor system comprised of multiple sensor devices), 컴퓨터, 이미징 시스템(imaging system), 감시 시스템(surveillance system), 서버(server), 여러 서버 시스템(different server system), 이메일 어플리케이션(email application), 웹 어플리케이션(Web application), 또는 데이터의 소스의 몇몇 다른 유형의 형태를 취할 수 있다.

더욱이, 클라이언트의 세트(104)의 클라이언트는 하드웨어, 소프트웨어, 또는 둘의 조합을 구비할 수 있다. 예컨대, 클라이언트의 세트(104)의 클라이언트는 데스크탑 컴퓨터, 랩탑 컴퓨터, 태블릿 컴퓨터, 모바일 폰, PDA(personal digital assistant), 처리 유닛(processor unit), 마이크로칩(microchip), 집적회로(integrated circuit), 어플리케이션 소프트웨어, 컴퓨터 프로그램, 데이터 안정화 시스템(data stabilization system), 디스플레이 장치, 가시화 도구(visualization tool), 데이터 뷰어(data viewer), 비쥬얼 인터페이스 프로그램(visual interface program), 가상 현실 시스템(virtual reality system), 또는 데이터의 요청자(requestor of data)의 몇몇 다른 유형의 형태를 취할 수 있다. 클라이언트가 전체적으로 소프트웨어로 이루어질 때, 클라이언트는 클라이언트 어플리케이션으로서 언급될 수 있다.

이러한 실례로 되는 예에 있어서, 서버 시스템(102)은 서버 콘트롤러(server controller; 108) 및 데이터 서버의 세트(set of data servers; 110)를 포함한다. 데이터 서버의 세트(110)의 데이터 서버는 하드웨어, 소프트웨어, 또는 둘의 조합을 이용해서 구현될 수 있다. 하나의 실례로 되는 예에 있어서, 데이터 서버의 세트(110)의 각 데이터 서버는 여러 하드웨어 장치로 구현될 수 있다. 그러나, 다른 실례로 되는 예에 있어서, 2 이상의 데이터 서버가 동일한 하드웨어 장치의 일부로서 구현될 수 있다.

서버 콘트롤러(108)는 데이터 서버의 세트(110)의 각 데이터 서버와의 통신을 확립하도록 구성될 수 있다. 몇몇 경우에 있어서, 서버 콘트롤러(108)는 데이터 서버의 세트(110)와 관련하여 원격적으로 위치된 하드웨어로 구현될 수 있다. 다른 경우에 있어서, 서버 콘트롤러(108)는 하나 이상의 데이터 서버의 세트(110)와 동일한 하드웨어의 개수로 구현될 수 있다.

더욱이, 서버 콘트롤러(108)는 클라이언트의 세트(104)의 각 클라이언트 및 데이터 공급자의 세트(106)의 각 데이터 공급자와 통신을 확립하도록 구성될 수 있다. 예컨대, 서버 콘트롤러(108)는 데이터 공급자의 세트(106)의 각 데이터 공급자가 데이터를 보내는 데이터 서버의 세트(110)의 하나 이상의 데이터 서버를 결정할 수 있다.

하나의 실례로 되는 예로서, 서버 콘트롤러(108)는 데이터 공급자의 세트(106)의 데이터 공급자(111)가 데이터 서버의 세트(110)의 특정 데이터 서버로 데이터를 보내는 것을 결정할 수 있다. 몇몇 경우에 있어서, 특정 데이터 서버는 데이터 공급자의 세트(106)의 하나의 데이터 공급자 이상으로부터 데이터를 수신하도록 구성될 수 있다. 더욱이, 구현에 따라, 데이터 공급자(111)는 데이터 서버의 세트(110)의 하나 이상의 다른 데이터 서버로 또한 데이터를 보내도록 서버 콘트롤러(108)에 의해 제어될 수 있다.

데이터 공급자(111)는, 구현에 따라, 이들 데이터 서버의 모두에 대해 데이터의 동일한 부분을, 및/또는 여러 데이터 서버에 대해 데이터의 다른 부분을 보낼 수 있다. 예컨대, 제한 없이, 데이터 공급자(111)는 하나의 데이터 서버에 대해 데이터의 일부분을 보낼 수 있고, 이어 백업을 위해 다른 데이터 서버에 대해 데이터의 동일한 부분을 보낼 수 있다. 이러한 다른 데이터 서버는 이어 제1 데이터 서버가 이용불가능하게 되거나 접근불가능하게 되는 경우 백업 데이터 서버로서 이용될 수 있다.

하나의 실례로 되는 예에 있어서, 서버 콘트롤러(108)는 데이터 공급자(111)가 데이터 서버의 세트(110)의 데이터 서버(124)로 데이터를 보내는 것을 결정할 수 있다. 데이터 서버(124)는 서버 관리자(server manager; 130), 수신기(receiver; 132), 및 저장 시스템(storage system; 134)을 포함할 수 있다. 서버 관리자(130)는 서버 콘트롤러(108)와 통신에 있을 수 있다. 서버 관리자(130)는 수신기(132)와 저장 시스템(134)을 제어할 수 있다.

데이터 공급자의 세트(106)의 데이터 공급자로부터 데이터 서버(124)에서 수신된 소정의 데이터는 수신기(132)에서 수신될 수 있다. 서버 관리자(130)는 수신기(132)가 데이터를 수신하는 것을 시작하는 때 및 수신기(132)가 데이터 공급자로부터 데이터를 수신하는 것을 중지하는 때를 결정할 수 있다. 몇몇 경우에 있어서, 서버 관리자(130)는 서버 콘트롤러(108)로부터의 명령(commands)을 기초로 수신기(132)에서 데이터를 수신하는 것을 제어할 수 있다.

이러한 실례로 되는 예에 있어서, 데이터 서버(124)는 데이터 공급자(111)로부터 데이터 포인트들(data points; 135)을 수신하도록 지정(designated)될 수 있다. 데이터 포인트들(135)은 소정 수의 데이터 스트림으로 비동기적으로 수신될 수 있다. 각 데이터 스트림은 시간 경과에 따라 수신된 다수의 데이터 포인트를 포함할 수 있다. 여기서 이용된 바와 같이, 데이터 포인트들(135)의 데이터 포인트(136)와 같은 "데이터 포인트(data point)"는 데이터 값(137) 및 시간 값(138)을 포함한다. 데이터 포인트들(135)은 여러 데이터 스트림이 여러 데이터 속도를 갖을 수 있다는 점에서 비동기적으로 수신될 수 있다.

데이터 값(137)은 파라미터를 위한 값이다. 여기서 이용된 바와 같이. "파라미터(parameter)"는 측정, 신호, 특징, 또는 몇몇 다른 형태의 측정가능 특성 또는 특질일 수 있다. 데이터 값(137)은 소정 수의 비트(bits)로 이루어질 수 있다. 여러 형태의 파라미터의 예는, 이에 한정되는 것은 아니고, 온도, 습도, 속도, 고도, 방향(heading), 연료 적재력(fuel capacity), 중량(weight), 광 강도(light intensity), 전력(power), 또는 다른 형태의 파라미터를 포함할 수 있다. 데이터 포인트들(135)은 하나 이상의 파라미터를 위한 데이터 포인트를 포함할 수 있다.

시간 값(time value; 138)은 데이터 값(137)이 획득되었던 시간을 나타내는 값이다. 데이터 값(137)이 "획득되었던" 시간은, 디지털 형태로, 데이터 값(137)이 획득되었거나 발생되었던 시간일 수 있다. 몇몇 경우에 있어서, 시간 값(138)은 획득 시간 값(acquisition time value) 또는 획득 타임스탬프(acquisition timestamp)로서 언급될 수 있다. 더욱이, 시간 값(138)은 몇몇 레퍼런스 클럭(reference clock)에 관한 시간일 수 있다. 하나의 실례로 되는 예에 있어서, 각 데이터 공급자의 세트(106)는 이러한 레퍼런스 클럭에 동기화될 수 있다.

하나의 실례로 되는 예에 있어서, 데이터 공급자(111)가 이러한 형태의 데이터를 위한 선택된 허용 오차를 벗어나는 소정의 시간 지연 또는 처리 지연 없이 데이터 포인트들(135)을 획득한 후 즉각적으로 데이터 공급자(111)는 데이터 서버(124)로 데이터 포인트들(135)을 보낼 수 있다. 이러한 방식에 있어서, 데이터 포인트들(135)은 현재 데이터 포인트(current data points), 라이브 데이터 포인트(live data points), 실시간 데이터 포인트(real-time data points), 또는 임박한 실시간 데이터 포인트(near real-time data points)로서 언급될 수 있다.

더욱이, 데이터 공급자(111)가 구성될 수 있어 데이터 포인트들(135)은 파라미터 당 단조롭게 증가하는 시간 순서(monotonically-increasing time order)로 수신기(132)에 보내진다. 즉, 가장 일찍 획득된 데이터 포인트가 먼저 데이터 서버(124)에서 수신됨에 따라, 특정 파라미터를 위한 모든 데이터 포인트는 시간에 관한 순서로 수신될 수 있다.

그러나, 몇몇 경우에 있어서, 여러 파라미터를 위해 수신된 데이터 포인트는 시간에 관한 순서로 되지 않을 수도 있다. 즉, 제1 파라미터를 위한 제1 데이터 포인트는 제1 데이터 포인트가 제2 파라미터를 위한 시간 값 보다 더 늦은 시간 값을 갖을 때에도 제2 파라미터를 위한 제2 데이터 포인트 전에 수신기(132)에서 수신될 수 있다. 그러나, 해당 제1 파라미터를 위한 모든 데이터 포인트는 시간 순서로 수신될 수 있고 제2 파라미터를 위한 모든 데이터 포인트는 시간 순서로 수신될 수 있다.

더욱이, 데이터 포인트들(135)을 위한 데이터 값은 여러 데이터 속도에서 획득될 수 있다. 예컨대, 하나의 파라미터를 위한 데이터 값은 다른 파라미터를 위한 데이터 값 외의 여러 데이터 속도에서 획득될 수 있다. 이러한 방식에 있어서, 데이터 포인트들(135)을 위한 데이터 값은 비동기적으로 또는 비결정적 방식(nondeterministic manner)으로 획득되었을 수 있다.

물론, 다른 경우에 있어서, 데이터 포인트들(135)을 위한 데이터 값은 동기적으로 획득될 수 있다. 하나의 실례로 되는 예로서, 데이터 포인트들(135)은 2개의 파라미터를 위한 데이터 포인트를 포함할 수 있다. 이들 2개의 파라미터를 위해 획득된 데이터 값은 동일한 특정 데이터 속도로 획득될 수 있다. 이러한 방식에 있어서, 데이터 포인트들(135)을 위한 데이터 값은 동기적으로, 또는 소정의 데이터 속도로 획득될 수 있다.

이러한 실례로 되는 예에 있어서, 저장 시스템(134)은 수신기(132)로부터 데이터 포인트들(135)을 수신하고 데이터 포인트들(135)을 저장한다. 저장 시스템(134)에 저장되면, 데이터 포인트들(135)은 저장된 데이터 포인트(stored data points; 139)로서 언급될 수 있다. 저장된 데이터 포인트(139)의 각 저장된 데이터 포인트는 원래의 데이터 포인트의 데이터 값과 시간 값을 유지할 수 있다. 몇몇 경우에 있어서, 저장된 데이터 포인트(139)는 또한 이력 데이터 포인트(historical data points) 또는 기록된 데이터 포인트(recorded data points)로 언급될 수 있다.

저장 시스템(134)은 다수의 여러 형태를 취할 수 있다. 하나의 실례로 되는 예에 있어서, 저장 시스템(134)은 캐싱 시스템(caching system) 및 디스크 저장기(disk storage)를 포함할 수 있다. 물론, 소정 수의 디스크 저장 장치, 메모리의 형태, 및/또는 다른 형태의 데이터 저장 장치기 저장 시스템(134)에 포함될 수 있다.

이러한 방식에 있어서, 서버 콘트롤러(108)는 데이터 공급자의 세트(106)로부터 데이터 서버의 세트(110)로의 데이터의 분배를 관리할 수 있다. 서버 콘트롤러(108)는 또한 데이터 서버의 세트(110)로부터 클라이언트의 세트(104)로의 데이터의 분배를 관리할 수 있다.

예컨대, 서버 콘트롤러(108)는 클라이언트의 세트(104)로부터의 소정 수의 정책 요청을 수신 및 처리하도록 구성될 수 있다. 여기서 이용된 바와 같이, "정책 요청(policy request)은, 클라이언트의 세트(104) 중 하나와 같은, 클라이언트가, 데이터 서버의 세트(110)와 같은, 하나 이상의 데이터 서버로부터 데이터를 억세스할 수 있는 수단이다. 특히, 정책 요청은 정책에 따른 데이터를 위한 요청이다.

여기서 이용된 바와 같이, "정책(policy)"은 데이터가 클라이언트에게 전달되는 방식을 설명하는데 이용되는 단어이다. 즉, 정책은 데이터가 클라이언트로부터 데이터를 위한 요청에 응답하여 클라이언트에게 전달되는 방법을 어떻게 데이터 서버가 제어하는가를 설명한다. 정책 요청 내에서 특정 정책을 특정화하는 것에 의해, 클라이언트는 클라이언트가 데이터를 수신하기 위해 원하는 방식을 식별한다. 정책 요청이 구현될 수 있는 하나의 방식의 예가 이하 도 2에서 설명된다.

하나의 실례로 되는 예에 있어서, 서버 콘트롤러(108)는 클라이언트의 세트(104)의 클라이언트(114)로부터 정책 요청(policy request; 112)을 수신한다. 클라이언트(114)가 데이터 서버의 세트(110)에 대해 호스트된 데이터를 억세스하기를 원할 때 클라이언트(114)는 정책 요청(112)을 발생시킨다.

정책 요청(112)은 정책(118)에 따른 데이터를 위한 요청이다. 정책(118)은 데이터의 형태, 데이터를 위한 시간 및/또는 데이터 범위, 데이터가 클라이언트(114)에세 보내지는 포맷, 데이터가 클라이언트(114)에게 보내지기 전에 소트되고, 시퀀스되고, 포맷되고, 및/또는 그렇지 않으면 처리되는 방식, 데이터가 클라이언트(114)에세 보내지는 특정 데이터 속도, 또는 데이터가 클라이언트(114)에게 보내지는 방식을 위한 몇몇 다른 형태의 지시(instruction) 또는 요구(requirement) 중 적어도 하나를 나타낼 수 있다.

여기서 이용된 바와 같이, 문구 "중 적어도 하나(at least one of)"는, 아이템의 리스트와 함께 이용될 때, 하나 이상의 리스트된 아이템의 여러 조합이 이용될 수 있고 리스트의 아이템 중 오직 하나만이 필요로 될 수 있음을 의미한다. 아이템은 특정 물체, 물건 또는 카테고리일 수 있다. 즉, "중 적어도 하나"는 아이템의 소정 조합 또는 다수의 아이템이 리스트로부터 이용될 수 있지만, 리스트의 모든 아이템이 요구될 수 있는 것이 아님을 의미한다.

예컨대, "아이템 A, 아이템 B, 및 아이템 C 중 적어도 하나"는 아이템 A; 아이템 A 및 아이템 B; 아이템 B; 아이템 A, 아이템 B, 및 아이템 C; 또는 아이템 B 및 아이템 C를 의미할 수 있다. 몇몇 경우에 있어서, "아이템 A, 아이템 B, 및 아이템 C 중 적어도 하나"는, 예컨대, 제한 없이, 2개의 아이템 A, 하나의 아이템 B, 및 10개의 아이템 C; 4개의 아이템 B 및 7개의 아이템 C; 또는 다른 적절한 조합을 의미할 수 있다.

클라이언트(114)로부터 정책 요청(112)을 수신하는 것에 응답하여, 서버 콘트롤러(108)는 하나 이상의 데이터 서버의 세트(110)가 클라이언트(114)에 의해 요청되는 데이터를 호스팅하는 것을 결정할 수 있다. 몇몇 경우에 있어서, 하나의 데이터 서버는 요청된 데이터의 모두를 호스트(host)할 수 있다. 다른 경우에 있어서, 하나의 데이터 서버는 요청된 데이터의 제1 부분을 호스트할 수 있는 한편, 다른 데이터 서버는 요청된 데이터의 제2 부분을 호스트한다.

요청된 데이터의 몇몇 부분을 호스팅함에 따라 식별된 데이터 서버의 세트(110)의 각 데이터 서버에 대해, 서버 콘트롤러(108)는 해당 데이터 서버에게 정책 요청(112)에 관한 정보를 포워드(forward)할 수 있다. 이 정보는 정책 요청 정보로 언급될 수 있고 서버 요청의 형태로 데이터 서버로 보내질 수 있다. 예컨대, 서버 콘트롤러(108)는 요청된 데이터의 일부분을 호스팅함에 따라 데이터 서버(124)를 식별할 수 있다. 상기한 바와 같이, 이 부분은 요청된 데이터의 몇몇 또는 모두일 수 있다. 이러한 실례로 되는 예에 있어서, 서버 콘트롤러(108)는 데이터 서버(124)를 위한 서버 요청(122)을 발생시키고 데이터 서버(124)로 서버 요청(122)을 보낼 수 있다.

도시된 바와 같이, 서버 요청(122)은 서버 정책(server policy; 128)에 따른 데이터를 위한 요청일 수 있다. 서버 정책(128)은 데이터 서버(124)에 대해 호스트된 요청 데이터의 부분에 대응하는 정책(118)의 부분을 포함할 수 있다. 즉, 서버 정책(128)은 데이터 서버(124)가 클라이언트(114)에게 데이터를 서비스하는 방식을 나타낼 수 있다.

이러한 실례로 되는 예에 있어서, 데이터 서버(124)는 서버 요청(122)을 수신하고 처리한다. 특히, 서버 관리자(130)는 서버 콘트롤러(108)로부터 서버 요청(122)을 수신할 수 있다. 서버 관리자(130)가 서버 요청(122)을 수신할 때, 서버 관리자(130)는 서버 요청(122)을 취급하도록 다수의 정책 요청 취급자(number of policy request handlers; 141)를 활성화시킬 수 있다. 여기서 이용된 바와 같이, "다수의(number of)" 아이템은 하나 이상의 아이템을 포함할 수 있다. 이러한 방식에 있어서, 다수의 정책 요청 취급자(141)는 하나 이상의 정책 요청 취급자를 포함할 수 있다.

다수의 정책 요청 취급자(141)는 클라이언트(114)에 의해 요청되는 데이터를 모으고, 이어 클라이언트(114)에게 이 데이터를 보내도록 구성될 수 있다. 정책 요청 취급자(140)는 다수의 정책 요청 취급자(141) 중 하나의 예일 수 있다. 서버 요청(122)을 기초로, 서버 관리자(130)는 정책 요청 취급자(140)가 수신기(132)로부터 또는 저장 시스템(134)으로부터 직접적으로 이 데이터를 모으는 것에 대한 여부를 결정한다.

더욱이, 서버 관리자(130)는 정책 요청 취급자(140)가 수신기(132)로부터 또는 저장 시스템(134)으로부터 직접적으로 이 데이터를 수신하는 것에 대한 여부를 식별하는 정책 요청 취급자(140)에 대해 취급자 정책(142)을 보낸다. 몇몇 경우에 있어서, 취급자 정책(142)은 또한 데이터가 수신되는 선택된 파라미터(selected parameters; 143)를 식별할 수 있다.

정책 요청 취급자(140)에 의해 수신된 데이터는 입력 데이터 포인트(input data points; 144)로서 언급될 수 있다. 입력 데이터 포인트(144)가 수신기(132)로부터 수신될 때, 서버 관리자(130)는 정책 요청 취급자(140)에게 수신기(132)에서 수신되는 데이터 포인트들(135)의 일부 또는 전부를 보내도록 수신기(132)를 명령한다. 이러한 방식에 있어서, 데이터 포인트들(135)이 수신기(132)에서 수신됨에 따라 데이터 포인트들(135)을 저장 시스템(134)으로 보내는 것에 부가하여, 수신기(132)는 입력 데이터 포인트(144)를 형성하기 위해 수신기(132)에서 수신된 데이터 포인트들(135)의 몇몇 또는 전부를 정책 요청 취급자(140)에게 보낸다.

하나의 실례로 되는 예에 있어서, 수신기(132)는 수신기(132)에서 수신된 데이터 포인트들(135)의 모두를 정책 요청 취급자(140)에게 보낼 수 있다. 다른 실례로 되는 예에 있어서, 수신기(132)는 취급자 정책(142)에서 특정된 선택된 파라미터(143)에 대응하는 데이터 포인트들(135)의 부분만을 정책 요청 취급자(140)에게 보낼 수 있다.

입력 데이터 포인트(144)가 저장 시스템(134)으로부터 수신될 때, 서버 관리자(130)는 저장된 데이터 포인트(139)의 이러한 부분이 검색되어지는 것을 저장 시스템(134)의 어느 저장 장치 또는 메모리 유닛으로부터 결정할 수 있다. 정책 요청 취급자(140)는 입력 데이터 포인트(144)를 형성하도록 저장된 데이터 포인트(139)의 이러한 부분을 검색할 수 있다.

정책 요청 취급자(140)는 파라미터 당 단조롭게 증가하는 시간 순서로 입력 데이터 포인트(144)를 수신할 수 있다. 그러나, 여러 파라미터를 위한 입력 데이터 포인트(144)는 시간 순서로 되지 않을 수 있다. 정책 요청 취급자(140)가 입력 데이터 포인트(144)를 수신함에 따라, 정책 요청 취급자(140)는 시간-순서 데이터 어레이(time-ordered data array; 146)를 형성하기 위해 함께 여러 파라미터를 위한 데이터 포인트를 합병한다. 시간-순서 데이터 어레이(146)는, 데이터 포인트가 대응하는 파라미터에 관계없이, 모든 데이터 포인트가 시간과 관련되어 순서화되는 데이터 포인트의 단일 어레이일 수 있다.

정책 요청 취급자(140)는 클라이언트(114)에게 보내지는 출력 데이터(156)를 형성하기 위해 시간-순서 데이터 어레이(146)를 처리할 수 있다. 취급자 정책(142)은 데이터가 비동기 방식 또는 동기 방식으로 클라이언트(114)에게 보내지는가의 여부를 식별할 수 있다.

데이터가 비동기 방식으로 클라이언트(114)에게 보내질 때, 정책 요청 취급자(140)는 클라이언트(114)에게 시간-순서 데이터 어레이(146)로 모든 데이터 포인트를 보낸다. 클라이언트(114)에게 보내진 각 데이터 포인트는 데이터 포인트가 획득되는 시간을 나타내는 원래 시간 값(original time value)을 포함할 수 있다.

데이터가 동기 방식으로 클라이언트(114)에게 보내질 때, 정책 요청 취급자(140)는 취급자 정책(142)에서 나타난 특정 데이터 속도 및 시간-순서 데이터 어레이(146)을 이용해서 정책-기반 데이터 프레임의 세트(set of policy-based data frames; 148)를 형성할 수 있다. 정책-기반 데이터 프레임의 세트(148)의 각 정책-기반 데이터 프레임은 이벤트(event)의 발생과 관련될 수 있다.

이벤트는 또한 트리거(trigger)로서 언급될 수 있다. 이벤트는, 예컨대, 이에 한정되는 것은 아니고, 시간 간격의 경과(lapsing), 데이터 트리거 이벤트, 시간 트리거 이벤트, 또는 몇몇 다른 형태의 이벤트일 수 있다. 데이터 트리거 이벤트는, 예컨대, 제한 없이, 몇몇 선택된 임계값 이상 또는 이하의 값으로 변하는 데이터 값, 식별된 선택된 다수의 반복 데이터 값, 또는 몇몇 다른 형태의 트리거일 수 있다.

정책-기반 데이터 프레임(150)은 특정 이벤트를 위해 형성된 정책-기반 데이터 프레임의 세트(148)의 정책-기반 데이터 프레임의 예일 수 있다. 정책-기반 데이터 프레임(150)은 다수의 데이터 값(152)과 시간 값(154)을 포함할 수 있다. 시간 값(154)은 특정 이벤트가 발생된 시간일 수 있다. 하나의 실례로 되는 예에 있어서, 이벤트는 특정 데이터 속도를 기초로 하는 시간 간격의 경과일 수 있다. 다수의 데이터 값(152)은 시간 값(154)에서 선택된 파라미터(143)의 각 파라미터에 대한 마지막 알려진 데이터 값을 포함할 수 있다.

이러한 방식에 있어서, 정책 요청 취급자(140)는 취급자 정책(142)에 따라 정책-기반 데이터 프레임의 세트(148)를 형성하여, 정책-기반 데이터 프레임의 세트(148)의 데이터 포인트가 클라이언트(114)에 의해 요청된 방식으로 클라이언트(114)에게 제공될 수 있다. 따라서, 취급자 정책(142)에 따라, 동일한 데이터가 다수의 다른 방법으로 클라이언트(114)에세 제공될 수 있다.

정책 요청 취급자(140)는 출력 데이터(156)의 형태로 클라이언트(114)에게 정책-기반 데이터 프레임의 세트(148)를 보낼 수 있다. 출력 데이터(156)는 시간 경과에 따라 클라이언트(114)에게 보내지는 하나 이상의 데이터 패킷을 포함할 수 있다.

몇몇 실례로 되는 예에 있어서, 서버 관리자(130)는 수신된 서버 요청 당 오직 하나의 정책 요청 취급자만을 활성화시킬 수 있다. 그러나, 다른 실례로 되는 예에 있어서, 서버 관리자(130)는 단일 서버 요청을 취급하기 위해 하나 이상의 정책 요청 취급자를 활성화시킬 수 있다. 예컨대, 각 다수의 정책 요청 취급자(141)는 서버 요청(122)의 특정 부분을 서비스하기 위해 서버 관리자(130)에 의해 산출될 수 있다.

이러한 방식에 있어서, 클라이언트(114)와 같은, 클라이언트의 세트(104)의 클라이언트로부터 유래되는 데이터를 위한 모든 요청은 서버 콘트롤러(108)에 의해 수신되고 서버 콘트롤러(108)에 의해 데이터 서버의 세트(110)로 적절히 분배될 수 있다. 이들 데이터 요청은 이어 클라이언트에게 직접 요청된 데이터를 보내는 정책 요청 취급자에 의해 취급될 수 있다. 정책 요청 취급자(140)와 같은, 정책 요청 취급자와, 클라이언트(114)와 같은 클라이언트 사이의 통신은 본 실례로 되는 예에서 오직 하나의 방향으로만 발생할 수 있다. 더욱이, 정책 요청 취급자는 본 실례로 되는 예에서 서버 콘트롤러(108)와는 결코 직접 통신하지 않는다.

데이터 공급자의 세트(106), 서버 콘트롤러(108), 데이터 서버의 세트(110), 및 클라이언트의 세트(104) 사이의 통신은 소정 수의 여러 형태의 통신 링크를 이용해서 수행될 수 있다. 예컨대, 무선 통신 링크, 유선 통신 링크, 광 통신 링크, 및/또는 다른 형태의 통신 링크가 이용될 수 있다.

따라서, 실례로 되는 예는 클라이언트로부터 정책 요청을 취급하기 위한 서버 시스템 및 방법을 제공한다. 예컨대, 도 1의 서버 시스템(102)의 데이터 서버의 세트(110)는 실질적으로 실시간으로 다중 데이터 공급자로부터 데이터 스트림을 수신하고 기록할 수 있다. 정책 요청 취급자를 이용함에 따라, 데이터 서버의 세트(110)는 데이터를 처리하고 매우 높은 데이터 속도로, 도 1의 클라이언트의 세트(104)와 같은, 클라이언트에게 이 데이터를 서비스할 수 있다.

더욱이, 데이터 서버의 세트(110)는 여러 데이터 속도에서 여러 클라이언트에게 데이터를 동시에 서비스하는 것을 가능하게 할 수 있다. 데이터가 클라이언트의 세트(104)에 대해 서비스될 수 있는 잠재적 데이터 속도는 이용되는 하드웨어에 의해서만 구속될 수 있다. 도 1에 개시된 서버 시스템(102)에 따르면, 데이터 대기시간(data latency)은 선택된 허용오차 내로 상당히 감소될 수 있다.

더욱이, 서버 시스템(102)은 분배되고 소정 수의 데이터 공급자 및/또는 소정 수의 클라이언트의 요구에 적절하도록 가변가능(scalable)하게 될 수 있다. 예컨대, 데이터 수율(throughput)을 증가시키기 위해, 새로운 데이터 서버가 데이터 서버의 세트(110)에 부가될 수 있다. 서버 콘트롤러(108)에 의해 수행된 관리 기능은 서버 시스템(102)의 전체 구조에 대한 소정의 원하는 변형 없이 끊임없이 새로운 데이터 서버가 데이터 서버의 세트(110)에 부가될 수 있도록 한다.

도 2를 참조하면, 도 1로부터의 정책 요청(112)의 실례가 실례로 되는 실시예에 따라 블록도의 형태로 도시된다. 이러한 실례로 되는 예에 있어서, 도 1의 클라이언트(114)에 의해 발생된, 정책 요청(112)이 구현될 수 있는 하나의 방식의 예가 도시된다.

정책 요청(112)은, 예컨대, 제한 없이, 클라이언트 식별자(client identifier; 200) 및 정책(118)을 포함할 수 있다. 클라이언트 식별자(200)는, 예컨대 서버 시스템(102)으로부터 데이터를 억세스하기 위해 특정 클라이언트 요청을 식별하기 위한 필드일 수 있다. 이러한 실례로 되는 예에 있어서, 클라이언트(114)를 위한 몇몇 형태의 식별자가 클라이언트 식별자(200)에 입력(entered)될 수 있다.

정책(118)은 도 1의 서버 시스템(102)이 어떻게 클라이언트(114)에게 데이터를 서비스하는가에 대해 정의하는 모든 상세내용을 포함한다. 도시된 바와 같이, 정책(118)은 출력 모드(output mode; 202), 다수의 속성(number of attributes; 204), 정책-특정 속성 상세내용(policy-specific attribute details; 205), 다수의 파라미터(206), 및 다수의 파라미터 블록(208)을 포함할 수 있고, 각각은 클라이언트(114) 및/또는 클라이언트(114)의 이용자에 의해 정의될 수 있다.

출력 모드(202)는 클라이언트(114)에게 보내진 데이터의 각 프레임에서 클라이언트(114)에 대해 출력되는 데이터의 모드를 식별하기 위한 필드일 수 있다. 출력 모드(202)에 입력된(entered) 값은, 이에 제한되는 것은 아니고, 디폴트 모드(default mode; 210), 최소 및 최대 데이터 모드(minimum and maximum data mode; 211), 선형 보간 모드(linear interpolation mode; 212), 2차 보간 모드(second order interpolation mode; 214), 최종 값 모드(last value mode; 216), 및 가중 평균 입방 보간 모드(weighted average cubic interpolation mode; 218)를 포함할 수 있는 다수의 여러 모드 중 하나를 식별할 수 있다. 이들 모드는 다수의 속성(204)과 관련하여 이하 설명될 수 있다.

여기서 이용된 바와 같이, 다수의 속성(204) 중 하나와 같은 "속성(attribute)"은 어떻게 데이터가 요청되는가, 어떻게 데이터가 포맷되는가, 어떻게 데이터가 전달되는가, 및/또는 클라이언트(114)가 데이터를 수신하는 것에 대해 원하는 방식의 다른 측면을 정의할 수 있다. 다수의 속성(204)은 데이터가 클라이언트(114)에게 전달되는 방식을 식별하는 것에 이용하기 위한 다수의 플래그(a number of flags)를 포함할 수 있다. 하나의 실례로 되는 예에 있어서, 다수의 속성(204)은 데이터 모드 플래그(data mode flag; 220), 타임스탬프 모드 플래그(timestamp mode flag; 222), 프로토콜 모드 플래그(protocol mode flag; 223), 프레임 모드 플래그(frame mode flag; 224), 트리거 모드 플래그(trigger mode flag; 226), 및 갭 검출 모드 플래그(gap detection mode flag; 228)를 포함할 수 있다. 이들 플래그의 각각은 정책(118)의 몇몇 측면과 어떠한 다른 정보가 정책(118)에 포함됨을 정의하는 값에 대해 설정될 수 있다.

데이터 모드 플래그(220)를 위해 입력된 값은 클라이언트(114)가 라이브 데이터 또는 이력 데이터에 관심이 있는가의 여부를 식별한다. 데이터 모드 플래그(220)가 라이브 데이터를 위해 설정될 때, 정책(118)은 라이브 정책으로 간주되고 정책 요청(112)은 라이브 정책 요청으로 간주된다. 데이터 모드 플래그(220)가 이력 데이터를 위해 설정될 때, 정책(118)은 이력 정책으로 간주되고 정책 요청(112)은 이력 정책 요청으로 간주된다.

타임스탬프 모드 플래그(222)를 위해 입력된 값은 데이터 포인트가 시간 값을 획득 또는 정정하였던 시간들을 나타내는 데이터 포인트를 위한 시간 값에 관심이 있는가의 여부를 식별한다. 예컨대, 몇몇 경우에 있어서, 데이터 포인트(136)를 위한 시간 값(138)은 데이터 포인트(136)를 위한 데이터 값(137)이 획득되었던 실제 시간 값 보다 늦을 수 있다. 이러한 지연은 아날로그 필터 또는 몇몇 다른 형태의 처리 지연을 통한 데이터 값(137)의 처리에 기인할 수 있다. 서버 시스템(102) 내에서, 도 1의 정책 요청 취급자(140)와 같은, 정책 요청 취급자는 클라이언트(114)에게 데이터 포인트(136) 및/또는 데이터 포인트(136)의 데이터 값(137)을 보내기 이전에 데이터 포인트(136)를 위한 시간 값(138)을 정정하는 것이 가능하게 될 수 있다.

이러한 실례로 되는 예에 있어서, 프로토콜 모드 플래그(223)을 위해 입력된 값은 클라이언트(114)에게 데이터를 보낼 때 이용되는 네트워크 프로토콜을 식별할 수 있다. 하나의 실례로 되는 예에 있어서, 프로토콜 모드 플래그(223)를 위해 입력된 값은 UDP(user datagram protocol) 또는 TCP(transmission control protocol)의 어느 한 쪽이 이용됨을 특정할 수 있다.

프레임 모드 플래그(224)를 위해 입력된 값은 프레이밍(framing)이 가능한가 또는 불가능한가의 여부를 식별할 수 있다. 예컨대, 프레이밍이 가능할 때, 특정 시간에 관하여 또는 특정 시간 범위 내에서 획득되었던 파라미터의 선택된 세트를 위한 모든 데이터 포인트는 프레임되고 단일 시간 값과 관련될 수 있다. 이러한 방식에 있어서, 데이터는 동기적으로 클라이언트(114)에 대해 출력될 수 있다. 그러나, 프레이밍이 불가능할 때, 각 데이터 포인트는 데이터 포인트를 위한 원래의 데이터 값으로 클라이언트(114)에게 개별적으로 보내질 수 있다. 이러한 방식에 있어서, 프레이밍이 불가능할 때, 데이터는 비동기적으로 클라이언트(114)에게 출력될 수 있다.

더욱이, 트리거 모드 플래그(226)를 위해 입력된 값은 클라이언트(114)에게 출력된 데이터가 어떻게 트리거되는지를 식별한다. 예컨대, 데이터는 몇몇 특정 시간 간격에서, 또는 데이터 스트림 내에서 발생하는 몇몇 특정된 데이터 값을 기초로 트리거될 수 있다. 즉, 데이터는 시간 트리거(time triggered)되거나 데이터 트리거(data triggered)될 수 있다.

갭 검출 모드 플래그(228)를 위해 입력된 값은 갭 검출 모드가 가능한지 또는 불가능한지의 여부를 결정할 수 있다. 갭 검출 모드가 가능할 때, 오래된 경고(stale alert)가 시간의 몇몇 선택된 기간에 걸쳐 클라이언트(114)에게 보내지는 특정 파라미터를 위한 데이터 값이 없을 때 클라이언트(114)에게 보내질 수 있다.

이러한 실례로 되는 예에 있어서, 정책(118)에 포함된 정책-특정 속성 상세내용(205)은 다수의 속성(204)에서 여러 속성과 관련된 상세내용을 제공할 수 있다. 예컨대, 정책-특정 속성 상세내용(205)은 각각 데이터 모드 플래그(220), 타임스탬프 모드 플래그(222), 프레임 모드 플래그(224), 트리거 모드 플래그(226), 및 갭 검출 모드 플래그(228)를 기초로 상세내용을 포함할 수 있는, 데이터 모드 상세내용(data mode details; 230), 타임스탬프 모드 상세내용(timestamp mode details; 232), 프레임 모드 상세내용(frame mode details; 234), 트리거 모드 상세내용(trigger mode details; 236), 및 갭 검출 모드 상세내용(gap detection mode details; 238)을 포함할 수 있다.

예컨대, 데이터 모드 플래그(220)가 라이브 데이터를 위해 설정될 때, 데이터 모드 상세내용(230)은 동기화 시간(synchronization time; 240)을 포함할 수 있다. 동기화 시간(240)은 라이브 정책이 동기화되는 시간일 수 있다. 더욱이, 데이터 모드 플래그(220)가 라이브 데이터를 위해 설정될 때, 데이터 모드 상세내용(230)은 데이터세트(dataset; 241), 시작 시간(start time; 242), 중지 시간(stop time; 244), 및 전달 속도(delivery rate; 246)를 포함할 수 있다. 데이터세트(241)는 이력 데이터가 요청되는 특정 데이터세트를 특정하기 위한 필드일 수 있다. 시작 시간(242) 및 중지 시간(244)은 이러한 시간 범위 내에서 시간 값을 갖춘 저장된 데이터 포인트가 요청되는 시간 범위를 특정하기 위한 필드일 수 있다. 전달 속도(246)는 데이터가 클라이언트(114)에게 보내지는 속도(rate)를 특정하기 위한 필드일 수 있다.

타임스탬프 모드 플래그(222)가 설정되어 정정된 시간 값이 클라이언트(114)에게 보내질 때, 타임스탬프 모드 상세내용(232)은 지연 시간(delay time; 248)을 포함할 수 있다. 지연 시간(248)은 클라이언트(114)에게 데이터 프레임 또는 데이터 포인트를 출력하기 전에 데이터를 기다리기 위한 최대 지연 시간을 식별하기 위한 필드일 수 있다. 지연 시간(248)은 데이터 포인트를 위한 시간 값에서 알려진 처리 지연을 위해 정정하도록 허용된 시간에 대한 제한을 식별할 수 있다.

프레임 모드 플래그(224)가 설정되어 프레이밍이 불가능할 때, 프레임 모드 상세내용(234)은 소정의 상세내용을 포함할 수 없다. 그러나, 프레임 모드 플래그(224)가 설정되어 프레이밍이 가능할 때, 프레임 모드 상세내용(234)은 시간 틱 간격(time tick interval; 250) 및 오래된 데이터 플래그(stale data flag; 252)를 포함할 수 있다.

시간 틱 간격(250)은 시간 틱이 클라이언트(114)에게 데이터 포인트로서 보내지는 최소 간격, 전형적으로 나노초(nanoseconds)로 특정하기 위한 필드이다. 하나의 실례로 되는 예에 있어서, 시간 틱은 빈 데이터 값(empty data value) 및 빈 시간 값(empty time value)을 구비하는 데이터 포인트일 수 있다. 다른 경우에 있어서, 시간 틱은 시간 틱이 형성되었던 시간을 표현하는 시간 값 및 빈 데이터 값을 구비하는 데이터 포인트일 수 있다. 오래된 데이터 플래그(252)는 서버 시스템(102)이 트리거 이벤트의 시간에서 오래된 것으로 되는 파라미터를 위한 모든 데이터 값 또는 단지 오래되지 않은 데이터 값(non-stale data values)만을 포워드하는 것에 대한 여부를 특정하기 위한 필드일 수 있다.

트리거 모드 플래그(226)가 설정되어 데이터가 시간 트리거되도록 될 때, 트리거 모드 상세내용(236)은 트리거 간격(trigger interval; 254)을 포함할 수 있다. 트리거 간격(254)은 서버 시스템(102)이 클라이언트(114)에게 출력되는 데이터 프레임 또는 데이터 포인트를 트리거하는 것에 대해, 전형적으로 나노초로, 시간 간격을 식별하기 위한 필드일 수 있다. 이러한 시간 간격은 트리거 간격(trigger interval)으로서 불리워질 수 있고, 이러한 "트리거(trigger)"가 발생되는 시간은 "트리거 시간(trigger time)"으로서 언급될 수 있다.

트리거 모드 플래그(226)가 설정되어 데이터가 데이터 트리거될 때, 트리거 모드 상세내용(236)은 트리거 파라미터 태그(trigger parameter tag; 256), 트리거 행위(trigger action; 258), 트리거 입력 마스크(trigger input mask; 260), 트리거 패턴(trigger pattern; 262), 및 트리거 출력 마스크(trigger output mask; 264)를 포함할 수 있다. 트리거 파라미터 태그(256)는 트리거가 클라이언트(114)에게 보내지는 데이터 프레임 또는 데이터 포인트를 야기시키게 되는 파라미터를 식별하기 위한 필드일 수 있다. 이 파라미터는 트리거 파라미터(trigger parameter)로서 언급될 수 있다. 예컨대, 0, 널(NULL)과 같은 디폴트 값, 또는 몇몇 다른 디폴트 값이 소정 또는 모든 파라미터를 위한 데이터 프레임 또는 데이터 포인트가 트리거 시간에서 출력될 수 있음을 나타내도록 트리거 파라미터 태그(256)에 입력될 수 있다.

트리거 행위(trigger action; 258)는 클라이언트(114)에게 출력되는 데이터 프레임 또는 데이터 포인트를 야기시키게 되는 트리거 행위 또는 트리거를 식별하는 필드일 수 있다. 트리거는, 예컨대, 제한 없이, 수신되어지는 데이터, 변경되는 데이터, 변경되지 않는 데이터, 패턴을 매치시키는 데이터, 패턴을 매치시키지 않는 데이터 중 하나로부터 선택될 수 있다. 수신되어지는 데이터는 정책 요청 취급자에서 수신되어지는 트리거 파라미터 태그(256)에 의해 식별된 파라미터를 위한 데이터 값을 포함할 수 있다. 변경되는 데이터는 트리거 파라미터를 위한 데이터 값의 적어도 하나의 비트를 포함할 수 있다.

예컨대, 모두 트리거 파라미터를 위한 동일한 데이터 값을 갖춘 데이터 포인트는 정책 요청 취급자에서 수신될 수 있다. 트리거 파라미터를 위한 데이터 값이 적어도 하나의 비트에 의해 변경될 때, 트리거가 발생되고 여러 데이터 포인트를 갖는 데이터 포인트 또는 데이터 프레임이 클라이언트(114)에게 보내질 수 있다.

변경되지 않는 데이터는 시간의 몇몇 선택된 기간에 걸쳐 변경되지 않는 트리거 파라미터를 위한 데이터 값을 포함할 수 있다. 이러한 방식에 있어서, 트리거는 트리거 파라미터를 위한 데이터가 변경되지 않는 것일 수 있다.

트리거 입력 마스크(260) 및 트리거 패턴(262)을 위한 엔트리는 트리거 패턴을 매치시키는 데이터 또는 트리거 패턴을 매치시키지 않는 데이터의 트리거가 발생되는가의 여부를 평가하는데 이용될 수 있다. 트리거 입력 마스크(260)는 트리거 패턴이 적용되어지는 트리거 패턴을 위한 데이터 값 내에서 비트를 정의하기 위한 필드일 수 있다. 이들 비트는 입력 마스크(input mask)로서 언급될 수 있다. 트리거 패턴(262)은 입력 마스크 내의 비트에 적용되어지는 트리거 패턴을 식별하는 필드일 수 있다.

따라서, 트리거 행위(258)가 패턴을 매치시키는 데이터에 대해 설정될 때에는, 입력 마스크가 데이터 값에 적용된 후 트리거 파라미터를 위한 데이터 값이 트리거 패턴과 매치될 때 데이터 프레임 또는 데이터 포인트가 클라이언트(114)에게 출력된다. 반대로, 트리거 행위(258)가 패턴과 매치되지 않는 데이터로 설정될 때에는, 입력 마스크가 데이터 값에 적용된 후 트리거 파라미터를 위한 데이터 값이 트리거 패턴과 매치되지 않을 때 데이터 프레임 또는 데이터 포인트가 클라이언트(114)에게 출력된다.

트리거 출력 마스크(264)는 트리거가 발생되면 클라이언트(114)에게 출력되는 트리거 파라미터를 위한 데이터 값 내에서 비트를 식별하는 필드일 수 있다. 이들 비트는 출력 마스크(output mask)로서 언급될 수 있다. 트리거가 발생되면, 출력 마스크는 발생에 대해 트리거를 야기시키는 데이터 값에 적용될 수 있고 출력 마스크 내에 속하는 비트는 클라이언트(114)에게 출력될 수 있다.

이러한 실례로 되는 예에 있어서, 갭 검출 모드 플래그(228)가 설정되어 갭 검출 모드가 가능하게 될 때, 갭 검출 모드 상세내용(238)은 갭 팩터(gap factor; 266)를 포함할 수 있다. 갭 팩터(266)는 해당 서버 시스템(102)이 가정하게 되는 오래된 데이터의 양이 데이터에서의 "갭(gap)"임을 식별하는 필드일 수 있다. 즉, 갭 팩터(266)를 위한 엔트리는 "갭"으로서 간주되어지도록 정책 요청 취급자에 도착할 수 있는 파라미터를 위한 데이터 값이 없는 동안의 시간의 기간을 정의한다. 이러한 시간의 양은 갭 팩터로서 언급될 수 있다.

정책(118)의 다수의 파라미터(206)는 데이터가 요청되어지는 다수의 파라미터를 특정하기 위한 필드일 수 있다. 다수의 파라미터(206)는, 예컨대 0(zero) 이외의 소정의 양의 정수 값(positive integer value)일 수 있다. 각 다수의 파라미터 블록(208)은 대응하는 파라미터를 위한 데이터를 출력하기 위한 정보를 제공하는 하나 이상의 필드의 블록일 수 있다.

파라미터 블록(268)은 다수의 파라미터 블록(208) 중 하나의 예일 수 있다. 파라미터 블록(268)은 파라미터 태그(parameter tag; 270), 출력 데이터 형태(output data type; 271), 및 출력 데이터 크기(output data size; 272)를 포함할 수 있다. 파라미터 태그(270)는 특정 파라미터를 식별하기 위한 필드일 수 있다. 출력 데이터 형태(271)는 클라이언트(114)에게 특정 파라미터를 위한 데이터를 출력하는데 이용되어지는 데이터 포맷을 식별하기 위한 필드일 수 있다. 출력 데이터 크기(272)는 출력 데이터 형태(271)에 의해 특정될 수 있는 각 데이터 형태를 위한 크기를 식별하기 위한 필드일 수 있다.

출력 모드(202)를 위해 입력된 값이 최소 및 최대 데이터 모드(211)를 선택할 때, 서버 시스템(102)은 다수의 파라미터 블록(208)에서 식별된 각 파라미터를 위한 트리거 간격 내에서 최소 및 최대 값을 갖춘 데이터 포인트를 선택한다. 이들 데이터 포인트를 위한 데이터 값 및 시간 값은 이어 정책-특정 속성 상세내용(205) 및 다수의 파라미터 블록(208)을 기초로 클라이언트(114)에게 보내지도록 출력 데이터(156)를 형성하는데 이용될 수 있다.

출력 모드(202)를 위해 입력된 값이 선형 보간 모드(212)를 선택할 때, 트리거 시간을 바로 앞서는 데이터 포인트 및 트리거 시간을 바로 뒤따르는 데이터 포인트는 다수의 파라미터 블록(208)에서 식별된 각 파라미터에 대해 선택될 수 있다. 트리거 시간을 위한 데이터 값은 이들 2개의 데이터 포인트를 위한 데이터 값과 시간 값을 이용해서 보간(interpolated)될 수 있다. 이 데이터 값과 트리거 시간은 정책-특정 속성 상세내용(205) 및 다수의 파라미터 블록(208)을 기초로 클라이언트(114)에게 보내지는 출력 데이터(156)를 형성하는데 이용될 수 있다.

더욱이, 출력 모드(202)를 위해 입력된 값이 2차 보간 모드(214)를 선택할 때, 트리거 시간을 바로 앞서는 2개의 데이터 포인트 및 트리거 시간을 바로 뒤따르는 2개의 데이터 포인트는 다수의 파라미터 블록(208)에서 식별된 각 파라미터에 대해 선택된다. 이러한 트리거 시간을 위한 데이터 값은 이들 4개의 데이터 포인트를 위한 데이터 값 및 시간 값을 이용해서 보간될 수 있다. 이러한 데이터 값과 트리거 시간은 정책-특정 속성 상세내용(205) 및 다수의 파라미터 블록(208)을 기초로 클라이언트(114)에게 보내지는 출력 데이터(156)를 형성하는데 이용될 수 있다.

출력 모드(202)를 위해 입력된 값이 최종 값 모드(216)를 선택할 때, 트리거 시간에서 가장 최근의 데이터 포인트가 다수의 파라미터 블록(208)에서 식별된 각 파라미터에 대해 식별된다. 이러한 데이터 포인트는 트리거 시간과 같은 시간 값을 갖춘 데이터 포인트일 수 있다. 이러한 데이터 포인트를 위한 데이터 값은 정책-특정 속성 상세내용(205) 및 다수의 파라미터 블록(208)을 기초로 출력 데이터(156)를 형성하는데 이용된다.

출력 모드(202)를 위해 입력된 값이 가중 평균 입방 보간 모드(218)를 선택할 때, 트리거 시간을 바로 앞서는 3개의 데이터 포인트 및 트리거 시간을 바로 뒤따르는 3개의 데이터 포인트는 다수의 파라미터 블록(208)에서 식별된 각 파라미터에 대해 선택된다. 이러한 트리거 시간에서 각 파라미터를 위한 데이터 값은 이들 6개의 데이터 포인트를 위한 데이터 값 및 시간 값을 이용해서 보간될 수 있다. 이러한 데이터 값 및 트리거 시간은 정책-특정 속성 상세내용(205) 및 다수의 파라미터 블록(208)을 기초로 클라이언트(114)에게 보내지는 출력 데이터(156)를 형성하는데 이용될 수 있다.

몇몇 경우에 있어서, 출력 모드(202)를 위해 입력된 값은 디폴트 모드(210)를 선택할 수 있다. 하나의 실례로 되는 예에 있어서, 디폴트 모드(210)는 최종 값 모드(216)일 수 있다. 물론, 몇몇 다른 형태의 모드가 다른 예에서 디폴트 모드(210)를 위해 선택될 수 있다. 더욱이, 설명된 것에 부가하여 다른 모드가 다른 실례로 되는 예에서 출력 모드(202)를 위해 입력된 값에 의해 선택될 수 있다.

이러한 방식에 있어서, 클라이언트(114)는 데이터가 정책(118)을 이용해서 클라이언트(114)에게 출력되어지는 방식을 매우 명확하게 정의할 수 있게 된다. 특정 서버에 의해 취급될 수 있는 정책(118)의 부분은, 도 1의 서버 정책(128)과 같은, 서버 정책으로서 언급될 수 있다. 더욱이, 도 1의 정책 요청 취급자(140)와 같은, 정책 요청 취급자에 의해 취급되어지는 서버 정책의 부분은, 도 1의 취급자 정책(142)과 같은, 취급자 정책으로서 언급될 수 있다.

몇몇 경우에 있어서, 서버 정책(128)은 정책(118)의 모두를 포함할 수 있다. 더욱이, 몇몇 경우에 있어서, 취급자 정책(142)은 정책(118)의 모두를 포함할 수 있다. 클라이언트(114)에 의해 발생된 정책 요청(112)을 취급하도록 서버 시스템(102)에 의해 산출된 각 정책 요청 취급자는 데이터가 클라이언트(114)에게 출력되는 방식을 제어하도록 정책(118) 내에 포함된 상세내용을 이용할 수 있다.

다수의 속성(204)에서 개시된 것들과 같은 속성의 소정 조합은 정책에 포함될 수 있다. 더욱이, 다수의 속성(204)의 소정의 조합 및/또는 치환은 정책에 포함될 수 있다. 더욱이, 정책-특정 속성 상세내용(205)에서 개시된 상세내용의 소정 조합 및/또는 치환은 정책에 포함될 수 있다.

도 1의 정보 관리 환경(100) 및 도 1 내지 도 2의 정책 요청(112)의 실례는 실례로 되는 실시예가 구현될 수 있는 방식에 대한 물리적 또는 구조적 제한을 암시하도록 의미하지는 않는다. 실례로 되는 것에 부가 또는 대신하여 다른 구성요소가 이용될 수 있다. 몇몇 구성요소는 선택적일 수 있다. 또한, 블록은 몇몇 기능적 구성요소를 설명하도록 제공된다. 실례로 되는 실시예에서 구현될 때 하나 이상의 이들 블록은 결합, 분리, 또는 여러 블록으로 결합 및 분리될 수 있다.

도 3을 참조하면, 정보 관리 환경의 실례가 실례로 되는 실시예에 따라 도시된다. 이러한 실례로 되는 예에 있어서, 정보 관리 환경(300)은 도 1의 정보 관리 환경(100)에 대한 하나의 구현의 예이다.

도시된 바와 같이, 정보 관리 환경(300)은 서버 시스템(302), 데이터 공급자의 세트(304), 및 클라이언트의 세트(306)를 포함한다. 서버 시스템(302), 데이터 공급자의 세트(304), 및 클라이언트의 세트(306)는, 각각, 도 1에서의 서버 시스템(102), 데이터 공급자의 세트(106), 및 클라이언트의 세트(104)에 대한 구현의 예이다. 서버 시스템(302)은 데이터 공급자의 세트(304)로부터 획득된 데이터를 호스트하고 요청에 따라 클라이언트의 세트(306)로 이 데이터를 제공한다.

본 실례로 되는 예에 있어서, 서버 시스템(302)은 서버 콘트롤러(server controller; 308) 및 데이터 서버의 세트(set of data servers; 310)를 포함한다. 서버 콘트롤러(308) 및 데이터 서버의 세트(310)는, 각각 도 1에서의 서버 콘트롤러(108) 및 데이터 서버의 세트(110)에 대한 구현의 예이다.

서버 콘트롤러(308)는 데이터 공급자의 세트(304), 클라이언트의 세트(306) 및 데이터 서버의 세트(310)와 통신할 수 있다. 특히, 서버 콘트롤러(308)는 데이터 서버의 세트(310)의 하나 이상에 대해 데이터 공급자의 세트(304)의 특정 데이터 공급자가 데이터를 보내는 것을 결정할 수 있다. 더욱이, 서버 콘트롤러(308)는 특정 데이터 공급자가 데이터 서버의 세트(310)의 하나 이상에 대해 데이터를 보내는 것에 대한 여부를 결정할 수 있다.

도시된 바와 같이, 데이터 서버의 세트(310)는 제1 데이터 서버(312), 제2 데이터 서버(314), 제3 데이터 서버(316), 및 제4 데이터 서버(318)를 포함한다. 데이터 공급자의 세트(304)는 제1 데이터 공급자(320), 제2 데이터 공급자(322), 및 제3 데이터 공급자(324)를 포함한다. 데이터 공급자의 세트(304)는 동일한 시간 소스(time source)에 대해 동기화될 수 있어 데이터 공급자의 세트(304)로부터 데이터 서버의 세트(310)로 보내진 데이터 포인트의 시간 값이 상관(correlated)될 수 있다.

더욱이, 클라이언트의 세트(306)는 제1 클라이언트(326), 제2 클라이언트(328), 제3 클라이언트(330), 및 제4 클라이언트(332)를 포함한다.

본 실례로 되는 예에 있어서, 서버 콘트롤러(308)는 제1 데이터 공급자(320)가 제1 데이터 서버(312)로 데이터를 보내는 것에 대해 결정하였다. 서버 콘트롤러(308)는 제2 데이터 공급자(322)가 제2 데이터 서버(314)로 데이터를 보내는 것에 대해 결정하였다. 더욱이, 서버 콘트롤러(308)는 제3 데이터 공급자(324)가 제2 데이터 서버(314), 제3 데이터 서버(316), 및 제4 데이터 서버(318)의 각각에 대해 데이터의 여러 부분을 보내는 것에 대해 결정하였다. 이러한 방식에 있어서, 제2 데이터 서버(314)는 2개의 다른 데이터 공급자로부터 데이터를 수신할 수 있다.

도 4를 참조하면, 도 3으로부터의 제1 데이터 서버(312) 및 서버 콘트롤러(308)의 실례가 실례로 되는 실시예에 따라 도시된다. 본 예에 도시된 바와 같이, 서버 콘트롤러(308)는 콘트롤러 관리자(controller manager; 402)를 포함할 수 있다. 콘트롤러 관리자(402)는 구성 정보(configuration information; 404)를 억세스하고, 그에 부가하며, 검색하도록 구성될 수 있다.

하나의 실례로 되는 예에 있어서, 구성 정보(404)는 구성 데이터베이스(405)에 저장될 수 있다. 그러나, 다른 실례로 되는 예에 있어서, 구성 정보(404)는 몇몇 다른 형태의 데이터 구조에, 및/또는 서버 콘트롤러(308) 밖의 로컬 메모리(local memory)에 저장될 수 있다.

구성 정보(404)는 도 3으로부터의 데이터 공급자의 세트(304), 클라이언트의 세트(306), 및 데이터 서버의 세트(310)에 관한 정보를 포함할 수 있다. 이 정보는 메타데이터(metadata)로서 언급될 수 있다.

예컨대, 구성 정보(404)는 클라이언트의 세트(306)에 의해 만들어진 정책 요청에 관한 정보를 포함할 수 있다. 부가적으로, 구성 정보(404)는 각 데이터 서버의 세트(310)가 데이터를 수신하도록 지정되는 데이터 공급자의 세트(304)의 하나 이상의 데이터 공급자에 관한 정보를 포함할 수 있다. 구성 정보(404)는 또한 데이터 서버의 세트(310)의 하나 이상의 데이터 서버에 대해 각 데이터 공급자의 세트(304)가 데이터를 보내는 것에 관한 정보를 포함할 수 있다.

도시된 바와 같이, 콘트롤러 관리자(402)는 제1 클라이언트(326)와 통신하도록 구성될 수 있다. 이러한 통신은 콘트롤러 관리자(402)와 제1 클라이언트(326) 간의 양방향 통신(two-way communication)일 수 있다. 몇몇 경우에 있어서, 콘트롤러 관리자(402)와 제1 클라이언트(326) 간의 단지 하나의 통신 연결만이 소정의 주어진 시점에서 허용될 수 있다.

하나의 실례로 되는 예에 있어서, 제1 클라이언트(326)는 콘트롤러 관리자(402)로 정책 요청(406)을 보낸다. 정책 요청(406)은 도 1에서의 정책 요청(112)에 대한 하나의 구현의 예일 수 있다. 더욱이, 정책 요청(406)은 도 2에서 설명된 정책(118)과 유사한 방식으로 구현된 정책을 포함할 수 있다. 콘트롤러 관리자(402)는 정책 요청(406)을 기초로 다수의 서버 요청을 발생시키도록 구성될 수 있다.

예컨대, 콘트롤러 관리자(402)는 정책 요청(406)에 의해 요청되는 데이터의 적어도 일부가 제1 데이터 서버(312)에 대해 호스트됨을 결정하기 위해 구성 정보(404)를 이용할 수 있다. 콘트롤러 관리자(402)는 서버 요청(408)을 발생시키고 제1 데이터 서버(312)로 서버 요청(408)을 보낸다. 서버 요청(408)은 제1 데이터 서버(312)에 의해 취급되는 정책 요청(406)에서의 정책의 부분을 포함하는 서버 정책을 포함할 수 있다.

더욱이, 콘트롤러 관리자(402)는 제1 데이터 서버(312)가 제1 클라이언트(326)에 대해 요청된 데이터의 적어도 일부분을 보내게 됨을 제1 클라이언트(326)가 알게 하는 제1 클라이언트(326)로 메시지를 보낸다. 이러한 방식에 있어서, 제1 클라이언트(326)는 제1 데이터 서버(312)로부터 데이터를 수신하도록 준비하는 것이 가능하게 될 수 있다. 예컨대, 제1 클라이언트(326)는 제1 데이터 서버(312) 내에서 통신 링크를 확립하는 것을 개시할 수 있다.

도시된 바와 같이, 제1 데이터 서버(312)는 서버 관리자(410), 수신기(412), 및 저장 시스템(414)을 포함한다. 서버 관리자(410), 수신기(412), 및 저장 시스템(414)은, 각각 도 1에서의 서버 관리자(130), 수신기(132), 및 저장 시스템(134)에 대한 구현의 예일 수 있다.

본 실례로 되는 예에 있어서, 수신기(412)는 제1 데이터 공급자(320)로부터 데이터 포인트(416)를 수신한다. 데이터 포인트(416)는 하나 이상의 데이터 스트림으로 수신될 수 있다. 예컨대, 데이터 포인트(416)는, 제1 파라미터를 위한 데이터 포인트로 이루어지는 제1 데이터 스트림과 제2 파라미터를 위한 데이터 포인트로 이루어지는 제2 데이터 스트림을 구비하는, 2개의 데이터 스트림으로 수신될 수 있다.

수신기(412)가 데이터 포인트(416)를 수신함에 따라, 수신기(412)는 데이터 포인트(416)를 저장 시스템(414)으로 보낸다. 저장 시스템(414) 내에 저장되면, 데이터 포인트(416)는 저장된 데이터 포인트(stored data points; 418)로서 언급될 수 있다.

서버 관리자(410)는 수신기(412)가 제1 데이터 공급자(320)로부터 데이터 포인트(416)를 수신하는 것을 시작하고 중지하는 때를 제어한다. 더욱이, 몇몇 경우에 있어서, 서버 관리자(410)는 데이터 포인트(416)가 저장 시스템(414) 내에 저장되는 방식을 제어할 수 있다.

본 실례로 되는 예에 있어서, 서버 요청(408)은 서버 관리자(410)에 의해 수신될 수 있다. 서버 요청(408)은 선택된 파라미터를 위한 데이터에 대한 요청일 수 있다. 서버 관리자(410)는 서버 요청(408)이 선택된 파라미터를 위한 라이브 요청 또는 이력 요청인가의 여부를 결정할 수 있다.

여기서 이용된 바와 같이, "라이브 요청(live request)"은 실시간 또는 거의 실시간에서의 데이터를 위한 요청일 수 있다. 특히, 라이브 요청은 데이터가 어떠한 고의가 아니거나 예기치 않은 처리 지연 없이 획득됨에 따라 데이터를 수신하기 위한 요청일 수 있다. 이러한 방식에 있어서, 서버 요청(408)이 라이브 요청일 때 서버 요청(408)을 서비스하는 것은 제1 데이터 서버(312)가 어떠한 고의가 아니거나 예기치 않은 처리 지연 없이 제1 데이터 공급자(320)로부터 데이터 포인트(416)를 수신함에 따라 제1 클라이언트(326)로 데이터 포인트를 보내는 것을 포함할 수 있다.

몇몇 경우에 있어서, 라이브 요청은 지연된 라이브 요청의 형태를 취할 수 있다. 지연된 라이브 요청은 데이터 포인트의 시간 값에 적용된 몇몇 형태의 지연을 구비하는 데이터 포인트를 수신하기 위한 요청일 수 있다. 이러한 지연은 클라이언트에 의해 선택될 수 있다. 몇몇 경우에 있어서, 지연은 특정 파라미터를 위한 데이터 값의 획득과 관련된 필터 지연을 위해 정정하도록 적용될 수 있다.

여기서 이용된 바와 같이, "이력 요청(historical request)"은 몇몇 선택된 시간의 기간 내에서 획득되었던 데이터를 위한 요청일 수 있다. 예컨대, 이력 요청은 과거의 선택된 시간의 기간 내에서 선택된 파라미터를 위해 획득된 데이터 포인트를 위한 요청일 수 있다.

더욱이, 라이브 요청 및 이력 요청은 모든 샘플 요청 또는 프레임된 요청 중 어느 하나의 형태를 취할 수 있다. 서버 요청(408)이 모든 샘플 라이브 요청(every sample live request)의 형태를 취할 때, 각 선택된 파라미터를 위한 수신기(412)에서 수신된 모든 데이터 포인트는 제1 클라이언트(326)로 보내질 수 있다. 정책 요청(406)이 모든 샘플 이력 요청(every sample historical request)의 형태를 취할 때, 선택된 시간의 기간 내에서 획득되었던 선택된 파라미터를 위해 저장 시스템(414)에 저장된 모든 데이터 포인트는 제1 클라이언트(326)로 보내질 수 있다. 이들 형태의 모든 샘플 요청에 따르면, 제1 클라이언트(326)에게 보내진 각 데이터 포인트는 해당 데이터 포인트와 관련된 원래의 시간 값으로 보내질 수 있다.

프레임된 요청(framed request)에 따르면, 도 1에서의 정책-기반 데이터 프레임(150)과 유사한, 다중 정책-기반 데이터 프레임이 제1 클라이언트(326)로 보내진다. 각 정책-기반 데이터 프레임(150)은 이벤트의 발생에 응답하여 형성될 수 있다. 이벤트는, 예컨대 시간 간격의 경과(lapse of a time interval)일 수 있다. 형성된 각 정책-기반 데이터 프레임(150)은 대응하는 이벤트가 발생된 시간에서 각각 선택된 파라미터를 위한 마지막 알려진 데이터 값으로 이루어질 수 있다.

서버 요청(408)을 수신하는 것에 응답하여, 서버 관리자(410)는 서버 요청(408)을 처리한다. 이러한 실례로 되는 예에 있어서, 서버 요청(408)은 라이브 요청 또는 이력 요청 중 어느 하나, 양쪽이 아닌 형태를 취한다. 이러한 방식에 있어서, 오직 하나의 정책 요청 취급자만이 서버 요청(408)을 서비스하는 것이 필요로 될 수 있다. 그러나, 다른 실례로 되는 예에 있어서, 서버 요청(408)은 라이브 요청 및 이력 요청 양쪽을 포함할 수 있다. 이들 예에 있어서, 서버 관리자(410)는 서버 요청(408)을 서비스하기 위해 적어도 2개의 정책 요청 취급자를 활성화하는 것이 필요로 될 수 있다.

도시된 바와 같이, 서버 관리자(410)는 서버 요청(408)을 취급하기 위해 정책 요청 취급자(420)를 활성화한다. 정책 요청 취급자(420)는 도 1에서의 정책 요청 취급자(140)에 대한 하나의 구현의 예일 수 있다.

서버 관리자(410)는 수신기(412) 또는 저장 시스템(414)이 정책 요청 취급자(420)를 위한 입력 데이터 포인트(input data points; 421)의 소스로 되는가의 여부를 결정한다. 서버 요청(408)이 라이브 요청일 때, 서버 관리자(410)는 입력 데이터 포인트(421)를 위한 소스로서 수신기(412)를 선택한다. 서버 요청(408)이 이력 요청일 때, 서버 관리자(410)는 입력 데이터 포인트(421)를 위한 소스로서 저장 시스템(414)을 선택한다.

수신기(412)가 입력 데이터 포인트(421)를 위한 소스로서 선택될 때, 서버 관리자(410)는 수신기(412)에서 수신된 데이터 포인트(416)의 부분이 입력 데이터 포인트(421)로서 정책 요청 취급자(420)에게 보내지게 되는 것을 결정한다. 서버 관리자(410)로부터 수신된 명령을 기초로, 수신기(412)는 정책 요청 취급자(420)에게 제1 데이터 공급자(320)로부터 수신된 데이터 포인트(416)의 몇몇 또는 전부를 보낼 수 있다.

예컨대, 몇몇 경우에 있어서, 수신기(412)는 제1 데이터 스트림 및 제2 데이터 스트림 양쪽에서 수신된 데이터 포인트의 모두를 정책 요청 취급자(420)에게 보낼 수 있다. 다른 예에 있어서, 수신기(412)는 오직 제1 데이터 스트림에서 수신된 데이터 포인트만을 정책 요청 취급자(420)에게 보낼 수 있다.

이러한 실례로 되는 예에 있어서, 수신기(412)에서 수신된 각 데이터 포인트(416)는 데이터 값 및 시간 값을 포함할 수 있다. 데이터 값은 특정 파라미터를 위한 값일 수 있다. 예컨대, 데이터 값은 특정 파라미터를 위해 측정된 양(quantity)일 수 있다. 파라미터가 고도(altitude)이라면, 데이터 값은 10,000 피트일 수 있다. 시간 값은 데이터 값이 디지털 형태로 획득되었던 시간일 수 있다.

몇몇 경우에 있어서, 데이터 포인트는 시간 틱(time tick)의 형태를 취할 수 있다. 시간 틱은 몇몇 선택된 시간 간격을 기초로 제1 데이터 공급자(320)로부터 수신기(412)로 주기적으로 보내질 수 있다. 예컨대, 시간 틱은 매 1 밀리초(millisecond)에 관하여 수신기(412)로 보내질 수 있다. 시간 틱은 제1 데이터 공급자(320)로부터 수신기(412)로 수신기(412)에 대해 보내진 데이터 스트림을 구성할 수 있다.

하나의 실례로 되는 예에 있어서, 시간 틱은 빈 데이터 값(empty data value)과 빈 시간 값(empty time value)을 구비하여 구성되는 데이터 포인트일 수 있다. 다른 경우에 있어서, 시간 틱은 시간 틱이 형성되었던 시간을 나타내는 빈 데이터 값 및 시간 값을 구비하여 구성되는 데이터 포인트일 수 있다. 이러한 시간은 데이터 공급자의 세트(304)가 동기화 되는 동일한 시간 소스와 관련될 수 있다. 이들 실례로 되는 예에 있어서, 제1 데이터 서버(312)와 같은, 데이터 서버는 하나의 데이터 공급자로부터 단지 시간 틱만을 수신하도록 구성될 수 있다.

수신기(412)는 수신기(412)가 데이터 포인트(416)를 수신함에 따라 시간 틱에 대해 점검할 수 있다. 수신된 데이터 포인트가 실질적으로 시간 틱이면, 시간 틱은 수신기(412)로부터 데이터 포인트(416)를 수신하고 있는 소정의 활성 정책 요청 취급자(active policy request handlers)에게 보내진다. 시간 틱은 데이터 포인트가 특정 시간 간격 내에서 획득되었는가의 여부를 결정하도록 정책 요청 취급자에 의해 이용될 수 있다. 시간 틱은 시간 파라미터를 위한 간주된 데이터 포인트일 수 있다.

데이터 포인트가 시간 틱이 아니고 진정한 데이터 포인트(true data point)이면, 수신기(412)는 데이터 포인트가 활성 정책 요청 취급자가 데이터를 요청하고 있는 파라미터에 대한 것인가의 여부를 결정한다. 데이터 포인트가 활성 정책 요청 취급자가 데이터를 요청하고 있는 파라미터에 대한 것이면, 수신기(412)는 정책 요청 취급자에게 데이터 포인트를 보낸다.

저장 시스템(414)이 입력 데이터 포인트(421)를 위한 소스로서 선택될 때, 정책 요청 취급자(420)는 저장 시스템(414)에 저장된 몇몇 또는 모든 저장된 데이터 포인트(418)를 검색할 수 있다. 예컨대, 정책 요청 취급자(420)는 선택된 시간 기간 내에서 발생된 제1 파라미터 및 제2 파라미터 양쪽을 위한 모든 데이터 포인트를 포함하는 저장된 데이터 포인트(418)의 부분을 검색할 수 있다.

입력 데이터 포인트(421)를 수신하는 것에 응답하여, 정책 요청 취급자(420)는 입력 데이터 포인트(421)를 처리하고 제1 클라이언트(326)에게 보내기 위해 출력 데이터(422)를 형성한다. 출력 데이터(422)는 도 1에서의 출력 데이터(156)와 유사한 방식으로 형성될 수 있다.

입력 데이터 포인트(421)는 다수의 데이터 스트림으로 정책 요청 취급자(420)에서 비동기적으로 수신될 수 있다. 각 데이터 스트림은 여러 파라미터를 위한 데이터 포인트를 구비하여 구성될 수 있다. 예컨대, 하나의 데이터 스트림은, 예컨대 시간 파라미터를 위한 시간 틱을 구비하여 구성될 수 있다. 제2 데이터 스트림은 특정 파라미터를 위한 데이터 포인트를 구비하여 구성될 수 있다. 제3 데이터 스트림은 여러 파라미터를 위한 데이터 포인트를 구비하여 구성될 수 있다. 정책 요청 취급자(420)에서 수신된 각 데이터 스트림은 본 실례로 되는 예에 있어서 해당 데이터 스트림 내에서 시간에 관하여 순서지워질 수 있다. 그러나, 여러 데이터 스트림은 여러 데이터 속도로 수신될 수 있다. 따라서, 입력 데이터 포인트(421)는 비동기적으로 수신될 수 있다.

정책 요청 취급자(420)는 각 데이터 스트림을 처리하고 여러 데이터 스트림으로부터의 데이터 포인트를 시간에 관하여 순서화된(ordered) 데이터 포인트의 단일 어레이로 통합할 수 있다. 이 어레이는 이어 출력 데이터(422)를 형성하는데 이용될 수 있다. 정책 요청 취급자(420)가 입력 데이터 포인트(421)를 이용해서 출력 데이터(422)를 형성할 수 있는 처리가 이하 도 8에서 더욱 상세하게 설명된다.

도 5를 참조하면, 도 4로부터의 제1 데이터 서버(312)의 더욱 상세한 실례가 실례로 되는 실시예에 따라 도시된다. 도시된 바와 같이, 서버 관리자(410)는 동시에 제1 서버 요청(500) 및 제2 서버 요청(502)을 수신할 수 있다. 하나의 실례로 되는 예에 있어서, 제1 서버 요청(500) 및 제2 서버 요청(502)은 동일한 클라이언트에 의해 보내진 정책 요청으로부터 유래할 수 있다. 다른 실례로 되는 예에 있어서, 제1 서버 요청(500)은 하나의 클라이언트로부터 유래할 수 있는 한편, 제2 서버 요청(502)은 다른 클라이언트로부터 유래할 수 있다.

제1 서버 요청(500)은 라이브 요청일 수 있다. 제2 서버 요청(502)은 이력 요청일 수 있다. 서버 관리자(410)는 제1 서버 요청(500)을 취급하도록 제1 정책 요청 취급자(504)와 제2 서버 요청(502)을 취급하도록 제2 정책 요청 취급자(506)를 활성화시킨다. 서버 관리자(410)는 수신기(412) 및 제1 정책 요청 취급자(504)를 제어하여 제1 정책 요청 취급자(504)는 수신기(412)로부터 입력 데이터 포인트를 수신한다. 더욱이, 서버 관리자(410)는 제2 정책 요청 취급자(506)를 제어하여 제2 정책 요청 취급자(506)는 저장 시스템(414)으로부터 입력 데이터 포인트를 수신한다.

이러한 실례로 되는 예에 있어서, 저장 시스템(414)은 캐시(cache; 508), 디스크 라이터(disk writer; 510), 디스크 저장기(disk storage; 512), 및 캐시 큐(cache queue; 514)를 포함한다. 저장 시스템(414)이 수신기(412)로부터 현재의 데이터를 수신할 때, 현재의 데이터는 먼저 캐시(508)에 저장된다. 캐시(508)가 채워지면, 및/또는 몇몇 특정 시간의 기간이 경과 한 후, 디스크 라이터(510)는 디스크 저장기(512)에 캐시(508)의 내용을 기록하는 것을 시작할 수 있다. 이러한 방식에 있어서, 수신기(412)로부터 보내진 모든 현재의 데이터는 캐시(508)를 통해 지나갈 수 있지만, 최종적으로는 디스크 저장기(512)에 저장될 수 있다. 캐시(508)에 저장된 데이터 및 디스크 저장기(512)에 저장된 데이터 양쪽은 과거 데이터(past data)로서 언급될 수 있다.

디스크 저장기(512)는, 예컨대, 이에 한정되는 것은 아니고, 하드 디스크 드라이브, 광학 디스크 드라이브, 또는 몇몇 다른 형태의 저장 장치와 같은 소정 수의 데이터 저장 장치로 이루어질 수 있다. 구현에 따라, 디스크 저장기(512)는 영구적으로 데이터를 저장할 수 있고 및/또는 잠재적으로 데이터를 저장할 수 있다. 디스크 저장기(512)에 저장된 데이터는 필요로 될 때 캐시(508)로 되돌려 기록될 수 있다.

활성화될 때, 제2 정책 요청 취급자(506)는 제2 서버 요청(502)에 의해 요청된 서버 데이터가 캐시(508)에 위치하는가의 여부를 결정하기 위해 캐시(508)를 억세스할 수 있다. 원하는 데이터가 실제로 캐시(508)에 위치하면, 제2 정책 요청 취급자(506)는 입력 데이터로서 이 데이터를 검색할 수 있다. 그러나, 원하는 데이터가 캐시(508)에 위치하지 않으면, 제2 정책 요청 취급자(506)는 서버 관리자(410)에게 이와 같은 것을 나타내는 메시지를 보낼 수 있다. 서버 관리자(410)는 이어 캐시(508)에 되돌려 기록된 디스크 저장기(512)에 저장된 과거 데이터를 갖도록 저장 시스템(414)에 명령을 보낼 수 있다. 이러한 데이터가 캐시(508)에 되돌려 기록되면, 제2 정책 요청 취급자(506)는 이어 이 데이터를 검색하는 것이 가능하게 될 수 있다.

이러한 실례로 되는 예에 있어서, 캐시 큐(514)는 캐시(508)의 엘리먼트가 비워져(empty) 있어서 과거 데이터가 디스크 저장기(512)로부터 캐시(508)까지 판독될 수 있음을 결정하는데 이용될 수 있다. 캐시(508)가 충만(full)되고 과거 데이터가 디스크 저장기(512)로부터 캐시(508)까지 기록될 필요가 있을 때, 캐시 큐(514)는 캐시(508)의 엘리먼트가 가장 오래된 데이터를 저장하여 이러한 가장 오래된 데이터가 중복기록(overwritten)될 수 있음을 결정하는데 이용될 수 있다. 더욱이, 캐시 큐(514)는 캐시(508)의 엘리먼트가 수신기(412)로부터 수신된 현재 데이터를 저장하기 위해 이용가능함을 결정하는데 이용될 수 있다.

도 6을 참조하면, 구성 정보의 실례가 실례로 되는 실시예에 따라 도시된다. 도 6에 있어서, 도 4에서의 구성 정보(404)를 위한 하나의 구현의 예가 도시된다. 구성 정보(404)는 다양한 형태의 메타데이터를 포함할 수 있다. 몇몇 경우에 있어서, 구성 정보(404) 내에 포함된 메타데이터는 콘트롤러 관리자(402)를 통해 도 3의 클라이언트의 세트(306) 중 하나 이상에 의해 질의(queried)될 수 있다.

이러한 실례로 되는 예에 있어서, 구성 정보(404)는 공급자 메타데이터(provider metadata; 600), 서버 메타데이터(server metadata; 602), 데이터셋 메타데이터(dataset metadata; 604), 및 클라이언트 메타데이터(client metadata; 606)를 포함할 수 있다. 이러한 실례로 되는 예에 있어서, 공급자 메타데이터(600)는 데이터 공급자, 데이터 공급자에 의해 제공된 데이터, 및 데이터가 데이터 공급자로부터 보내지는 데이터 서버를 추적(track)하는데 이용될 수 있다. 예컨대, 공급자 메타데이터(600)는 도 3에서의 데이터 공급자의 세트(304)를 추적하기 위해 도 4의 콘트롤러 관리자(402)에 의해 이용될 수 있다.

공급자 메타데이터(600)는 파라미터 메타데이터(parameter metadata; 608)와 관련될 수 있다. 파라미터 메타데이터(608)는 데이터가 도 3의 서버 시스템(302)에서 호스트되어지는 여러 파라미터를 식별할 수 있다. 공급자 메타데이터(600) 및 파라미터 메타데이터(608)는 데이터 공급자의 세트(304)의 각각이 데이터를 공급하는 여러 형태의 파라미터를 추적하는데 이용될 수 있다.

서버 메타데이터(602)는 데이터 서버 및 이들 데이터 서버의 각각에 대해 호스트된 데이터를 추적하는데 이용될 수 있다. 예컨대, 서버 메타데이터(602)는 도 3에서의 데이터 서버의 세트(310)를 추적하도록 도 4에서의 콘트롤러 관리자(402)에 의해 이용될 수 있다. 서버 메타데이터(602), 공급자 메타데이터(600), 및 파라미터 메타데이터(608)는 데이터가 데이터 공급자의 세트(304)의 여러 데이터 공급자로부터 데이터 서버의 세트(310)의 각각에서 수신되는 여러 형태의 파라미터를 추적하는데 이용될 수 있다.

이러한 실례로 되는 예에 있어서, 데이터셋 메타데이터(604)는 데이터셋을 추적하는데 이용될 수 있다. 여기서 이용된 바와 같이, "데이터셋(dataset)"은 시간이 단조롭게 증가하는 데이터의 논리적 블록일 수 있다. 데이터셋은 시간이 소정 블록을 커버할 수 있다. 예컨대, 데이터셋은 시간의 선택된 기간에 걸쳐 획득되었던 모든 데이터를 포함할 수 있다. 하나의 특정 예로서, 데이터셋은 하루의 과정에 걸쳐 항공기의 동작의 테스트 실행 동안 데이터 공급자의 세트(304)에 의해 획득되었던 모든 데이터를 나타낼 수 있다.

각 데이터셋 내에서, 시간에 걸쳐 수집된 데이터 포인트는 파라미터 당 단조롭게-증가하는 시간 순서(monotonically-increasing time order)로 간주될 수 있다. 즉, 특정 데이터 서버가 특정 데이터셋에 대한 데이터 포인트를 수신함에 따라, 각 파라미터에 대한 모든 데이터 포인트는, 가장 빠르게 획득된 데이터 포인트가 먼저 데이터 서버에서 수신됨에 따라, 시간에 관하여 순서화될 수 있다.

소정의 주어진 시점에서, 고작 단지 하나의 데이터셋만이 활성화될 수 있다. 활성 데이터셋(active dataset)은 라이브 데이터가 이용가능하고 라이브 데이터가 데이터 서버의 세트(310)에서 현재 수신되고 있는 데이터셋일 수 있다. 이러한 실례로 되는 예에서, 오직 하나의 데이터셋만이 소정의 주어진 시점에서 제공될 수 있다. 그러나, 다른 실례로 되는 예에 있어서, 다중 활성 데이터 셋이 제공될 수 있다.

데이터셋 메타데이터(604)는 데이터가 도 3의 데이터 서버의 세트(310)에 의해 수신되는 각 데이터셋을 추적할 수 있다. 데이터셋 메타데이터(604)는 파라미터 메타데이터(608)와 관련될 수 있고, 양쪽은 데이터가 각 데이터셋에서 수집되는 파라미터를 추적하는데 이용될 수 있다. 더욱이, 데이터셋 메타데이터(604)는 또한 이벤트 메타데이터(event metadata; 610), 상황 메타데이터(condition metadata; 612), 및 정책 요청 메타데이터(policy request metadata; 614)와 관련될 수 있다. 이벤트 메타데이터(610) 및 상황 메타데이터(612)는 데이터셋과 관련될 수 있는 부가적 주석(additional notes)을 제공할 수 있다.

더욱이, 데이터셋 메타데이터(604) 및 정책 요청 메타데이터(614)는 데이터가 정책 요청에 의해 요청되는 특정 데이터셋을 추적하는데 이용될 수 있다. 이러한 실례로 되는 예에 있어서, 클라이언트로부터의 각 정책 요청은 오직 단일 데이터셋 내에서 데이터를 요청할 수 있다.

클라이언트 메타데이터(606)는 클라이언트를 추적하는데 이용될 수 있다. 예컨대, 클라이언트 메타데이터(606)는 도 3에서의 클라이언트의 세트(306)를 추적하는데 이용될 수 있다. 클라이언트 메타데이터(606)는 정책 요청 메타데이터(614)와 관련될 수 있다. 클라이언트 메타데이터(606) 및 정책 요청 메타데이터(614)는 각 클라이언트에 의해 만들어진 정책 요청을 추적하는데 이용될 수 있다.

이러한 방식에 있어서, 구성 정보(404)는 데이터 공급자의 세트(304), 데이터 서버의 세트(310), 및 클라이언트의 세트(306)를 관리하기 위해 도 4에서의 서버 콘트롤러(308)의 콘트롤러 관리자(402)에 의해 이용될 수 있다. 물론, 다른 실례로 되는 예에 있어서, 다른 형태의 메타데이터가 상기 설명된 것에 부가 및/또는 대신하여 구성 데이터베이스(405) 내에 포함될 수 있다.

도 7을 참조하면, 도 4의 제1 데이터 서버(312)의 서버 관리자(410)의 실례가 실례로 되는 실시예에 따라 도시된다. 이러한 실례로 되는 예에 있어서, 서버 관리자(410)는 메모리 관리자(memory manager; 700), 공급자 추적자(provider tracker; 702), 데이터셋 추적자(dataset tracker; 704), 서버 요청 추적자(server request tracker; 706), 및 취급자 관리자(handler manager; 708)를 포함할 수 있다.

이러한 실례로 되는 예에 있어서, 메모리 관리자(700)는 제1 데이터 서버(312) 내에서 공유 메모리(shared memory)를 관리하도록 구성될 수 있다. 예컨대, 도 4의 저장 시스템(414)은 서버 관리자(410)와 공유될 수 있는 메모리의 일부분을 포함할 수 있다. 메모리 관리자(700)는 이러한 공유 메모리를 관리한다. 더욱이, 메모리 관리자(700)는 제1 데이터 서버(312)의 소정의 캐시 메모리를 관리하도록 구성될 수 있다. 예컨대, 메모리 관리자(700)는 도 5에서의 캐시(508)를 관리할 수 있다.

공급자 추적자(702)는 제1 데이터 서버(312)가 데이터를 수신하고 있는 도 3의 데이터 공급자의 세트(304)의 하나 이상의 데이터 공급자를 추적할 수 있다. 데이터셋 추적자(704)는 데이터가 제1 데이터 서버(312)에서 수신되는 데이터셋을 추적할 수 있다. 서버 요청 추적자(706)는 제1 데이터 서버(312)에서 수신된 서버 요청을 추적할 수 있다. 더욱이, 취급자 관리자(708)는 제1 데이터 서버(312) 내의 소정의 주어진 시간에서 활성화되는 정책 요청 취급자를 추적할 수 있다.

이러한 방식에 있어서, 서버 관리자(410)는 도 4 및 도 5에서 알 수 있는 바와 같이 제1 데이터 서버(312) 내에서 활성화되는 수신기(412), 저장 시스템(414), 및 정책 요청 취급자를 효과적으로 관리하는 것이 가능하게 될 수 있다. 더욱이, 서버 관리자(410)는, 도 3의 서버 콘트롤러(308)로부터 수신된, 서버 요청을 포함하는, 정책 요청 정보를 추적하는 것이 가능하게 될 수 있다.

도 8을 참조하면, 도 4의 정책 요청 취급자(420)의 실례가 실례로 되는 실시예에 따라 도시된다. 이러한 실례로 되는 예에 있어서, 정책 요청 취급자(420)는 데이터 합병기(data merger; 800), 정책-기반 데이터 관리자(policy-based data manager; 802), 출력 패킷화기(output packetizer; 804), 전송기(transmitter; 806)를 포함한다.

데이터 합병기(800)는 다수의 비동기 데이터 스트림(plurality of asynchronous data streams; 801)으로 도 4로부터 입력 데이터 포인트(421)를 수신하도록 구성될 수 있다. 다수의 비동기 데이터 스트림(801)은 여러 속도를 갖춘 데이터 스트림을 포함할 수 있다. 예컨대, 다수의 비동기 데이터 스트림(801)의 데이터 스트림은 다수의 비동기 데이터 스트림(801)의 다른 데이터 스트림 이외의 여러 데이터 속도로 수신될 수 있다.

하나의 실례로 되는 예에 있어서, 다수의 비동기 데이터 스트림(801)은 제1 파라미터를 위한 제1 데이터 포인트(805)를 구비하는 제1 데이터 스트림(803) 및 제2 파라미터를 위한 제2 데이터 포인트(809)를 구비하는 제2 데이터 스트림(807)을 포함한다. 부가적으로, 다수의 비동기 데이터 스트림(801)은 또한 시간 틱 스트림(time tick stream; 810)을 포함할 수 있다. 시간 틱 스트림(810)은 시간 틱의 데이터 스트림일 수 있다.

제1 데이터 포인트(805)는 제1 데이터 스트림(803) 내에서 단조롭게 증가하는 시간 순서로 될 수 있다. 제2 데이터 포인트(809)는 제2 데이터 스트림(807) 내에서 단조롭게 증가하는 시간 순서로 될 수 있다.

데이터 합병기(800)는 시간-순서화된 데이터 포인트(time-ordered data points; 811)를 구비하는 시간-순서화된 데이터 어레이(time-ordered data array; 808)를 형성하기 위해 제1 데이터 포인트(805)를 제2 데이터 포인트(809)와 합병하도록 구성될 수 있다. 시간-순서화된 데이터 포인트(811)는 단조롭게 증가하는 시간 순서로 될 수 있다. 특히, 시간-순서화된 데이터 어레이(808)는 각 데이터 포인트를 위한 시간 값을 기초로 증가하는 시간 순서로 시간-순서화된 데이터 어레이(808)에 제1 데이터 포인트(805) 및 제2 데이터 포인트(809)를 부가하는 것에 의해 형성될 수 있다.

데이터 합병기(800)는 처리를 위해 정책-기반 데이터 관리자(802)로 시간-순서화된 데이터 어레이(808)의 시간-순서화된 데이터 포인트(811)를 보낸다. 정책-기반 데이터 관리자(802)는 시간-순서화된 데이터 포인트(811)를 처리하기 위해 취급자 정책(handler policy; 812)을 이용하도록 구성될 수 있다. 취급자 정책(812)은 도 4의 서버 관리자(410)로부터 수신될 수 있다. 취급자 정책(812)은 정책 요청 취급자(420)에 의해 이용되어지는 도 4의 서버 요청(408)에서의 서버 정책의 부분을 포함할 수 있다. 취급자 정책(812)은 도 2에서 설명된 정책(118)과 유사한 방식으로 구현될 수 있다.

정책-기반 데이터 관리자(802)는 정책-기반 데이터(policy-based data; 813)를 형성하기 위해 취급자 정책(812) 및 시간-순서화된 데이터 포인트(811)를 이용한다. 정책-기반 데이터(813)는 이어 출력 패킷화기(804)로 보내질 수 있다.

서버 요청(408)이 모든 샘플 요청임을 취급자 정책(812)가 나타낼 때, 정책-기반 데이터 관리자(802)는 간단하게 시간-순서화된 데이터 포인트(811)의 각 데이터 포인트를 출력 패킷화기(804)로 보낼 수 있다. 출력 패킷화기(804)로 보내진 시간-순서화된 데이터 포인트(811)의 각 시간-순서화된 데이터 포인트는 데이터 포인트가 획득되었던 시간을 나타내는 데이터 포인트와 관련된 원래의 시간 값을 유지한다.

그러나, 서버 요청(408)이 포맷된 요청임을 취급자 정책(812)이 나타낼 때, 정책-기반 데이터 관리자(802)는 정책-기반 데이터 프레임의 세트(set of policy-based data frames; 814)를 형성하기 위해 시간-순서화된 데이터 포인트(811)를 이용할 수 있다. 예컨대, 취급자 정책(812)은 클라이언트가 매 1 초에 대하여 데이터 프레임을 수신하도록 원함을 나타낼 수 있다.

매 1초 간격에 대한 경과에서, 정책-기반 데이터 관리자(802)는 실질적으로 시간 간격의 경과와 일치하는 제1 파라미터를 위한 데이터 포인트와 실질적으로 시간 간격의 경과와 일치하는 제2 파라미터를 위한 데이터 포인트에 대한 데이터 값을 식별할 수 있다. 이들 데이터 포인트를 위한 데이터 값은 이어 이들 데이터값과 프레임 시간 값을 구비하는 데이터 프레임을 형성하기 위해 추출되어 이용될 수 있다. 이 데이터 프레임에 할당된 프레임 시간 값은 1 초 간격이 경과하는 시간 또는 제1 파라미터를 위해 선택된 데이터 포인트 또는 제2 파라미터를 위해 선택된 데이터 포인트 중 어느 하나를 위한 실제 시간 값일 수 있다. 몇몇 경우에 있어서, 각 데이터 값은 프레임 시간 값과 관련되는 데이터 프레임의 모두에 부가하여 데이터 값을 위한 실제 시간 값과 관련될 수 있다.

몇몇 경우에 있어서, 데이터 포인트가 시간 간격이 경과하는 시간과 정확하게 일치하지 않을 때, 정책-기반 데이터 관리자(802)는 제1 파라미터 및 제2 파라미터를 식별하기 위해 보간 기법(interpolation techniques)을 이용할 수 있다. 이들 기법은, 예컨대, 제한 없이, 시간 간격이 경과되는 시간 전 또는 후의 N 데이터 값을 기초로 새로운 데이터 값을 추출하는 것을 포함할 수 있다. 구현에 따라, 이용되는 보간의 형태는 취급자 정책(812)에 의해 특정될 수 있다.

다른 실례로 되는 예에 있어서, 정책-기반 데이터 관리자(802)는 해당 시간에서 제1 파라미터를 위한 마지막 알려진 데이터 값과 제2 파라미터를 위한 마지막 알려진 데이터 값을 식별한다. 제1 파라미터를 위한 마지막 알려진 데이터 값은 제1 데이터 스트림(803)의 다른 데이터 포인트에 비해 간격이 경과하는 시간 이전 및 가장 가까운 시간 값을 갖춘 제1 데이터 스트림(803)으로부터의 제1 데이터 포인트의 데이터 값일 수 있다. 마찬가지로, 제2 파라미터를 위한 마지막 알려진 데이터 값은 제2 데이터 스트림(807)의 다른 데이터 포인트에 비해 간격이 경과하는 시간 이전 및 가장 가까운 시간 값을 갖춘 제2 데이터 스트림(807)으로부터의 제2 데이터 포인트의 데이터 값일 수 있다.

정책-기반 데이터(813)가 형성됨에 따라, 정책-기반 데이터(813)는 다른 처리를 위해 출력 패킷화기(804)로 보내질 수 있다. 출력 패킷화기(804)는 고정된 크기의 하나 이상의 버퍼를 이용하는 정책-기반 데이터(813)를 버퍼링할 수 있다. 하나의 실례로 되는 예로서, 출력 패킷화기(804)는 커런트 버퍼(current buffer; 816)를 이용해서 정책-기반 데이터(813)를 버퍼링할 수 있다.

커런트 버퍼(816)가 충만일 때 또는 대기 시간(latency time)의 몇몇 소정 양이 경과하였을 때, 커런트 버퍼(816)는 전송을 기다리기 위해 전송기(806)로 보내질 수 있고 전송기 버퍼 리스트(transmitter buffer list; 818)의 부분으로 될 수 있다. 전송기(806)는 전송기 버퍼 리스트(818)를 이용해서 전송을 기다리는 커런트 버퍼를 추적할 수 있다. 전송기(806)는 전송을 기다리는 커런트 버퍼의 콘텐츠를 출력 데이터(422)의 형태로 도 3 및 도 4의 제1 클라이언트(326)로 내보낼 수 있다.

도 9를 참조하면, 도 8의 데이터 합병기(800)의 실례가 실례로 되는 실시예에 따라 도시된다. 도 9에 있어서, 입력 데이터 포인트(421)가 도 8의 데이터 합병기(800)에 의해 시간에 관하여 함께 합병될 수 있는 하나의 방식의 예가 도시된다.

도시된 바와 같이, 입력 데이터 포인트(421)는 제1 데이터 스트림(803) 및 제2 데이터 스트림(807)에서 수신될 수 있다. 제1 데이터 스트림(803)의 제1 데이터 포인트(805)는 제1 큐(first queue; 900)에 위치할 수 있고, 반면 제2 데이터 스트림(807)의 제2 데이터 포인트(809)는 제2 큐(second queue; 902)에 위치할 수 있다.

이러한 실례로 되는 예에 있어서, 제1 데이터 포인트(805)는 시스템 지연 없이 수신될 수 있다. 그러나, 제2 데이터 포인트(809)는 약 0.5초의 시스템 지연에 따라 수신될 수 있다. 즉, 각 제2 데이터 포인트(809)를 위한 시간 값은 데이터 포인트를 위한 데이터 값이 획득된 실제 시간으로부터 약 0.5초 만큼 지연될 수 있다. 이러한 시스템 지연은 또한 필터 지연(filter delay)으로서 언급될 수 있다.

이러한 시스템 지연이 알려지기 때문에, 데이터 합병기(800)는 제1 데이터 스트림(803)과 제2 데이터 스트림(807)의 합병 동안 이러한 지연을 고려한다. 데이터 합병기(800)는 제2 데이터 포인트(809)가 제2 큐(902) 내에 도착할 수 있도록 하기 위해 약 0.75초의 큐 지연 시간(queue delay time; 904) 동안 제1 큐(900)에 제1 데이터 포인트(805)를 유지할 수 있다.

현재 시간(current time; 906)은 시간 틱 스트림(810)에서 수신된 시간 틱(907)을 기초로 알려진 현재 시간일 수 있다. 현재 시간(906)에서 큐 지연 시간(904)을 빼면 약 1.25초의 출력 제한 시간(output limit time; 908)을 초래한다. 본 실례로 되는 예에 있어서, 출력 제한 시간(908) 보다 더 일찍 획득되었던 제1 큐(900) 및 제2 큐(902)에 저장된 소정의 데이터 포인트는 시간-순서화된 데이터 포인트(811)로서 시간-순서화된 데이터 어레이(808)에 부가된다. 시간-순서화된 데이터 포인트(811)는 이어 도 8의 정책-기반 데이터 관리자(802)에게 처리를 위해 보내질 수 있다.

출력 제한 시간(908) 보다 후에 획득되었던 제1 큐(900) 및 제2 큐(902)에 저장된 소정의 데이터 포인트는 제1 큐(900) 및 제2 큐(902)에 유지된다. 시간이 진행됨에 따라, 따라서 출력 제한 시간(908)은 변화하는 현재 시간(906)을 기초로 변화하여 데이터 포인트가 시간-순서화된 데이터 포인트를 형성하기 위해 연속적으로 합병되고 처리를 위해 내보내진다.

시스템 지연 또는 필터 지연이 특정 파라미터를 위한 데이터 포인트를 위해 존재하지 않는 경우, 큐 지연 시간(904)은 필요로 되지 않을 수 있다. 오히려, 최대 대기 시간(maximum latency time)이 이용될 수 있다. 이 최대 대기 시간은 도 4에서 보여지는 정책 요청 취급자(420) 또는 클라이언트에 의해 선택될 수 있고, 또는 미리 결정될 수 있다.

다른 실례로 되는 예에 있어서, 데이터 합병기(800)는 시스템 지연과 관련된 데이터 포인트를 위한 시간 값을 조정하도록 구성될 수 있다. 예컨대, 데이터 합병기(800)는 제2 데이터 포인트(809)가 제2 큐(902)에 부가됨에 따라 제2 데이터 포인트(809)를 위한 시간 값을 조정하도록 구성될 수 있다. 특히, 각 데이터 값은 시스템 지연을 위해 조정하도록 약 0.5 초 만큼 감소될 수 있다. 이러한 방식에 있어서, 큐 지연 시간(904)은 이용되어질 필요가 없다.

부가적으로, 시간-순서화된 데이터 어레이(808)의 공간 및/또는 크기의 양은 재구성가능할 수 있다. 특히, 시간-순서화된 데이터 어레이(808)의 공간 및/또는 크기의 양은 여러 형태의 시스템 지연을 수용하기 위해 동적으로 변경될 수 있다.

도 10을 참조하면, 도 8로부터의 정책-기반 데이터 관리자(802)의 실례가 실례로 되는 실시예에 따라 도시된다. 정책-기반 데이터 관리자(802)는 도 8에서 정책-기반 데이터(813)를 형성하기 위해 시간-순서화된 데이터 포인트(811)를 수신하고 시간-순서화된 데이터 포인트(811)를 처리하도록 구성된다. 이러한 실례로 되는 예에 있어서, 정책-기반 데이터(813)가 보간될 수 있는 방식의 예가 도시된다.

간격 값(1002)은 0.5초 간격이 경과하고 데이터 프레임이 형성되어지는 시간을 나타낸다. 제1 데이터 포인트(1004)는 제1 파라미터를 위한 시간-순서화된 포인트이다. 제2 데이터 포인트(1006)는 제2 파라미터를 위한 시간-순서화된 데이터 포인트이다.

도시된 바와 같이, 시간 간격(1008)과 정확하게 일치하는 데이터 포인트는 없다. 결과적으로, 정책-기반 데이터 관리자(802)는 시간 간격(1008)을 위한 데이터 프레임을 형성하기 위해 이용되어지는 데이터 값을 식별하도록 보간(interpolation)을 이용할 수 있다. 이러한 실례로 되는 예에 있어서, 데이터 포인트(1010)를 위한 데이터 값과 데이터 포인트(1012)를 위한 데이터 값은 데이터 프레임을 형성하는데 이용하기 위해 식별된다. 데이터 포인트(1010)는 시간 간격(1008) 후 다음의 가장 오래된 시간 값을 갖춘 제1 데이터 포인트(1004) 내의 데이터 포인트이다. 데이터 포인트(1012)는 시간 간격(1008) 후 다음의 가장 오래된 시간 값을 갖춘 제2 데이터 포인트(1006) 내의 데이터 포인트이다.

마찬가지로, 시간 간격(1014)을 위해 형성되어지는 데이터 프레임에 대해, 데이터 포인트(1016)를 위한 데이터 값과 데이터 포인트(1018)를 위한 데이터 값은 데이터 프레임을 형성하는데 이용하기 위해 식별된다. 데이터 포인트(1016)는 시간 간격(1014) 후 다음의 가장 오래된 시간 값을 갖춘 제1 데이터 포인트(1004) 내의 데이터 포인트이다. 데이터 포인트(1018)는 시간 간격(1014) 후 다음의 가장 오래된 시간 값을 갖춘 제2 데이터 포인트(1006) 내의 데이터 포인트이다.

상기한 도 8 내지 도 10에서, 데이터 합병기(800)는 정책-기반 데이터 관리자(802)에 의해 처리되는 시간-순서화된 데이터 포인트(811)로 시간-순서화된 데이터 어레이(808)를 형성하는 것으로서 설명됨에도 불구하고, 다른 형태의 어레이가 다른 구현으로 형성될 수 있다. 다른 실례로 되는 예에 있어서, 제1 데이터 포인트(805)는 시간 외의 몇몇 다른 요소에 따라 제2 데이터 포인트(809)와 합병될 수 있다. 예컨대, 제1 데이터 포인트(805)는 데이터-순서화된 어레이를 형성하도록 제2 데이터 포인트(809)와 합병될 수 있다. 데이터-순서화된 어레이는 데이터 포인트를 위한 데이터 값과 관련하여 순서화된 데이터 포인트의 어레이일 수 있다. 데이터 포인트는 증가하는 순서, 감소하는 순서로 순서화될 수 있고, 데이터 값의 형태를 기초로 소트(sorted)될 수 있으며, 또는 몇몇 다른 방식으로 순서화 및/또는 소트될 수 있다.

또 다른 실례로 되는 실시예에 있어서, 정책-기반 데이터 관리자(802)는 정책-기반 데이터(813)를 형성하기 위해 보간에 부가 및/또는 대신하여 다른 기법을 이용하도록 구성될 수 있다. 예컨대, 정책-기반 데이터 관리자(802)는 데이터 합병기(800)에 의해 제공된 데이터 포인트를 이용해서 정책-기반 데이터(813)를 형성하기 위해 외삽 기법(extrapolation technique), 커브-피팅 기법(curve-fitting technique), 방정식-피팅 기법(equation-fitting technique), 필터링 기법(filtering technique), 예측 기법(predictive technique), 데이터 필링 기법(data filling technique), FFT(fast Fourier transform) 기법, 제로 위상 실시간 필터링(zero phase real-time filtering)(SPF) 기법, 또는 몇몇 다른 형태의 기법이나 알고리즘 중 적어도 하나를 이용할 수 있다.

도 11을 참조하면, 클라이언트에게 데이터를 제공하기 위한 프로세스의 실례가 실례로 되는 실시예에 따라 플로우차트의 형태로 도시된다. 도 11에 개시된 프로세스는 도 1에서의 서버 시스템(103)을 이용해서 구현될 수 있다.

프로세스는 서버 시스템의 데이터 서버의 세트에서 데이터 공급자의 세트로부터 데이터를 수신하는 것에 의해 시작한다(동작 1100). 다음에, 클라이언트로부터의 정책 요청이 서버 시스템의 서버 콘트롤러에서 수신된다(동작 1102). 동작 1102에서, 정책 요청은 정책에 따른 데이터를 위한 요청이다.

서버 콘트롤러는 클라이언트에 의해 요청되는 데이터를 호스팅하는 데이터 서버의 세트의 하나 이상의 데이터 서버를 식별한다(동작 1104). 서버 콘트롤러는 클라이언트에 의해 요청되는 데이터를 호스팅함에 따라 식별된 각 데이터 서버의 세트로 서버 요청을 보낸다(동작 1106). 동작 1106에서, 서버 요청은 서버 정책에 따른 데이터를 위한 요청이다. 서버 정책은 정책 요청을 서비스함에 있어서 서버에 의해 이용되어지는 정책 요청에서의 정책의 부분을 포함한다.

서버 요청을 수신하는 것에 응답하여, 데이터 서버의 세트의 각 데이터 서버는 서버 요청을 서비스하기 위해 다수의 정책 요청 취급자를 활성화시키고 이어 서버 정책에 따라 클라이언트에게 요청된 데이터를 보내고(동작 1108), 그 후 처리가 종료된다.

도 12를 참조하면, 서버 요청을 취급하기 위한 프로세스의 실례가 실례로 되는 실시예에 따라 플로우차트의 형태로 도시된다. 도 12에 개시된 프로세스는, 도 1에서의 데이터 서버(124)와 같은, 데이터 서버에 의해 구현될 수 있다. 더욱이, 프로세스는 도 11에서 동작 1108을 구현하는데 이용될 수 있다.

프로세스는 데이터 서버의 서버 관리자에서 서버 요청을 수신하는 것에 의해 시작한다(동작 1200). 서버 요청은 클라이언트에 의해 보내진 정책 요청으로부터 유래될 수 있다. 서버 관리자는 서버 요청을 수신하는 것에 응답하여 서버 요청을 취급하도록 데이터 서버 내의 정책 요청 취급자를 활성화시킨다(동작 1202). 서버 관리자는 데이터 서버의 수신기 또는 데이터 서버의 저장 시스템이 서버 요청을 기초로 정책 요청 취급자를 위한 다수의 비동기 데이터 스트림의 소스로 되는가의 여부를 결정한다(동작 1204).

동작 1204에서, 수신기는 서버 요청이 라이브 요청일 때 소스로서 선택된다. 저장 시스템은 요청이 이력 요청일 때 소스로서 선택된다.

다수의 비동기 데이터 스트림이, 정책 요청 취급자에 의해, 서버 관리자에 의해 식별된 소스로부터 수신된다(동작 1206). 다수의 비동기 데이터 스트림은 다른 데이터 속도로 정책 요청 취급자에서 수신된 적어도 2개의 데이터 스트림을 포함할 수 있다.

다음에, 다수의 비동기 데이터 스트림에서의 데이터 포인트는, 정책 요청 취급자에 의해, 시간-순서화된 데이터 포인트를 형성하도록 함께 합병된다(동작 1208). 그 후, 정책-기반 데이터가, 정책 요청 취급자에 의해, 서버 요청에서 식별된 서버 정책에 따라 시간-순서화된 데이터 포인트를 이용해서 형성된다(동작 1210).

이어 정책-기반 데이터는, 정책 요청 취급자에 의해, 서버 요청이 형성되었던 정책 요청을 유래시킨 클라이언트에게 출력 데이터로서 보내지고(동작 1212), 그 후 프로세스가 종료된다. 서버 요청이 라이브 요청일 때, 동작 1206, 1208, 1210, 및 1212는 데이터를 보내는 것을 중지하기 위한 요청이 클라이언트에 의해 수신될 때 까지 연속적으로 형성될 수 있다.

도 13을 참조하면, 정책-기반 데이터를 형성하기 위한 프로세스의 실례가 실례로 되는 실시예에 따라 도시된다. 도 13에 개시된 프로세스는, 예컨대 도 1에서의 정책 요청 취급자(140)와 같은, 정책 요청 취급자에 의해 수행될 수 있다. 더욱이, 이러한 처리는 도 12에서의 동작 1210을 구현하는데 이용될 수 있다.

프로세스는 시간-순서화된 데이터 포인트를 수신하는 것에 의해 시작한다(동작 1300). 다음에, 결정이 시간-순서화된 데이터 포인트가 형성된 서버 요청이 모든 샘플 요청(every sample request) 또는 프레임된 요청(framed request)인가의 여부에 대해 이루어진다(동작 1302).

서버 요청이 모든 샘플 요청이면, 정책-기반 데이터는 시간-순서화된 데이터 포인트에서의 모든 데이터 포인트를 이용해서 형성된다(동작 1304). 정책-기반 데이터를 형성하기 위해 이용된 각 데이터 포인트는 데이터 포인트와 관련된 원래의 시간 값을 유지한다. 다음에, 결정이 시간-순서화된 데이터 포인트가 여전히 수신되고 있는가의 여부에 대해 이루어진다(동작 1306). 시간-순서화된 데이터 포인트가 여전히 수신되고 있다면, 프로세스는 상기한 바와 같이 동작 1304로 되돌아간다. 그렇지 않으면, 프로세스가 종료된다.

다시 동작 1302를 참조하면, 서버 요청이 프레임된 요청이면, 데이터 프레임이 형성되어지는 이벤트가 식별된다(동작 1308). 이 이벤트는 또한 트리거(trigger)로서 언급될 수 있다. 그 후, 이벤트의 모든 발생에 대해, 정책-기반 데이터 프레임이 정책-기반 데이터 프레임의 세트를 형성하기 위해 시간-순서화된 데이터 포인트를 이용해서 형성된다(동작 1310).

다음에, 결정이 시간-순서화된 데이터 포인트가 여전히 수신되고 있는가의 여부에 대해 이루어진다(동작 1312). 시간-순서화된 데이터 포인트가 여전히 수신되고 있다면, 프로세스는 상기한 바와 같이 동작 1310으로 되돌아간다. 그렇지 않으면, 프로세스가 종료된다.

도 14를 참조하면, 블록도의 형태로 데이터 처리 시스템의 실례가 실례로 되는 실시예에 따라 도시된다. 데이터 처리 시스템(1400)은 도 1에서의 데이터 공급자의 세트(106), 클라이언트의 세트(104), 데이터 서버의 세트(110), 및 서버 콘트롤러(108) 중 하나를 구현하는데 이용될 수 있다. 도시된 바와 같이, 데이터 처리 시스템(1400)은 프로세서 유닛(1404), 저장 장치(1406), 통신 유닛(1408), 입력/출력 유닛(1410), 및 디스플레이(1412) 사이에서 통신을 제공하는, 통신 프레임워크(communications ; 1402)를 포함한다. 몇몇 경우에 있어서, 통신 프레임워크(1402)는 버스 시스템으로서 구현될 수 있다.

프로세서 유닛(1404)은 다수의 동작을 수행하기 위해 소프트웨어를 위한 명령을 실행하도록 구성된다. 프로세서 유닛(1404)은, 특정 구현에 따라, 다수의 프로세서, 다중-프로세서 코어(multi-processor core), 및/또는 몇몇 다른 형태의 프로세서를 구비하여 구성될 수 있다. 몇몇 경우에 있어서, 프로세서 유닛(1404)은, 회로 시스템, ASIC(application specific integrated circuit), 프로그래머블 로직 장치(programmable logic device), 또는 몇몇 다른 적절한 형태의 하드웨어 유닛과 같은, 하드웨어 유닛의 형태를 취할 수 있다.

오퍼레이팅 시스템, 어플리케이션, 및/또는 프로세서 유닛(1404)에 의해 실행되는 프로그램을 위한 명령은 저장 장치(1406)에 위치될 수 있다. 저장 장치(1406)는 통신 프레임워크(1402)를 통해 프로세서 유닛(1404)와 통신에 있을 수 있다. 여기서 이용된 바와 같이, 또한 컴퓨터 판독가능 저장장치로서 언급되는, 저장 장치는 잠정적 및/또는 영구적 기반 상에서 정보를 저장할 수 있는 소정 개의 하드웨어이다. 이러한 정보는, 이에 한정되는 것은 아니고, 데이터, 프로그램 코드, 및/또는 다른 정보를 포함할 수 있다.

메모리(1414) 및 영구 저장기(1416)는 저장 장치(1406)의 예이다. 메모리(1414)는, 예컨대 랜덤 억세스 메모리(random access memory) 또는 몇몇 형태의 휘발성 또는 비휘발성 저장 장치의 형태를 취할 수 있다. 영구 저장기(1416)는 소정 수의 구성요소 또는 장치를 구비하여 구성될 수 있다. 예컨대, 영구 저장기(1416)는 하드 드라이브, 플래시 메모리, 재기록가능 광학 디스크, 재기록가능 자기 테이프, 또는 상기의 몇몇 조합을 구비하여 구성될 수 있다. 영구 저장기(1416)에 의해 이용된 매체는 제거가능 또는 제거가능하지 않을 수 있다.

통신 유닛(1408)은 데이터 처리 시스템(1400)이 다른 데이터 처리 시스템 및/또는 장치와 통신을 할 수 있도록 한다. 통신 유닛(1408)은 물리적 및/또는 무선 통신 링크를 이용해서 통신을 제공할 수 있다.

입력/출력 유닛(1410)은 입력이 데이터 처리 시스템(1400)에 연결된 다른 장치로부터 수신될 수 있고 출력이 데이터 처리 시스템(1400)에 연결된 다른 장치로 보내질 수 있도록 한다. 예컨대, 입력/출력 유닛(1410)은 사용자 입력이 키보드, 마우스, 및/또는 몇몇 다른 형태의 장치를 통해 수신될 수 있도록 한다. 다른 예로서, 입력/출력 유닛(1410)은 출력이 데이터 처리 시스템(1400)에 연결된 프린터로 보내질 수 있도록 한다.

디스플레이(1412)는 사용자에게 정보를 디스플레이하도록 구성된다. 디스플레이(1412)는, 예컨대, 제한 없이, 모니터, 터치 스크린, 레이저 디스플레이, 홀로그래픽 디스플레이, 가상 디스플레이 장치, 및/또는 몇몇 다른 형태의 디스플레이 장치를 구비하여 구성될 수 있다.

이러한 실례로 되는 예에 있어서, 여러 실례로 되는 실시예의 프로세스는 컴퓨터-구현 명령(computer-implemented instructions)을 이용해서 프로세서 유닛(1404)에 의해 수행될 수 있다. 이들 명령은 프로그램 코드, 컴퓨터 이용가능 프로그램 코드, 또는 컴퓨터 판독가능 프로그램 코드로 언급될 수 있고, 프로세서 유닛(1404)의 하나 이상의 프로세서에 의해 판독 및 실행될 수 있다.

이들 예에 있어서, 프로그램 코드(1418)는, 선택적으로 제거가능한, 컴퓨터 판독가능 매체(1420) 상에 기능적 형태로 위치하고, 프로세서 유닛(1404)에 의한 실행을 위해 데이터 처리 시스템(1400) 상으로 로드되거나 데이터 처리 시스템(1400)에 전송될 수 있다. 프로그램 코드(1418) 및 컴퓨터 판독가능 매체(1420)는 함께 컴퓨터 프로그램 제품(1422)을 형성한다. 본 실례로 되는 예에 있어서, 컴퓨터 판독가능 매체(1420)는 컴퓨터 판독가능 저장 매체(1424) 또는 컴퓨터 판독가능 신호 매체(1426)일 수 있다.

컴퓨터 판독가능 저장 매체(1424)는 프로그램 코드(1418)를 전파 또는 전송하는 매체라기 보다는 프로그램 코드(1418)를 저장하는데 이용된 물리적 또는 유형의 저장 장치이다. 컴퓨터 판독가능 저장 매체(1424)는, 예컨대, 제한 없이, 광학 또는 자기 디스크 또는 데이터 처리 시스템(1400)에 연결된 영속적 저장 장치일 수 있다.

대안적으로, 프로그램 코드(1418)는 컴퓨터 판독가능 신호 매체(1426)를 이용해서 데이터 처리 시스템(1400)에 전송될 수 있다. 컴퓨터 판독가능 신호 매체(1426)는, 예컨대 프로그램 코드(1418)를 포함하는 전파된 데이터 신호일 수 있다. 이 데이터 신호는 전자기 신호, 광학 신호, 및/또는 물리적 및/또는 무선 통신 링크를 거쳐 전송될 수 있는 몇몇 다른 형태의 신호일 수 있다.

도 14에서 데이터 처리 시스템(1400)의 실례는 실례로 되는 실시예가 구현될 수 있는 방식에 대해 구조적 제한을 제공하도록 의미하지는 않는다. 여러 실례로 되는 실시예는 데이터 처리 시스템(1400)을 위해 개시된 것에 부가 또는 대신하여 구성요소를 포함하는 데이터 처리 시스템에서 구현될 수 있다. 더욱이, 도 14에 도시된 구성요소는 도시된 실례로 되는 예로부터 변경될 수 있다.

여러 도시된 실시예에서의 플로우차트 및 블록도는 실례로 되는 실시예에서의 장치 및 방법의 몇몇 가능한 구현의 구조, 기능성, 및 동작을 설명한다. 이와 관련하여, 플로우차트 또는 블록도의 각 블록은 모듈, 세그먼트, 기능, 및/또는 동작 또는 단계의 부분을 나타낼 수 있다.

예컨대, 블록 중 하나 이상은 프로그램 코드로서, 하드웨어로, 또는 프로그램 코드 및 하드웨어의 조합으로 구현될 수 있다. 하드웨어로 구현될 때, 하드웨어는, 예컨대 플로우차트 또는 블록도에서의 하나 이상의 동작을 수행하도록 제조 또는 구성되는 집적 회로의 형태를 취할 수 있다. 프로그램 및 하드웨어의 조합으로 구현될 때, 구현은 펌웨어(firmware)의 형태를 취할 수 있다.

실례로 되는 실시예의 몇몇 대안적인 구현에 있어서, 블록에서 주지된 기능 또는 기능들은 도면에서 주지된 순서를 벗어나 발생될 수 있다. 예컨대, 몇몇 경우에 있어서, 연속적으로 도시된 2개의 블록은 실질적으로 동시에 실행될 수 있고, 또는 블록은 때때로, 포함된 기능성에 따라, 반대의 순서로 수행될 수도 있다. 또한, 다른 블록이 플로우차트 또는 블록도에서 개시된 블록에 부가하여 부가될 수 있다.

여러 실례로 되는 실시예의 설명이 도시 및 설명의 목적을 위해 제공되고 있고, 개시된 형태로 실시예를 포괄시키거나 한정하도록 의미하는 것은 아니다. 많은 변경 및 변형이 당업자에게는 명백할 것이다. 더욱이, 여러 실례로 되는 실시예는 다른 실례로 되는 실시예와 비교하여 여러 특징을 제공할 수 있다. 선택된 실시예 또는 실시예들이 실시예의 원리, 실제적 적용을 가장 잘 설명하고, 당업자가 아니라도 다양한 변형에 따른 다양한 실시예에 대한 발명이 고려된 특정 이용에 대해 적절한 것으로서 이해할 수 있도록 하기 위해 선택되고 설명된다.

Claims (19)

1. 데이터 서버로서,
   데이터 공급자로부터 복수의 비동기 데이터 스트림을 수신하도록 구성된 수신기;
   수신기에 의해 수신되고 수신기에 의해 저장 시스템으로 전송된 복수의 비동기 데이터 스트림을 저장하도록 구성된 저장 시스템; 및
   비일시적 컴퓨터 판독가능 저장 장치에 있는 프로그램 코드로서, 상기 프로그램 코드는 서버 요청이 클라이언트로부터 데이터 서버에서 수신되는 것에 응답하여 데이터 서버 내에서 활성화되는 정책 요청 취급자를 포함하는, 프로그램 코드;를 포함하고, 상기 정책 요청 취급자는:
   서버 요청이 라이브 데이터에 대한 제1 요청인 것에 응답하여, 복수의 비동기 데이터 스트림이 저장 시스템에 저장되기 전에 수신기에 의해 수신된 복수의 비동기 데이터 스트림을 포함하는 입력 포인트를 수신하고;
   서버 요청이 이력 데이터에 대한 제2 요청인 것에 응답하여, 저장 시스템으로부터 입력 포인트를 검색하고;
   시간-순서화된 데이터 포인트의 어레이를 형성하기 위해 입력 포인트의 데이터 포인트를 함께 병합하고 - 데이터 포인트는 데이터 값 및 시간 값을 포함하고, 데이터 값은 센서로부터의 파라메트릭 데이터를 포함하고, 데이터 포인트는 복수의 비동기 데이터 스트림의 각각의 대응하는 데이터 포인트에 대한 대응하는 시간 값에 기초하여 복수의 비동기 데이터 스트림 모두로부터 시간-순서화된 데이터 포인트의 어레이에서 단조적으로 증가하는 시간 순서로 병합됨 -;
   시간-순서화된 데이터 포인트의 어레이를 형성하는 것에 응답하여, 서버 요청이 모든 샘플 요청인지 또는 트리거를 갖는 프레임된 요청인지에 대한 결과를 결정하고;
   서버 요청에서 식별된 서버 정책에 따라 정책-기반 데이터를 생성하고 - 정책-기반 데이터는 시간-순서화된 데이터 포인트의 어레이 및 상기 결과로부터 생성됨 -; 및
   클라이언트에 의해 요청된 방식으로 정책-기반 데이터를 클라이언트에게 전송하도록 - 정책-기반 데이터는 데이터 포인트가 클라이언트에게 전달되는 방식을 정의함 -; 구성되는, 데이터 서버.
2. 제1항에 있어서, 정책 요청 취급자는:
   복수의 비동기 데이터 스트림의 데이터 포인트를 함께 병합하여 시간-순서화된 데이터 포인트의 어레이를 형성하는 데이터 병합기를 포함하는, 데이터 서버.
3. 제2항에 있어서, 데이터 병합기는 서버 요청이 제1 요청일 때 데이터 서버의 수신기로부터 복수의 비동기 데이터 스트림을 수신하고, 수신기가 데이터 공급자들의 세트 중 적어도 하나로부터 제1 데이터를 수신하는, 데이터 서버.
4. 제3항에 있어서, 데이터 병합기는 서버 요청이 제2 요청일 때 데이터 서버의 저장 시스템으로부터 복수의 비동기 데이터 스트림을 수신하고, 저장 시스템이 수신기에 의해 수신된 데이터를 저장하는, 데이터 서버.
5. 제2항에 있어서, 정책 요청 취급자는:
   정책-기반 데이터가 서버 정책을 기초로 형성되는 시간-순서화된 데이터 포인트의 어레이를 사용해서 정책-기반 데이터를 형성하는 정책-기반 데이터 관리자를 더 포함하는, 데이터 서버.
6. 제5항에 있어서, 정책-기반 데이터 관리자는 시간-순서화된 데이터 포인트의 어레이의 각 데이터 포인트를 사용하여 서버 요청이 모든 샘플 요청임을 나타내는 서버 정책에 대한 정책-기반 데이터를 생성하도록 구성되는, 데이터 서버.
7. 제5항에 있어서, 정책-기반 데이터 관리자는 정책-기반 데이터 프레임의 세트의 각 정책-기반 데이터 프레임이 시간-순서화된 데이터 포인트의 어레이를 사용해서 발생되는 이벤트에 응답하여 형성되는 정책-기반 데이터 프레임의 세트로서 정책-기반 데이터를 형성하도록 구성되는, 데이터 서버.
8. 제7항에 있어서, 이벤트는 시간 간격의 경과이고, 정책-기반 데이터 프레임 세트의 정책-기반 데이터 프레임 세트 중 하나는 다수의 데이터 값 및 시간 간격의 경과가 발생된 시간의 표시를 포함하는, 데이터 서버.
9. 제8항에 있어서, 다수의 데이터 값은 시간-순서화된 데이터 포인트의 어레이 및 보간을 사용하여 식별되는, 데이터 서버.
10. 제1항에 있어서, 정책 요청 취급자는: 정책-기반 데이터를 사용하여 정책 요청 취급자로부터 클라이언트로 전송하기 위한 출력 데이터를 형성하는 출력 패킷화기를 더 포함하는, 데이터 서버.
11. 제1항에 있어서, 시간 값은 데이터 값이 획득된 시간을 나타내는, 데이터 서버.
12. 제1항에 있어서, 정책 요청 취급자는 서버 요청이 형성되었던 정책 요청을 생성한 클라이언트에 정책-기반 데이터를 제공하는, 데이터 서버.
13. 서버 시스템으로서,
    비일시적 컴퓨터 판독가능 저장 장치에 있는 프로그램 코드로서, 상기 프로그램 코드는 클라이언트로부터 정책 요청을 수신하고 정책 요청을 기초로 다수의 서버 요청을 생성하도록 구성된 서버 제어기를 포함하는, 프로그램 코드; 및
    데이터 서버의 세트;를 포함하고, 상기 데이터 서버의 세트 내의 데이터 서버는:
    제1 수신기;
    다수의 서버 요청 내의 서버 요청을 수신한 것에 응답하여 다수의 정책 요청 취급자를 활성화시키는 서버 관리자; 및
    다수의 정책 요청 취급자 내의 정책 요청 취급자;를 포함하고,
    상기 제1 수신기는:
    데이터 공급자로부터 복수의 비동기 데이터 스트림을 수신하고; 및
    복수의 비동기 데이터 스트림을 저장 시스템에 전송하도록 - 저장 시스템은 복수의 비동기 데이터 스트림을 저장하도록 구성됨 -; 구성되고,
    상기 정책 요청 취급자는:
    서버 요청이 라이브 데이터에 대한 제1 요청인 것에 응답하여, 복수의 비동기 데이터 스트림이 저장 시스템에 저장되기 전에 제1 수신기에 의해 수신된 복수의 비동기 데이터 스트림을 포함하는 입력 포인트를 수신하고;
    서버 요청이 이력 데이터에 대한 제2 요청인 것에 응답하여, 저장 시스템으로부터 입력 포인트를 검색하고;
    시간-순서화된 데이터 포인트의 어레이를 형성하기 위해 입력 포인트의 데이터 포인트를 함께 병합하고 - 데이터 포인트는 데이터 값 및 시간 값을 포함하고, 데이터 값은 센서로부터의 파라메트릭 데이터를 포함하고, 데이터 포인트는 복수의 비동기 데이터 스트림의 각각의 대응하는 데이터 포인트에 대한 대응하는 시간 값에 기초하여 복수의 비동기 데이터 스트림 모두로부터 시간-순서화된 데이터 포인트의 어레이에서 단조적으로 증가하는 시간 순서로 병합됨 -;
    시간-순서화된 데이터 포인트의 어레이를 형성하는 것에 응답하여, 서버 요청이 모든 샘플 요청인지 또는 트리거를 갖는 프레임된 요청인지에 대한 결과를 결정하고;
    서버 요청에서 식별된 서버 정책에 따라 정책-기반 데이터를 생성하고 - 정책-기반 데이터는 시간-순서화된 데이터 포인트의 어레이 및 상기 결과로부터 생성됨 -; 및
    클라이언트에 의해 요청된 방식으로 정책-기반 데이터를 클라이언트에게 전송하도록 - 정책-기반 데이터는 데이터 포인트가 클라이언트에게 전달되는 방식을 정의함 -; 구성되는, 서버 시스템.
14. 방법으로서:
    데이터 서버에서 수신기에 의해 데이터 공급자로부터 복수의 비동기 데이터 스트림을 수신하는 단계;
    수신기에 의해 수신된 복수의 비동기 데이터 스트림을 데이터 서버의 저장 시스템으로 전송하는 단계;
    수신기로부터 전송된 복수의 비동기 데이터 스트림을 저장 시스템의 저장 시스템에 저장하는 단계;
    클라이언트에 의해 생성된 정책 요청을 사용하여 서버 요청을 생성하는 단계;
    서버 요청을 수신한 것에 응답하여 데이터 서버 내의 정책 요청 취급자를 활성화시키는 단계;
    서버 요청이 라이브 데이터에 대한 제1 요청인 것에 응답하여, 정책 요청 취급자에서 복수의 비동기 데이터 스트림이 저장 시스템에 저장되기 전에 수신기에 의해 수신된 복수의 비동기 데이터 스트림을 포함하는 입력 포인트를 수신하는 단계;
    서버 요청이 이력 데이터에 대한 제2 요청인 것에 응답하여, 정책 요청 취급자에 의해 저장 시스템으로부터 입력 포인트를 검색하는 단계;
    정책 요청 취급자에 의해, 시간-순서화된 데이터 포인트의 어레이를 형성하기 위해 입력 포인트의 데이터 포인트를 함께 병합하는 단계로서, 데이터 포인트는 데이터 값 및 시간 값을 포함하고, 데이터 값은 센서로부터의 파라메트릭 데이터를 포함하는, 단계;
    시간-순서화된 데이터 포인트의 어레이를 형성하는 것에 응답하여, 서버 요청이 모든 샘플 요청인지 또는 트리거를 갖는 프레임된 요청인지에 대한 결과를 결정하는 단계;
    정책 요청 취급자에 의해, 시간-순서화된 데이터 포인트 및 결과를 사용하여 서버 요청에서 식별된 서버 정책에 따라 정책-기반 데이터를 형성하는 단계; 및
    정책-기반 데이터를 출력 데이터로서 클라이언트에 전송하는 단계;를 포함하는, 방법.
15. 제14항에 있어서, 정책 요청 취급자에서 입력 포인트를 수신하는 단계는: 서버 요청이 제1 요청일 때 정책 요청 취급자에서 데이터 서버의 수신기로부터 복수의 비동기 데이터 스트림을 수신하는 단계를 포함하고, 수신기가 데이터 공급자의 세트 중 적어도 하나로부터 제1 데이터를 수신하는, 방법.
16. 제15항에 있어서, 정책 요청 취급자에서 입력 포인트를 수신하는 단계는: 서버 요청이 제2 요청일 때 정책 요청 취급자에서 데이터 서버의 저장 시스템으로부터 복수의 비동기 데이터 스트림을 수신하는 단계를 더 포함하고, 저장 시스템이 수신기에 의해 수신된 데이터를 저장하는, 방법.
17. 제14항에 있어서, 정책 요청 취급자에 의해 정책-기반 데이터를 형성하는 단계는: 정책 요청 취급자에 의해, 정책-기반 데이터 프레임의 세트의 각 정책-기반 데이터 프레임이 시간-순서화된 데이터 포인트를 사용해서 발생되는 이벤트에 응답하여 형성되는 정책-기반 데이터 프레임의 세트로서 정책-기반 데이터를 형성하는 단계를 포함하는, 방법.
18. 제2항에 있어서,
    복수의 비동기 데이터 스트림의 데이터 포인트는 제1 시간 값을 갖는 제1 데이터 포인트 및 제2 시간 값을 갖는 제2 데이터 포인트를 포함하고;
    제1 데이터 포인트 및 제1 시간 값은 제2 데이터 포인트 및 제2 시간 값보다 이른 시간에 생성되고;
    정책 요청 취급자는 제1 데이터 포인트 및 제1 시간 값 이전에 제2 데이터 포인트 및 제2 시간 값을 수신하고; 및
    데이터 병합기는 제1 데이터 포인트가 제2 데이터 포인트 앞에 배열되도록 시간-순서화된 데이터 포인트의 어레이를 형성하는, 데이터 서버.
19. 제13항에 있어서,
    서버 요청이 모든 샘플 요청임을 서버 정책이 나타낼 때 시간-순서화된 데이터 포인트의 어레이의 각 데이터 포인트는 정책 기반 데이터를 생성하는데 사용되며;
    정책-기반 데이터는 정책-기반 데이터 프레임의 세트를 생성하는데 사용되고, 정책-기반 데이터 프레임 세트의 각 정책-기반 데이터 프레임은 시간-순서화된 데이터 포인트의 어레이를 사용해서 발생되는 이벤트에 응답하여 생성되고;
    이벤트는 시간 간격의 경과이고, 정책-기반 데이터 프레임 세트의 정책-기반 데이터 프레임 중 하나는 다수의 데이터 값 및 시간 간격의 경과가 발생된 시간을 나타내는 제1 시간 값을 포함하고; 및
    다수의 데이터 값은 시간-순서화된 데이터 포인트의 어레이 및 보간을 사용하여 식별되는, 서버 시스템.

Images