KR20100019473A - 무선 제어 및 센서 네트워크에서의 진단 및 문제 해결 방법들 - Google Patents
무선 제어 및 센서 네트워크에서의 진단 및 문제 해결 방법들 Download PDFInfo
- Publication number
- KR20100019473A KR20100019473A KR1020097025159A KR20097025159A KR20100019473A KR 20100019473 A KR20100019473 A KR 20100019473A KR 1020097025159 A KR1020097025159 A KR 1020097025159A KR 20097025159 A KR20097025159 A KR 20097025159A KR 20100019473 A KR20100019473 A KR 20100019473A
- Authority
- KR
- South Korea
- Prior art keywords
- diagnostic
- internal
- data
- memory
- variables
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B19/00—Programme-control systems
- G05B19/02—Programme-control systems electric
- G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
- G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
- G05B19/0428—Safety, monitoring
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/20—Pc systems
- G05B2219/24—Pc safety
- G05B2219/24055—Trace, store a working, operation history
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/20—Pc systems
- G05B2219/24—Pc safety
- G05B2219/24067—Processor stores variables, events and date in eeprom, for external monitor
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/20—Pc systems
- G05B2219/24—Pc safety
- G05B2219/24084—Remote and local monitoring, local result to remote, remote takes action
Landscapes
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Automation & Control Theory (AREA)
- Debugging And Monitoring (AREA)
- Test And Diagnosis Of Digital Computers (AREA)
- Testing And Monitoring For Control Systems (AREA)
Abstract
빌딩 자동화 시스템 내에서 동작가능한 제1 계층적 장치에 대한 진단을 수행하는 방법이 개시된다. 본 방법은, 상기 제1 계층적 장치를 제어하도록 구성된 애플리케이션 코드를 상기 애플리케이션 코드가 복수의 내부 변수들을 포함하도록 컴파일링하는 단계, 상기 복수의 내부 변수들을 모니터링하도록 구성된 진단 모듈을 제공하는 단계, 상기 모니터링된 복수의 내부 변수들에 관련된 내부 변수 진단 데이터를 수집하는 단계, 상기 수집된 내부 변수 진단 데이터를 제2 계층적 장치에 업로드하는 단계, 상기 제2 제1 계층적 장치에서, 상기 내부 변수 진단 데이터에 대한 계층화 진단 분석을 수행하는 단계, 및 상기 분석된 내부 변수 진단 데이터에 기초하여 제1 계층적 장치 문제점을 식별하는 단계를 포함한다.
무선 제어, 센서 네트워크, 계층적 장치, 빌딩 자동화 시스템, 애플리케이션 코드
Description
[관련 출원들에 대한 교차 참조]
본 특허는 35 U.S.C 119(e) 하에서 2007년 5월 3일에 출원된 미국 가 특허 출원 제 60/915,710(2007P09009US)호 및 2007년 5월 10일에 출원된 미국 가 특허 출원 제 61/035,109(2008P004472US)호의 우선권을 주장하며, 이들의 내용은 모든 면에서 본원에 참조로서 통합된다.
본 특허는 2006년 10월 31일에 출원된 동시계류중(co-pending) 미국 특허 출원 제 11/590,157(2006P18573US)호 및 2004년 8월 8일 출원된 동시계류중 미국 특허 출원 제 10/915,034(2004P13093US)호에 관한 것으로, 이들 출원들의 내용들은 모든 면에서 본원에 참조로서 통합된다.
함께 네트워킹된 임베드된 시스템들, 및 특히 무선으로 함께 네트워킹된 임베드된 시스템들을 포함하는 일반적인 임베드된 시스템들은 문제점들이 발생했을 때 문제 해결이 복잡하고 어려울 수 있다. 검출되고 및/또는 보일 때 문제점들은 일반적으로 시스템 운영자 또는 제공자에 의한 신속한 해결을 요구한다.
경험은, 내장된 진단 장치들(built-in diagnostics) 없이는, 무선 제어 및 센서 네트워크(WCSN)에서, 예를 들면, "단순한" 무선 장치에서조차 문제점들의 근본 원인을 결정하는 것이 대부분 어렵다는 것을 보여주는데, 문제점들은: (1) 라디오 하드웨어, (2) 라디오 펌웨어, (3) 애플리케이션 프로세서, (4) 무선 스택 펌웨어, (5) 무선 애플리케이션 펌웨어, 및 (6) 라디오 프로세서 및 애플리케이션 프로세서 사이의 통신 채널과 같은 많은 가능한 위치들 중 하나의 위치에서 발생할 수 있다. 또한, 무선 장치들 및/또는 빌딩 자동화 컴포넌트들이 (천장 공간 내 또는 잠겨진 사무실들 또는 장비 벽장들 내와 같은) 접근할 수 없는 위치들에 배치될 수 있기 때문에, 무선 장치의 무선 통신 채널을 이용하는 것은 문제 해결을 더욱 쉽고, 능률적이고, 실용적으로 만든다.
사용자가 외부의 서비스를 호출할 필요없이 일상의 문제점들을 진단하게 하는, 내장 진단 장치를 갖는 현대의 임베드된 제품들을 제공하는 것이 알려져 있다. 외부의 서비스 직원은 종종 통신과 같은 시스템 레벨 문제점들을 진단하기 위한 추가적 또는 확장된 진단 능력들 또는 도구를 갖는다. 많은 상황에서, 무선 장치의 및/또는 시스템의 동작들의 심층 분석(in-depth analysis)을 제공하기 위해 제3 레벨의 "원격" 인터넷 진단("remote" over-the-internet diagnostics)이 서비스 직원에 이용가능하다.
[개요]
무선 제어 및 센서 네트워크(WCSN)의 문제점들을 무선 진단하고 문제 해결하는 방법들 및 장치들이 본원에 개시된다. 개시된 진단 기능성은 WCSN 내의 장치들과 연관된 내부 변수들의 분석에 기초하여 WCSN 내의 문제점들 및 오류들의 확인 및 해결을 제공한다. 개시된 방법 및 장치는 사용자의 시간 및 돈을 절약하고, 빠른 문제 해결을 제공하고, 고객 경험을 향상시킬 수 있다.
일 실시예에서, 빌딩 자동화 시스템 내에서 동작가능한 제1 계층적 장치(hierarchical device)에 대한 진단을 수행하는 방법이 개시된다. 본 방법은, 상기 제1 계층적 장치를 제어하도록 구성되는 애플리케이션 코드를 상기 애플리케이션 코드가 복수의 내부 변수들을 포함하도록 컴파일링하는(compiling) 단계, 상기 복수의 내부 변수들을 모니터링하도록 구성되는 진단 모듈을 제공하는 단계, 상기 모니터링된 복수의 내부 변수들에 관련된 내부 변수 진단 데이터를 수집하는 단계, 상기 수집된 내부 변수 진단 데이터를 제2 계층적 장치에 업로드하는 단계, 상기 제2 제1 계층적 장치에서, 상기 내부 변수 진단 데이터에 대한 계층화된(layered) 진단 분석을 수행하는 단계, 및 상기 분석된 내부 변수 진단 데이터에 기초하여 제1 계층적 장치 문제점을 식별하는 단계를 포함한다. 또 다른 실시예에서, 빌딩 자동화 시스템 내에서 동작가능한 계층적 장치가 개시된다. 상기 장치는 무선 통신 컴포넌트, 상기 무선 통신 컴포넌트와 통신하는 프로세서, 및 상기 프로세서와 통신하는 메모리를 포함한다. 상기 메모리는, 애플리케이션 코드가, 상기 애플리케이션 코드와 연관된 복수의 내부 변수들을 모니터링하고, 상기 모니터링된 복수의 내부 변수들에 관련된 내부 변수 진단 데이터를 수집하고, 상기 수집된 내부 변수 진단 데이터를 통신하도록 구성된 진단 모듈을 포함하도록, 상기 프로세서에 의해 실행가능한 상기 애플리케이션 코드를 저장하도록 구성된다.
다른 실시예들이 개시되며, 각각의 실시예들은 단독으로 또는 조합으로 함께 이용될 수 있다. 개시된 실시예들의 추가적인 특징들 및 장점들은 이하의 상세한 설명 및 도면들에서 설명되고 그로부터 명백하게 될 것이다.
도 1은 빌딩 자동화 시스템 내에 배치될 수 있는 유선 또는 무선 장치 내에서 동작가능한 애플리케이션 코드를 나타내는 블럭도.
도 2는 도 1에 도시된 애플리케이션 코드와 함께 동작가능할 수 있는 예시의 진단 모듈을 나타내는 도면.
도 3은 진단 모듈 및 애플리케이션 코드의 예시의 통합을 나타내는 도면.
도 4는 예시의 진단 데이터 레벨들을 나타내는 도면.
도 5는 예시의 네트워크 구성을 나타내는 도면.
도 6은 진단 모듈-중간 노드의 예를 나타내는 도면.
도 7은 프로그래머 진단 도구 코드 모듈의 예를 나타내는 도면.
도 8은 본원에 개시된 애플리케이션 코드 및 진단 도구를 구현할 수 있는 예시의 자동화 컴포넌트 또는 장치를 나타내는 도면.
본 명세는 장치 프로그래머에 의해 제공되고 및 또는 구현될 수 있는 제4 레벨의 진단에 초점을 둔다. 제4 레벨 또는 내부 변수 진단은, 애플리케이션 코드 레벨에서, 오류 또는 잡 고장(job failure)의 근본 원인을 정확하게 결정하기 위해 임베드된 장치 또는 자동화 컴포넌트의 작업들 및 임베드된 장치 또는 자동화 컴포넌트의 소프트웨어/펌웨어 내부 변수들을 관측하는 수단을 제공한다.
애플리케이션 코드 레벨의 진단들이 거의 포함되지 않고 및/또는 그들이 보고하는 것에서 매우 제한되는 많은 이유들이 존재한다. 특히, 일반적인 임베드된 시스템에는 수백의 내부 변수들이 있어서, 모든 내부 변수들을 추적하고 모니터링하기 위해 장치 및/또는 시스템이 이용할 수 있는 충분한 네트워크 대역폭 또는 내부 메모리 자원들 중 어느 쪽도 존재하지 않는다. 내부 변수들은 일반적으로 진단 메시지를 송신하기 위해 요구되는 통신 시간보다 더 빠르고 및/또는 더 자주 변한다. 내부 변수 변화의 속도에 관한 이러한 통신 지연은 모든 변화가 보고되지 않거나 또는 기록되지 않는 결과를 초래할 수 있다. 임베드된 제어기들 내의 귀중한 상품인 메모리는 진단을 수행하고, 진단을 수행함에 있어서 다른 도움을 저장하는 데에 이용될 수 있으나; 그러한 이용은 소기의 애플리케이션 메모리 및 제품의 전체 성능에 영향을 미치거나/감소시킬 수 있다. 많은 임베드된 장치들 또는 시스템들에서, 진단의 설계 및 구현은 실제 애플리케이션 코드의 개발보다 더 큰 개발 노력일 수 있다.
문제점을 진단하는 공통 방법은 : (ⅰ) 넓은 범위의 잠재적 문제점들 또는 오류들 및 상기 오류들 또는 문제점들 각각에 연관된 변수들을 평가하고; (ⅱ) 만약 있다면, 상기 연관된 변수들 중 어느 것이 그들의 설계 한계들의 밖에서 동작하는지를 결정하기 위해 상기 연관된 변수들 각각을 검토하고; (ⅲ) 상기 한도-밖(out-of-limit) 변수들을 사이트-특정(site-specific) 문제점과 상관시키고; (ⅳ) 그것의 한도의 밖에서 동작하는 상기 변수들과 연관된 변동의 원인(source of variance)을 결정하고; (ⅴ) 상기 변동 및/또는 사이트-특정 문제점을 해결하거나 또는 다루기 위한 액션들 또는 전략을 결정하는 것이다.
종종 고장이 발생할 때, 아마 내부 "연쇄 반응" 또는 이벤트들의 연속으로서, 두 개 이상의 변수들이 한도-밖에 있을 것이다. 이들 경우들에서, 한도-밖 변수들의 하나 이상의 부분 집합에 초점을 맞추고, 부분 집합의 거동을 이해하고, 그 후 또 다른 부분 집합을 분석하는 것이 필요할 수 있다. 이 진단 알고리즘은 변수들의 우선 순위 분석(prioritized analysis)으로 칭해질 수 있다.
변수들의 우선 순위 분석은 가시적인 변수들에 효과적이나, 소프트웨어 내부 변수들은 외적으로 보이지 않을 수 있고 같은 방식으로 추적되지 않을 수 있다. 공개 문서로 소프트웨어 내부 변수들을 노출시키고 문서화하는 것은 영업 비밀들의 공표를 초래할 수 있어서, 아마 사업 및/또는 개발 이점과의 경쟁을 제공할 수 있다.
본 명세는 내부 변수들을 추적하고 및/또는 모니터링하는 데에 이용하기 위한 제4 레벨 진단 해법을 정의한다. 제4 레벨 진단 해법은, (1) 진단 모듈이 애플리케이션 코드 내에 통합될 때 프로그래머에 의해 우선 순위가 정해진 많은 변수들을 추적하고, (2) 각 변수의 우선 순위들에 대해서 메모리 자원들의 균형을 잡고, (3) 수집된 데이터 안에서 내부 회복 동작들을 허용하고, (4) 설계 정보를 누설하지 않고 수집된 데이터가 보고되게 하는 익명 보고 방법들을 이용하고, (5) 특정한 변수 집합들에 초점을 맞추는 것을 허용하도록 수집 방법들의 변경을 허용하는 사용자 인터페이스에 대한 계층적 데이터 수집 방법 또는 해법을 제공한다. 본 명세는 이하의 세 개의 주요 섹션들로 분할될 것이다: (I) 장치에서의 진단 데이터의 수집; (Ⅱ) 네트워크에 걸친 통신 및 데이터 전송; 및 (Ⅲ) 소스 장치에서 진단 데이터를 분석하고 및/또는 데이터 수집을 변경하기 위한 프로그래머 진단 도구.
I. 진단 데이터의 수집
도 1은 본원에서 제공되는 명세에 따라 구현될 수 있는 몇몇 코드 모듈들을 포함하는 소프트웨어 블록도의 실시예를 나타낸다.
블록들(101a-101f)은, 예를 들면, 운영 체제(102)와 다양한 하드웨어 입력/출력(I/O) 기능들을 인터페이스하고 및/또는 통신하기 위해 이용될 수 있는 드라이버들을 나타낸다. 이 실시예에서, 운영 체제(102)는 태스크 스케쥴링(task scheduling), 태스크 실행, 태스크-간(inter-task) 통신, 코드 모듈들 I/O 요청들을 연관된 I/O 드라이버와 인터페이스하는 것, 및 다른 운영 체제 기능들에 대해 책임이 있을 수 있다.
블록들(103a-103f)은 장치들 및/또는 자동화 컴포넌트들 내에서 태스크들을 수행하도록 구성되거나 또는 프로그램된 컴퓨터 판독가능 코드의 소프트웨어 모듈들 또는 블록들을 나타낸다. 예를 들면, 블록(103a)은 하위 레벨 시스템 센서들 및 또는 출력 액츄에이션(actuation) 장치들과 통신하기 위한 프로토콜 스택일 수 있다. 블록(103b)은 계층적 시스템(hierarchal system) 내의 상위 레벨 제어기들과 통신하기 위한 프로토콜 스택일 수 있다. 지그비 유사(ZigBee analogy)에서는, RFD(reduced function device)가 FFD(full function device)와 통신할 수 있거나, 또는 FFD가 또 다른 FFD 또는 PAN 코디네이터(Coordinator)와 통신할 수 있다. 블록(103c)은 내부 데이터 및 변수들을 위한 데이터 관리자를 구현하는 코드 모듈일 수 있다. 블록(103d)은 고객 요건들을 기술하는 소프트웨어, 코드 및/또는 컴퓨터 구현 명령어들과 같은 솔루션 코드일 수 있다. 다른 소프트웨어 모델들에서, 솔루션 코드는 "애플리케이션 코드"로 칭해지고 있다. 솔루션 코드는 본원에서 애플리케이션 코드(100)로 칭해질 전체 소프트웨어 패키지와 블록 또는 모듈(103d)을 구별하기 위해 이용될 수 있다. 블록(103e)은, 사용자가 로컬적으로(locally) 직접 하드웨어 연결을 통해 또는 원격적으로(remotely) 네트워크를 통해 하나 또는 양쪽 모두의 프로토콜 스택들(103a, 103b)을 통해 장치 또는 자동화 컴포넌트에 액세스하게 하는 사용자 인터페이스 모듈일 수 있다. 블록(103f)은, 진단 코드가 장치 또는 자동화 컴포넌트 내에 포함되었고, 활성화되었고 및/또는 제공되었다면 진단 모듈 또는 코드일 수 있다.
각 소프트웨어 블록은, 루프를 따르는 0 내지 다수의 함수들을 갖는 메인 루프로서 일반적으로 구성되는, 코드의 라인들 객체들(lines objects) 및/또는 그룹들로 구성된다. (소스 포인트들로부터의) 함수 호출들은 변수들을, 전달된 변수들을 이용할 수 있는 호출된 함수들 또는 루틴들에 전달할 수 있다. 호출된 함수들 중 하나 이상의 호출된 함수는 옵션으로 호출한 함수에 값을 통신하고 반환할 수 있다. 함수들은 다른 함수들을 호출하여 코드가: (1) 더 용이한 테스팅 및 확인을 허용하는 점점 더 적은 복잡성을 갖는 점점 더 작은 조각들로 쪼개지게 할 수 있고; (2) 요구된 시퀀스에서 "더 단순한" 함수들을 호출함으로써 더 크고 더 복잡한 함수들이 구성될 수 있다.
데이터를 포함하는 변수들은 다른 함수들 또는 루틴들에 전달되거나, 또는 그들로부터 반환될 수 있다. 함수들 및 메인 루프들 내에서 다른 변수들은 함수 또는 메인 루프의 흐름 및 시퀀스를 제어한다. 함수들 및/또는 메인 루프 내의 변수들의 대부분은 내부 데이터를 전달하며 개발 동안에 이용되는 진단 도구들 내에서 외에는 볼 수 없다. 이들 변수들은 내부 변수들로 칭해질 수 있다. 각각의 내부 변수들은 그들의 이용에 의존하는 한도들의 테스트된 범위 또는 집합 내에서 동작한다. 변수가 그 범위 밖의 값들로 동작할 때, 그들의 동작은, 예를 들면, 연구실 내에서 행해진 테스트의 범위 밖에 있었던 잡사이트(jobsite) 특정 문제점들에 기인하여, 테스트되지 않거나 때때로 상궤를 벗어날(erratic) 수 있다. 어떤 변수들이 고장 나는지와 어떻게 그들이 고장 나는지를 상관시키는 것은 종종 잡사이트에서의 문제 해결로 이어진다.
도 1은 어떻게 소프트웨어 코드가 보여지고 및/또는 구현될 수 있는지의 일례이다. 예를 들면, 더 많은 코드 블록들이 있을 수 있거나 또는 더 적은 코드 블록들이 있을 수 있고, 드라이버들이 도시된 바와 같이 분리될 수 있거나 또는 단일 또는 다수의 드라이버 블록들에 통합될 수 있고, 드라이버들의 수가 변할 수 있고, 운영 체제가 개별 소프트웨어 구조 또는 블록일 수 있거나 또는 그렇지 않을 수 있다. 도 1은 구조화된 코드, 그것이 하나의 코드 모듈 내의 또는 상이한 모듈 내의 함수들 사이에 통신하기 위해 함수 호출들을 이용하는 것, 및 그들 함수들에 또는 그들 함수로부터 데이터를 전달하기 위해 변수들을 이용하는 것에 대한 배경 지식을 주도록 의도된다. 또한, 도 1은 내부 변수의 개념을 설명하도록 의도된다.
도 2는 진단 기능성을 설명하고 강조하기 위해 배열된 진단 모듈(103f)의 내부 블록도의 예를 나타낸다.
초기화(INITIALIZE) 함수(201)는 진단 모듈(103f) 및 그의 연관된 메모리들을 초기화하기 위해 애플리케이션 코드(100)로부터 호출될 수 있다. 이 호출은 키 초기화 변수들(key initialization variables)을 진단 모듈(103f)에 전달할 수 있다/전달할 것이다. 초기화 함수(210)의 실행 후에, 제어는 애플리케이션 코드(100) 호출 포인트로 귀환될 수 있다.
틱(TICK) 함수(202)는 알려진 시간의 경과 후에 애플리케이션 코드(100)에 의해 호출될 수 있다. 시간 간격은 하드웨어 타이머, 하드웨어 시간 신호, 또는 대략 일정한 시간 간격의 임의의 다른 소스에 의해 제어될 수 있다. 틱 함수(202)는 진단 "틱" 시간 또는 기간이 경과될 때까지 시간 간격들을 카운트할 수 있다. 평가의 기준(point of reference)으로서, 진단 "틱" 시간은, 하나의 예에서, 오(5) 분 간격일 수 있다. 각 진단 "틱" 시간의 끝에서, 틱 함수(202)는 특정 시간-관련 함수들을 실행할 수 있다.
메모리 관리(MEMORY MANAGEMENT) 함수(203)는 진단 모듈(103f)에 부여된(granted) 진단 메모리의 세그먼트들을 할당하고 해제(de-allocate)할 수 있다. 메모리 관리 함수(203)는 현재 이용되는 메모리의 양 및 이용가능한 메모리의 양을 계속 추적(keep track of)할 수 있다. 다른 진단 모듈(103f) 함수들은 그들이 메모리의 블록을 요구하거나, 또는 메모리의 블록을 끝낼 때마다 메모리 관리 함수(203)를 호출할 수 있다.
체크(CHECK) 함수(204)는 변수가 체크될 애플리케이션 코드(110)의 각 포인트에 배치될 수 있다. 애플리케이션 코드(100) 내의 이들 포인트들 또는 위치들은 체크포인트들로 칭해질 수 있다. 각 체크포인트에는 애플리케이션 코드 내의 체크포인트 위치를 정확히 나타내는 유일한 체크포인트 번호가 할당될 수 있다. 체크포인트 번호와 함께, 체크 함수(204)에는 또한 체크될 변수의 값이 전달될 수 있다. 추가적인 변수들이 호출에서 전달될 수 있지만, 어떤 방법으로도 체크되지 않는다. 이들 여분의 변수들은 대응하는 체크포인트에서 유용한 정보로 간주된다. 체크포인트 변수의 값은 애플리케이션 코드(100)의 그 특정한 체크포인트에서 그 변수에 대한 상한 및 하한에 대해 평가된다. 체크포인트 변수가 한도 내에 있다면, 함수는 제어를 애플리케이션 코드의 호출 포인트로 귀환시킨다. 변수가 한도-밖, 상한 또는 하한 밖에 있다면, 추적(TRACK) 함수(205)가 호출될 수 있다.
추적 함수(205)는, 하나의 실시예에서, 체크포인트 번호, 변수 값, 및 변수가 상한 밖에 있는지 하한 밖에 있는지를 수신한다. 추적 함수(205)는 체크포인트에 대한 모든 현존하는 진단 데이터를 업데이트한다. 진단 데이터의 상세는 도 5와 함께 더욱 상세히 설명된다. 추적 함수(205)가 태스크들을 끝마칠 때, 제어는 액션(ACTION) 함수(206)에 전달될 수 있다.
액션 함수(206)는 체크포인트 번호에 대해 지정된 "언제 액션들을 취할지를(take actions when)" 살펴볼 수 있고 (1) 이 변수에 대해 행해진 추적의 양을 확장하거나 또는 축소하는 것을 요청하고; (2) 진단 데이터가 시스템 아키텍처 내의 상위 레벨 제어기에 업로드되거나 제공되어야 하는 것을 표시(flag)하고 나타내고; 및/또는 (3) 이런 변수들의 한도-밖 조건을 다루거나 또는 교정하기 위한 교정 액션을 취할 수 있다. "액션들을 취하는(take actions)" 함수들에 대한 더욱 상세한 설명은 도 3과 함께 설명된다. 액션이 취해져야 하지 않는 경우 또는 액션으로부터의 귀환 후에, 제어는 애플리케이션 코드(100)의 호출 포인트로 귀환한다. 애플리케이션 코드(100)로 귀환하는 것의 예외는 프로그래머가 하드 리셋, 소프트 리셋, 또는 다른 유사한 "귀환 없음(no return)" 액션들을 선택하였을 때 발생할 수 있다.
업로드(UPLOAD) 함수(207)는, 애플리케이션 코드(100)가 상위 레벨 제어기에 메시지를 막 보내려고 할 때, 애플리케이션 코드(100)에 의해 호출될 수 있다. 업로드 함수(207)는 업로드할 임의의 펜딩(pending) 데이터가 있는지를 결정하고, 만약 있다면, 보내질 애플리케이션 데이터에 보내질 메시지의 최대 길이에 이르기까지 진단 데이터를 첨부한다. 무선 노드들 또는 네트워크들에서, 이러한 방법은 진단 데이터가 상위 제어기에 보내지는 정상 데이터와 함께 편승(hitchhike)하게 하고, 더 긴 메시지가 네트워크에서 또 다른 메시지 간격 동안 검색하는 것보다 더 적은 전력을 취하기 때문에 배터리 수명을 절약한다. 상위 레벨 제어기로부터의 응답 메시지는 진단 데이터의 데이터 전송을 받았음을 확인한다. 제어는 애플리케이션 코드(100)의 호출 포인트로 귀환한다. 일부 메모리는 영구적으로 또는 데이터가 마지막 목적지까지 보내질 때까지 진단 데이터를 저장하기 위해 상위 레벨 제어기에서 요구될 것이다.
수정(MODIFY) 함수(208)는 프로그래머 진단 도구(506)(도 5 참조)로부터 메시지가 수신될 때 하나 이상의 진단 체크포인트 변수의 한도들, 액션들, 보고를 수정하도록 또는 어떻게 메모리가 진단 변수들에 할당되는지를 이 진단 모듈(103f)에 말하는, 이 노드들의 차상위 레벨 제어기를 경유하여 호출될 수 있다. 수정 함수(208)는, 프로그래머 진단 도구(506)가 문제점에 대해서 더 알기 위한 의도로 수집되는 데이터 및 그 데이터를 수집하는 방법을 변경하게 한다.
도 3은 어떻게 진단 모듈(103f)이 애플리케이션 코드(100)에 통합되는지를 나타낸다. 블록(301)은 코드의 단일 모듈, 코드의 몇몇 모듈들의 연쇄 뷰(concatenated view), 또는 코드의 모든 모듈들 중 어느 하나를 나타낸다. 코드(301)의 중심 아래의 짧은 선들은, 프로그래머가 체크 함수(204) 호출들을 삽입하기로 결정한 장소들 또는 위치들을 나타내고, 각 위치에서 단일 변수의 한도들을 체크하고 있다. 각 체크 포인트는 연관된 체크포인트 번호와 함께 도시된다(예를 들면, 체크포인트들(#3 및 #11)은 코드(301)의 상단 또는 시작 부분에 리스트됨). 이들 번호들은 애플리케이션당 한 번만 이용되어야만 하고 코드 위치를 한도 테이블(302)의 체크포인트 엔트리에 링크한다. 체크포인트 번호는 모든 다른 체크포인트들에 관한 이 체크포인트의 상대적인 중요성을 정의할 수 있다. 상위 우선 순위 체크포인트들은 하위 우선 순위 체크포인트들보다 이용하기 위한 더 많은 진단 추적 메모리를 할당받을 수 있고 이에 따라 더 나은 데이터 수집 정보를 제공하거나 달성할 수 있다. 도면의 좌측편에는 AXX(여기에서 XX는 식별 번호임)로 명명된 라인들의 또 다른 집합이 있는데, 이는 프로그래머가 교정 액션을 요구하는 체크포인트 변수로부터 회복하기 위해 유용하다고 생각한 함수 호출들을 나타낸다.
한도 테이블(302)은 프로그래머가 각 체크포인트에 제공해야 하는 정보의 윤곽을 나타낸다. 정보는: (1) 변수의 상한; (2) 변수의 하한; (3) 진단 데이터 수집 레벨들을 확장하고 및 또는 축소하기 위한 조건들; (4) 체크포인트 데이터가 상위 레벨 제어기로 업로드 되어야만 하는 때; (5) 교정 액션이 취해져야만 하는 때 및 어떤 액션이 취해질 것인지를 포함할 수 있다. 아이템들(3, 4 및 5)은 프로그래머가 부과한 진단 데이터 한도들에 대하여 진단 데이터의 수집된 값들에 기초한 조건문들(conditional statements)이다. 취해질 액션들은 애플리케이션 코드(100) 내의 함수 호출의 주소를 얻도록 액션 테이블(303)에서 상관될 수 있는 숫자 교차 참조 코드(numeric cross reference code)이다.
도 4에서 나중에 보여지는 바와 같이, 진단 데이터 수집은 진단 필드들에서 일어난다. 다양한 계산들에서 이들 필드들을 결합시키는 것은 통계적인 값들이 결정되게 한다. 진단 필드들 및 계산 결과들에 번호를 매기는 것은 이들 정보들이 액션 함수(206)의 일부로서 이용되게 한다. 예를 들면, (특정한 체크포인트 변수 상한 또는 하한 값들의) 표준 편차가, 예를 들면, 5보다 더 크다면, 액션 #3을 호출한다. 만약 참이라면, 위치 3에서의 액션 테이블(303) 내의 주소가 페치될(fetched) 수 있고 그 교정 액션이 실행될 수 있다.
액션 테이블(303)은 프로그램 제어가 전송될 수 있는 주소들을 리스트할 수 있다. 그들은 이전 단락에서 정의된 숫자 교차 참조에 의해 키된다(keyed). 액션이 요구될 때, 숫자 교차 참조는 액션 테이블(303)에서 조회되고(looked up), 주소들이 찾아지고, 제어는 그 함수로 이동한다. 대부분의 경우에, 제어는 함수가 완료된 후에 여기로 귀환하고, 그 후 여기에서부터 제어는 현재의 체크포인트 함수 호출 후에 애플리케이션 코드(100)의 다음 라인으로 귀환한다.
애플리케이션 참조 데이터(304)는, 이름들, 위치, 용도, 및 각각이 한도-밖에 있게 될 가능한 이유들과 같은 체크포인트들에 대한 전자 데이터를 포함할, 프로그래머에 대한 옵션 아이템이다. 정보는 수집된 데이터 소스 체크포인트들을 더욱 잘 설명하기 위해 프로그래머 진단 도구(506) 내에 로딩 될 수 있다. 정보는 분배에서 매우 제한될 수 있을 것 같다. 대안적으로, 정보는 층들로 구조화될 수 있다. 고객 층은 설계 관련 정보의 유포를 방지하기 위해 체크포인트 번호들을 대신하는 이름들을 가질 수 있는데, 예를 들면, 체크포인트 17은 타이머 3이 된다. 제2 층(필드 서비스)은 코드 모듈에 이름들을 관련시킬 수 있다, 예를 들면, 지그비 스택-타이머 3. 또한 "이 고장 장치 근처의 영역에 추가적인 라우팅 노드를 추가하시오"와 같은 가능한 해결이 제안될 수 있다. 제3 층(고객 서비스)은 "지그비 스택 타이머 3은 장치가 네트워크 액세스를 위해 대기하는 대기 시간을 획득합니다. 만약 너무 길다면, 메쉬 네트워크(mesh network)의 이 섹션에서 불충분한 라우팅이 존재할 수 있으며, 따라서 추가적인 라우팅 노드들이 문제점을 해결할 수 있습니다"와 같은 약간 더 많은 정보를 줄 수 있다. 개발자/프로그래머 레벨인, 제4 레벨은: (1) 코드 모듈 이름; (2) 코드 모듈 라인 번호; (3) 변수 이름; (4) 감시된(watched) 변수 이름들; (5) 각각의 변수들의 의미들; (6) 테스트된 한도들; (7) 수반된 원인들, 등을 포함할 수 있다. 네 개의 레벨들이 본 명세와의 일관성을 위해 여기에 도시되었지만, 층들의 수는 개념을 예시하기 위해 이용되며, 결코 제한하려는 것이 아니다.
애플리케이션 참조 문서(305)는 진단 데이터 수집 동안에 서비스 또는 고객 지원에 의해 이용되는 체크포인트들, 변수들 및 참조 데이터의 심층적인 설명들을 주기 위해 프로그래머에 의해 생성된 옵션 문서일 수 있다. 이 "종이" 또는 "하드 카피" 문서는 애플리케이션 모듈의 내부 거동을 설명하는 진짜 문서 이상의 것이 되도록 의도된다.
도 4는 계층적 데이터 모델(400)의 개념을 소개한다. 모델(400)은 일단 상한 위반들에 대해서 그리고 다시 하한 위반들에 대해서 이용될 수 있다. 임의의 시점에서의 체크포인트 변수에 대한 이용에서의 실제 레벨들의 수는: (1) 이 체크포인트가 높은 또는 낮은 방향으로 한도-밖으로 넘어갔던 횟수; (2) 한도-밖으로 넘어갔던 상위 우선 순위 체크포인트들의 수, 그들이 한도-밖으로 넘어갔던 횟수, 및 그들의 진단 데이터 구조를 확장하기 위해 각각이 정의되는 방법; 및 (3) 진단 데이터 추적을 위해 프로그래머에 의해 할당된 전체 메모리 공간에 의존할 수 있다. 종종 고장 나는 상위 우선 순위 체크포인트는 때때로 고장 나는 하위 우선 순위 체크포인트보다 더욱 많은 추적 레벨들을 가지며, 더 많은 메모리를 이용할 것이고, 더 작은 우선 순위 체크포인트들은 소수의 추적의 레벨들을 구현할 수 있지만, 매우 낮은 우선 순위 체크포인트들은 그들이 가질 수 있는 메모리에서 제한될 수 있다. 한편, 어떠한 상위 우선 순위 체크포인트들도 고장 나지 않는다면, 매우 낮은 우선 순위 체크포인트들은 진단 추적을 위한 많은 메모리를 가질 수 있다.
데이터가 본 명세의 교시에 따라 모델링될 수 있는 방식을 예시하기 위해 예시의 모델 레벨들이 이제 설명될 것이다.
예시의 모델(400)은 하한 쪽의 한도-밖에 있는 변수에 대해 설명될 것이다. 그 구조는 또한, 요구되면, 상한의 한도-밖 추적을 위해 이용가능할 수 있다. 하한 구조는 체크포인트 변수가 하한보다 아래에 있는 경우에만 생성되고 이용된다. 유사하게, 상한 구조는 체크포인트 변수가 상한보다 더 큰 경우에만 생성되고 이용된다.
참조 번호(401)에 대응하는, 레벨 1은 유일한 하나의 통계를 계속 추적한다. "장치의 가장 최근의 전원 투입 이후로 체크포인트 변수가 낮은 쪽의 한도-밖에 있었는가?" 변수가 낮은 쪽의 한도-밖으로 넘어갈 때마다 비트가 설정될 수 있다. 필드는 다른 체크포인트들로부터의 다른 하한 필드들을 갖는 비트 스트링에서 유지될 것으로 기대된다. 액세스는 체크포인트 번호에 의한 것이다. 모든 낮은 한도-밖에 있을 때마다 설정되는 옵션 합성 비트(optional composite bit)가 포함될 수 있다. 사용자는 비트 스트링을 분석하여: (1) 임의의 체크포인트 변수가 한도-밖으로 넘어갔었는지; 및 (2) 어떤 비트(들)가 설정되었는지에 기초하여 어떤 체크포인트 변수(들)인지를 알 수 있다. 비휘발성 진단 메모리가 이용가능하면, 정보는 "마지막 전원 투입 이후에" 대신에 "장치 설치 이후에"로 확장될 수 있다.
참조 번호(402)에 대응하는 레벨 2는 상이하게 제어되는 레벨 1 구조의 정확한 복제(exact duplicate)일 수 있다. 레벨 2 필드 위치에 설정된 각 비트에 대해서 진단 모듈 틱 타이머가 타임 아웃(times out)할 때, "인 넘버 틱(In Number Ticks)" 카운터(counter)는 레벨 4 레코드(레코드가 존재한다면)에서 증가된다. 모든 비트들이 체크된 후에, 필드는 지워지고 틱 함수가 귀환한다. 레벨 4(참조 번호(404) 참조)를 설명할 때, "인 넘버 틱" 필드 대한 것이 더 있을 것이다.
참조 번호(403)에 대응하는 레벨 3은 (a) 시작 시간, (b) 마지막 시간(last time), (c) 마지막 값들, 및 (d) 오버헤드(overhead) 필드들을 포함하는 다중-필드 레코드이다. 틱 타이머는 전원 투입 이후의 시간(the time of day) 및 일수(the number of days)를 추적하고 카운트하도록 구성될 수 있다. 값은 처음으로 한도-밖이 발생할 때 시작 시간 필드에 저장된다. 동일한 값이 마지막 시간 필드에 저장된다. 한도-밖 상태를 경험하는 변수들의 현재 값은 마지막 값 필드에 위치한다. 오버헤드 필드는 구현 상세들(implementation details)을 위해 이용되고 예약되지 않을 수 있다. 변수에 대한 모든 연속적인 한도-밖들에 대해서, 마지막 시간 및 마지막 값 필드들만 작성될 것이다. 이 레코드로부터, 당업자는 고장들이 시작된 때 및 마지막 것이 발생된 때(시간 간격) 및 마지막 고장 값을 볼 수 있다.
참조 번호(404)에 대응하는 레벨 4는 또한 네 개의 필드를 포함한다. 이들 필드들은 발생 횟수, 인 넘버 틱, 스칼라 오프셋(scalar offset), 및 또 다른 오버헤드 필드이다. 한도-밖이 발생하고 레벨 4 레코드가 있을 때마다, 발생 횟수 필드는 증가된다. 레벨 2(틱) 마스크(402)에서 비트가 설정될 때마다, 인 넘버 틱 필드는 틱 타이머가 타임 아웃할 때 증가된다. 스칼라 오프셋은 제1 고장 값의 캡쳐(capture)를 나타내며, 모든 연속적인 한도-밖 기록들을 오프셋하기 위해 이용된다. 이 오프셋은 일반적으로 필드 오버 플로우(데이터의 손실)가 발생하기 전에 레벨 5 및 6에서 더 많은 데이터 판독치들이 컴파일되게 할 것이다. 레벨 4의 두 개의 카운터 필드들은 하나는 모든 고장마다 카운트하고, 다른 하나는 고장난 틱들의 수를 카운트하도록 구성된다. 이들 두 수들이 같다면, 고장들은 틱 간격보다 더 큰 간격에서 발생되고 있다. 발생된 수가 인 넘버 틱 값보다 현저하게 더 크다면, 다수의 고장들이 틱 시간 내에 발생하고 있다. 얼마나 자주 고장들이 발생하는지(1 틱 내의 고장들의 퍼짐(spread out) 대 버스트들(bursts))에 대한 대강의 아이디어는 이들 카운트들로부터 도출될 수 있다. 레벨 3 시작 및 마지막 시간들이 포함될 때, 고장들 사이의 평균 시간의 추정이 근사될 수 있다.
참조 번호(405)에 대응하는 레벨 5는 네 개의 필드들: 넘버 샘플들; 합 X 합 X**2; 및 또 다른 오버헤드 필드를 포함한다. 제1 필드는 레코드가 생성된 이후의 고장 발생들의 수이다. 제2 필드는 스칼라 오프셋 값(레벨 4의 필드 번호 3을 참조)에 의해 오프셋된 후의 변수 값들의 합이다. 제3 필드는 오프셋 변수 값들의 제곱들의 합이다. 이들 세 필드들로부터 고장 값들의 평균 및 표준 편차가 산출될 수 있다.
참조 번호(406)에 대응하는 레벨 6은 합 X**3 및 합 X**4로 명명된 두 개의 필드들을 포함한다. 레벨 5 필드들과 함께, 이들 필드들은 들어오는 고장 데이터의 왜곡도(skewness) 및 데이터 종형(bell) 곡선의 높이를 산출하기 위해 이용될 수 있다. 정의에 의해, 종형 곡선 아래의 면적이 정확하게 1.000이어서, 곡선이 더 높을수록, 판독치들은 더 높고, 곡선이 더 낮을수록, 판독치들은 더 광범위하다라는 것을 명심한다. 이것은 왜곡도가 높이 값을 이용하는 것에 대하여 설명된다는 점에서 표준 편차와 다르다.
참조 번호(407)에 대응하는 레벨 7은 나중에 검토하기 위해 수집된 데이터를 기록(log)하도록 구성될 수 있다. 기록된 필드들은 (이용가능하다면) 일자 및 시간의 더욱 정확한 타임 스탬프(time stamp), (크기조정 안된(unscaled)) 체크포인트 변수의 값들, 및 또 다른 오버헤드 필드일 수 있다. 다수의 이들 레코드들에 의해, 이력(history)이 결정될 수 있다.
참조 번호(408)에 대응하는 레벨 8 레코드는 레벨 7 필드와 동일한 데이터를 기록하지만, 원래의 체크 함수 호출로부터의 여분의 "감시(watch)" 필드들을 추가한다. 이러한 상세의 레벨(level of detail)에서 검토자는 이제 체크포인트가 발생됐을 때의 바로 그 시점에서 변수 값과 미리 결정된 다른 "감시" 변수 값들을 볼 수 있다. 그 시점은 레코드의 제1 필드에 타임 스탬프된다.
모델(400)은 모델의 여덟(8) 개의 다른 레벨들 중 세 개의 다른 레벨에서 장치 메모리를 이용하였다. 레벨들 1 및 2(각각, 401, 402)는 그들의 필드들을 위해 예약된 전용 양(dedicated amount)의 메모리를 가질 수 있다. 레벨들 3, 4, 5, 및 6(각각, 403, 404, 405 및 406)은 누적(accumulation) 레코드들이다. 즉, 그들은 생성(creation)으로부터 필드들 중 하나 이상이 오버플로우할 때까지 데이터를 누적한다. 누적된 데이터는 통계적으로 검토되고 해석될 수 있다. 마지막으로, 레벨들 7 및 8(각각 407 및 408) 레코드들은 매우 상세한 정보의 하나(1)의 부분을 위해 많은 양의 메모리를 소모한다. 이 구조는 장치가 이용되는 메모리의 실제 양을 최소화하면서 이용가능한 정보를 최대화하게 한다.
Ⅱ. 통신 및 데이터 전송
도 5는 지그비 네트워크의 많은 구성들 중 하나를 나타내고 본 명세의 통신 부분을 설명하기 위해 이용된다. 지그비가 여기에 이용되었지만, 이 통신 모델은 현재 존재하거나 또는 미래에 개발될 하나 이상의 레벨의 계층을 갖는 대부분의 임의의 네트워크 또는 표준과 함께 작동할 수 있다. 임의의 현재 알려진 또는 나중에 개발될 네트워크 및 전송 알고리즘들은 장치들 사이에서 통신하기 위해 이용될 수 있다. 통신, 전송 및 라우팅(routing) 알고리즘들이 적절한 장치들에 제공된다. 임의의 패킷 크기 또는 데이터 포맷이 이용될 수 있다.
도 5에 도시된 지그비 네트워크(500)는, 일반적으로 깨어나고(wake-up)(활성화되고), 입력 감지(input sensing) 및 또는 출력 액츄에이션(output actuation)을 수행하고, 옵션으로 요구되면 각각의 FFD(full function device)(502a-502d)에 보고하고, 그 후 잠드는(비활성화되는) RFD(reduced function device) 노드들(501a-501i)을 갖는 단순한 계층적 네트워크를 나타낸다. 통신이 발생되었다면, 그들은 일반적으로 FFD(502a-502d) 중 하나의 FFD에서 라우팅(routed)되고 캐쉬(cashed)되며, 이들 FFD들은 그 후 다른 FFD(502a-502d), PAN 코디네이터(503), 대용량 저장 장치(504), 로컬 프로그래머의 진단 도구(506)와 같은 다른 더 먼 거리의 목적지들에 대해서, 또는 인터넷 인터페이스를 통해 원격 대용량 저장 장치(도시되지 않음) 또는 원격 프로그래머 진단 도구(506)와 같은 더 먼 거리의 목적지들에 대해서 통신을 라우팅할 수 있다.
지그비 표준에 따른 FFD들(502a-502d)은 항상 깨어있고 활성화하고, 라우팅 노드들로서 동작할 수 있다. FFD들(502a-502d)은 서로와, PAN 코디네이터(503), 대용량 저장 장치(504) 또는 프로그래머의 진단 도구(506)와 정보를 라우팅하고 공유할 수 있다. FFD들은 또한 그들의 RFD들로부터의 마지막 보고된 정보를 보유하고, 그들의 RFD들에 보낼 메시지들을 보유한다.
진단 코드 모듈(200)은 도 2, 3 및 4와 함께 설명된 바와 같은 RFD들, FFD들, PAN 코디네이터(503), 또는 대용량 저장 장치(504) 중 임의의 것에 의해 실행되는 애플리케이션 코드(100)에 포함되거나 또는 더해질 수 있다.
대부분의 경우에서, 각각의 상이한 장치 유형(501, 502 등)에 대해 상이한 애플리케이션 코드(100)가 이용될 수 있다. 이것은 각각의 상이한 장치 유형이 상이한 체크포인트 위치들 및 상이한 추적된 변수들을 갖는다는 것을 의미한다. 진단 데이터가 다른 노드들에 전달될 때, 장치 유형 및 네트워크 노드 위치가 노드들의 진단 데이터에 동반할 필요가 있다.
적절히 동작하는 장치는 한도-밖을 넘어가는 체크포인트 변수들을 갖지 않을 것이면, 이에 따라 업로드할 데이터를 갖지 않을 것이다. 소수의 변수들에 대한 제한된 수의 한도-밖 발생들을 갖는 노드도 또한 업로드하기 위한 제한된 진단 데이터를 가질 것이다. 변수들이 상세한 "인스턴스들(instances)" 레벨들(레벨 7 및 8)에 대해서 추적될 때에만 현저한 데이터가 상행 라인(up line)에 전달될 것 같다.
전술한 바와 같이, 다수의 노드들은 RFD 유형이고 높은 비율의 시간 동안 잠든다, 즉 비활성이다. RFD 노드들은 깨어나고, 입력을 감지하고 및 또는 출력을 구동하고, 상행-라인에 보고하는 등을 하고, 그 후 다시 잠든다, 즉 비활성 된다. 프로그래머 진단 도구(506)와 같은 진단 도구들에 진단 데이터가 이용가능하기 위해서는, 진단 데이터(제한된 양조차)는 RFD로부터 연관된 FFD로 업로드 되어야 한다. FFD는 업로드된 데이터를 로컬적으로 저장하거나 또는 그 데이터를 다른 FFD(502a-502d), PAN 코디네이터(503), 대용량 저장 장치(504) 또는 일부 원격 대용량 저장 장치(도 5에 도시되지 않음), 또는 원격 프로그래머의 진단 도구(506)와 같은 더 많은 이용가능한 메모리를 갖는 다른 장치들에 전달한다. 누적된 필드들 또는 "마지막 값" 필드들 중 어느 하나인 업로드된 데이터는 제1 장치에서 상위 레벨인 제2 장치로 전달될 수 있다. 제2 장치는, 이번에는, 제1 장치로부터의 업로드된 데이터를 동일한 필드들의 이전에 업로드된 제1 장치 데이터와 함께 누적할 수 있다. 옵션으로, 제2 층 장치는, 정기적으로 또는 예정된 대로, 누적된 데이터를 저장하고 추가 업로드들을 수신하기 위해 데이터 필드들을 리셋할 수 있다. 프로그래머의 진단 도구(506)는 이 저장된 누적된 데이터를 이용하여 고장 상태, 내부 변수 상태, 고장 타이밍 및/또는 빈도를 이력적으로 분석하거나, 검토할 수 있다.
업로드된 진단 데이터는 프로그래머의 진단 도구(506)에 의한 액세스 및 검토를 위해 네트워크 아키텍처의 다양한 레벨들에서 보관된다.
도 6은 하위 레벨 장치로부터 데이터를 수신하고 그것을 보관하거나 또는 네트워크(500) 내의 다른 장치들에 전달하고 있는 장치들에 의해 요구되는 소프트웨어의 모델(600)을 나타낸다. 이 모델(600)은 체크(CHECK) 함수(204) 및 추적(TRACK) 함수(205)가 제거된 도 2와 함께 개시된 모든 엘리먼트들에 기초한다. 또한, 액션(ACTION) 함수(606), 업로드(UPLOAD) 함수(607) 및 수정(MODIFY) 함수(608)는 하위 레벨 장치로부터의 업로드 메시지들을 수신하고, 데이터가 저장되는지 전달되는지를 결정하고, 그 후 상행-라인 상에 그 데이터를 보낼 능력을 갖는 것을 허용하는 추가적인 기능성을 포함할 수 있다. 또한, 액션 함수(606) 및 수정 함수(608)는 상행 라인으로부터 명령들을 얻고, 그들을 대기열에 넣고(queue), 하위 노드들이 깨어있을 때 그들을 전달할 수 있어야 한다.
Ⅲ. 프로그래머의 진단 도구
프로그래머의 진단 도구(506)는, 장치들의 공급자가 내부 디자인을 얼마나 공개하기를 원하는지에 따라, 고객의 서비스 도구, 서비스 직원의 서비스 도구, 고객의 컴퓨터 상에 로딩되거나 또는 개발 인원들(프로그래머들)에 의해서만 이용되는 소프트웨어 패키지일 수 있다.
진단 모듈(103f)이 애플리케이션 코드(100)에 추가되었을 때 프로그래머가 생성했을 수 있는 옵션 "전자" 및 "종이" 문서들은 이제 업로드 데이터가 설명하는 것이 무엇인지 해독하기 위해 이용될 수 있다.
누가 도구를 이용하는지에 따라 프로그래머의 진단 도구(506)와 함께 로딩되는 정보의 양을 분할하는 것도 가능하다. 이러한 경우에, 서비스 및 고객 서비스가 애플리케이션 참조 데이터(304)와 함께 논의된 정보와 같은 보고된 데이터의 의미를 해독하기 위해 더 많은 정보를 받을 수 있지만, 고객들은 아마 매우 제한된 정보를 얻을 것이다.
도 7은 프로그래머 진단 도구(506)의 모델(700)을 나타낸다. 그것은 또한 애플리케이션 코드(100)에 위치한 진단 코드 모듈(103f)(도 2)과 매우 유사하게 보이나, 도 6에 도시된 모델(600)과 같이, 원래 함수들 중 소수의 함수(체크 함수(204) 및 추적 함수(205))를 빠뜨릴 수 있고 두 개의 새로운 함수들인, 분석(ANALYZE) 함수(704) 및 GUI(graphical user interface) 함수(705)를 포함할 수 있다는 것에 주의한다.
초기화(INITIALIZE), 틱(TICK) 및 메모리 관리(MEMORY MANAGEMENT) 함수들은 도 2 및 6과 함께 논의된 것들과 동일하거나 또는 유사한 기능들을 갖는다.
도 2에 도시된 체크 함수(204)는 모델(700)의 이러한 실시예에서 분석 함수(704)로 교체되었다. 분석 함수(704)는 하나 이상의 노드로부터 업로드 데이터를 수신하고, 그 후 확장된 알고리즘들을 이용하여, 카운터들, 및 노드에서 수집되고 아마 네트워크의 다른 곳에서 (업로드들로부터) 누적된 다른 값들을 소스 노드에서의 문제점을 진단하는 것을 도와주기 위해 이용될 수 있는 의미 있는 정보로 변환하려고 시도한다. 분석된 것은 모듈 GUI 함수(705)를 이용하여 도구의 스크린 상에 그것의 정보를 표시한다.
GUI 함수(705)는 다양한 소스들로부터 데이터를 수신하고 그것을 장치의 스크린 상에 표시한다. 그것은 또한, 사용자가 이들 모듈들이 동작하고 있는 방법 또는 그들이 표시하고 있는 정보 및 그 정보를 표시하는 방법을 수정하기 위한 다양한 유형의 명령어들을 도구 내의 모듈들에 다시 입력하게 한다.
액션 함수(706)는 사용자가 노드에서 취해질 액션을 명령하게 한다. 이들 액션들은 이용가능한 노드 프로토콜 명령들 및 액션 테이블(303)에 포함된 모든 액션들에 제한된다.
업로드 함수(707)는 데이터 업로드 함수의 수신 부분일 수 있다. 업로드 함수는 처리하기 위해 분석 함수(704)에 대한 노드로부터 업로드된 데이터를 수신하고 저장한다.
수정 함수(708)는 사용자가, 데이터가 수집되는 방법, 진단 레벨들이 확장되거나 또는 수축되는 때, 업로드가 수행되는 때, 및 액션들이 취해지는 방법을 바꾸거나 또는 소스 노드의 진단 모듈이, 한도 내에서 그리고 한도 밖에서, 모든 데이터를 수집하게 하여, 체크포인트에서 변수의 전체 동작으로 시각화하게 하는, 한도 테이블(304)에 대한 일시적인 또는 영구적인 변화를 행하게 한다.
모든 애플리케이션들 코드에 더해진 모든 진단 모듈들(103f)이 동일한 데이터 수집 모델을 이용하기 때문에, 추론(inference) 및 정보가 가능한 많이 추출될 수 있게 하도록 추가적인 자원들이 분석 함수(704)에 적용될 수 있다.
GUI 함수(705)에 의해 표시되거나 또는 제공된 정보로부터, 장치 코드에 대한 이해와 함께, 개시된 알고리즘, 방법 및 장치 해법은, 디자인 개념을 누설하지 않고 내부 변수들의 액션들을 검토하고 이해하게 해주며 잡사이트 해법들이 현존하는 시행착오 방법들보다 더 빠르게 달성되게 한다.
도 8은 애플리케이션 코드(100) 및/또는 진단 모듈(103f)을 실행할 수 있는 자동화 컴포넌트(800)의 예시적인 상세한 뷰를 나타낸다. 자동화 컴포넌트(800)는 FFD(502), RFD(501), PAN 코디네이터(503) 또는 임의의 다른 유선 또는 무선 장치일 수 있다. 자동화 컴포넌트(800)가 본원에서 예시되고 설명되지만, 그 구성, 레이아웃 및 구성 부품(componentry)은 도 5와 함께 도시되고 설명된 네트워크(500) 내에 배치된 장치들 및/또는 자동화 컴포넌트들 중 임의의 것과 함께 이용될 수 있다. 이 예시적인 실시예의 자동화 컴포넌트(800)는 메모리(804) 또는 저장 매체와 통신하는 INTEL®PENTIUM, AMD®ATHLON™ 또는 다른 8, 12, 16, 24, 32 또는 64 비트 클래스들의 프로세서들과 같은 프로세서(802)를 포함할 수 있다. 메모리(804) 또는 저장 매체는 RAM(806), 플래시 가능한(flashable) 또는 플래시 가능하지 않은(non-flashable) ROM(808) 및/또는 하드 디스크 드라이브(도시되지 않음), 또는 임의의 다른 알려진 또는 예상된 저장 장치 또는 메커니즘을 포함할 수 있다. 자동화 컴포넌트(800)는 통신 컴포넌트(810)을 더 포함할 수 있다. 통신 컴포넌트(810)는, 예를 들면, 네트워크(500)와의 유선 통신을 구현하기 위해 필요한 포트들, 하드웨어 및 소프트웨어를 포함할 수 있다. 통신 컴포넌트(810)는 대안적으로, 또는 그에 더하여, 안테나(816) 또는 다른 브로드캐스트 하드웨어에 통신적으로 연결되는 무선 송신기(812) 및 수신기(814) (또는 통합된 트랜스시버)를 포함할 수 있다.
예시적인 자동화 컴포넌트(800)의 서브-컴포넌트들(802, 804 및 810)은 통신 버스(818)를 통해 서로 정보를 공유하도록 연결되고 구성될 수 있다. 이런 방식으로, 소프트웨어, 펌웨어, 애플리케이션 코드(100) 및/또는 진단 모듈(103f)과 같은 컴퓨터 판독가능 명령어들 또는 코드는 메모리(804)에 저장될 수 있다. 프로세서(802)는 통신 버스(818)를 통해 컴퓨터 판독가능 명령어들 또는 코드를 판독하고 실행할 수 있다. 결과로서 생기는 명령들, 요청들 및 쿼리들은 네트워크(500) 내에서 동작하는 다른 자동화 컴포넌트들에 송신기(812) 및 안테나(816)를 통해 송신하기 위해 통신 컴포넌트(810)에 제공될 수 있다. 서브-컴포넌트들(802-818)은 이산 컴포넌트들(discrete components)일 수 있거나 또는 하나 이상의 집적 회로, 다중-칩 모듈, 및 또는 하이브리드(hybrid)에 통합될 수 있다.
예시적인 자동화 컴포넌트(800)는, 예를 들면, 구조 내에 배치되거나 설치된 WRTS와 같은 RFD(501)일 수 있다. 동작 중에, WRTS는 구조의 영역 또는 지역 내의 온도를 모니터링하거나 또는 검출할 수 있다. 검출된 온도를 나타내는 온도 신호 또는 표시는 또한 WRTS에 의해 생성될 수 있다. 또 다른 실시예에서, 자동화 컴포넌트(800)는, 예를 들면, 센서 또는 다른 자동화 컴포넌트에 연결된 액츄에이터일 수 있다. 동작 중에, 액츄에이터는 네트워크(500) 내의 또 다른 자동화 컴포넌트로부터 신호 또는 표시를 수신하고, 수신된 신호에 따라 기계적 컴포넌트의 위치를 조절할 수 있다. 신호 또는 표시는 나중에 처리하거나 또는 네트워크(500) 내의 또 다른 컴포넌트에 통신하기 위해 메모리(804) 내에 저장되거나 보관될 수 있다.
본원에서 설명된 현재의 바람직한 실시예들에 대한 다양한 변화들 및 변경들은 본 기술 분야에 숙련된 자들에게 명백할 것이라는 것이 이해되어야 한다. 그러한 변화들 및 변경들은 본 발명의 정신 및 범주로부터 벗어나지 않고 그것의 의도된 이점들을 감소시키지 않고 행해질 수 있다. 이에 따라 그러한 변화들 및 변경들이 첨부된 청구항들에 의해 포함된다는 것이 의도된다.
Claims (20)
- 빌딩 자동화 시스템 내에서 동작가능한 제1 계층적 장치(hierarchical device)에 대한 진단을 수행하는 방법으로서,상기 제1 계층적 장치를 제어하도록 구성된 애플리케이션 코드를 컴파일링(compiling)하는 단계 ― 상기 애플리케이션 코드는 복수의 내부 변수들을 포함함 ―;상기 복수의 내부 변수들을 모니터링하도록 구성된 진단 모듈을 제공하는 단계;상기 모니터링된 복수의 내부 변수들에 관련된 내부 변수 진단 데이터를 수집하는 단계;상기 수집된 내부 변수 진단 데이터를 제2 계층적 장치에 업로드하는 단계;상기 제2 계층적 장치에서, 상기 내부 변수 진단 데이터에 대한 계층화된(layered) 진단 분석을 수행하는 단계; 및그 분석된 내부 변수 진단 데이터에 기초하여 제1 계층적 장치 문제점을 식별하는 단계를 포함하는 방법.
- 제1항에 있어서, 내부 변수 진단 데이터를 수집하는 단계는 상기 애플리케이션 코드 내의 상기 복수의 내부 변수들 중 하나의 내부 변수를 모니터링하기 위한 체크포인트를 설정하는 단계를 더 포함하는 방법.
- 제1항에 있어서, 상기 제1 계층적 장치는 상기 모니터링된 복수의 내부 변수들을 저장하기 위해 예약된(reserved) 진단 메모리를 갖는 메모리를 포함하는 방법.
- 제3항에 있어서, 상기 진단 메모리는 계층적 데이터 로깅 스키마(hierarchical data logging schema)에 연관된 복수의 층들 각각에 따라 할당되는 방법.
- 제3항에 있어서, 상기 진단 메모리는 체크포인트의 우선 순위에 따라 할당되는 방법.
- 제5항에 있어서, 하위 우선 순위를 갖는 제1 체크포인트는 상위 우선 순위를 갖는 제2 체크포인트보다 더 적은 진단 메모리를 할당받는 방법.
- 제1항에 있어서, 상기 수집된 내부 변수 진단 데이터를 업로드하는 단계는 상기 수집된 내부 변수 데이터를 펜딩 중인(pending) 네트워크 통신에 추가(append)하는 단계를 포함하는 방법.
- 제1항에 있어서, 상기 모니터링된 복수의 내부 변수들에 관련된 내부 변수 진단 데이터를 수집하는 단계는 은닉된(hidden) 내부 변수 진단 데이터를 수집하는 단계를 포함하는 방법.
- 제1항에 있어서, 계층화된 진단 분석을 수행하는 단계는 프로그래머 진단 툴을 이용하는 단계를 포함하는 방법.
- 빌딩 자동화 시스템 내에서 동작가능한 계층적 장치로서,무선 통신 컴포넌트;상기 무선 통신 컴포넌트와 통신하는 프로세서; 및상기 프로세서와 통신하는 메모리― 상기 메모리는 상기 프로세서에 의해 실행가능한 애플리케이션 코드를 저장하도록 구성됨 ―를 포함하고,상기 애플리케이션 코드는,상기 애플리케이션 코드와 연관된 복수의 내부 변수들을 모니터링하고;상기 모니터링된 복수의 내부 변수들에 관련된 내부 변수 진단 데이터를 수집하고;상기 수집된 내부 변수 진단 데이터를 통신하도록구성된 진단 모듈을 포함하는 것인, 계층적 장치.
- 제10항에 있어서,무선 네트워크 내의 동작을 위해 구성되고 상기 내부 변수 진단 데이터에 대한 계층화된 진단 분석을 수행하도록 구성된 제2 계층적 장치를 더 포함하는 계층적 장치.
- 제11항에 있어서, 상기 제2 계층적 장치는 상기 분석된 내부 변수 진단 데이터에 기초하여 문제점을 식별하도록 더 구성되는 계층적 장치.
- 제10항에 있어서, 상기 내부 변수 진단 데이터는 상기 애플리케이션 코드 내의 상기 복수의 내부 변수들 중 하나의 내부 변수를 모니터링하기 위한 체크포인트를 포함하는 계층적 장치.
- 제10항에 있어서, 상기 메모리는 상기 모니터링된 복수의 내부 변수들을 저장하기 위해 예약된 진단 메모리를 포함하는 계층적 장치.
- 제14항에 있어서, 상기 진단 메모리는 계층적 데이터 로깅 스키마에 연관된 북수의 층들의 각각에 따라 할당되는 계층적 장치.
- 제14항에 있어서, 상기 진단 메모리는 체크포인트의 우선 순위에 따라 할당되는 계층적 장치.
- 제14항에 있어서, 상기 진단 메모리는 체크포인트와 연관된 우선 순위에 기초하여 할당되는 계층적 장치.
- 제17항에 있어서, 하위 우선 순위를 갖는 제1 체크포인트는 상위 우선 순위를 갖는 제2 체크포인트보다 더 적은 진단 메모리를 할당받는 계층적 장치.
- 제10항에 있어서, 상기 진단 모듈은,상기 수집된 내부 변수 데이터를 펜딩 중인 네트워크 통신에 추가하도록 더 구성된 계층적 장치.
- 제10항에 있어서, 상기 수집된 내부 변수들은 수집된 은닉된 내부 변수 진단 데이터를 포함하는 계층적 장치.
Applications Claiming Priority (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US91571007P | 2007-05-03 | 2007-05-03 | |
US60/915,710 | 2007-05-03 | ||
US3510908P | 2008-03-10 | 2008-03-10 | |
US61/035,109 | 2008-03-10 | ||
US12/114,766 US8332819B2 (en) | 2007-05-03 | 2008-05-03 | Diagnostic and trouble-shooting methods in a wireless control and sensor network |
US12/114,766 | 2008-05-03 | ||
PCT/US2008/005761 WO2008137127A1 (en) | 2007-05-03 | 2008-05-05 | Diagnostic and trouble-shooting methods in a wireless control and sensor network |
Publications (2)
Publication Number | Publication Date |
---|---|
KR20100019473A true KR20100019473A (ko) | 2010-02-18 |
KR101085621B1 KR101085621B1 (ko) | 2011-11-22 |
Family
ID=39940427
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
KR1020097025159A KR101085621B1 (ko) | 2007-05-03 | 2008-05-05 | 무선 제어 및 센서 네트워크에서의 진단 및 문제 해결 방법들 |
Country Status (7)
Country | Link |
---|---|
US (1) | US8332819B2 (ko) |
EP (1) | EP2145239B1 (ko) |
KR (1) | KR101085621B1 (ko) |
CN (1) | CN101802729B (ko) |
BR (1) | BRPI0810732B1 (ko) |
CA (1) | CA2685901C (ko) |
WO (1) | WO2008137127A1 (ko) |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1460546A1 (fr) * | 2003-03-18 | 2004-09-22 | SCHLUMBERGER Systèmes | Procédé de sécurisation de l'exécution d'un programme dans un ensemble électronique contre les attaques par introduction d'erreurs |
WO2009116126A1 (ja) * | 2008-03-17 | 2009-09-24 | 富士通株式会社 | 情報取得支援装置 |
US8219776B2 (en) * | 2009-09-23 | 2012-07-10 | Lsi Corporation | Logical-to-physical address translation for solid state disks |
US9092332B2 (en) * | 2013-05-02 | 2015-07-28 | Microsoft Technology Licensing, Llc | Activity based sampling of diagnostics data |
CN103581952A (zh) * | 2013-11-25 | 2014-02-12 | 广州视声电子实业有限公司 | 一种智能家居设备及执行诊断的方法 |
US9886707B1 (en) * | 2014-12-18 | 2018-02-06 | Jpmorgan Chase Bank, N.A. | System and method for building dynamic hierarchy for products |
US9906413B1 (en) * | 2014-12-18 | 2018-02-27 | Jpmorgan Chase Bank, N.A. | System and method for implementing a dynamic hierarchy for devices |
CN107408809B (zh) | 2015-01-13 | 2019-12-10 | 特灵国际有限公司 | 改进的无线hvac组件 |
CN104717689B (zh) * | 2015-03-12 | 2018-05-11 | 清华大学 | 一种无线传感器网络的故障诊断方法 |
US20160370023A1 (en) | 2015-06-19 | 2016-12-22 | Trane International Inc. | Fault detection and diagnostics system utilizing service personnel feedback for improved accuracy |
US10191024B2 (en) | 2015-07-13 | 2019-01-29 | Trane International Inc. | Energy management for sensors |
US10255127B2 (en) * | 2015-09-30 | 2019-04-09 | International Business Machines Corporation | Optimized diagnostic data collection driven by a ticketing system |
US11274843B2 (en) * | 2018-12-31 | 2022-03-15 | Johnson Controls Tyco IP Holdings LLP | Systems and methods for providing multi-dimensional load data on a dashboard |
Family Cites Families (40)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4841434A (en) * | 1984-05-11 | 1989-06-20 | Raytheon Company | Control sequencer with dual microprogram counters for microdiagnostics |
US5202985A (en) * | 1988-04-14 | 1993-04-13 | Racal-Datacom, Inc. | Apparatus and method for displaying data communication network configuration after searching the network |
US4989132A (en) * | 1988-10-24 | 1991-01-29 | Eastman Kodak Company | Object-oriented, logic, and database programming tool with garbage collection |
JPH02272645A (ja) * | 1989-04-14 | 1990-11-07 | Hitachi Ltd | プログラム・デバツグ支援方法 |
US5584009A (en) * | 1993-10-18 | 1996-12-10 | Cyrix Corporation | System and method of retiring store data from a write buffer |
US5634098A (en) * | 1995-02-01 | 1997-05-27 | Sun Microsystems, Inc. | Method and apparatus for environment-variable driven software testing |
US6272672B1 (en) * | 1995-09-06 | 2001-08-07 | Melvin E. Conway | Dataflow processing with events |
US5784553A (en) * | 1996-01-16 | 1998-07-21 | Parasoft Corporation | Method and system for generating a computer program test suite using dynamic symbolic execution of JAVA programs |
US6314558B1 (en) * | 1996-08-27 | 2001-11-06 | Compuware Corporation | Byte code instrumentation |
US6721941B1 (en) * | 1996-08-27 | 2004-04-13 | Compuware Corporation | Collection of timing and coverage data through a debugging interface |
US5915083A (en) * | 1997-02-28 | 1999-06-22 | Vlsi Technology, Inc. | Smart debug interface circuit for efficiently for debugging a software application for a programmable digital processor device |
US6182279B1 (en) * | 1997-08-12 | 2001-01-30 | International Business Machines Corporation | Method and apparatus for storing templates in a component system |
US5991543A (en) * | 1997-08-29 | 1999-11-23 | Dell Usa, L.P. | Software installation and testing for a build-to-order computer system |
US6401220B1 (en) * | 1998-08-21 | 2002-06-04 | National Instruments Corporation | Test executive system and method including step types for improved configurability |
GB9825102D0 (en) * | 1998-11-16 | 1999-01-13 | Insignia Solutions Plc | Computer system |
US6553565B2 (en) * | 1999-04-23 | 2003-04-22 | Sun Microsystems, Inc | Method and apparatus for debugging optimized code |
IT1309106B1 (it) | 1999-10-13 | 2002-01-16 | Merloni Elettrodomestici Spa | Utenza elettrica domestica a controllo elettronico e relativo sistemadi controllo e programmazione. |
US8032409B1 (en) * | 1999-11-22 | 2011-10-04 | Accenture Global Services Limited | Enhanced visibility during installation management in a network-based supply chain environment |
US20020087949A1 (en) * | 2000-03-03 | 2002-07-04 | Valery Golender | System and method for software diagnostics using a combination of visual and dynamic tracing |
US7779089B2 (en) * | 2000-09-15 | 2010-08-17 | Invensys Systems, Inc. | Method and system for remote configuration of process data access servers |
US6901586B1 (en) * | 2000-11-06 | 2005-05-31 | Sun Microsystems, Inc. | Safe language static variables initialization in a multitasking system |
DE10117459A1 (de) | 2001-04-06 | 2002-10-24 | Siemens Ag | Verfahren und Vorrichtung zur Gewinnung von Diagnoseinformationen |
US7292900B2 (en) * | 2001-07-13 | 2007-11-06 | Siemens Aktiengesellschaft | Power distribution expert system |
EP1407334B1 (en) * | 2001-07-13 | 2010-02-17 | Siemens Aktiengesellschaft | System architecture and method for network-delivered automation-related content |
JP2003173246A (ja) * | 2001-12-05 | 2003-06-20 | Ricoh Co Ltd | デバイス情報収集方法、プログラム、サーバ装置及び記憶媒体 |
US7206964B2 (en) * | 2002-08-30 | 2007-04-17 | Availigent, Inc. | Consistent asynchronous checkpointing of multithreaded application programs based on semi-active or passive replication |
US20040160464A1 (en) * | 2003-02-14 | 2004-08-19 | David Reyna | System and method for providing a graphical user interface and alternate mappings of management information base objects |
US7367023B2 (en) * | 2003-07-10 | 2008-04-29 | International Business Machines Corporation | Method and apparatus for generating computer programming code selectively optimized for execution performance and not optimized for serviceability |
US20050182655A1 (en) * | 2003-09-02 | 2005-08-18 | Qcmetrix, Inc. | System and methods to collect, store, analyze, report, and present data |
US7921412B1 (en) * | 2003-11-26 | 2011-04-05 | Sprint Communications Company L.P. | Application monitor system and method |
US7464373B1 (en) * | 2003-12-10 | 2008-12-09 | The Mathworks, Inc. | System and method for using a graphical debugging tool in a modeling and execution environment |
US7774172B1 (en) * | 2003-12-10 | 2010-08-10 | The Mathworks, Inc. | Method for using a graphical debugging tool |
DE10358732A1 (de) | 2003-12-15 | 2005-07-14 | BSH Bosch und Siemens Hausgeräte GmbH | Haushaltsgerät und Verfahren zum Ermitteln einer Störungsursache an einem solchen Gerät |
US7529897B1 (en) * | 2003-12-31 | 2009-05-05 | Vmware, Inc. | Generating and using checkpoints in a virtual computer system |
US7421562B2 (en) * | 2004-03-01 | 2008-09-02 | Sybase, Inc. | Database system providing methodology for extended memory support |
US7712081B2 (en) * | 2005-01-19 | 2010-05-04 | International Business Machines Corporation | Using code motion and write and read delays to increase the probability of bug detection in concurrent systems |
JP5096359B2 (ja) * | 2005-12-05 | 2012-12-12 | フィッシャー−ローズマウント システムズ,インコーポレイテッド | 同時プロセスシミュレーションを伴う多目的予測プロセス最適化 |
US7669081B2 (en) * | 2006-09-27 | 2010-02-23 | Raytheon Company | Systems and methods for scheduling, processing, and monitoring tasks |
US8706914B2 (en) * | 2007-04-23 | 2014-04-22 | David D. Duchesneau | Computing infrastructure |
US20110138319A1 (en) * | 2007-11-08 | 2011-06-09 | David Sidman | Apparatuses, Methods and Systems for Hierarchical Multidimensional Information Interfaces |
-
2008
- 2008-05-03 US US12/114,766 patent/US8332819B2/en active Active
- 2008-05-05 BR BRPI0810732-7A patent/BRPI0810732B1/pt active IP Right Grant
- 2008-05-05 EP EP08767562A patent/EP2145239B1/en active Active
- 2008-05-05 WO PCT/US2008/005761 patent/WO2008137127A1/en active Application Filing
- 2008-05-05 CN CN2008800145605A patent/CN101802729B/zh active Active
- 2008-05-05 CA CA2685901A patent/CA2685901C/en active Active
- 2008-05-05 KR KR1020097025159A patent/KR101085621B1/ko active IP Right Grant
Also Published As
Publication number | Publication date |
---|---|
CN101802729A (zh) | 2010-08-11 |
EP2145239A1 (en) | 2010-01-20 |
CA2685901A1 (en) | 2008-11-13 |
US8332819B2 (en) | 2012-12-11 |
BRPI0810732A2 (pt) | 2014-10-21 |
CN101802729B (zh) | 2012-12-12 |
KR101085621B1 (ko) | 2011-11-22 |
BRPI0810732B1 (pt) | 2019-04-30 |
EP2145239B1 (en) | 2012-11-28 |
CA2685901C (en) | 2015-06-30 |
US20080276127A1 (en) | 2008-11-06 |
WO2008137127A1 (en) | 2008-11-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR101085621B1 (ko) | 무선 제어 및 센서 네트워크에서의 진단 및 문제 해결 방법들 | |
CN107925612B (zh) | 网络监视系统、网络监视方法和计算机可读介质 | |
KR101683321B1 (ko) | 분산 애플리케이션들을 모니터링 하는 방법 | |
AU740146B2 (en) | A telecommunications performance management system | |
KR101951526B1 (ko) | 스마트팩토리 플랫폼을 위한 인터페이스 미들웨어 시스템 및 그 동작방법 | |
US8990770B2 (en) | Systems and methods to configure condition based health maintenance systems | |
US9037920B2 (en) | Method for performing condition based data acquisition in a hierarchically distributed condition based maintenance system | |
EP2581796A1 (en) | Method and computer readable storage media for distributed diagnostic reasoning | |
CN1936849A (zh) | 资源动态调整方法及设备 | |
US9043652B2 (en) | User-coordinated resource recovery | |
US8174990B2 (en) | Mechanism and system for programmable measurement of aggregate metrics from a dynamic set of nodes | |
KR20090000932A (ko) | 원격지 센서에서 측정된 대용량 데이터 처리 시스템 및 그방법 | |
JPWO2012029500A1 (ja) | 運用管理装置、運用管理方法、及びプログラム | |
EP1777188A1 (en) | Elevator monitoring system | |
CN101719091A (zh) | 面向服务体系结构中基于规则的监控方法和系统 | |
JP5598362B2 (ja) | トラフィックデータの監視システムおよびサーバ間データ整合方法 | |
KR102312523B1 (ko) | 대량의 데이터 수집을 위한 인터페이스 미들웨어 시스템 | |
JP4816169B2 (ja) | グローバルプロセス生成方法、装置、システム、およびプログラム | |
US20150012505A1 (en) | Configurable data masks supporting optimal data extraction and data compaction | |
JP7442751B1 (ja) | 制御プログラム、監視制御システム、ゲートウェイ装置及び制御方法 | |
KR102346721B1 (ko) | 전력 소모량 프로파일의 협력적 비교를 통한 연결기반 스마트 제어시스템의 멈춤 억제 장치 및 방법 | |
CN101894119A (zh) | 用于监控的海量数据的储存 | |
KR100916839B1 (ko) | 온라인 gis 예방진단시스템의 진단데이타에 대한정시간성 전송 보장형 통신 처리시스템 | |
Dixon et al. | An external logic architecture for implementing traffic signal system control strategies. | |
CN103581952A (zh) | 一种智能家居设备及执行诊断的方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A201 | Request for examination | ||
E902 | Notification of reason for refusal | ||
E701 | Decision to grant or registration of patent right | ||
GRNT | Written decision to grant | ||
FPAY | Annual fee payment |
Payment date: 20141021 Year of fee payment: 4 |
|
FPAY | Annual fee payment |
Payment date: 20151020 Year of fee payment: 5 |
|
FPAY | Annual fee payment |
Payment date: 20161014 Year of fee payment: 6 |
|
FPAY | Annual fee payment |
Payment date: 20181011 Year of fee payment: 8 |
|
FPAY | Annual fee payment |
Payment date: 20191008 Year of fee payment: 9 |