KR20070044200A

KR20070044200A - 유비쿼터스 센서 네트워크 시스템 및 그 시스템에서 수행되는 이벤트 요구 및 응답 방법

Info

Publication number: KR20070044200A
Application number: KR1020050100244A
Authority: KR
Inventors: 이민직; 송성학; 이재우; 정영식; 김종국
Original assignee: 삼성에스디에스 주식회사
Priority date: 2005-10-24
Filing date: 2005-10-24
Publication date: 2007-04-27
Also published as: KR100720284B1

Abstract

본 발명은 유비쿼터스 센서 네트워크를 위한 소프트웨어 아키텍처에 관한 것으로, 데이터를 센싱하는 복수개의 센서들로 이루어진 센서필드, 센서필드로부터 센싱된 데이터를 게이트웨이를 통해 수신하여, 저장 및 관리하는 말단 UIM, 말단 UIM으로부터 수신한 데이터를 콘텍스트 인지 기능으로 추상화하여 어플리케이션에 적합한 정보로 변환 및 저장하는 내부 UIM 및, 내부 UIM으로부터 수신한 정보를 이용하여 소정 서비스를 제공하는 어플리케이션을 포함한다. 이때, 말단 UIM과 내부 UIM은, 데이터를 저장하는 정보저장부, 상위 계층으로부터 이벤트 요구가 들어왔을 때 이벤트 조건을 분석하여 관련된 하위 계층을 연결시켜 주는 이벤트 관리블록, 하위 계층으로부터 들어오는 이벤트 응답을 처리하는 이벤트 처리블록 및, 정보저장부에 저장된 데이터에 대해 상위 계층으로부터 요청이 있을 때 이에 응답하는 질문 처리블록을 구비하는 정보제어부 및, 메시지 큐를 이용한 신뢰할 수 있는 메시징 기능을 제공하고, 서비스 통합을 위한 인터페이스를 제공하는 정보버스를 포함한다.

Description

유비쿼터스 센서 네트워크를 위한 소프트웨어 아키텍처 및 그 소프트웨어 아키텍처에서 수행되는 이벤트 요구 및 응답 방법 {SOFTWARE ARCHITECTURE FOR UBIQUITOUS SENSOR NETWORK AND METHOD OF EVENT REQUEST AND RESPONSE PERFORMING IN THE SOFTWARE ARCHITECTURE}

도 1은 종래기술에 의한 'IrisNet' 아키텍처를 설명하기 위한 개요도이다.

도 2는 종래기술에 의한 'Gaia' 아키텍처를 설명하기 위한 개요도이다.

도 3은 본 발명의 바람직한 실시예에 따른 유비쿼터스 센서 네트워크를 위한 소프트웨어 아키텍처를 설명하기 위한 개요도이다.

도 4는 도 3에 도시된 UIM의 구조를 설명하기 위한 블록도이다.

도 5는 UIM의 이벤트 데이터 플로우를 설명하기 위한 블록도이다.

도 6은 UIM 내에서 일어나는 이벤트 요구와 관련된 데이터 플로우를 보여준다.

도 7은 이벤트 응답과 관련된 데이터 플로우를 보여준다.

도 8은 UIM의 질문 데이터 플로우를 보여준다.

도 9는 본 발명의 일실시예에 따른 산불 감시 시스템 화면을 표시한 것이다.

본 발명은 유비쿼터스 센서 네트워크(Ubiquitous sensor network; USN)에 관한 것으로, 특히 유비쿼터스 센서 네트워크를 종래의 비지니스 환경에 쉽게 연계할 수 있는 서비스 지향 아키텍처(Service Oriented Architecture; SOA) 기반의 웹서비스를 이용한 소프트웨어 아키텍처 및 그 소프트웨어 아키텍처에서 수행되는 이벤트 요구 및 응답 방법에 관한 것이다.

최근 유비쿼터스 컴퓨팅이 부각되고, 그에 따라 유비쿼터스 센서 네트워크 (USN)에 대한 관심이 높아지고 있다. 유비쿼터스 센서 네트워크란 센싱 기술을 초소형 무선장치에 접목하여 이들 간의 네트워킹과 통신으로써 실시간으로 정보를 획득, 처리, 활용함으로써, 사물의 이력정보뿐만 아니라 사물을 둘러싸고 변화하는 물리 환경계의 다양한 정보를 획득하여 생산성, 안전성 및 인간 생활수준의 고도화를 실현하는 것이다.

이하, 도 1 및 도 2를 참조하여 종래기술에 의한 유비쿼터스 센서 네트워크의 아키텍처를 설명한다.

CMU(Carnegie Mellon Univ.)에서 연구된 'IrisNet' 아키텍처는 이미지 프로세싱 기반의 콘텍스트 인지(Context Awareness) 아키텍처를 제시하는 것이며, 센서로는 웹캠을, 콘텍스트 처리를 위해서는 상당한 컴퓨팅 파워 및 저장공간을 가지는 PC를 사용하고 있다.

도 1을 참조하면, 'IrisNet' 아키텍처는 크게 웹캠등의 센서로부터 센싱된 정보를 획득하여 이미지 프로세싱과 데이터 필터링 등의 기능을 하는 센싱 에이전트(Sensing Agent; SA)와, SA로부터 입력되는 정보를 수신하여 데이터 통합과 캐싱 등의 기능을 하는 구성 에이전트(Organizing Agent; OA)로 구성되어 있다.

그러나, 'IrisNet'은 센싱된 정보를 처리하기 위해서 웹캠 등의 많은 정보를 생성하는 센서(Resource Rich Sensor) 및 PC나 PDA등 고사양의 장비를 요구하고 있기 때문에, USN을 인프라스트럭처(Infrastructure)의 관점으로 보는 경우에는 경제성 측면에서 적합하지 않다.

