2016년 8월 12일 금요일

[AWS]What Is AWS IoT? - AWS IoT

AWS IoT
Developer Guide

What Is AWS IoT?

AWS IoT 는 인터넷에 연결된 사물(센서, 액추에이터, 임베디드 장치 또는 스마트 장치와 같은) 과 AWS 클라우드 사이에 안전한 양방향의 통신을 제공한다. 이는 당신이 복수개의 장치로부터 원격측정 데이터를 수집하고 데이터를 저장, 분석할 수 있게 한다. 또한 당신은 사용자가 그들의 폰이나 태블릿으로 이들 장치를 제어할 수 있는 애플리케이션을 작성할 수 있다.

AWS IoT Components

AWS IoT 는 다음의 컴포넌트들로 구성된다:
  • Message broker—사물과 AWS Iot 애플리케이션 서로 간에 메시지를 퍼블리시하고 수신하기 위한 안전한 메커니즘을 제공한다. 퍼블리시와 구독하기 위해 직접 MQTT 프로토콜을 사용하거나 WebSockets 상에 MQTT를 사용할 수 있다: 퍼블리시를 위해 HTTP REST를 사용할 수 있다.
  • Rules engine—다른 AWS 서비스들과 메시지 처리와 통합을 제공한다. payloads로부터 데이터를 선택하고 데이터를 처리하고 Amazon S3, Amazon DynamoDB, 그리고 AWS Lambda와 같이 다른 서비스로 데이터를 보내기 위해 SQL 기반의 언어를 사용할 수 있다. 또한 다른 구독자들에게 메시지를 republish 하기 위해 message broker를사용할 수 있다.
  • Thing registry—종종 Device Registry로 언급된다. 각각의 사물과 연관된 리소스들을 조직해라. 사물을 등록하고 사물들과 세개의 custom attributes와 연관지어라. 또한 당신의 사물을 관리하고 고장수리하는 능력을 개선학기 위해 각 사물들과 함께 certificates와 MQTT 클라이언트 ID들을 연관지을 수 있다.
  • Thing Shadows service—AWS 클라우드에서 당신 사물의 지속적인 표현을 제공한다. 당신은 업데이트된 상태 정보를 thing shadow에 퍼블리싱할 수 있다. 그리고 당신의 사물은 접속되었을 때 그것의 상태를 동기화할 수 있다.  또한 당신의 사물은 애플리케이션이나 장치에서 사용할 수 있도록 thing shadow에 그들의 현재 상태를 퍼블리싱할 수 있다.
  • Thing shadow— 종종 device shadow라고도 불린다. 사물을 위한 현재 상태 정보를 저장하거나 받아올 때 JSON 문서가 사용된다(device, app, 등등)
  • Device gateway—장치가 AWS IoT와 안전하고 효율적으로 통신할 수 있도록 한다.
  • Security and Identity service—AWS cloud 상에서 보안을 위해 공유 책임을 제공한다. 당신의 사물은 message broker로 데이터를 안전하게 보내기 위해 인증서(자격, credentials)를 안전하게 유지해야 한다. message broker와 rules engine은 장치와 다른 AWS 서비스들에 데이터를 안전하게 보내기 위해 AWS security features를 사용한다.

How to Get Started with AWS IoT

Accessing AWS IoT

AWS IoT 는 당신의 사물을 생성하고 상호작용하기 위해 다음의 인터페이스를 제공한다:
  • AWS Command Line Interface (AWS CLI)—Window, MAC 그리고 리눅스 상에서 AWS IOT 명령을 실행한다. 시작하려면 AWS Command Line Interface User Guide 보아라. AWS IoT를 위한 명령에 대해 더 많은 정보는 AWS Command Line Interface Reference에 있는 iot 를 보아라. 
  • AWS SDKs—특정 언어의 API를 이용해 IoT 애플리케이션을 생성해라. 더 많은 정보는 AWS SDKs and Tools 를 보아라.
  • AWS IoT API—HTTP 도는 HTTPS 요청을 이용해 당신의 IoT 애플리케이션을 만들어라. AWS IoT를 위한 API 액션에 대한 더 많은 정보는 AWS IoT API Reference에 있는 Actions 를 보아라. 
  • AWS IoT Thing SDK for C—마이크로 컨트롤러와 같은 리소스가 제약되는 사물을 위한 IoT 애플리케이션을 만들어라.
