certification test specification - silicon labs … · written by: dking;mvo;bbr date: 2018-03-06...

Certification Test Specification

Z-Wave Certification Test Specification

Document No.: CTS10999

Version: 6

Description: The purpose of this document is to define the test cases that are performed in Z Wave self-certification and Z Wave verification testing. Compliance to the test cases ensures a high level of interoperability for all Z Wave certified products.

Written By: DKING;MVO;BBR

Date: 2018-03-06

Reviewed By: JFR;MAM;NTJ;CHL;CST;ATOK;DKING;BBR;JAD;JRM

Restrictions: Public

Approved by:

Date CET Initials Name Justification

2018-03-06 11:32:17 NTJ Niels Thybo Johansen

This document is the property of Silicon Labs. The data contained herein, in whole or in part, may not be duplicated, used or disclosed outside the recipient for any purpose. This restriction does not limit the recipient's right to use information contained in the data if it is obtained from another source without restriction.

CTS10999-6 Z-Wave Certification Test Specification 2018-03-06

silabs.com | Building a more connected world. Page ii of vi

REVISION RECORD

Doc. Rev

Date By Pages affected

Brief description of changes

2 2011 HCS All Full updated version combining all tests in certification

3 20121205 DKING All Complete update based on INS10637-34 Certification Form

6 20131003

20131004

DKING Section 11.1

Section 11.2 Section 2.5 & 12

Increased delay time when performing tests from 12 seconds to13 seconds Added requirement to verify a non-secure controller cannot add devices securely Deleted test case for Send Invalid Scheme Get Deleted test case for Send Invalid Scheme Report Updated references to new split Command Class Specifications

4 20180306 BBR All Added Silicon Labs template

https://www.silabs.com/


silabs.com | Building a more connected world. Page iii of vi

Table of Contents

1 ABBREVIATIONS ................................................................................................................................. 1

2 INTRODUCTION ................................................................................................................................... 2

2.1 Purpose .............................................................................................................................................. 2 2.2 Audience and prerequisites ................................................................................................................ 2 2.3 Overview – a readers guide ............................................................................................................... 2 2.4 Validity of this document .................................................................................................................... 3 2.5 Precedence of definitions ................................................................................................................... 3 2.6 Terms used in the Z-Wave Certification program .............................................................................. 3

3 Z-WAVE CERTIFICATION PROGRAM ............................................................................................... 5

3.1 Certification test areas ........................................................................................................................ 5 3.1.1 General Z-Wave compliance.................................................................................................... 5 3.1.2 Product documentation ............................................................................................................ 5 3.1.3 Hardware .................................................................................................................................. 6 3.1.4 Z-Wave network support .......................................................................................................... 6 3.1.5 Z-Wave application support ..................................................................................................... 6 3.1.6 Controllers ................................................................................................................................ 6

4 TOOLS USED FOR TESTING .............................................................................................................. 7

4.1 Tools used for hardware testing ......................................................................................................... 7 4.2 Tools used for Z-Wave network support testing ................................................................................. 7 4.3 Tools used for Z-Wave application support testing ............................................................................ 7

5 GENERAL Z-WAVE COMPLIANCE ................................................................................................... 8

5.1 General Z-Wave Compliance ............................................................................................................. 8 5.1.1 Use of defined Device and Command Classes ....................................................................... 9 5.1.2 All commands in each supported Command Class are implemented ...................................10 5.1.3 All mandatory Command Classes are implemented ..............................................................11 5.1.4 Version of the Z-Wave protocol .............................................................................................12 5.1.5 Optional Flag in the Node Information Frame ........................................................................13 5.1.6 Z-Wave Device Class and Z-Wave Command Class specification version ..........................14

5.2 Certified Z-Wave Stack ....................................................................................................................15 5.3 Z-Wave Hardware Platform ..............................................................................................................16 5.4 Meta Data .........................................................................................................................................17 5.5 Basic Command Class .....................................................................................................................18

5.5.1 Basic Command Class Control ..............................................................................................18 5.5.1.1 Basic Command Class Control with On and Off ............................................................19 5.5.1.2 Basic Command Class Control with configurable value ................................................20 5.5.1.3 Basic Command Class Control with learned value ........................................................20

5.6 Proprietary Command Class ............................................................................................................22 5.7 Tolerant towards unexpected frame lengths ....................................................................................23 5.8 Inclusion Method ..............................................................................................................................24

5.8.1 Low Power Inclusion Slaves ..................................................................................................25 5.8.1.1 Low Power Inclusion Slaves ...........................................................................................26

5.8.2 Network Wide Inclusion – Slave ............................................................................................26 5.8.3 Network Wide Inclusion – Controller ......................................................................................28

5.9 Battery operation ..............................................................................................................................30 5.9.1 Listening Mode .......................................................................................................................31

5.9.1.1 Documentation for the Listening Mode ..........................................................................32 5.9.2 FliRS Device ..........................................................................................................................32

5.10 Security Layer implemented .............................................................................................................33 5.10.1 Documentation about Z-Wave Secure Enabled Product .......................................................33 5.10.2 Same functionality when secure and non-secure included ....................................................34



silabs.com | Building a more connected world. Page iv of vi

5.10.3 Different functionality when secure and non-secure included ...............................................35 5.10.3.1 Secure Generic or Specific Device Class ......................................................................36 5.10.3.2 Documentation about Z-Wave Secure Enabled Controller ............................................36

5.11 Production test mode .......................................................................................................................37 5.12 Factory Reset ...................................................................................................................................38

5.12.1 Documentation Factory Reset................................................................................................38 5.13 Power Down .....................................................................................................................................39 5.14 Listening Flag ...................................................................................................................................39 5.15 Watchdog Timer ...............................................................................................................................40 5.16 Duty Cycle ........................................................................................................................................40 5.17 Manufacturer Specific Command Class ...........................................................................................41 5.18 Explorer Frames ...............................................................................................................................42

6 PRODUCT DOCUMENTATION ..........................................................................................................44

6.1 Inclusion / Exclusion / Replication ....................................................................................................44 6.1.1 Use and explanation non-standard terms ..............................................................................45

6.2 Include device into existing network .................................................................................................46 6.3 Devices from multiple vendors in one network .................................................................................47 6.4 Documentation for Configuration Command Class ..........................................................................48 6.5 Documentation for Associations .......................................................................................................49 6.6 Documentation related to Basic Command Class ............................................................................50 6.7 Documentation for Verification Testing ............................................................................................51 6.8 Documentation for Controllers ..........................................................................................................52

7 HARDWARE .......................................................................................................................................53

7.1 Minimum communication range tests ...............................................................................................53

8 Z-WAVE NETWORK SUPPORT ........................................................................................................55

8.1 Slave .................................................................................................................................................55 8.1.1 Inclusion of DUT (Slave) ........................................................................................................56 8.1.2 Exclusion of product (Slave) ..................................................................................................59 8.1.3 Send Node Information Frame based on user interaction .....................................................60 8.1.4 Repeater Functionality ...........................................................................................................60 8.1.5 Support of Security Command Class .....................................................................................61

8.1.5.1 Secure Inclusion .............................................................................................................61 8.2 Routing Slave ...................................................................................................................................63

8.2.1 Enhanced Slave .....................................................................................................................63 8.2.2 Inclusion of DUT (Routing Slave) ...........................................................................................64 8.2.3 Exclusion of product ...............................................................................................................64 8.2.4 Send Node Information Frame based on user interaction .....................................................64 8.2.5 Repeater Functionality ...........................................................................................................64 8.2.6 Request topology update from SUC / SIS .............................................................................64 8.2.7 Device will call ZW_RequestNetworkUpdate daily ................................................................65 8.2.8 Support of Security Command Class .....................................................................................66

8.2.8.1 Secure Inclusion .............................................................................................................66 8.3 Z-Wave Controller Library (Controller, Static Controller, Installer, Bridge or Portable) ...................67

8.3.1 Unique HomeID ......................................................................................................................68 8.3.2 Inclusion of Controller ............................................................................................................69 8.3.3 Exclusion of Controller ...........................................................................................................72 8.3.4 Send Node Information Frame based on user interaction .....................................................73 8.3.5 Request Node Information Frame ..........................................................................................73 8.3.6 Controller will call ZW_RequestNetworkUpdate daily ............................................................74 8.3.7 Controller will call ZW_RequestNetworkUpdate before configuring associations .................76 8.3.8 Controller Replication Command are acknowledged with Command Complete ...................78 8.3.9 Secondary controller ..............................................................................................................80

8.3.9.1 Secondary controller documentation ..............................................................................81 8.3.10 Support of Security Command Class .....................................................................................82



silabs.com | Building a more connected world. Page v of vi

8.3.10.1 Secure Inclusion of a Controller .....................................................................................82 8.3.11 Controller can act as primary and/or Inclusion controller .......................................................85

8.3.11.1 Inclusion of products from other manufacturer ...............................................................87 8.3.11.2 Exclusion of products from other manufacturer .............................................................90 8.3.11.3 Receive primary controller role via controller shift .........................................................92 8.3.11.4 Relinquish primary controller role via controller shift......................................................94 8.3.11.5 Support reception of protocol replication data ................................................................96 8.3.11.6 Ability to replicate protocol data .....................................................................................98 8.3.11.7 Ability to replicate group/scene data ............................................................................100 8.3.11.8 Delete a malfunctioning node .......................................................................................101 8.3.11.9 Support replacement of a malfunctioning node ............................................................102 8.3.11.10 Controller initiates rediscovery of nodes ......................................................................103 8.3.11.11 Controller initiates rediscovery from a SUC / SIS on problems ...................................103 8.3.11.12 Assign SIS Capability to included Controller ................................................................104 8.3.11.13 Support of Security Command Class ...........................................................................106 8.3.11.14 Controller is Static or Bridge Controller ........................................................................109

8.4 General Demands for all protocol libraries .....................................................................................114 8.4.1 All supported Command Classes are listed in the NIF ........................................................114 8.4.2 Controlled Command Classes are listed in the NIF .............................................................115

8.4.2.1 Control Mark exists if controlled Command Classes are displayed in the NIF ............116

9 Z-WAVE APPLICATION SUPPORT ................................................................................................117

10 CONTROLLER COMPLIANCE ........................................................................................................119

10.1 All Controllers .................................................................................................................................119 10.1.1 Compliance with requirements for Generic and Specific Device Class ...............................119 10.1.2 Certified devices can be included ........................................................................................120

10.1.2.1 Non-preferred devices are not forced out of the network .............................................121 10.1.3 Network Management functionality is included in the application/GUI ................................122

10.1.3.1 Network Management functions are password protected ............................................122 10.1.3.2 Network Management functions are hidden from end user .........................................123

10.1.4 This device/software provides a limited control application/GUI..........................................123 10.1.4.1 Network Management is provided through a separate application/GUI ......................124

10.1.5 Devices from non-preferred manufacturers are placed in a special section ........................124 10.1.6 The user is informed that the device is not part of the preferred ecosystem .......................125

10.1.6.1 Wording similar to the following is used: … .................................................................126 10.1.7 The user can select if they wish to continue with inclusion ..................................................127

10.2 Dedicated Controllers .....................................................................................................................128 10.2.1 Minimum Controller Functionality is implemented ...............................................................128 10.2.2 The controller recognizes devices as “unknown” devices. ..................................................129

10.2.2.1 Unknown devices can be controlled via the Basic Set commands ..............................129 10.3 Universal Controllers ......................................................................................................................130

10.3.1 Minimum Controller Functionality is implemented ...............................................................130 10.3.2 The controller recognizes devices as “unknown” devices ...................................................131

10.3.2.1 Unknown devices can be controlled via the Basic Set commands ..............................131

11 SECURITY TEST CASES .................................................................................................................132

11.1 Z-Wave PC Controller includes the DUT .......................................................................................133 11.1.1 Invalid Nonce in Network Key Set ........................................................................................135 11.1.2 Invalid MAC in Network Key Set ..........................................................................................136 11.1.3 Invalid Network Key Set .......................................................................................................137 11.1.4 Send Invalid Scheme Inherit ................................................................................................138 11.1.5 Delay Scheme Get ...............................................................................................................139 11.1.6 Delay Nonce Get ..................................................................................................................139 11.1.7 Delay Network Key Set ........................................................................................................140 11.1.8 Delay Nonce Report .............................................................................................................141 11.1.9 Delay Scheme Inherit ...........................................................................................................142



silabs.com | Building a more connected world. Page vi of vi

11.2 Z-Wave PC Controller is included by the DUT ...............................................................................143 11.2.1 Invalid Nonce in Network Key Verify ....................................................................................145 11.2.2 Invalid MAC in Network Key Verify ......................................................................................146 11.2.3 Invalid Network Key (Verify) .................................................................................................147 11.2.4 Delay Scheme Report ..........................................................................................................148 11.2.5 Delay Nonce Report .............................................................................................................148 11.2.6 Delay Nonce Get ..................................................................................................................149 11.2.7 Delay Network Key Verify ....................................................................................................150 11.2.8 Delay Scheme Report after Scheme Inherit ........................................................................151

12 REFERENCES ..................................................................................................................................152



silabs.com | Building a more connected world. Page 1 of 152

1 ABBREVIATIONS

Abbreviation Explanation

CE Conformité Européenne, indicates conformance to European union regulations

CTT Compliance Test Tool

DUT Device under test

ERTT Enhanced Reliability Test Tool

FCC Federal Communication Commission

RF Radio Frequency




2 INTRODUCTION

2.1 Purpose

The purpose of this document is to specify the tests that are to be performed in Z-Wave certification. It therefore covers all areas of Z-Wave certification, including network management functions, application functionality, and minimum RF performance.

Two main steps in Z-Wave certification are the “self-certification” test preformed by the OEM and the verification test performed by a authorized Z-Wave test partner. To assist in performing these tests the Z-Wave alliance provides the Compliance Test Tool (CTT). The CTT facilitates automated tests for the majority of the Z-Wave device and command classes used in products.

Building on and further extending the idea of the CTT, this document specifies application level test cases in a “language” that is both human readable, but also easy to parse and process for automated test tools such as the CTT.

Summing up, this document:

- Creates a common reference of test cases that are needed to perform Z-Wave self-certification and Z-Wave verification testing;

- Assures high quality and consistency in verification tests regardless of which authorized Z-Wave test partner performs the tests

It may be noted that this document does not introduce significant changes in the certification criteria. The fundamental certification criteria are defined and described in the Z-Wave device class specification and the certification form.

It is not the purpose of this document to:

- Provide a reference for full quality assurance testing

- Replace parts of or the entire Z-Wave Device Class Specification

2.2 Audience and prerequisites

The audience of this document is primarily Z-Wave OEM’s, Z-Wave developers, and authorized Verification Test Partners. It is assumed that the reader of this document is familiar with Z-Wave, the Z-Wave Device Class Specification and the Z-Wave certification program, particularly with [1], [2], and the Z-Wave Developer’s Kit overall.

2.3 Overview – a readers guide

This document is divided into a number of subsection, these are outlined here along with their intended use.

Section 2 is the document introduction providing the reader with the intended purpose, prerequisites and other relevant information needed before reading the document.

Section 3 of the document describes the Z-Wave certification program, and the various areas it covers.




Section 4 introduces the tools recommended to use to perform self-certification and verification tests. The tools are briefly introduced and references to further information is given.

Section 5-10 includes test case specifications needed to perform a Z-Wave self-certification or a verification test. The test cases are divided into sections directly corresponding to the sections of the certification form.

Section 11 includes additional test cases for security enabled devices

2.4 Validity of this document

This document is effective immediately.

This version of the Z-Wave Certificaiton Test Specification is updated using version 8.5 of the Z-Wave certification form (INS10637-34). Future changes in the Z-Wave certification program and/or Z-Wave Device Class specification may cause new versions of this document.

Always check the Z-Wave Technical Services website to assure you working with the latest version of the Z-Wave specifications, including this document.

2.5 Precedence of definitions

Regarding Z-Wave Certification, definitions are valid based on the following precedence of documents (“1.” has highest precedence):

1. The Z-Wave Certification Form, Doc. INS10637 [7]

2. Z-Wave Device and Command Class Specifications, SDS10242 [2] and SDS12657 / SDS12652 [3]

3. Z-Wave Device and Command Class Specifications not yet incorporated into SDS10242 [2] and SDS11060 [3]

4. The Z-Wave Certification Overview, Doc. INS10638 [6]

5. Z-Wave ZW0102 / ZW0201 / ZW0301 /400 Series Application Programming Guide, Doc. INS10247, INS10682, INS12034, INS11095, INS10690 [1]

6. This document

2.6 Terms used in the Z-Wave Certification program

This document describes how the mandatory, recommended and optional aspects of compliance to the Z-Wave specification of a product are tested.

The words “shall” and “must” specify aspects that are mandatory for compliance. Equally, “must not” has to be adhered to for compliance. Products that are in violation any such statement are considered to be not Z-Wave compliant.

The words “may”, “could”, and “may not” leave the choice to the implementer. “Recommended” also leaves the choice formally to the OEM, but provides additional guidance. Future versions of Z-Wave may make aspects that are recommended at this time mandatory.




Throughout the Z-Wave Certification Program, the following terms are used:

Interoperability Interoperability is the successful inter-working of multiple products from multiple manufacturers, for multiple applications, that may be based on multiple versions of Z-Wave. The detailed requirements for Compliance to the Z-Wave protocol and the Z-Wave Device Class specifications have been chosen to assure that compliant products will be interoperable. However, it may be noted that Interoperability always describes the inter-working of two or more products, while Compliance relates to the conformity to the Z-Wave standard.

Z-Wave Compliance Adherence to the Z-Wave standard – especially to the definitions made in the Z-Wave Device Class Specification [2] – by a given product. The term “conformance” is used equivalently to the term “compliance”

Z-Wave Certification Process of providing assurance that a given product is Z-Wave compliant.

Self-certification Process, where OEMs conduct the certification of compliance to the Z-Wave standard themselves.

Verification Confirmation of the Self-certification through an external test partner.

PICS Protocol Implementation Conformance Statement; Set of detailed forms where the details of the targeted Z-Wave Compliance, e.g. which Z-Wave Device and Command Classes a product supports are recorded.

Certification Fees Fees to be paid by OEMs for the Z-Wave Certification; Covers costs for administration, review process, and verification testing.




