KR102519701B1

KR102519701B1 - 다양한 프로토콜을 갖는 IoT 디바이스와의 호환성을 제공하는 IoT 게이트웨이 및 그 제어 방법

Info

Publication number: KR102519701B1
Application number: KR1020220110027A
Authority: KR
Inventors: 강세범; 정성기; 이재진
Original assignee: 주식회사 융창
Priority date: 2022-08-31
Filing date: 2022-08-31
Publication date: 2023-04-13
Also published as: WO2024049011A1

Abstract

본 발명은 다양한 프로토콜을 갖는 IoT 디바이스와의 호환성을 제공하는 IoT 게이트웨이에 관한 것으로, 일 실시예에서, 제1 IoT 디바이스로부터 수신한 메시지에 기초하여 상기 제1 IoT 디바이스의 타입(Type) 및 사용하는 프로토콜을 확인하고, OCF 프레임워크 기반의 가상의 리소스 모델 객체의 생성 및 상기 수신된 메시지의 OCF 기반 프로토콜로의 변환을 수행하는 프로토콜 변환부, 상기 생성된 리소스 모델 객체에 디바이스 ID를 부여하고 상기 OCF 기반 프로토콜로 변환된 상기 수신된 메시지와 매핑하는 디바이스 관리부 및 상기 생성된 리소스 모델 객체를 OCF 기반 프로토콜을 이용하여 통합제어서버로 전송하는 제어 관리부를 포함하는 IoT 게이트웨이를 개시한다.

Description

다양한 프로토콜을 갖는 IoT 디바이스와의 호환성을 제공하는 IoT 게이트웨이 및 그 제어 방법 {IoT gateway for providing compatibility with IoT devices with various protocols and a method therefor}

본 발명은 다양한 프로토콜을 갖는 IoT 디바이스와의 호환성을 제공하는 IoT 게이트웨이 및 그 제어 방법에 관한 것으로, 보다 상세하게는 다양한 제조사에 의해 다양한 종류의 프로토콜을 사용하는 IoT 디바이스와 연동하기 위해 발생하는 개발리소스를 표준 플랫폼인 OCF 방식으로 변환하여 다양한 IoT 디바이스와의 호환성을 제공하고 개발 리소스를 줄이고 다양한 편의를 제공할 수 있으며, IoT 디바이스간의 해킹에 대한 위험요소를 탐지 및 차단하여 보안에 안전한 환경을 제공하는 IoT 게이트웨이 및 그 제어방법에 관한 것이다.

사물인터넷(IoT, Internet of Things)은 주변 사물들이 유무선 네트워크로 유기적으로 서로 연결되어, 정보를 수집, 가공, 공유 등을 함으로써, 원하는 서비스를 수행하는 기술을 의미할 수 있다.

초기에는 IoT를 환경 정보 센싱과 센싱한 정보에 대한 통신 및 네트워크 관점에서 보는 경향이 많았지만, 최근에는 웹 서비스 개념을 디바이스로 확장하는 WoT(Web of Things) 개념, 모든 오브젝트까지 사물 대상을 확대하는 IoE(Internet of Everything) 개념 등으로 확장되고 있다.

한편, IoT의 원래 목적인 초연결성을 실현한 IoT 응용 서비스 중 하나로서 스마트 시티(Smart City)가 있다. 스마트 시티는 IT 기술과 네트워크 접속을 통하여 도시 데이터를 확보하고 이를 바탕으로 도시 자원을 효율적으로 사용하고 재분배함으로써 궁극적으로 도시 내 시민의 삶을 더욱 풍요롭고 편리하게 하는데 그 목적이 있다.

이를 위해서는 도시 곳곳에 네트워크 환경을 조성하고 문화시설, 주택, 도로, 기업 등 각종 기반 시설에 센서를 구비한 IoT 장치들을 장착하여 센싱되는 데이터를 수집하고 이에 기초하여 도시의 정보를 통합적으로 관리하고 운영할 수 있다.

또한, IoT 응용 서비스 중 다른 하나로는 스마트 홈(Smart Home)을 들 수가 있는데, 스마트 홈은 IoT 디바이스가 수집한 데이터들에 기반하여 현재 상황을 인지하고, 이것을 분석하여 사용자 생활패턴에 맞게 데이터를 가공함으로써 사용자 맞춤형 서비스를 제공할 수 있다.

스마트 시티 또는 스마트 홈과 같은 IoT 응용 서비스를 제공하기 위해서는 필요한 데이터를 수집하기 위한 센서를 구비하고 네트워크를 통해 통신할 수 있는 IoT 장치, 다수의 IoT 장치와 통신하며 데이터를 수집하고 가공하여 사용자에게 서비스를 제공하기 위한 게이트웨이 및 서버 등이 필요하다. 또한, 다수의 IoT 장치가 한곳으로 통합 집중되기 때문에 연결되는 네트워크와 IoT 장치에 대한 보안 요소 또한 동반되어야 한다.

이처럼 다양한 IoT 응용 서비스를 제공하기 위해 여러 종류의 IoT 장치들이 수많은 제조사를 통해 생산되고 있으며 이들을 제어하기 위한 프로토콜 또한 다양하게 개발 및 발전되어 왔다. 일 예로서, IoT 관련 표준 제정을 위해 리눅스 재단의 주도하에 LG전자, 하이얼, 파나소닉, 퀄컴, 샤프 등의 멤버들이 모여 연합체 올씬얼라이언스(AllSeen Alliance)를 출범하고 퀄컴의 P2P 솔루션인 올조인(AllJoyn) 오픈 프로젝트를 IoE의 기반의 프레임워크로 선정하였다. 또한, 한국의 TTA, 유럽의 ESTI, 북미 ATIS 및 TIA 등 세계 7개 표준 개발기구들이 모여 사물인터넷 공동플랫폼 개발을 목적으로 모여 프로젝트를 구성하여 oneM2M 규격을 발표하였다. 이밖에도 인텔, 삼성전자, Amtel 등 다수의 기업들이 OIC(Open Interconnect Consortium)을 발족하고 표준규격을 개발하기 위해 OCF(Open Connectivity Foundation)을 신설하였다.

특히, 사물인터넷 표준화 단체 가운데 OCF(Open Connectivity Foundation)는 사물인터넷에 대한 오픈소스 기반의 OCF 표준을 제정하였고, OCF 표준은 최근 사물인터넷과 관련된 다양한 표준들 가운데서도 빠르게 채택되고 있는 대표적인 사물인터넷 표준에 해당한다. OCF는 사물인터넷 장치들을 연결하고 사물인터넷 장치에 존재하는 자원들을 상호제어 할 수 있도록 하는 표준 플랫폼 기술로써, OCF는 서버-클라이언트 모델로 각 서버는 자신들이 제공 가능한 다양한 사물인터넷 서비스를 리소스 형태로 정의하여 클라이언트에서 원하는 서비스를 사용할 수 있는 Restful 방식을 채용하고 있다. 한편 상기 OCF는 Constrained Application Protocol(CoAP)을 사용하여 컴퓨팅 파워가 크지 않은 소형 기기에서도 사물인터넷이 구현 가능하도록 하고 있다.

이와 같이, OCF 기술이 적용된 사물인터넷 기기의 경우에는 OCF에서 채택한 프로토콜을 통해 OCF 기술이 적용된 타 장치들과 통신을 정상적으로 수행할 수 있으나, OCF가 아닌 다른 표준 기술이 적용된 타 장치와 통신을 수행하기 어려운 문제가 존재한다. 이러한 문제는 OCF 진영과 타 표준 기술 진영 모두 각자의 생태계를 확장하는데 걸림돌이 될 수밖에 없다.

