ISO/IEC 14543-4-3:2015

ISO/IEC 14543-4-3
Edition 1.0 2015-09
INTERNATIONAL
STANDARD
colour
inside
Information technology – Home electronic system (HES) architecture –
Part 4-3: Application layer interface to lower communications layers for network
enhanced control devices of HES Class 1

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about
ISO/IEC copyright or have an enquiry about obtaining additional rights to this publication, please contact the address
below or your local IEC member National Committee for further information.

IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé Fax: +41 22 919 03 00
CH-1211 Geneva 20 info@iec.ch
Switzerland www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the

latest edition, a corrigenda or an amendment might have been published.

IEC Catalogue - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
The stand-alone application for consulting the entire The world's leading online dictionary of electronic and
bibliographical information on IEC International Standards, electrical terms containing more than 30 000 terms and
Technical Specifications, Technical Reports and other definitions in English and French, with equivalent terms in 15
documents. Available for PC, Mac OS, Android Tablets and additional languages. Also known as the International
iPad. Electrotechnical Vocabulary (IEV) online.

IEC publications search - www.iec.ch/searchpub IEC Glossary - std.iec.ch/glossary
The advanced search enables to find IEC publications by a More than 60 000 electrotechnical terminology entries in
variety of criteria (reference number, text, technical English and French extracted from the Terms and Definitions
committee,…). It also gives information on projects, replaced clause of IEC publications issued since 2002. Some entries
and withdrawn publications. have been collected from earlier publications of IEC TC 37,

77, 86 and CISPR.
IEC Just Published - webstore.iec.ch/justpublished

Stay up to date on all new IEC publications. Just Published IEC Customer Service Centre - webstore.iec.ch/csc
details all new publications released. Available online and If you wish to give us your feedback on this publication or
also once a month by email. need further assistance, please contact the Customer Service
Centre: csc@iec.ch.
ISO/IEC 14543-4-3
Edition 1.0 2015-09
INTERNATIONAL
STANDARD
colour
inside
Information technology – Home electronic system (HES) architecture –

Part 4-3: Application layer interface to lower communications layers for network

enhanced control devices of HES Class 1

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 35.200 ISBN 978-2-8322-2868-5

– 2 – ISO/IEC 14543-4-3:2015
© ISO/IEC 2015
CONTENTS
FOREWORD . 5
INTRODUCTION . 6
1 Scope . 7
2 Normative references . 7
3 Terms, definitions and abbreviations . 7
3.1 Terms and definitions . 7
3.2 Abbreviations . 9
4 Conformance . 9
5 Services of the application layer . 9
5.1 Positioning in communications layers . 9
5.1.1 General . 9
5.1.2 When using UDP in layer 4 and IP in layer 3 . 10
5.2 Service primitives of the application layer . 10
5.2.1 General . 10
5.2.2 NECD objects from the viewpoint of application software . 11
5.2.3 Case 1: Obtaining the status of another node . 11
5.2.4 Case 2: Controlling the functions of other nodes . 12
5.2.5 Case 3: Notifying own node status to other nodes . 13
6 Application layer protocol data unit (APDU) . 15
6.1 Overview. 15
6.2 NECD header (NHD) . 16
6.2.1 Overview . 16
6.2.2 NECD header 1 (NHD1) . 16
6.2.3 NECD header 2 (NHD2) . 17
6.3 Transaction ID (TID) . 17
6.4 NECD data (NDATA) . 17
6.5 NECD object (NOJ) . 17
6.6 NECD Service (NSV) . 18
6.6.1 Overview . 18
6.6.2 Property value write service (no response required) [0x60, 0x50] . 22
6.6.3 Property value write service (response required) [0x61, 0x71, 0x51] . 22
6.6.4 Property value read service [0x62, 0x72, 0x52] . 23
6.6.5 Property value write and read service [0x6E, 0x7E, 0x5E] . 24
6.6.6 Property value notification service [0x63, 0x73, 0x53] . 25
6.6.7 Property value notification (response required) [0x74, 0x7A]. 26
6.7 Processing object property counters (OPC, OPCSet and OPCGet) . 27
6.8 NECD property (NPC) . 27
6.9 Property data counter (PDC) . 28
6.10 NECD property value data (NDT) . 28
7 Basic sequences . 29
7.1 General . 29
7.2 Basic sequences for object control . 29
7.2.1 Overview . 29
7.2.2 Basic sequences for object control in general . 29
7.2.3 Basic sequences for service content . 30

