http://www.vesternet.com/compatibility/z-wave-compatibility-guide

Z-Wave Compatibility Guide: Choosing the Right Home Automation Devices

AUGUST 9, 2013 2 COMMENTS

One of the advantages of choosing the Z-Wave Home Automation standard is the wide variety of modules available from the many manufactures that support it.

However as things get more complex, compatibility issues can sometimes start to creep in, even with a system of devices that support the same protocol.  We asked Mark Onions at Vesternet to give us some background on the reasons behind these interoperability issues and what they recommend their users do to minimise them…

Z-Wave Compatibility

The Z-Wave wireless protocol is one of todays most widely adopted home automation technologies. It delivers a reliable and easy to install network suitable for almost any smart home. One of its great benefits is that it’s supported by more than 160 vendors who’ve introduced over 700 Z-Wave-based devices. This means that whatever type of device you’re looking for, there will be a Z-Wave version available.  Furthermore, each of these devices is tested and certified by the Z-Wave Alliance, so compatibility is assured.

However, this doesn’t mean that all Z-Wave devices will work with each other. This article looks at issues users need to be aware of and how they affect device compatibility.

그러나, 이 의미는 Z-Wave 디바이스들이 자동으로 서로 어울려져서 작업이 된다는걸 의미하지 않는다.

Z-Wave Backward Compatibility

Interoperability is at the centre of Z-Wave. All newly certified devices are backward compatible with existing Z-Wave products. This means today’s latest devices work with products from the earliest days of Z-Wave.

However, forward compatibility is a different matter. It’s not possible for a device released today, to support future device types or Z-Wave commands. You can’t support things that haven’t been defined or developed yet.

For instance, a remote control released in 2007 will control lights (On/Off/Dim); it is fully certified and works well. During 2010, new command classes were introduced allowing LED colours to be controlled as well as their brightness. Our remote control from 2007 can still control the new LED devices, but it can’t control their colour. This could be considered incompatibility, but this wouldn’t be fair, as these commands weren’t even invented when it was introduced. However, it does mean that a user needs to be careful when choosing a controller for devices that incorporate new command classes.

Certification vs Full Command Class Support

When a device is certified, it doesn’t have to support all Z-Wave command classes, it only needs to support the command classes for its intended function. It will be fully certified so long as these classes are correctly supported. This makes sense for devices such as actuators where they only need to support the relevant command classes for controlling lamps and appliances attached to them.

디바이스가 인증되었을때, 그게 모든 Z-Wave 커맨드클래스들을 지원해야 한다는 건 아니다. 

Problems arise when Z-Wave controllers don’t support all command classes. For example some controllers don’t support the classes used for locks and other security devices. There is nothing wrong in a controller not supporting particular classes, so long as this is documented to ensure customers know which device types can be used with it. Sometimes this information isn’t freely available in vendor’s documentation, so users usually need to dig a little deeper.

Also, it’s worth noting that controllers regularly receive firmware updates where new device and class support are added; so if a particular class of device isn’t supported now, it probably will be in the near future.

Firmware Versions

It’s not just Z-Wave controllers that have regular firmware updates, some more complex devices such as multiple sensors or even wall plugs can have firmware updates. So it’s always worthwhile checking if a new device has the latest firmware before trying to install it. If you’re not sure, check with your reseller, the best ones will be able to tell you what the firmware is and how to update it.

Documentation

There is a huge variation in Z-Wave documentation quality and consistency. The ZWave Alliance enforces common language for critical functions such as Include, Exclude, Association etc., but vendors can use their own terminology for other functions and processes. This can be confusing to the user as different vendors may describe the same process in different ways. This is made worse as most documentation is also translated from the vendor’s local language. Device documentation is now often supplemented by tutorials and videos showing how to install and use the devices.

Old Devices – Old Classes