이와 같이 IoT 디바이스들에 대한 다양한 IoT 프레임워크 및 통신 프로토콜이 존재하므로 서로 다른 프레임워크 또는 프로토콜을 사용하는 IoT 디바이스들을 통합적으로 제어 및 관리하기가 어렵다는 문제점이 발생하였고, 하나의 게이트웨이에 연결되는 IoT 디바이스의 수가 늘어나면서 이러한 문제점은 더욱 악화되었다.

본 발명은 상기 문제점을 해결하기 위한 것으로, 서로 다른 프로토콜을 사용하는 다수의 IoT 디바이스와 연동하고 이를 제어하기 위해 OCF 표준 프로토콜 형태로 통합할 수 있는 IoT 게이트웨이를 제공하는 것을 목적으로 한다.

또한, 본 발명은 기존에 데이터가 없는 신규한 IoT 디바이스라 하더라도 머신러닝 알고리즘을 통해 학습한 룰셋을 제공하여 IoT 디바이스의 타입 및 사용하는 프로토콜을 판단할 수 있는 신규한 IoT 게이트웨이를 제공하는 것을 목적으로 한다.

또한, 본 발명은 연동된 IoT 디바이스와 통신하는 과정에서 발생할 수 있는 위험요소를 탐지하고 차단할 수 있는 기능을 구비한 신규한 IoT 게이트웨이를 제공하는 것을 목적으로 한다.

본 발명의 일 실시예에 따르면, 다양한 프로토콜을 갖는 IoT 디바이스와의 호환성을 제공하는 IoT 게이트웨이에 있어서, 제1 IoT 디바이스로부터 수신한 메시지에 기초하여 상기 제1 IoT 디바이스의 타입(Type) 및 사용하는 프로토콜을 확인하고, OCF 프레임워크 기반의 가상의 리소스 모델 객체의 생성 및 상기 수신된 메시지의 OCF 기반 프로토콜로의 변환을 수행하는 프로토콜 변환부, 상기 생성된 리소스 모델 객체에 디바이스 ID를 부여하고 상기 OCF 기반 프로토콜로 변환된 상기 수신된 메시지와 매핑하는 디바이스 관리부 및 상기 생성된 리소스 모델 객체를 OCF 기반 프로토콜을 이용하여 통합제어서버로 전송하는 제어 관리부를 포함하는 IoT 게이트웨이를 개시한다.

본 발명의 다른 실시예에 따르면, 상기 프로토콜 변환부가 상기 수신한 메시지에 기초하여 상기 제1 IoT 디바이스의 타입(Type) 및 사용하는 프로토콜을 확인할 수 없는 경우, 상기 디바이스 관리부는 상기 수신된 메시지로부터 소정 정보를 획득하고, 상기 추출된 정보 및 미리 학습되어 저장된 룰셋(Ruleset)에 기초하여 상기 제1 IoT 디바이스의 타입 및 사용하는 프로토콜을 더 판단한다.

본 발명의 다른 실시예에 따르면, 상기 IoT 게이트웨이는 상기 룰셋을 학습하고 저장하는 디바이스 분석 머신러닝부를 더 포함한다.

본 발명의 다른 실시예에 따르면, 상기 획득하는 소정 정보는 상기 제1 IoT 디바이스의 MAC(media Access Control) 정보 또는 UUID(Universally Unique Identifier), 제조사 정보, 사용하는 서비스포트 정보, 모델명 중 적어도 하나이다.

본 발명의 다른 실시예에 따르면, 상기 IoT 게이트웨이는 상기 제1 IoT 디바이스로부터 수신한 메시지로부터 위험요소를 탐지하고 상기 제1 IoT 디바이스를 차단하는 위험탐지부를 더 포함한다.

본 발명에 따르면 OCF 표준 프로토콜 형태로 통합할 수 있는 IoT 게이트웨이를 이용하여 서로 다른 프로토콜을 사용하는 다수의 IoT 디바이스에 대해서도 연동하고 이를 제어할 수 있다는 효과를 갖는다.

또한, 본 발명에 따르면 머신러닝 알고리즘을 통해 학습한 룰셋을 제공하여 기존에 데이터가 없는 신규한 IoT 디바이스라 하더라도 그 IoT 디바이스의 타입 및 사용하는 프로토콜 판단의 정확도를 높일 수 있다는 효과를 갖는다.

또한, 본 발명에 따르면 연동된 IoT 디바이스와 통신하는 과정에서 발생할 수 있는 위험요소를 탐지하고 차단할 수 있어 보안이 강화되고 안전하게 IoT 디바이스와 연동 및 제어할 수 있다는 효과를 갖는다.

도 1은 본 발명의 일 실시예에 따른 IoT 게이트웨이를 포함하는 전체 시스템을 개략적으로 도시한 도면,
도 2는 본 발명의 일 실시예에 따른 IoT 게이트웨이의 블록도를 도시한 도면,
도 3은 본 발명의 실시예에 따른 프로토콜 변환부를 구성하는 각 모듈을 포함하는 블록도를 도시한 도면,
도 4는 본 발명의 실시예에 따른 디바이스 관리부를 구성하는 각 모듈을 포함하는 블록도를 도시한 도면,
도 5는 본 발명의 실시예에 따른 제어 관리부를 구성하는 각 모듈을 포함하는 블록도를 도시한 도면,
도 6은 본 발명의 일 실시예에 따라 IoT 게이트웨이가 신규 IoT 디바이스의 최초 등록을 수행하는 것을 설명하기 위한 흐름도,
도 7은 본 발명의 일 실시예에 따른 OCF 프레임워크 기반의 리소스 모델 객체의 예를 도시한 도면이다.

이상의 본 발명의 목적들, 다른 목적들, 특징들 및 이점들은 첨부된 도면과 관련된 이하의 바람직한 실시예들을 통해서 쉽게 이해될 것이다. 그러나 본 발명은 여기서 설명되는 실시예들에 한정되지 않고 다른 형태로 구체화될 수도 있다. 오히려, 여기서 소개되는 실시예들은 개시된 내용이 철저하고 완전해질 수 있도록 그리고 당업자에게 본 발명의 사상이 충분히 전달될 수 있도록 하기 위해 제공되는 것이다.

본 명세서에서 제1, 제2 등의 용어가 구성요소들을 기술하기 위해서 사용된 경우, 이들 구성요소들이 이 같은 용어들에 의해서 한정되어서는 안된다. 이들 용어들은 단지 어느 구성요소를 다른 구성요소와 구별시키기 위해서 사용되었을 뿐이다. 여기에 설명되고 예시되는 실시예들은 그것의 상보적인 실시예들도 포함한다.

본 명세서에서, 단수형은 문구에서 특별히 언급하지 않는 한 복수형도 포함한다. 명세서에서 사용되는 '~를 포함한다', '~로 구성된다', 및 '~으로 이루어진다'라는 표현은 언급된 구성요소 외에 하나 이상의 다른 구성요소의 존재 또는 추가를 배제하지 않는다.

