'IoT' 카테고리의 다른 글

아마존 ( AWS IoT – 사물 인터넷을 위한 클라우드 서비스 )  (0) 2015.11.25
OpenADR vs SEP 2.0  (0) 2015.10.04
지그비(ZigBee) 의 SEP 2.0 표준 살펴보기  (0) 2015.10.02
SEP 2.0 이란?  (0) 2015.10.02
Kitu 시스템의 SEP 2.0  (0) 2015.10.02

An overview of ZigBee's Smart Energy Profile 2.0 standard

5/14/2013 11:30 AM EDT 


IoT 의 부분으로서 정의된 디바이스들은 상호 연결된 디바이스/네트워크를 이용하기 위한 혁신적인 방법을 찾는 방향으로 빠르게 개인/산업에서 성장하고있다.  머신간(M2M)에 통신을 할수있게하는것은 무한한 가능성을 가지고있으며, 스마트 에너지의 떠오르는  아주 유망한 기술분야의 하나일것이다.

홈 미터장치로서, 개인 디바이스/어플라이언스는 서로 연결되기 시작하며, 어떻게 현명한 에너지 소비결정을 할수있는지에 대해 이해하기 쉬운 그림을 그려나가게 한다.

스마트 그리드를 위한 집과 로컬인터넷네트워크에서 디바이스들의 연결은 집주인과 전력회사간에  양방향 통신을 할수있게 해주며 점점 현실화 되고있다.


이 기사에서는 지그비얼라이언스에 의해 개발되는 스마트 에너지 마켓의 떠오르는 표준인 SEP 2.0 에 대한 전반적인 모습을 보여줄것이다.

SEP 2.0 에 대한 기본적인 이해를 바탕으로, 소프트웨어 개발자들은 스마트 에너지 어플리케이션을 개발하기위해 적합한 임베디드 소프트웨어를 선택하기위한 준비를 더 잘 하게될것이다.



IoT 와 새로운 개척자 

IoT 는 요즘 들려오는 시끌시끌한 단어인데 ,먼가 미래엔 흥미로운것들이 일어날것 같은 상상을 하게 해준다. 스스로 내용물을 체크하는 냉장고인데 만약 필요한 식료품이 없으면 알아서, 직장에서 돌아오는 길에 쇼핑을 할수있도록  쇼핑 리스트를 정리해서 이메일을 보내준다던지 하는것말이다. 집에 돌아오면 알아서 적당 온도가 맞춰져 있고 저녁식사를 위해 오븐이 미리 데워져있는 그런 쿨한 것들 말이다.  

무선연결기,센서,마이크로 프로세서등과 컴비네이션된 임베디드 디바이스의 빠른 확산은 기능적으로 풍부하고 지능적인 결과를 만들고있으며, 기기들이 현명하게 연결된 세상에 대한 비전을 우리에게 보여주고있다.



Figure 1: Energy providers, the development of a nationwide smart grid and energy-conscious consumers will usher in a new era of smart energy use


이런 기술셋을 적용하면 스마트 에너지라는 단어로 불리는 에너지 소비를 발전시킨다. 스마트 에너지뒤에 있는 개념은 내부에서 외부까지 모든 디바이스,네트워크,스마트 그리드 그자신을 포함하여 에너지를 조절하는것이다. 홈 네트워크와 발전소사이의 양방향 통신은 신뢰성/지속성을 증가시켜서 큰 가능성을 열어준다.



Figure 2: In a typical smart home, devices such as a washing machine, an in-home display, and a power meter all work together in tandem –to make the home and grid smarter



스마트 에너지에 대해 스마트해지기

스마트그리드와 스마트홈 (스마트 가전, 게이트웨이 등) 과 스마트 미터(전기,가스,물) 은 스마트 에너지 에코시스템의 중요한 요소이다. 스마트 홈 가전들은 매일 사용자와 상호작용하는 전형적인 기기이다. 이런 기기를 서로서로 소통하게하고 소비자에 의해 컨트롤되는것은 figure 2) 처럼 전체적으로 새로운 편리함이 더해진다. 

스마트 온도장치, 스마트 스위치, 스마트 냉장고 등 오늘날에는 무선으로 연결될수있고 지능적으로 작동할수있는 여러 제품이 있다. 몇몇 진보된 가전제품들은 커넥티드 홈안에서 다른 디바이스들과 상호작용을 하기위해  빌트-인 웹서버를 포함한다. 스마트미터들은 이런 홈/오피스 에서 게이트웨이이고 스마트 그리드와 함께 이런 정보들 모두 혹은 일부를 공유하기 전에 리소스 사용처를 측정하고 수집한다.  그리드는 이런 정보로서 부하조절 , 피크 단축(peak curtailment) , 수요매니지먼트등의 작동을 할수있게 된다. 