AWS IoT 는 다음의 AWS 서비스와 바로 통합된다.
AWS IoT integrates directly with the following AWS services:
  • Amazon Simple Storage Service—AWS 클라우드 상에서 scalable storage를 제공한다. 더많은 정보는 Amazon S3 를 보아라.
  • Amazon DynamoDB—managed NoSQL 데이터베이스를 제공한다. 더 많은 정보는 Amazon DynamoDB 를 보아라.
  • Amazon Kinesis— 거대한 규모의 실시간 스트리밍 데이터처리를 가능케한다. 더 많은 정보는 Amazon Kinesis 를 보아라.
  • AWS Lambda—이벤트에 응답하는 아마존 EC2 상의 가상 서버에서 당신의 코드를 실행해라. 더 많은 정보는 AWS Lambda 를 보아라. 
  • Amazon Simple Notification Service—노티피케이션을 보내고 수신해라. 더 많은 정보는 Amazon SNS 를 보아라.
  • Amazon Simple Queue Service—애플리케이션에 의해 가져올 데이터를 큐에 저장해라. 더 많은 정보는 Amazon SQS 를 보아라.

작성자: 시간: 댓글 없음:
라벨:

2016년 8월 11일 목요일

[AWS]Message Broker for AWS IoT - AWS IoT

AWS IoT
Developer Guide

Message Broker for AWS IoT

AWS IoT message broker는 AWS Iot 로 그리고 로부터 메시지를 보내거나 받을 수 있게 해주는 pub/sub broker service이다. AWS IoT와 통신할 때, 클라이언트는 message broker는 그  "Sensor/temp/room1." 과 같은 토픽이 지정된 메시지를 보낸다. message brker는 차례로, 그 토픽을 위한 메시지를 받도록 등록된 모든 클라이언트에게 메시지를 보낸다. 메시지를 보내는 행위는 publishing이라고 부른다. 토픽에 대해 메시지를 수신하겠다고 등록하는 행위를 subscribing이라고 한다.

토픽 namespace 는 각 AWS account와 region 쌍에 따라 격리된다. 예를 들어, 한 AWS account 를 위한 Sensor/temp/room1 토픽은 다른 AWS account 를 위한 "Sensor/temp/room1"에 대해 독립적이다. 이는 regions에 대해서도 동일하다. us-east-1에 있는 동일한 AWS account를 위한 Sensor/temp/room1 토픽은 us-west-2에 있는 동일한 토픽에 대해 독립적이다. AWS Iot는 AWS account와 regions을 가로질러 메시지를 송수신하는 것을 지원하지 않는다.

message broker는 모든 클라이언트 세션과 각 세션에 대한 구독 리스트를 유지한다. 메시지가 토픽에 대해 퍼블리시되면 broker는 토픽에 대해 매핑되는 구독 세션들을 체크한다. 그리고 나서 broker는 publish message를 현재 연결된 클라이언트를 가지고 있는 모든 세션으로 전달한다.
작성자: 시간: 댓글 없음:
라벨:

[AWS]Protocols - AWS IoT

AWS IoT
Developer Guide

Protocols


message broker는 발행하고 구독을 위한 MQTT 프로토콜과 발행을 위한 HTTPS 프로토콜의 사용을 지원한다. 두 프로토콜 모두 IP v4와 IP v6를 통해 지원된다. message broker는 또한 WebSocket 프로토콜을 통해 MQTT를 지원한다.

MQTT는 constrained device를 위해 고안된 널리 채용되는 가벼운 메시징 프로토콜이다. 더 많은 정보는 MQTT 를 방문해라. AWS IoT message broker 구현은 MQTT 버전 3.1.1에 기반하고 있지만 다음과 같이 규격으로부터 벗어난다:
  • AWS IoT에서 Qaulity of Service (QoS) 0으로 topic에 구독하는 것은 메시지가 0번 이상 전달될 것이라는 것을 의미한다. 메시지는 한 번 이상 전달될 수 있다. 메시지는 다른 ID를 가지고 한번 이상 전달될 것이다. 이러한 경우 DUP 플래그는 셋팅되지 않는다.
  • AWS IoT는 QoS 2로 배포하고 구독하는 것을 지원하지 않는다. AWS IoT message broker는 QoS 2 가 요청될 때 PUBACK 나 SUBACK를 보내지 않는다.
  • topic 에 대해 구독하고 발행하기 위한 QoS 레벨은 서로 관련이 없다. 한 클라이언트는 다른 클라이언트가 QoS0으로 동일한 topic에 대해 발행하더라도  QoS 1을 이용해 topic을 구독할 수 있다.
  • connection 요청에 대해 응답할 때 message broker는 CONNACK 메시지를 보낸다. 이 메시지는 connection이 이전 세션을 재시작하는지를 가리키는 플래그를 포함한다. 이 플래그의 값은 두 MQTT 클라이언트가 동시에 동일한 클라이언트 ID를 가지고 접속할 때 부정확할 수 있다.
  • 클라이언트가 topic을 구독할 때 message broker가 SUBACK를 보내는 시간과 클라이언트가 새로운 매칭 메시지를 수신하기 시작하는 시간 사이에 지연이 발생할 수 있다.
  • MQTT 규격은 발행인이 broker가 topic에 대해 보낸 마지막 메시지를 유지하고 그것을 모든 미래 topic 구독자에게 보내도록 요청하는 것을 제공한다. AWS IoT는 메시지를 유지하는 것을 지원하지 않는다. 메시지를 유지하는 요청이 만들어지면 접속이 해제된다.

  • The message broker uses the client ID to identify each client. The client ID is passed in from the client to the message broker as part of the MQTT payload. Two clients with the same client ID are not allowed to be connected concurrently to the message broker. When a client connects to the message broker using a client ID that another client is using, a CONNACK message will be sent to both clients and the currently connected client will be disconnected.
  • The message broker does not support persistent sessions (clean session set to 0). All sessions are assumed to be clean sessions and messages are not stored across sessions. If an MQTT client sends a message with the clean session attribute set to false, the client will be disconnected.
  • On rare occasions, the message broker may resend the same logical publish message with a different packet ID.
  • The message broker does not guarantee the order in which messages and ACK are received.