3 Z-WAVE CERTIFICATION PROGRAM

All products that use the Z-Wave Technology and carry the Z-Wave logo must be certified. This includes embedded products, Z-Wave gateways or hardware interfaces, and also software products that incorporate the Z-Wave application protocol (i.e. the Z-Wave device & command classes).

The certification process is designed to help OEM customers ensure that products have been correctly and robustly implemented, in accordance with the requirements and criteria described in the Z-Wave device class specification [2] and the Z-Wave certification form [7]. These requirements are designed to ensure that the product will successfully interoperate with other certified Z-Wave products from the same and other vendors, for the same and other applications.

The certification process is in its core a “self-certification” process. The OEM is responsible for ensuring that products are designed and tested for compliance; typically conducted as and recommended to be part of the internal QA process. Furthermore, OEMs must ensure that their product’s certification remains valid over the lifecycle with any changes that may be made on the products.

For more details about the Z-Wave certification process please refer to the Z-Wave Certification Overview [6].

3.1 Certification test areas

As a part of the Z-Wave certification process, the Z-Wave functionality which is declared as implemented in the certification form, is to be verified by doing a number of self-certification and verification tests.

Please note that a Z-Wave product that implements a certain Z-Wave functionality in part or full, but where such functionality is not marked as supported in the corresponding section of the product’s Z-Wave certification form, is also in violation to Z-Wave compliance and would thus not pass Z-Wave certification.

The Z-Wave certification form is divided into a number of areas, each reflecting a class of requirements. Each self-certification and verification test case reflects one or several items in such a class. The purpose and contents of each of the classes are described below.

3.1.1 General Z-Wave compliance

The general Z-Wave compliance section of the form contains a declaration from the OEM that the device has been designed in accordance with the Z-Wave device class specification. It furthermore outlines the very basic functionality of the device, such as ability to perform factory reset, whether the device is a listening device or not, if it contains ability to enter a production test mode etc.. Most items in the general Z-Wave compliance area are review only items.

3.1.2 Product documentation

The purpose of the product documentation section is to ensure that the product documentation includes basic information to assure consumers can successfully utilize, fundamental Z-Wave functionality of the product.

It further enforces common Z-Wave terminology for basic interactions such as ‘inclusion’ and ‘exclusion’ to be used in all Z-Wave product documentation. In addition to the terminology the documentation must also cover certain subjects in terms of an interoperability statement, and additional documentation for various command classes such as configuration and association.




3.1.3 Hardware

The purposes of the hardware section is to ensure that all devices that come to marked meet a minimum level of RF performance such that they will operate properly in a mesh network configuration. The hardware area contains only simplistic RF tests which should be possible for most technical personal to perform.

The purpose of the hardware area is not to repeat FCC / CE tests or to perform RF quality testing.

3.1.4 Z-Wave network support

The purpose of the Z-Wave network support section is to ensure devices support basic device class functionality. For all devices this includes functionality such as the ability to be included and exclusion from a network, and the ability to work as a repeater for other devices. For controllers this area will also include test of advanced controller functionality such as SUC/SIS implementation. Test cases for this area is mostly defined as step-by-step guides including one or many verification steps using the Z-Wave Zniffer network monitor.

3.1.5 Z-Wave application support

The Z-Wave application support section tests the application functionality of Z-Wave devices. This area includes tests of all command classes implemented in a device, and tests of special behavior related to the generic and specific device class of the device.

Z-Wave application support tests are mostly defined in the Z-Wave application test case specification language used by the Compliance Test Tool, CTT.

3.1.6 Controllers

The controller section of the form identifies the type of controller being certified, the product types it is designed to control, its compliance with minimum controller functionality requirements and whether or not control of preferred VS non-preferred devices is implemented.




4 TOOLS USED FOR TESTING

Obviously the tools available for testing determine the complexity and time needed to perform the self-certification and verification tests. One of the benefits of the Z-Wave certification process is that the OEM has access to the same tools as the authorized verification test lab. The tools are provided partly via the Z-Wave developer’s kit and partly by the Z-Wave alliance.

This section will introduce the tools normally used for testing, and provide references to additional information and instructions about how to use the tools.

4.1 Tools used for hardware testing

To perform the minimum communication range testing the Enhanced Reliability Test Tool program (ERTT) can be used. The ERTT program is included in the Z-Wave development kit as one of the functions of the PC Controlller. For more information about how to use the ERTT program please refer to the “Z-Wave Reliability Test Guideline” [4] or to the latest developers kit.

4.2 Tools used for Z-Wave network support testing

To test the supported network management features, an example network is setup using modules and sample software from the Z-Wave developer kit. When a reference is made to sample software e.g. a LED dimmer, it implicitly means a Z-Wave module loaded with LED dimmer sample software.

An example network for Z-Wave network support testing will typically include a module connected to the PC Controller as the primary controller, a LED dimmer as an example slave device and a Z-Wave “Zniffer” network analyzer to monitor and verify the network traffic.

For more information about how to setup and use the tools mentioned please refer to “PC based Controller User Guide” (INS10240) and “Z-Wave Zniffer User Guide” (INS10249) included in the developers kits.

4.3 Tools used for Z-Wave application support testing

The Z-Wave application support is typically verified using the Z-Wave Compliance Test Tool (CTT). The Z-Wave Compliance Test Tool is provided as a membership benefit by the Z-Wave Alliance. The CTT is a Microsoft Windows based application that automates the testing of Z-Wave device and command classes.

The CTT program is continuously under maintenance as new device and command class are created by the Z-Wave community; hence the latest available CTT version may not explicitly contain test scripts for all classes. This means some classes are tested using an example network typically consisting of a PC Controller as the primary node, an LED dimmer as an example slave device and a Z-Wave “Zniffer” network analyzer to monitor and verify the network traffic.




5 GENERAL Z-WAVE COMPLIANCE

5.1 General Z-Wave Compliance

Test Case General Z-Wave Compliance

Certification Form Item

G.1

Item Description The product does not violate requirements for Z-Wave compliance as defined.

Purpose This field is used for the OEM to confirm that the DUT is designed for Z-Wave compliance, using the documentation available from Silicon Labs such as the Z-Wave Device Class Specification, the Z-Wave Command Class Specification [3] and the Z-Wave Application Programming Guide [1].

Pre-requisites/ Test setup

Required Test Tool

Procedure To validate these items, refer to the results of the Z-Wave network support and Z-Wave application support sections.

Expected outcome

Comments Note: No additional tests are currently performed for these items in verification testing. Please note however that random spot checks are performed.




5.1.1 Use of defined Device and Command Classes

Test Case Use of defined Device and Command Classes


G.1.1

Item Description The device only uses the Generic Device Class, Specific Device Class and Command Classes defined in the Z-Wave Device Class Specifications and Z-Wave Command Class Specifications [2].

Purpose The purpose of this item is to verify that the Device and Command Classes that are displayed in the NIF of the DUT actually exist in the Specifications.


The DUT and Zniffer are using the same operation frequency.

Required Test Tool

Zniffer

Procedure 1. Send an unsolicited Node Information Frame from the DUT

2. Compare Generic Device Class, Specific Device Class and Command Classes with the Z-Wave Device Class Specification and the Z-Wave Command Class Specification and verify that all mentioned Command Classes in the Node Information Frame really exist and are defined in these documents.

Expected outcome

The device only uses a Generic Device Class, a Specific Device Class and Command Classes that are defined in the Z-Wave Device Class Specification and the Z-Wave Command Class Specification.

Comments If the Zniffer does not display a name for a Device or Command Class but only the hexadecimal byte value then this Device or Command class is either not yet known to the Zniffer or it does not exist, in which case the verification of this item fails.




5.1.2 All commands in each supported Command Class are implemented

Test Case All commands in each supported Command Class are implemented


G.1.2

Item Description All commands (get, set, report etc.) in each Command Class supported by the device are implemented.

Purpose The purpose of this item is to verify that all commands (get, set, report etc.) in each Command Class supported by the DUT are implemented.


Required Test Tool

Procedure This item can only be verified after all tests in the Z-Wave application support section (Section A) have been performed. If during those tests Commands in any supported Command Class are found that are not implemented then this item fails.

Expected outcome

All commands of all Command Classes supported by the DUT must be implemented.

Comments The purpose of this item is not to test if every Command of each supported Command Class is implemented correctly. These verification tests will be performed in Section A of the Certification Form. Only if a Command is not implemented at all this item fails.




5.1.3 All mandatory Command Classes are implemented

Test Case All mandatory Command Classes are implemented


G.1.3

Item Description All mandatory Command Classes for the selected Generic/Specific Device Class are implemented.

Purpose The purpose of this test is to verify that all mandatory Command Classes for the selected Generic and Specific Device Class combination are implemented in the DUT.



Required Test Tool

Zniffer

Procedure 1. Send an unsolicited Node Information Frame from the DUT 2. Review the Node Information Frame and the Device Class Specification to

check if all mandatory Command Classes are displayed in the Node Information Frame

Expected outcome

All mandatory Command Classes must be displayed in the Node Information Frame and implemented in the DUT.

Comments This item may also fail if during the Z-Wave application support tests the DUT shows that mandatory Command Classes are not implemented.




5.1.4 Version of the Z-Wave protocol

Test Case Version of the Z-Wave protocol


G.1.4

Item Description The device is not based on a beta version of the Z-Wave protocol.

Note: Devices based on Beta versions of the SDK cannot be certified. Beta versions end in the Z Wave version numbering scheme with a “0” in the last digit, e.g. “4.20” or “5.00”

Purpose The purpose of this item is to confirm that the product is not based on a Beta version of the Z-Wave protocol.


The Z-Wave PC Controller and the DUT must be part of the same Z-Wave network.

Required Test Tool

Z-Wave PC Controller Zniffer

Procedure 1. Use the PC Controller to send a Version Get command to the DUT 2. Verify that the protocol version in the Version Report command from the

DUT matches the Z-Wave developer's kit version given in section 2.3.3 of the Certification Form and that this version is not a Beta version

Expected outcome

The DUT is not based on a SDK Beta version.

Comments Beta versions in the Z-Wave version numbering scheme have a “0” as the last digit e.g. 4.20, 5.00.

The mapping between the version of the Z-Wave developer's kit and the protocol version in the Version Report command is given in the Version Command Class section of the Command Class Specification.

If the DUT does not support the Version Command Class then it is only possible to verify that the Z-Wave developer's kit version given in section 2.3.3 of the Certification Form is not a beta version.




5.1.5 Optional Flag in the Node Information Frame

Test Case Optional Flag in the NIF Certification Form Item

G.1.5

Item Description The optional functionality flag is set in Node Information Frame in case any optional Command Classes are included for the selected device.

Purpose The purpose of this item is to verify, that the optional flag is set correctly as specified.



Required Test Tool

Zniffer

Procedure 1. Send an unsolicited Node Information Frame from the DUT 2. Use Zniffer output to verify that the optional bit is set correctly in the Node

Information Frame

Expected outcome

If any optional items (non-mandatory Command Classes) are implemented the optional functionality flag must be set to “true”, if only the mandatory Command Classes are implemented the optional flag must be set to “false”.

Comments




5.1.6 Z-Wave Device Class and Z-Wave Command Class specification version

Test Case Z-Wave Device Class and Z-Wave Command Class Specification version


G.1.6

Item Description Specify document number and version of the Z-Wave Device Class and Z-Wave Command Class specifications used e.g. SDS10242-19:

Note:

The latest version of the Device Class and Command Class Specifications must be used. These can be downloaded from the Z-Wave Technical Services website.

Purpose These fields inform the verification test lab which version of the Device Class Specification has been used to design the product.


Required Test Tool

Procedure

Expected outcome

The latest version of the Device Class and Command Class Specifications must be used with this certification form. These can be downloaded from the Z-Wave Technical Services website.

Comments If any other then the latest version is used a special permission is needed from the Z-Wave Certification Group.




5.2 Certified Z-Wave Stack

Test Case Certified Z-Wave Stack Certification Form Item

G.2 G.2.1 G.2.2 G.2.3 G.2.4 G.2.5 G.2.6

Item Description G.2: The product is based on a standard Z-Wave stack.

G.2.1: The entire application runs on the Z-Wave chip (Embedded system).

G.2.2: The application runs at least partially on a second micro-controller (Embedded system).

G.2.3: The application runs on a second micro-controller. The standard Z-Wave Serial API is used.

G.2.4: The application runs on a second micro-controller. A modified Z-Wave Serial API is used.

G.2.5: The application runs on a PC. The application uses the standard Z Wave Serial API (either directly or hidden through another library layer)

G.2.6: The application runs on a PC. The application does not use the standard Z-Wave Serial API (either directly or hidden through another library layer).

Purpose These fields are used to confirm that the standard Z-Wave stack is used. Furthermore these fields are used to indicate the type of stack used (Serial API two MCUs, Serial API PC Application or one MCU Embedded system).


Required Test Tool

Procedure These fields must be verified by the OEM by reviewing the product design documentation.

Expected outcome





5.3 Z-Wave Hardware Platform

Test Case Z-Wave Hardware Platform


G.3 G.3.1

Item Description G.3: Product is certified as Z-Wave Hardware Platform.

G.3.1: Product exposes Z-Wave standard Serial API to applications.

Purpose These fields are used to indicate the product is a Z-Wave hardware platform, exposing the Z-Wave standard serial API to other applications.


Required Test Tool

Procedure These fields must be verified by the OEM by reviewing the product design documentation.

Expected outcome

If the hardware product information given in section 2.3.4 of the certification form is marked as Z-Wave Hardware Platform Product, item G.3 and G.3.1 must be marked accordingly.





5.4 Meta Data

Test Case Meta Data Certification Form Item

G.4 G.4.1 G.4.2 G.4.3

Item Description G.4: The product transmits Meta Data as defined in a Command Class and/or other types of information that require multiple Z-Wave messages to transport the entire content between nodes.

G.4.1: All such transmissions are performed by using the Z-Wave API call ZW_SendDataMeta.

G.4.2: The product implements traffic shaping/policing having a minimum delay of 35ms after each frame carrying such data as defined in [1]

G.4.3: The API call ZW_SendDataMeta is used to transmit commands for a Manufacturer Proprietary Command Class.

Purpose These fields are used to indicate that the product streams or transmits bulk data in the Z-Wave network. For transmitting such data in a Z-Wave network certain rules and procedures must be met.


Required Test Tool

Procedure The OEM must verify these items by reviewing product design documentation, and operation of the product in question.

Expected outcome

Reviewing the operation of the product in question must show that ZW_SendDataMeta is used to transmit streams or bulk data in the Z-Wave network data. The review is met when review result matches the Command Class implementation guideline [3].





5.5 Basic Command Class

Test Case Basic Command Class Support


G.5

Item Description The Basic Command Class is implemented in compliance to the Generic and Specific Device Class of the product.

Purpose The purpose of this test is to verify that the product implements the Basic Command Class as required according to the supported Generic and Specific Device Class.


The DUT is part of the same network as a Controller.

Required Test Tool


Procedure The items must be validated based on the Z-Wave Device Class Specification [2].

Expected outcome

The Basic Command Class must work similar to the Command Class to which it is mapped according to the Generic and Specific Device Class Specification.

Comments

5.5.1 Basic Command Class Control

Test Case Basic Command Class Control


G.5.1

Item Description The device controls via Basic commands.

Purpose The purpose of this test is to verify the DUT's capabilities to control a slave device via Basic Command Class.


The DUT is part of the same network as another node that can be controlled via the Basic Command Class.

Required Test Tool

Zniffer Slave

Procedure 1. Consult the product or technical documentation to figure out how other

nodes can be controlled via Basic Commands 2. Test if the DUT can communicate with other nodes via Basic Commands

Expected outcome

The DUT should be able to control other nodes via Basic Commands.

The Zniffer trace must show Basic Set or Get Commands from the DUT to other nodes.

Comments The product or technical documentation must describe how the Basic Command Class is controlled.




5.5.1.1 Basic Command Class Control with On and Off

Test Case Basic Command Class Control with On and Off


G.5.1.1

Item Description The device controls with OFF (0x00) and ON (0xFF) as minimum.

Purpose The purpose of this test is to verify that the device is able to control the Basic Command Class with Basic On (0x00) and Basic Off (0xFF) Commands.


The DUT is part of the same network as a LED Dimmer module. The devices are setup such that the DUT is controlling the LED Dimmer i.e. via association.

Required Test Tool

Zniffer LED Dimmer

Procedure 1. Setup the Basic Set Command to send 0x00 2. Send Command to the LED Dimmer and verify it in the Zniffer. The LED

Dimmer is turned off 3. Setup the Basic Set Command to send 0xFF 4. Send Command to the LED Dimmer and verify it in the Zniffer that the

LED Dimmer is turned on

Expected outcome

The Zniffer trace must show the Basic Set commands send from the DUT to the LED Dimmer with the values specified above.

Comments The product or the technical documentation must describe how Basic Commands with values 0x00 and 0xFF can be send to other nodes in the network.




5.5.1.2 Basic Command Class Control with configurable value

Test Case Basic Command Class Control with configurable value


G.5.1.2

Item Description It is possible to configure any value to be used in Basic Set Commands sent by the device.

Purpose The purpose of this test is to verify that the device is able to control the Basic Command Class using a configurable value.



Required Test Tool

Zniffer LED Dimmer

Procedure 1. Setup the Basic Set Command to send 0x00. 2. Send command to LED Dimmer and verify in Zniffer that the LED Dimmer

is turned off. 3. Setup the Basic Set Command to send 0xFF. 4. Send command to LED Dimmer and verify in Zniffer that the LED Dimmer

is turned on. 5. Setup the Basic Set Command to send Value = 1. 6. Send command to LED PC- and verify it in Zniffer. 7. Setup the Basic Set Command to send Value = 17. 8. Send command to LED Dimmer and verify it in Zniffer. 9. Setup the Basic Set Command to send Value = 55. 10. Send command to LED Dimmer and verify it in Zniffer. 11. Setup the Basic Set Command to send Value = 99. 12. Send command to LED Dimmer and verify it in Zniffer. 13. Setup the Basic Set Command to send Value = 255. 14. Send command to LED Dimmer and verify it in Zniffer. 15. Setup the Basic Set Command to send Value = 0. 16. Send command to LED Dimmer and verify it in Zniffer.

Expected outcome