스마트 에너지 디바이스들(그들의 표준 기능으로부터 좀 떨어진)은 로컬 네트워크안에서 다른 스마트 에너지 디바이스와 반드시 통신할수있어야한다. 그리고 관련정보(과금,사용상황,알림등)들을 서로 주고 받고 할수있어야한다. 데이타 교환은 전반적인 효율성과 장애극복을 높힐뿐 아니라 에너지 사용을 효율적으로 옵티마이징할수있게 해준다.  

스마트 미터들은 에너지 제공자에게 사용데이터를 모으고 전송해주고 소비자들에게는 그들의 에너지 소비상황을 조절하고 모니터링할수있게 해준다. 즉 사용자로부터 사용데이터(usage data) 가 에너지 제공자로의 흘러가는 동시에 과금데이터가 에너지 제공자로부터 소비자로 흘러들어가게된다. 이런 양방향 흐름정보는 소비자로 하여금 현명한 소비를 하게 한다.

이런 양방향성과 실시간 커뮤니케이션은 에너지 제공자가 에너지 공급 & 분산정책을 잘 계획하도록 도와줄수도있다.


스마트 에너지 디자인 표준화 하기

ZigBee 얼라이언스는 SEP 2.0 이라는 명세를 스마트 에너지 에코시스템의 여러가지 측면(디바이스간 통신, 연결성 , 정보공유등) 에 대해 형식화 하기위해 만들었다. 

SEP 2.0 은 디바이스들끼리 커뮤니케이션하는것에 관한 가이드라인을 제공하며, 여러가지 디바이스 속성(조절될수있음)을 정의한다. 이런 속성 ("리소스"라고도 말해짐) 은 SEP 2.0 기능 ("기능 셋" 이라고 불려짐) 을 구현한 논리그룹에서 서로 어울려서 작동하게된다. 