HTTP

The message broker supports clients connecting with the HTTP protocol using a REST API. Clients can publish by sending a POST message to <AWS IoT Endpoint>/topics/<url_encoded_topic_name>?qos=1".

MQTT Over the WebSocket Protocol

AWS IoT supports MQTT over the WebSocket protocol to enable browser-based and remote applications to send and receive data from AWS IoT-connected devices using AWS credentials. AWS credentials are specified using AWS signature version 4. For more information, see AWS Signature Version 4. WebSocket support is available on port tcp:443, which allows messages to pass through most firewalls and web proxies.
A WebSocket connection is initiated on a client by sending an HTTP GET request. The URL you use is of the following form:
wss://<endpoint>.iot.<region>.amazonaws.com/mqtt
wss
Specifies the WebSocket protocol.
endpoint
Your AWS account-specific AWS IoT endpoint. You can use the AWS IoT CLI describe-endpoint command to find this endpoint.
region
The AWS region of your AWS account.
mqtt
Specifies you will be sending MQTT messages over the WebSocket protocol.
When the server responds, the client sends an upgrade request to indicate to the server it will communicate using the WebSocket protocol. After the server acknowledges the upgrade request, all communication is performed using the WebSocket protocol. The WebSocket implementation you use acts as a transport protocol. The data you send over the WebSocket protocol are MQTT messages.

Using the WebSocket Protocol in a Web Application

The WebSocket implementation provided by most web browsers does not allow the modification of HTTP headers, so you must add the signature version 4 information to the query string. For more information, see Adding Signing Information to the Query String.
The following JavaScript defines some utility functions used in generating a signature version 4 request.
  /**
   * utilities to do sigv4
   * @class SigV4Utils
   */
  function SigV4Utils(){}

  SigV4Utils.sign = function(key, msg){
    var hash = CryptoJS.HmacSHA256(msg, key);
    return hash.toString(CryptoJS.enc.Hex);
  };

  SigV4Utils.sha256 = function(msg) {
    var hash = CryptoJS.SHA256(msg);
    return hash.toString(CryptoJS.enc.Hex);
  };

  SigV4Utils.getSignatureKey = function(key, dateStamp, regionName, serviceName) {
    var kDate = CryptoJS.HmacSHA256(dateStamp, 'AWS4' + key);
    var kRegion = CryptoJS.HmacSHA256(regionName, kDate);
    var kService = CryptoJS.HmacSHA256(serviceName, kRegion);
    var kSigning = CryptoJS.HmacSHA256('aws4_request', kService);
    return kSigning;
  };

To create a Signature Version 4 request
  1. Create a canonical request for Signature Version 4.
    The following JavaScript code creates a canonical request:
    var time = moment.utc();
var dateStamp = time.format('YYYYMMDD');
var amzdate = dateStamp + 'T' + time.format('HHmmss') + 'Z';
var service = 'iotdevicegateway';
var region = this.options.regionName;
var secretKey = this.options.secretKey;
var accessKey = this.options.accessKey;
var algorithm = 'AWS4-HMAC-SHA256';
var method = 'GET';
var canonicalUri = '/mqtt';
var host = this.options.endpoint;

var credentialScope = dateStamp + '/' + region + '/' + service + '/' + 'aws4_request';
var canonicalQuerystring = 'X-Amz-Algorithm=AWS4-HMAC-SHA256';
canonicalQuerystring += '&X-Amz-Credential=' + encodeURIComponent(accessKey + '/' + credentialScope);
canonicalQuerystring += '&X-Amz-Date=' + amzdate;
canonicalQuerystring += '&X-Amz-SignedHeaders=host';