본 명세서에서 용어 '소프트웨어'는 컴퓨터에서 하드웨어를 움직이는 기술을 의미하고, 용어 '하드웨어'는 컴퓨터를 구성하는 유형의 장치나 기기(CPU, 메모리, 입력 장치, 출력 장치, 주변 장치 등)를 의미하고, 용어 '단계'는 소정의 목을 달성하기 위해 시계열로 연결된 일련의 처리 또는 조작을 의미하고, 용어 '컴퓨터 프로그램', '프로그램', 또는 '알고리즘'은 컴퓨터로 처리하기에 합한 명령의 집합을 의미하고, 용어 '프로그램 기록 매체'는 프로그램을 설치하고 실행하거나 유통하기 위해 사용되는 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체를 의미한다.

본 명세서에서 발명의 구성요소를 지칭하기 위해 사용된 '~노드', '~부', '~모듈', '~유닛', '~블록', '~보드' 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 물리적, 기능적, 또는 논리적 단위를 의미할 수 있고 이는 하나 이상의 하드웨어나 소프트웨어 또는 펌웨어로 구현되거나 또는 하나 이상의 하드웨어, 소프트웨어, 및/또는 펌웨어의 결합으로 구현될 수 있다.

본 명세서에서 '모바일 기기', '컴퓨터', '컴퓨팅 장치', '서버 장치', 또는 '서버'는 윈도우, 맥, 또는 리눅스와 같은 운영체제, 컴퓨터 프로세서, 메모리, 응용프로그램들, 기억장치(예를 들면, HDD, SDD), 및 모니터를 구비한 장치로 구현될 수 있다. 컴퓨터는 예를 들면, 데스크톱 컴퓨터나 노트북, 모바일 단말기 등과 같은 장치일 수 있으나 이들은 예시적인 것이며 이에 한정되는 것은 아니다. 모바일 단말기는 스마트폰, 태블릿 PC, 또는 PDA와 같은 모바일 무선통신기기 중 하나일 수 있다.

본 명세서에서, 구성요소 'A'가 구성요소 'B'에게 정보, 내역, 및/ 또는 데이터를 전송한다고 함은 구성요소 'A'가 구성요소 'B'에게 직접 전송하거나 또는 구성요소 'A'가 적어도 하나 이상의 다른 구성요소를 통해서 구성요소 'B'에 전송하는 것을 포함하는 의미로 사용한다.

이하 도면을 참조하여 본 발명을 상세히 설명하도록 한다. 아래의 특정 실시예들을 기술하는데 있어서 여러 가지의 특정적인 내용들은 발명을 더 구체적으로 설명하고 이해를 돕기 위해 작성되었다. 하지만 본 발명을 이해할 수 있을 정도로 이 분야의 지식을 갖고 있는 독자는 이러한 여러 가지의 특정적인 내용들이 없어도 사용될 수 있다는 것을 인지할 수 있다. 또한 발명을 기술하는 데 있어서 공지 또는 주지관용 기술이면서 발명과 크게 관련 없는 부분들은 본 발명을 설명하는 데 있어 혼돈을 막기 위해 기술하지 않음을 미리 언급해 둔다.

도 1은 본 발명의 일 실시예에 따른 IoT 게이트웨이를 포함하는 전체 시스템을 개략적으로 도시한다.

도 1에 도시된 IoT 게이트웨이(100)는 다양한 종류의 프로토콜을 사용하는 IoT 디바이스(200)와 연동하기 위해 IoT 디바이스(200)로부터 수신되는 메시지를 저장된 IoT 디바이스 정보와 대비하여 IoT 디바이스(200)의 타입(Type) 및 사용하는 프로토콜 정보를 확인하고 OCF 프레임워크 기반의 가상의 리소스 모델 객체를 생성하며, 수신되는 메시지를 OCF 기반의 프로토콜로 변환한다. 한편, IoT 디바이스 정보와 대비하여도 IoT 디바이스(200)의 타입 및 사용하는 프로토콜 정보의 확인이 안되는 경우, 최초 등록하는 IoT 디바이스로 판단하고 수신된 메시지로부터 MAC(media Access Control) 정보 또는 UUID(Universally Unique Identifier) 등 IoT 디바이스의 고유 식별자, 제조사 정보, 사용하는 서비스포트 정보, 모델명 등 다양한 정보를 획득하고 미리 학습하여 저장해 둔 룰셋(Ruleset)을 기반으로 IoT 디바이스(200)의 타입 및 사용하는 프로토콜을 판단하고 IoT 디바이스 정보에 이러한 내용을 추가한다.

룰셋은 현재 존재하는 모든 IoT 디바이스에 대한 정보를 다 포함할 수 없고, 새로운 타입과 프로토콜을 갖는 IoT 디바이스는 계속하여 시장에 나올 수 있으므로 IoT 게이트웨이(100)는 공지된 머신러닝 알고리즘 중 적어도 하나를 사용하여 룰셋에 대한 기계 학습을 수행함으로써, 추후 룰셋에 반영되지 않는 방식의 IoT 디바이스의 연동시 디바이스 타입 분석에 기초해 가상 리소스 모델 객체 생성하고 사용하는 프로토콜을 결정하는 등 리소스 모델 판별 정확도를 높이는데 사용될 수 있다. 이때, 획득한 다양한 정보 중 적어도 일부는 공지된 머신러닝 방식의 학습에 사용될 수 있다.

한편, IoT 게이트웨이(100)는 OCF 프레임 워크 기반으로 생성된 가상의 리소스 모델 객체의 리소스에 OCF 기반의 프로토콜로 변환된 메시지를 매핑한다. 연동된 IoT 디바이스(200)에 대한 OCF 프레임워크 기반의 가상의 리소스 모델 객체가 생성되고 리소스에 필요한 데이터가 매핑되었으므로, IoT 게이트웨이(100)는 OCF 프로토콜을 지원하는 통합 제어서버(300)에 CoAP (Constrained Application Protocol)을 사용하여 통신하고 통합 제어서버(300)로부터 연동된 IoT 디바이스(200)를 제어하기 위한 RESTful 방식의 제어 메시지를 수신하면 이에 기초하여 해당 IoT 디바이스(200)가 사용하는 프로토콜에 맞게 재변환하여 전송함으로써 IoT 디바이스(200)를 제어할 수 있다.

그리고, IoT 게이트웨이(100)는 연동된 IoT 디바이스(200)와 통신하는 과정에서 발생할 수 있는 위험요소를 탐지하고 차단하는 기능을 수행한다. 즉, IoT 디바이스(200)로부터 수신되는 정보를 상시 탐지하여 비정상 정보가 탐지되었을 때 연동된 IoT 디바이스(200)를 차단하거나, 화이트리스트 방식으로 IoT 게이트웨이(100)와 연동 가능한 IoT 디바이스(200)의 리스트를 보유하고 최초 연동시를 제외하고는 일반적인 제어 상황에서 화이트리스트에 등록되지 않은 IoT 디바이스가 정보를 전송하려고 할 때 이를 차단할 수도 있다.

IoT 게이트웨이는 본원 발명의 정의에 따른 모바일 기기, 컴퓨터, 컴퓨팅 장치, 서버 장치, 또는 서버 중 어느 하나에 해당할 수 있으나 이에 한정되는 것은 아니며, 로컬 또는 클라우드 등의 원격 저장 장치를 구비하고 하나 이상의 IoT 디바이스 및 통합제어서버와 유선 및/또는 무선으로 연동 및 통신하면서 본원 발명에 기재된 기능을 수행하는 장치라면 어느 장치든 본원 발명에 따른 IoT 게이트웨이에 해당할 수 있다.