UIUC (Univ. of Illinois at Urbana Champaign)에서 진행하고 있는 'Gaia' 프로젝트는 유비쿼터스 컴퓨팅 환경을 위한 미들웨어 기능을 제공하는 것이다. 도 2에 도시된 바와 같이 'Gaia' 콘텍스트 인프라스트럭처는 크게 콘텍스트 제공자(Context Provider), 콘텍스트 합성자(Context Synthesizer), 콘텍스트 소비자(Context Consumer) 및 부가 기능을 제공하기 위한 다른 모듈들로 구성된다.

콘텍스트 제공자(100a,100b,100c)는 다양한 종류의 콘텍스트를 감지해 제공하고, 다른 에이전트가 엑세스 할 수 있는 기능을 제공한다. 콘텍스트 합성자(102)는 기초적인 콘텍스트를 상위 콘텍스트로 변환해 제공하는 역할을 담당한다. 콘텍스트 소비자(104a,104b)는 제공된 콘텍스트를 이용해 자신의 타스크를 수행하는 어플리케이션 역할을 한다.

그러나 'Gaia'는 콘텍스트 인지 어플리케이션 개발을 위한 아키텍처를 제공하고 있지만, 그 목적이 유비쿼터스 컴퓨팅의 시스템 관점으로만 접근한 것이어서 비즈니스 어플리케이션과의 연계는 고려하지 않았다.

요컨대, 이러한 유비쿼터스 센서 네트워크에 대한 기존의 아키텍처들은 콘텍스트 인지(context awareness) 측면에서만 접근하였기 때문에, 특정 하드웨어 또는 소프트웨어에 의존하는 레거시(legacy) 비지니스 시스템에도 쉽게 연계될 수 있는 그런 아키텍처가 필요했다.

즉, 기존의 유비쿼터스 센서 네트워크를 위한 소프트웨어 아키텍처는 콘텍스트인지의 기능적인 부분에만 치중했고, 기존의 비즈니스 소프트웨어와의 통합은 염두에 두지 않았다는 문제가 있었다.

본 발명은 상기한 점을 감안하여 발명된 것으로, 유비쿼터스 센서 네트워크의 소프트웨어 아키텍처를 새로이 정의함으로써 기존의 비지니스 소프트웨어와의 연계 및 통합이 가능한 소프트웨어 아키텍처 및 그 소프트웨어 아키텍처에서 수행되는 이벤트 요구 및 응답 방법을 제공함에 그 목적이 있다.

상기 목적을 달성하기 위한 본 발명은, 유비쿼터스 센서 네트워크를 위한 소프트웨어 아키텍처에 있어서, 데이터를 센싱하는 복수개의 센서들로 이루어진 센서필드, 센서필드로부터 센싱된 데이터를 게이트웨이를 통해 수신하여, 저장 및 관리하는 말단 UIM, 말단 UIM으로부터 수신한 데이터를 콘텍스트 인지 기능으로 추상화하여 어플리케이션에 적합한 정보로 변환 및 저장하는 내부 UIM 및, 내부 UIM으로 부터 수신한 정보를 이용하여 소정 서비스를 제공하는 어플리케이션을 포함하는 것을 특징으로 한다.

이때, 말단 UIM과 내부 UIM은, 데이터를 저장하는 정보저장부, 상위 계층으로부터 이벤트 요구가 들어왔을 때 이벤트 조건을 분석하여 관련된 하위 계층을 연결시켜 주는 이벤트 관리블록, 하위 계층으로부터 들어오는 이벤트 응답을 처리하는 이벤트 처리블록 및, 정보저장부에 저장된 데이터에 대해 상위 계층으로부터 요청이 있을 때 이에 응답하는 질문 처리블록을 구비하는 정보제어부 및, 메시지 큐를 이용한 신뢰할 수 있는 메시징 기능을 제공하고, 서비스 통합을 위한 인터페이스를 제공하는 정보버스를 포함하는 것이 바람직하다.

여기서 정보제어부는, 말단 UIM으로부터 수신한 데이터를 기초로 해서 추상화된 콘텍스트를 도출하고, 플러거블한 특성을 갖는 콘텍스트 인지블록을 더 포함하는 것이 바람직하고, 정보버스는 서비스 지향 아키텍처(SOA) 기반의 ESB인 것이 바람직하다.

상기 목적을 달성하기 위한 본 발명은, 정보저장부, 정보제어부 및, 정보버스로 이루어지는 말단 UIM과 내부 UIM, 센서필드, 어플리케이션을 포함하는 소프트웨어 아키텍처에서 수행되는 이벤트 요구 및 응답 방법에 있어서, (a) 어플리케이션이 내부 UIM에게 이벤트 요구를 보내는 단계, (b) 내부 UIM이 이벤트 조건을 저장하고, 요청 받은 이벤트와 연관된 말단 UIM에게 이벤트 요구를 보내는 단계, (c) 이벤트 요구에서 설정된 조건이 만족될 때 말단 UIM에서 내부 UIM으로 이벤트 응답을 보내는 단계 및, (d) 내부 UIM에서 어플리케이션으로 이벤트 응답을 보내는 단 계를 포함하는 것을 특징으로 한다.