var canonicalHeaders = 'host:' + host + '\n';
var payloadHash = SigV4Utils.sha256('');
var canonicalRequest = method + '\n' + canonicalUri + '\n' + canonicalQuerystring + '\n' + canonicalHeaders + '\nhost\n' + payloadHash;
    console.log('canonicalRequest ' + canonicalRequest);
  2. Create a string to sign, generate a signing key, and sign the string.
    Take the canonical URL you created in the previous step and assemble it into a string to sign. You do this by creating a string composed of the hashing algorithm, the date, the credential scope, and the SHA of the canonical request. Next, generate the signing key and sign the string, as shown in the following JavaScript code.
    
    var stringToSign = algorithm + '\n' +  amzdate + '\n' +  credentialScope + '\n' +  SigV4Utils.sha256(canonicalRequest);
    var signingKey = SigV4Utils.getSignatureKey(secretKey, dateStamp, region, service);
    var signature = SigV4Utils.sign(signingKey, stringToSign);
  3. Add the signing information to the request.
    The following JavaScript code shows how to add the signing information to the query string.
    
    canonicalQuerystring += '&X-Amz-Signature=' + signature;
    var requestUrl = 'wss://' + host + canonicalUri + '?' + canonicalQuerystring;
  4. If you have session credentials (from an STS server, AssumeRole, or Amazon Cognito), append the session token to the end of the URL string after signing:
    requestUrl += "&X-Amz-Security-Token=" + encodeURIComponent(sessionToken);
  5. Open the WebSocket.
    The following JavaScript code shows how to create a Paho MQTT client and call CONNECT to AWS IoT. The endpoint argument is your AWS account-specific endpoint. The clientId is a text identifier that is unique among all clients simultaneously connected in your AWS account.
    var client = new Paho.MQTT.Client(requestUrl, clientId);
var connectOptions = {
    onSuccess: function(){
        // connect succeeded
    },
    useSSL: true,
    timeout: 3,
    mqttVersion: 4,
    onFailure: function() {
        // connect failed
    }
};
client.connect(connectOptions);

Using the WebSocket Protocol in a Mobile Application

We recommend using one of the AWS IoT Device SDKs to connect your device to AWS IoT when making a WebSocket connection. The following AWS IoT Device SDKs support WebSocket-based MQTT-connections to AWS IoT:
You can find a reference implementation for connecting a web application to AWS IoT using MQTT over the WebSocket protocol here: AWS Labs WebSocket sample.
If you are using a programming or scripting language that is not currently supported, any existing WebSocket library can be used as long as the initial WebSocket upgrade request (HTTP POST) is signed using AWS Signature Version 4. Some MQTT clients, such as Eclipse Paho for JavaScript, support the WebSocket protocol natively.

작성자: 시간: 댓글 없음:

[AWS]사물인터넷이란 무엇입니까?

Internet of Things(IoT) 라는 용어는 RFID 에서 근무하는 영국의 기술 개척자 Kevin Ashton에 의해 만들어졌다. 그는 물리적 세계와 인터넷을 연결해주는 어느 곳에나 존재하는 센서 시스템을 상상했다.사물, 인터넷 그리고 연결은 IoT의 세가지 핵심 요소이지만, 가치는 자기 강화 그리고 자기 개선 시스템 내에서 물리세계와 디지털 세계 간의 간극을 이어주는데 있다.IoT 는 사물, 유생물 또는 무생물을 컨텍스트를 제공하는 고유한 식별자를 가지고
인터넷에 연결함으로서 시스템을 생성한다. 이는 네트워크에 장치 자체와 그들 환경이 보여지도록 한다. 풍부한 데이터 집합을 갖추고 향상된 분석툴을 이용하여 IoT는 세상에 대한 거대한 통찰력을 제공한다: 풍력 발전용 날개의 진동을 측정하고 실시간 분석을 수행하여 날개가 멈추기 전에 유지보수의 필요성을 결정한다. 아무도 없는 층의 조명을 제어함으로써 빌딩의 에너지 소비를 감소시킨다. 또는 멈추고 사고를 피하기 위한 결정을 내리기 위한 주변 정보를 처리하는 자율주행 차량을 만들 수 있다. IoT를 통해 물리 세계에 대한 수집 정보는 더 좋은 효율성, 새로운 비즈니스 모델, 적은 오염, 그리고 더 좋은 건강을 위한 입력이 된다.

Internet of Things Resources

IoT 를 둘러싼 많은 광고 미디어들이 존재한다. 단지 그것으로 끝인가? 우리는 IoT
에대한 물음들을 탐색하는데 도움을 주는 리소스들을 수집하여 모아 놓았다.

AWS IoT

AWS Iot는 장치를 클라우드에 연결하기 위한 목적으로 만들어진 관리 서비스이다.
그래서 고객들은 그들의 제품과 솔루션 하부의 것들은 신경쓰지 않고 제품과 솔루션을 더 좋게 만드는데만 집중할 수 있다.