미터링 시스템이나 과금시스템은 특정 어플리케이션 기능셋 (application-specific function set의 전형적인 예이다. 스마트미터같은 디바이스들은 사용통계나 경향같은 속성이 추가된서비스들을 제공하기 위해 하나 또는 그 이상의 기능셋을 구현한다. 이런 과금통계나 경향정보는 에너지 제공자나 소비자 모두에게 서비스 및 에너지사용을 더 잘할수있게 해준다.

디바이스상에서 기능셋과 그들의 리소스들은 HTTP URLs 를 통해 접근되어진다. 이런 디바이스들은 DNS-SD 나 mDNS 같은 기술을 사용하여 네트워크상에서 동적으로 주변의 서비스들을 탐색한다. 그리고 그들 자신을 SEP 2.0 기능셋을 구현한 리소스에 접근하기위해 스스로 등록한다. 

스마트 에너지 디바이스간에 진정한 상호작용할수있는 에코시스템을 제공하기위해 TCP/UDP 와 IP-Based 네트워킹의 사용은 필수적이다. 또한 외부 네트워크에 노출된 취약점이 있기때문에 디바이스간의 보안에 관한것도 중요하다. 

많은 스마트 디바이스들은 꾸준하면서 신뢰성있고 실시간데이터를 서비스하기 때문에, 디바이스들은 반드시 "항상켜져있고" "항상 연결되었는" 상태를 유지해야한다. 그것은 또한 스마트 에너지 디바이스들은 그들 스스로 굉장히 에너지에 있어서 효율적이어야한다는 말이된다. 

마지막으로 그들은 반드시 유/무선네트워킹을 지원해야한다. 


상호 연결된 디바이스를 위한 하드웨어

현재 주요 홈 가전 디바이스들은 떠오르는 M2M 물결에 맞춰진 진보된 모습을 아직 가지고있지 않다. 그래서 하나의 디바이스안에 여러 능력을 통합하는것은 매우 비싼 하드웨어 업그레이드 비요을 지불해야한다는걸 의미한다. BOM의 증가를 초래하는데 제조업자들은 스마트 에너지기능을 가진 가전제품을 추가비용과 함께 제공할때 생기는 이윤의 밸런스를 맞추어야한다. 

좀 가전제조사들은 스마트 에너지기능을 가진 가전제품을 디자인 하기위한 비용을 효율화할수있는 솔루션을 찾기위한 여러 옵션을 가지고있다. 이런 가전제품에 대한 SoC 하드웨어사는 기능성, 폼 팩터, 소프트웨어 지원, 비용사이에서 올바른 밸런스를 찾아가기위해 고군분투하고있다.

32-bit 마이크로 컨트롤러스(MCUs) 는 그들을 강력한 후보군으로 만들기위한 맞춤형의 프로세싱파워,메모리,연결성등을 제공하려한다.  현세대의 Freescale, Kinetis,STMicroelectronics STM32, TI Stellalris (ARM Cortex-M core) 같은 마이크로컨트롤러는 합리적인 가격에 엄청난 기능을 제공한다.  옳바른 하드웨어의 선택은 그저 시작일뿐이다. 이 방정식을 마져 풀기위해서 소프트웨어 선택이 남아있다. 




Figure 3: An example of a hardware design that can support a wide range of peripherals, powered by a real-time operating system such as Nucleus RTOS, which offers all the services required by SEP 2.0
Click on image to enlarge



옳은 소프트웨어 선택하기

소프트웨어기술에 관한 요구사항은 SEP2.0 스펙에 포함되어져있다. 풍부한 TCP/IP , UDP 스택지원; mDNS 나 DNS-SD 같은 동적 서비스 탐색 능력을 가진 IPv6 서비스; 그리고GET,PUT,POST,DELETE 같은 기본메소드를 지원하는 HTTP 구현같은것; 또한 의무적으로 SSL/TLS 같은 보안구현사항들과 다양한 현대 인터넷 테크놀러지 아키텍처 (Restful, XML, EXI 인코딩 스킴). 그런 소프트웨어 테크놀러지를 지원하는 베이스로 사용하기 충분한 Linux. 그러나 불행하게도 96~128k 범위의 RAM 을 가진 마이크로 컨트롤러의 사용은 옵션에서 리눅스를 제외한다.  그런 기술을 개발하는것은 매우 비싸며 시간이 많이 소모되는데, 그런 제약사항은 RTOS 시스템을 이런 디바이스에 구현하도록 만드는 역할을 하고있다.  

이런 RTOS 들은 빠르고 효율적일뿐만 아니라 강력하다. 그들은 전형적으로 네트워크 스택을 포함하며 SSL/TLS 같은 보안에 대한것들도 제공한다. 꽤 무거운 소프트웨어들도 지원할수있는 메모리사이즈를 가질수도있다. Nucleus RTOS 는 그런 솔루션중에 하나이다. (Figure 3). 이것은 많은 스마트 그리드 디바이스 요구사항을 충족시켜줄수있다. 무겁고, 실시간 성능 및 파워 매니지먼트 서비스를 통합하고있다. 그런 RTOS 메모리 제약이 있는 MCU 에 적합하며, 스마트 그리드 디바이스와 연결되는것에 의해 요구되는 커다란 기능셋을 제공할수도있다.



결론 

With the projected rapid growth in the adoption of smart grid technologies, designing fully compliant devices that keep the bill of materials minimized will become a major challenge for manufacturers. To create a device compliant with the SEP 2.0 specification, a homegrown software design is likely not an option due to the high number of functional requirements and the expensive in-house development efforts. On the other extreme, using a general purpose operating system will result in unacceptable cost increases because of the need for significantly upgraded hardware resources. Device manufacturers need to find the right balance when choosing both the software design and hardware platform. The use of a scalable, power-efficient, real-time operating system with extensive networking support (wired and wireless) — along with one of the 32-bit MCUs now available in the market—is the closest to meeting all of these requirements. Following this design paradigm, designers will significantly reduce their time-to-market and still realize all of their smart grid application goals.

http://www.eetimes.com/document.asp?doc_id=1280846 번역

'IoT' 카테고리의 다른 글

OpenADR vs SEP 2.0  (0) 2015.10.04
Avahi - mDNS/DNS-SD 구현체  (0) 2015.10.02
SEP 2.0 이란?  (0) 2015.10.02
Kitu 시스템의 SEP 2.0  (0) 2015.10.02
IoT 빅데이터 분석 솔루션을 만들기위한 도구들  (0) 2015.09.03

 스마트에너지 프로파일(SEP) 2.0 표준

표준
내용
- 스마트 미터, IHD, HEMS 등 전기 설비 장치 및 스마트 가전 간 상호호환을 위하여 표준화된 장치 정의 및 장치 간 통신을 위한 인터페이스를 제공
- 보안, 서비스 탐색, 장치의 전원 및 네트워크 상태, 수요 반응 및 부하 제어, 전력 측정, 요금 계산, 청구 및 지불 등의 다양한 응용 계층 메시지 규격을 정의하고 있어 계량기 원격 검침뿐만 아니라 기기의 에너지 수요 제어, 실시간 요금 정보와 같은 서비스의 제공에도 사용이 가능
추진
현황
- ZigBee Alliance와 HomePlug Powerline Alliance에 의해 주도되어 개발됨
- 2011년 8월부터는 공동 인증 및 시험 프로그램 개발을 위한 컨소시엄에 Wi-Fi Alliance 및 HomeGrid Forum도 참여하고 있음
- 2013년 2월 현재 Revision 0.9, Version R32의 draft가 나온 상태임 

디바이스상에서 기능셋과 그들의 리소스들은 HTTP URLs 를 통해 접근되어진다. 이런 디바이스들은 DNS-SD 나 mDNS 같은 기술을 사용하여 네트워크상에서 동적으로 주변의 서비스들을 탐색한다. 그리고 그들 자신을 SEP 2.0 기능셋을 구현한 리소스에 접근하기위해 스스로 등록한다. 

스마트 에너지 디바이스간에 진정한 상호작용할수있는 에코시스템을 제공하기위해 TCP/UDP 와 IP-Based 네트워킹의 사용은 필수적이다. 또한 외부 네트워크에 노출된 취약점이 있기때문에 디바이스간의 보안에 관한것도 중요하다. 



http://www.ksga.org/sub3/pds_read_newsletter.asp?ID=2284&read=143&article4=1&ForumID=0&kind=4  참고

http://www.csee.org.cn/Portal/zh-cn/Publications/atm/docs-13-0200-00-sep2-smart-energy-profile-2.pdf.pdf   스펙문서


Smart Energy Profile 2.0 (SEP2) 는 국제표준으로서, 홈 / 비지니스 부분의 에너지 디바이스에 대해 스마트 그리드 서비스를 제공하는  IP 기반의 어플리케이션 프로토콜 명세이다. 


Kitu 시스템이 제공하는 SEP2 스택 :

  • Small footprint   (공간을 적게 차지하며)
  • Flexible – robust API’s   (유연성있고 강력한 API 제공)
  • Hardware, PHY, OS agnostic   (모든 하드웨어 , OS 등에서 사용가능) 
  • Feature rich application environment and services simplifying application development and speeding TTM (개발이 쉽고,시장에 빠르게 진입할수있게함) 

Kitu 의 SEP2 스택은 가장 완벽하며 , 테스트되어있고 ,넓게 적용될수있으며 성숙된 SEP2
스택을 제공합니다.

SEP2 코어 



1. IP 기반으로 다양한 물리적 인터페이스 (Ethernet, Wi-Fi, ZigBee, PLC, 등) 에서 작동.

2. 표준 HTTP/HTTPS 방식과 XML/EXI 정의를  사용한 Restful 서버/클라이언트 아키텍쳐.

3. mDNS  기반 서비스 디렉토리를 사용하여  복잡한 설정을 제거.

(역주: mDNS
Rendezvous, Bonjour 혹은 mDNS라 불리는 기술은 근거리 망에서 각 노드상의 서비스를 발견할 수 있도록 알리는 방식을 정의한다. 리눅스에서는 그 구현체로 Avahi가 쓰이고 있다. (과거 구현체인 Howl과도 호환된다)애플 쪽에서 이걸 잘 쓰고 있는데 가령 iTunes에서 공유를 걸면 네트워크 안의 다른 아이튠즈에서 그 공유를 알아챌 수 있게 되어 있다.)

(역주: WiFi-Direct 는 기존의 uPNP 프로토콜이나  iOS 의 Bonjour 프로토콜을 사용하여 서로를 인증한다.

  uPNP, Bonjour 는  Multicase UDP 통신을 통해 기기를 검색하고 인증한다.)

4. ECC 기반 암호수트를 사용하여 높은 보안성 제공.

(역주: ECC 타원곡선기반 암호화,웹상의 자료들을 살펴보니 ECC가 분명히 RSA보다 상대적으로 안전한 알고리즘이라는 의견이 지배적입니다. 그러나 상대적으로 복잡하고 실제 구현을 위해 전문 지식이 필요하여 업계 전반으로 확대되는 데에는 많은 시간이 필요하다고 합니다. 또한, 특정 타원 곡선 유형에서는 쉽게 풀리는 문제점이 지적되고 있습니다.  


위키피디아에 소개된 ECC 관련 보안 위협 사례가 몇 가지 있습니다. 
  • 2010년 12월 소니는 PlayStation3에 ECDSA 개인키가 해킹되었으며, 잘못된 알고리즘 사용이 원인이였습니다. 
  • 2011년 3월 29일 서버의 TLS 개인키가 노출될 수 있는 가능성이 제기되어 OpenSSL 1.0.0e에서 수정되었습니다. 
  • 2013년 8월 자바 SecureRandom 클래스의 결함이 발견되었습니다.

현재 국가에서 진행중인 행정기관 인터넷 전화 보안의 기기인증 부문에서는 ECC와 RSA를 동시에 사용할 수 있도록 규정되어 있습니다. 또한, 무선 분야나 USN 분야에서는 ECC가 매우 효과적입니다. ECC의 짧은 키길이로 인해 기존 RSA보다 훨씬 짧은 시간에 키 생성 및 교환이 가능하기 때문입니다 )

기능성


수요조절, 과금, 미터링, 메세징, 흐름 예약, 분산 에너지 리소스 (DER), 빌링,  선불 및 확장


     KITU SEP2 스택 


1. Kitu 시스템은  클라이언트/서버에 대해  완전한  end-to-end SEP2 프로토콜 스택을 제공합니다. SEP2 통신 을 완전히 추상화 하였으며,  많은 프로토콜을 지원하는 어플리케이션으로 빠르게 시장에 진입할수있도록 도와줍니다. (protocol agnostic applications)

agnostic 의미 : http://whatis.techtarget.com/definition/agnostic

2. 많은 예제와 잘 구축된 문서

3. 적은 프로세서, 램을 요구하며 임베디드 RTOS 라든지 리눅스에서 돌아가는 게이트웨이 디바이스등 저전력디바이스에서도 작동합니다.

4. 엣지디바이스,게이트웨이/라우터,클라우드등에서 돌아가는 유연성 

5. 스마트한 엔드노드 어플리케이션 서비스를 제공합니다.그것은 멀티서버를 제공하는것을 포함하여 어플리케이션 개발을 단순화합니다.


            플랫폼  & 도구


Support for a wide range of standard and implementation-specific platforms.

Kitu Systems own platform modules also available for very constrained devices.

Powerful and flexible debug and monitoring tools for control, debug, logging and regression testing

http://www.infoworld.com/article/2876247/application-development/building-an-iot-analytics-solution-with-big-data-tools.html  요약 번역




데이터 얻고 저장하기


ad  IoT 디바이스들로부터의 이벤트(데이터)를 받을수있는 무수한 프로토콜중에 (특별히 로우레벨에서) 우리의 목적에 부합하기위해 디바이스가 블루투스,스마트폰,WI-FI 또는 하드웨어 커넥션인지는 중요하지 않다. 다만 정해진 프로토콜을 사용하는는 어떤 종류의 브로커에게 메세지를 보낼수있는지가 중요하다. 

이에 IoT 에서 사용하는 가장 유명한 프로토콜중에 하나는 MQTT (Message Queue Telemetry Transport) 이다. 이것은 잘 알려진 많은 오픈소스 클라이언트/브로커와 활용되는데 특별한 다른 이유가 있지 않다면  Mosquitto  는 가장 잘 알려지고 널리 쓰이는 오픈소스 MQTT 브로커를 사용하면 된다.  모스키토는 오픈소스이기때문에 예산이 부족한 당신이 낭비를 피하면서 당신의 분석 컨셉을 미리 실험 해볼수도 있다.

일단 모스키토같은 브로커에 메세지가 오면, 당신은 분석 시스템으로 메세지를 건네줄수있게된다. 가 장 좋은 방법중 하나는  분석을 위해 전처리/변경되야하기전에 오리지널 데이터는 따로 저장하는것이다. 그렇게 되면 디버깅이슈때나 다시 리플레이 할때나 이전 기록을 테스팅을 다시 해볼수있다는것이다. 

데이터를 저장하기위한 여러가지 옵션이 있는데, 많은 프로젝트들이 Hadoop 과 Hive 를 사용하는데, 최근에 나는 문서기반 NoSQL 의 하나인 Couchbase  ( 역주: 다른 문서기반 NoSQL 몽고DB 가있으며 http://www.infoworld.com/article/2613970/nosql/nosql-showdown--mongodb-vs--couchbase.html  비교해놓았다.)  은 를 사용했는데 매우 만족하였다. Couchbase 는 높은 처리율과 낮은 지연률을 꽤 훌륭히 컴비네이션한  특성을 가지고있다. 그것은 또한 스키마가 없는 문서형 데이타베이스라서 쉽게 새로운 이벤트타입을 추가할수있다. HDFS (역주: 하둡의 분산파일 저장시스템, 저장하기위한 시스템이고 저장된 데이터를 분석하기위한 유명한것으로 맵리듀스가 있다)  에 직접적으로 데이터를 쓰는것은 실용적인 옵션이다. 그렇게 하면 나중에 Hadoop 을 이용하여 배치기반의 분석도 사용할수있게 된다. 

영구저장소에 소스데이터를 쓰기위해 커스텀코드를 메세지브로커에 붙히거나  (예를들어 , 모스키토 브로커) 또는 아파치 카프카 같은 중간 메세지브로커에 메세지를 전달할수있다. (당신의 시스템의 다른 부분에 메세지를 이동하기위해 카프카 컨슈머를 사용하거나) 

결국 하나의 입증된 패턴은 카프카에 메세지를 넣는것과 2개의 컨슈머 그룹이 있다는것이다. 하나는 당신의 영구저장소에 로우데이터를 쓰기위한 것이고, 나머지 하나는 실시간 분석도구(아파치 스톰같은) 로 데이터를 넘겨주는 역할을 한다. 

만약 당신이 MQTT 와 모스키토 및 여러가지를 묶어서  편한길을 가려면  MQTT 스파우트 (역주: 스파우트는 아파치 스톰의 개념으로 스파우트를 통해서 데이터를 모아서 볼트를 통해서 분석작업을 하게된다.)  를 사용해서 아파치 스톰에 직접적으로 전달하는것이다. 


전처리 및 데이터 변환 

로우 형태를  가진 디바이스로부터의 데이터는 분석하기엔 적절하지 않은 경우가 많다. 데이타를 읽어버릴수도있고, 좀 더 많은 정보를 가진것으로  요구되기도 한다. 값을 표현하기위ㅐ 변경이 필요할수도있다. ( 데이타에 시간필드를 추가한다던가 하는)  

이런것을 하기위해 전처리 / 변환 과정이 필요하며 다양한 방법이 있다. 내가 경험했던 가장 좋은 방법은  위에 언급했듯이 일단 로우 소스 데이터와 함께 변경된 데이터를 저장할 필요가 있다는것이다.

지금 이렇게 생각할수도있을것이다 " 내가 항상 그것을 다시 변경할수있는데 왜 해야하지? " 하지만 이것은 매우 큰 비용을 들이게 된다. 

데이터 변환을 하는것은 여러가지 방법이 있다. 만약 배치모드에 촛점을 맞춘다면 HDFS 로 데이터를 쓰고 ( 피그 등을 통해 분석할수있을것이다. 피그는 시간은 오래걸리며 워크플로우에 지연도 길다.) 실시간 분석을 하기위해서는 아파치 스톰을 사용할수있다.   (역주: 스톰으로 분석하고 결과 데이터는 HDFS 에 쓸수도있고, Couchbase 에 쓸수도있고 그렇다) 


비지니스 혜안을 얻기위한 분석

일단 데이터가 적합한 상태로 변환이 되고 저장이 되면 , 이제 분석을 위해 그것들을 다룰수있게 된다. 아파치 스톰은 연속된 데이터 흐름을 분석하기위해 고안되었다. 그것은 정확히 IoT 시스템이 생성하는 데이터 흐름을 다루기에 적합하다.  이벤트 상관관계(event correlation), rolling metric calculations, and 집합통계(aggregate statistics) 같은것을 수행할수있게된다. 물론 상황에 적절한 여러가지 알고리즘을 직접 넣을수 있다. 

우리가 경험한바로는 스톰은 스트리밍 IoT 데이터 처리에 매우 잘 맞는 옷이었고, 어떻게 당신의 분석파이프라인의 중요요소로 작동하는지 살펴보자.

스톰에서는 기본적으로 토폴로지들이 영구히 동작하는데 , 당신의 끊임없는 메세지를 처리할수있다. 토폴로지는 어떤 개수와 프로세싱스텝으로도 구성될수있으며 , 일명 "볼트" 라고 불리는 처리단위가 클러스터의 노드에 분산되어 있다. 

볼트에서 처리된 데이터들은 버려질수도있으며, 재 가공되어 넘겨질수도있고, 결과 데이터들은 영구저장소에 저장되거나 , 뷰어에 의해 디스플레이되어 사용자에게 보여질수도있다.

위의 그림을 설명해 보면 

1.엣지디바이스/센서로부터 데이터가 생성되어 약속된 프로토콜인  MQTT (모스키토) 로 보내지고, 

2. 그 데이터들은 카프카에 모인후 카프카에서는 

      2-1. 로우데이터 자체를  Couchbase 로 보내서 저장하고 

      2-2. 데이터 분석을 위한 다른 컨슈머는 스톰에게 보내고 

           2-2-1.  실시간 분석중에 위험요소 발견하면 즉시 디바이스에 통보하고

           2-2.2.  실시간 데이터를 타임스탬프와 함께 사용자에게 그래프 등으로 보여주고

           2-2.3.  분석하기위해 필터링된  데이터를 Couchbase 로 저장하며

           2-2.4.  분석 결과 데이터는  Couchbase 와 HDFS 에 저장됩니다.


3. HDFS 에 저장된 데이터는 추후에 배치분석에 사용될수있으며

4. Couchbase 에 저장된 데이터는 사용자가 쿼링하여 살펴볼수있게됩니다.


Local-Trees-Code

Need to track hundreds of billions of data points? These Opower engineers’ Open Source software can help.

Last month, our colleague Greg Poirier wrote about Opower’s innovations with Open Source software, and specifically Wizardvan — an Opower open-source contribution that helps organize computational metrics on a large scale.

Today we’ll discuss a similar innovation that Opower developed and everyone can now use thanks to the nature of Open Source contributions. As our colleagues havepreviously mentioned, Open Source software is so valuable because the larger the community there is using it and working on it, the better it becomes.

THE CHALLENGE AND OPPORTUNITY OF LARGE DATA VOLUMES

Because Opower’s data volumes are scaling rapidly as we partner with more utilities and launch more programs, we have to take special care that our production systems and services always operate at optimal levels of performance. We measure that performance around the clock by tracking metrics on the type and amount of data flowing through our system.

Historically, we’ve utilized two traditional open-source systems to provide a backend to store our metrics data: Graphite and OpenTSDB. Both systems claim to to be scalable solutions for storing vast amounts of information about data metrics, but have different approaches to addressing the scalability challenge.

Graphite-and-OpenTSDB

Schematics of two OSS approaches that store metrics data: Graphite and OpenTSDB

As the amount of metrics data in our systems has continued to grow, we’ve begun to approach the limits of what existing versions of Graphite can support. For example, Graphite runs on “whisper“— a fixed-size database where each individual node can only store so much data. In addition, whisper’s archiving and time-stamping features aren’t nimble or efficient enough to support ultra-high volumes of data.

Where Graphite and its fixed-size database structure fall short, OpenTSDB can step in. OpenTSDB’s advantages span a range of features, including linear scaling and time-efficient scans.

However, as we’ve started to rely more on OpenTSDB for storing our metrics, we’ve found the need to add more functionality to support specific scenarios that stem from processing large and ever-growing streams of energy-related data. So, we did what’s become the natural thing: we implemented new functionality ourselves and shared our improvements back to the Open Source software community.

STRENGTHENING OPEN SOURCE SOFTWARE, STRENGTHENING OPOWER’S DATA SYSTEMS

Here are two important Open Source contributions we recently developed that show how our day-to-day experience with high-volume data processing allows us break new ground in Open Source software.

a) Metasync thread dead-locking

A benefit of having billions of rows of data in our system is that it can help us expose edge cases in Open Source software — especially edge cases that may not always be evident to the original maintainers of the Open Source repositories.

For example, in the case of OpenTSDB 2.0, we ran into a strange issue with running an operation called “metasync.” It would start properly and process data for about 5 minutes, then lock up suddenly and stop processing data. After some debugging work and looking at the code, we found the code block responsible:

Local Trees Code

A buggy block of code in a previous version of OpenTSDB software, which Opower engineers’ Open Source software contributions have helped improve

After 5 minutes, the OpenTSDB procedure would make a deferred call to reload some information (related to the new tree functionality, as shown in the code above). Unfortunately, this code block exited without releasing a mutual exclusion lock, which is required to ensure that multiple computational processes can run at once. As such, things would deadlock and no more data would be processed.

In this case, we were able to identify and fix a serious bug because we had the amount of data required to run the “metasync” operation long enough to produce this edge-case. This may not always be possible for the maintainers of the source repository because their testing data-sets may be much smaller (or they may not have the time or resources to run extended tests). We submitted this bug fix to the OpenTSDB repository, and it’s included in the upcoming 2.0 release.

b) Support for open-ended queries