© ISO/IEC 2015
7.3 Basic sequences for node start-up . 32
7.3.1 Overview . 32
7.3.2 Basic sequence for NECD node start-up . 32
8 NECD objects – Detailed specifications . 33
8.1 General . 33
8.2 Types of objects. 33
8.2.1 Device objects . 33
8.2.2 Node profile object . 33
8.3 NECD property value data types . 33
8.3.1 Overview . 33
8.3.2 NECD property value range . 34
8.3.3 Class-specific mandatory properties . 34
8.3.4 Profiles obliged to have a status change announcement function . 35
Bibliography . 36

Figure 1 – Communications middleware . 9
Figure 2 – Acquisition of status of another node (synchronous type) . 11
Figure 3 – Acquisition of status of another node (asynchronous type) . 12
Figure 4 – Objects seen from application software . 12
Figure 5 – Method of controlling other nodes . 13
Figure 6 – Objects seen from application software . 13
Figure 7 – Method of notification to other nodes (synchronous type) . 14
Figure 8 – Method of notification to other nodes (asynchronous type) . 14
Figure 9 – Objects seen from application software . 14
Figure 10 – Example of object configuration . 15
Figure 11 – NECD frame format . 16
Figure 12 – Bit specifications of NHD 1 . 17
Figure 13 – Detailed specifications of NHD 2 . 17
Figure 14 – Bit specifications of the NOJ code . 18
Figure 15 – Bit specifications of the NSV code . 18
Figure 16 – Sequence diagram for NSV transmission and reception . 21
Figure 17 – NDATA configuration for property value write service (no response
required) . 22
Figure 18 – NDATA configuration for property value write service (response required) . 23
Figure 19 – NDATA configuration for property value read service . 24
Figure 20 – NDATA configuration for property value write and read service . 25
Figure 21 – NDATA configuration for property value notification service . 26
Figure 22 – NDATA configuration for property value notification (response required)
service . 27
Figure 23 – Processing target property counter for three requests . 27
Figure 24 – NPC detailed specifications . 28
Figure 25 – NPC code allocation . 28
Figure 26 – Basic sequence when controlled object does not exist . 29
Figure 27 – Basic sequence when controlled objects exist . 30
Figure 28 – Basic request receiving sequence for NSV = 0x60 . 30

– 4 – ISO/IEC 14543-4-3:2015
© ISO/IEC 2015
Figure 29 – Basic request receiving sequence for NSV = 0x6* . 31
Figure 30 – Basic request receiving sequence for NSV = 0x63 . 31
Figure 31 – Basic property value notification sequence . 32
Figure 32 – Basic sequence for NECD node start-up . 32

Table 1 – List of NSV Codes for Requests . 20
Table 2 – List of NSV codes for response/notification . 20
Table 3 – List of NSV codes for “Response not possible” . 21
Table 4 – Data types, data sizes and overflow / underflow codes . 34

© ISO/IEC 2015
INFORMATION TECHNOLOGY –
HOME ELECTRONIC SYSTEM (HES) ARCHITECTURE –

Part 4-3: Application layer interface to lower communications
layers for network enhanced control devices of HES Class 1