Internet of Things on AWS Blog

AWS 공식 블로그에 있는 Internet of Things 는 우리가 IoT와 업계 리더들에 대한
물음, 그리고 어떻게 클라우드에서 IOT 솔루션을 배치할 수 있는지 답하는 곳이다.


Whitepapers

칼라우드를 위한 Iot 솔루션을 개발하기 위한 전략에 대해 더 많은 것을 배우려면
우리의 백서를 다운로드 하세요.
작성자: 시간: 댓글 없음:
라벨:

2016년 8월 10일 수요일

oneM2M과 산업표준플랫폼의 상호연동 표준화 동향



oneM2M과 산업표준플랫폼의 상호연동 표준화 동향

By 조상록 기자 -


2269

0
oneM2M과 산업표준플랫폼의 상호연동 표준화 동향
전자부품연구원(KETI) 임베디드SW융합연구센터 원광호 센터장
1. 머리말
사물인터넷은 현실세계와 가상세계에 존재하는 사물기기(센서, 액츄에이터)들을 네트워크로 상호 연결해 사람과 사물, 사물과 사물간에 언제 어디서나 서로 소통할 수 있는 미래 인터넷 기술이다.
시장조사업체 가트너의 조사 결과에 따르면, 2020년까지 사물인터넷 시장은 3,000억 달러의 매출 규모로 성장하고 인터넷에 연결되는 사물기기들의 수가 250억~2000억 개를 넘어설 것으로 예상하고 있다. 이러한 기술 흐름을 보여주듯 전미가전협회(CEA) 주최로 개최되는 CES 2015 행사에서는 ‘사물인터넷’, ‘Connectivity’, ‘초연결사회’와 같은 단어들이 주요 화두로 하여 스마트홈, 웨어러블 기기, 스마트카, 드론 비행체 등의 분야에서 사물기기들의 상호연결(Connectivity)을 바탕으로 신규 제품 및 서비스들이 선보여졌다.
이처럼 현재 우리는 주변의 사물들이 인터넷에 연결되고 사물들이 서로 연동돼 지능적인 서비스를 제공하는 미래 인터넷의 세상으로 변화하는 길목에 서 있다고 할 수 있다.
이와 관련해 사물인터넷 시장의 주도권을 획득하기 위한 다양한 시도들이 나타나고 있으며, 대표적으로 올신 연합(AllSeen Alliance), OIC(Open Internet Consortium), IPSO(IP for Smart Objects) Alliance와 같은 산업체 컨소시엄을 중심으로 그리고 한편 oneM2M 과 같은 국제 표준개발단체를 중심으로 관련 표준 플랫폼 기술 개발이 활발하게 진행되고 있다.
이러한 단체들은 과거의 파편화된 수직적 플랫폼 개발을 지양하고, 수평적 공통 사물인터넷 플랫폼 개발을 통한 저비용/규모의 경제 달성을 꾀하고 있다.
그리고 각 단체들은 사물인터넷 기술의 디바이스 간, 플랫폼 간의 상호 연동 기반 기술의 중요성을 인지하고 상호호환성을 주요 목표로 표준 기술개발이 이뤄지고 있는 상황이다. 또 현재 산업체 컨소시엄 및 국제표준단체에서 개발된 플랫폼을 기반으로 시장 주도권을 확보하기 위한 경쟁이 진행 중이며, 아직 어느 플랫폼도 시장의 주도권을 장악하지 못하는 상황에서 각 표준단체들은 서로의 플랫폼과 디바이스의 상호호환성을 지원하기 위한 상호연동(Interworking) 솔루션 개발을 고려하고 있다.
이와 관련해 oneM2M은 2015년 1월 릴리즈 1.1 표준규격을 공개했고, 가장 앞서 AllJoyn 플랫폼 그리고 LWM2M 디바이스 기술과의 상호연동 솔루션 개발 워크아이템(Work Item)을 발의하고 해당 기술 개발을 진행 중에 있다. 본 고에서는 oneM2M을 중심으로 한 사물인터넷 플랫폼 표준개발 동향 및 oneM2M의 상호연동 워크아이템 개발 동향에 대해서 살펴본다.
<사물인터넷 플랫폼 표준 동향>
oneM2M과 산업표준플랫폼의 상호연동 표준화 동향

2. 본론
 1) 산업표준플랫폼 동향
