KR20130069298A - 디바이스 아키텍처 시스템 - Google Patents

디바이스 아키텍처 시스템 Download PDF

Info

Publication number
KR20130069298A
KR20130069298A KR1020120029823A KR20120029823A KR20130069298A KR 20130069298 A KR20130069298 A KR 20130069298A KR 1020120029823 A KR1020120029823 A KR 1020120029823A KR 20120029823 A KR20120029823 A KR 20120029823A KR 20130069298 A KR20130069298 A KR 20130069298A
Authority
KR
South Korea
Prior art keywords
file
message
information
management unit
manager
Prior art date
Application number
KR1020120029823A
Other languages
English (en)
Inventor
이은서
이학진
이광일
김민기
박준희
Original Assignee
한국전자통신연구원
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 한국전자통신연구원 filed Critical 한국전자통신연구원
Publication of KR20130069298A publication Critical patent/KR20130069298A/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • H04L12/2812—Exchanging configuration information on appliance services in a home automation network describing content present in a home automation network, e.g. audio video content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2823—Reporting information sensed by appliance or service execution status of appliance services in a home automation network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Landscapes

  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)

Abstract

본 발명은 디바이스 아키텍처 시스템에 관한 것으로, 홈네트워크 상에서 특정 디바이스를 검색하기 위한 디스커버리 관리부, 홈네트워크 상에서 특정 디바이스를 대상으로 정보를 요청하고 정보를 수신하기 위한 정보 관리부, 홈네트워크 상에서 디바이스의 상태 변화를 알려주기 위한 광고 관리부, 홈네트워크 상에서 특정 이벤트가 발생하였을 때 구독을 요청한 특정 디바이스에게 이벤트 정보를 전송하기 위한 이벤트 관리부, 다양한 디바이스별 기능들을 통해 디바이스 혹은 서비스를 제어하기 위한 제어 관리부, 파일의 송수신 및 그 결과, 특정 파일에 대한 기능 수행 및 그 결과를 관리하기 위한 파일 관리부 및, 메시지를 생성 및 분석하기 위한 메시지 관리부를 포함한다.

Description