이때, 상기 (b) 단계는, 내부 UIM의 정보버스가 어플리케이션으로부터 받은 이벤트 요구를 내부 UIM의 정보제어부로 보내는 단계, 정보제어부는 이벤트 요구를 분석하여 어느 말단 UIM으로 이벤트 요구를 보내야 하는지를 결정하고, 선정된 말단 UIM으로 보낼 이벤트 요구를 생성하는 단계, 내부 UIM의 정보제어부는 이벤트 요구를 내부 UIM의 정보버스로 보내고, 말단 UIM으로 이벤트 요구를 보낼 것을 요청하는 단계, 내부 UIM의 정보버스가 말단 UIM의 정보버스로 이벤트 요구를 보내는 단계, 말단 UIM의 정보버스가 내부 UIM의 정보버스로부터 받은 이벤트 요구를 말단 UIM의 정보제어부로 전달하는 단계 및, 말단 UIM 정보제어부는 전달 받은 이벤트 요구를 기초로 하여, 센싱된 데이터에 대해 이벤트 조건을 검사하는 단계를 포함하는 것이 바람직하다.

그리고, 상기 (c) 단계는, 말단 UIM의 정보버스가 센싱된 데이터를 말단 UIM의 정보제어부에 전달하는 단계, 말단 UIM의 정보제어부는 전달받은 센싱된 데이터가 이벤트 요구를 받았을 때 설정된 조건을 만족하는지 검사하는 단계, 센싱된 데이터가 이벤트 조건을 만족시키는 경우에는, 말단 UIM의 정보제어부는 이벤트 응답 메시지를 생성하여 말단 UIM의 정보버스로 전달하는 단계, 말단 UIM의 정보버스로 데이터가 전달되면, 센싱된 데이터를 말단 UIM의 정보저장부에 저장하는 단계 및, 이벤트 응답 메시지가 말단 UIM의 정보버스에서 내부 UIM의 정보버스로 전송되는 단계를 포함하는 것이 바람직하다.

또한, 상기 (d) 단계는, 말단 UIM의 정보버스로부터 이벤트 응답 메시지를 받은 내부 UIM의 정보버스는 내부 UIM의 정보제어부로 이벤트 응답을 전달하는 단계, 내부 UIM의 정보제어부는 이벤트 응답을 기반으로 어플리케이션에서 요구한 이벤트 조건을 만족시키는지 검사하는 단계, 이벤트 조건을 만족시키는 경우, 내부 UIM의 정보제어부는 이벤트의 발생을 어플리케이션에게 알리기 위한 이벤트 응답을 생성하고, 내부 UIM의 정보버스로 보내는 단계, 이벤트 조건 검사를 마친 후 말단 UIM으로부터 받은 데이터를 내부 UIM의 정보저장부에 저장하는 단계 및, 내부 UIM의 정보버스가 어플리케이션에게 이벤트 응답을 전송하는 단계를 포함하는 것이 바람직하다.

본 발명은 유비쿼터스 센서 네트워크를 비지니스 환경에 쉽게 연계 할 수 있는 서비스 지향 아키텍처(Service Oriented Architecture;SOA) 기반의 웹서비스를 이용한 새로운 소프트웨어 아키텍처를 제공한다. 유비쿼터스 센서 네트워크는 유비쿼터스 컴퓨팅에서 기존의 아키텍처들의 주요 포커스인 콘텍스트 인지라는 것이 중요한데, 이 콘텍스트 인지란 어떠한 콘텍스트을 인지하여 사람이 뭘 원하는지 알아내서 그 사람에게 알맞은 정보를 제공하는 것이다. 이전의 아키텍처들은 이 콘텍스트 인지 측면에서만 접근했다. 그러나 본 발명은 이런 기능은 유지하면서 웹서비스 기술을 도입하여 센싱된 정보가 기존의 비지니스 어플리케이션에도 활용될 수 있는 아키텍처를 제시하는 것이다.

이하, 첨부된 도면을 참조하여 본 발명에 따른 바람직한 실시예를 상세하게 설명하기로 한다. 그러나, 이하의 실시예는 이 기술분야에서 통상적인 지식을 가진 자에게 본 발명이 충분히 이해되도록 제공되는 것으로서 여러 가지 다른 형태로 변형될 수 있으며, 본 발명의 범위가 다음에 기술되는 실시예에 한정되는 것은 아니다.

(실시예)

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

도 3에 도시된 바와 같이, 본 발명의 바람직한 실시예에 따른 소프트웨어 아키텍처는 센서 필드(Sensor Field; 106a,106b,…,106n), 게이트웨이(Gateway; 108a,108b,…,108n), 유비쿼터스 정보 관리자(Ubiquitous Information Manager;UIM; 110a,110b,112), 어플리케이션(Application;114)으로 구성된다.

UIM은 정보를 발생시키는 센서노드와 정보를 이용해 서비스를 제공하는 어플리케이션 사이에서 미들웨어(middleware) 역할을 수행한다. UIM은 역할에 따라 말단(Edge) UIM(110a,110b)과 내부(Internal) UIM(112)로 구분되는데, 말단 UIM(110a,110b)는 센서노드(106a,106b,…,106n)로부터 데이터를 받아 이를 필터링, 저장 및 관리하고, 내부 UIM(112)은 말단 UIM(110a,110b)으로부터 전달받은 데이터를 콘텍스트 인지 기능으로 추상화하여 어플리케이션에 적합한 정보로 변환 및 저장하는 역할을 한다. 또한, 내부 UIM(112)은 이렇게 저장된 정보를 어플리케이션(114)에게 제공하는 역할도 담당한다.

도 4를 참조하면, UIM은 정보저장부(Information Repository;IR; 118), 정보제어부(Information Coordinator;IC; 116) 및, 정보버스(Information Bus;IB; 120)로 구성된다. 정보저장부(118)는 데이터를 저장하는 역할을 하고, 정보제어부(116)는 데이터의 처리 및 흐름을 제어하는 역할을 하며, 정보버스(120)는 신뢰할 수 있는 메시징(Reliable Messaging) 및 서비스 통합(Service integration)과 같은 ESB(Enterprise Service Bus) 역할을 한다. 신뢰할 수 있는 메시징이란 메시지를 전달함에 있어서 메시지의 유실이나 중복 전송이 없음을 보장하는 것을 말하고, 서비스 통합이란 서로 다른 비지니스 어플리케이션 사이에서 한 어플리케이션이 다른 어플리케이션에서 제공하는 기능을 쉽게 호출하여 그 결과를 자신의 어플리케이션에서 활용하는 기술을 말한다. ESB는 기업용 어플리케이션간에 서비스의 요청이나 그 결과물들이 흘러다니는 통로역할을 해주는 버스를 통칭한다.