The Zniffer trace must show the Basic Set commands send from the DUT to the LED Dimmer with the values specified above.

Comments The product or technical documentation must describe how the values used in Basic Commands can be configured.

5.5.1.3 Basic Command Class Control with learned value

Test Case Basic Command Class Control with learned value


G.5.1.3

Item Description The device learns values to be used in Basic Set commands by enquiring other devices with Basic Get and is able to learn any value to be used in the




Basic Set.

Purpose The purpose of this test is to verify that the device is able to control the Basic Command Class using values learned from other nodes in the network.



Required Test Tool

Zniffer LED Dimmer

Procedure 1. Hold down the button on the LED Dimmer until only D1 is on and the other

LED Dimmers are off 2. Instruct the DUT to learn value from the LED Dimmer 3. Press the button on the LED Dimmer to turn off D1 4. Send the learned Basic value to the LED Dimmer from the DUT 5. Verify in the Zniffer trace that the Basic Set values are equal to the Basic

Report values 6. Hold down the button on the LED Dimmer until D1 and D2 are on and D3

is off 7. Instruct the DUT to learn value from the LED Dimmer 8. Press the button on the LED Dimmer to turn off D1 and D2 9. Send the learned Basic value to the LED Dimmer from the DUT 10. Verify in Zniffer trace that the Basic Set values are equal to the Basic

Report values

Expected outcome

The values received by the DUT polling a Basic Report must be used in all subsequent Basic Set Commands sent by the DUT to the LED Dimmer.

Comments The product or technical documentation must describe how the values used in Basic Commands can be learned from other nodes in the network.




5.6 Proprietary Command Class

Test Case Proprietary Command Class


G.6 G.6.1

Item Description G.6: This product uses one or multiple Proprietary and/or Manufacturer Proprietary Command Classes.

G.6.1: The product uses the Proprietary Command Class and this has been approved by Silicon Labs based on the “Proprietary Command Class Request Form” [5]. Copies of the relevant Proprietary Command Class Request Forms have been attached to this Certification Form. (see also Note 1)

Purpose These fields are used to indicate that the product is using Proprietary and/or Manufacturer Proprietary command classes.


Required Test Tool

Procedure The OEM must confirm that a “Proprietary Command Class Request Form” is submitted to Silicon Labs.

Expected outcome

In order to be allowed to use proprietary command classes a “Proprietary Command Class Request Form” must be submitted. All certifications are conditional to get the proprietary command class request form approved by Silicon Labs.





5.7 Tolerant towards unexpected frame lengths

Test Case Tolerant towards unexpected frame lengths


G.7

Item Description The Frame Length field is NOT used to discard an incoming frame in which the frame length is longer than expected. The implementation is robust against frames that are longer than expected.

Purpose It is not allowed to use the length field to discard an incoming frame, since newer versions of the command class might expand the length of frames.


Required Test Tool

Procedure The OEM must confirm by reviewing the product design documentations that the length field under no circumstances is used to discard frames, and that the product implementation is robust against frames which are longer than expected.

Expected outcome





5.8 Inclusion Method

Test Case Normal Power Inclusion Certification Form Item

G.8

Item Description The device shall be able to operate at normal power level when being included into an existing Z-Wave network.

(For controllers: if instructed to use normal power level by the primary/Inclusion controller)

Purpose The purpose of this test is to verify that the Inclusion power level of the device can also be a normal power level.


The DUT is excluded from any previous networks, preferably by doing a factory reset.

Required Test Tool

CTT or any other Controller that is able to perform a full power Inclusion Zniffer

Procedure 1. Open the Controller window in the Project Properties of an open CTT

Project 2. Press the “Add Node” button in the Controller window 3. Perform Inclusion step on the DUT 4. Verify the transfer presentation from CTT, the Node Information Frame

from the DUT and all other Inclusion commands are sent in normal power messages

Expected outcome

The Inclusion process is done with normal power messages.

Comments Note: If any message is send with low power the Zniffer trace will state “LTX.*” in the Data column.

The DUT also passes this test if a low power Inclusion is continued with a normal power NIF from the DUT. This low power inclusion can be done with the PC Controller.

The including Controller instructs the included node to do a full or low power inclusion by sending out the initial Transfer Presentation messages as full or low power messages.




5.8.1 Low Power Inclusion Slaves

Test Case Low Power Inclusion Slaves


G.8.1

Item Description The device is a slave device and has a user configurable mode to operate at low power level when being included into an existing Z-Wave network.

(Notes:

1. It is permitted to make this mode as a default mode 2. Mark this item as n/a if the device is not a slave device

Purpose The purpose of this test is to test the reduction of Inclusion power in a slave device.



Required Test Tool


Procedure 1. Examine the DUT documentation and activate the low power Inclusion

mode accordingly 2. Start and reset the PC Controller

a) Controller > Reset Controller 3. Press “Add Node” on Z-Wave PC Controller

a) Node > Add Node 4. Perform Inclusion step on the DUT triggering a Node Information Frame

transmission 5. Verify the Node Information Frame from the DUT was sent in low power

Expected outcome

The Node Information Frame must show in the Zniffer trace as being send as “LTX.BroadCast”.

Comments Note: If the node information frame is send with normal power the Zniffer trace will state “BroadCast” in the Data column.




5.8.1.1 Low Power Inclusion Slaves

Test Case Low Power Inclusion Slaves


G.8.1.1

Item Description The device’s documentation describes the normal power Inclusion versus the low power Inclusion, and how to activate either mode.

Purpose Verification of the documentation regarding the low and normal power Inclusion.


Required Test Tool

Procedure Verify by examining the product documentation accompanying the device for testing and/or any other documentation provided by the OEM such as product website, help files etc.

Expected outcome

The documentation must include a section explaining how the different power levels are activated.

Comments

5.8.2 Network Wide Inclusion – Slave

Test Case Network Wide Inclusion – Slave


G.8.2

Item Description This device implements Network Wide Inclusion.

Purpose The purpose of this test is to verify the Network Wide Inclusion feature of a slave device.



Required Test Tool


Procedure 1. Press the button “NW Inclusion” in the Z-Wave PC Controller 2. Verify in the Zniffer, that the PC Controller sends “Cmd Set NWI Mode”

and “Transfer Presentation” commands 3. Activate the Network Wide Inclusion function on the DUT 4. Verify in the Zniffer, that the DUT sends “Explorer Autoinclusion Node

Info” 5. Verify in the Zniffer, that the DUT was included correctly




Expected outcome

If the DUT supports the Network Wide Inclusion the Zniffer output must be substantially similar to:

Comments 1 If this frame is a normal Node Information Frame then the DUT started a

classic Inclusion instead of an NW Inclusion. Please consult the product documentation to see how an NW Inclusion can be started. If the DUT only starts an NW Inclusion if the classic Inclusion fails then the DUT must be moved away from the including Controller so that the classic Inclusion attempt does not succeed.

DUT PC Controller

CMD Set NWI Mode

Transfer Presentation

Explorer Autoinclusion Node Info1

Assign ID

ACK

NOP

ACK

Find Nodes in Range

ACK

NOP Power

ACK

Command Complete

ACK

Get Nodes in Range

ACK

Node Range Info

ACK




5.8.3 Network Wide Inclusion – Controller

Test Case Network Wide Inclusion - Controller


G.8.2

Item Description This device implements Network Wide Inclusion.

Purpose The purpose of this test is to verify the Network Wide Inclusion feature of a controller device.



Required Test Tool

Zniffer LED Dimmer

Procedure 1. Start the 'Network Wide Inclusion' function in the DUT according to the

provided information in the Manual. 2. Verify in the Zniffer, that the DUT sends 'Cmd Set NWI Mode' and

'Transfer Presentation' commands. 3. Plug the LED Dimmer. 4. Verify in the Zniffer, that the LED Dimmer was included.




Expected outcome

If the DUT supports the Network wide Inclusion the Zniffer output must be substantially similar to:

Comments

DUT LED Dimmer

CMD Set NWI Mode


Node Info

Assing ID

ACK

NOP

ACK

Find Nodes in Range

ACK

NOP Power

ACK

Command Complete

ACK

Get Nodes in Range

ACK

Node Range Info

ACK

Only if the DUT is a static Controller




5.9 Battery operation

Test Case Battery operation Certification Form Item

G.9 G.9.1

Item Description G.9: The product is battery operated.

G.9.1: When learn mode is initiated the product will operate in normal transmit mode until an Inclusion/Exclusion process is completed, before entering power down mode. (Notes: After entering learn mode the device must stay awake until a callback status with the value LEARN_MODE_DONE or LEARN_MODE_FAILED is received from the API.)

Purpose This field is used to indicate that the product is battery operated and designed to fulfill the minimum requirements for battery operated devices.


Required Test Tool

Procedure The OEM must confirm by reviewing product design documentation and operation that the product will operate in normal transmit mode and not go to sleep mode before the Inclusion process is completed.

Expected outcome

The DUT is a battery operated device and it remains in listening mode during the entire Inclusion and Exclusion process.

Comments Note: No additional tests are currently performed for these items in the verification test. Please note, that random spot checks are performed.




5.9.1 Listening Mode

Test Case Listening Mode Certification Form Item

G.9.2

Item Description The device can be put into a mode to remain awake and listen to commands through user interaction (e.g. to allow enquiring Version or Manufacturer Specific).

Purpose The purpose of this test is to verify if the battery operated device can enter a listening mode and stay awake to receive and transmit commands.


The DUT is included into the Z-Wave PC Controllers Z-Wave network.

Required Test Tool


Procedure 1. Refer to the DUT’s documentation and activate the listening mode in the

device. 2. Use the Z-Wave PC Controller to enquire the device (Cmd Class > Send)

a) If the device supports the Basic Command Class use a Basic Get. b) If the device supports the Version Command Class use a Version Get. c) If the device supports the Manufacturer Specific Command Class use

a Manufacturer Specific Get. 3. Verify that the commands are received and that reports are sent correctly.

Expected outcome

The commands must be verified either in the Zniffer trace, or as receiving commands directly in the PC Controller.

Comments If the PC Controller includes a battery operated device then it will queue any outgoing commands until it receives a Wakeup Notification from this node. To test the listening mode of the DUT the command queuing must be disabled so that commands are sent out immediately. This can be done by clicking on the checkbox in 'Q...' column of the node list.

This test can also be performed by running a CTT script for any supported command class. The CTT does not queue commands for battery operated devices.

There is no minimum timing requirement for the listening mode. It is recommended to stay awake for at least 10 seconds and to prolong this time if any command has been received.




5.9.1.1 Documentation for the Listening Mode

Test Case Documentation for the Listening Mode


G.9.2.1

Item Description The device’s documentation describes how to activate this mode.

Purpose Verification of the documentation regarding the activation of the listening mode.


Required Test Tool


Expected outcome

The documentation must include a section explaining how DUT can be put in Awake Mode/Listening Mode.

Comments

5.9.2 FliRS Device

Test Case FliRS Device Certification Form Item

G.9.3

Item Description This is a FliRS device.

Purpose The purpose of this test is to verify that the DUT is a Frequently listening Routing Slave (FliRS).


The DUT is included into the Z-Wave PC Controllers Z-Wave network.

Required Test Tool


Procedure 1. Trigger a Node Information Frame from the DUT. 2. In the Security byte of the NIF either the 'Sensor 250ms' or the 'Sensor

1000ms' should be set as “true”. 3. Send an arbitrary command from the Z-Wave PC Controller to the DUT. 4. Verify in the Zniffer that the Z-Wave PC Controller uses Wakeup Beams to

wake up the DUT before it sends the actual command.

Expected outcome

The NIF of the DUT shows the FLiRS capabilities and other nodes use Wakeup Beams to communication with the DUT.

Comments




5.10 Security Layer implemented

Test Case Security Layer implemented


G.10

Item Description The device implements the Z-Wave Application Security Layer in accordance with [8].

Purpose The purpose of this item is to verify that the DUT is a Security Enabled Z-Wave product and all requirements for such a product are fulfilled.


Required Test Tool

Security Enabled Z-Wave Controller Security Enabled Zniffer

Procedure 1. Trigger a Node Information Frame from the DUT. 2. Verify the Security Command Class is listed as supported in the NIF.

Expected outcome

The DUT is identified as a Security Enabled Z-Wave product in the NIF.

Comments All other mandatory tests for a Security Enabled Z-Wave product are listed in section 8.3.10 or 8.3.11.13.

5.10.1 Documentation about Z-Wave Secure Enabled Product

Test Case Documentation about Z-Wave Secure Enabled Product


G.10.1

Item Description The product documentation (manuals, help files, web page link etc.) clearly describes the product as a Security Enabled Z-Wave Product.

Purpose Verification of the documentation regarding Z-Wave Security Enabled products.


Required Test Tool


Expected outcome

The DUT must clearly be described as a Z-Wave Security Enabled product that can use encrypted Z-Wave messages to communicate with other Security Enabled Z-Wave devices.

Comments A possible example sentence may be as follows: “This device is a security enabled Z-Wave product that is able to use encrypted Z-Wave messages to communicate to other security enabled Z-Wave products”




5.10.2 Same functionality when secure and non-secure included

Test Case Same functionality when secure and non-secure included


G.10.2

Item Description The functionality and supported/controlled command classes of the device is identical when included as a secure and non-secure device.

Purpose The purpose of this test item is to verify that the functionality of the device and supported/controlled Command Classes of the DUT are identical when the device is included as a secure and as a non-secure device.


The DUT must be excluded from any existing network, preferably by doing a factory reset.

Required Test Tool

Z-Wave PC Controller Security Enabled Z-Wave Controller Security Enabled Zniffer

Procedure 1. Use the normal Z-Wave PC Controller to include the DUT as a normal

node. 2. Trigger a Node Information Frame from the DUT. 3. Reset the DUT and the Z-Wave PC Controller's network. 4. Use the Security Enabled Z-Wave Controller to include the DUT as a

secure node. 5. Trigger a Node Information Frame from the DUT. 6. Send a Security Commands Supported Get Command to the DUT. 7. Verify that the same Command Classes are supported when the DUT is

included secure/non-secure.

Expected outcome

The DUT has the same Command Classes in the NIF when being secure and non-secure included and the Security Commands Supported Report Command from the DUT must only list Command Classes that are also listed in the NIF.

Comments If any other behavior differences between secure and non-secure mode exist is not tested here. However if other differences are detected in other tests this item may still fail.




5.10.3 Different functionality when secure and non-secure included

Test Case Different functionality when secure and non-secure included


G.10.3

Item Description The functionality and/or supported/controlled command classes is different when included as a secure and non-secure device.

Purpose The purpose of this test item is to verify that the functionality of the device and supported/controlled Command Classes of the DUT are different when the device is included as a secure and as a non-secure device.



Required Test Tool

Z-Wave PC Controller Security Enabled Z-Wave Controller Security Enabled Zniffer

Procedure 1. Use the normal Z-Wave PC Controller to include the DUT as a normal

node. 2. Trigger a Node Information Frame from the DUT. 3. Reset the DUT and the Z-Wave PC Controller's network. 4. Use the Security Enabled Z-Wave Controller to include the DUT as a

secure node. 5. Trigger a Node Information Frame from the DUT. 6. Send a Security Commands Supported Get Command to the DUT. 7. Verify that additional Command Classes are listed in the Security

Commands Supported Report Command from the DUT that are not listed in the NIF.

Expected outcome

The DUT provides support for additional Command Classes when being included as a secure node.

Comments If behavior differences between secure and non-secure mode really exist is not tested here. However if no differences are detected in all other tests this item may still fail.




5.10.3.1 Secure Generic or Specific Device Class

Test Case Secure Generic or Specific Device Class


G.10.3.1

Item Description The device is categorized with a secure generic or specific device class.

Purpose The purpose of this item is to verify that the DUT has a Secure Generic or Specific Device Class.


Required Test Tool

Zniffer

Procedure 1. Trigger a NIF from the DUT 2. Verify that the NIF of the DUT contains a Secure Generic or Specific

Device Class.

Expected outcome

The DUT should be categorized with a generic or specific device class.

Comments

5.10.3.2 Documentation about Z-Wave Secure Enabled Controller

Test Case Documentation about Z-Wave Secure Enabled Controller


G.10.3.2

Item Description The product documentation (manuals, help files, web page link etc.) states a Security Enabled Z-Wave Controller must be used in order to fully utilize the product.

Purpose Verification of the documentation regarding the use of a Security Enabled Z-Wave Controller.


Required Test Tool


Expected outcome

The documentation must contain a part which explains that a Security Enabled Z-Wave Controller is needed to use all features of the DUT.

Comments A possible example sentence may be as follows: “This device must be used in conjunction with a Security Enabled Z-Wave Controller in order to fully utilize all implemented functions.”




5.11 Production test mode

Test Case Production test mode Certification Form Item

G.11 G.11.1

Item Description G.11: A production test mode is implemented in the product.

G.11.1: The production test mode can only be entered by external hardware stimulation.

Purpose These items are used for the OEM to inform the verification test lab that a production test mode exists in the product. The OEM can choose to include information about how to activate the test mode.


Required Test Tool

Procedure If these fields are marked the OEM must confirm that the device can enter the product test mode.

Expected outcome





5.12 Factory Reset

Test Case Factory Reset Certification Form Item

G.12

Item Description The device provides a factory reset function.

Purpose The purpose of this test is to check if the Z-Wave part of the device is reset when performing a factory reset.


The DUT is included into an existing network with the Z-Wave PC Controller.

Required Test Tool


Procedure 1. Refer to the DUT’s documentation and perform a factory reset as stated. 2. Try using the Z-Wave PC Controller to communicate with the DUT (i.e.

sending a basic set/get). 3. Verify that the device does not react to the commands sent from the Z-

Wave PC Controller.

Expected outcome

The DUT is expected to reset its Z-Wave part. If the device is a slave it must be reset to HomeID = 00000000, if the device is a controller it must be reset to a pre-programmed or a randomly generated HomeID.

Comments During Factory Reset all application specific settings like Association grouping data, configuration settings, protection and alarm settings should be reset as well.

5.12.1 Documentation Factory Reset

Test Case Documentation Factory Reset


G.12.1

Item Description The factory reset function is described in the documentation.

Purpose Verification of the documentation regarding the Factory Reset function.


Required Test Tool


Expected outcome

The documentation must include a section explaining how the Z-Wave part of the DUT can be reset to factory settings.