Here’s another case in which our large data volumes enabled us to identify and rectify a procedural limitation of OpenTSDB.

When running open-ended queries, it’s not always known beforehand how many data points any specific computational metric will produce. This situation is fine when a metric’s count of data points sits in the tens or hundreds of thousands. However, we have some very common metrics such as Input/Output performance and central processing utilization that are computed for all systems and have millions of data points.

Whenever we ran into an open-ended query of this kind, OpenTSDB would continue trying to retrieve data until eventually all of the worker threads would be occupied by these gigantic queries and the process would eventually stall.

Our solution was straightforward: add an option to OpenTSDB to abort querying for more data after a specified timeout was exceeded. This allowed us to bypass queries in a set amount of time (e.g., 60 seconds) instead of being stuck in an indefinite waiting pattern. An added benefit is that if people accidentally query for too much data, it will prevent them from crashing any given process in OpenTSDB. This feature is also beneficial to other OpenTSDB functionality because different portions of OpenTSDB share Input/Output worker capacity.

We felt that this feature was broadly useful, so we contributed it back to the upstream open-source OpenTSDB repository for the 2.1 release. It’s an entirely optional configuration parameter, so regular users with less data won’t need to worry about it,. But it’s available for users who need this sort of functionality to keep their OpenTSDB nodes functional during workloads that query large datasets. Additionally, users that do receive timeouts can retry the same query with a different downsampling rate.