이하, 도 4에 도시된 각 구성요소를 더욱 상세하게 설명한다.

먼저, 정보저장부(IR; 118)는 데이터를 저장하기 위한 저장공간인데, 저장되는 데이터는 말단 UIM과 내부 UIM에서 조금씩 다르다. 말단 UIM의 정보저장부는 센서필드에서 센싱된 데이터가 게이트웨이를 통해 들어오는 경우 이를 그대로 저장시킨다. 반면, 내부 UIM의 정보저장부는 주기적인 질문을 통해 말단 UIM으로부터 모은 데이터를 어플리케이션에서 요구하는 형태로 추상화 시켜서 생성된 콘텍스트 인지 정보를 저장한다.

산불감지 어플리케이션을 예를 들면, 각 지역의 온도, 습도, 풍향 등의 정보는 말단 UIM의 정보저장부에 저장되고, 이들 정보를 모아서 생성한 지역별 산불의 발생 여부 및 진행단계 등에 관한 정보는 내부 UIM의 정보저장부에 저장된다.

정보저장부(118)는 데이터베이스(DB)를 사용하여 구축되는데, XML DB나 관계형(Relational) DB를 사용할 수 있다. 관계형 DB를 사용하는 경우에는 XML 데이터를 관계형 DB에 맞는 구조로 변환하는 컨버터(Converter)가 필요하다.

다음으로, 정보제어부(IC; 116)는 UIM 내로 들어오는 각종 정보에 대해 조정자(Coordinator) 역할을 하는데, 정보제어부(116)의 기능으로는 이벤트 관리(Event Management), 이벤트 처리(Event Handling), 질문 처리(Query Processing), 콘텍스트 인지 등이 있다.

정보제어부(116)의 기능 중 이벤트 관리 기능은 상위 계층(Upper Layer)으로부터 이벤트 요구(Event Request)가 들어왔을 때, 이벤트 조건을 분석하여 이와 연관된 하위 계층(Lower Layer)을 연결시켜 주는 것이다. 즉, 도 3에 도시된 센서 필드에서 이벤트가 발생하는 경우, 어플리케이션 까지 그 정보가 전달되는 경로를 셋업하는 기능이라고 할 수 있다. 이에 대한 자세한 설명은 도 6을 참조하여 후술한다.

정보제어부(116)의 기능 중 이벤트 처리 기능은 하위 계층으로부터 이벤트 응답이 들어올 때, 이를 처리하는 것이다. 말단 UIM의 이벤트 처리부(Event Handler)는 게이트웨이로부터 받은 센싱 데이터에 대한 처리를 담당하고, 내부 UIM의 이벤트 처리부는 말단 UIM에서 들어온 이벤트 응답을 처리한다. 이와 관련된 상세한 설명은 도 7을 참조하여 후술한다.

정보제어부(116)의 기능 중 질문 처리 기능은 IR(118)에 저장된 데이터에 대 한 요청에 관해서 응답해주는 것이다. 어플리케이션(114)이 내부 UIM(112)에 질문 요구를 전송하여 데이터를 요청하면, 내부 UIM(112)의 IC(116)는 IR(118)을 검색하여 요청된 데이터를 어플리케이션(114)으로 전송하게 된다. 내부 UIM(112)의 IC(116)는 미리 정해 놓은 시간간격으로 말단 UIM(110)에 주기적으로 질문 요구를 보내고, 말단 UIM으로부터 받은 응답은 IR에 저장한다.

정보제어부(116)의 기능 중 콘텍스트 인지 기능은 센서로부터 읽어 들인 다양한 값들을 기반으로 해서 보다 추상화된 콘텍스트를 도출하는 것이다. 예를 들면, 산불관리 어플리케이션에서 온도, 습도, 풍향등의 센싱 값의 변화를 감지하여 산불발생 단계라는 추상화된 콘텍스트를 도출하는 것이 바로 콘텍스트 인지이다. 콘텍스트 인지의 핵심은 센싱 데이터를 어플리케이션에서 활용할 수 있는 데이터로 변환하는 알고리즘으로서, 어플리케이션에 따라서 각각 다른 알고리즘을 가지고 있다. 이러한 다양성을 고려하여 콘텍스트 인지 기능은 플러거블(Pluggable)하도록 설계되어 있다. 따라서, 다른 소스코드의 수정없이 새롭게 만든 콘텍스트 인지 기능을 추가할 수 있다. 즉, 정보제어부는 미리 정의된 인터페이스만을 호출하고, 이를 통해서 호출되는 콘텍스트 인지 기능은 이러한 인터페이스를 지원하도록 하여 어플리케이션의 변경에 유연하게 대처할 수 있도록 해준다.

마지막으로, 정보버스(IB; 120)에 대해 설명하면, 정보버스는 UIM이 외부와의 연결을 위한 통로이다. 정보버스(120)는 ESB를 채택하여 ESB의 주요 기능인 신뢰할만한 메시징 기능을 제공하고, 데이터 통합(Data Integration) 및 서비스 통합(Service Integration)을 가능케 하는 표준 인터페이스를 제공한다. 정보버스가 제 공하는 이러한 기능들은 비지니스 어플리케이션과의 연계를 쉽게 한다.