FOREWORD
1) ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission)
form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC
participate in the development of International Standards through technical committees established by the
respective organization to deal with particular fields of technical activity. ISO and IEC technical committees
collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in
liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have
established a joint technical committee, ISO/IEC JTC 1.
2) The formal decisions or agreements of IEC and ISO on technical matters express, as nearly as possible, an
international consensus of opinion on the relevant subjects since each technical committee has representation
from all interested IEC National Committees and ISO member bodies.
3) IEC, ISO and ISO/IEC publications have the form of recommendations for international use and are accepted
by IEC National Committees and ISO member bodies in that sense. While all reasonable efforts are made to
ensure that the technical content of IEC, ISO and ISO/IEC publications is accurate, IEC or ISO cannot be held
responsible for the way in which they are used or for any misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees and ISO member bodies undertake to
apply IEC, ISO and ISO/IEC publications transparently to the maximum extent possible in their national and
regional publications. Any divergence between any ISO, IEC or ISO/IEC publication and the corresponding
national or regional publication should be clearly indicated in the latter.
5) ISO and IEC do not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. ISO or IEC are not responsible
for any services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or ISO or its directors, employees, servants or agents including individual experts
and members of their technical committees and IEC National Committees or ISO member bodies for any
personal injury, property damage or other damage of any nature whatsoever, whether direct or indirect, or for
costs (including legal fees) and expenses arising out of the publication of, use of, or reliance upon, this ISO/IEC
publication or any other IEC, ISO or ISO/IEC publications.
8) Attention is drawn to the normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this ISO/IEC publication may be the subject of
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
International Standard ISO/IEC 14543-4-3 was prepared by subcommittee 25: Interconnection
of information technology equipment, of ISO/IEC joint technical committee 1: Information
technology.
The list of all currently available parts of the ISO/IEC 14543 series, under the general title
Information technology – Home electronic system (HES) architecture, can be found on the
IEC web site and ISO web site.
This International Standard has been approved by vote of the member bodies, and the voting
results may be obtained from the address given on the second title page.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct
understanding of its contents. Users should therefore print this document using a
colour printer.
– 6 – ISO/IEC 14543-4-3:2015
© ISO/IEC 2015
INTRODUCTION
This part of ISO/IEC 14543 specifies the message structure, sequences and protocol of the
application layer for use in the Home Electronic System. Some services are targeted for
communications between devices. Other services are exclusively reserved for management
purposes. Some services can be used for both management and run-time communications.
This standard is applicable for energy management services, mobile access, remote
appliance maintenance services, home healthcare services, home security services and
th th
comfort control. This standard focuses on the application layers (5 layer to 7 layer of the
OSI reference model). This standard specifies a message structure that differs from the
12 message structures specified in ISO/IEC 14543-4-1. This standard allows the use of IP
addressing or MAC addressing, while ISO/IEC 14543-4-1 specifies a different non-IP address
structure. This part depends on routing functions provided by an external IP layer.
ISO/IEC 14543-4-1 uses the routing functions specified in ISO/IEC 14543-4-2. Therefore
Part 4-3 is an alternative to Part 3-1 plus Part 3-2.
ISO/IEC 14543, Information technology – Home Electronic System (HES) architecture,
provides
an introduction to specifications for Home Electronic System (HES):
Part 2-1: Introduction and device modularity
and specifications for three types of HES devices:
Parts 3-x Specifications for network based control of HES Class 1
Parts 4-x Specifications for network enhanced control of HES Class 1
Parts 5-x Specifications for intelligent grouping and resource sharing for HES Class 2
and Class 3
© ISO/IEC 2015
INFORMATION TECHNOLOGY –
HOME ELECTRONIC SYSTEM (HES) ARCHITECTURE –

Part 4-3: Application layer interface to lower communications
layers for network enhanced control devices of HES Class 1

1 Scope
This part of ISO/IEC 14543 specifies the message structure, sequences and protocol of the
application layer for use in network enhanced control devices of the Home Electronic System
(HES) Class 1. It provides the services and the interface for the user-level process. This
application layer protocol is independent of lower communications layers, which support MAC
addressing or IP addressing. The communications sequence is based on the application
services.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and
are indispensable for its application. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any
amendments) applies.
ISO/IEC 14543-2-1, Information technology – Home electronic system (HES) architecture –
Part 2-1: Introduction and device modularity
ISO/IEC 14543-4-1, Information technology – Home electronic system (HES) architecture –
Part 4-1: Communication layers – Application layer for the network enhanced control devices
of HES Class 1
ISO/IEC 14543-4-2, Information technology – Home electronic system (HES) architecture –
Part 4-2: Communication layers – Transport, network and general parts of data link layer for
network enhanced control devices of HES Class 1
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document the terms and definitions given in ISO/IEC 14543-2-1 and
the following apply.
3.1.1
NECD communications middleware
middleware between the lower communications layers to the application layer that performs
communications processing according to the protocol specified in this standard
3.1.2
NECD communications processing block
processing block for the communications middleware
Note 1 to entry: This block performs communications protocol processing to facilitate remote device control /
monitoring processing for application software, stores information for the above and controls various data on the
device as well as the status of other devices.