As Z-Wave has matured over the last 10-years, its certification processes have become more strict and controlled. Through this time, some devices have gained certification that wouldn’t receive it today; these devices are now rare but will have incompatibilities with other devices. In many cases these devices had support for early implementations of Z-Wave classes, or classes that quickly became
superseded. For instance the ‘Multi Instance’ class was deprecated in favour of the ‘Multi Channel’ command class.

For most users, this won’t be an issue unless you’re trying to use a very old device.

Choosing the Right Devices

There has never been such a wide choice of Z-Wave devices and the level of compatibility and interoperability has never been higher. But users still need to be careful when selecting devices to work in their system.

For this reason, Vesternet created and maintains the only Z-Wave Compatibility guide. This helps users choose the devices that work well together and with a variety of Z-Wave controllers. And, to make it even easier, all verified products carry the ‘Vesternet Certified’ badge, taking all the guesswork out of choosing the right devices. Vesternet also has a huge library of tutorials, videos and resources that make it easy for people to install and use the devices.

References:

• Vesternet Z-Wave Compatibility Guide
• Vesternet Resources
  
• Vesternet Certified

Read More Z-Wave Articles on Automated Home

http://www.monblocnotes.com/node/2034

Created on 29-Jul-2014 - Updated on 28-Jul-2015 - 2600 views

A list of some organizations providing standards for the Internet of Things and Machine to Machine

what and who section contents are copied from relative web sites - in progress

• Open Interconnect Consortium
• what: the Open Interconnect Consortium (OIC) will seek to define a common communication framework based on industry standard technologies to wirelessly connect and intelligently manage the flow of information among devices, regardless of form factor, operating system or service provider. OIC also intends to deliver open source implementations for a variety of IoT market opportunities and vertical segments from smart home solutions to automotive and more.
• who: Cisco, Intel, Mediatek, Samsung, ADT, Atmel, Dell, EyeballNetworks, HP, etc.
• news:
• 20-Jul-2015: OIC Specification 0.9.1 available to members 
• 26-Feb-2015: liaison with Industrial Internet Consortium
• Thread Group
• what: build a technology that uses and combines the best of what’s out there and create a networking protocol that can help the Internet of Things realize its potential for years to come.
• who: ARM, Big Ass Fans, Freescale, nest, Samsung, Silicon Labs, Yale, etc.