ESB의 기능 중, 정보버스에서 제공하고 있는 것은 두 가지인데, 첫째는 메시지 큐(message queue)를 이용한 신뢰할만한 메시징(reliable messaging) 기능이고, 둘째는 WSDL과 SOAP을 이용한 서비스 통합 기능이다.

신뢰할만한 메시징 기능은 하나의 메시지가 중복이 없이 단 한번, 그리고 반드시 전송이 되는 것을 보장한다. 하부 계층에서 보내는 이벤트 메시지는 어플리케이션에 미치는 영향이 크기 때문에 신뢰할 수 있게 전송되는 것이 중요하다. 현재, 정보버스(IB)에서는 자바 메시지 서비스(Java Message Service;JMS)를 활용한 메시지 큐로 신뢰할만한 메시징 기능을 구현하고 있다. 그리고, IB는 WSDL과 SOAP을 사용하여 서비스 통합 기능을 제공한다. 어플리케이션은 UDDI(Universal Description, Discovery, and Integration)에 등록된 서비스를 이용할 수 있다. UDDI등록된 서비스는 WSDL형식으로 기술되어 있으며 여기에 나온 인터페이스와 SOAP을 이용하여 서비스 요청을 할 수 있다.

이하에서는, 도 5~도 8을 참조하여 UIM의 이벤트 및 질문 데이터 플로우를 설명한다. UIM에서 데이터 플로우는 크게 두 가지 경우를 생각해 볼 수 있다. 하나는 주어진 조건에 맞는 데이터 발생시 비동기방식으로 전송하는 이벤트 정보에 대한 플로우이고, 다른 하나는 데이터 요청에 대한 응답을 동기방식으로 전송하는 질문에 대한 플로우이다.

도 5는 UIM의 이벤트 데이터 플로우를 보여준다.

도 5에 도시된 바와 같이, 어플리케이션(114)이 내부 UIM(112)에게 이벤트 요구를 보내면, 내부 UIM(112)은 이벤트 조건(condition)을 저장하고 요청 받은 이벤트와 연관된 말단 UIM(110)에게 이벤트 요구를 전송한다.

이벤트 응답은 이벤트 요구에서 설정된 조건이 만족될 때 말단 UIM(110)에서 내부 UIM(112)으로, 내부 UIM(112)에서 어플리케이션(114)으로 전송되는 응답 메시지로서, 요구를 보낼 때 바로 응답되는 것이 아니라 실제 이벤트가 발생했을 때 전송된다.

도 6에 도시된 플로우는 어플리케이션으로부터 전송된 이벤트 요구가 어떤 과정을 거쳐 말단 UIM에 까지 내려 오는지를 보여준다. 또한, 이벤트 조건이 내부 UIM과 말단 UIM에 설정되는 과정도 보여준다.

먼저, 이벤트 요구가 어플리케이션으로부터 내부 UIM(112)의 IB를 통해서 들어온다(122). 이벤트 요구는 웹서비스 형태로 호출이 된다.

이어서, 내부 UIM(112)의 IB는 어플리케이션으로부터 받은 이벤트 요구를 내부 UIM의 IC로 넘겨준다(124). 그러면, IC에서는 이벤트 요구를 분석하여 어느 말단 UIM으로 이벤트 요구를 보내야 하는지를 결정하고, 선정된 말단 UIM으로 보낼 이벤트 요구를 만든다.

이어서, 내부 UIM의 IC는 작성된 이벤트 요구를 다시 내부 UIM의 IB로 보내 어, 말단 UIM으로 이벤트 요구를 보낼 것을 요청한다(126).

이어서, 내부 UIM(112)의 IB는 말단 UIM(110)의 IB로 이벤트 요구를 보낸다(128).

그러면, 말단 UIM(110)의 IB는 내부 UIM(112)의 IB로부터 받은 이벤트 요구를 말단 UIM의 IC로 전달한다(130). IC는 전달 받은 이벤트 요구를 기반으로 어느 게이트웨이에서 들어오는 데이터를 검사해야 할지를 결정하고, 미리 정의된 게이트웨이로부터 들어오는 센싱된 데이터에 대해 이벤트 조건을 검사하게 된다.

상술한 과정(122~130)을 거치면 어플리케이션에서 요청한 이벤트 요구에 대해 내부 UIM(112)과 말단 UIM(110)의 설정이 끝나게 된다.

도 7은 이벤트 응답과 관련된 데이터 플로우를 보여준다.

도 7에 도시된 플로우는 센서 필드로부터 들어온 데이터가 어떻게 처리되고 콘텍스트 인식 정보로 변환되어 어플리케이션에게 전달되는지를 보여준다.

먼저, 게이트웨이는 센싱된 데이터를 말단 UIM(110)의 IB로 보낸다(132).

이어서, 말단 UIM의 IB는 센싱된 데이터를 말단 UIM의 IC에 전달한다(134). 이때, 데이터의 전달은 말단 UIM의 IC가 등록해 놓은 이벤트 처리 기능을 사용해서 이루어진다. 말단 UIM의 IC는 전달받은 센싱된 데이터가 이벤트 요구를 받았을 때 설정된 조건을 만족하는지 검사한다.

센싱된 데이터가 이벤트 조건을 만족시키는 경우에는, 이 데이터를 내부 UIM로 보내기 위해서 말단 UIM의 IC는 이벤트 응답 메시지를 만들어 말단 UIM의 IB로 전달한다(136).

말단 UIM의 IB로 데이터가 전달되면, 센싱된 데이터를 말단 UIM의 IR에 저장한다(138).

이어서, 이벤트 응답 메시지는 말단 UIM(110)의 IB에서 내부 UIM(112)의 IB로 전송된다(140).