다음으로, IoT 디바이스(200)는 다양한 제조사에서 제조된, 다양한 프로토콜을 사용하는 IoT 장치를 통칭하는 의미이다. IoT 디바이스(200)는 OCF 표준을 지원하고 OCF 표준에서 사용하는 CoAP를 이용하여 IoT 게이트웨이(100)와 연동하는 디바이스일 수도 있으나, MQTT(Message Queuing Telemetry Transport) 프로토콜이나 HTTP, 시리얼 통신 중에 하나인 RS-485 등 OCF 표준을 지원하지 않는 프로토콜을 이용할 수도 있고 제어를 위해 OCF 표준을 준수하지 않는 비-OCF 장치일 수도 있다. IoT 디바이스(200)는 디바이스 타입 및 사용하는 프로토콜에 관계없이 IoT 게이트웨이(100)와 연동되어 정보를 제공하고 제어될 수 있다.

IoT 디바이스(200)는 기본적으로 특정 상태를 감지하는 센싱(Sensing) 기능 및 IoT 게이트웨이와 연동 및 통신하기 위한 네트워킹(networking) 기능을 갖는 장치이면 어느 장치든 본원 발명에 따른 IoT 게이트웨이에 해당할 수 있으며, 이 외에도 그 타입에 따라 특정 동작을 수행하는 액츄에이팅(actuating) 기능 등 부가적인 기능 또한 구비할 수 있음은 이해될 수 있다.

통합 제어서버(300)는 스마트 시티의 경우 통합 관제센터, 스마트 홈의 경우 사용자에 의해 설치한 서버 또는 핸드폰 내의 애플리케이션일 수 있으며, IoT 게이트웨이(100)를 통하여 연동된 다양한 IoT 디바이스(200)로부터 필요한 정보를 수집하고 이에 기반하여 필요한 제어를 수행할 수 있는 기능을 구비한 것을 특징으로 한다. 여기서, 통합 제어서버(300)는 IoT 디바이스(200)의 타입 및 사용하는 프로토콜에 관계없이 IoT 게이트웨이(100)와 OCF 표준에 기초한 통신을 수행하여 IoT 디바이스(200)의 제어가 가능하므로 개발 리소스를 줄이면서도 다양한 IoT 디바이스와의 호환성을 제공할 수 있다.

통합제어서버(300)는 본원 발명의 정의에 따른 모바일 기기, 컴퓨터, 컴퓨팅 장치, 서버 장치, 또는 서버 중 어느 하나에 해당할 수 있으나 이에 한정되는 것은 아니며, IoT 게이트웨이와 통신하면서 IoT 게이트웨이에 연동된 IoT 디바이스를 제어하기 위한 제어 메시지를 전송하는 등 본원 발명에 기재된 기능을 수행하는 장치라면 어느 장치든 본원 발명에 따른 통합제어서버에 해당할 수 있다.

도 1의 예에서, IoT 디바이스(200)가 OCF 표준을 준수하지 않는 온도 센서 및 에어컨 기기의 2개가 있다고 가정할 때, 온도 센서 및 에어컨 기기의 IoT 게이트웨이(100)와의 최초 연동시에 IoT 게이트웨이(100)는 수신된 메시지로부터 통신 프로토콜을 분석하고 디바이스 타입 및 사용하는 프로토콜을 결정하여 이를 기초로 한 OCF 기반 가상 리소스 모델 객체를 생성한다. 생성된 가상 리소스 모델 객체는 각각 온도 센서 및 에어컨 기기에 대한 객체에 해당하고, 필요한 프로퍼티(property)로써 온도 센서의 경우 현재 온도 및 온도의 단위(예컨대 섭씨인지 화씨인지) 등을 포함할 것이고, 에어컨 기기 역시 현재 작동 여부(ON/OFF)를 포함할 것이다. 이와 같이, 생성된 온도 센서 및 에어컨 기기에 대한 OCF 기반 객체에 대한 정보는 리소스 모델을 기반으로 RESTful 방식을 만족하는 오퍼레이션, 즉 생성(Create), 읽기(Retrieve), 갱신(Update), 삭제(Delete), 통보(Notify)를 만족하는 각각의 동작을 포함하는 CRUDN 방식을 기초로 통합 제어서버(300)로 읽기(Retrieve) 및/또는 통지(Notify)될 수 있고 만일 통합 제어서버(300)에서 특정 온도(예컨대, 섭씨 27도)에 도달하고 에어컨이 작동하지 않는 경우 작동하도록, 그리고 특정 온도(예컨대, 섭씨 23도)까지 떨어졌는데 에어컨이 작동하는 경우 작동을 중지하도록 하는 제어를 설정한 경우, 온도 센서의 온도의 값이 섭씨 27도이고, 에어컨 기기의 작동 여부가 OFF인 정보에 기초하여 통합 제어서버(300)는 에어컨 기기의 작동 여부에 대한 프로퍼티를 OFF에서 ON으로 변경하기 위한 업데이트(Update)를 전송하면, 이에 기초하여 IoT 게이트웨이(100)는 에어컨 기기가 사용하는 프로토콜에 맞추어 전송된 내용을 변환(conversion)하고 전송하며, 에어컨 기기는 이에 따라 상태를 OFF에서 ON으로 변경함으로써 에어컨을 작동시킬 수 있다. 마찬가지로, 온도 센서의 온도의 값이 섭씨 23도이고, 에어컨 기기의 작동 여부가 ON인 정보에 기초하여 통합 제어서버(300)는 에어컨 기기의 작동 여부에 대한 프로퍼티를 ON에서 OFF으로 변경하기 위한 업데이트(Update)를 전송하면, 이에 기초하여 IoT 게이트웨이(100)는 에어컨 기기가 사용하는 프로토콜에 맞추어 전송된 제어 메시지를 변환(conversion)하고 전송하며, 에어컨 기기는 이에 따라 상태를 ON에서 OFF으로 변경함으로써 동작중인 에어컨을 정지시킬 수 있다.

도 2는 본 발명의 일 실시예에 따른 IoT 게이트웨이의 블록도를 도시한다.

도 2를 참조하면, IoT 게이트웨이(100)는 프로토콜 변환부(110), 디바이스 관리부(120), 디바이스 분석 머신러닝부(130), 제어 관리부(140), 위험탐지부(150) 및 데이터베이스(160)를 포함한다.

프로토콜 변환부(110)는 IoT 디바이스(200)와의 통신시 수신된 메시지로부터 바인딩(binding)된 통신 프로토콜을 확인 및 해석하여 이로부터 페이로드(Payload)를 추출해내고, 페이로드를 데이터베이스(160)에 저장된 IoT 디바이스 정보와 대비하여 IoT 디바이스 타입 및 사용하는 프로토콜 정보를 확인한 후 만일 해당 IoT 디바이스에 대해 생성된 객체가 없다면 OCF 프레임워크 기반의 가상의 리소스 모델 객체를 생성하고, 수신된 페이로드를 OCF 기반의 프로토콜로 변환하여 디바이스 정보 전달 모듈(114)을 통해 디바이스 관리부(120)로 전달한다. 만일 데이터베이스에 매칭되는 IoT 디바이스 정보가 없는 경우, 최초 등록하는 IoT 디바이스로 판단하여, 페이로드를 디바이스 정보 전달 모듈(114)을 통해 디바이스 관리부(120)로 전달하고, 디바이스 관리부(120)가 판단한 IoT 디바이스 타입에 기초하여 OCF 프레임워크 기반의 가상의 리소스 모델 객체를 생성한다. 또한, 통합 제어서버(300)로부터 특정 IoT 디바이스로의 제어 메시지를 수신한 경우, 수신한 메시지를 데이터베이스(160)에 저장된 사용하는 프로토콜 정보를 확인한 후 특정 IoT 디바이스가 사용하는 프로토콜 및 통신 프로토콜로 변환(conversion) 및 바인딩하여 전송한다.