• AllSeen Alliance
• what: to enable widespread adoption and help accelerate the development and evolution of an interoperable peer connectivity and communications framework based on AllJoyn for devices and applications in the Internet of Everything.
• who: Electrolux, Haier, LG, Microsoft, Panasonic, Qualcomm, Sharp, Silicon Image, Sony, Technicolor, TP-Link, etc.
• news:
• 15-Jul-2015: IBM and Pivotal join the initiative 
• HyperCat Consortium
• what: the HyperCat specification allows Internet of Things clients to discover what data an IoT server has available. It is built on the same Web standards that are now common for that interface, i.e. HTTPS, REST/HATEOAS, JSON.  With HyperCat, developers can write apps that will work across many servers, which helps to break down the walls between today's vertical silos.
• who: 1248, AIMES, AlertMe, Amey, ARM, Avanti Communications, Balfour Beatty, Bre, BT, Carillion, City of Westminster, Critical Software, Ctrl-Shift, EDF Energy, Eseye, Flexeye, Guildford Borough, Highway Agency, IBM, Intel, IntelliSense, In Touch, Living PlanIT, London City Airport, The Merseyside Transport Trust, Milligan, Mission:Explore, Neul, Open Dta Institute, Placr, Red Ninja Studios, Science Scope, SHABA, Stakeholder Design, Traak Systems, University of Birmingham, University of Bristol, University of Cambridge, University College London, Lancaster University, The Open University, University of Surrey, etc.
• Industrial Internet Consortium
• what: the Industrial Internet Consortium (IIC) was founded in March 2014 to bring together the organizations and technologies necessary to accelerate growth of the Industrial Internet by identifying, assembling and promoting best practices.
• who: AT&T, Cisco, General Electric, IBM, Intel, etc.
• news:
• 26-Feb-2015: liaison with Open Interconnect Consortium
• Global Standards Initiative on Internet of Things (IoT-GSI)
• what: the Global Standards Initiative on Internet of Things (IoT-GSI) promotes a unified approach in ITU-T for development of technical standards (Recommendations) enabling the Internet of Things on a global scale. ITU-T Recommendations developed under the IoT-GSI by the various ITU-T Questions - in collaboration with other standards developing organizations (SDOs) – will enable worldwide service providers to offer the wide range of services expected by this technology. IoT-GSI also aims to act as an umbrella for IoT standards development worldwide.
• who: members of ITU-T
• ITU Joint Coordination Activity on IoT
• what: the scope of the JCA-IoT is to coordinate the ITU-T work on the “Internet of Things” including networks aspects of identification of things, and ubiquitous sensor network (USN). 
• who: members of ITU-T
• oneM2M
• what: the purpose and goal of oneM2M is to develop technical specifications which address the need for a common M2M Service Layer that can be readily embedded within various hardware and software, and relied upon to connect the myriad of devices in the field with M2M application servers worldwide.
• who: 208 participating partners and members, most of them being affiliated to one of the following SDOs (Standards Developing Organization): ARIB, ATIS, CCSA, ETSI, TIA, TTA, TTC
• TIA TR-50 
• what: responsible for the development and maintenance of access agnostic interface standards for the monitoring and bi-directional communication of events and information between machine-to-machine (M2M) systems and smart devices, applications or networks.
• who: The Telecommunications Industry Association (TIA) is the leading [USA] trade association representing the global information and communications technology (ICT) industry.
• Open Mobile Alliance
• what: OMA delivers open specifications for creating interoperable services that work across all geographical boundaries, on any bearer network. OMA’s specifications support the billions of new and existing fixed and mobile terminals across a variety of mobile networks, including traditional cellular operator networks and emerging networks supporting machine-to-machine device communication.
• who: AT&T, BlackBerry, Intel, Microsoft, Motorola Solutions, NTT DOCOMO, Orange, Qualcomm, etc.
• OMG Data-Distribution Service for Real-Time Systems (DDS) 
• what: the first open international middleware standard directly addressing publish-subscribe communications for real-time and embedded systems. The Object Management Group (OMG) is an international, open membership, not-for-profit technology standards consortium.
• who: hundreds of organizations including software end-users in over two dozen vertical markets (from finance to healthcare and automotive to insurance) and virtually every large organization in the technology industry.
• Internet of Things (IoT) Architecture Working Group from IEEE
• what: to deliver a standard defining an architectural framework for the Internet of Things (IoT), including descriptions of various IoT domains, definitions of IoT domain abstractions, and identification of commonalities between different IoT domains.
• who: members of IEEE-SA (Standards Association)
• IETF
• what: CoAP, DTLS, ICN-IoT, 6LoWPAN, etc.
• who: IETF members
• IPSO Alliance
• what: IPSO seeks to establish the Internet Protocol as the basis for the connection of Smart Objects. The IPSO Alliance provides a foundation for industry growth by fostering awareness, providing education, promoting the industry, generating research, and creating a better understanding of IP and its role in the Internet of Things.
• who: ARM, Atmel, Bosch, Cooper Power Systems, Dust Networks, EDF, Ericsson, Freescale, Greenwave Systems, Gridconnect, IAR Systems, Landis+Gyr, Micrium, Sigma Designs, Silicon Labs, Silverspring, ST, SICS, Tridium, etc.
• Alliance for Internet of Things Innovation 
• what: to strengthen links and build new relationships between the different IoT players (industries, SMEs, startups) and sectors. It will also be used to promote interoperability and convergence between standards, facilitate policy debates and prepare a Commission's initiative for large scale testing and experimentation.
• who: European Commission, Bosch, Philips, Sigfox
• W3C Web of Things Community Group
• what: the aim of the Web of Things Community Group (CG) is to accelerate the adoption of Web technologies as a basis for enabling services for the combination of the Internet of Things with rich descriptions of things and the context in which they are used.
• who: Toshiba, IBM, University of Surrey, Fraunhofer Gesellschaft, Dell, Intel, Samsung, MITRE, Institut Telecom, Telecom Italia, Siemens, Nokia, NTT, Université de Lyon, Sony, INRIA, KDDI, Orange, etc.
• W3C Semantic Sensor Network Incubator Group
• what: the group had two main objectives. The first was to develop an ontology to describe sensors and sensor networks for use in sensor network and sensor web applications. The second was to study and recommend methods for using the ontology to semantically enable applications developed according to available standards such as the Open Geospatial Consortium's (OGC™) Sensor Web Enablement (SWE) standards.
• who: Open Geospatial Consortium, CSIRO, DERI, Ericsson, Boeing, Fundacion CETIC, Wright State University, etc.
• Wireless IoT Forum 
• what: to drive the widespread adoption of wireless wide-area networking technologies in both licensed and unlicensed spectrum.
• who: no yet public
• ZigBee Alliance
• what: to develop standards that ultimately deliver greater freedom and flexibility for a smarter, more sustainable world. As a result of this focus, the ZigBee Alliance provides green, low-power and open global wireless networking standards focused on monitoring, control and sensor applications.
• who: COMCAST, Freescale, Itron, Kroger, Landis+Gyr, Legrand, NXP, Philips, Schneider Electric, Silicon Laboratories, Texas Instruments, etc.
• ULE Alliance
• what: The ULE Alliance vision is to establish ULE (Ultra Low Energy) as the world’s leading control network eco-system for home and building use by leveraging the proven reliability and range of the DECT radio technology currently in use in 100’s of millions of products worldwide.
• who: DECT Forum, Dialog Semiconductor, DSP Group, Gigaset Communications, Vtech, etc.
• Z-Wave Alliance
• what: to support Z-Wave as the enabling technology for the age of anywhere/everywhere wireless control and monitoring.
• who: AHAM, CEA, CABA, Continua Health Alliance, CEDIA, ITU, IPSO Alliance, NIST, OpenADR Alliance, USNAP Alliance
• to be continued...

