Standards Development and Convergence

1
Standards Development and Convergence

• Skip Ashton
• Senior VP Engineering
• Ember Corporation

2
Overview

• ZigBee Standards Development Process
• What takes the time and effort?
• Questions and issues in standard
• Where is it converging?

3
ZigBee Systems Architecture
Application Profiles (defined by ZigBee and OEMs)
Home Automation (HA) Building Automation
(CBA)Smart Energy (SE) more ...
Stack Feature Sets(defined by ZigBee)
ZigBee 2007 Specification - ZigBee PRO
Radios(defined by IEEE 802.15.4)
IEEE 802.15.4 Ratified 2003, Updated 2006
4
Who is Involved in ZigBee?

• ZigBee Promoters represent cross section of
  providers and users of technology
• Ember, Emerson, Freescale, Itron, Landis Gyr,
  Philips, Reliant Energy, Schneider, ST, Tendril
  and Texas Instruments
• Membership over 300 additional companies

5
ZigBee Development Process

• Marketing Working Group defines features
  required and creates MRD
• Architecture Review Reviews MRD and assigns to
  Work Group for Completion
• Work Groups Complete specific assigned work to
  create TRD and then Specification
• Core Stack Ongoing stack maintenance and
  Cluster Library
• Home Automation
• Smart Energy
• Commercial Building Automation
• ZigBee Qualification Group test plan
  development and testing to validate specifications

6
Smart Energy Development Timeline

• December 2006 Marketing Study group formed
• MRD Ballot March 12, 2007
• TRD Ballot Nov 14, 2007
• Initial Pretest event Dec 7, 2007
• Profile Approved by Board (Rev 14) in June 2008
• Vendor release of product 3-6 months later
• 18 months to complete then time for vendor to
  release
• 3 months MRD, 8 months TRD, 5 months testing, 3-6
  months for product release

7
What takes the time?

• Bulk of time is in technical development and
  testing (13 of 16 months)
• Define specific devices needed
• Define attributes and commands for each device
  (data types, sizes, optional fields etc)
• Define message formats and exchanges
• Define device behavior based on messages
• Only as required do not test functional
  behavior but required device behavior from
  commands
• Testing defines if this is done properly, use or
  error cases covered, can be properly implemented

8
Beyond Devices and Clusters

• Application profile must also specify underlying
  network behavior, policies and security
• Baseline ZigBee provides underlying wireless
  technology for
• Forming and joining networks
• Security
• Network routing and management
• Application service discovery
• Error handling and recovery
• It is not enough to define data models and
  commands network must operate under known
  conditions
• No different than what happens when you arrive to
  use a strange WiFi access point

9
What else is developed?

• Developing the standard is not enough
• Work group also developed a test plan to certify
  devices as compliant and interoperable
• Test events held from December to May
• Validate specification and test plan
• In final event certify those devices that
  complete testing
• Also validate test harnesses used by ZigBee test
  houses for certification of additional devices

10
How Does this Converge?

• Many Groups Defining Data Types and Models for
  various Smart Grid Elements
• Data can be represented in various formats
• ZigBee uses binary messaging for efficiency on
  low bandwidth wireless communications
• IEC specifies object models in CIM using XML
• OASIS also defines models in XML

11
Data versus Behavior

• Mapping of data between different models
  generally not difficult
• SE 1.0 was mapped to CIM
• SE 2.0 evaluating tokenized XML for data format
• Different mappings or data formatting will
  converge over time
• This data mapping is small part of overall
  specification
• Network behavior and security
• Commands and expected responses
• Device behavior normal and error cases
• Testing to validate behavior and interoperability

12
Specification Efforts

• Many groups now wanting to write pieces of the
  specifications
• ZigBee is moving the opposite direction and
  working to harmonize
• Already working with IEEE on PHY/MAC
• Moving to IETF based routing methods, security
  etc
• Contributing Application Profile to IEC to
  commonize models and methods
• In the end the market wants unified standard
  solutions and not arguments on whose is better