본 발명의 실시예에 따른 프로토콜 변환부(110)를 구성하는 각 모듈을 포함하는 블록도를 도시한 도 3을 참조하여 프로토콜 변환부(110)를 더욱 상세히 설명하면, 프로토콜 변환부(110)는 통신 프로토콜 처리 모듈(111), 프로토콜 변환 모듈(112), 가상모델 객체 생성 모듈(113) 및 디바이스 정보 전달 모듈(114)을 포함한다.

통신 프로토콜 처리 모듈(111)은 IoT 디바이스(200)로부터 수신한 메시지에 바인딩된 통신 프로토콜을 확인 및 해석하여, 수신한 정보로부터 페이로드를 추출해 낸다. 통신 프로토콜에는 무선이나 유선인 시리얼 방식을 통한 MQTT, HTTP, RS-485, CoAP, WebSocket과 같은 다양한 프로토콜이 사용될 수 있으며, 통신 프로토콜 처리 모듈(111)은 각 프로토콜의 규격에 대한 정보와 수신한 메시지로부터 헤더를 비교하는 방식으로 어떠한 통신 프로토콜이 바인딩되었는지를 확인하고, 이로부터 페이로드를 추출할 수 있다. 또한, 통신 프로토콜 처리 모듈(111)은 특정 IoT 디바이스로의 메시지 전달을 위해 해당 IoT 디바이스가 사용하는 프로토콜로 변환된 페이로드에 특정 IoT 디바이스가 사용하는 통신 프로토콜을 바인딩하여 해당 IoT 디바이스로 전달하는 기능을 더 수행할 수 있다. 이때, 특정 IoT 디바이스가 사용하는 통신 프로토콜은 메시지 수신시에 확인된 결과를 데이터베이스(160)에 저장하고 이를 참조하여 확인할 수 있다.

프로토콜 변환 모듈(112)은 추출된 페이로드를 데이터베이스(160)에 의해 저장된 IoT 디바이스 정보와 대비하여 IoT 디바이스 타입 및 사용하는 프로토콜 정보를 확인하고, 이에 기초하여 OCF 기반의 프로토콜로 변환한다. 여기서 사용하는 프로토콜 정보는 AllJoyn, oneM2M, HomeKit 등 IoT 디바이스를 제어하기 위해 제정된 다양한 프레임워크를 지원하는 프로토콜 중 하나일 수 있다. 프로토콜 변환 모듈(112)은 OCF의 브리징 스펙의 OCF 장치와 비-OCF 생태계에서의 장치간의 연결을 위한 프레임 워크를 포함할 수 있으며, 여기서 브리징 스펙은 리소스 검색, 메시지 변환, 보안 및 다중의 브리지 처리에 관한 일반적인 요구사항을 정의하고 있고, 브리징 스펙은 코어 리소스의 매핑, 오류 및 사용자의 리소스 타입의 알고리즘 변환을 포함하는 OCF와 비-OCF 프로토콜 간의 연결을 위한 특정 요구사항을 제공할 수 있으며, 기존에 공지된 OCF-AllJoyn Mapping Spec이나 OCF-oneM2M Mapping Spec을 더 포함할 수 있다.

만일 데이터베이스(160)에 저장된 IoT 디바이스 정보와 매칭되지 않는 경우 IoT 게이트웨이(100)에 신규 등록하고자 하는 디바이스로 판단하여 페이로드를 디바이스 관리부(120)로 전달한다.

또한, 프로토콜 변환 모듈(112)은 특정 IoT 디바이스로의 메시지 전달을 위해 OCF 표준 기반의 메시지를 객체 가상의 해당 IoT 디바이스가 사용하는 프로토콜로 변환하여 통신 프로토콜 처리 모듈(111)로 전달하는 기능을 더 수행할 수 있다.

다음으로, 가상모델 객체 생성 모듈(113)은 해당 IoT 디바이스에 대한 가상모델 객체가 아직 생성되지 않은 경우 OCF 프레임워크 기반의 가상의 리소스 모델 객체를 생성한다. 본 발명의 일 실시예에 따른 OCF 프레임워크 기반의 리소스 모델 객체의 예를 도시한 도 7을 참조하면, 가상모델 객체 생성 모듈(113)은 IoT 디바이스의 타입으로부터 스마트 조명임을 확인하고, 이에 해당하는 OCF 표준이 지원하는 리소스 URI인 /light 및 /dimming에 해당하는 리소스 타입인 oic.r.switch.binary 및 oic.r.brightness를 포함하는 가상 모델 객체를 생성할 수 있다. 이후, 통합 제어서버(300)를 통해 OCF 표준 방식으로 해당 가상 모델 객체를 제어(예컨대, 전원의 on/off 또는, 밝기를 조절함으로써 dimming 기능 제어)할 수 있게 된다.

마지막으로, 디바이스 정보 전달 모듈(114)은 생성된 가상의 리소스 모델 객체 및 수신한 페이로드를 디바이스 관리부(120)에 전달하는 한편, 머신러닝을 위해 수신한 페이로드를 디바이스 분석 머신러닝부(130)로 전달한다.

다음으로, 디바이스 관리부(120)는 프로토콜 변환부(110)에서 생성된 가상의 리소스 모델 객체가 전달되는 경우 IoT 게이트웨이(100)에 연동된 IoT 디바이스(200)에 대한 정보를 매칭시킬 수 있도록 디바이스 ID를 생성하고 데이터베이스(160)에 저장된 IoT 디바이스 정보에 추가한다. IoT 디바이스 정보가 보다 명확해질 수 있도록 디바이스 관리부(120)는 전달된 페이로드를 통해 디바이스 제조사, 모델명, IoT 디바이스의 MAC 정보 또는 UUID 등 식별 정보, 사용 서비스 포트 등을 더 수집해서 저장할 수 있다. 한편, 디바이스 관리부(120)는 생성된 가상의 리소스 모델 객체와 OCF 기반의 프로토콜로 변환된 정보를 매핑한다. 도 7의 예에서 계속하여, OCF 기반의 프로토콜로 변환된 정보를 참조하여 IoT 디바이스에 해당하는 스마트 조명의 전원이 켜져 있고, 밝기가 100인 것을 확인하고, 이를 해당 IoT 디바이스에 대해 생성된 가상의 리소스 모델 객체에 매핑함으로써, 리소스 /light에 해당하는 값은 TRUE, 리소스 /diming에 해당하는 값은 100으로 반영한다. 한편, 기존에 등록되지 않은 IoT 디바이스의 최초 등록 상황이 발생하는 경우 디바이스 관리부(120)는 디바이스 분석 머신러닝부(130)에 의해 학습되고 데이터베이스(160)에 저장된 룰셋을 기반으로 IoT 디바이스의 타입 및 사용하는 프로토콜을 판단한다. 판단된 타입 및 프로토콜은 프로토콜 변환부(110)에 의해 OCF 기반의 프로토콜 변환 및 가상의 리소스 모델 객체를 생성하는데 사용되고, 이후 디바이스 관리부(120)는 디바이스 ID 생성 등의 전술한 절차를 수행할 수 있다.