FINAL THOUGHTS

By applying the above improvements to OpenTSDB, we’ve made our systems more stable and ensured we can continue to support an ever-growing amount of metrics data. In our day-to-day work of processing uniquely large utility data streams, we’ve been able to break new ground in using and refining powerful Open Source tools. By making improvements to OpenTSDB’s metasync operation, we’re helping large-scale data users around the world (including ourselves) reliably generate metadata about their metrics. And by building in new support for open-ended queries, we’ve provided the ability to time out and re-optimize queries for stall-prone scenarios where waiting forever is not an option.

http://www.washingtonpost.com/news/energy-environment/wp/2015/03/03/why-knowing-your-energy-personality-could-help-save-you-a-lot-of-money/  번역 


Knowing your “energy personality” can save you a lot of money


   

For much of humanity today, getting out of bed is followed, very closely, by turning on a bunch of stuff. We crank up the heat. We start the coffee. We click on the morning news.

Some of us then go to work — and turn the stuff off again before we leave. Some of us don’t (either work, or turn our stuff off). Some of us get home from work and crash — but some of us stay up late, with lots of lights on, watching television, listening to music, working on the computer.

More stuff — sucking up electricity.

These patterns comprise what you might call our diverse “energy personalities” — which are theoretically capable of being quantified in terms of how much power we use across the day. Heck, these personalities could ultimately be reduced all the way down to flows of electrons. But the data have never been easily accessible to create such profiles — or, at least, not until now.