https://stanfy.com/blog/developers-guide-to-iot-standards/

Developer’s Guide To IoT Standards

Internet of Things may seem a young (and promising) industry but it has already started facing at least one problem typical for older ones. The problem is standardization, or rather lack of thereof: currently there’s a bunch of different platforms fighting, with new ones mushrooming every month or even more often.

The need for one standard to unite all the refrigerators, thermostats, cars, washing machines and other smart appliances is obvious. However, it seems like there won’t be just one winner in this war as too many players have already got some traction with manufacturers. As Z-Wave’s Avi Rosenthal put it:

“There will be a prevailing standard at some point. But it is going to take years, maybe 5-7 years, and I expect the standards will change over time.”

To navigate the rough sea of IoT standards, here’s a handy guide for developers gearing up towards building a new IoT appliance.

There are Bluetooth and Wi-Fi, so why bother?

Actually, quite a few players on the IoT scene don’t bother at all and just use the most widely adopted universal standards. It goes for all devices that would connect to your home Wi-Fi network, from Petcube to Amazon Echo, which also uses Bluetooth to stream music from mobile devices.

However, more sophisticated smart home devices like thermostats or energy monitoring systems, which need to interact with other appliances, need protocols tailored for their purposes. According to Jeffrey Kaplan, managing director of Think Strategies, usage of standards like Bluetooth and Wi-Fi raises questions of security, privacy, and efficiency.

Hence the fragmentation.

ZigBee

An open standard by IEEE dating back to 2003 with the later revisions from 2006 and 2007, ZigBee uses low-power radios to transfer data through mesh networks. That means that although the transmission is limited to 10–100 meters, it uses intermediate devices to pass the data further, so all the radios work as repeaters.

ZigBee is a good solution for those concerned about security: the mesh networks are secured by 128 bit symmetric encryption keys.