Comments




5.13 Power Down

Test Case Power Down Certification Form Item

G.13

Item Description The product uses the Power Down functionality in the API.

Purpose This item is used for the OEM to indicate that the power down functionality from the Z-Wave Power API is used.


Required Test Tool

Procedure

Expected outcome


5.14 Listening Flag

Test Case Listening Flag Certification Form Item

G.14

Item Description Listening Flag set to APPLICATION_NODEINFO_LISTENING for continuously powered devices based on a Z-Wave library with repeater functionality.

Listening Flag set to APPLICATION_NODEINFO_NOT_LISTENING for not continuously powered devices e.g. battery operated devices.

Purpose The purpose of this test is to verify that the listening bit in the node information frame is set correctly.


The DUT is included into an existing network with the Z-Wave PC Controller.

Required Test Tool


Procedure 1. Trigger a NIF sent from the DUT. 2. Verify that the listening bit is set in accordance with Device Class

Specification.

Expected outcome

If the device is always listening, the bit must be set to “true”, if the device is battery operated the listening bit must be set to “false”.

Comments




5.15 Watchdog Timer

Test Case Watchdog Timer Certification Form Item

G.15

Item Description The watchdog timer of the Z-Wave chip is enabled.

Purpose To protect the product against getting stuck in an undesired state, the watchdog timer can be enabled.


Required Test Tool

Procedure The OEM must confirm if the watchdog timer is used by reviewing product design and documentation.

Expected outcome


5.16 Duty Cycle

Test Case Duty Cycle Certification Form Item

G.16

Item Description The product does not have a transmit duty cycle of more than 1%, relative to a one hour period.

Purpose Regulatory requirements in Europe demand that the device does not have a transmit duty cycle of more than 1%, relative to a one hour period. Similar requirements may exist in other regions as well. This must be verified by the OEM when products for other regions are developed.


Required Test Tool

Procedure The OEM must confirm by measuring that the device does not have a higher duty cycle than 1% relative to the hour in normal operation.

Expected outcome

Comments Note: No tests are performed for this item in verification testing and this is not an actual Z-Wave requirement. The OEM is responsible for not violating any local regulations regarding radio transmit duty cycles.




5.17 Manufacturer Specific Command Class

Test Case Manufacturer Specific Command Class


G.17 G.17.1 G.17.2 G.17.3 G.17.4 G.17.5 G.17.6

Item Description G.17: If the Manufacturer Specific Command Class is supported, provide the values returned in the Manufacturer Specific report in this section (otherwise please insert “n/a”)

G.17.1: Manufacturer ID 1

G.17.2: Manufacturer ID 2

G.17.3: Product Type ID 1

G.17.4: Product Type ID 2

G.17.5: Product ID 1

G.17.6: Product ID 2

Purpose The purpose of this item is to test if the values, which are returned by the Manufacturer Specific Command Class, are correct. The values of the Manufacturer Specific Command Class are among others used for other devices to identify the device and any special features.


The DUT is included into an existing network with the PC Controller.

Required Test Tool


Procedure 1. Use the PC Controller to send a Manufacturer Specific Get to the DUT. 2. Verify that the returned values are in accordance with items G.17.1 to

G.17.6.

Expected outcome

The returned values must be verified either in the Zniffer trace, or directly in the Z-Wave PC Controller.

The Manufacturer ID's in G.17.1 and G.17.2 must correspond to the correct Manufacturer. The Manufacturer IDs are listed in the Device Class Specification [2].

Comments The Manufacturer ID referenced in G.17.1 and G.17.2 is assigned by Silicon Labs. Please send a request to the Z-Wave Certification E-mail address if your company needs one assigned.

The Product Type ID and Product ID numbers are assigned by the manufacturer and are intended for use in identifying and differentiating various products from the same manufacturer. These numbers should be unique for each device.




5.18 Explorer Frames

Test Case Explorer Frames Certification Form Item

G.18

Item Description The device shall be able to initiate and/or repeat the use of Explorer Frames to obtain a new route to a lost destination node

Purpose The purpose of this test item is to verify that the DUT is able to send Explorer Frames to obtain a new route to a lost destination node in order to maintain a stable network.


The DUT and a LED Dimmer are included into the same existing network.

Required Test Tool

LED Dimmer Zniffer

Procedure For Controller:

1. Send any Command from the DUT to the LED Dimmer. For example a Basic Set.

2. Unplug the LED Dimmer. 3. Send any command from the DUT to the LED Dimmer. 4. Verify that an Explorer Frame was sent after 3 failed attempts of sending a

normal Command.

For Slaves:

1. Ensure the devices are setup such that the DUT is controlling the LED Dimmer i.e. via association.

2. Try to send any Command from the DUT to the LED Dimmer. 3. Verify the Command was received from the LED Dimmer. 4. Unplug the LED Dimmer. 5. Try to send any command from the DUT to the LED Dimmer 6. Verify that an Explorer Frame was sent after 3 not responded Commands.




Expected outcome

If the DUT supports the Explorer Frames Functionality the Zniffer output must be substantially similar to:

Comments If a slave device does not have any way of sending out requests (e.g. unsolicited Reports, Get, Set Commands) to other nodes than there is no way to send out Explorer Frames as well. In this case this item should not be checked.

DUT LED Dimmer

Basic Set

ACK

Basic Set

ACK

Basic Set

ACK

LED Dimmer is powered off

Basic Set

Basic Set

Basic Set

Explorer Normal Basic Set




6 PRODUCT DOCUMENTATION

6.1 Inclusion / Exclusion / Replication

Test Case Inclusion / Exclusion / Replication


D.1

Item Description The product documentation (manuals, help files, web page links, etc) describes the ‘inclusion’, ‘exclusion’ and ‘replication’ between Z Wave node(s)

Purpose The purpose of this item is to ensure that crucial Z-Wave functions are explained properly and independent of OEM and product type.


Required Test Tool

Procedure Verify by examining the product documentation accompanying the device for testing and/or any other documentation provided by the OEM such as product website, help files, links etc.

Expected outcome

Z-Wave products documentation must describe the Z-Wave functions "Inclusion" and "Exclusion". If the DUT is a Controller, the "Replication" between Controllers must be described as well. It must be clear from the descriptions how those functions can be used or activated on the DUT. However it is up to the OEM to either have a separate section for explaining the actual Z-Wave functions and for how they can be activated in the DUT or to have a combined section for both topics.

Comments For Slave devices the required description for the "Inclusion" process is the same as in item D2. For Controllers it must be described additionally how other devices can be included into the network of the tested Controller.

The "Replication" here refers to the protocol replication between Controllers that is used to exchange protocol replication data between different Controllers of the same network (these functions are tested in items 8.3.10.5 and 8.3.10.6). How a Controller can receive or transmit protocol replication data (through Learn Mode, Controller Shifts or as a separate function) must be clearly described in the product documentation.




6.1.1 Use and explanation non-standard terms

Test Case Use and explanation non-standard terms


D.1.2

Item Description If other terms/words are used for ‘Inclusion’, ‘Exclusion’ and ‘replication’ in the documentation and/or user interface of the product, the product documentation contains at least a list/table explaining the synonyms. (Mark as “n/a” if only standard terms are used)

Purpose The purpose of these items is to create a common Z-Wave terminology for the consumer independent of OEM and product type.


Required Test Tool


Expected outcome

It is possible to use alternative terms for "Inclusion", "Exclusion" and "Replication". If the documentation includes other terms than the standard Z-Wave terms, the documentation must include a list or a table that explains the relation between the OEM and Z-Wave terms.

Comments




6.2 Include device into existing network

Test Case Include device into existing network


D.2

Item Description The product documentation (manuals, help files, web page links, etc.) describes how to add the product into an existing Z-Wave network from a 3

rd

party vendor.

Purpose Cross vendor interoperability is one of the cornerstones of Z-Wave, it is therefore important that the consumer is properly informed about how to add this product to a network from a 3

rd party vendor.


Required Test Tool


Expected outcome

Z-Wave products documentation must include a section that explains how to add the device into a network from a 3

rd party vendor. For Slave devices this

includes a description how the Inclusion mode is activated (usually by pressing a button on the device). For Controllers it must be described how the Learn Mode is activated on the included Controller device.

Comments




6.3 Devices from multiple vendors in one network

Test Case Devices from multiple vendors in one network


D.3

Item Description The product documentation (manuals, help files, web page links, etc.) has a section which describes how products from different vendors and product categories can be part of the same network and that the different always powered nodes can act as repeaters regardless of vendor. Please note: This can be a generic statement and does not have to address the functions of the DUT.

Purpose Cross vendor interoperability is one of the cornerstones of Z-Wave, it is therefore important that the consumer becomes aware of the ability to include products from various vendors into one network and that different listening nodes can act as repeaters regardless of the vendor.


Required Test Tool


Expected outcome

The product documentation must include an interoperability section which describes that products from different vendors and product categories (lighting, HVAC, Home Entertainment etc.) can be a part of the same network. Additionally it must be described that all "listening" nodes act as message repeaters regardless of vendor. This part is always required even if the DUT itself is not a listening node.

The manufacturer is allowed to use custom wording as long as it complies with the rules defined above.

Comments The following wording is recommended: “This product can be included and operated in any Z-Wave network with other Z-Wave certified devices from any other manufacturers. All constantly powered nodes in the same network will act as repeaters regardless of the vendor in order to increase reliability of the network.”




6.4 Documentation for Configuration Command Class

Test Case Documentation for Configuration Command Class


D.4

Item Description If the Configuration Command Class is supported, documentation for showing the use of parameter numbers and values is required. (Mark as “n/a” if Configuration Commands are not supported)

Purpose The Configuration Command Class allows the OEM to freely define configuration values for the device. In order to utilize this command class the OEM must provide information about the parameters and possible values.


Required Test Tool


Expected outcome

If the DUT supports the Configuration Command Class the documentation must include a section explaining the use of the possible parameters and values. For each parameter the size, the default value and the possible values must be described.

Comments




6.5 Documentation for Associations

Test Case Documentation for Associations


D.5

Item Description If the Association Command Class is supported, documentation is provided about how association groups are used in the device. (Mark as “n/a” if Association Commands are not supported)

Purpose The Association Command Class allows for the OEM to define a number of association groups. In order to fully utilize these groups the OEM must describe how the groups are used in the device e.g. button mapping.


Required Test Tool


Expected outcome

If the DUT supports the Association Command Class, the documentation must include a section explaining how the supported association groups are used in the device. The number of supported groups and the number of possible nodes in one group must be described as well.

Comments




6.6 Documentation related to Basic Command Class

Test Case Documentation related to Basic Command Class


D.6

Item Description If the device is based on a Device Class where the Generic and the Specific Device Class do not fully specify which values are implemented in Basic Set Commands and/or do not fully specify the denotation of the values in Basic Set Commands, such information is provided in the device’s documentation. (Mark as “n/a” if Basic commands are fully specified in the generic and/or specific device class of the device)

Purpose The Basic Command Class is used as a last resort to communicate if the device type is unknown to the controller. If the mapping of the Basic Commands is not described in the device class specification it must be described in the product documentation.


Required Test Tool


Expected outcome

If the DUT supports the Basic Command Class and its Generic and Specific Device does not fully specify the mapping of the Basic Command Class, the documentation must include a section describing the mapping and the possible values of the Basic Command Class Set/Get commands.

Comments




6.7 Documentation for Verification Testing

Test Case Documentation for Verification Testing


D.7

Item Description If the testing of any item in certification requires “special” procedures, documentation is provided for this to the test lab. All documentation is provided in English language; or arrangements have been made with the test lab. (Mark “n/a” if both are not applicable)

Purpose When submitting for verification testing, it is the OEMs responsibility to remember to always include information about how to perform special cases of the verification tests such as triggering the use of ALL controlled Command Class, how to put the device into listening mode etc.


Required Test Tool

Procedure If the verification test lab feels that the documentation provided to them for special test cases was insufficient it can be indicated in this column.

Expected outcome

The verification test lab must be able to perform all tests without needing to contact the OEM for additional information.

Comments Please note that insufficient information about how to perform certain verification tests can lead to failing these items.




6.8 Documentation for Controllers

Test Case Documentation for Controllers


D.8

Item Description Include description of controlled commands and functions as well as instructions for controlling included devices. (Mark “n/a” if this device is not a controller)

Purpose The documentation for Controllers is used by the OEM to describe controlled Command Classes as well as instructions for controlling included devices.


Required Test Tool


Expected outcome

If the DUT is a Controller, the documentation must include a section explaining how the controlled Command Classes are used in order to control included devices.

Comments




7 HARDWARE

7.1 Minimum communication range tests

Test Case Minimum communication range tests


H.1 H.1.1

Item Description H.1: In order to assure proper communication range, the device must fulfill the following criteria without retransmission: Measured in line of sight; with load (e.g. Dimmer: lamp used)

H.1.1: 25m range: CER << 5% (Communication Error Rate)

Purpose In order to ensure an acceptable minimum communication range any device under test must pass Items H.4 and H.4.1.


The range test shall be performed in an in-door environment free of radio interference. The test is performed using a Z-Wave development module with a whip antenna as the test module. The Z-Wave module must be based on the same chip series as the DUT and it must be programmed with a Static Controller Serial API firmware from Z-Wave Developer Kit. To perform the range tests the Enhanced Reliability Test Tool (ERTT) part of the most current Z-Wave PC Controller tool is used.

Procedure To perform the test the Z-Wave Serial API module must be placed in a fixed position connected to a PC. The DUT must be included into the Z-Wave Serial API module’s network using the PC Controller.

After Inclusion the following tests must be performed at 25 meters line-of-sight distance from the Z-Wave module.

Send 1000 frames to the DUT, if the device does not meet the CER requirement try moving the DUT a bit keeping it within a half-sphere with a diameter of about 30 cm. The half-sphere is placed such that the device has a distance of at least 25 meters to the Z-Wave module at all times.

In addition to the placement variations the test shall also be performed at four different normal operation angles of the DUT. The device must pass on an average of the four angles. If there are special operation angles of the DUT the OEM must inform the verification lab of such.

Expected outcome




Comments It must be confirmed that differences in device operation mode and state is not affecting the communication range. To confirm this a set of operating modes and states must be selected and tests must be performed for each mode and state. The selected modes and states must be selected such that it can be assured that the communication range is not affected by any modes and/or states. It is not required to measure the directionality at each operating mode and state.

For binary switches this means tests must be made in both the on and off state. For dimming devices the tests must be performed at basic set levels 0, 20, 40, 60, 80, 99.




8 Z-WAVE NETWORK SUPPORT

8.1 Slave

Test Case DUT is based on the Slave Library


B.1

Item Description The product is based on the Slave Library

Purpose This field is used to identify the product as being based on the Slave Library.


Required Test Tool

Procedure This field must be verified by the OEM by reviewing the product design documentation and by checking the library type that was used for developing the product.

Expected outcome





8.1.1 Inclusion of DUT (Slave)

Test Case Inclusion of DUT (Slave) Certification Form Item

B.1.1 B.2.2

Item Description Inclusion of the product into a Z-Wave network.

Purpose This will check if a device can be included into an existing Z-Wave network with a standard Inclusion process. For NWI Inclusion see item 5.8.2.



Required Test Tool


Procedure 1. Start and reset the Z-Wave PC Controller

a) Controller > Reset Controller 2. Press “Add Node” on the Z-Wave PC Controller

a) Node > Add Node 3. Perform the Inclusion step on the DUT by triggering a Node Information

Frame (NIF) transmission. Refer to the provided product documentation how the NIF can be triggered.

4. Verify in the Z-Wave PC Controller and in the Zniffer output that the DUT is included in the PC Controller's Z-Wave network.




Expected outcome

After a successful Inclusion the DUT must be displayed in the node list of the Z-Wave PC Controller application and the Zniffer output must be substantially similar to:

DUT PC Controller

Node Info1


Assign Node ID

ACK

NOP

ACK

Find Nodes in Range

ACK

NOP Power

ACK

Command Complete

ACK

Get Nodes in Range

ACK

Node Range Info

ACK




Comments 1 If this is an “Explorer Autoinclusion Node Info” frame then the DUT started an

NW Inclusion. Please consult the product documentation to see how a classic Inclusion can be started instead. This item only passes if such a classic Inclusion can be triggered.

If only the Node Information Frame is shown in the Zniffer and no additional communication, make sure the “Add Node” button is activated in the Z-Wave PC Controller and try again.

Double check that the DUT is not included into any other Z-Wave network.

The Inclusion might also fail because the Learn mode was not activated in the DUT. Consult the product documentation on how to activate the Learn mode in the DUT. This usually matches the process of sending out a NIF.

The Transfer Node/Range Info commands are sent once for each node that is part of the Z-Wave network.




8.1.2 Exclusion of product (Slave)

Test Case Exclusion of product (Slave)


B.1.2 B.2.3

Item Description Exclusion of the product from the Z-Wave network.

Purpose This will check if a device can be excluded from a Z-Wave network.


The DUT is included into a network consisting of at least a Z-Wave PC Controller and the DUT.

Required Test Tool


Procedure 1. Start the Z-Wave PC controller and check that the DUT is included into the

network. 2. Press the “Exclude Node” button on the Z-Wave PC Controller

a) Node > Exclude Node 3. Perform the Exclusion step on the DUT by triggering a Node Information

Frame (NIF) transmission. Refer to the provided product documentation how the NIF can be triggered.

4. Verify in the Z-Wave PC Controller and in the Zniffer output that the DUT is excluded from the PC Controller's Z-Wave Network.

Expected outcome

After a successful Exclusion the DUT must be removed from the node list of the PC Controller application and the Zniffer output must be substantially similar to:

Comments If the Node information frame is shown in the Zniffer and no additional communication is shown, make sure the “Exclude Node” button is activated in the Z-Wave PC Controller and try again. If the NOP frames from the Controller are still answered with an ACK, make sure no other Z-Wave device accidently has the same Node and Home ID.

DUT PC Controller

Node Info


Assign Node ID

ACK

NOP

NOP

NOP




8.1.3 Send Node Information Frame based on user interaction

Test Case Send Node Information Frame based on user interaction


B.1.3 B.2.4 B.3.4

Item Description Send Node Info frame based on user interaction.

Purpose This test will examine if it is possible to send an unsolicited Node Information Frame (NIF) from the DUT, triggered by an user interaction.