올신 연합(AllSeen Alliance)은 2013년 12월 퀄컴, LG전자, 하이얼, 샤프, 마이크로소프트, 파나소닉 등 51개 기업이 참여해 결성된 산업체 컨소시엄이다.
올신 연합의 오픈소스 사물인터넷 플랫폼인 AllJoyn 프레임워크는 퀄컴에서 개발해 2011년 Mobile World Congress에 공개한 것으로, 2013년 12월 리눅스 재단에 소스를 이관해 현재 오픈소스 프로젝트로 개발되고 있다.
AllJoyn은 로컬 네트워크 환경에서 AllJoyn이 탑재된 디바이스들 간 근접기반(Proximity-based)의 서비스 광고(Advertisement) 및 검색(Discovery) 그리고 피어투피어(Peer-to-Peer) 데이터 전달 기능을 지원하고 있으며, AllJoyn 프레임워크의 구조는 데이터 전송을 담당하는 Core 프레임워크와 연결, 구성, 통지 등의 서비스 기능을 제공하는 Service 프레임워크로 구성되고, Publish/Subscribe 스타일 API를 기반으로 AllJoyn기반의 애플리케이션 개발 편의성을 제공하고 있다.
AllJoyn을 통해서 올신 연합은 제조사, 네트워크, 오퍼레이팅 시스템에 상관없이 동작할 수 있는 호환성을 지원하며 이를 바탕으로 AllJoyn 기반의 상호 연결 가능한 기기들과 애플리케이션들을 확산시키기 위한 방향으로 플랫폼을 발전시키고 있다.
Open Interconnect Consortium(OIC)는 인텔, 삼성전자, Atmel, 윈드리버 등을 주축으로 하여 2014년 7월 발족된 산업체 컨소시엄으로서, 현재 사물인터넷 디바이스들을 연결하기 위한 요구사항 및 상호 운용성을 보장하기 위한 플랫폼 개발을 진행 중에 있다.
OIC는 플랫폼의 주요 기능은 디바이스 검색, 데이터 전달, 디바이스 관리, 데이터 관리, 보안 기능이고 이를 통해 디바이스에 대한 상호 운용, 서비스 레벨 상호 운용성이 가능하도록 하고 있다. 그리고 OIC는 2014년 12월, 리눅스 재단(Linux Foundation)이 주관하는 오픈소스 프로젝트로서 OIC 표준이 구현된 소프트웨어인 IoTivity 를 공개했다.
IoTivity는 OIC 표준규격의 참조 구현(Reference Implementation)을 지원하는 것으로서 RESTful API 및 리눅스, 윈도우, iOS, 타이젠의 다양한 운영체제를 지원하고 있다. 향후 OIC 표준 완성 규격과 해당 참조 구현인 IoTivity 1.0은 2015년 말 내에 공개 예정으로 AllJoyn에 비해 후발주자로 출발한 것에 대한 만회를 위해 IoTivity 참조 구현, 인증프로세스 등을 통해 OIC 표준 플랫폼을 시장에 빠르게 확산시키기 위한 전략을 취하고 있다.
IPSO (IP for Smart Object) Alliance는 IETF를 통해서 개발된 IPv6 프로토콜 기반의 디바이스와 디바이스간의 End-to-End 연결성 제공 기술에 대해 스마트 에너지, 스마트 시티, 헬스케어, 홈 자동화 등 다양한 애플리케이션 서비스 도메인에서 해당 기술의 활용을 증진시키기 위해 2008년 결성된 산업체 컨소시엄이다. 이를 위해 다양한 서비스 산업군에서 적용하기 쉽도록 기술백서 및 해설서 작업과 더불어 상호호환성 테스트 이벤트 등을 개최해왔다. 2011년 IPSO Alliance내에 Smart Object Committee를 구성해 사물인터넷에 존재할 수 있는 센서, 액츄에이터와 같은 스마트 오브젝트들에 대한 타입, 리소스에 대한 모델을 정의한 Smart Objects Starter Pack을 2014년 발간했고, 이를 통해 스마트 오브젝트 간의 연결을 바탕으로 상호 간에 데이터를 해석할 수 있는 가이드라인을 제공하고 있다.

2) oneM2M 상호연동 표준화 동향
 (1) oneM2M 표준 개요