There are quite a few ZigBee-compatible devices on the market, however some say that gadgets by different manufacturers may have difficulties communicating with each other.

Z-Wave

This standard has the largest installed base of products at the moment, even though it’s a proprietary one owned by Sigma Designs. The standard also uses power-efficient radios and mesh networks but works on the 908.42 MHz frequency, while its rival ZigBee runs on the 2.5 GHz.

Z-Wave Alliance’s Raoul Wijgergangs says that ZigBee’s frequency is also used by Wi-Fi, which makes the spectrum much more cluttered. Less cluttered spectrum, in his opinion, can mean reduced power usage and fewer attempts that have to be made to send the data between radios.

The fact that Z-Wave is today’s market leader doesn’t mean anything if we think about the future. For example, the recent Samsung’s IoT chip Artik does not include support for Z-Wave, but will work with Wi-Fi, Bluetooth, Zigbee, and Google’s Thread.

Thread

One of the younger standards in the IoT world used by the Google-owned smart home appliances startup Nest. The working group behind the standard includes Samsung, ARM Holdings, Freescale, Silicon Labs, and Big Ass Fans. Thread creates an IP-addressable mesh network with up to 250 devices that supports cloud access and AES encryption.

Like ZigBee, it’s an open standard built on top of IEEE 802.15.4 wireless protocol; recently the two working groups even announced plans to collaborate on creating a unified solution with ZigBee as a network layer and Thread as an application layer.

Apparently this one is worth looking at if you’re thinking about building something that’s going to need to communicate with core smart home appliances. Also, betting on something backed by Google doesn’t seem a bad idea.

HomeKit

But here comes another standard backed by a big name in the industry: Apple’s HomeKit. It’s not available for customers yet but we know quite a bit about the standard already.

HomeKit is supposed to be a platform that unites Apple-made and Apple-certified devices via Wi-Fi and Bluetooth. Apple has already revealed a list of partners that includes iHome, Haier, Withings, Philips, iDevices, Belkin, Honeywell, and Kwikset.

HomeKit is not compatible for any other standards per se, though Apple has announced a hardware bridge that could be used to connect non-HomeKit devices that use ZigBee or Z-Wave with a HomeKit network. There are, however, numerous limitations to the range devices that can be bridged: basically, the only way to make sure your product will work with HomeKit is by receiving an MFi (Made For iPhone) license from Apple.

In addition to these four standards, there are several minor ones, as well as recently announced platforms we know nothing about, like that by Huawei. None of the current standards is perfect, which means that with the rapid increase in numbers of IoT devices we’ll see new entrants in this market.

As of today, however, it makes sense for IoT developers to look at the biggest players fighting a Battle Of The Four, with the battlefield being our own homes and hardware manufacturers’ preferences.

There’s another war going on, too — that of hardware platforms that can be used to power various Internet of Things appliances. This will be the topic of one of our next posts. Stay tuned!

GE PowerOn Precision 

ABB DRMS

SliverSpring DRMS

국내 DRMS 솔루션회사 

아이온 커뮤니케이션즈 

국내 DR 수요자원 관리회사 

iDRS 

벽산파워

효성

해외 수요자원 관리회사

에너낙

슈나이더 일렉트릭 / 에너지풀

디바이스와 어떻게 통신할수 있느냐에 대한 고민이 끝나면, 그 디바이스가 “무엇을 할수 있습니다.” 라고 하는 말을 알아 들을 수 있고, A 제품에게 들 은 말을 B 제품에게 실행 시킬수 있는 공통 언어가 있어야 한다. 이렇게 모든 디바이스와 대화를 나눌수 있는 공통된 행동/특성 명세를 IoT 표준 플 랫폼이 담당하는데 현재 이것 역시 표준화 전쟁중이다. 관련 기술 현황을 살 펴보자.

Allseen Alliance (2013년 12월~)

+ 목표

  - 상호 연결 가능한 Thing과 App의 확산

  - AllJoyn 기반 통신 프레임워크의 확산