Required Test Tool

Zniffer

Procedure 1. Consult the provided documentation for information about how to send the

Node Information Frame. a) For slaves this is equal to performing an Inclusion of the device b) For Controllers consult specific product documentation.

2. Verify the Node Information Frame was sent in the Zniffer.

Expected outcome

If the DUT sends the Node Information Frame correctly it must be shown in the Zniffer output as a broadcast frame.

Comments Slaves must be able to send unsolicited NIFs at all times.

8.1.4 Repeater Functionality

Test Case Repeater Functionality Certification Form Item

B.1.4 B.2.5

Item Description Function as a repeater in the Z-Wave network.

Purpose This test will check the possibility for the DUT to work as a repeater. It is only meant for always listening nodes. FLiRS and battery operated devices do not repeat Z-Wave messages.


Required Test Tool

Zniffer

Procedure Whether the message repeating works correctly is not tested explicitly because this is a protocol feature that is handled by the Z-Wave libraries. To pass this item only the following items are verified:

1. G.14 (Listening Flag) is marked as supported & verified 2. The Listening Flag is set to “True” 3. A Routing Library is used

Expected outcome

Comments Battery powered / FliRS devices must not be repeaters.




8.1.5 Support of Security Command Class

Test Case Support of Security Command Class


B.1.5 B.2.8

Item Description Z-Wave Application Security Layer The device supports the Security Command Class.

Purpose The purpose of this item is to verify that the DUT supports the Security Command Class.


Required Test Tool

Zniffer

Procedure 1. Trigger a NIF according to the provided product documentation. 2. Verify that the Security Command Class is listed as supported in the NIF.

Expected outcome

The Security Command Class must be part of the Command Classes list of the NIF if this item is checked.

Comments This item only verifies if the Security Command Class is displayed in the NIF. Whether the DUT correctly works as a secure Z-Wave device is tested in the following "Secure Inclusion" items and in the Command Class tests in Section A where all supported Command Classes must be tested with security encapsulation as well.

8.1.5.1 Secure Inclusion

Test Case Secure Inclusion Certification Form Item

B.1.5.1 B.2.8.1

Item Description Slave can be included by any controller supporting the Security Command Class as a secure device.

Purpose The purpose of this item is to verify that the DUT can be included into a secure Z-Wave network and that it meets all mandatory requirements for a secure Inclusion.



Required Test Tool

Z-Wave PC Controller (Security Version) Zniffer (Security Version)

Procedure Include the DUT according to the provided documentation and verify in the Zniffer trace that the secure Inclusion process followed the normal Inclusion.




Expected outcome

If the DUT supports the Secure Inclusion an additional secure Inclusion part follows the normal Inclusion. The secure part must be similar to (ACKs are not included):

DUT PC Controller

Security Scheme Get

Security Scheme Report

Security Nonce Get

Security Nonce Report Nonce Request

Timer

Network Key Set1

Security Nonce Get

Nonce Timer

Security Nonce Report

Network Key verify

Nonce Request Timer

Nonce Timer

Security Nonce Get


Timer

Security Cmds Supported Get Nonce Timer

Security Nonce Get


Security Cmds Supported Report

Nonce Timer

Nonce Request Timer

Inclusion Completed Inclusion Timer

Inclusion Timer

Inclusion Timer

Inclusion Timer

Inclusion Timer

Inclusion Timer

1 with initial Network Key (Scheme 0: 16 x 0x00)

Inclusion Timer: 10 sec (mandatory) Nonce Timer: min. 3 sec, rec. 10 sec, max. 20 sec Nonce Request Timer: optional

Encrypted Command




Comments For additional test description refer to section 3.1.

8.2 Routing Slave

Test Case DUT is based on the Routing Slave Library


B.2

Item Description The product is based on the Routing Slave Library.

Purpose This field is used to identify the product as being based on the Routing Slave Library.


Required Test Tool


Expected outcome


8.2.1 Enhanced Slave

Test Case Enhanced Slave Certification Form Item

B.2.1

Item Description Device is an Enhanced Slave.

Purpose This field is used to identify the product as being an Enhanced Slave.


Required Test Tool


Expected outcome





8.2.2 Inclusion of DUT (Routing Slave)

For Test Case description refer to item 8.1.1 Inclusion of DUT (Slave).

8.2.3 Exclusion of product

For Test Case description please refer to item 8.1.2 Exclusion of product (Slave).


For Test Case description please refer to item 8.1.3 Send Node Information Frame based on user interaction.

8.2.5 Repeater Functionality

For Test Case description please refer to item 8.1.4 Repeater Functionality.

8.2.6 Request topology update from SUC / SIS

Test Case Request topology update from SUC / SIS


B.2.6

Item Description Request topology updates from SUC / SIS.

Purpose Manual topology updates from the SUC/SIS makes sure the node have the most updated network layout after any network changes, thereby improving performance and latency in the network. This test will verify that the DUT can request a topology update from the network SUC / SIS.


The Z-Wave PC Controller must have the SUC role assigned. The DUT is included into the Z-Wave PC controller’s network.

Required Test Tool


Procedure Since the triggering of a topology update request is application dependent, no universal test case is specified. This item must be verified by referring to the device documentation for information about how to trigger this event and by verifying the event in the Zniffer trace.




Expected outcome

A Network Update Request from a slave to a SIS is shown in the following trace.

Comments If this item is checked then the documentation for the test houses must contain a section that describes how such a topology update can be triggered. If there is no such description this item will fail in the document review part of the verification tests.

8.2.7 Device will call ZW_RequestNetworkUpdate daily

Test Case Device will call ZW_Request- NetworkUpdate daily


B.2.7

Item Description Device will call ZW_RequestNetworkUpdate at least once per day (if SUC / SIS is present).

Purpose Regular automatic topology updates from the SUC / SIS makes sure the node always have the most updated network layout, thereby improving performance and latency in the network.

Pre-requisites/ The Z-Wave PC Controller must have the SUC role

Required Test Z-Wave PC Controller

DUT SIS

Static Route Request

ACK

ACK

Assign (SUC) Return Route

ACK


ACK


ACK

Transfer End

ACK





Test setup assigned. The DUT is included into the Z-Wave PC controller’s network.

Tool Zniffer

Procedure The OEM must verify this item by monitoring the device in normal operation for at least a day.

Expected outcome

A Network Update Request from a Slave to a SIS is shown in the following trace.

Comments Note: This item is not confirmed in regular verification testing at this time. Please note however that random spot checks will be performed.


For Test Case description please refer to item 8.1.5 Support of Security Command Class.

8.2.8.1 Secure Inclusion

For Test Case description please refer to item 8.1.5.1 Secure Inclusion.

DUT SIS

Static Route Request

ACK

ACK


ACK


ACK


ACK

Transfer End

ACK





8.3 Z-Wave Controller Library (Controller, Static Controller, Installer, Bridge or Portable)

Test Case DUT is based on Z-Wave Controller Library


B.3

Item Description The product is based on a Z-Wave Controller Library.

Purpose This field is used to identify the product as being based on a Controller Library.


Required Test Tool


Expected outcome





8.3.1 Unique HomeID

Test Case Unique HomeID Certification Form Item

B.3.1

Item Description The HomeID is in the range allocated to the OEM or random home ID generation used.

Precautions are taken to ensure that HomeID from the allocated range is only used once during production.

Purpose The unique or random HomeID’s ensures security in the Z-Wave network.


Required Test Tool

Procedure The OEM must verify this item by reviewing operation and production procedures.

Expected outcome


All current SDK versions are generating a random home ID if the Controller is reset. In this case the requirement in this item is always met.




8.3.2 Inclusion of Controller

Test Case Inclusion of Controller Certification Form Item

B.3.2

Item Description Controller can be included into an existing Z-Wave network.

Purpose This test will examine the possibility for the device under test to be included into an existing Z-Wave network with a standard Inclusion process. For NWI Inclusion see item 8.8.2.


The DUT is excluded from any existing network, preferably by doing a factory reset.

Required Test Tool


Procedure 1. Start and reset Z-Wave PC Controller

a) Controller > Reset Controller 2. Press "Add Node" on the Z-Wave PC Controller

b) Node > Add Node 3. Enter Inclusion/Learn mode on the DUT 4. Verify that the controller is included into the existing network




Expected outcome

If the DUT is correctly included the Zniffer output must be substantially similar

to:

DUT PC Controller

Node Info1


Assign Node ID

ACK

NOP

ACK

Find Nodes in Range

ACK

NOP Power

ACK

Command Complete

ACK

Get Nodes in Range

ACK

Node Range Info

ACK

Transfer Node Info

ACK

Command Complete

ACK

Transfer Range Info

ACK

Command Complete

ACK

Transfer End

ACK




Comments 1 If this is an “Explorer Autoinclusion Node Info” frame then the DUT started an

NW Inclusion. Please consult the product documentation to see how a classic Inclusion can be started instead. This item only passes if such a classic Inclusion can be triggered.

If only the Node Information Frame is shown in the Zniffer and no additional communication, make sure the “Add Node” button is activated in the Z-Wave PC Controller and try again. Additionally double check that the DUT is not included into any other Z-Wave network.




8.3.3 Exclusion of Controller

Test Case Exclusion of Controller Certification Form Item

B.3.3

Item Description Controller can be excluded from the Z-Wave network.

Purpose This test will examine the possibility for the device under test to be excluded from a Z-Wave network.


The DUT is included into the PC Controllers Z-Wave network.

Required Test Tool


Procedure 1. Press "Remove Node" on the Z-Wave PC Controller.

a) Node > Remove Node 2. Enter the Exclusion/Learn mode on the DUT. 3. Verify that the controller is excluded from the Z-Wave network.

Expected outcome

If the DUT is correctly excluded the Zniffer output must be substantially similar to:

Comments If the Node information frame is shown in the Zniffer and no additional communication is shown, make sure the “Exclude Node” button is activated in the Z-Wave PC Controller and try again.

If the NOP frames from the Controller are still answered with an ACK, make sure no other Z-Wave device accidently has the same Node and Home ID.

DUT PC Controller

Node Info


Assign Node ID

ACK

NOP

NOP

NOP

Transfer End (to Node ID 0x00)

ACK (from Node ID 0x00)





For Test Case description please refer to item B.1.3 Send Node Information Frame based on user interaction.

8.3.5 Request Node Information Frame

Test Case Request Node Information Frame


B.3.5

Item Description Request Node Info Frame

Purpose This test will examine if it is possible for the DUT to request a Node Information Frame from another device.


The DUT and LED Dimmer must be part of the same network.

Required Test Tool

Zniffer LED Dimmer

Procedure 1. Consult the submitted documentation for information about how to request

a node information frames. 2. Verify that the Node Information Frame was requested in the Zniffer.

Expected outcome

If the DUT is correctly sending the Node Information Frame the Zniffer output must be substantially similar to:

Comments

DUT LED Dimmer

Request Node Info

Node Info




8.3.6 Controller will call ZW_RequestNetworkUpdate daily

Test Case Controller will call ZW_Request- NetworkUpdate daily


B.3.6.1

Item Description Controller will call ZW_RequestNetworkUpdate at least once per day (if SUC / SIS is present).

Purpose Regular automatic topology updates from the SUC / SIS makes sure the Controller always have the most updated network layout, thereby improving performance and latency in the network.


The Z-Wave PC Controller must have the SUC role assigned. The DUT is included into the Z-Wave PC controller’s network.

Required Test Tool


Procedure The OEM must verify this item by monitoring the device in normal operation for at least a day.




Expected outcome

A Network Update Request from a Controller to a SIS is shown in the following trace. In this example the update contains information about one new node.

Comments Note: This item is not confirmed in regular verification testing at this time. Please note however that random spot checks will be performed.

DUT SIS

Automatic Controller Update Start

ACK

ACK

Command Complete

ACK

New Range Registered

ACK

Command Complete

New Node Registered

ACK

Transfer End

ACK




8.3.7 Controller will call ZW_RequestNetworkUpdate before configuring associations

Test Case Controller will call ZW_Request- NetworkUpdate before configuring associations (if SUC / SIS is present)


B.3.6.2

Item Description Controller will call ZW_RequestNetworkUpdate before configuring associations (if SUC / SIS is present).

Purpose Getting topology updates from the SUC / SIS before configuring associations makes sure the configured node has the most updated network layout, thereby receiving the optimal route to the associated node.


The Z-Wave PC Controller must have the SUC role assigned. The LED Dimmer and the DUT must be part of the Z-Wave PC Controllers network.

Required Test Tool

Z-Wave PC Controller Zniffer LED Dimmer (from SDK version 4.54 or higher for 300 series chips and version 6.02 or higher for 400 series chips)

Procedure 1. Refer to the DUTs documentation for information about how to configure

associations in other devices. 2. Setup an association in the LED Dimmer using the DUT. 3. Verify in the Zniffer trace that the ZW_RequestNetworkUpdate was called.




Expected outcome

A Network Update Request from a Controller to a SIS is shown in the following trace. In this example the update contains information about one new node.

Comments

DUT SIS

Automatic Controller Update Start

ACK

ACK

Command Complete

ACK


ACK

Command Complete

New Node Registered

ACK

Transfer End

ACK




8.3.8 Controller Replication Command are acknowledged with Command Complete

Test Case Controller Replication Command are acknowledged with Command Complete command


B.3.7

Item Description Controller Replication Commands must always as minimum be acknowledge on application level using the API call “ZW_ReplicationReceiveComplete”.

Purpose This item verifies that even if the DUT does not implement the Controller Replication Command Class it still answers Commands of this Command Class with a Command Complete command.


Required Test Tool

CTT (the Z-Wave PC Controller is not able to send Controller Replication commands if the DUT does not support this Command Class) Zniffer

Procedure 1. Create a CTT Project for the DUT, include the DUT into the CTTs network

and make sure the Controller Replication Command Class test script is part of the Project.

2. Run the Controller Replication Command Class test script against the DUT.

3. Verify in the Zniffer output that all outgoing Commands from the CTT are answered by the DUT with a Command Complete command.




Expected outcome

The monitored Zniffer traffic must be similar to:

Comments Any other tool or device that is able to send Controller Replication Commands to the DUT can also be used for this test.

DUT CTT

ACK

Command Complete

ACK

CtrlReplicationTransferGroupName

ACK

CtrlReplicationTransferScene

CtrlReplicationTransferGroup

ACK

CtrlReplicationTransferSceneName

ACK

Command Complete

ACK

Command Complete

ACK

Command Complete

ACK




8.3.9 Secondary controller

Test Case Secondary controller Certification Form Item

B.3.8

Item Description Controller can only act as secondary controller and can be included into a network started by any controller from any manufacturer.

Purpose The purpose of this item is to verify, that the controller is only able to work as a Secondary Controller and not as a Primary Controller. Therefore it must not be possible to create a Z-Wave network with the DUT by including other Z-Wave devices.


The Z-Wave PC Controller and the DUT are not included in any network.

Required Test Tool


Procedure 1. Review product documentation and device functions to verify that there is

no way to create a new network with the DUT. 2. Include the DUT into the Z-Wave PC Controllers network. 3. Verify that the DUT is unable to accept the primary role during a controller

shift. a) This test should be realized with the Controller shift function in Z-

Wave PC Controller.

Expected outcome

The product is not able to include other Z-Wave devices and it does not accept the primary role during a controller shift. After the attempted controller shift it must still be impossible for the DUT to include or exclude other Z-Wave devices.

Comments




8.3.9.1 Secondary controller documentation

Test Case Secondary controller documentation


B.3.8.1

Item Description Product documentation clearly describes that the controller can only act as secondary controller; and that another Z-Wave controller is required as primary controller to setup and maintain the network.

Product literature and websites include same clarification. (OEM either need to provide samples / drafts or confirm this will be assured with a comment on the self-certification page)

Purpose If a device is a secondary controller only device, the OEM must state this clearly in the device documentation and the limitation which follows from this.


Required Test Tool

Procedure This item must be verified by examining the product documentation accompanying the device for testing and/or any other documentation provided by the OEM such as product website, help files, links etc.

Expected outcome

The documentation must state that the DUT is envisioned to be a secondary only controller and must state all the limitation that follows from this e.g. another controller is needed to setup and maintain network.

Comments For additional test description refer to section 11.1, Z-Wave PC Controller includes the DUT.





Test Case Support of Security Command Class


B.3.8.2 B.3.9.13

Item Description Z-Wave Application Security Layer The controller implements the Security Command Class

Purpose The purpose of this item is to verify that the Controller implements the Security Command Class.


Required Test Tool

Zniffer

Procedure 1. Trigger a NIF according to the provided product documentation. 2. Verify that the Security Command Class is listed as supported in the NIF.

Expected outcome

The Security Command Class must be part of the Command Classes list of the NIF if this item is checked.

Comments This item only verifies if the Security Command Class is displayed in the NIF. Whether the DUT correctly works as a secure Z-Wave device is tested in the following “Secure Inclusion” items and in the Command Class tests in Section A where all supported Command Classes must be tested with Security Encapsulation as well.

8.3.10.1 Secure Inclusion of a Controller

Test Case Secure Inclusion of a Controller


B.3.8.2.1 B.3.9.13.2

Item Description The controller can be included by any controller of any type of manufacturer supporting the Security Command Class as a secure device

Purpose The purpose of this item is to verify that the Controller can be included into a secure Z-Wave network and that it meets all mandatory requirements for a secure Inclusion.



Required Test Tool


Procedure Include the DUT according to the provided documentation and verify in the Zniffer trace that the secure Inclusion process followed the normal Inclusion.




Expected outcome

If the DUT supports the Secure Inclusion an additional secure Inclusion part follows the normal Inclusion. The secure part must be similar to (ACKS are not included):

Comments For additional test description refer to section 11.2, Z-Wave PC Controller is included by the DUT.



Encrypted Command

DUT PC Controller

Security Scheme Get


Security Nonce Get


Timer

Network Key Set1

Security Nonce Get

Nonce Timer


Network Key verify

Security Nonce Get


Nonce Request Timer

Nonce Timer

Security Scheme Inherit

Security Nonce Get



Nonce Timer

Nonce Request Timer

Inclusion Completed Inclusion Timer

Inclusion Timer

Inclusion Timer

Inclusion Timer

Inclusion Timer

Inclusion Timer

Inclusion Timer

Inclusion Timer

Nonce Request Timer