oneM2M은 사물인터넷 공통플랫폼 개발을 목적으로 한국(TTA), 유럽(ETSI), 북미(ATIS, TIA), 중국(CCSA), 일본(ARIB, TTC)의 세계 7개 표준개발기구들이 모여 글로벌 파트너쉽 프로젝트로서, 2012년 9월에 첫 미팅을 시작한 뒤에 아키텍쳐, 프로토콜, 보안, 장치관리 기능이 포함된 사물인터넷 시스템의 후보 규격인 release 1.0을 2014년 8월에 발표했다.
이에 대한 안정화 작업을 거처 지난 2015년 1월에 oneM2M release 1.1 표준을 발간했다. 현재 oneM2M은 크게 6개의 실무반을 구성하여 표준을 개발하고 있으며, 각 실무반별로 WG1-요구사항, WG2-아키텍처, WG3-프로토콜, WG4-보안, WG5-디바이스 관리 및 시맨틱, WG6-테스팅 개발을 담당하고 있다.
oneM2M에서 개발한 공통 플랫폼 기술은 12개의 공통 기능을 제공하고 있으며, 등록, 검색, 보안, 그룹관리, 데이터 관리, 구독&통지, 디바이스 관리, 애플리케이션 관리, 데이터 전달 관리, 네트워크 서비스 활용, 위치 정보 관리, 서비스계층 과금의 기능으로 구성된다. oneM2M 공통 플랫폼은 ROA(Resource Oriented Architecture) 구조를 갖고 따라서 웹과 같이 REST API를 통해서 oneM2M 공통플랫폼에 접근할 수 있다. 아래 도표는 2015년 1월 출판된 표준규격서 목록을 포함한다.
<표1> oneM2M 표준규격
표준 규격표준 번호WGs
Functional ArchitectureTS-0001WG2
RequirementsTS-0002WG1
Security SolutionsTS-0003WG4
Protocol SpecificationsTS-0004WG3
Management Enablement (OMA)TS-0005WG5
Management Enablement (BBF)TS-0006WG5
CoAP Protocol BindingTS-0008WG3
HTTP Protocol BindingTS-0009WG3
MQTT Protocol BindingTS-0010WG3
Common TerminologyTS-0011WG1

3) non-oneM2M 솔루션과의 상호연동 표준 개요
(1) oneM2M 과 AllJoyn Interworking
2014년 9월 AllSeen Alliance의 오픈소스 기반 사물인터넷 플랫폼인 AllJoyn과 oneM2M 플랫폼간의 상호연동 솔루션 개발을 위한 신규 WI(Work Item)가 발의됐다.
아래 그림과 같이 AllJoyn 프레임워크는 근접기반 Advertisement/Discovery를 통해서 디바이스 상호 간의 서비스를 발견해 연결하고 데이터를 전달하는 기능을 제공하는 로컬영역에서 동작하는 플랫폼이고, oneM2M 동작영역이 광역네트워크까지 포함할 수 있는 플랫폼으로 이 둘 간의 상호 연동을 통해서 플랫폼 간 시너지 효과를 가져올 수 있다는 전제로 출발했다. 그리고 현재 해당 WI을 통해서 oneM2M과 AllJoyn 시스템 간의 기술적 비교, 상호 연동을 제공하기 위한 시나리오 및 요구사항 도출, 최종적으로 oneM2M 리소스와 AllJoyn 시스템 간의 매핑구조 정의에 대한 개발을 진행 중에 있다.
<oneM2M과 AllJoyn 시스템 비교>
oneM2M과 산업표준플랫폼의 상호연동 표준화 동향
AllJoynoneM2M
Network ArchitecturePeer-to-Peer in LANServer-to-Client in WAN
API StyleRPC(RMI) APIResource-based API
Discovery StyleProactive DiscoveryPassive Discovery

기술적으로 AllJoyn의 서비스는 인터페이스를 통해서 표현되며 해당 인터페이스는 멤버로서 메소드, 시그널, 속성을 갖는다.
따라서 AllJoyn 서비스의 인터페이스를 oneM2M의 리소스로 어떻게 맵핑할 것인가가 주요 상호연동 개발의 이슈로 다루어졌다.
현재 AllJoyn 인터페이스의 oneM2M 리소스로의 맵핑을 <container>, <contentInstance>를 활용하는 방안1과 AllJoyn을 위한 신규 리소스를 oneM2M에 정의하는 방안2에 대해서 논의되고 있다. 아래 그림과 같이 방안1의 <contentInstance>로서 AllJoyn의 메소드, 시그널, 속성을 맵핑하게 되면 <contentInstance>리소스가 accessControlPolicy 속성을 지정할 수 없는 리소스이기 때문에 AllJoyn 인터페이스의 메소드, 시그널, 속성별로 oneM2M의 accessControlPolicy 적용이 어렵다.
또한, 방안2와 같이 신규 리소스를 정의하게 되면서 생기는 오버헤드가 없다는 특징이 있지만 방안2와 같이 oneM2M 신규 리소스를 정의한다면 accessControlPolicy 적용이 메소스, 시그널, 속성 레벨까지 가능한 반면, AllJoyn 서비스를 위한 신규 리소스를 정의해야 하는 오버헤드가 있다. 현재 이에 대한 스터디가 진행 중이다.
<AllJoyn 과 oneM2M 리소스 맵핑>
oneM2M과 산업표준플랫폼의 상호연동 표준화 동향
(2) LWM2M Interworking
2015년 1월 oneM2M 릴리즈 2를 위한 신규 개발 기능 리스트 중에서 non-oneM2M 시스템과 oneM2M 시스템과의 상호연동 이슈가 부각됐고, 이를 위한 LWM2M Interworking 신규 WI(Work Item)이 발의됐다.
LWM2M 기술은 OMA(Open Mobile Alliance)에서 제정한 리소스 제약적인 소형 디바이스를 위한 디바이스 관리 목적으로 개발된 프로토콜 표준으로서 LWM2M 기반 디바이스는 LWM2M 클라이언트와 LWM2M 서버로 구분된다.
기술적으로 oneM2M에서는 LWM2M과 같은 non-oneM2M 시스템과의 상호연동을 위해서 IPEs(Interworking Proxy Application Entities)를 정의하고 있는데 이를 통해서 LWM2M 상호연동 WI(Work Item)에서도 IPEs를 활용해 LWM2M 기기들과의 연동을 위한 표준개발을 진행 중이다.
LWM2M과 oneM2M의 상호연동을 위해서 LWM2M 기기들은 oneM2M의 AE(Application Entity) 로서 등록되고, LWM2M 기기들의 데이터는 AE의 <container> 리소스에 담길 수 있는 구조를 취한다.
<LWM2M과 oneM2M 상호연동 참조구조>
oneM2M과 산업표준플랫폼의 상호연동 표준화 동향
또한 아래 그림과 같이 LWM2M과 oneM2M의 상호연동 모델을 위해서 현재 non-oneM2M 기기의 데이터를 oneM2M의 AE 하부의 container 리소스에 인코딩해서 저장하는 방식과 (옵션1) non-oneM2M 기기의 데이터에 대해 시맨틱 온톨로지 정보를 활용해 해당 데이터에 대한 해석이 가능한 방식 (옵션2)에 대해서 상호연동 모델로서 고려하고 있으며, 옵션1의 방식은 oneM2M의 어플리케이션에서 상호연동 리소스를 발견했을 때, 데이터에 대한 non-oneM2M 방식의 데이터 해석이 가능해야 한다는 것과 옵션2 방식은 시맨틱 온톨로지를 통해서 범용의 해석이 가능하다는 부분에서 기술적 차이점을 갖는다.