+ 오픈소스 AllJoyn(올조인)

  - 가전기기/자동차/컴퓨터가 상호 커뮤니케이션할 수 있는 오픈소스 프레임워크

  - 퀄컴이 2011년 MWC에서 처음 공개한 오픈소스 프로젝트

  - 2013년 12월 리눅스 재단으로 소스 이관(리눅스 재단의 11번째 협업 프로젝트)

- allseenalliance.org 에서 코드와 API스펙 다운로드 가능

- WiFi 기반

+ Allseen Alliance가 성공할 것 같은 이유 (Allseen Alliance가 주장하는 이유임)

  - 다양한 분야의 많은 회사들이 참여하고 있기 때문

  - 공개표준 기반 오프소스 프로젝트 AllJoyn을 갖고 있기 때문

  - 이미 AllJoyn을 채택한 상용제품이 존재하기 때문 (LG HDTV, LIFX 스마트 전구)

  - 포괄적 인증 프로그램을 운영하고 있기 때문

- 참여업체: 시스코, 하이얼, LG전자, 파나소닉, 샤프, 퀄컴, MS, 리눅스 재단 등

Thread 그룹 (2014년 6월~)

+ 목표

  - Thing마다 상이한 프로토콜 문제 해결

  - 데이터 전송 거리 문제 해결

  - 배터리 제약 문제 해결

+ 가정용 기기들을 연결하고 제어하는 최선의 방법을 찾기 위해 설립

  + 가정용 네트워크 기술의 한계 (as-is)

    - HUB 기기가 죽으면 네트워크 자체가 불통됨

    - 설정이 어려움

    - 기기들이 항상 켜져 있어야 하기 때문에 배터리 소모가 심함

  + Thread 그룹이 만들려는 프로토콜

    - 쓰기 쉬울 것

    - 안전할 것 (Security)

    - 전력 효율이 좋을 것

    - IPv6 기반 공개 프로토콜일 것

    - HUB 없는 MESH 네트워크일 것

    - IEEE 802.15.4 무선 표준 (ZigBee)* 기반일 것

    - 다양한 기기를 지원할 수 있을 것

      * IEEE 802.15.4 무선 표준 : 저렴함과 단순함을 추구하는 사물(임베디드 시스템)을 위한 무선 네트워크 기술 (ZigBee로 통칭), 사람을 위한 무선 네트워크 기술 WiFi와 대비됨

+ Thread 기술의 특징

  - 지금 당장 사용 가능

  - Nest가 이미 초기형태의 Thread 기술을 사용하고 있음

- 교육과 인증 사업 추진 예정

- 참여업체: 구글, 삼성전자, ARM 등

OIC (Open Interconnect Consortium) (2014년 7월~)

+ 목표

  - IOT를 위한 연결(Connectivity) 요구사항 규정

  - 이종 기기들 사이의 상호운용성(Interoperability) 보장

+ 활동 분야

  + Interoperability 제공을 위한 스펙/인증/브랜드 규정

    - IP(네트워크) Protection 제공

    - 기기에 대한 인증 제공

    - 서비스 레벨 상호운용성 제공

  - 표준을 구현한 오픈소스 SW 제공

  - 공개표준, 크로스플랫폼SW 지향

- 참여업체: 인텔, Atmel, 델, 브로드컴, 삼성, 윈드리버 등

- 퀄컴 등의 영리 기업이 올씬얼라이언스를 통해 오픈소스 프로토콜 제정을 주도하는 것에 반대

- 퀄컴과는 경쟁, 오픈소스 공동체와는 협력 표방

oneM2M

- oneM2M은 한국 TTA를 비롯 7개 세계 주요 표준화 기관이 공동 설립한 글로벌 표준화 기구

+ 목표

  - 다양한 산업 직군간 요구사항, 아키텍처, 프로토콜, 보안기술, 단말 관리 및 시맨틱 추상화 표준 정의

- '14년 7.28~8.1 프랑스에서 개최된 oneM2M 12차 기술 총회에서 oneM2M 1.0 표준 승인