Nonce Timer




8.3.10.1.1 Controller inherits Security Schemes from including controller

Test Case Controller inherits Security Schemes from including controller


B.3.8.2.1.1 B.3.9.13.2.1

Item Description The controller will inherit the Security Scheme from the including controller.

Purpose The purpose of this item is to test if the Controller will inherit the Security Scheme from the including controller.


The DUT and the Z-Wave PC Controller are excluded from any other Z-Wave network, preferably by doing a factory reset.

Required Test Tool


Procedure When including the DUT as a secure device the Security Schemes of the including Controller will be transferred to the DUT at the end of the secure Inclusion process.

The DUT must inherit those Security Schemes and is not allowed to return any other Schemes in a Security Scheme Get command.

Expected outcome

If the DUT is included into a secured Z-Wave network the Zniffer output must be substantially similar to:

Comments In the Security Command Class Version 1 there is only one Scheme available (Scheme 0). Therefore the Security Scheme Inherit and the Security Scheme Report will always contain value 0.

DUT PC Controller

… (Network Key exchange)


Security Nonce Get



Nonce Timer

Nonce Request Timer

Inclusion Timer

Inclusion Timer


Encrypted Command




8.3.11 Controller can act as primary and/or Inclusion controller

Test Case Controller can act as primary and/or Inclusion controller


B.3.9

Item Description Controller can act as primary and/or Inclusion controller.

Purpose The Primary Controller functionality is tested in item B.3.9.1. This test will verify that the Controller can be an Inclusion Controller, which is the Controller that will request a Node ID from a SIS before including other devices in the network.


The Z-Wave PC Controller must be reset. The LED Dimmer must be excluded from any network.

Required Test Tool

Z-Wave PC Controller Zniffer LED Dimmer

Procedure 1. Assign SIS role to Z-Wave PC Controller

a) In the Controller Tab select the “SIS” radio button and click on the Assign button

2. Start Inclusion mode on the Z-Wave PC Controller by clicking on the “Add Node” button

3. Start Learn mode on the DUT 4. Verify the DUT was included into the network 5. Set the DUT into Inclusion mode 6. Start the Inclusion on the LED Dimmer (single or triple button press

depending on the LED Dimmer FW version) 7. Verify that the LED Dimmer is included into the network and the DUT

requested it's Node ID from the SIS




Expected outcome

If the LED Dimmer is included into the Z-Wave network the Zniffer output must be substantially similar to:

DUT PC Controller LED Dimmer

Reserve Node ID

ACK

Reserved ID

ACK


Node Info

Assign Node ID

ACK

NOP

ACK

New Node Registered

ACK

Find Nodes in Range

ACK

NOP Power

ACK

NOP Power

ACK

Command Complete

ACK

Get Nodes Range in Range ACK

Node Range Info

ACK


ACK




Comments

8.3.11.1 Inclusion of products from other manufacturer

Test Case Inclusion of products from other manufacturer


B.3.9.1

Item Description Ability to include compliant controller and slave nodes of any type from any manufacturer

Purpose This will examine if the device is able to include controller and slave devices from other manufacturers.


The DUT, the Z-Wave PC Controller and the LED Dimmer are excluded from any prior networks, preferably by doing a factory reset.

Required Test Tool


Procedure 1. Activate the Inclusion mode on the DUT according to the provided

documentation. 2. Start learn mode on the PC Controller

a) Controller > Start Learn Mode 3. Verify that the PC Controller is included into the Z-Wave network 4. Activate the Inclusion mode on the DUT according to the provided

documentation 5. Press the button on the LED Dimmer module to transmit the node

information frame 6. Verify that the LED Dimmer is included into the network




Expected outcome

If the LED Dimmer is included into the Z-Wave network the Zniffer output must be substantially similar to: (The Find Nodes In Range and all following commands depend if and how many other nodes are in the network.)

DUT LED Dimmer


Node Info

Assing ID

ACK

NOP

ACK

Find Nodes in Range

ACK

NOP Power

ACK

Command Complete

ACK

Get Nodes in Range

ACK

Node Range Info

ACK




If the PC Controller is included into the Z-Wave network the Zniffer output

must be substantially similar to:

DUT PC Controller

Node Infor


Assign Node ID

ACK

NOP

Find Nodes in Range

ACK

NOP Power

ACK

Command Complete

ACK

Get Nodes in Range

ACK

Node Range Info

ACK

Transfer Node Info

ACK

Command Complete

Transfer Range Info

ACK

Transfer End

ACK

ACK

ACK

Command Complete

ACK




Comments The Transfer Node/Range Info commands are sent for each node that is part of the Z-Wave network.

8.3.11.2 Exclusion of products from other manufacturer

Test Case Exclusion of products from other manufacturer


B.3.9.2

Item Description Ability to exclude compliant controller and slave nodes of any type from any manufacturer

Purpose This will examine if the device is able to exclude controller and slave devices from another manufacturers.


The DUT, the Z-Wave PC Controller and the LED Dimmer are all part of a Z-Wave network initiated by the DUT. The DUT must be primary controller in the network.

Required Test Tool


Procedure 1. Activate the Exclusion mode on the DUT according to the provided

documentation 2. Start learn mode on the PC Controller

a) Controller > Start Learn Mode 3. Verify that the PC Controller is excluded from the Z-Wave network. 4. Activate the Exclusion mode on the DUT according to the provided

documentation 5. Press the button on the LED Dimmer module to transmit the node

information frame 6. Verify that the LED Dimmer is excluded from the network




Expected outcome

If the PC Controller is excluded from the Z-Wave network the Zniffer output must be substantially similar to:

If the LED Dimmer is excluded from the Z-Wave network the Zniffer output must be substantially similar to:

Comments

DUT PC Controller

Node Info


Transfer End (to Node ID 0x00)

ACK (from Node ID 0x00)


Assign Node ID

ACK

NOP

NOP

NOP

DUT LED Dimmer

Node Info


Assign Node ID

ACK

NOP

NOP

NOP




8.3.11.3 Receive primary controller role via controller shift

Test Case Receive primary controller role via controller shift


B.3.9.3

Item Description Receive primary controller role via controller shift.

Purpose This will examine if the device is able to receive the primary controller role from another controller by doing a controller shift.


The DUT and the Z-Wave PC Controller are part of the same Z-Wave network where the Z-Wave PC Controller is the primary controller.

Required Test Tool


Procedure 1. Initiate a controller shift from the PC Controller

a) Controller > Controller Shift 2. Activate the Learn mode on the DUT according to the provided

documentation. 3. Verify that the primary controller role was transferred to the DUT. 4. The DUT must now allow to Include and Exclude other nodes. 5. If the DUT has a GUI or any other function to display the current network

role then this role must be updated to “Primary Controller”




Expected outcome

If the primary controller role was transferred to the DUT the Zniffer output must be substantially similar to:

Comments Transfer Node/Range Information commands will be repeated for each node in the network. This is required to transfer all network information to the new primary controller.

DUT PC Controller

Node Info


Transfer Node Info

ACK

Command Complete

ACK

Transfer Range Info

Transfer End

ACK

…

…

SUC Node ID

ACK

Transfer New Primary Complete

ACK

ACK

Command Complete

ACK




8.3.11.4 Relinquish primary controller role via controller shift

Test Case Relinquish primary controller role via controller shift


B.3.9.4

Item Description Relinquish primary controller role via a controller shift and become secondary controller (in case the controller is in a SIS role or an Inclusion Controller role this item is exempted).

Purpose This will examine if the device is able to relinquish the primary controller role and become a secondary controller by doing a controller shift.


The DUT and the Z-Wave PC Controller are part of the same Z-Wave network where the DUT is the primary controller.

Required Test Tool


Procedure 1. Activate the controller shift mode on the DUT according to the provided

documentation. 2. Activate the learn mode on the Z-Wave PC Controller. 3. Verify that the primary controller role was transferred to the Z-Wave PC

Controller. 4. Any functions to Include or Exclude other nodes with the DUT must now

be disabled. 5. If the DUT has a GUI or any other function to display the current network

role then this role must be updated to “Secondary Controller”




Expected outcome

If the primary controller role was transferred to the PC Controller the Zniffer output must be substantially similar to:

Comments The Transfer Node/Range Information commands will be repeated for each node in the network. This is required to transfer all network information to the new primary controller.

DUT PC Controller

Node Info


Transfer Node Info

ACK

Command Complete

Transfer Range Info

ACK

Transfer End

ACK

ACK

Command Complete

ACK

…

…

SUC Node ID

ACK

Transfer New Primary Complete

ACK




8.3.11.5 Support reception of protocol replication data

Test Case Support reception of protocol replication data


B.3.9.5

Item Description Support reception of protocol replication data from another controller.

Purpose This will examine if the device is able to receive protocol replication data from another controller.


The two LED Dimmers are part of the PC Controllers Z-Wave network. The DUT is excluded from any network, preferably by doing a factory reset.

Required Test Tool

Z-Wave PC Controller Zniffer 2x LED Dimmer

Procedure 1. Activate the Z-Wave PC Controllers Inclusion mode

a) Node > Add Node 2. Activate the learn mode on the DUT according to the provided

documentation. 3. Verify that the protocol data has been replicated to the DUT after the

Inclusion process. 4. If the DUT has any GUI where the nodes of the network are displayed

then the received updated nodes must be displayed in DUT.




Expected outcome

If protocol data was replicated to the DUT the Zniffer output must be substantially similar to:

Comments The Transfer Node/Range Information commands will be repeated for each node in the network. This is required to transfer all network information to the included controller.

DUT PC Controller

Node Info


Transfer Node Info

ACK

Command Complete

ACK

Transfer Range Info

Transfer End

ACK

…

…

ACK

Command Complete

ACK

Assign Node ID

ACK

NOP

ACK




8.3.11.6 Ability to replicate protocol data

Test Case Ability to replicate protocol data


B.3.9.6

Item Description Ability to replicate protocol data to another controller.

Purpose This will examine if the device is able to replicate protocol data to another controller.


The two LED Dimmers are part of the DUTs Z-Wave network. The Z-Wave PC Controller is excluded from any network, preferably by doing a factory reset.

Required Test Tool

Z-Wave PC Controller Zniffer 2x LED Dimmer


documentation. 2. Activate the Z-Wave PC Controller´s learn mode

a) Controller > Start Learn Mode 3. Verify that protocol data was replicated from the DUT to the Z-Wave PC

Controller




Expected outcome

If protocol data was replicated to the PC Controller the Zniffer output must be substantially similar to:

Comments The Transfer Node/Range Information commands will be repeated for each node in the network. This is required to transfer all network information to the included controller.

DUT PC Controller

Node Info


ACK

Transfer Node Info

ACK

Command Complete

ACK

…

Transfer Range Info

ACK

Command Complete

ACK

Transfer End




8.3.11.7 Ability to replicate group/scene data

Test Case Ability to replicate group/scene data


B.3.9.7 B.3.7

Item Description Ability to replicate group/scene data to another controller.

Purpose Group and Scene data can be replicated between Z-Wave Controllers if both Controllers implement the Controller Replication Command Class. The Command Class MUST only be used in conjunction with a Controller Shift or when including a new Controller to the network.


Required Test Tool

Procedure Transmitting or receiving group and scene data with the Controller Replication Command Class can only be tested during a Controller Shift or an Inclusion process. Currently the Z-Wave PC Controller does not provide this function so another controller that implements this Command Class must be used to test this function.

Expected outcome

If the DUT implements support and control of the Controller Replication Command Class it must be possible to receive and transmit group and scene data to/from other controllers.

Comments Devices supporting this Command Class SHOULD accept all the Commands. If some Commands are not used in the particular implementation, then they SHOULD be ignored.

It is not possible to test this function with the current Z-Wave PC Controller or CTT because the Commands cannot be triggered during a Controller Shift. The CTT script for this Command Class can be used to test the correct return of Command Complete messages from the receiving controller (see item B.3.7).

The test houses verify this feature with another certified Z-Wave device that implements the Controller Replication Command class.




8.3.11.8 Delete a malfunctioning node

Test Case Delete a malfunctioning node


B.3.9.8

Item Description Delete a malfunctioning node.

Purpose A controller can include the functionality to delete a malfunctioning node.


The DUT is the primary controller of a Z-Wave network.

Required Test Tool

Zniffer LED Dimmer

Procedure 1. Include LED Dimmer into the existing Network. 2. Unplug the LED Dimmer. 3. Send any Command from the DUT to the LED Dimmer. 4. The LED Dimmer should be in the DUTs "Failed" list of the DUT now. 5. Refer to the DUT documentation for information about how to delete a

malfunctioning node. 6. Activate this function and verify that the LED Dimmer is removed from the

DUTs Z-Wave network.

Expected outcome

The node must be deleted such that the controller no longer is able to send frames to the node, and no traffic is routed through the node.

Comments




8.3.11.9 Support replacement of a malfunctioning node

Test Case Support replacement of a malfunctioning node


B.3.9.9

Item Description Support replacement of a malfunctioning node.

Purpose A controller can include the functionality to replace a malfunctioning node.


The DUT is the primary controller of a Z-Wave network. Both LED Dimmers should be excluded from any network.

Required Test Tool

Zniffer 2x LED Dimmer

Procedure 1. Include LED Dimmer 1 into the existing Network. 2. Unplug the LED Dimmer 1. 3. Send any Command from the DUT to the LED Dimmer 1. 4. LED Dimmer 1 should be in the DUTs "Failed" list of the DUT now. 5. Refer to the DUT documentation for information about how to replace a

malfunctioning node. 6. Activate this function and trigger a Node Info Frame from LED Dimmer 2. 7. LED Dimmer 2 should be included and it replaces LED Dimmer 1 with the

same Node and Home ID.

Expected outcome

LED Dimmer 1 must be replaced with LED Dimmer 2 so that all frames sent to the Node Id are sent to the new node.

Comments




8.3.11.10 Controller initiates rediscovery of nodes

Test Case Controller initiates rediscovery of nodes


B.3.9.10

Item Description Controller initiates rediscovery of nodes from a SUC / SIS.

Purpose This test will verify if the controller initiates a rediscovery of nodes lost in the network.


The Z-Wave PC Controller assigned the SUC or SIS role. The DUT is included into the Z-Wave PC Controller´s network.

Required Test Tool


Procedure Please refer to the DUT´s documentation for information about how the network rediscovery is triggered.

Expected outcome

The network rediscovery of the nodes must be verified in the Zniffer output.

Comments

8.3.11.11 Controller initiates rediscovery from a SUC / SIS on problems

Test Case Controller initiates rediscovery from a SUC / SIS when noticing problems in the network


B.3.9.11

Item Description Controller initiates rediscovery from a SUC / SIS when noticing problems in the network.

Purpose A controller can include the functionality to initiate a rediscovery when noticing problems in the network.


The Z-Wave PC Controller assigned the SUC or SIS role. The DUT and LED Dimmer are included into the Z-Wave PC Controller network.

Required Test Tool

Z-Wave PC Conttroller Zniffer LED Dimmer

Procedure 1. Unplug the LED Dimmer. 2. Repeatedly try to send frames to the LED Dimmer until a rediscovery is triggered.

Expected outcome

The network rediscovery must be verified in the Zniffer output.

Comments




8.3.11.12 Assign SIS Capability to included Controller

Test Case Assign SIS Capability to included Controller


B.3.9.12

Item Description Assign SIS capability Controller will always attempt to assign the SIS role to another controller that is being included (in case the controller is in a SIS role or an Inclusion controller role this item is exempted).

Purpose Having a SIS in the network improves the network robustness significantly. Therefore if the DUT itself is not a SUC / SIS it must try to assign those roles to another included Controller.



Required Test Tool



documentation. 2. Activate the learn mode on the Z-Wave PC Controller.

a) Controller > Start Learn Mode 3. Verify that the Z-Wave PC Controller is included into the Z-Wave network 4. Verify that the DUT tried to assign the SUC or SIS role to the PC

Controller




Expected outcome

If the DUT tried to assign the SUC / SIS role the Zniffer output must be substantially similar to:

1 State: enable, Server Running: true

Comments The outcome of the above sequence will be the assignment of the SIS or SUC role to the controller if accepted.

DUT PC Controller

Node Info


ACK

…

Set SUC1

ACK

Set SUC ACK

ACK

Transfer End

Assign Node ID

ACK




8.3.11.13 Support of Security Command Class

For Test Case description refer to item 8.3.10 Support of Security Command Class.

8.3.11.13.1 Secure Inclusion of any Device

Test Case Secure Inclusion of any Device


B.3.9.13.1

Item Description The DUT can include compliant controller and slave nodes of any type from any manufacturer supporting the Security Command Class as secure devices.

Purpose The purpose of this test is to verify that the DUT is able to include compliant controller and slaves nodes of any type from any manufacturer supporting the security Command Class as secure device.


The DUT, the Z-Wave PC Controller and the LED Dimmer are excluded from any other Z-Wave network, preferably by doing a factory reset.

Required Test Tool

Z-Wave PC Controller (Security Version) Zniffer (Security Version) LED Dimmer (Security Version)

Procedure 1. Include the Security Z-Wave PC Controller into the DUT´s Z-Wave network. 2. Include the Security LED Dimmer into the DUT's Z-Wave network.




Expected outcome

After the normal Inclusion of the PC Controller an additional secure Inclusion part should follow that must be similar to (ACKs are not included):

Continued on next page…

Nonce Timer

Nonce Request Timer

DUT PC Controller

Security Scheme Get


Security Nonce Get


Nonce Request Timer

Network Key Set1

Security Nonce Get

Nonce Timer


Network Key verify

Security Nonce Get


Nonce Request Timer

Nonce Timer


Security Nonce Get



Nonce Request Timer

Inclusion Completed

Inclusion Timer

Inclusion Timer

Inclusion Timer

Inclusion Timer

Inclusion Timer

Inclusion Timer

Inclusion Timer

Inclusion Timer

Nonce Timer



Encrypted Command




Expected Outcome

After the normal Inclusion of the LED Dimmer an additional secure Inclusion part should follow that must be similar to (ACKs are not included):

Comments For additional test description refer to section 11.2, Z-Wave PC Controller is included by the DUT.

DUT PC Controller

Security Scheme Get


Security Nonce Get


Nonce Request Timer

Network Key Set1

Security Nonce Get

Nonce Timer


Network Key verify