– 8 – ISO/IEC 14543-4-3:2015
© ISO/IEC 2015
3.1.3
NECD data
NDATA
data region for message exchanged by NECD communications middleware
3.1.4
NECD header
NHD
data containing the protocol type and message format for the NDATA section
3.1.5
NECD object
NOJ
model of information to be disclosed to the network from information owned by the NECD
communications processing block, or an access procedure model
Note 1 to entry: The information or control target owned by each device is specified as a property and the
operating method (setting, browsing) for this is specified as a service.
3.1.6
NECD property code
NPC
code value related to the NECD property
3.1.7
NECD service
NSV
code value related to the NECD service
3.1.8
NECD frames
frame composed of NHD1, NHD2, TID and NDATA
3.1.9
property value data
data value related to the NECD property code (NPC)
EXAMPLE Status notification or specific setting.
Note 1 to entry: Property value data is controlled by the NECD service (NSV).
3.1.10
transaction ID
TID
parameter to link a sent request with a received response
3.1.11
property data counter
PDC
indication of the size of the NDT region

© ISO/IEC 2015
3.2 Abbreviations
DNOJ Destination NECD ObJect
IP Internet Protocol
NDATA NECD DATA
NDT NECD DaTa
NECD Network Enhanced Control Device
NHD NECD HeaDer
NPC NECD Property Counters
NSV NECD SerVice
OPC Processing Object Property Counter
PDC Property Data Counter
SNOJ Source NECD ObJect
TID Transaction ID
UDP User Datagram Protocol
4 Conformance
Enhanced control devices of HES Class 1 that claim conformance to this International
Standard shall:
• send, receive and process application layer protocol data units as specified in Clause 6;
• provide application services specified in 6.6 that may be needed by devices for which the
application is intended.
5 Services of the application layer
5.1 Positioning in communications layers
5.1.1 General
The NECD communications processing block is positioned between application and lower
communications layers. This standard provides the specifications of “NECD communications
processing block”. In Figure 1, the shaded area shows the communications middleware block
to be specified.
OSI layer
Application
Device objects Profile objects
NECD
communications
NECD communications
middleware
processing block
Lower communications layers
(Layers 1 to 4 not defined)
IEC
Figure 1 – Communications middleware

– 10 – ISO/IEC 14543-4-3:2015
© ISO/IEC 2015
As Figure 1 shows, the NECD communications middleware block specified in this standard
corresponds to the NECD communications processing block, which is specified as a function
that is independent of layers 1 to 4. The NECD communications processing block sends and
receives a NECD frame specified in Clause 6. There are two kinds of messages: unicast and
broadcast.
Unicast transmission specifies a destination address that is in layer 4 or lower, and transmits
the NECD frame to a specific NECD node. Broadcast transmission specifies a destination
address that is in layer 4 or lower, and transmits the NECD frame to all the NECD nodes in a
subnet. In case of UDP/IP, refer to 5.1.2.
When the transmission system of layer 4 or lower layer corresponds to neither multicasting
nor broadcasting, it shall transmit to all the NECD nodes in a subnet using multiple unicast
transmissions to achieve the equivalence of a broadcast transmission. The destination
address and the method for setting it are not specified, but shall be defined for every lower
communications layer.
Security is not specified in the NECD communications processing block. Security standard
technologies in layer 4 or lower can be applied as necessary.
5.1.2 When using UDP in layer 4 and IP in layer 3
When using UDP/IP, the following addresses and ports shall be supported.
Each NECD node has an IP address. The IP address range and acquisition method are not
specified. If NECD frames are transferred by UDP packets, the destination port number of
UDP packets shall be 3 610. The source port number is not specified. For general broadcast
(simultaneous transmission), NECD frames are mapped on IP multicast packets and
transferred. For IPv4, the destination multicast address value shall be 224.0.23.0. For IPv6,
ff02::1 (all-node multicast address) shall be used.
5.2 Service primitives of the application layer
5.2.1 General
The NECD objects are introduced with two objectives:
• compartmentalisation of the functions of devices connected to the NECD network;
• modularisation of communications between devices to enable application software
developers to utilise NECD communications without having to consider detailed
specifications.
The NECD objects are processed in the NECD communications processing block. Control
content exchanged in communications can be classified into those relating to functions unique
to each device and those relating to data profiling other than the functions unique to each
device. In NECD, all of these are specified as NECD objects, and control and data exchange
are achieved to enable their manipulation.
Each NECD object has some properties. The various unique functions possessed by an
NECD node are represented as NECD properties. Devices are operated by reading or writing
the NECD properties of the NECD object in the relevant NECD node.
NECD objects are defined by the following specifications: object type (codes are specified in
6.5 as NOJ); the properties possessed by each object (codes are specified in 6.8 as NPC);
and the services for those properties (codes are specified in 6.6 as NSV).
NOTE It is assumed that each NECD node would have more than one NECD object of the same type (e.g., two
human detection sensor objects in the same node), and that identification could be performed by stipulating a
specific code.
© ISO/IEC 2015
5.2.2 NECD objects from the viewpoint of application software
Control from application software is described for the three main cases listed below, with a
focus on how the NECD objects are perceived.
• Case 1: Obtaining the status of another node
• Case 2: Controlling the functions of other nodes
• Case 3: Notifying own node status to other nodes
5.2.3 Case 1: Obtaining the status of another node
This standard provides two methods: synchronous type and asynchronous type for obtaining
the status of another node. Each device can select the synchronous type or asynchronous
type. These methods are shown in Figure 2 (synchronous type) and Figure 3 (asynchronous
type). In the method shown in Figure 2, when the NECD communications middleware receives
a request from an application, the NECD communications middleware sends the request to
obtain the status of another node to the target node (Node B). After that NECD
communications middleware receives the results, NECD communications middleware notifies
the application of the status. With this method, object data for the other node need not be
stored in the NECD communications middleware for the node (Node A in Figure 2 and
Figure 3), which sends the request. In the second method, shown in Figure 3, even when the
NECD communications middleware does not receive any request from an application, it
receives and holds the notified status of objects in other nodes in advance, and then returns
them to an application when it receives a request. In this method, objects copied to NECD
objects in other nodes actually exist within the NECD communications middleware.
In the former method (Figure 2), a virtual copy of the NECD objects in the other nodes exists
in the NECD communications middleware because access is performed from an application.
In the latter method (Figure 3), a copy of each property of the NECD objects in the other
nodes exists in the NECD communications middleware. In both cases, in order to set the
desired NECD object instance, not only the NECD object class code, but also an instance
code and data that is specifying the node are necessary. From the viewpoint of the application,
therefore, NECD objects are represented using the relationship shown in Figure 4 within the
NECD communications middleware.
Status read
Node A Node B
Application software Application software
NOJ NOJ
Status of peer node
NECD communications middleware NECD communications middleware
IEC
Figure 2 – Acquisition of status of another node (synchronous type)