Opower is an Arlington, Va.-based software firm that works with power companies to help them better connect with their customers and, potentially, change their customers’ behavior. This role gives the company access to a ton of data, including from smart meters, which record our energy use and convey it back to utility companies in intervals of 15 minutes or less. (Opower protects customer data and confidentiality; you can read its privacy principleshere.)

Using this data, Opower’s Nancy Hersh, the company’s vice president of analytics, recently plotted the energy use of more than 800,000 homes over a 24-hour period. The resulting figure (not shown), in Hersh’s words, resembled a “hairball.” It was a blur of tangled lines, running horizontally, zigzagging from midnight to midnight.

But after Hersh and her team applied some “exploratory techniques” to the data, they saw that there were actually five separate clusters within the seemingly chaotic mess — representing five separate lifestyles that people tend to pursue. “The hairball can actually be untangled into these five separate ways that customers are living,” Hersh says.

Here’s the result — for a representative group of 1,000 customers, not the full 800,000:

There’s several things to note about this image. One is that even when people are sleeping, they’re never using zero power. That’s because of all the objects in the home, like cable boxes and cable televisions and various Internet-connected devices, that never actually turn off.

[“Your home is full of devices that never turn off. And they’re costing you a lot of money“]

The second thing to notice is that there are five well-trod paths for using energy over the course of the day —- or, if you’ll permit, five major personalities. “Every customer that we have smart meter data on can be classified into one of those five curves,” Hersh says.