Nonce Request Timer

Nonce Timer

Security Nonce Get


Nonce Request Timer

Security Cmds Supported Get

Nonce Timer

Security Nonce Get


Security Cmds Supported Report

Nonce Timer

Nonce Request Timer

Inclusion Completed

Inclusion Timer

Inclusion Timer

Inclusion Timer

Inclusion Timer

Inclusion Timer

Inclusion Timer



Encrypted Command




8.3.11.13.2 Secure Inclusion of a Controller

For Test Case description refer to item 8.3.10.1 Secure Inclusion of a Controller.

8.3.11.13.3 Controller inherits Security Schemes from including controller

For Test Case description refer to item 8.3.10.1.1 Controller inherits Security Scheme from including controller.

8.3.11.14 Controller is Static or Bridge Controller

Test Case Controller is Static or Bridge Controller


B.3.9.14

Item Description Controller is Static or Bridge Controller.

Purpose


Required Test Tool

Procedure This must be verified by reviewing the nature of the device.

Expected outcome

A static or bridge controller must be static in its nature e.g. the device is not moved around the house.

Comments Examples of static or bridge controllers includes USB dongles connected to a stationary computer, router, gateways, AV equipment etc.




8.3.11.14.1 Controller is always on and will accept to become a SUC / SIS

Test Case Controller is always on and will accept to become a SUC / SIS


B.3.9.14.1 B.3.9.14.1.1 B.3.9.14.1.2

Item Description B.3.9.14.1: Controller is not turned off by the consumer (e.g. PCs would typically not fall into this category).

B.3.9.14.1.1: Controller will accept to become SUC upon request (if supported by the protocol library. Mark n/a if not supported)

B.3.9.14.1.2: Controller will accept to become SIS upon request (if supported by the protocol library. Mark n/a if not supported)

Purpose If a controller is static in its nature and is not turned off regularly by the consumer it must accept to become a SUC / SIS in the network. The SUC / SIS ability should be supported by the protocol library.



Required Test Tool


Procedure This must be verified by reviewing the nature of the controller device. If the device is an “always on” device, it must accept the SUC / SIS role. This must be verified by creating a new network and monitor the traffic in the Zniffer or by assigning the SUC / SIS role to the DUT with the help of the Z-Wave PC Controller.




Expected outcome

The device must accept the SUC role when asked to adopt it. If SUC role has been accepted the Zniffer output must be substantially similar to:

1 State: enable, Server Running: false - (Bytes: 01 00)

2 Result: accepted, Server Running: false - (Bytes: 80 00)

The device must accept the SIS role when asked to adopt it. If SIS role has been accepted the Zniffer output must be substantially similar

to:

³ State: enable, Server Running: true - (Bytes: 01 01)

4 Result: accepted, Server Running: true - (Bytes: 80 01)

Comments

DUT PC Controller

Set SUC1

…

ACK

Set SUC ACK2

ACK

DUT PC Controller

Set SUC³

…

ACK

Set SUC ACK4

ACK




8.3.11.14.2 Controller is portable and will reject to become SIS / SUC

Test Case Controller is portable and/or can be turned off by the consumer and will reject to become SIS / SUC


B.3.9.15 B.3.9.15.1

Item Description B.3.9.15: Controller is portable controller and/or may be turned off by the consumer.

B.3.9.15.1: Controller will neither accept to become SUC nor SIS.

Purpose If a controller is portable and/or can be turned off by the consumer it cannot be allowed to take the role of a SUC / SIS as they must be present in the network at all times.



Required Test Tool


Procedure This must be verified by reviewing the nature of the controller device. If the device is portable and/or can be turned off by the consumer, it must reject attempt of assigning the SUC / SIS role. This must be verified by creating a new network and monitor the traffic in the Zniffer or by using the Set SUC / SIS function in the Z-Wave PC Controller.




Expected outcome

The device must reject any request of becoming a SUC/SIS in the network. If SUC/SIS was rejected the Zniffer output must be substantially similar to:

1 State: enable, Server Running: false – SUC assignment - (Bytes: 01 00)

² Result: rejected - (Bytes: 00 00)

³ State: enable, Server Running: true – SIS assignment - (Bytes: 01 01)

4 Result: rejected - (Bytes: 00 00)

Comments

DUT PC Controller

Set SUC1

…

ACK

Set SUC ACK²

ACK

…

Set SUC³

ACK

Set SUC ACK4

ACK




8.4 General Demands for all protocol libraries

8.4.1 All supported Command Classes are listed in the NIF

Test Case All supported Command Classes are listed in the NIF


B.4.1

Item Description All Command Classes supported must be listed in the NIF.

Purpose The purpose of this item is to verify that all supported Command Classes are listed in the NIF.

Listing all supported Command Class in the NIF is mandatory so other nodes in the network can determine which Z-Wave Commands can be controlled in the DUT.


Required Test Tool

Zniffer

Procedure Trigger a NIF from the DUT according to the provided documentation and verify that all supported Command Classes are listed. The list of supported Command Classes in the NIF must match the selected Command Classes in Section A of the certification form.

Expected outcome

All supported Command Classes that are selected in Certification Form Section A should be listed in the NIF.

Comments As a general rule, a device supports a Command Class if it receives Get and Set Commands and sends out Report Commands.




8.4.2 Controlled Command Classes are listed in the NIF

Test Case Controlled Command Classes are listed in the NIF


B.4.2

Item Description Controlled Command Classes are listed in the NIF.

Purpose The purpose of this item is to check if controlled Command Classes are listed in the NIF.

Listing controlled Command Class in the NIF is optional but recommended.


Required Test Tool

Zniffer

Procedure Trigger a NIF of the DUT according to the provided documentation and check if controlled Command Classes are listed.

Expected outcome

Controlled Command Classes must be listed in the NIF if this item is marked. Only Command Classes that are selected as controlled in Certification Form Section A must be displayed in the NIF as controlled Command Classes.

Comments As a general rule, a device controls a Command Class if it sends out Get and Set Commands and receives Report Commands.




8.4.2.1 Control Mark exists if controlled Command Classes are displayed in the NIF

Test Case Control Mark exists if controlled Command Classes are displayed in the NIF


B.4.2.1

Item Description If controlled Command Classes are listed they must be listed correctly with proper use of the control mark.

Purpose The purpose of this item is to verify that a Control Mark byte (0xEF) is used to separate the supported and the controlled Command Classes in the NIF.


Required Test Tool

Zniffer

Procedure Trigger a NIF from the DUT according to the provided documentation and verify that a Control Mark byte (0xEF) is present in the NIF and that it is used as a delimiter to separate the supported Command Classes from the controlled Command Classes.

Expected outcome

The Command Classes list in the NIF should contain all supported Command Classes first, then the Control Mark byte (0xEF) and last of all the controlled Command Classes.

Comments If the DUT does not control any Command Classes or if the OEM decides to not display controlled Command Classes in the NIF then this item does not need to be checked.




9 Z-WAVE APPLICATION SUPPORT

Section A in the certification form is divided into two parts. The first part lists all existing Z-Wave Device Classes and their mandatory or recommended Command Classes. The developer of a Z-Wave device needs to select the appropriate Generic and Specific Device Class and all Command Classes that are supported or controlled by the device that needs to be certified.

The second part starts with item number A.100 and it contains a list of all available Z-Wave Command Classes. In this list ALL implemented Command Classes must be selected and it must be specified if the Command Class is supported or/and controlled. As a general rule a Command Class is supported if it receives Get and Set Commands and sends out Reports. A Command Class is controlled if the device sends out Get and Set Commands and receives Reports.

During the Documentation Review part of the certification process the test houses verify if the selection made in Section A is correct. A form failure e.g. is to select a Command Class that is not implemented or to not select a Command Class that is implemented and listed in the product documentation or the Node Information Frame. Furthermore the selected Generic and Specific Device Class is compared to the information given in the Node Information Frame.

Supported Command Classes

If a Command Class is supported then all Commands of this Class need to be implemented according to the Command Class Specification [2]. This is usually verified with the Compliance Test Tool (CTT) test scripts. However some Command Classes may not have scripts at all or it may not be comprehensive enough to test all features of the Command Class. In this case some or all Commands need to be tested manually with the PC Controller. Most importantly, that a CTT script passes the test of a supported Command Class does not necessarily mean that all mandatory features of this Command Class are correctly implemented. The CTT is a tool to assist and to speed up Command Class testing but it cannot be a final judge about the correctness of the implementation of a Command Class.

Supported Command Classes with Security Encapsulation

For all Z-Wave devices that implement the Security Command Class each secure Command Class must be tested with secure encapsulation. The Command Classes that are supported securely can be determined with a Security Commands Supported Get Command. In most cases a Command Class is supported with and without secure encapsulation depending on whether the device was included securely or not. In this case these Command Classes must be tested separately with and without encapsulation.

For the secure encapsulation tests the Compliance Test Tool (CTT) can be used as well. To run a CTT script with secure encapsulation the “Enable Security” option must be activated in the Encapsulation toolbar. In order to successfully run the script the DUT must be securely included within the CTT tool. If the DUT has been securely included by any other tool or device (e.g. the PC-Controller) then the CTT does not possess the correct network key and cannot communicate with the DUT via secure messages. When a Z-Wave device is selected as DUT in the CTT an interview will start which will automatically determine all Command Class that are supported securely. The results of this interview are shown in the message log window.

Controlled Command Classes

If a Command Class is controlled the developer can choose what Commands are controlled in other devices. As an example a device may control Multilevel Get and Set Commands but no Start/Stop Level Change Commands. During the verification tests the test houses check the correctness of the outgoing




Commands especially if all parameter values are valid. It is also verified if received Reports are interpreted correctly and if the device ignores reserved parameter values. This is mainly done with other slave devices or with the CTT Device Emulator. With this emulator it is possible to configure a slave device with arbitrary device classes and any supported Command Classes.

To pass the tests for the controlled Command Classes it is essential that the device developer provides sufficient information to the test house about how and under which circumstances a certain Command Class is controlled. Without this information the test houses cannot verify the correctness of the implementation and the Command Classes may be marked as failed.




10 CONTROLLER COMPLIANCE

10.1 All Controllers

10.1.1 Compliance with requirements for Generic and Specific Device Class

Test Case Functionality – All Controllers


C.1

Item Description This device complies with all mandatory requirements for its Generic and Specific Device Class

Purpose This field is used for the OEM to confirm that the DUT is designed for Z-Wave compliance, using the documentation available from Silicon Labs such as the Z-Wave Device Class Specification [2], the Z-Wave Command Class Specification [3] and the Z-Wave Application Programming Guide [1].


Required Test Tool

Procedure To validate this item, refer to the results of the Z-Wave Network Support (Section 2.7.4) and Z-Wave Application Support (Section 2.7.5).

Expected outcome

Comments Note: No additional tests are currently performed for this item in verification testing. Please note however that random spot checks are performed.




10.1.2 Certified devices can be included



C.1.1

Item Description All certified devices can be included into the DUT’s network

Purpose The purpose of this item is to verify that the DUT can include unknown and non-preferred devices to its network.


The DUT, Zniffer and sample devices are using the same operation frequency.

Required Test Tool

Zniffer

Procedure Add 2 random unknown devices from Home Control Groups not listed in 2.7.6.1 as controlled by this DUT

If Preferred VS non-Preferred control is implemented (2.7.6.2), add a random non-preferred device for each of the controlled Home Control Groups to the controller’s network.

Expected outcome

Successful inclusion of all devices

Comments Note: Sample devices can be real products or development boards with sample device code. The CTT’s device emulator can also be used to create unknown devices.




10.1.2.1 Non-preferred devices are not forced out of the network



C.1.1.1

Item Description After inclusion, non-preferred devices are not forced out of the network (excluded)

Purpose The purpose of this item is to verify that if Control of Preferred VS Non-Preferred Devices is implemented (Section 2.7.6.2), that devices added in C.1.1 are not automatically excluded or forced out of the network.


Successful inclusion of sample devices in C.1.1

Required Test Tool

Zniffer PC Controller

Procedure Add PC Controller to network as secondary and review the network device list. Confirm that all devices added in C.1.1 are shown. Control each non-preferred device using the DUT.

Visual verification is also needed to confirm that the user is not prompted to automatically start an exclusion process on the device just added; however, the user can be offered an option to exclude the device.

Expected outcome

All sample devices included in C.1.1 remain in the network and can be controlled.

Comments




10.1.3 Network Management functionality is included in the application/GUI



C.1.2

Item Description Network Management functionality is included in the application/GUI

Purpose The purpose of this item is to identify whether or not the DUT’s application/GUI includes network management functionality.


Required Test Tool

Procedure Visual verification

Expected outcome

Comments

10.1.3.1 Network Management functions are password protected



C.1.2.1

Item Description Network Management functions (inclusion, exclusion, replication, etc.) are password protected. Any combination is allowed.

Purpose The purpose of this item is to identify whether or not the network management functions are password protected and if so, that the provided password allows access and that they function properly.


Required Test Tool

Zniffer

Procedure Enter password to activate network management and use the provided functions to perform the various activities. Monitor network communications with the Zniffer to confirm functionality.

Expected outcome

All provided network management functions must work properly

Comments




10.1.3.2 Network Management functions are hidden from end user



C.1.2.2

Item Description Network Management functions are hidden from end user and only accessible to the owner of the device (Test lab must be given access for testing)

Purpose The purpose of this item is to verify that if the network management functions are hidden from the end user, that they are still included in the application and that they function properly when accessed by installers and/or tech support personnel.


Required Test Tool

Zniffer

Procedure Access network management and use the provided functions to perform the various activities. Monitor network communications with the Zniffer to confirm functionality.

Expected outcome

All provided network management functions must work properly

Comments

10.1.4 This device/software provides a limited control application/GUI



C.1.3

Item Description This device/software provides a limited control application/GUI that does not include Network Management Functionality.

Purpose The purpose of this item is to identify when network management functions are not included in the application/GUI.


Required Test Tool


Expected outcome

Comments




10.1.4.1 Network Management is provided through a separate application/GUI



C.1.3.1

Item Description Network Management functionality is provided through a separate Z-Wave certified application/GUI.

Purpose The purpose of this item is to identify the application used to access network management functionality and confirm that that application has a current certification.


Required Test Tool

Procedure Verify that the application identified in C.1.3.1.1 & C.1.3.1.1.1 provides network management functionality for this DUT and has a current, valid certification.

Expected outcome

Comments Note: Certifications for updateable products must be maintained as specified in the INS10638 Certification Overview.

10.1.5 Devices from non-preferred manufacturers are placed in a special section



C.1.4

Item Description Devices from non-preferred manufacturers are placed in a special section of the user interface. (this section should be referred to as “Additional Z-Wave Ecosystem Devices”)

Purpose The purpose of this item is to identify when non-preferred devices are segregated from preferred devices in the application/GUI.


Required Test Tool


Expected outcome

Comments




10.1.6 The user is informed that the device is not part of the preferred ecosystem



C.1.5

Item Description The user is informed, upon inclusion of non-preferred devices that the device being included is not part of the vendors preferred ecosystem, and that control and support of the device by the vendor may be limited.

Purpose The purpose of this item is to identify when control of non-preferred devices varies from the control provided for preferred devices and that the user is informed of this.


Required Test Tool


Expected outcome

Comments




10.1.6.1 Wording similar to the following is used: …



C.1.5.1

Item Description Wording similar to the following is used: “You are about to include a Z-Wave compatible device that is not promoted by ‘service provider name’ for use in this application. While the device should work as expected the device may or may not support all of the features of the ‘service provider name’ recommended device.”

Purpose The purpose of this item is to confirm that acceptable wording is used to describe the limited control provided for non-preferred devices.


Required Test Tool

Procedure Visual verification using the screen capture provided for C.1.5.1.1

Expected outcome

Comments




10.1.7 The user can select if they wish to continue with inclusion



C.1.5.2 C.1.5.2.1

Item Description The user can select if they wish to continue with inclusion of the non-preferred device or reverse the action (exclude after inclusion is completed). This warning is only permitted to be shown once during each inclusion.

It is not permitted to display additional pop-ups, ask for pin codes or implement any other blocking or discouraging behavior for inclusion or control of non-preferred devices.

Purpose The purpose of these items is to confirm that the application/GUI meets the requirements regarding inclusion and control of non-preferred devices.


Required Test Tool


Expected outcome

Comments




10.2 Dedicated Controllers

10.2.1 Minimum Controller Functionality is implemented

Test Case Dedicated Controllers Certification Form Item

C.2.1 C.2.2 C.2.3

Item Description Minimum Controller Functionality as defined in the Device Class Specification is implemented for the specific Home Control Group this device is designed to control. This is the minimum allowed. All Product Types within the designated Home Control Group must be supported with the functionality specified in the Minimum Controller Functionality section of the Device Class Specification. If Preferred VS Non-Preferred control functionality is implemented for devices from various manufacturers, control of non-preferred devices must meet the Minimal Controller Functionality requirements as identified in the Device Class Specification.

Purpose The purpose of these items is to confirm that minimum controller functionality has been implemented correctly.


Successful inclusion of 1 device for each Product Type within the controlled Home Control Group (see note)

Required Test Tool

Zniffer

Procedure Verify with each of the Product Types within the selected Home Control Group (Section 2.7.6.1) that minimum functionality is implemented correctly.

Expected outcome

Successful control of all mandatory functions for each non-preferred device in the network

Comments Note: Since a dedicated controller is typically designed to work with that manufacturer’s own specific brand of device, any other brand and/or a development board with sample application can be used for this testing.




10.2.2 The controller recognizes devices as “unknown” devices.


C.2.4

Item Description The controller recognizes all devices not included in the designated Home Control Group as “unknown” devices.

Purpose The purpose of this item is to confirm that the DUT can add devices not in the controlled Home Control Group and they are listed in the DUT’s network device list.


Required Test Tool

Zniffer

Procedure Add 3 random devices from different Home Control Groups (that this controller is not designed to control) to the network.

Expected outcome

Successful inclusion of all 3 devices

Comments Note: The CTT’s device emulator can also be used to create unknown devices.

10.2.2.1 Unknown devices can be controlled via the Basic Set commands


C.2.4.1

Item Description Unknown devices can be controlled via the Basic Set commands Off: 0x00 and On: 0xFF

Purpose The purpose of this item is to verify that if implemented, the user has a way to control the unknown devices.