본 발명의 실시예에 따른 디바이스 관리부(120)를 구성하는 각 모듈을 포함하는 블록도를 도시한 도 4을 참조하여 디바이스 관리부(120)를 더욱 상세히 설명하면, 디바이스 관리부(120)는 디바이스 생성 모듈(121), 디바이스 패킷 정보 수집 모듈(122) 및 디바이스 관리 모듈(123)을 포함한다.

디바이스 생성 모듈(121)은 프로토콜 변환부(110)에서 생성된, 연동된 IoT 디바이스(200)의 타입을 기반으로 만들어진 가상 리소스 모델 객체에 대해 정보를 매칭시킬 수 있도록 디바이스 ID를 부여한다.

디바이스 패킷 정보 수집 모듈(122)는 전달된 페이로드를 통해 디바이스 제조사, 모델명, IoT 디바이스의 MAC 정보 또는 UUID 등 식별 정보, 사용 서비스 포트 등을 더 수집할 수 있다. 이처럼 저장된 정보들은 후술하는 디바이스 분석 머신러닝부(130)에서 머신러닝 알고리즘에 이용되어 디바이스 타입 및 사용하는 프로토콜을 판단하고, 이에 대응하여 생성할 가상 리소스 모델 객체의 정확도를 높이는데 사용될 수 있다.

디바이스 관리 모듈(123)은 디바이스 생성 모듈(121) 및 디바이스 패킷 정보 수집 모듈(122)에서 생성/수집된 정보를 매핑하여 데이터베이스에 저장하고, 생성된 디바이스 ID에 해당하는 가상 리소스 모델 객체에 OCF 기반의 프로토콜로 변환된 정보를 매핑한다. 만일 기존에 등록되지 않은 IoT 디바이스가 최초 등록하고자 하는 경우 디바이스 관리 모듈(123)은 데이터베이스(160)에 저장된 룰셋을 기반으로 IoT 디바이스의 타입 및 사용하는 프로토콜을 판단하고 판단된 타입 및 프로토콜은 프로토콜 변환부(110)에 의해 OCF 기반의 프로토콜 변환 및 가상의 리소스 모델 객체를 생성하는데 사용되고, 이후 디바이스 관리부(120)는 디바이스 ID 생성 등의 전술한 절차를 수행할 수 있다.

디바이스 관리 모듈(123)은 또한, 연동된 IoT 디바이스와 매칭된 가상의 리소스 모델 객체 및 IoT 디바이스의 메시지 정보를 기반으로 제어 관리부(140)에 정보를 전달한다. 전술한 도 7의 예에서, IoT 디바이스의 메시지 정보에 따라 IoT 디바이스에 해당하는 스마트 조명의 전원이 켜져 있고, 밝기가 100인 것을 확인하면, 이러한 정보를 제어 관리부(140)에 전달한다. 한편, 디바이스 관리 모듈(123)은 IoT 디바이스 타입 별 위험탐지 룰셋 정보를 통합 제어서버(300)로부터 수신하고 위험탐지부(150)에 전달할 수 있다.

한편, 디바이스 분석 머신러닝부(130)는 프로토콜 변환부(110) 또는 디바이스 관리부(120)에서 수신된 정보에 기초하여 연동된 IoT 디바이스의 타입 및 사용하는 프로토콜을 결정할 수 있도록 공지된 머신러닝 방식 중 적어도 하나를 이용하여 학습한 룰셋을 작성 및 업데이트하고 데이터베이스(160)에 저장한다. 이때, 룰셋은 현존하는 다양한 IoT 디바이스들에 대한 정보(IoT 디바이스 타입, 사용하는 프로토콜, 디바이스 제조사, 모델명, IoT 디바이스의 MAC 정보 또는 UUID 등 식별 정보, 사용 서비스 포트)를 기초로 하여 디바이스 분석 머신러닝부(130)에 의해 학습된다.

일 예로서, 디바이스 분석 머신러닝부(130)는 제조사 별로 모델명 및 IoT 디바이스 타입을 구분해 두고, 새로운 IoT 디바이스로부터 수신한 정보로부터 해당 제조사에 의해 제조된 디바이스이긴 하나 기존의 모델명 및 디바이스 타입에 매칭되지 않는 경우, 모델명 중 적어도 70% 이상이 기존의 모델명과 일치하는 경우, 새로운 IoT 디바이스의 타입은 일치되는 기존의 모델에 해당하는 디바이스 타입의 새로 출시된 모델인 것으로 판단하거나, 또는 모델명 중 70% 이상 매칭되는 모델명이 없고 해당 제조사에 해당하는 IoT 디바이스 중 특정 타입 (예컨대, 온도조절기)에 해당하는 타입이 70% 이상 차지하는 경우, 특정 타입(온도조절기)에 대해 새로 출시된 모델인 것으로 판단하도록 룰셋을 구성할 수 있다.

다른 예로서, 사용하는 서비스 포트별로 디바이스 타입 및 사용하는 프로토콜의 동일성을 계산해 두고, 서비스 포트 말고는 다른 정보가 매칭되지 않는 경우 동일한 서비스 포트를 사용하는 IoT 디바이스 중 가장 많은 종류의 디바이스 타입 및 프로토콜에 해당하는 것으로 판단하도록 룰셋을 구성할 수 있으며, 각 정보의 대비의 우선순위를 정하여 모델명이 일치하는지 여부를 제일 먼저 판단하고, 이후 제조사, IoT 디바이스의 식별번호의 유사도, 사용하는 서비스 포트 등의 순으로 일치 또는 유사한지 여부를 판단하는 식의 룰셋을 구성할 수도 있다. 또는, 필요한 경우에 사용자에 의한 디바이스 타입 및 디바이스 타입에 따른 사용하는 프로토콜 등을 설정해 줌으로써 새로운 디바이스 정보에 대한 학습을 수행할 수 있도록 할 수도 있다.

전술한 룰셋의 구성 예는 단지 일부 예에 불과하므로, 본원 발명의 디바이스 분석 머신러닝부(130)가 구성하는 룰셋의 학습 방법은 전술한 예에 한정되지 않으며, 획득할 수 있는 정보를 기반으로 다양한 방식의 학습을 수행하여 그 정확도를 높일 수 있다.

디바이스 분석 머신러닝부(130)는 신규한 IoT 디바이스가 연동하는 경우 프로토콜 변환부(110) 또는 디바이스 관리부(120)로부터 이와 관련된 정보를 수신하여 학습 및 룰셋을 갱신할 수 있으며, 이처럼 학습 및 갱신되는 룰셋은 디바이스 관리부(120)에서 새로운 IoT 디바이스의 최초 등록시에 유용하게 활용될 수 있다.

다음으로 제어 관리부(140)는 통합 제어서버(300)와 OCF 기반 프로토콜로 통신하여, 제어서버(300)로부터의 IoT 게이트웨이(100)와 연동된 특정 IoT 디바이스(200)의 제어 메시지를 수신하고 프로토콜 변환부(110)를 통해 특정 IoT 디바이스(200)를 제어한다.

본 발명의 실시예에 따른 제어 관리부(140)를 구성하는 각 모듈을 포함하는 블록도를 도시한 도 5를 참조하여 제어 관리부(140)를 더욱 상세히 설명하면, 제어 관리부(140)는 제어 변환 모듈(141), 제어 수신 모듈(142) 및 제어 전송 모듈(143)을 포함한다.