– 12 – ISO/IEC 14543-4-3:2015
© ISO/IEC 2015
Node A Node C
Application software Application software
NOJ NOJ
Status of peer node
NECD communications middleware
NECD communications middleware

IEC
Figure 3 – Acquisition of status of another node (asynchronous type)
Node A
Application software
Node B Node C
NOJ NOJ
NOJ
NOJ
NOJ
NOJ
NECD communications middleware
IEC
Figure 4 – Objects seen from application software
5.2.4 Case 2: Controlling the functions of other nodes
The NECD provides a method for controlling the functions of other nodes, as shown in
Figure 5. Just as in Figure 2, however, a request for control (property value setting) is issued
to objects in the target node (Node B), and the application is then notified of the results
(although there are exceptions to this). Basically, therefore, property data for objects in the
other node (Node B) need not be present in the NECD communications middleware for the
node (Node A), which sends the request. From the viewpoint of the application, the NECD
objects are seen in the relationship shown by Node B in Figure 6 within the NECD
communications middleware.
© ISO/IEC 2015
Control setting
request
Node A Node B
Application software Application software
NOJ NOJ
NECD communications middleware
NECD communications middleware

IEC
Figure 5 – Method of controlling other nodes
Node A
Application software
Node B
NOJ
NOJ
NOJ
NECD communications middleware
IEC
Figure 6 – Objects seen from application software
5.2.5 Case 3: Notifying own node status to other nodes
The NECD provides two methods: “synchronous type” and “asynchronous type” for notifying
the status of the own node to the application software on another node. Each device can
select the synchronous type or asynchronous type. These methods are shown in Figure 7
(synchronous type) and Figure 8 (asynchronous type). In the method shown in Figure 7, when
the NECD communications middleware receives a request from an application, it sends the
notification to the other specified node (Node B) immediately. In this case, the device status
need not be stored as an object in the NECD communications middleware for the node (Node
A) that is notifying the status.
In the second method, shown in Figure 8, when the NECD communications middleware
receives a request from an application, it periodically notifies the property value to the other
node. In this case, the NECD object data actually exists in the NECD communications
middleware. In either case, from the viewpoint of the application, the NECD objects of the own
node are seen as existing within the NECD communications middleware (Figure 9).