<LWM2M과 oneM2M 상호연동 데이터 모델>LWM2M과 oneM2M 상호연동 참조구조
3. 향후 전망
사물인터넷에서 사용되는 다양한 기기들을 인터넷에 연결하고 이들간의 상호 작용을 제공하기 위해서는 글로벌 표준에 따른 개발이 필수적이며, oneM2M은 2012년 9월부터 표준작업을 시작해 국제적으로 인정받을 수 있는 사물인터넷 공통 서비스 플랫폼 표준기술을 공개했다.
그리고 현재 Release2를 목표로 다양한 신규 WI(Work Item)을 발의하고 관련 표준 개발이 진행 중에 있다.
신규 WI은 아래 표와 같이 홈 도메인, 산업 도메인과 같은 다양한 응용도메인에서 oneM2M 공통 플랫폼을 위한 신규 기능정의를 진행 중에 있으며, 다양한 산업체 표준(AllJoyn, LWM2M, OIC 등) 및 네트워크(KNX, ZigBee 등)와의 상호연동, 시맨틱스, 보안 기술 개발 및, oneM2M 표준기술의 상호운용성 및 적합성 규격 개발, 시험인증 방안에 대한 논의가 진행 중에 있다.
현재 어떤 사물인터넷 플랫폼도 시장에서 독보적인 주도권을 장악하지 못한 상황에서 향후 oneM2M과 같은 글로벌 표준 플래폼과 AllSeen 및 OIC와 같은 산업체 컨소시엄들이 서로 협력하는 국제표준 상생 협력 모델로서 관련 사물인터넷 플랫폼 개발이 이뤄질 것으로 전망된다.
<oneM2M 릴리즈 2 신규 WI 리스트>
WI(Work Item)설명
oneM2M and AllJoyn Interworking근접 장치 간 연결 기술인 AllJoyn과 광역 연결을 보장하는 oneM2M 간 상호연동 기술
LWM2M InterworkingLWM2M 장치 관리 기술 상호연동 기술
Generic InterworkingArea Network (ZigBee, BT 등) 상호연동 기술
Home Domain Enablement스마트홈 서비스 지원을 위해 필요한 신규 요구사항 및 기능 검토, 가전기기를 위한 메시지 프로파일 정의
Industrial Domain Enablement산업용 IoT 응용(공장자동화 등)에 필요한 기술 검토
Testing Framework상호운용성/적합성 테스트 규격을 위한 프레임워크 개발
Interoperability TestingHTTP/CoAP/MQTT 프로토콜 바인딩 기반 상호운용성 테스트 규격 개발
Service Layer Local API로컬 어플리케이션 개발에 필요한 API 정의
End-to-End Security and Group AuthenticationE2E 보안기술 및 그룹 Authentication 개발
작성자: 시간: 댓글 없음:
라벨:
피드 구독하기: 글 (Atom)