제어 변환 모듈(141)은 디바이스 관리부(120)로부터 특정 ID에 매칭되는 IoT 디바이스로부터 수신되는 메시지를 ID를 이용하여 메시지를 전달한 IoT 디바이스를 확인하고, 해당 메시지를 제어 전송 모듈(143)을 통해 통합제어 서버(300)로 전송한다. 이 때, 이미 OCF 기반의 가상의 리소스 모델 객체가 생성되어 있고 통합제어 서버(300)는 OCF 표준을 지원하므로 별도의 프로토콜 변환이 필요하지 않다. 또한, 통합제어 서버(300)에서 특정 IoT 디바이스에 대한 제어 메시지를 제어 수신 모듈(142)을 통해 수신한 경우, 디바이스 관리부(120)에서 생성 및 저장한 ID를 이용하여 제어 메시지를 전달할 IoT 디바이스를 특정하고, 제어 전송 모듈(143)을 통해 프로토콜 변환부(110)에서 제공하는 특정된 IoT 디바이스에서 사용하는 프로토콜로의 변환 및 통신 프로토콜의 바인딩을 마친 후 특정 IoT 디바이스로 전송한다.

제어 수신 모듈(142)은 통합제어 서버(300)로부터 OCF에서 지원하는 CoAP 통신 프로토콜로 바인딩된 특정 IoT 디바이스에 대한 제어 메시지를 수신하고, 페이로드를 추출하여 제어 변환 모듈(141)로 전달한다.

제어 전송 모듈(143)은 제어 변환 모듈(141)로부터 전달된 메시지를 OCF에서 지원하는 CoAP 통신 프로토콜로 바인딩하여 통합제어 서버(300)로 전송하고, 또한 통합제어 서버(300)로부터 수신된 제어 메시지를 프로토콜 변환부(110)를 통하여 전달할 IoT 디바이스에서 사용하는 프로토콜로의 변환 및 통신 프로토콜의 바인딩을 마친 후 전달한다.

전술한 도 7의 예에서, IoT 디바이스의 리소스에 현재 시간(/time)에 해당하는 리소스가 더 포함되어 있고, 만일 통합 제어서버(300)에서 오전 6시가 되고 해당 IoT에 해당하는 스마트 조명이 꺼져 있는 경우, 조명을 키고 밝기를 20으로 하고, 시간이 5분씩 경과함에 따라 밝기를 20씩 증가시켜서 100까지 증가하도록 하는 제어 명령이 설정되어 있는 경우, 제어 관리부(140)는 IoT 디바이스로부터 수신되는 메시지를 OCF 기반의 프로토콜을 통해 통합 제어서버(300) 측에 전송하고, 이 안의 리소스들에 기초하여 상기 제어 명령이 트리거 되는 경우 제어 관리부(140)는 통합 제어서버(300)로부터 제어 메시지를 수신하여 (예를 들어, 아침 6시이고 조명이 꺼져 있는 경우 조명을 키고 밝기를 20으로 하라는 OCF 기반의 프로토콜을 이용한 제어 메시지) 해당 IoT 디바이스 측에 전송한다. 또한, 제어 관리부(140)는 시간이 5분 경과시마다 밝기를 20 증가하라는 제어 메시지를 밝기가 100이 될 때까지 통합 제어서버(300)로부터 수신하여 해당 IoT 디바이스 측에 전송한다.

위험탐지부(150)는 IoT 게이트웨이(100)가 연동된 IoT 디바이스(200)와 통신하는 과정에서 위험요소를 탐지하고 차단한다. 위험탐지부(150)는 데이터베이스(160)에 저장된 접속을 허용하는 IoT 디바이스의 리스트인 화이트리스트를 구비하고, IoT 게이트웨이(100)와 통신하는 IoT 디바이스 간의 네트워크 패킷을 상시 탐지하여 신규 IoT 디바이스가 IoT 게이트웨이(100)에 새로이 등록하고자 하는 최초 등록에 해당하는 경우를 제외하고는 화이트리스트에 등록되지 않은 IoT 디바이스가 패킷을 보내온 경우 이를 차단할 수 있으며, 정상적으로 최초 등록이 이루어진 경우 해당 IoT 디바이스를 화이트리스트에 추가적으로 등록할 수 있다. 화이트리스트는 IoT 디바이스 정보일 수도 있고 또는 별개로 관리될 수 있다.

또한, 위험 탐지부(150)는 디바이스 관리부(120)로부터 위험 탐지에 활용할 수 있는 룰셋 정보를 전달받아 저장하고, IoT 디바이스로부터 수신된 데이터를 저장된 룰셋 정보를 활용하여 정상 범위 내에 포함되지 않는 경우 보안 위험이 발생한 것으로 판단하고 이 경우 해당 IoT 디바이스와의 통신을 차단하고 통합 제어서버(300) 측에 발생된 IoT 디바이스의 위험 정보 및 이로 인해 차단되었다는 알리는 메시지를 전달할 수 있다.

여기서 위험 탐지에 사용될 수 있는 룰셋 정보는 네트워크 상의 위험 탐지에 사용되는 다양한 방법을 포함할 수 있으며, 일 예로서 동일한 디바이스 식별번호를 가지면서 디바이스의 타입 등 다른 정보가 변경된 데이터가 수신되거나, 생성된 가상 리소스 모델 객체의 특정 리소스의 범위를 벗어나는 값이 전달되는(예컨대, 도 7의 예에서, 리소스 /dimming에 해당하는 값이 100을 초과하거나 음수인 경우 등) 경우 등을 위험 탐지에 사용될 수 있는 룰셋 정보에 포함할 수 있으나 반드시 이에 한정되는 것은 아니고, 공지되어 있는 네트워크 상의 위험 탐지에 사용되는 다양한 방법을 포함할 수 있다.

데이터베이스(160)는 IoT 게이트웨이(100)에 로컬(local)로 또는 원격(remote)로 연결되고 IoT 게이트웨이(100)의 각 구성요소가 사용, 학습, 업데이트 그리고 임시적으로 또는 영구적으로 생성하는 다양한 데이터를 저장하고 있으며, 그 일 예로서 IoT 디바이스 정보, IoT 디바이스의 타입 및 사용하는 프로토콜의 활용의 판단에 사용되는 룰셋, 위험탐지부에 의해 사용되는 화이트리스트 및 룰셋 등을 포함할 수 있으나 이에 한정되는 것은 아니다.

도 6은 본 발명의 일 실시예에 따라 IoT 게이트웨이가 IoT 디바이스 간의 연동을 설명하기 위한 흐름도이다.

도 6을 참조하면, IoT 디바이스(200)가 메시지를 송신하면 IoT 게이트웨이(100)가 이를 수신(S100)하고, 바인딩된 통신 프로토콜을 확인 및 해석하고 이로부터 페이로드를 추출(S200)한다. 여기서 통신 프로토콜은 무선이나 유선인 시리얼 방식을 통한 MQTT, HTTP, RS-485, CoAP, WebSocket과 같은 다양한 프로토콜 중 어느 하나일 수 있고, 단계(S200)에서 IoT 게이트웨이(100)는 각 프로토콜의 규격에 대한 정보와 수신한 정보로부터 헤더를 비교하는 방식으로 어떠한 통신 프로토콜이 바인딩되었는지를 확인하고, 이로부터 페이로드를 추출할 수 있다.