– 14 – ISO/IEC 14543-4-3:2015
© ISO/IEC 2015
Node A Node B
Application software Application software
Immediate
transmission of
status setting to
NOJ
Node B status of peer node
NECD communications middleware
NECD communications middleware

IEC
Figure 7 – Method of notification to other nodes (synchronous type)
Node A Node C
Application software Application software
No transmission
until status
NOJ
setting
Status of peer node
implementation
time
NECD communications middleware NECD communications middleware
IEC
Figure 8 – Method of notification to other nodes (asynchronous type)
Node A
Application software
Node B
NOJ
NOJ
NOJ
NECD communications middleware
IEC
Figure 9 – Objects seen from application software

© ISO/IEC 2015
As is clear from the three cases shown above, the NECD communications middleware is
viewed by the application software as containing (and in some cases actually does contain)
a) a collection of NECD objects of the own node whose role is to disclose the functions of the
own node to other nodes and to be controlled by other nodes; and
b) NECD objects at the node level whose role is to control and obtain the status of the
functions of other nodes.
Own node properties exist in the NECD communications middleware of only one device. The
middleware also may contain properties of other related nodes.
Based on the above, Figure 10 shows an example of the NECD communications middleware
object configuration for a system in which an air conditioner, ventilation fan and motion
detection sensor are connected as separate nodes via a network, seen from the perspective
of the application software in the air conditioner.
NECD communications middleware
Other device n
Own device Other device 2
(Object group for own node device disclosure) (Object field for other node function control)
Air conditioner class
[ Instance 1 ] Ventilator class
[ Instance 1 ]
Property Contents of
property
Property Contents of
Operating state ON/OFF
Property
Operation mode Auto/cooling/ Operating state ON/OFF
…
heating/.
…
Temperature setting Temperature
Fault occurrence Fault Yes/No
value
status
Fault occurrence Fault Yes/No
status
Other device 1
(Object field for other node function control)
Human detection sensor class
[ Instance 2 ]
Motion detection sensProperor tcylass Contents of
[ Instance 1 ]
Property
Property Contents of
Operating state ON/OFF
Property
Detection Level 1…
Operating state ON/OFF
threshold level
Detection Level 1…
Human detection Yes/No
threshold level
status
Human detection Yes/No
status
Fault occurrence Fault Yes/No
Fault occurrence Fault Yes/No
status
IEC
Figure 10 – Example of object configuration
6 Application layer protocol data unit (APDU)
6.1 Overview
To reduce the load of simple devices, NECD specifies the frame format for the NECD
communications middleware block to minimise the message size while fulfilling the
requirements of the communications layer structure.
Figure 11 shows the format of NECD frames processed by the NECD communications
middleware. Detailed specifications for each message component are described in 6.2 to 6.10.