Successful inclusion in C.2.4

Required Test Tool

Zniffer

Procedure Verify that Basic Set commands can control the unknown devices either individually or as a group

Expected outcome

Comments Note: The CTT’s device emulator can also be used to create unknown devices.




10.3 Universal Controllers

10.3.1 Minimum Controller Functionality is implemented

Test Case Universal Controllers Certification Form Item

C.3.1 C.3.2 C.3.3

Item Description Minimum Controller Functionality as defined in the Device Class Specification is implemented for all Home Control Groups this device is designed to control. This is the minimum allowed.

All Product Types within the designated Home Control Groups must be supported with the functionality specified in the Minimum Controller Functionality section of the Device Class Specification.

If Preferred VS Non-Preferred control functionality is implemented for devices from various manufacturers, control of non-preferred devices must meet the Minimal Controller Functionality requirements as identified in the Device Class Specification

Purpose The purpose of these items is to confirm that minimum controller functionality has been implemented correctly.


Successful inclusion of 2 devices for each Product Type within the controlled Home Control Groups (see note)

Required Test Tool

Zniffer

Procedure Verify with each of the Product Types within the selected Home Control Groups (Section 2.7.6.1) that minimum functionality is correctly implemented.

If Preferred VS Non-Preferred control functionality is implemented, add a random non-preferred device from each of the selected/controlled Home Control Groups (section 2.7.6.1) to the network and verify that minimum functionality is provided.

Expected outcome

Minimal functionality is correctly implemented for all selected Home Control Groups

Comments Note: Different brands of devices or one real product plus a development board with sample application should be used for testing each Product Type within the controlled Home Control Groups.




10.3.2 The controller recognizes devices as “unknown” devices


C.3.4

Item Description The controller recognizes all devices not included in the designated Home Control Groups as “unknown” devices.

Purpose The purpose of this item is to confirm that the DUT can add devices not in the controlled Home Control Group and they are listed in the DUT’s network device list.


Required Test Tool

Zniffer

Procedure Add 3 random devices from different Home Control Groups (that this controller is not designed to control) to the network.

Expected outcome

Successful inclusion of all 3 devices

Comments

10.3.2.1 Unknown devices can be controlled via the Basic Set commands


C.3.4.1

Item Description Unknown devices can be individually controlled via the Basic Set commands Off: 0x00 and On: 0xFF

Purpose The purpose of this item is to verify that the user has a way to individually control the unknown devices.


Successful inclusion in C.3.4

Required Test Tool

Zniffer

Procedure Verify that Basic Set On/Off commands can individually control the unknown devices added in C.3.4.

Expected outcome

Successful control via Basic CC

Comments




11 SECURITY TEST CASES

This section contains additional mandatory test cases for security enabled Slaves and Controllers. These test cases extend the required procedures for certification form items 8.11, Inclusion of DUT (Slave) and 8.2.2, Inclusion of DUT.

There are two different sections where the DUT is either included by another Controller or the DUT includes another security enabled device. While the later section only applies to Controllers the former section applies to both device types but the tests cases differ slightly between a Slave and a Controller.

In all test cases a secure Inclusion process follows the normal Inclusion and depending on the test case different timing or other error criteria are applied in order to verify the correct behavior of the DUT in such a fault condition.

Correct behavior usually means that the DUT aborts the secure Inclusion process and does not treat itself or other included device as secure devices. How this can be verified is explained in the sections below.

The following Pre-requisites and Test setup is required:

The required Test Tools are

- Security Z-Wave PC Controller - Security enabled Zniffer

The DUT and the Z-Wave PC Controller should not be part of the same network, preferably by doing a factory reset. After each test case the DUT and the Z-Wave PC Controller should be reset again.

This must be verified by sending a Basic Get from the including device. The included device should not respond the Nonce Get command with a Nonce Report. Not responding the mentioned command means it is not secure included.

The Security enabled Zniffer is able to decrypt secure Z-Wave messages if the Decrypt button is pressed on the right side of the Frame Details window and the correct network key is entered in the opened dialog. To get the network key that an including controller uses a secure Inclusion process needs to be recorded. The first encrypted message in a secure Inclusion process is the Network Key Set command from the including controller. This message contains the network key and it can be decrypted with the temporary scheme network key which is for Scheme 0 as follows:

- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

For all flow diagrams in this section the following descriptions apply:



Encrypted Command




11.1 Z-Wave PC Controller includes the DUT

The following test cases must be performed for all security enabled Slaves and Controllers. During all these test cases the DUT is securely included by a PC Controller. However some test cases only apply if the DUT is a Controller.

The DUT must abort the secure Inclusion process depending on different error conditions. If the secure Inclusion is stopped, the DUT must not be part of the secure Z-Wave network. This can be verified by sending a Secure Basic Get from the Z-Wave PC Controller to the DUT. The DUT must not respond the Nonce Get command with a Nonce Report.

To start the test cases open the Security Z-Wave PC Controller and select the Security Test Schema item in the Categories menu

The following tab should open in the upper right section of the Z-Wave PC Controller. Enable the check box Enable security test schema and select Including Controller as Inclusion Role. This means the PC Controller includes the DUT.




11.1.1 Invalid Nonce in Network Key Set

Select the Invalid Nonce in Network Key Set item and insert any Nonce in the corresponding text field. The Nonce is a hexadecimal number with 16 digits/8 bytes (e.g. 0102030405060708).

The Nonce is requested by the message sender from the message receiver before the actual message is sent. This Nonce is used to encrypt the message to be sent. If the sender (PC Controller) uses a different Nonce to encrypt the message then the Slave is not able to decrypt the message.

Procedure:

Include the DUT according to the provided documentation into the Z-Wave PC Controllers network.

The expected outcome should be similar to:

After the Network Key Set from the PC Controller the DUT is not allowed to answer with a Network Key Verify because the Network Key Set was encrypted with a wrong Nonce. The secure Inclusion process must be aborted by the DUT at this point.

If the DUT is a controller, secure inclusion was aborted, AND the DUT was added to the network as a non-secure device, you MUST verify that the DUT Controller cannot include other nodes securely.




11.1.2 Invalid MAC in Network Key Set

Select the Invalid MAC in Network Key Set item and insert any MAC in the corresponding text field. The MAC is a hexadecimal number with 16 digits/8 bytes (e.g. 0102030405060708).

The Message Authentication Code is a checksum that is used by the receiver to verify the integrity of the secure message. If the MAC in the secure message differs from the MAC that the receiver calculated from the message payload then this message has been tampered with and it must be dropped.

Procedure:



After the Network Key Set from the PC Controller the DUT is not allowed to answer with a Network Key Verify because the message contained a wrong MAC. The secure Inclusion process must be aborted by the DUT at this point.





11.1.3 Invalid Network Key Set

Select the Invalid Network Key Set item and insert any Network Key in the corresponding text field. The Network Key is a hexadecimal number with 32 digits/16 bytes (e.g. 01020304050607080102030405060708).

The Network Key is an initially transferred 16 byte number that is used together with the sender and the receiver Nonce to encrypt and decrypt secure messages. This Network Key is transferred to the included Nodes with the Network Key Set command.

If the PC Controller sends a different Network Key than it is actually using to encrypt the following messages the DUT will encrypt its own messages with a wrong key and the PC Controller cannot decrypt those messages.

Procedure:



The secure Inclusion will be stopped by the PC Controller after the Network Key Verify because the PC Controller is not able to decrypt the Network Key Verify. The DUT is not securely included and it is not allowed to answer secure messages.





11.1.4 Send Invalid Scheme Inherit

This test item only applies if the DUT is a Controller.

Select the Send Invalid Scheme Inherit item and insert value 01 in the corresponding text field.

At the end of the secure Inclusion process the including Controller tells the included Controller it’s supported Schemes with a Scheme Inherit command. If the inherited Schemes do not match any of the supported Schemes of the included Controller it must abort the secure Inclusion. The only way to do this is by sending value 0x01 in the Scheme Inherit because this means Scheme 0 is not supported.

Procedure:



The DUT must abort the secure Inclusion after the Invalid Security Scheme Inherit because the DUT does not support any Scheme that the PC Controller tries to inherit.

If secure inclusion was aborted, AND the DUT was added to the network as a non-secure device, you MUST verify that the DUT Controller cannot include other nodes securely.




11.1.5 Delay Scheme Get

Select the Delay Scheme Get item and insert a number of seconds that is at least 3 seconds higher higher than the maximum time for the mandatory Inclusion Timer (10 sec), e.g. 13 sec.

Procedure:



The DUT must abort the secure Inclusion because of the exceeded Inclusion Timer.


11.1.6 Delay Nonce Get

Select the Delay Nonce Get item and insert a number of seconds that is at least 3 seconds higher than the maximum delay time for the Nonce Get (10 sec), e.g. 13sec.

Procedure:



The DUT must abort the secure Inclusion because of the delayed Nonce Get.


DUT PC Controller

Security Scheme Get

Inclusion Completed Inclusion Timer Delay: 13 sec




11.1.7 Delay Network Key Set

Select the Delay Network Key Set item and insert a number of seconds that is at least 3 seconds higher than the maximum delay for the Network Key Set command (10 sec), e.g. 13 sec.

Procedure:



The DUT must abort the secure Inclusion because of the delayed Network Key Set command.





11.1.8 Delay Nonce Report

Select the Delay Nonce Report and insert a number of seconds that the Nonce Report should be delayed e.g. 13 sec.

Procedure:



If the DUT is a Slave then this timing requirement is optional because for a slave the secure Inclusion is already complete as soon as the Network Key Set command has been received. Only because of the optional Nonce Request Timer the DUT may abort the inclusion.

If the DUT is a Controller then aborting the secure inclusion at this point is mandatory because another 10 sec. Inclusion timer must be active between the Network Key Set and the Scheme Inherit command from the including Controller (see the following test case). If secure inclusion was aborted, AND the DUT was added to the network as a non-secure device, you MUST verify that the DUT Controller cannot include other nodes securely.




11.1.9 Delay Scheme Inherit

This test items only applies if the DUT is a Controller.

Select the Delay Scheme Inherit item and insert a number of seconds that is at least 3 seconds higher than the maximum delay for the Scheme Inherit command (10 sec), e.g. 13 sec.

Procedure:



The DUT must abort the secure Inclusion because of the delayed Scheme Inherit command.

If secure inclusion was aborted, AND the DUT was added to the network as a non-secure device, you MUST verify that the DUT Controller cannot include other nodes securely.




11.2 Z-Wave PC Controller is included by the DUT

The following test cases must be performed if the DUT is a controller and if it is able to securely include other Z-Wave devices. During all these test cases the DUT includes the Z-Wave PC Controller as a secure node.

The DUT must abort the secure Inclusion process depending on different error conditions. If the secure Inclusion is stopped, the DUT must not treat the Z-Wave PC Controller as a secure node. This can be verified by communicating with the included Z-Wave PC Controller. The DUT must not send any secure messages to the Z-Wave PC Controller.

To start the test cases open the Security Z-Wave PC Controller and select the Security Test Schema item in the Categories menu.

The following tab should open in the upper right section of the Z-Wave PC Controller. Enable the check box Enable security test schema and select Included Node as Inclusion Role. This means the PC Controller is included by the DUT.




11.2.1 Invalid Nonce in Network Key Verify

Select the Invalid Nonce in Network Verify item and insert any Nonce in the corresponding text field. The Nonce is a hexadecimal number with 16 digits/8 bytes (e.g. 0102030405060708).

The Nonce is requested by the message sender from the message receiver before the actual message is sent. This Nonce is used to encrypt the message to be sent. If the sender (DUT) uses a different Nonce to encrypt the message then the Z-Wave PC Controller is not able to decrypt the message.

Procedure:

Include the Security Z-Wave PC Controller into the DUT´s Z-Wave network.


After the Network Key Verify from the PC Controller the DUT is not allowed to continue the secure Inclusion process because the Network Key Verify was encrypted with a wrong Nonce. The secure Inclusion process must be aborted by the DUT at this point.




11.2.2 Invalid MAC in Network Key Verify

Select the Invalid MAC in Network Key Verify item and insert any MAC in the corresponding text field. The MAC is a hexadecimal number with 16 digits/8 bytes (e.g. 0102030405060708).

The Message Authentication Code is a checksum that is used by the receiver to verify the integrity of the secure message. If the MAC in the secure message differs from the MAC that the receiver calculated from the message payload then this message has been tampered with and it must be dropped.

Procedure:



After the Network Key Verify from the PC Controller the DUT is not allowed to continue the secure Inclusion process because the message contained a wrong MAC. The secure Inclusion process must be aborted by the DUT at this point.




11.2.3 Invalid Network Key (Verify)

Select the Invalid Network Key (Verify) item and insert any Network Key in the corresponding text field. The Network Key is a hexadecimal number with 32 digits/16 bytes (e.g. 01020304050607080102030405060708).

The Network Key is an initially transferred 16 byte number that is used together with the sender and the receiver Nonce to encrypt and decrypt secure messages. This Network Key is transferred to the included Nodes with the Network Key Set command.

If the PC Controller uses a different Network Key to encrypt the Network Key Verify message then the DUT cannot decrypt this message.

Procedure:



The DUT must abort the secure Inclusion process if the Network Key Verify is encrypted with a wrong network key.




11.2.4 Delay Scheme Report

Select the Delay Scheme Report item and insert a number of seconds that is higher than the maximum time for the mandatory Inclusion Timer (10 sec), e.g. 12 sec.

Procedure:




11.2.5 Delay Nonce Report

Select the Delay Nonce Report and insert a number of seconds that the Nonce Report should be delayed e.g. 12 sec.

Procedure:







11.2.6 Delay Nonce Get

Select the Delay Nonce Get item and insert a number of seconds that is higher than the maximum delay time for the Nonce Get (10 sec), e.g. 12 sec.

Procedure:



The DUT must abort the secure Inclusion because of the delayed Nonce Get.




11.2.7 Delay Network Key Verify

Select the Delay Network Key Verify item and select a number of seconds that is higher than the maximum delay for the Network Key Set command (10 sec), e.g. 12 sec.

Procedure:



The DUT must abort the secure Inclusion because of the delayed Network Key Verify command.




11.2.8 Delay Scheme Report after Scheme Inherit

Select the Delay Scheme Report after Scheme Inherit item and insert a number of seconds that is higher than the maximum delay for the Scheme Report command (10 sec), e.g. 12 sec.

Procedure:



The DUT must abort the secure Inclusion because of the delayed Scheme Report command.




12 REFERENCES

The last two digits of the document part number refer to the revision of the document. When the document revision is listed as “xx” please refer to the latest revision of the document.

[1] Silicon Labs, INS10682, Instruction, Z-Wave 400 Series Appl. Prg. Guide v6.11.00 (JP) Silicon Labs, INS12034, Instruction, Z-Wave 400 Series Appl. Prg. Guide v6.02.00 Silicon Labs, INS10247, Instruction, Z-Wave ZW0201/ZW0301 Appl. Prg. Guide v5.03.00 Silicon Labs, INS11095, Instruction, Z-Wave ZW0201/ZW0301 Appl. Prg. Guide v4.54.02 Silicon Labs, INS10690, Instruction, Z-Wave ZW0102/ZW0201/ZW0301 Appl. Prg. Guide v4.28

[2] Silicon Labs, SDS10242, Software Design Specification, Z-Wave Device Class Specification

[3] Silicon Labs, SDS12657 (A-M) and SDS12652 (N-Z), Software Design Specification, Z-Wave Command Class Specifications

[4] Silicon Labs, INS10336, Instruction, Z-Wave Reliability Test Guideline

[5] Silicon Labs, INS10479, Instruction, Proprietary Command Class Request Form

[6] Silicon Labs, INS10638, Instruction, Z-Wave Certification Overview

[7] Silicon Labs, INS10637, Instruction, Z-Wave Certification Form V8.5

[8] Silicon Labs, SDS10865, Software Design Specification, Z-Wave Application Security Layer


http://www.silabs.com

Silicon Laboratories Inc.400 West Cesar ChavezAustin, TX 78701USA

Smart. Connected. Energy-Friendly.

Productswww.silabs.com/products

Qualitywww.silabs.com/quality

Support and Communitycommunity.silabs.com

DisclaimerSilicon Labs intends to provide customers with the latest, accurate, and in-depth documentation of all peripherals and modules available for system and software implementers using or intending to use the Silicon Labs products. Characterization data, available modules and peripherals, memory sizes and memory addresses refer to each specific device, and "Typical" parameters provided can and do vary in different applications. Application examples described herein are for illustrative purposes only. Silicon Labs reserves the right to make changes without further notice and limitation to product information, specifications, and descriptions herein, and does not give warranties as to the accuracy or completeness of the included information. Silicon Labs shall have no liability for the consequences of use of the information supplied herein. This document does not imply or express copyright licenses granted hereunder to design or fabricate any integrated circuits. The products are not designed or authorized to be used within any Life Support System without the specific written consent of Silicon Labs. A "Life Support System" is any product or system intended to support or sustain life and/or health, which, if it fails, can be reasonably expected to result in significant personal injury or death. Silicon Labs products are not designed or authorized for military applications. Silicon Labs products shall under no circumstances be used in weapons of mass destruction including (but not limited to) nuclear, biological or chemical weapons, or missiles capable of delivering such weapons.

Trademark InformationSilicon Laboratories Inc.® , Silicon Laboratories®, Silicon Labs®, SiLabs® and the Silicon Labs logo®, Bluegiga®, Bluegiga Logo®, Clockbuilder®, CMEMS®, DSPLL®, EFM®, EFM32®, EFR, Ember®, Energy Micro, Energy Micro logo and combinations thereof, "the world’s most energy friendly microcontrollers", Ember®, EZLink®, EZRadio®, EZRadioPRO®, Gecko®, ISOmodem®, Micrium, Precision32®, ProSLIC®, Simplicity Studio®, SiPHY®, Telegesis, the Telegesis Logo®, USBXpress®, Zentri, Z-Wave and others are trademarks or registered trademarks of Silicon Labs. ARM, CORTEX, Cortex-M3 and THUMB are trademarks or registered trademarks of ARM Holdings. Keil is a registered trademark of ARM Limited. All other products or brand names mentioned herein are trademarks of their respective holders.

certification test specification - silicon labs … · written by: dking;mvo;bbr date: 2018-03-06...

Documents