이벤트 응답을 받은 내부 UIM의 IB는 내부 UIM의 IC의 이벤트 처리 기능을 통해 이벤트 응답을 전달한다(142).

내부 UIM의 IC는 어플리케이션이 보낸 이벤트 조건을 가지고 있으므로, 받은 이벤트 응답을 기반으로 어플리케이션에서 요구한 이벤트 조건을 만족시키는지 검사한다. 이벤트 조건을 만족시키는 경우 내부 UIM의 IC는 이벤트의 발생을 어플리케이션에게 알리기 위한 이벤트 응답을 생성하고, 이것을 내부 UIM의 IB에게 전송한다(144).

이벤트 조건 검사를 마친 후 말단 UIM으로부터 받은 데이터를 내부 UIM의 IR에 저장한다(146).

이어서, 내부 UIM의 IB는 어플리케이션에게 이벤트 응답을 전송한다(148).

도 8은 UIM의 질문 데이터 플로우를 보여준다.

도 8에 도시된 바와 같이, 어플리케이션(114)이 내부 UIM(112)에게 질문 요구를 보내면, 내부 UIM은 요청 받은 정보를 자신의 IR에서 검색하여 어플리케이션(114)에게 질문 응답을 보낸다. 만일, 정보를 찾을 수 없는 경우에는, 질문 응답에 에러 내역을 추가하여 질문 응답을 전송한다.

그런데, 내부 UIM(112)과 말단 UIM(110) 사이에서 일어나는 질문 요구와 응답은 이벤트의 경우와는 다르다. 즉, 이벤트의 경우에는 어플리케이션에서 요청한 내용이 내부 UIM과 말단 UIM까지 전달되지만, 질문의 경우 어플리케이션에서 내부 UIM에 요청한 질문은 말단 UIM까지 전달되지 않는다. 내부 UIM에서는 미리 정의된 시간 간격으로 말단 UIM에 데이터에 대한 질문 요구를 하고, 바로 응답을 받는다. 그러면 내부 UIM은 전송받은 데이터를 어플리케이션에 서비스할 수 있는 형태로 변환하여, 내부 UIM의 IR에 저장한다. 여기에 저장된 정보는 나중에 어플리케이션에서 질문 요구가 들어올 때 검색 대상이 된다.

이상 설명한 바와 같은 본 발명은 산불 감지 및 감시, 환경 감시, 재난 방지, 교통 감시 및 예측, 의료 등의 시스템에 적용될 수 있다. 즉, 본 발명을 이용하면, 센서들로부터 데이터를 모아, 그 데이터에서 어떤 추론적인 결론을 내림으로써, 사용자에게 필요한 정보를 제공해주거나 편리를 제공할 수 있다. 이러한 시스템 이외에도 센서를 사용하여 추론적인 정보나 해답을 얻어야 하는 그런 시스템이라면 얼마든지 적용될 수 있다.

이하에서는, 본 발명에 의한 유비쿼터스 센서 네트워크를 위한 소프트웨어 아키텍처가 산불 감시 시스템에 적용된 예를 설명한다.

구현된 산불 감시 시스템은 산불 조기 경보 시스템으로서, 관할영역에 산불 의 발생 여부를 감시자에게 알려주는 것이다. 감시자는 해당 지역에 대해 상세 검색 기능을 사용하여 산불이 발생한 지역이나 발생할 지역을 자세히 감시하고 관련된 조치를 취한다.

산불 감시 시스템에서는 산불의 진행단계를 4 단계로 구분한다. 4가지 단계는 'normal', 'low-alert', 'high-alert', 'on-fire'이다. 'High-alert' 단계는 주변에 산불이 발생했거나 산불 발생 가능성이 높은 단계이다. 'Low-alert' 단계는 산불 발생 가능성이 낮은 단계이다. 캠프 파이어나 소각장 등과 같은 다른 요소들이 특정 지역의 온도나 습도에 영향을 미칠 수 있으므로, 실제 산불 여부를 판단하기 위해서는 부가적인 정보가 필요하다.

도 9는 산불 감시 시스템 화면을 표시한 것이다. 도 9의 (a)는 관할영역 전체보기를 나타낸 것이고, 도 9의 (b)는 자세히 보기 화면을 나타낸 것이다. 관할영역 전체보기는 내부 UIM에서 보낸 이벤트에 의해 업데이트 되며, 자세히 보기는 질문 요구와 응답에 의해 업데이트 된다.

특정 셀(Cell)에 대한 정보를 보는 화면이 도 9의 (b)로 도시된 자세히 보기 화면인데, 셀 ID번호, 셀의 위치정보(location의 Position[TL]은 셀의 상단 왼쪽의 위치를 나타내는 것이고, Position[BR]은 하단 오른쪽의 위치를 나타내는 것이다), 산불 가능성등을 나타낸다.

감시자가 특정 센서 노드(도 9의 (b)에서 파란 점이나 빨간 점)를 지정하면 센서 정보가 나타난다. 여기서 빨간 점은 산불 단계를 알려온 센서들을 나타내고, 파란 점은 정상단계의 센서 정보를 나타낸다.

이러한 산불 감시 시스템은 자바(Java) 프로그래밍 언어로 구현되었고, 오픈 소스 소프트웨어(open source software)를 사용하여 운영된다. 말단 UIM에 있는 IR로는 'Berkeley DB XML'이 사용되었고, 내부 UIM의 IR로는 'MySQL'이 사용되었다. 웹 서버로는 'Tomcat'이 사용되었으며, 'JMS engine'으로 'ActiveMQ'가 사용되었다. ESB 기능으로 'Mule'이 사용되었다.

게이트웨이, 말단 UIM, 내부 UIM으로는 'Intel Pentium4 1.70 GHz' 서버가 사용되었고, OS로는 'Red Hat Enterprise Linux Update2'가 사용되었다. 어플리케이션은 같은 기기에 'Windows XP OS'를 사용하였다.