디바이스 아키텍처 시스템{DEVICE ARCHITECTURE SYSTEM}
본 발명은 홈네트워크 환경에서의 디바이스 아키텍처 시스템에 관한 것으로, 특히 디바이스 계층뿐만 아니라 네트워크, 서비스 등 여러 계층에서 제공되는 정보들을 표준화된 프로토콜을 통해 통합적으로 운용 및 관리할 수 있는, 즉 디바이스, 서비스 간 호환성 제공에 초점을 맞춘 디바이스 아키텍처 시스템에 관한 것이다.
홈네트워크란 인터넷 기반의 정보화가 생활속에 자리잡은 현실로 인하여 단순한 가정내 네트워크 연결이 아닌 주택(건물)내의 정보기술 요소를 구현하는 토탈 홈정보제어 시스템 및 서비스/솔루션을 총칭하는 개념이다. 그리고, 미들웨어(middleware)란 두 개 이상의 시스템 혹은 프로그램 사이에서 둘 사이를 중재하는 프로그래밍 서비스를 말한다. 그런데, 이종의 홈네트워크 미들웨어 상에 접속해 있는 홈 디바이스들간의 상호 연동이 문제되어 왔다.
한국 특허출원 제2005-207263호는 이러한 이종의 홈네트워크 미들웨어 상에 접속해 있는 홈 디바이스들간의 상호 연동을 위한 홈네트워크 범용 미들웨어 브릿지 시스템 및 그 방법을 개시하고 있다. 이 발명은 이종의 홈네트워크 미들웨어 상에 접속해 있는 모든 디바이스들을 가상적으로 마치 동일한 미들웨어 상에 접속해 있는 실제의 물리적인 디바이스들처럼 보이도록 함으로써, 디바이스 접속/해제, 디바이스 제어, 이벤트 등록/발생알림을 해당 미들웨어들의 변형없이 기존의 해당 미들웨어 메커니즘대로 운용할 수 있게 하는, 이종의 홈네트워크 미들웨어상에 접속해 있는 홈 디바이스들간의 상호 연동을 위한 홈네트워크 범용 미들웨어 브릿지 시스템 및 그 방법을 제공한다. 하지만, 한국 특허출원 제2005-207263호는 기존 홈네트워크 프로토콜 혹은 미들웨어의 상호 운용 입장에서의 브릿지 시스템에 대한 것으로서, 디바이스, 네트워크 서비스 등 여러 계층에서 제공되는 정보들을 표준화된 프로토콜을 통해 통합적으로 운용할 수 있는 새로운 홈네트워크 시스템에 관한 것이 아니다.
아울러, 한국 특허출원 제2002-0010935호는 홈 네트워크를 구성할 수 있는 다양한 통신규격이 적용된 제품간의 호환이 이루어질 수 있도록 한 홈 네트워크 시스템의 호환장치 및 방법을 개시하고 있다. 한국 특허출원 제2002-0010935호에 의하면, UPnP가 지원되는 윈도우즈 XP로 동작하는 가전제품군과, 8비트 마이컴과 같이 저수준의 컨트롤러를 사용하는 일반 가전제품간의 규격을 호환시킬 수 있으므로 이종의 규격이 적용된 제품간의 홈 네트워크를 구성할 수 있다. 하지만, 이 또한 디바이스, 네트워크 서비스 등 여러 계층에서 제공되는 정보들을 표준화된 프로토콜을 통해 통합적으로 운용할 수 있는 새로운 홈네트워크 시스템에 관한 것이 아니었다.
따라서 홈네트워크 환경에서 디바이스 계층뿐만 아니라 네트워크, 서비스 등 여러 계층에서 제공되는 정보들을 표준화된 프로토콜을 통해 통합적으로 운용 관리 할 수 있는, 즉 디바이스, 서비스 간 호환성 제공에 초점을 맞춘 디바이스 아키텍처 구조의 제시가 요망되어 왔다.
본 발명은 상기한 점을 감안하여 발명된 것으로, 홈네트워크 상의 디바이스, 네트워크, 서비스 등 여러 계층에서 제공되는 정보들을 통합적으로 운용 및 관리할 수 있는 디바이스 아키텍처 시스템을 제공함에 그 목적이 있다.
본 발명의 일 측면에 의한 디바이스 아키텍처 시스템은 홈네트워크 상에서 특정 디바이스를 검색하기 위한 디스커버리 관리부, 홈네트워크 상에서 특정 디바이스를 대상으로 정보를 요청하고 정보를 수신하기 위한 정보 관리부, 홈네트워크 상에서 디바이스의 상태 변화를 알려주기 위한 광고 관리부, 홈네트워크 상에서 특정 이벤트가 발생하였을 때 구독을 요청한 특정 디바이스에게 이벤트 정보를 전송하기 위한 이벤트 관리부, 다양한 디바이스별 기능들을 통해 디바이스 혹은 서비스를 제어하기 위한 제어 관리부, 파일의 송수신 및 그 결과, 특정 파일에 대한 기능 수행 및 그 결과를 관리하기 위한 파일 관리부 및, 메시지를 생성 및 분석하기 위한 메시지 관리부를 포함한다.
이때 메시지 관리부는 메시지를 생성하는 메시지 생성기 및, 메시지를 분석하는 메시지 파서를 포함하고, 메시지는 헤더와 페이로드로 이루어지는 것이 바람직하다. 헤더는 시작신호, 소스 디바이스 ID, 타겟 디바이스 ID, 동작 코드 및 종료신호를 포함하는 것이 바람직하다.
디스커버리 관리부는, 디바이스 검색 조건, 디바이스 ID 또는 이름, 디바이스 타입 또는 성능 파라미터를 포함하는 디바이스 검색 요청 메시지 및, 요청된 검색 조건에 해당하는 디바이스 정보들을 페이로드로 생성한 디바이스 검색 응답 메시지를 이용하는 것이 바람직하다.
광고 관리부는, 디바이스 개수, 디바이스 ID 또는 이름, 디바이스 타입 또는 성능, 또는 네트워크 참여 정보 파라미터를 포함하는 디바이스 광고 메시지를 이용하는 것이 바람직하다.
정보 관리부는, 디바이스의 정보의 타입 파라미터를 포함하는 디바이스 정보 요청 메시지 및, 특정 디바이스로부터 정보 요구를 요청을 받았을 때 요청된 정보의 종류에 따라 해당 정보를 응답해주기 위한 디바이스 정보 응답 메시지를 이용하는 것이 바람직하다. 이때 디바이스 정보 타입 파라미터는, 디바이스의 기본 정보, 디바이스별 기능목록 정보, 디바이스 특성 정보, 디바이스의 일반 특성 정보, 디바이스의 환경 설정 정보, 디바이스의 상태 정보, 또는 디바이스별 고유 특성 정보를 포함하는 것이 바람직하다. 그리고, 디바이스 정보 응답 메시지는, 디바이스의 기본 정보, 디바이스별 기능목록 정보, 디바이스 특성 정보, 디바이스의 일반 특성 정보, 디바이스의 환경 설정 정보, 디바이스의 상태 정보, 또는 디바이스별 고유 특성 정보를 포함하되, 디바이스의 기본 정보는 디바이스 ID, 타입, 이름, 복합 디바이스가 지원하는 여러 고유 기능목록 정보를 포함하고, 디바이스별 기능목록 정보는 디바이스별로 제공하는 기능 리스트 갯수, 디바이스별 정의된 기능 ID, 기능의 카테고리, 특정 기능 수행을 위해 디바이스 기준으로 입력되는 메시지 리스트, 또는 디바이스 기준으로 출력되는 메시지 리스트를 포함하는 것이 바람직하다.
제어 관리부는, 디바이스 타입 코드와 기능 목록 구분을 포함하는 기능 ID, 기능 카테고리, 입력 목록, 또는 출력 목록 파라미터를 포함하는 디바이스 제어 요청 메시지 및, 디바이스 제어 요청 메시지와 동일한 파라미터를 포함하는 디바이스 제어 응답 메시지를 이용하는 것이 바람직하다.
이벤트 관리부는, 기능 ID, 기능 카테고리, 또는 이벤트 목록 파라미터를 포함하는 이벤트 통지 메시지, 기능 ID, 구독 주기, 또는 구독 타입 파라미터를 포함하는 이벤트 구독 요청 메시지 및, 결과 파라미터를 포함하는 이벤트 구독 응답 메시지를 이용하는 것이 바람직하다.
파일 관리부는, 파일 타입, 파일 이름, 검색 대상 시작 시간, 또는 검색 대상 종료 시간 파라미터를 포함하는 파일 송수신 과정에 필요한 파일 정보 요청 메시지 및, 파일 정보 리스트 파라미터를 포함하는 파일 정보 응답 메시지를 이용하는 것이 바람직하다. 이때 파일 정보 리스트에는, 파일이름, 파일타입, 파일크기, 파일생성날짜, 파일 URL, 또는 파일 버전 정보가 포함되는 것이 바람직하다.
또는 파일 관리부는, 타겟 디바이스 위치, 로컬 디바이스 위치, 또는 파일 이름 파라미터를 포함하는 파일 전송 요청 메시지, 에러 코드를 포함하는 파일 전송 응답 메시지 및, 전송오류, 또는 전송완료 결과에 대한 파일 전송 결과 메시지를 이용하는 것이 바람직하다.
또는 파일 관리부는, 타겟 디바이스 위치, 로컬 디바이스 위치, 또는 파일 이름 파라미터를 포함하는 파일 전달 요청 메시지, 에러 코드를 포함하는 파일 전달 응답 메시지 및, 전송오류, 또는 전송완료 결과에 대한 파일 전달 결과 메시지를 이용하는 것이 바람직하다.
또는 파일 관리부는, 특정 파일에 대한 실행, 서비스 업데이트, 복원, 파일 추가, 또는 파일 삭제를 포함하는 기능 수행 요청 메시지, 에러 코드를 포함하는 기능 수행 응답 메시지 및, 기능 수행 오류, 또는 기능 수행 완료 결과에 대한 결과 메시지를 이용하는 것이 바람직하다.
바람직하게, 디바이스에 대한 원격 유지보수를 관리하기 위한 유지보수 관리부를 더 포함할 수 있다. 이러한 유지보수 관리부는 펌웨어 업데이트, 구성, 파일 업로드/다운로드, 또는 롤백/리부트 기능을 제공하는 것이 바람직하다.
상기한 바와 같이 본 발명에 의하면, 홈네트워크 환경에서 디바이스 계층뿐만 아니라 네트워크, 서비스 등 여러 계층에서 제공되는 정보들을 통합적으로 운용 및 관리할 수 있는 효과가 있다. 이는 홈네트워크에 연결되는 다양한 업체의 정보가전기기들 간의 효율적 관리 체계 제공하고, 지능형 홈 시장의 확산 및 지능형 홈 유지보수 업체와 같은 새로운 직업군을 창출할 수 있을 것으로 기대되며, 더 나아가서는 제조업체들이 독자적으로 정보가전기기를 개발할 수 있는 환경을 제공할 수 있게 된다.
도 1은 디바이스 아키텍처 기반의 홈네트워크 구성 예를 나타낸 개략도,
도 2는 본 발명의 바람직한 실시예에 의한 디바이스 아키텍처 시스템을 설명하기 위한 블록도,
도 3은 디바이스 아키텍처의 메시지의 구성을 설명하기 위한 개념도,
도 4는 "DEVICE_DISCOVERY_REQUEST" 메시지에 대한 예시적인 XML 스키마 구조,
도 5는 "DEVICE_DISCOVERY_RESPONSE" 메시지에 대한 예시적인 XML 스키마 구조,
도 6은 "DEVICE_ADVERTISEMENT" 메시지에 대한 예시적인 XML 스키마 구조,
도 7은 "DEVICE_INFO_REQUEST" 메시지에 대한 예시적인 XML 스키마 구조,
도 8은 "DEVICE_INFO_RESPONSE" 메시지에 대한 예시적인 XML 스키마 구조,
도 9는 "BASIC_INFO" 메시지에 대한 예시적인 XML 스키마 구조,
도 10은 "FUNCTION_LIST" 메시지에 대한 예시적인 XML 스키마 구조,
도 11은 "DEVICE_PROPERTY" 메시지에 대한 예시적인 XML 스키마 구조,
도 12는 "DEVICE_CONTROL_REQUEST" 메시지에 대한 예시적인 XML 스키마 구조,
도 13은 "DEVICE_CONTROL_RESPONSE" 메시지에 대한 예시적인 XML 스키마 구조,
도 14는 "EVENT_NOTIFICATION" 메시지에 대한 예시적인 XML 스키마 구조,
도 15는 "EVENT_SUBSCRIPTION_REQUEST" 메시지에 대한 예시적인 XML 스키마 구조,
도 16은 "EVENT_SUBSCRIPTION_RESPONSE" 메시지에 대한 예시적인 XML 스키마 구조,
도 17은 "GET_FILEINFO_REQUEST" 메시지에 대한 예시적인 XML 스키마 구조,
도 18은 "GET_FILEINFO_RESPONSE" 메시지에 대한 예시적인 XML 스키마 구조,
도 19는 "GET_FILE_REQUEST" 메시지에 대한 예시적인 XML 스키마 구조,
도 20은 "GET_FILE_RESPONSE" 메시지에 대한 예시적인 XML 스키마 구조,
도 21은 "GET_FILE_RESULT" 메시지에 대한 예시적인 XML 스키마 구조,
도 22는 "PUT_FILE_REQUEST" 메시지에 대한 예시적인 XML 스키마 구조,
도 23은 "PUT_FILE_RESPONSE" 메시지에 대한 예시적인 XML 스키마 구조,
도 24는 "PUT_FILE_RESULT" 메시지에 대한 예시적인 XML 스키마 구조,
도 25는 "APPLY_REQUEST" 메시지에 대한 예시적인 XML 스키마 구조,
도 26은 "APPLY_RESPONSE" 메시지에 대한 예시적인 XML 스키마 구조,
도 27은 "APPLY_RESULT" 메시지에 대한 예시적인 XML 스키마 구조이다.
이하, 첨부된 도면을 참조하여 본 발명에 따른 바람직한 실시예를 상세하게 설명하기로 한다. 그러나, 이하의 실시예는 이 기술분야에서 통상적인 지식을 가진 자에게 본 발명이 충분히 이해되도록 제공되는 것으로서 여러 가지 다른 형태로 변형될 수 있으며, 본 발명의 범위가 다음에 기술되는 실시예에 한정되는 것은 아니다.
도 1은 디바이스 아키텍처 기반의 홈네트워크 구성 예를 나타내고 있다. 각각의 정보 단말(100)에는 디바이스 아키텍처 시스템(200)이 탑재되어 있고, 그 위에는 디바이스 아키텍처 API를 이용한 어플리케이션(300)이 탑재되어 있다. 이러한 정보 단말에는 센서 디바이스, 정보 디바이스, 가전 기기, 네트워크 디바이스, 빌트인(built-in) 디바이스 등이 있다. 도 1에 도시된 바와 같이, 홈네트워크에서 다수의 정보 단말들(100)은 디바이스 관리 서비스를 제공하는 서버(110)와 네트워크로 연결된다. 디바이스 관리 서비스 서버(110)도 디바이스 아키텍처 시스템(200)과 어플리케이션(300)으로 이루어진다. 다양한 정보 단말(100)과 디바이스 관리 서비스 서버(110)는 서로 단말의 정보를 주고받고, 특정 제어 서비스들이 활용된다. 또한 특정 정보 단말(100)에 관련 어플리케이션(300)이 탑재되어 있다면, 다른 정보 단말을 관리 및 제어할 수도 있다.
이러한 디바이스 아키텍처는 홈 게이트웨이, 월패드, TV 등과 같은 홈네트워크 중심 단말들 간의 상호연동 문제를 해결하고, 홈네트워크 서비스 아키텍처를 공유하기 위해 필요하다. 디바이스 아키텍처는 디바이스 및 상태 정보를 제공하고, 디바이스 자동 구성을 위해 네트워크 초기화, 디바이스 초기화, 토폴로지 디스커버리와 같은 기능을 제공한다. 또한, 원격 유지보수를 위해 펌웨어 업데이트, 구성, 파일 업로드/다운로드, 롤백/리부트(rollback/reboot) 등의 기능을 제공하고, 디바이스 감시/제어를 위해 원격 제어, 로깅, 리부트 등의 기능을 제공한다.
도 2는 본 발명의 바람직한 실시예에 의한 디바이스 아키텍처 시스템(200)의 기본 구성도이다. 기본적으로 홈네트워크 내의 디바이스를 관리하는 어플리케이션(300)은 디바이스 아키텍처가 제공하는 API를 사용하게 되며, 디바이스 아키텍처 시스템(200)은 디스커버리 관리부(210), 정보 관리부(220), 광고 관리부(230), 이벤트 관리부(240), 제어 관리부(250), 파일 관리부(260) 및, 유지보수 관리부(280)를 포함한다.
그리고 디바이스 아키텍처 시스템(200)은 메시지 관리부(270)의 메시지 생성기(271)와 메시지 파서(272)를 이용하여 디바이스 관리 서비스 서버(110)와 통신한다. 메시지 생성기(271)는 개별 관리부의 고유 역할을 수행하기 위한 표준 메시지 스트림(Message stream)을 만들어주며, 메시지 파서(272)(Message Paser)는 수신된 표준 메시지 스트림을 분석하여 해당 관리부로 전달해주는 역할을 수행한다.
이러한 메시지는 디바이스 및 네트워크의 상태 정보를 제공하고, 네트워크 초기화, 디바이스 초기화 등의 기능을 통해 디바이스 자동 구성을 지원하는 것으로서, 도 3과 같은 구조를 가질 수 있다. 도 3을 참고하면, 디바이스 아키텍처의 메시지는 헤더(Header)와 페이로드(Payload)로 이루어질 수 있으며, 헤더는 바이너리 스트림(Binary Stream), 페이로드는 XML로 구성될 수 있다. 헤더는 시작신호, 소스 디바이스(Source Device) ID, 타겟 디바이스(Target Device) ID, 동작(OP) 코드, 종료신호 등으로 구성되며, 특히 동작 코드에는 디바이스 아키텍처에서 제공하는 다양한 기능들이 정의되어 있다. 따라서 디바이스 아키텍처 시스템은 기본적으로 디바이스 아키텍처 메시지를 받으면 헤더를 분석한 후, 동작 코드에 따라 페이로드를 해당 관리부에 전달한다. 헤더 필드 중 트랜스액션(Transaction) ID는 특정 요청과 응답 메시지가 공유하는 ID로서 요청 메시지 생성시간을 기준으로 만들어지는 시간정보이며, 응답시 이 ID를 사용하여 메시지를 생성하게 된다. 디바이스 아키텍처 헤더 구조의 내용은 예시적으로 표 1에 상세히 기술되어 있다.
필드명 크기 ( Byte ) 설명
MessageStart 2 message의 시작을 알리는 Magic Code
Version 1 DA 프로토콜 버전 (= 1)
Flag 1 Urgen,
Length 4 message 크기 (헤더 포함)
Mesage ID 4 Payload XML ID
Sequence Number 4 Partial sequence number for specific XML
Source ID 20 message 생성 노드 ID
Destination ID 20 message 목적지 노드 ID
OP Code 2 Operation code
TransactionID 4 트랜잭션 식별자, Request Transaction이 처음 initiation되었을 때의 시간
CRC 4 message 오류 확인 코드
Optional Header /
DATA		 Variable OP Code에 종속적인 가변 헤더 또는
사용자가 정의한 데이터
MessageEnd 2 message의 끝을 알리는 Magic Code
디바이스 아키텍처 기능들은 디바이스 아키텍처 메시지 헤더에 포함된 동작 코드(OP Code)를 통해 제공된다. 이러한 동작 코드 또는 동작 코드들의 조합을 통해 제공되는 주요 기능들은 디바이스 및 상태 정보 제공, 제로 구성(Zero Configuration), 원격 진단(Remote Diagnostic), 치료(Healing) 등 디바이스 자동 구성 및 원격 유지 보수를 위한 기능들이며, 이들은 해당 관리부에서 수행된다. 이러한 기능들은 개방형 API로 구현하여 홈네트워크 상호연동 미들웨어 시스템 안에서 활용될 수 있도록 설계하는 것이 바람직하다. 동작 코드의 예가 표 2에 예시적으로 나타나 있다.
Transaction OP Name Code Description
Device Discovery DEVICE_DISCOVERY_REQUEST
DEVICE_DISCOVERY_RESPONSE		 0x1111
0x1112		 특정 조건의 Device 검색
Device Advertisement DEVICE_ADVERTISEMENT 0x1121 Device 상태 변화 정보를 전송
Device Info DEVICE_INFO_REQUEST
DEVICE_INFO_RESPONSE		 0x2011
0x2012		 Device(Network) Description
Device/Network State
Device Control DEVICE_CONTROL_REQUEST
DEVICE_CONTROL_RESPONSE		 0x2111
0x2112		 Device 제어
Event EVENT_NOTIFICATION 0x2FF1 Device/Network 상태변화
SENSOR Data
사용자정의 이벤트
Evet Subscription EVENT_SUBSCRIPTION_REQUEST
EVENT_SUBSCRIPTION_RESPONSE 		0x2F11
0x2F12		 이벤트 등록 / 해제요청
요청 결과
GET FILE
INFO 		GET_FILEINFO_REQUEST
GET_FILEINFO_RESPONSE		 0x2211
0x2212		 파일정보 요청
파일정보 요청결과
GET FILE GET_FILE_REQUEST
GET_FILE_RESPONSE
GET_FILERESULT		 0x2221
0x2222
0x2223		 파일 전송 요청 (EXE, FIRMWARE, Configuration,
파일 송신 결과
PUT FILE PUT_FILE_REQUEST
PUT_FILE_RESPONSE
PUT_FILE_RESULT		 0x2231
0x2232
0x2233		 파일수신 수락요청
파일수신 요청수락여부
파일송신 결과전송
APPLY APPLY_REQUST
APPLY_RESPONSE
APPLY_RESULT		 0x2311
0x2312
0x2313		 Rollback / FILE (EXE, FIRMWARE, Configuration,)
User Defined Transaction USER Defined Operation 0x8000 ~ 0xFFFF 사용자가 정의한 transaction
디바이스 아키텍처 프로토콜에서는 디바이스의 타입에 따라 특정 속성값과 함수를 제공할 수 있으며, 표 3에는 디바이스 타입과 코드가 예시되어 있다. 디바이스 코드는 총 2 Bytes로 나타낼 수 있으며, 앞 1 Byte는 디바이스 카테고리, 뒤 1 Byte는 카테고리 내에서의 디바이스 구분을 위해 사용될 수 있다.
Device
Type 		Home Gateway /
Server 		Home Information Internet Consume Automation Audio / Video Miscellaneous
Code 11XX 12XX 13XX 14XX 15XX 1FXX
01 Home Gateway Phone Refrigerator Light Audio Speaker VIOCS
02 Home Server PDA Air Conditioner Gas Valve HIFI Audio UPS
03 Digital Cable STB PC Microwave Curtain Cam coder Complex Server
04 Digital Satellite STB Home Pad Boiler Power Meter Camera Network Device
05 Digital DMB STB Video Phone Oven Door Lock Scanner Open/Close Sensor
06 Digital IP STB Smart TV Laundry HVAC Printer Auto Parcel
07 Wall Pad Etc Running Machine Batch Breaker Display Etc
08 Etc Health Device Security CCTV
09 Coffee Machine Thermostat Etc
0A Etc Door Bell
0B Etc
디바이스 아키텍처 프로토콜에서는 메시지 전달과정 혹은 특정 서비스 과정에서 발생될 수 있는 다양한 에러 코드들이 정의될 수 있다. 기본적으로 에러 코드들은 2 Bytes Hex Code로 나타낼 수 있으며, 크게 공통 에러(Common Error), 특정 디바이스 관련 에러(Device Specific Error), 사용자 정의 에러(User Defined Error)로 구분될 수 있다. 이 중 공통 에러는 디바이스 아키텍처 프로토콜 동작 코드와 관련된 다양한 에러들을 나타내는데, 동작 에러, 트랜잭션 에러(Transaction Error), 파일 관련 에러(File-related Error) 등이 포함될 수 있다. 특정 디바이스 관련 에러는 개별 디바이스 별로 특정 서비스 과정에서 발생하는 에러들이다. 사용자 정의 에러는 특정 서비스와 관련된 특정한 에러들에 관한 것이다.
다시 도 2를 참조하여, 디바이스 아키텍처 시스템의 각 관리부에 대해 상세하게 설명한다.
디스커버리 관리부(210)(Discovery Manager)는 "DEVICE_DISCOVERY_REQUEST" 메시지와 "DEVICE_DISCOVERY_RESPONSE" 메시지를 이용하여 홈네트워크 상에서 특정 디바이스를 검색하는 기능을 한다.
"DEVICE_DISCOVERY_REQUEST"는 특정 디바이스 또는 서비스가 현재 네트워크에 연결된 디바이스들은 어떤 것들이 있으며, 그 디바이스들의 기본 정보는 무엇인지 알기 위해, 특정 조건으로 검색할 수 있는 요청 메시지이다. "DEVICE_DISCOVERY_REQUEST"와 함께 생성되어야 하는 페이로드 메시지 구조는 표 4과 같이 예시적으로 나타낼 수 있다.
OP Code Parameter Size Description Condition
Device Discovery Request
(0x1111)		 DiscoveryReqType 16 Bytes Char[16]
All
DeviceID
DeviceType
DeviceName
Capbility 		M
StrTypeReq 20 Bytes Char[20]
(DeviceID, DeviceName)		 O
HexTypeReq 2byte Hex
(DeviceType, DeviceCapability) 		O
파라미터를 살펴보면 "DiscoveryReqType"은 디스커버리를 위한 조건을 나타낸다. 즉, 모든 디바이스를 검색할 것인지, 디바이스 타입별로 검색할 것인지, 디바이스 이름 혹은 디바이스 성능을 기반으로 검색할 것인지를 결정하며, 16 Bytes 스트링으로 기술될 수 있다. "StrTypeReq"는 상기 기술한 "DiscoveryReqType"이 "DeviceID" 또는 "DeviceName"일 경우 검색하고자 하는 실제 "DeviceID"와 "DeviceName" 값을 기술하며, "HexTypeReq"는 "DiscoveryReqType"이 "DeviceType" 혹은 "DeviceCapability"일 경우 검색하고자 하는 "DeviceType"과 "DeviceCapability" 값을 16진수로 기술한다. "DiscoveryReqType"이 "All"일 경우 "StrTypeReq"와 "HexTypeReq"는 기술하지 않는다. 상기 기술한 "DEVICE_DISCOVERY_REQUEST"의 페이로드 메시지 구조의 XML 스키마 구조는 도 4와 같이 나타낼 수 있다.
"DEVICE_DISCOVERY_RESPONSE"는 "DEVICE_DISCOVERY_REQUEST"에 대한 응답 메시지로서, 요청된 검색 조건에 해당하는 디바이스 정보들을 XML기반의 페이로드로 생성하게 된다. 표 5 및 표 6은 "DEVICE_DISCOVERY_RESPONSE"의 페이로드 메시지 구조를 예시적으로 나타내었다.
OP Code Parameter Size Description Condition
Device Discovery Response
(0x1112) 		Result 2byte Result code M
DeviceList variable DeviceList Type -
Data Structure Parameter
( Condition ) 		Sub Parameter Size Description Condition
DeviceList Type NumOfDevice
(M)		 - 2 Bytes integer M
BasicInfo
(M)		 DeviceID 20 Bytes Char[20] M
DeviceType 2 Bytes Device Type M
DeviceName 16 Bytes Char[16] M
DeviceSubName 16 Bytes Char[16] M
DeviceCapabilityList Variable DeviceCapabilityList Type O
파라미터를 살펴보면, "Result"는 "DEVICE_DISCOVERY_REQUEST"에 대한 응답 처리여부를 나타내는 정보로서, 성공적으로 잘 처리되었을 때는 "0000" Hex값을 기술하며, 오류 발생 시에는 상기 설명된 에러 코드를 통해 기술할 수 있다. "DeviceList"는 실제 요청에 응답하는 디바이스의 기본 정보들을 나타내며, 디바이스의 갯수(NumOfDevice), 디바이스 ID, 디바이스 타입, 디바이스 이름, 디바이스 지원 기능이 포함된다. 상기 기술한 "DEVICE_DISCOVERY_RESPONSE"의 페이로드 메시지 구조의 XML 스키마 구조는 도 5와 같이 나타낼 수 있다.
디바이스 디스커버리의 프로세스를 예를 들어 설명하면, 먼저 서비스가 네트워크에 처음 접속하거나 어플리케이션 상에서 디스커버리 명령이 내려지면, 디스커버리 관리부(210)를 통해 "DEVICE_DISCOVERY_REQUEST" 메시지를 전송한다. 이 과정에서 메시지 관리부(270)는 메시지 생성기에서 페이로드 XML과 헤더 메시지를 생성하고, 생성된 메시지를 브로드캐스팅(Broadcasting)한다.
그러면 홈네트워크에 연결된 디바이스가 소켓을 통해 메시지를 수신하게 되고, 해당 디바이스의 메시지 관리부(270)는 메시지 파서(272)를 통해 헤더 및 페이로드를 분석한다. 헤더의 동작 코드가 "DEVICE_DISCOVERY_REQUEST"일 경우 해당 디바이스의 디스커버리 관리부(210)는 전달받은 정보와 자신의 디바이스 정보를 비교한다. 만약 요청 디바이스에 해당하는 경우, 자신의 디바이스 정보를 수집한 후 메시지 관리부(270)를 통해 페이로드 XML 과 헤더 메시지를 생성한 후에, 요청한 디바이스 혹은 서비스에게 디바이스 아키텍처 메시지를 전송한다. 이후 소켓을 통해 디바이스 아키텍처 메시지를 수신한 디바이스는 메시지 관리부(270)의 메시지 파서(272)를 통해 헤더 및 페이로드를 분석하고, 헤더의 동작 코드가 "DEVICE_DISCOVERY_RESPONSE"일 경우 디스커버리 관리부(210)는 디바이스 리스트/정보를 업데이트한다.
광고 관리부(230)(Advertisement manager)는 "DEVICE_ADVERTISEMENT" 메시지를 이용하여 디바이스의 접속 또는 온오프와 같은 기본적인 상태 변화를 알려주는 기능을 한다.
"DEVICE_ADVERTISEMENT" 메시지는 디바이스가 처음 네트워크에 연결되거나 전원이 켜질 때나 꺼질 때, 네트워크에 있는 디바이스(서비스)에게 자신의 기본 정보를 브로드캐스팅을 통해 알려주는 메시지이다. 만약 네트워크에 참여하는 디바이스가 여러 디바이스들과 연동되어 있는 게이트웨이(Gateway) 같은 장비일 경우에는, 자신의 노드에 있는 디바이스들의 정보를 한번에 제공해 줄 수도 있다. "DEVICE_ADVERTISEMENT" 메시지는 상기 기술한 "DEVICE_DISCOVERY_RESPONSE" 메시지 구조와 비슷하지만, 기본 정보에 AdType을 추가하여 "Start"/"End"를 스트링 형태로 기술함으로써, 현재 네트워크에 참여하는 디바이스인지 또는 나가는 디바이스인지를 구별할 수 있다. "DEVICE_ADVERTISEMENT" 메시지와 스키마 구조를 표 7 및 8과 도 6에 예시적으로 나타내었다.
OP Code Parameter Size Description
Device Advertisement
(0x1121)		 AdList variable AdList Type
Data Structure Parameter
( Condition ) 		Sub Parameter Size Description Condition
AdList Type NumOfDevice
(M)		 - 2byte integer M
AdInfo
(M)		 DeviceID 20 Bytes Char[20] M
DeviceType 2 Bytes Device Type M
DeviceNme 16 Bytes Char[16] M
DeviceSubName 16 Bytes Char[16] M
DeviceCapabilityList Variable DeviceCapabilityList Type O
AdType 16Bytes Char[16]
Start
End		 M
디바이스 광고 프로세스를 예를 들어 설명하면, 서비스가 네트워크에 처음 접속하거나 전원이 켜질 때 혹은 종료할 때 디바이스의 광고 관리부(230)를 통해 메시지 관리부(270)와 연동하여 페이로드 XML과 헤더 메시지를 생성한다. 그리고, 생성된 메시지를 브로드캐스팅하면, 네트워크에 연결된 디바이스들은 소켓을 통해 메시지를 수신하고, 메시지 관리부(270)의 메시지 파서(272)는 헤더 및 페이로드를 분석한다. 그리고, 헤더의 동작 코드가 "DEVICE_ ADVERTISEMENT"일 경우 광고 관리부를 통해 전달받은 정보를 이용하여 Device ID와 같은 정보를 업데이트한다.
정보 관리부(220)(Information Manager)는 "DEVICE_INFO_REQUEST" 메시지와 "DEVICE_INFO_RESPONSE" 메시지를 이용하여 홈네트워크 상에서 특정 디바이스를 대상으로 다양한 정보를 요청하고 정보를 수신하는 기능을 한다.
"DEVICE_INFO_REQUEST"는 특정 디바이스를 대상으로 다양한 정보를 요청하기 위해 사용되는 메시지이다. "DEVICE_INFO_REQUEST"와 함께 생성되어야 하는 페이로드 메시지 구조는 표 9와 같이 예시적으로 나타낼 수 있다. "DEVICE_INFO_REQUEST"에 사용되는 파라미터는 요청하는 디바이스의 정보의 타입(DeviceInfoReqType) 하나이며, 디바이스 정보 타입은 크게 "BasicInfo", "FunctionList", "DeviceProperty" 세가지로 나뉠 수 있다. 이 세가지 정보를 모두 포함하는 "FullDescription", "DeviceProperty"의 세부 항목인 "CommonProperty", "ConfigProperty", "StatusProperty", "DeviceSpecificProperty"도 디바이스 요청 시 정보 타입으로 사용할 수 있으며, 이들은 모두 32Bytes 스트링 형식으로 기술될 수 있다.
OP Code Parameter Size Description Condition
Device Info Request
(0x2011)		 DeviceInfoReqType 32 Bytes Char[16]

FullDescription
BasicInfo
FunctionList
DeviceProperty
CommonProperty
ConfigProperty
StausProperty
DeviceSpecificProperty		 M
"BasicInfo"는 디바이스 ID, 타입, 이름 등의 기본 정보를 요청할 때 사용된다. "FunctionList"는 디바이스 별로 정의된 기능목록들을 요청하는 것이다. "DeviceProperty"는 디바이스 모델, 버전 등과 같은 일반적인 정보를 나타내는 "CommonProperty", 환경 설정 정보를 나타내는 "ConfigProperty", 현재 디바이스의 상태를 나타내는 "StatusProperty", 디바이스별 고유 특성을 나타내는 "DeviceSpecificProperty"로 구분되어, 서비스별로 필요한 정보들만 요청하여 받을 수 있다. 상기 기술한 "DEVICE_INFO_REQUEST"의 페이로드 메시지 구조의 XML 스키마 구조는 도 7과 같이 나타낼 수 있다.
"DEVICE_INFO_RESPONSE"는 특정 디바이스로부터 정보 요구를 요청을 받았을 때, 요청된 정보의 종류에 따라 해당 정보를 응답해주기 위한 메시지이다. "DEVICE_INFO_RESPONSE"와 함께 생성되는 페이로드 메시지 구조는 표 10과 같으며, 세부 타입별 메시지 구조는 도 8에 나타내었다.
OP Code Parameter Size Description Conditioin
DeviceInfo Response
(0x2012) 		Result 2 Bytes Error Code M
FullDescription variable BasicInfo Type
FunctionLIst Type
DeviceProprty Type 		-
BasicInfo variable BasicInfo Type -
FunctionLIst variable FunctionLIst Type -
DeviceProperty variable CommonProperty Type
ConfigProperty Type
StatusProperty Type
DeviceSpecificPropertyType 		-
CommonProperty variable CommonProperty Type -
ConfigProperty variable ConfigProperty Type -
StatusProperty variable StatusProperty Type -
DeviceSpecificProperty variable DeviceSpecificPropertyType -
표 10을 참조하면, 디바이스 정보는 기본적으로 "BasicInfo", "FunctionList", "DeviceProperty" 세가지로 나눌 수 있으며, "FullDescription" 요청이 오면 위 세가지 정보를 모두 함께 보낼 수 있다. 또한 "DeviceProperty" 역시 "CommonProperty", "ConfigProperty", "StatusProperty", "DeviceSpecificProperty" 각각의 세부 항목별로도 정보를 보낼 수 있다.
"BasicInfo"는 디바이스 ID, 타입, 이름 등의 기본 정보를 응답할 때 사용된다. 특히, "BasicInfo"에는 "DeviceCapabilityList"라는 정보가 포함되는데, 이는 기존의 디바이스들의 기능을 조합한 새로운 디바이스 타입이 시장에 나올 경우, 복합 디바이스가 지원하는 여러 고유 기능들을 기존 디바이스 타입을 통해 기술할 수 있다. 표 11은 "BasicInfo"의 메시지 구조를 예시적으로 나타내고, 도 9는 "BasicInfo" 메시지의 스키마 구조를 나타낸다.
Data Structure Parameter Size Description Condition
BasicInfo Type DeviceID 20 Bytes Char[20] M
DeviceType 2 Bytes Device Type M
DeviceName 16 Bytes Char[16] M
DeviceSubName 16 Bytes Char[16] M
DeviceCapabilityList Variable DeviceCapabilityList
Type		 O
DeviceCapabilityList Type NumOfCapability 2 Bytes Integer M
DeviceCapability 2 Bytes Device Type M
"FunctionList"는 디바이스 별로 정의된 기능목록들에 대한 것이다. 표 12는 "FunctionList"의 메시지 구조를 예시적으로 나타낸다. "NumOfFunction"은 디바이스별로 제공하는 기능 리스트 갯수, "FunctionID"는 디바이스별 정의된 기능 ID, "FunctionCategory"는 기능의 성격이 제어 기능인지 또는 이벤트 기능인지 등과 같이 카테고리를 구별해 준다. "InputList"는 특정 기능 수행을 위해 디바이스 기준으로 입력되는 메시지 리스트이며, "OutputList"는 디바이스 기준으로 출력되는 메시지 리스트를 의미한다. 상기 기술한 "FunctionList" 메시지의 기본 XML 스키마 구조는 도 10과 같이 나타낼 수 있다.
Data Structure Parameter Size Description Condition
FunctionList Type NumOFFunction 2 Bytes Integer M
FunctionID 4 Bytes Hex M
FuctionCategory 8 Bytes Char[8]
Control
Event		 M
InputList Varialble InputList Type O
OutputList Varialble OutputList Type O
"DeviceProperty"는 디바이스 모델, 버전 등과 같은 일반적인 정보를 나타내는 "CommonProperty", 환경 설정 정보를 나타내는 "ConfigProperty", 현재 디바이스의 상태를 나타내는 "StatusProperty", 디바이스별 고유 특성을 나타내는 "DeviceSpecificProperty"로 이루어 질 수 있다. 서비스별로 필요한 정보들만 요청하여 받을 수 있다. 표 13은 "DeviceProperty"의 메시지 구조를 예시적으로 나타내고, 도 11은 "DeviceProperty"의 스키마 구조를 예시적으로 나타낸다.
Data Structure Parameter Size Description Condition
DeviceProperty Type CommonProperty Varialble CommonProperty Type M
ConfigProperty Varialble ConfigProperty Type M
StatusProperty Varialble StatusProperty Type M
DeviceSpecificProperty Varialble DeviceSpecificProperty Type M
"ConfigProperty"는 디바이스의 네트워크 설정과 펌웨어 혹은 소프트웨어 설정을 위한 정보들을 기술하며, 특히 디바이스 설정의 경우에는 "Configuration" 파일 이름 정보를 기술하여 각 제조사가 자체적으로 설정을 수행할 수 있다. 여기서 "DeviceConfig"의 FTPURL은 "Configuration File"과 "Apply Operation" 등을 위한 파일 관리를 하는 FTP 주소이다.
정보 관리부(220)의 디바이스 정보 요청 및 응답 프로세스를 예를 들어 설명하면, 서비스 혹은 어플리케이션에서 특정 디바이스를 선택하고 특정 정보를 요청하면 메시지 관리부(270)와 연동하여 페이로드 XML과 헤더 메시지를 생성하게 된다. 생성된 메시지는 타켓 디바이스 ID로 전달되고, 해당 디바이스는 소켓을 통해 메시지를 수신한다. 그러면, 해당 디바이스의 메시지 관리부(270)는 헤더 및 페이로드를 분석하여 헤더의 동작 코드가 "INFORMATION_REQUEST"일 경우 정보 관리부는 자신의 디바이스의 정보를 모아 메시지 관리부(270)와 연동하여 페이로드 XML과 헤더 메시지를 생성한다. 이후, 요청한 디바이스 혹은 서비스에게 메시지를 전송하면, 메시지를 전송받은 디바이스는 메시지 관리부(270)를 통해 헤더 및 페이로드를 분석한다. 만약 헤더의 동작 코드가 "DEVICE_INFORMATION_RESPONSE"이면 전달받은 정보를 이용하여 디바이스 정보를 업데이트 한다.
제어 관리부(250)(Control Manager)는 "DEVICE_CONTROL_REQUEST" 메시지와 "DEVICE_CONTROL_RESPONSE" 메시지를 이용하여 다양한 디바이스별 기능들을 통해 디바이스 혹은 서비스를 제어하는 기능을 한다.
"DEVICE_CONTROL_REQUEST"는 다양한 디바이스별 기능들을 통해 디바이스 혹은 서비스를 제어하기 위한 요청 메시지이다. 각 디바이스 별 기능 목록들은 해당 디바이스의 종류에 따라 다양하게 기술될 수 있다. 표 14는 "Device Control Request"의 메시지 구조를 예시적으로 나타낸다. "FunctionID"의 경우 총 4Bytes로 구성되는데, 상위 2Bytes는 디바이스 타입 코드(Device Type Code)이며 하위 2Bytes는 기능 목록 구분을 위해 사용된다. 따라서 "FunctionID"만 있어도, 어느 디바이스를 어떻게 제어하고자 하는지를 알 수 있다. 또한 "FunctionCategory"를 통해 해당 메시지가 제어 정보인지 이벤트 정보인지를 알려줄 수 있으며, 스트링 타입을 통해 "Control" 혹은 "Event"로 기술할 수 있다. 이러한 "DEVICE_CONTROL_REQUEST"의 페이로드 메시지 구조의 XML 스키마 구조는 도 12와 같이 나타낼 수 있다.
OP Code Parameter Size Description Condition
Device Control Request
(0x2111)		 FunctionID 4 Bytes Hex M
FuctionCategory 8 Bytes Char[8]
Control
Event		 M
InputList Varialble InputList Type O
OutputList Varialble OutputList Type O
"DEVICE_CONTROL_RESPONSE"는 다양한 디바이스별 기능을 수행하고자 하는 "DEVICE_CONTROL_REQUEST" 메시지에 대한 응답 메시지이다. 응답 유형은 요청에 대해 해당 기능을 정상적으로 수행했는지에 대한 여부를 나타내는 정보에서부터, 서비스 결과에 따른 다양한 정보까지 다양하며, 기본적인 메시지 구조는 "DEVICE_CONTROL_REQUEST"와 같을 수 있다. 표 15에는 "DEVICE_CONTROL_RESPONSE" 메시지 구조를 예시적으로 나타내었으며, XML 스키마 구조는 도 13과 같이 나타낼 수 있다.
OP Code Parameter Size Description Condition
Device Control Response
(0x2112)		 FunctionID 4 Bytes Hex M
FuctionCategory 8 Bytes Char[8]
Control
Event		 M
InputList Varialble InputList Type O
OutputList Varialble OutputList Type O
제어 관리부(250)의 디바이스 제어 프로세스를 예를 들어 설명하면, 서비스 혹은 어플리케이션에서 특정 디바이스를 선택하고 제어를 요청하면 메시지 관리부(270)와 연동하여 페이로드 XML과 헤더 메시지를 생성한다. 생성된 메시지는 타켓 DeviceID로 전달되고, 타겟 디바이스는 소켓을 통해 메시지를 수신하고 메시지 관리부(270)에서는 헤더 및 페이로드를 분석한다. 헤더의 동작 코드가 "CONTROL_REQUEST"일 경우 제어 관리부는 전달받은 정보를 분석하여 해당 디바이스 제어 모듈을 호출하고, 해당 디바이스 제어모듈에서 제어 명령을 내린 후 기능 구조체에 필요한 정보를 모아 메시지 관리부(270)와 연동하여 페이로드 XML과 헤더 메시지를 생성한다. 이후, 요청한 디바이스 혹은 서비스에게 메시지를 전송하고, 메시지를 전송받은 디바이스의 메시지 관리부(270)에서는 메시지를 분석하여 헤더의 동작 코드가 "DEVICE_CONTROL_RESPONSE"일 경우 제어 관리부는 전달받은 정보를 업데이트한다.
이벤트 관리부(240)(Event Manager)는 "EVENT_NOTIFICATION", "EVENT_SUBSCRIPTION_REQUEST", "EVENT_SUBSCRIPTION_RESPONSE" 메시지를 이용하여 이벤트가 발생하였을 때 구독을 요청한 특정 디바이스에 이벤트 정보를 전송하는 기능을 한다.
"EVENT_NOTIFICATION"은 센서와 같은 특정 이벤트를 주기적으로 발생시키는 디바이스를 위한 메시지 구조로서, 구독을 요청한 특정 디바이스에 이벤트 메시지를 통지하는 것이다. 기본 구조는 "FunctionLIst Type"의 "OutputList Type"을 따를 수 있다. 디바이스별 이벤트 목록은 해당 디바이스의 종류에 따라 다양하게 기술될 수 있다. "EVENT_NOTIFICATION"의 메시지 구조를 표 16에 예시적으로 나타내었고, XML 스키마 구조는 도 14와 같이 나타낼 수 있다.
OP Code Parameter Size Description Condition
Event Notification
(0x2FF1)		 FunctionID 4 Bytes Hex M
FuctionCategory 8 Bytes Char[8]
Control
Event		 M
EventList Varialble OutputList Type O
이벤트 관리부(240)의 이벤트 통지 프로세스를 예를 들어 설명하면, 구독요청이 온 디바이스에 이벤트 메시지를 전송하기 위해 해당 정보를 메시지 관리부(270)와 연동하여 페이로드 XML과 헤더 메시지를 생성하고, 생성된 메시지를 타켓 DeviceID로 전달한다. 그러면, 타겟 디바이스의 메시지 관리부(270)는 헤더와 페이로드를 분석하여 헤더의 동작 코드가 "EVENT_NOTIFICATION"일 경우 이벤트 관리부(240)는 전달받은 정보를 분석하여 해당 응용에 적용한다.
"EVENT_SUBSCRIPTION_REQUEST"는 센서와 같은 특정 이벤트를 주기적으로 발생시키는 디바이스를 대상으로 이벤트 정보를 구독하기 위한 요청 메시지이다. 표 17에 "EVENT_SUBSCRIPTION_REQUEST" 메시지 구조를 예시적으로 나타내었으며, XML 스키마 구조는 도 15와 같이 나타낼 수 있다. "SubscriptionInterval"은 구독하고자 하는 정보의 주기 정보로서 ms단위로 기술하며, "SubscriptionType"은 현재 등록하는 이벤트가 새로 등록하는 것인지, 갱신을 하는 것인지, 또는 취소하는 것인지를 나타내는 정보로서, "Renew", "Registration", "Cancel" 스트링 타입으로 기술할 수 있다.
OP Code Parameter Size Description Condition
Event Subscription Request
(0x2F11)		 FunctionID 4 Bytes Hex M
SubscriptionInterval 8 Bytes Char[8]
(ms)		 O
subscriptionType 8 Bytes Char[16]
Renew
Registration
Cancel		 O
"EVENT_SUBSCRIPTION_RESPONSE"는 센싱 정보와 같은 특정 이벤트 정보를 구독하기 위한 요청에 대한 응답 메시지이다. 메시지에는 표 18에 기술된 "Result Code"를 통하여 기술될 수 있으며, 스키마 구조는 도 16과 같이 나타낼 수 있다.
OP Code Parameter Size Description Condition
Event Subscription Response
(0x2F12)		 Result 2 Bytes Result Code M
이벤트 관리부(240)의 이벤트 구독 요청 및 응답 프로세스를 예를 들어 설명하면, 서비스 혹은 어플리케이션에서 특정 이벤트 구독 명령을 내리면 메시지 관리부(270)와 연동하여 페이로드 XML과 헤더 메시지를 생성한다. 생성된 메시지는 타켓 DeviceID로 전달되고, 수신받은 디바이스의 메시지 관리부(270)는 메시지를 분석한 후 헤더의 동작 코드가 "EVENT_SUBSCRIPTION"일 경우 전달받은 정보를 분석하여 해당 디바이스의 이벤트 관리부(240)를 업데이트한다. 이 과정에서 결과 정보를 메시지 관리부(270)와 연동하여, 결과 정보에 대한 페이로드 XML과 헤더 메시지를 생성한다. 생성된 메시지는 요청한 디바이스 혹은 서비스에게 전송되고, 메시지를 전달 받은 디바이스의 메시지 관리부(270)는 메시지를 분석한 후 헤더의 동작 코드가 "EVENT_SUBSCRIPTION_RESPONSE"일 경우 이벤트 관리부를 통해 결과정보 값을 받고, 이를 통해 이벤트 구독 절차를 종료한다.
파일 관리부(260)(File manager)는 "GET_FILEINFO_REQUEST", "GET_FILEINFO_RESPONSE", "GET_FILE_REQUEST", "GET_FILE_RESPONSE", "GET_FILE_RESULT", "PUT_FILE_REQUEST", "PUT_FILE_RESPONSE", "PUT_FILE_RESULT", "APPLY_REQUEST", "APPLY_RESPONSE", "APPLY_RESULT" 메시지를 이용하여, 파일의 송수신 및 그 결과, 특정 파일에 대한 기능 수행 및 그 결과를 관리하는 기능을 한다.
"GET_FILEINFO_REQUEST"는 파일 송수신 과정에 필요한 파일 정보를 요청하기 위한 메시지이다. "GET_FILEINFO_REQUEST" 메시지와 스키마 구조를 표 19와 도 17에 예시적으로 나타내었다. 정보 요청을 위한 파라미터들은 파일 타입, 파일 이름, 검색 대상 시작 날짜 및 시간, 검색 대상 종료 날짜 및 시간이며, 파일 타입에는 로그파일, 실행파일, 펌웨어 파일, 환경 설정 파일 등 다양한 타입을 조건으로 파일 정보를 요청할 수 있다.
OP Code Parameter Size Description Condition
Get Fileinfo Request
(0x2211)		 FileType 16 Bytes Char[16]
All
Log
Execution
Firmware
Debug
Configure
Image
Audio
Video
Text		 O
Name 64 Bytes Char[64] O
StartTime 16 Bytes Char[16]
년, 월, 일, 시, 분, 초
(ex : 20110808242233)		 O
EndTime 16 Bytes Char[16]
년, 월, 일, 시, 분, 초
(ex : 20110808242233)		 O
"GET_FILEINFO_RESPONSE"는 파일 정보 요청에 대한 응답 메시지이다. 이 메시지에는 요청된 파일 조건에 맞는 파일 정보 리스트가 기술되며, 파일 정보에는 파일이름, 파일타입, 파일크기, 파일생성날짜, 파일 URL, 파일 버전 정보가 포함될 수 있다. "GET_FILEINFO_RESPONSE" 메시지와 스키마 구조를 표 20 및 표 21과 도 18에 예시적으로 나타내었다.
OP Code Parameter Size Description Condition
Get Fileinfo Response
(0x2212)		 Result 2byte Result code (표 5) M
FileInfoList Variable FileInfoList Type M
Data Structure Parameter
( Condition ) 		Sub Parameter Size Description Condition
FileInfoList Type NumOfFile
(M)		 - 2 Bytes Integer M
FileInfo
(M)		 FileName 64 Bytes Char[64] M
FileType 16 Bytes Char[16]
All
Log
Execution
Firmware
Debug
Configure
Image
Audio
Video
Text		 M
FileSize 8 Bytes Char[8]
(Mbytes)		 M
Date 16 Bytes Char[16]
년, 월, 일, 시, 분, 초
(ex : 20110808242233)		 M
URL 256 Bytes Char[256]
(FTP URL)		 M
FileVersion 16 Bytes Char[16] O
파일 관리부(260)의 파일정보 요청 및 응답 프로세스를 예를 들어 설명하면, 서비스 혹은 어플리케이션에서 타겟 디바이스의 파일 정보를 요청하면 메시지 관리부(270)와 연동하여, 페이로드 XML과 헤더 메시지를 생성한다. 그리고, 생성된 메시지를 타켓 DeviceID로 전달하면, 해당 디바이스는 메시지를 수신하고 메시지 관리부(270)가 메시지를 분석한다. 만약 헤더의 동작 코드가 "GET_FILEINFO_REQUEST"일 경우 파일 관리부(260)는 전달받은 정보를 분석하여 응답해야 할 정보를 수집한 후 메시지 관리부(270)와 연동하여 메시지를 생성한다. 그리고, 요청한 디바이스 혹은 서비스에게 메시지를 전송하고, 전달받은 타겟 디바이스의 메시지 관리부(270)에서는 메시지를 분석하고, 헤더의 동작 코드가 "GET_FILEINFO_RESPONSE"일 경우 파일 관리부(260)는 파일 정보를 받아 해당 디바이스를 관리한다.
"GET_FILE_REQUEST"는 파일 전송 요청을 위한 메시지로서, URL을 통해 타겟 디바이스의 위치와 로컬 디바이스의 위치가 기술되며, 추가로 파일이름이 함께 기술될 수 있다. 실제 파일 다운로드는 FTP 프로토콜을 통해 피어투피어(Peer-to-Peer)로 이루어질 수 있다. "GET_FILE_REQUEST" 메시지와 스키마 구조를 표 22와 도 19에 예시적으로 나타내었다.
OP Code Parameter Size Description Condition
Get File Request
(0x2221)		 TargetURL 256 Bytes Char[256]
(FTP)		 M
LocalURL 256 Bytes Char[256]
(FTP)		 M
FileName 256 Bytes Char[256] M
"GET_FILE_RESPONSE"는 파일 전송 요청에 대한 응답 메시지로서, 에러 코드를 기술할 수 있다. "GET_FILE_RESPONSE" 메시지와 스키마 구조를 표 23과 도 20에 예시적으로 나타내었다.
OP Code Parameter Size Description Condition
Get File Response
(0x2222)		 Result 2 Bytes Error Code M
"GET_FILE_REQUEST"에 의해 실제 파일 전송이 모두 진행되기까지는 많은 시간이 걸릴 수 있다. 따라서 파일 전송 요청에 대한 동작 시작이 이루어지면, 상기 기술한 "Get File Response"를 통해 응답 메시지를 생성하고, 실제 파일 전송이 이루어지는 과정에서 발생하는 전송오류, 전송완료 등에 대한 응답 메시지는 "GET_FILE_RESULT"를 통해 이루어진다. "GET_FILE_RESULT" 메시지와 스키마 구조를 표 24와 도 21에 예시적으로 나타내었다.
OP Code Parameter Size Description Condition
Get File Result
(0x2223)		 Result 2 Bytes Error Code M
파일 관리부(260)의 파일 전송 프로세스를 예를 들어 설명하면, 서비스 혹은 어플리케이션에서 타겟 디바이스로부터의 파일 전송을 요청하면 메시지 관리부(270)와 연동하여 페이로드 XML과 헤더 메시지를 생성한다. 생성된 메시지는 타켓 DeviceID로 전달되고, 해당 디바이스의 메시지 관리부(270)는 메시지를 분석하다. 헤더의 동작 코드가 "GET_FILE_REQUEST"일 경우, 파일 관리부(260)는 전달받은 정보를 분석하여 해당 주소로 FTP 프로토콜을 사용하여 파일 전송명령을 내린다. 이후 FTP 전송이 시작되거나 또는 실패할 경우 에러 메시지를 메시지 관리부와 연동하여 생성하고, 요청한 디바이스 혹은 서비스에게 메시지를 전송한다. 메시지를 전달받은 타겟 디바이스의 메시지 관리부(270)는 메시지를 분석하여 헤더의 동작 코드가 "GET_FILE_RESPONSE"일 경우 파일 관리부(260)는 결과 정보를 받아 "Get file Transaction"을 관리한다. 만약, 파일 전송을 수행하고 있는 서비스 혹은 디바이스에서 FTP 파일 전송이 완료되거나 중간에 에러가 발행하면 FTP 에러 메시지를 메시지 관리부(270)와 연동하여 생성하고, 요청한 디바이스 혹은 서비스에게 메시지를 전송한다. 메시지를 전달받은 디바이스의 메시지 관리부(270)에서는 메시지를 분석하여 헤더의 동작 코드가 "GET_FILE_RESULT"일 경우 파일 관리부(260)는 결과 값을 받아 "Get file Transaction"을 관리한다.
"PUT_FILE_REQUEST"는 특정 URL로 파일 전달 요청을 하기 위한 메시지로서, URL을 통해 타겟 디바이스의 위치와 로컬 디바이스의 위치가 기술되며, 추가로 파일이름이 함께 기술될 수 있다. 실제 파일 다운로드는 FTP 프로토콜을 통해 피어투피어로 이루어질 수 있다. "PUT_FILE_REQUEST" 메시지와 스키마 구조를 표 25와 도 22에 예시적으로 나타내었다.
OP Code Parameter Size Description Condition
Put File Request
(0x2231)		 TargetURL 256 Bytes Char[256]
(FTP)		 M
LocalURL 256 Bytes Char[256]
(FTP)		 M
FileName 256 Bytes Char[256] M
"PUT_FILE_RESPONSE"는 파일 전달 요청에 대한 응답 메시지로서, 에러 코드를 통해 기술할 수 있다. "PUT_FILE_RESPONSE" 메시지와 스키마 구조를 표 26과 도 23에 예시적으로 나타내었다.
OP Code Parameter Size Description Condition
Put File Response
(0x2232)		 Result 2 Bytes Error Code M
"PUT_FILE_REQUEST"에 의해 실제 파일 전송이 모두 진행되기까지는 많은 시간이 걸릴 수 있다. 따라서 파일 전송 요청에 대한 동작 시작이 이루어지면, 상기 기술한 "Put File Response"를 통해 응답 메시지를 생성하고, 실제 파일 전송이 이루어지는 과정에서 발생하는 전송오류, 전송완료 등에 대한 응답 메시지는 "PUT_FILE_RESULT"를 통해 이루어진다. "PUT_FILE_RESULT" 메시지와 스키마 구조를 표 27과 도 24에 예시적으로 나타내었다.
OP Code Parameter Size Description Condition
Put File Result
(0x2233)		 Result 2 Bytes Error Code M
파일 관리부(260)의 특정 URL로 파일 전송을 요청하는 것은 "PUT_FILE_REQUEST", "PUT_FILE_RESPONSE", "PUT_FILE_RESULT" 메시지를 이용하는 것만 다를 뿐, 전반적인 프로세스는 상기에서 설명한 파일 전송을 진행하는 것과 유사하다.
"APPLY_REQUEST"는 특정 파일에 대한 실행, 서비스 업데이트, 복원, 파일 추가, 파일 삭제와 같은 기능 수행 요청 메시지로서, "ApplyType"을 통해 진행하고자 하는 기능을 구분한다. "ApplyFileName"은 현재 수행하고자 하는 기능을 제공하는 파일명을 나타내며, "Apply Request"의 메시지와 스키마 구조를 표 28과 도 25에 예시적으로 나타내었다.
OP Code Parameter Size Description Condition
Apply Request
(0x2311)		 ApplyType 16 Bytes Char[16]
Execution
Update
Rollback
FileAdd
FileDelete		 M
ApplyFileName 256 Bytes Char[256] M
"APPLY_RESPONSE"는 "Apply" 요청에 대한 응답 메시지로서, 에러 코드를 통해 기술할 수 있다. "Apply Response" 메시지와 스키마 구조를 표 29와 도 26에 예시적으로 나타내었다.
OP Code Parameter Size Description Condition
Apply Response
(0x2312)		 Result 2 Bytes Error Code M
"APPLY_REQUEST"에 의해 실제 파일 기능 수행이 모두 진행되기까지는 많은 시간이 걸릴 수 있다. 따라서 파일 기능 수행 요청에 대한 동작 시작이 이루어지면, 상기 기술한 "APPLY_RESPONSE"를 통해 응답 메시지를 생성하고, 실제 파일 기능 수행이 이루어지는 과정에서 발생하는 오류, 기능 수행 완료 등에 대한 응답 메시지는 "APPLY_RESULT"를 통해 이루어진다. "Apply Result" 메시지와 스키마 구조를 표 30과 도 27에 예시적으로 나타내었다.
OP Code Parameter Size Description Condition
Apply
Result
(0x2313)		 Result 2 Bytes Error Code M
파일 관리부(260)의 특정 파일에 대한 기능 수행 요청 프로세스를 예를 들어 설명하면, 서비스 혹은 어플리케이션에서 타겟 디바이스로의 어플라이 명령을 요청하면 메시지 관리부(270)와 연동하여 페이로드 XML과 헤더 메시지를 생성한다. 생성된 메시지는 타켓 DeviceID로 전달되고, 수신된 메시지는 헤더 및 페이로드가 분석된다. 헤더의 동작 코드가 "APPLY_REQUEST"일 경우 파일 관리부(260)는 전달받은 정보를 분석하여 해당 작업(파일실행, 업데이트, 롤백, 파일삭제, 파일추가 등) 수행 명령을 내린 후, 에러가 발생하면 에러 메시지를 메시지 관리부(270)와 연동하여 생성한다. 다시 요청한 디바이스 혹은 서비스에게 메시지를 전송하고, 메시지를 전달받은 디바이스 혹은 서비스는 메시지 관리부(270)를 통해 메시지를 분석한다. 헤더의 동작 코드가 "APPLY_RESPONSE"일 경우 파일 관리부(260)는 해당 정보를 받아 어플라이 동작을 관리한다. 만약 어플라이 해당 작업이 완료되거나 중간에 에러가 발행하면 에러 메시지를 생성하고, 요청한 디바이스 혹은 서비스에게 이 메시지를 전송할 수도 있다.
유지보수 관리부(280)는 디바이스에 대한 원격 유지보수를 관리하는 역할을 한다. 구체적으로, 원격 유지보수를 위해 펌웨어 업데이트(Fimware update), 구성(configuration), 파일 업로드/다운로드(file up/download), 롤백/리부트(rollback/reboot) 등의 기능을 제공한다.
이러한 유지보수 기능들은 추가적인 소프트웨어의 설치과정 없이 원격에서 자유롭게 수행되는 것이 바람직하다. 즉, 본 발명에 의한 디바이스 아키텍처 시스템에서 제공하는 프로토콜을 사용하는 디바이스들은 디바이스 제조업자가 프로토콜에 기반한 관리 기능을 응용레벨 / OS레벨에서 자유롭게 구현할 수 있으며, 추가적인 장치에 관리 소프트웨어를 설치할 필요 없이, 자체 프로토콜을 통해 원격에서 유지보수 기능을 활용할 수 있다. 이러한 유지보수 관리부(280)는 각 디바이스(100)의 디바이스 아키텍처 시스템(200) 및 디바이스 관리 서비스 서버(110)의 디바이스 아키텍처 시스템(200)에 구비되어, 디바이스 관리 서비스 서버(110)의 디바이스 아키텍처 시스템(200)이 개별 디바이스(100)에 대해 유지보수 관리하거나, 또는 특정 디바이스의 디바이스 아키텍처 시스템(200)이 다른 디바이스에 대해 유지보수 관리할 수도 있다.
이상 설명한 바와 같은 본 발명에 의한 디바이스 아키텍처 시스템을 활용하면 다양한 서비스 모델을 창출할 수 있다. 예를 들어, 디바이스 아키텍처 시스템은 홈네트워크 내의 다양한 디바이스들에 대한 정보 교환 및 원격 제어를 가능케 한다. 따라서 이는 주요 건물, 유적, 사물 등에 대한 안내 및 정보제공 서비스에 활용될 수 있다. 또한 상기에서는 디바이스 관리 서비스 서버(110)를 중심으로 다수의 정보 단말(100)을 제어 및 관리하는 관점에서 설명하였으나, 특정 정보 단말(100)에 관리 및 유지가 가능한 관련 어플리케이션(300)이 탑재되어 있다면, 다른 정보 단말을 직접 관리 및 제어할 수도 있음은 물론이다.

Claims (17)

  1. 홈네트워크 상에서 특정 디바이스를 검색하기 위한 디스커버리 관리부;
    홈네트워크 상에서 특정 디바이스를 대상으로 정보를 요청하고 정보를 수신하기 위한 정보 관리부;
    홈네트워크 상에서 디바이스의 상태 변화를 알려주기 위한 광고 관리부;
    홈네트워크 상에서 특정 이벤트가 발생하였을 때 구독을 요청한 특정 디바이스에게 이벤트 정보를 전송하기 위한 이벤트 관리부;
    다양한 디바이스별 기능들을 통해 디바이스 혹은 서비스를 제어하기 위한 제어 관리부;
    파일의 송수신 및 그 결과, 특정 파일에 대한 기능 수행 및 그 결과를 관리하기 위한 파일 관리부 및;
    메시지를 생성 및 분석하기 위한 메시지 관리부를 포함하는 것을 특징으로 하는 디바이스 아키텍처 시스템.
  2. 제1항에 있어서, 상기 메시지 관리부는 메시지를 생성하는 메시지 생성기 및, 메시지를 분석하는 메시지 파서를 포함하고,
    메시지는 헤더와 페이로드로 이루어지는 것을 특징으로 하는 디바이스 아키텍처 시스템.
  3. 제2항에 있어서, 상기 헤더는 시작신호, 소스 디바이스 ID, 타겟 디바이스 ID, 동작 코드 및 종료신호를 포함하는 것을 특징으로 하는 디바이스 아키텍처 시스템.
  4. 제1항에 있어서, 상기 디스커버리 관리부는,
    디바이스 검색 조건, 디바이스 ID 또는 이름, 디바이스 타입 또는 성능 파라미터를 포함하는 디바이스 검색 요청 메시지 및,
    요청된 검색 조건에 해당하는 디바이스 정보들을 페이로드로 생성한 디바이스 검색 응답 메시지를 이용하는 것을 특징으로 하는 디바이스 아키텍처 시스템.
  5. 제1항에 있어서, 상기 광고 관리부는,
    디바이스 개수, 디바이스 ID 또는 이름, 디바이스 타입 또는 성능, 또는 네트워크 참여 정보 파라미터를 포함하는 디바이스 광고 메시지를 이용하는 것을 특징으로 하는 디바이스 아키텍처 시스템.
  6. 제1항에 있어서, 상기 정보 관리부는,
    디바이스의 정보의 타입 파라미터를 포함하는 디바이스 정보 요청 메시지 및,
    특정 디바이스로부터 정보 요구를 요청을 받았을 때 요청된 정보의 종류에 따라 해당 정보를 응답해주기 위한 디바이스 정보 응답 메시지를 이용하는 것을 특징으로 하는 디바이스 아키텍처 시스템.
  7. 제6항에 있어서, 상기 디바이스 정보 타입 파라미터는,
    디바이스의 기본 정보, 디바이스별 기능목록 정보, 디바이스 특성 정보, 디바이스의 일반 특성 정보, 디바이스의 환경 설정 정보, 디바이스의 상태 정보, 또는 디바이스별 고유 특성 정보를 포함하는 것을 특징으로 하는 디바이스 아키텍처 시스템.
  8. 제6항에 있어서, 상기 디바이스 정보 응답 메시지는,
    디바이스의 기본 정보, 디바이스별 기능목록 정보, 디바이스 특성 정보, 디바이스의 일반 특성 정보, 디바이스의 환경 설정 정보, 디바이스의 상태 정보, 또는 디바이스별 고유 특성 정보를 포함하되,
    디바이스의 기본 정보는 디바이스 ID, 타입, 이름, 복합 디바이스가 지원하는 여러 고유 기능목록 정보를 포함하고,
    디바이스별 기능목록 정보는 디바이스별로 제공하는 기능 리스트 갯수, 디바이스별 정의된 기능 ID, 기능의 카테고리, 특정 기능 수행을 위해 디바이스 기준으로 입력되는 메시지 리스트, 또는 디바이스 기준으로 출력되는 메시지 리스트를 포함하는 것을 특징으로 하는 디바이스 아키텍처 시스템.
  9. 제1항에 있어서, 상기 제어 관리부는,
    디바이스 타입 코드와 기능 목록 구분을 포함하는 기능 ID, 기능 카테고리, 입력 목록, 또는 출력 목록 파라미터를 포함하는 디바이스 제어 요청 메시지 및,
    디바이스 제어 요청 메시지와 동일한 파라미터를 포함하는 디바이스 제어 응답 메시지를 이용하는 것을 특징으로 하는 디바이스 아키텍처 시스템.
  10. 제1항에 있어서, 상기 이벤트 관리부는,
    기능 ID, 기능 카테고리, 또는 이벤트 목록 파라미터를 포함하는 이벤트 통지 메시지,
    기능 ID, 구독 주기, 또는 구독 타입 파라미터를 포함하는 이벤트 구독 요청 메시지 및,
    결과 파라미터를 포함하는 이벤트 구독 응답 메시지를 이용하는 것을 특징으로 하는 디바이스 아키텍처 시스템.
  11. 제1항에 있어서, 상기 파일 관리부는,
    파일 타입, 파일 이름, 검색 대상 시작 시간, 또는 검색 대상 종료 시간 파라미터를 포함하는 파일 송수신 과정에 필요한 파일 정보 요청 메시지 및,
    파일 정보 리스트 파라미터를 포함하는 파일 정보 응답 메시지를 이용하는 것을 특징으로 하는 디바이스 아키텍처 시스템.
  12. 제11항에 있어서, 상기 파일 정보 리스트에는,
    파일이름, 파일타입, 파일크기, 파일생성날짜, 파일 URL, 또는 파일 버전 정보가 포함되는 것을 특징으로 하는 디바이스 아키텍처 시스템.
  13. 제1항에 있어서, 상기 파일 관리부는,
    타겟 디바이스 위치, 로컬 디바이스 위치, 또는 파일 이름 파라미터를 포함하는 파일 전송 요청 메시지,
    에러 코드를 포함하는 파일 전송 응답 메시지 및,
    전송오류, 또는 전송완료 결과에 대한 파일 전송 결과 메시지를 이용하는 것을 특징으로 하는 디바이스 아키텍처 시스템.
  14. 제1항에 있어서, 상기 파일 관리부는,
    타겟 디바이스 위치, 로컬 디바이스 위치, 또는 파일 이름 파라미터를 포함하는 파일 전달 요청 메시지,
    에러 코드를 포함하는 파일 전달 응답 메시지 및,
    전송오류, 또는 전송완료 결과에 대한 파일 전달 결과 메시지를 이용하는 것을 특징으로 하는 디바이스 아키텍처 시스템.
  15. 제1항에 있어서, 상기 파일 관리부는,
    특정 파일에 대한 실행, 서비스 업데이트, 복원, 파일 추가, 또는 파일 삭제를 포함하는 기능 수행 요청 메시지,
    에러 코드를 포함하는 기능 수행 응답 메시지 및,
    기능 수행 오류, 또는 기능 수행 완료 결과에 대한 결과 메시지를 이용하는 것을 특징으로 하는 디바이스 아키텍처 시스템.
  16. 제1항에 있어서,
    디바이스에 대한 원격 유지보수를 관리하기 위한 유지보수 관리부를 더 포함하는 것을 특징으로 하는 디바이스 아키텍처 시스템.
  17. 제16항에 있어서, 상기 유지보수 관리부는 펌웨어 업데이트, 구성, 파일 업로드/다운로드, 또는 롤백/리부트 기능을 제공하는 것을 특징으로 하는 디바이스 아키텍처 시스템.

KR1020120029823A 2011-12-16 2012-03-23 디바이스 아키텍처 시스템 KR20130069298A (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020110136255 2011-12-16
KR20110136255 2011-12-16

Publications (1)

Publication Number Publication Date
KR20130069298A true KR20130069298A (ko) 2013-06-26

Family

ID=48864720

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020120029823A KR20130069298A (ko) 2011-12-16 2012-03-23 디바이스 아키텍처 시스템

Country Status (1)

Country Link
KR (1) KR20130069298A (ko)

Similar Documents

Publication Publication Date Title
US6763040B1 (en) Internet control system communication protocol and method
CA2371739C (en) Internet control system and method
CN101461194B (zh) 用于远程访问网络中的装置的方法和系统
EP1905205B1 (en) Residential gateway system for home network service
KR100703361B1 (ko) 다수의 디지털 기기들의 어플리케이션을 관리하는 시스템및 방법
TWI295770B (ko)
US20090024727A1 (en) Network system management method
US20110314163A1 (en) Wireless communication network for smart appliances
TW201408019A (zh) 協定配接的系統、方法及電腦程式產品
KR102000234B1 (ko) 홈 네트워크 서비스를 제공하기 위한 장치 및 그 방법
US10405256B2 (en) Technique for access by a master device to a value taken by a characteristic managed by a peripheral device
CN111782228A (zh) 分布式应用生命周期管理的解决方案
JP3929733B2 (ja) 家電機器、家電サーバ装置及び中継装置
US20130173696A1 (en) Information providing service system and method based on inter-device information exchange protocol
KR20070119013A (ko) 네트워크 시스템의 디바이스 장치 및 프로파일 전송 방법
JP2005346190A (ja) 家電機器情報通信システム
KR20130077734A (ko) 다중 디바이스간 정보교환 프로토콜 기반의 정보제공 서비스 시스템 및 방법
KR101672868B1 (ko) 사물인터넷 디바이스의 소프트웨어 프로비저닝 시스템 및 방법
US20080172481A1 (en) Method of Configuring Network Profile of Network System
KR20130069298A (ko) 디바이스 아키텍처 시스템
CN102904978B (zh) 泛在网络内泛在设备实现通用即插即用的方法
KR20130077733A (ko) 다중 디바이스간 정보교환 프로토콜 기반의 정보제공 서비스 시스템 및 방법
CN107807619A (zh) 基于虚拟服务器模块的智能家居控制系统及其工作方法
US11888641B1 (en) Dynamic provisioning of IoT devices from an online application marketplace
US20240097931A1 (en) Decoupling IoT Devices with Soft-Wiring or other Configuration, Including Dynamic Variance of Control Group Pairings Based on Context Such as Time and/or Location

Legal Events

Date Code Title Description
WITN Withdrawal due to no request for examination