Hersh and her team gave five names for the five curves and the types of people they represent:

Then, based on additional demographic data, they examined what kinds of people tend to be Daytimers, vs. Evening Peakers, vs. Steady Eddies.

“The Night Owl group skews young and apartment condo dwellers. And the Daytimers skew old with few children,” Hersh says. “And the thing I love about this, compare Night Owls to Daytimers, just the curves themselves, they’re mirror opposites.”

What of the other shapes? According to Hersh, Steady Eddies tend to live in condos and have a high level of winter energy usage from electric heating; Evening Peakers represent single-family homes that use a lot of power in the summer on air conditioning; and Twin Peaks tends to be wealthier families, also in single-family homes whose heat source is electric, not gas.

Data like these aren’t just a cool curiosity — they have big relevance for utility companies and for their customers. Why? Because depending on your energy personality, there are likely to be very different ways and strategies for you to save money and reduce your energy use.

“Let’s imagine there’s two energy-efficiency programs, one aimed at reducing consumption during peak periods and a different one that’s aimed at reducing base load,” Hersh says. “I want the one that’s useful to me. So when I have a big peak in the afternoon, having the program that’s aimed at reducing peak [usage] is going to be much more relevant to me. Whereas if I’m flat like a Steady Eddie, the big lever for me is not peak, it’s reducing my baseline. So it gives me more control over my energy use.”

So how can you figure out your energy personality, so that you can start saving? Currently, Opower doesn’t produce these charts for individuals, though Hersh says it is considering whether to do so.

In the meantime, if you have a smart meter, your utility probably provides an online portal where you can see your power usage, hour by hour. It probably won’t look like the curves above, but it will help you get a sense. By just knowing your own habits and patterns, you may also be able to guess which group you’re in and let that inform how you use power in your home.

“The ability to bring alive consumer smart meter data is a super exciting area for me,” Hersh says. “For the first time, utilities have just hoards and hoards and hoards of smart meter data, and it’s just sitting there. This changes around this paradigm.”


+ Recent posts