– 16 – ISO/IEC 14543-4-3:2015
© ISO/IEC 2015
In these specifications, messages exchanged between the NECD communications processing
blocks are called NECD frames. NECD frames are divided into two types depending on the
specified NHD (see 6.2): message format specified by the NECD (Format 1) and message
format unique to manufacturers (Format 2). Format 2 is specified so that each manufacturer
can provide additional functions. The NECD frame length depends on the lower-layer
communications media.
Format 2 (arbitrary
Arbitrary format
message format)
Format 1 (specified
SNOJ DNOJ NSV OPC NPC 1 PDC 1 NDT 1 --- NPC n PDC n NDT n
message format)
SNOJ : Source NECD object (3 B)
DNOJ : Destination NECD object (3 B)
NSV : NECD service (1 B)
OPC : Number of processing properties (1 Byte
NPC : NECD property code (1 B)
PDC : Property data counter (1 B)
NDT : Property value data (Specified by PDC)
NHD1 NHD2 TID NDATA
NHD1 : NECD message header 1 (1 B)
NHD2 : NECD message header 2 (1 B)
TID : Transaction ID (2 B)
NDATA : NECD DATA
IEC
Figure 11 – NECD frame format
6.2 NECD header (NHD)
6.2.1 Overview
NHD consists of an NECD header 1 and an NECD header 2.
6.2.2 NECD header 1 (NHD1)
Figure 12 shows the detailed specifications of the NECD header 1 (NHD1) byte. The contents
of this byte are shown in Figure 12.

© ISO/IEC 2015
b7 b6 b5 b4 b3 b2 b1 b0
0 0 0 1 0 0 0 0
Reserved for future use
Protocol type
1***: Conventional ECHONET specification
(ISO/IEC 14543-4-1, ISO/IEC 14543-4-2)
0001: ECHONET lite specification
(This standard)
0000: DO NOT USE
Other: Reserved for future use

IEC
Figure 12 – Bit specifications of NHD 1
The combination of b7 to b4 specifies an NECD protocol type. “b7:b6:b5:b4 = 0:0:0:1”
indicates the NECD protocol defined in this standard “b7:b6:b5:b4 = 0:0:0:0” shall not be used
because it would prevent compatibility with ISO/IEC 14543-4-1 and ISO/IEC 14543-4-2.
6.2.3 NECD header 2 (NHD2)
Figure 13 shows the detailed specifications of NECD header 2 (NHD2) shown in Figure 11.
b7 b6 b5 b4 b3 b2 b1 b0
1 0 0 0 0 0 * *
0x81: Format 1
0x82: Format 2
Other: Reserved for future use
However, b7 = 1 (fixed)
IEC
Figure 13 – Detailed specifications of NHD 2
NHD2 defines the NDATA frame format. When the value of NHD2 is 0x81, the NDATA frame
format is Format 1 (specified message format) defined in this standard. When the value of
NHD2 is 0x82, the NDATA frame format is Format 2 (arbitrary message format). For
coexistence with the ISO/IEC 14543-4-1 and ISO/IEC 14543-4-2 Protocol, b7 shall be
constantly set to 1.
6.3 Transaction ID (TID)
TID is a parameter to associate a received response with a sent request when the request
sender receives the response in NECD communications. The response sender shall store the
same value as that contained in the request message.
6.4 NECD data (NDATA)
NDATA refers to the data area of a message exchanged by the NECD communications
middleware.
6.5 NECD object (NOJ)
Figure 14 shows the detailed specifications of NECD objects in Figure 11.

– 18 – ISO/IEC 14543-4-3:2015
© ISO/IEC 2015
Byte 1 Byte 2 Byte 3
b7 b6 b5 b4 b3 b2 b1 b0 b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
X3: Instance code
X2: Class code
X1: Class group code
IEC
Figure 14 – Bit specifications of the NOJ code
NECD objects are described using the formats [X1.X2] and [X3], to be specified as shown
below. (However, “.” is used only for descriptive purposes and does not mean a specific
code.) The object class is designated by the combination of X1 and X2, while X3 shows the
class instance. A single NECD node may contain more than one instance of the same class,
in which case X3 is used to identify each one.
The instance code 0x00 is regarded as a special code (code for specifying all instances).
When a DNOJ having this specified code is received, it is handled as a code specifying
general broadcast to all instances of a specified class.
• X1: Class group code
0x00–0xFF.
• X2: Class code
0x00–0xFF.
• X3: Instance code
0x00 – 0x7F. This is an identification code when more than one of the same class as that
of the attributes specified by [X1.X2] exists in the same node.
However, 0x00 is used for general broadcast to instances of the same class.
6.6 NECD Service (NSV)
6.6.1 Overview
This subclause provides detailed specifications for the NECD service (NSV) code shown in
Figure 15.
b7 b6 b5 b4 b3 b2 b1 b0
0  1
For details, see Tables 1 to 3.
Fixed
IEC
NOTE Except when b7:b6=0:1, b0 to b5 have different meanings.
Figure 15 – Bit specifications of the NSV code
It specifies a simultaneous action for one or more properties stipulated by the NPC. However,
it does not stipulate the order of operations. The order of property operations is an
implementation issue.
© ISO/IEC 2015
The following three types of operations are provided. The response is subdivided into two
types: “response” and “response not possible”. The “response” is used when the service
request in relation to all the NPC-stipulated properties is accepted. The “response not
possible” is used when one or more specified properties do not exist or when the specified
service cannot be processed for one or more properties.
“Request,” “Response” (response/response not possible) and “Notification”.
The “response” is a response to a “request” that requires a response. It shall be returned
when an NOJ-stipulated object exists. When the service-processing request related to all the
NPC-stipulated properties is accepted, the “response” shall be returned. If the processing
request related to one or more specified properties cannot be accepted or if the object exists
but one or more properties do not exist, “response not possible” shall be returned. When the
“request” does not require any response or when the specified object does not exist, no
“response” will be returned.
There are two types of “notificatio
...