Standards Development and Convergence Skip Ashton Senior VP Engineering Ember Corporation

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

Application Profiles (defined by ZigBee and OEMs) Stack Feature Sets (defined by ZigBee) Radios (defined by IEEE ) ZDO NWK App Support (APS) SSP ZigBee Systems Architecture Physical Radio (PHY) Medium Access (MAC) IEEE Ratified 2003, Updated 2006 ZigBee 2007 Specification: - ZigBee PRO Home Automation (HA) Building Automation (CBA) Smart Energy (SE) + more... Custom OEM… HCL ZDO NWK App Support (APS) SSP Custom OEM… HCL Custom OEM… App Profile ZDO NWK App Support (APS) SSP

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

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

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

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

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

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

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

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

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