상기와 같은 산불 감시 시스템에서 UIM 계층은 다음과 같이 동작한다.

먼저, 게이트웨이에 대해 설명하면, 산불 감시 시스템에서는 센서들이 게이트웨이로 온도, 습도, 위치정보를 2.5초 간격으로 보내는 것으로 가정한다. 본 구현에서 센서들은 센서 데이터 생성기를 사용하여 시뮬레이션 되었다. 게이트웨이는 센서 데이터를 모아서 SNML(Sensor Network Markup Language) 형태로 기록하고, 이를 말단 UIM으로 전송한다.

말단 UIM에 대해 설명하면, 말단 UIM의 IC는 게이트웨이로부터 받은 센서 데이터 정보인 id, 시간정보, 위치 정보, 온도값, 습도값등을 그대로 말단 UIM의 IR에 저장한다. 그리고, 말단 UIM은 내부 UIM으로부터 미리 설정된 이벤트 조건에 따라서 센서 데이터가 조건을 만족시키는지 검사한다. 마지막으로, 필요한 경우, 말단 UIM은 내부 UIM에 응답을 보낸다. 예를 들면, 온도 변화가 그날의 평균온도보다 2℃~10℃ 이상이거나, 습도 변화가 그날의 평균습도보다 5%~10% 이하인 데이터가 발생하는 경우에는, 말단 UIM은 내부 UIM으로 해당 데이터를 전송한다. 또한, 말단 UIM은 내부 UIM으로부터 주기적으로 오는 질문 요구에 대해서 질문 응답을 생성하여 내부 UIM에 되돌려 준다. 이때 전송되는 데이터는 이벤트 응답에서 전송되는 데이터와 동일하다.

내부 UIM은 말단 UIM에서 올라온 온도와 습도 데이터를 토대로 해서 산불의 단계를 판단한다. 관심영역의 산불단계가 'low-alert', 'high-alert', 'on-fire'인 경우, 내부 UIM은 이벤트 응답을 어플리케이션에게 보낸다. 산불 감시 시스템은 온도와 습도값의 실험 결과를 참조하여 산불의 발생 가능성을 판단한다. 이러한 발생가능성 정보를 이용하여 산불 발생 4가지 단계를 결정하기 위한 가능성 범위가 생성된다. 'low-alert'나 'high-alert' 상태를 판단하기 위해서는, 관할 영역 주변에 대한 부가 정보도 필요하다. 어플리케이션으로부터 질문 요구가 들어오면, 적절한 데이터가 질문 응답으로 보내어 진다.

어플리케이션은 내부 UIM으로부터 받은 질문 및 이벤트 데이터를 시스템의 화면에 각 단계별로 무색(normal), 노랑(low-alert), 오렌지(high-alert), 빨강(on-fire)으로 표시해준다. 산불 감시 시스템의 사용자는 산불 가능성과, 관심영역을 자세히 보기 위해서 자세히 보기 기능을 이용할 수 있다. 확인 후, 사용자는 소방수들을 그 지역에 보낼지를 결정하게 된다.

상기한 바와 같이 본 발명에 의하면, 임의의 센서 네트워크에도 적용될 수 있는 서비스 지향 아키텍처에 기반을 둔 소프트웨어 아키텍처를 제공하므로, 기존의 비지니스 환경에 유연성 있게 연계할 수 있는 효과가 있다.

이는 본 발명이 계층화 아키텍처(센싱 데이터, 추상화된 데이터)를 채택하기 때문인데, 즉 말단 UIM과 내부 UIM으로 나누어져 있다. 따라서, 센서 필드에서 생성된 원시 데이터를 이용하길 원한다면 손쉽게 그 데이터를 말단 UIM에서 제공할 수 있고, 또한 임의의 콘텍스트 인지에 대한 알고리즘 교체를 용이하게 할 수 있다. 이러한 아키텍처는 서비스 지향 아키텍처 기반의 ESB(enterprise service bus)를 채택하기 때문에, 안정적인 데이터 전달, 보안 및 통합이 가능하다. 본 발명은 이러한 웹서비스로 표준화된 인터페이스를 지원하고, 이 인터페이스를 통해 데이터에 접근이 가능하기 때문에 비지니스 통합이 쉬워지는 장점이 있다.

이상, 본 발명의 바람직한 실시예를 들어 상세하게 설명하였으나, 본 발명은 상기 실시예에 한정되는 것은 아니며, 본 발명의 기술적 사상의 범위내에서 당 분야에서 통상의 지식을 가진 자에 의하여 여러 가지 변형이 가능하다.

Claims

유비쿼터스 센서 네트워크를 위한 소프트웨어 아키텍처에 있어서,

데이터를 센싱하는 복수개의 센서들로 이루어진 센서필드;

상기 센서필드로부터 센싱된 데이터를 게이트웨이를 통해 수신하여, 저장 및 관리하는 말단 UIM;

상기 말단 UIM으로부터 수신한 데이터를 콘텍스트 인지 기능으로 추상화하여 어플리케이션에 적합한 정보로 변환 및 저장하는 내부 UIM 및;

상기 내부 UIM으로부터 수신한 정보를 이용하여 소정 서비스를 제공하는 어플리케이션을 포함하는 것을 특징으로 하는 소프트웨어 아키텍처.
제1항에 있어서, 상기 말단 UIM과 내부 UIM은,

데이터를 저장하는 정보저장부;

상위 계층으로부터 이벤트 요구가 들어왔을 때 이벤트 조건을 분석하여 관련된 하위 계층을 연결시켜 주는 이벤트 관리블록, 하위 계층으로부터 들어오는 이벤트 응답을 처리하는 이벤트 처리블록 및, 상기 정보저장부에 저장된 데이터에 대해 상위 계층으로부터 요청이 있을 때 이에 응답하는 질문 처리블록을 구비하는 정보제어부 및;