+ 참여업체

  - 한국 TTA와 ETSI(유럽), ATIS(북미), TTC(일본), CCSA(중국) 등 7개 세계 주요 표준화 기관을 비롯,

  - 해외기업 AT&T, 스프린트, 에릭슨, 시스코, 화웨이, 퀄컴, 알카텔루슨트, 인텔 등 참여

  - 국내기업 SKT, KT, LGU+, 삼성전자, LG전자 등 참여

본문에서 보면 Thread 그룹은 Zigbee 기반일것이라고 나오는데 ,

Zigbee / Thread / Z-wave / WeMo 등의 구분이 매우 궁금해지는데, 

저처럼 궁금한분은, 아래 링크를 타고 가서 읽어보시라~ (2015년 7월 기사) 

ZigBee, Z-Wave, Thread and WeMo: What's the Difference?

기사를 보면 Thread 쪽에 다음과 같은 언급이 있다. 

무튼, 이 표준화 전쟁은 어떻게 될것인가 매우 궁금해진다. 

AWS IoT – 사물 인터넷을 위한 클라우드 서비스

https://aws.amazon.com/ko/blogs/korea/category/aws-iot/  펌 

OpenADR 2.0 은 유틸리티들간에 그리고 에너지 관리 시스템들 사이에  정보를 교환하는것에 관해 표준화하며 반면에 SEP 2.0 은  게이트웨어에 의해 받아들인 마켓 시그널들에 대한 응답에 대한 디바이스 커뮤니케이션을 표준화한다.OpenADR 2.0 과 SEP 2.0 모두 SGIP CIM 가이드라인을 따른다. 2 가지 어플리케이션 레이어 프로토콜간에 매핑 테이블을 개발하기위한 노력이 이루어지고있다.

아래는 차이점을 나타낸다.

오픈ADR(OpenADR): 개방형 자동수요반응(Open Automated Demand Response)을 뜻하며, 지능형 수요반응에 적용되는 표준 통신 프로토콜이다. 전력공급자와 소비자 간 양방향 통신을 가능케 함으로써 송전과 배전의 효율성을 극대화하는 게 주목적이다. 보통 스마트그리드 통신은 인터넷·무선랜·지그비·전력선통신(PLC) 등의 수단으로 잘 알려져 있다. 오픈ADR은 이 같은 물리적 통신방식이 아닌 수요반응(DR) 신호 교환을 위한 응용계층의 표준기술이며, 기존의 수동작업을 통한 수요 반응을 대체하는 방법이다. 오픈ADR을 적용함으로써 전력공급자가 실시간으로 수요관리 명령을 내렸을 때, 소비자가 이에 대응해 자동으로 전기사용량을 줄이는 지능형 수요반응을 구현할 수 있게 된다. 파이크 리서치사(Pike Research)가 발행한 최근 조사보고서에 따르면, 지능형 수요반응에 대한 전세계 지출액은 2012년 연간 4억100만 달러에서 2018년까지 연간 17억 달러 규모까지 확대될 전망이다.

* 지능형 수요반응: 지능형 수요반응이란 전력공급 상황, 피크 부하율 및 전력생산·공급가격에 따라 자동으로 반응해 전력사용량을 조정하는 메커니즘을 의미한다. 이를 통해 소비자는 변동하는 가격에 전력 소비를 줄이거나 전력 사용 시간대를 옮길 수 있다. 기존 공급위주의 전력 정책이 환경문제, 에너지가격 급등 등으로 인해 한계에 봉착함에 따라 수요 관리 측면의 대안으로 적극 모색되고 있다. 

 한국전기연구원 (KERI) 발췌

관련 국내 기사:

http://www.newsis.com/ar_detail/view.html?ar_id=NISX20140218_0012731032&cID=10812&pID=10800 (기-1)

관련 논문

https://pure.ltu.se/portal/files/37136211/CoAP_SEP2_final.pdf   (논-1)