단계(S300)에서, IoT 게이트웨이(100)는 추출된 페이로드를 데이터베이스(160)에 저장된 IoT 디바이스 정보와 대비하여 IoT 디바이스 타입 및 사용하는 프로토콜을 확인한다. 매칭되는 데이터가 IoT 디바이스 정보에는 있으나 아직 생성된 가상 객체가 없는 경우(S400), IoT 게이트웨이(100)는 OCF 프레임워크 기반의 가상의 리소스 모델 객체를 생성하고 수신된 페이로드를 OCF 기반의 프로토콜로 변환한다(S500). 생성된 가상 객체가 있다면 별도의 가상 객체 생서 없이 수신된 페이로드의 프로토콜 변환만을 수행한다(S500).

한편, 단계(S300)에서 매칭되는 데이터가 IoT 디바이스 정보에 없는 경우 최초 등록하는 IoT 디바이스로 판단하고, 추출된 페이로드로부터 MAC(media Access Control) 정보 또는 UUID(Universally Unique Identifier) 등 IoT 디바이스의 고유 식별자, 제조사 정보, 사용하는 서비스포트 정보, 모델명 등 다양한 정보를 획득하고 IoT 게이트웨이(100)가 학습하여 저장해 둔 룰셋을 기반으로 IoT 디바이스의 타입 및 사용하는 프로토콜을 판단(S600)한다. 단계(S600)에서 획득한 정보 및 판단된 정보 중 적어도 일부는 룰셋에 반영 및 머신러닝 방식을 기초로 한 학습에 이용할 수 있으며, 단계(S600)에서 판단된 IoT 디바이스의 타입 및 사용하는 프로토콜을 기초로 단계(S400)으로 이동하여 가상 객체 생성(S600) 및 페이로드의 OCF 기반의 프로토콜 변환 수행(S500) 단계를 수행할 수 있다.

다음으로, IoT 게이트웨이(100)는 새로 가상 객체가 생성된 경우 연동된 IoT 디바이스(200)에 대한 정보를 매칭할 수 있도록 디바이스 ID를 생성하고 이를 데이터베이스(160)에 저장된 IoT 디바이스 정보에 추가(S700)한다. 한편, IoT 게이트웨이(100)는 ID가 부여된 생성된 가상 객체에 OCF 기반의 프로토콜로 변환된 정보를 매핑(S800)한다. 이를 통해 생성된 OCF 프레임워크 기반의 가상의 리소스 모델 객체에는 연동되는 IoT 디바이스(200)의 타입에 맞추어 상태 정보 등 필요한 모든 정보가 사용하는 프로토콜에 관계없이 매핑되어 저장되어 있고, 도 6에 도시되지 않은 통합 제어서버(300)로 OCF 표준을 지원하는 프로토콜을 통해 메시지 전달할 수 있다.

한편, 도 6에 도시되지 않은 통합 제어서버(300)로부터 특정 IoT 디바이스(200)에 대한 제어 메시지가 IoT 게이트웨이(100)로 전송된 경우, IoT 게이트웨이(100)는 제어 메시지로부터 페이로드를 추출(S900)한다. 여기서 통합 제어서버(300) 및 IoT 게이트웨이(100) 모두 OCF 표준을 지원하므로 제어 메시지는 OCF 표준이 지원하는 통신 프로토콜인 CoAIP를 사용하여 전송된다. 다음으로, IoT 게이트웨이(100)는 페이로드로부터 획득할 수 있는 정보와 데이터베이스(160)에 저장된 IoT 디바이스 정보를 비교하여 제어 메시지가 전송될 특정 IoT 디바이스(200)를 식별하고, 특정 IoT 디바이스(200)가 사용하는 프로토콜에 맞춰 제어 메시지를 변환(S1000)한다. 이후, 변환된 제어 메시지는 특정 IoT 디바이스(200)가 사용하는 통신 프로토콜에 맞춰 바인딩된 후 특정 IoT 디바이스(200)로 전송(S1100)되고 특정 IoT 디바이스(200)는 수신한 제어 메시지에 기초하여 요청된 제어 내용을 수행한다.

이상과 같이 본 발명이 속하는 분야에서 통상의 지식을 가진 자라면 이러한 명세서의 기재로부터 다양한 수정 및 변형이 가능함을 이해할 수 있다. 그러므로 본 발명의 범위는 설명된 실시예에 국한되어 정해져서는 아니되며 후술하는 특허청구범위뿐 아니라 이 특허청구범위와 균등한 것들에 의해 정해져야 한다.

100: IoT 게이트웨이 110: 프로토콜 변환부
111: 통신 프로토콜 처리 모듈 112: 프로토콜 변환 모듈
113: 가상모델 객체 생성 모듈 114: 디바이스 정보 전달 모듈
120: 디바이스 관리부 121: 디바이스 생성 모듈
122: 디바이스 패킷 정보 수집 모듈 123: 디바이스 관리 모듈
130: 디바이스 분석 머신러닝부 140: 제어 관리부
141: 제어 변환 모듈 142: 제어 수신 모듈
143: 제어 전송 모듈 150: 위험 탐지부
160: 데이터베이스 200: IoT 디바이스
300: 통합제어서버

Claims

다양한 프로토콜을 갖는 IoT 디바이스와의 호환성을 제공하는 IoT 게이트웨이에 있어서,
제1 IoT 디바이스로부터 수신한 메시지에 기초하여 상기 제1 IoT 디바이스의 타입(Type) 및 사용하는 프로토콜을 확인하고, OCF 프레임워크 기반의 가상의 리소스 모델 객체의 생성 및 상기 수신된 메시지의 OCF 기반 프로토콜로의 변환을 수행하는 프로토콜 변환부;
상기 생성된 리소스 모델 객체에 디바이스 ID를 부여하고 상기 OCF 기반 프로토콜로 변환된 상기 수신된 메시지와 매핑하는 디바이스 관리부; 및
상기 생성된 리소스 모델 객체를 OCF 기반 프로토콜을 이용하여 통합제어서버로 전송하는 제어 관리부;를 포함하는, IoT 게이트웨이.
제1항에 있어서,
상기 프로토콜 변환부가 상기 수신한 메시지에 기초하여 상기 제1 IoT 디바이스의 타입(Type) 및 사용하는 프로토콜을 확인할 수 없는 경우, 상기 디바이스 관리부는 상기 수신된 메시지로부터 소정 정보를 획득하고, 상기 획득한 정보 및 미리 학습되어 저장된 룰셋(Ruleset)에 기초하여 상기 제1 IoT 디바이스의 타입 및 사용하는 프로토콜을 더 판단하는, IoT 게이트웨이.
제2항에 있어서, 상기 IoT 게이트웨이는,
상기 룰셋을 학습하고 저장하는 디바이스 분석 머신러닝부를 더 포함하는, IoT 게이트웨이.
제3항에 있어서,
상기 획득한 정보는 상기 제1 IoT 디바이스의 MAC(media Access Control) 정보 또는 UUID(Universally Unique Identifier), 제조사 정보, 사용하는 서비스포트 정보, 모델명 중 적어도 하나인, IoT 게이트웨이.
제1항에 있어서, 상기 IoT 게이트웨이는,
상기 제1 IoT 디바이스로부터 수신한 메시지로부터 위험요소를 탐지하고 상기 제1 IoT 디바이스를 차단하는 위험탐지부를 더 포함하는, IoT 게이트웨이.