메시지 큐를 이용한 신뢰할 수 있는 메시징 기능을 제공하고, 서비스 통합을 위한 인터페이스를 제공하는 정보버스를 포함하는 것을 특징으로 하는 소프트웨어 아키텍처.
제2항에 있어서,

상기 정보저장부는 XML 데이터베이스 또는 관계형 데이터베이스를 이용하여 구현되는 되는 것을 특징으로 하는 소프트웨어 아키텍처.
제2항에 있어서, 상기 질문 처리블록에 있어서,

내부 UIM의 정보제어부가 미리 정해 놓은 시간간격으로 말단 UIM에 주기적으로 질문 요구를 보내고, 말단 UIM으로부터 받은 응답이 정보저장부에 저장되는 것을 특징으로 하는 소프트웨어 아키텍처.
제2항에 있어서, 상기 정보제어부는,

상기 말단 UIM으로부터 수신한 데이터를 기초로 해서 추상화된 콘텍스트를 도출하고, 플러거블한 특성을 갖는 콘텍스트 인지블록을 더 포함하는 것을 특징으로 하는 소프트웨어 아키텍처.
제2항에 있어서, 상기 정보버스는,

서비스 지향 아키텍처(SOA) 기반의 ESB인 것을 특징으로 하는 소프트웨어 아키텍처.
정보저장부, 정보제어부 및, 정보버스로 이루어지는 말단 UIM과 내부 UIM, 센서필드, 어플리케이션을 포함하는 소프트웨어 아키텍처에서 수행되는 이벤트 요구 및 응답 방법에 있어서,

(a) 상기 어플리케이션이 상기 내부 UIM에게 이벤트 요구를 보내는 단계;

(b) 상기 내부 UIM이 이벤트 조건을 저장하고, 요청 받은 이벤트와 연관된 말단 UIM에게 이벤트 요구를 보내는 단계;

(c) 이벤트 요구에서 설정된 조건이 만족될 때 말단 UIM에서 내부 UIM으로 이벤트 응답을 보내는 단계 및;

(d) 내부 UIM에서 어플리케이션으로 이벤트 응답을 보내는 단계를 포함하는 것을 특징으로 하는 이벤트 요구 및 응답 방법.
제7항에 있어서, 상기 (b) 단계는,

상기 내부 UIM의 정보버스가 상기 어플리케이션으로부터 받은 이벤트 요구를 내부 UIM의 정보제어부로 보내는 단계;

상기 정보제어부는 이벤트 요구를 분석하여 어느 말단 UIM으로 이벤트 요구를 보내야 하는지를 결정하고, 선정된 말단 UIM으로 보낼 이벤트 요구를 생성하는 단계;

상기 내부 UIM의 정보제어부는 이벤트 요구를 내부 UIM의 정보버스로 보내고, 말단 UIM으로 이벤트 요구를 보낼 것을 요청하는 단계;

상기 내부 UIM의 정보버스가 말단 UIM의 정보버스로 이벤트 요구를 보내는 단계;

상기 말단 UIM의 정보버스가 내부 UIM의 정보버스로부터 받은 이벤트 요구를 말단 UIM의 정보제어부로 전달하는 단계 및;

상기 말단 UIM 정보제어부는 전달 받은 이벤트 요구를 기초로 하여, 센싱된 데이터에 대해 이벤트 조건을 검사하는 단계를 포함하는 것을 특징으로 하는 이벤트 요구 및 응답 방법.
제7항에 있어서, 상기 (c) 단계는,

상기 말단 UIM의 정보버스가 센싱된 데이터를 말단 UIM의 정보제어부에 전달하는 단계;

상기 말단 UIM의 정보제어부는 전달받은 센싱된 데이터가 이벤트 요구를 받았을 때 설정된 조건을 만족하는지 검사하는 단계;

센싱된 데이터가 이벤트 조건을 만족시키는 경우에는, 상기 말단 UIM의 정보제어부는 이벤트 응답 메시지를 생성하여 말단 UIM의 정보버스로 전달하는 단계;

상기 말단 UIM의 정보버스로 데이터가 전달되면, 센싱된 데이터를 말단 UIM의 정보저장부에 저장하는 단계 및;

이벤트 응답 메시지가 상기 말단 UIM의 정보버스에서 내부 UIM의 정보버스로 전송되는 단계를 포함하는 것을 특징으로 하는 이벤트 요구 및 응답 방법.
제7항에 있어서, 상기 (d) 단계는,

상기 말단 UIM의 정보버스로부터 이벤트 응답 메시지를 받은 내부 UIM의 정보버스는 내부 UIM의 정보제어부로 이벤트 응답을 전달하는 단계;

상기 내부 UIM의 정보제어부는 이벤트 응답을 기반으로 상기 어플리케이션에서 요구한 이벤트 조건을 만족시키는지 검사하는 단계;

이벤트 조건을 만족시키는 경우, 내부 UIM의 정보제어부는 이벤트의 발생을 어플리케이션에게 알리기 위한 이벤트 응답을 생성하고, 내부 UIM의 정보버스로 보내는 단계;

이벤트 조건 검사를 마친 후 말단 UIM으로부터 받은 데이터를 내부 UIM의 정보저장부에 저장하는 단계 및;

상기 내부 UIM의 정보버스가 어플리케이션에게 이벤트 응답을 전송하는 단계를 포함하는 것을 특징으로 하는 이벤트 요구 및 응답 방법.
제1항 내지 제6항에 기재된 소프트웨어 아키텍처에 의해 구현된 산불 감시 시스템.