ISO 22510:2019
(Main)Open data communication in building automation, controls and building management — Home and building electronic systems — KNXnet/IP communication
Open data communication in building automation, controls and building management — Home and building electronic systems — KNXnet/IP communication
This document defines the integration of KNX protocol implementations on top of Internet protocol (IP) networks, called KNXnet/IP. It describes a standard protocol for KNX devices connected to an IP network, called KNXnet/IP devices. The IP network acts as a fast (compared to KNX twisted pair transmission speed) backbone in KNX installations.
Réseau ouvert de communication de données pour l'automatisation, la régulation et la gestion technique du bâtiment — Systèmes électroniques pour la maison et le bâtiment — Communication KNXnet/IP
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 22510
First edition
2019-11
Open data communication in building
automation, controls and building
management — Home and building
electronic systems — KNXnet/IP
communication
Réseau ouvert de communication de données pour l'automatisation,
la régulation et la gestion technique du bâtiment — Systèmes
électroniques pour les foyers domestiques et les bâtiments —
Communication KNX/IP
Reference number
©
ISO 2019
© ISO 2019
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2019 – All rights reserved
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 4
5 Requirements . 5
5.1 Overview . 5
5.1.1 KNXnet/IP document parts . 5
5.1.2 Mandatory and optional implementation of IP protocols . 7
5.2 Core . 8
5.2.1 Use . 8
5.2.2 KNXnet/IP frames . 9
5.2.3 Host protocol independence.10
5.2.4 Discovery and self description .11
5.2.5 Communication channels .13
5.2.6 General implementation guidelines .15
5.2.7 Data Packet structures .19
5.2.8 IP Networks .38
5.2.9 Minimum supported services .47
5.3 Device management specification .48
5.3.1 Use .48
5.3.2 KNXnet/IP device management .48
5.3.3 Implementation rules and guidelines .59
5.3.4 Data packet structures .60
5.3.5 Minimum profiles .63
5.4 Tunnelling .64
5.4.1 Use .64
5.4.2 Tunnelling of KNX telegrams .64
5.4.3 Configuration and management .68
5.4.4 Frame structures.70
5.4.5 Minimum profiles .77
5.5 Routing .78
5.5.1 Use .78
5.5.2 KNXnet/IP routing of KNX telegrams .78
5.5.3 Implementation rules and guidelines .88
5.5.4 Configuration and management .91
5.5.5 Data packet structures .91
5.5.6 Minimum profiles .93
5.6 Remote diagnosis and configuration .94
5.6.1 Use .94
5.6.2 Remote diagnosis of KNXnet/IP devices .95
5.6.3 Configuration and management .95
5.6.4 Data packet structures .96
5.6.5 Certification .101
5.7 Secured communication .101
5.7.1 Use .101
5.7.2 Stack and communication .102
5.7.3 Management procedures .143
5.7.4 Synchronizing timers .146
Annex A (normative) List of codes .148
Annex B (informative) Binary examples of KNXnet/IP frames .155
Annex C (normative) KNXnet/IP parameter object .175
Annex D (normative) Common external messaging interface (cEMI) .178
Annex E (normative) Coupler resources .210
Bibliography .221
iv © ISO 2019 – All rights reserved
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/ patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www .iso .org/
iso/ foreword .html.
This document was prepared by the European Committee for Standardization (CEN) Technical
Committee CEN/TC 247, Building Automation, Controls and Building Management, in collaboration with
ISO Technical Committee TC 205, Building environment design, in accordance with the agreement on
technical cooperation between ISO and CEN (Vienna Agreement).
A list of all parts in the ISO 16484 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
Introduction
This document is intended for the design of new buildings and the retrofit of existing buildings in terms
of acceptable indoor environment, practical energy conservation and efficiency.
KNXnet/IP is a protocol designed to transport KNX home and building electronic system (HBES) control
frames over an IP network. It is used as an infrastructure backbone for connecting KNX sub-networks,
as a communication medium for KNX-IP devices and to provide IP based services for clients (e.g.
connecting a tool software to a KNX installation). The main advantages of using IP for these purposes
are that IP network infrastructure is inexpensive, available almost everywhere and that the distance of
two communication parties on an IP network is virtually unlimited.
Widespread deployment of data networks using the Internet protocol (IP) presents an opportunity to
expand building control communication beyond the local KNX control bus, providing:
— remote configuration;
— remote operation (including control and annunciation);
— fast interface from LAN to KNX and vice versa;
— WAN connection between KNX systems (where an installed KNX system is at least one line);
— an interface to super ordinate building management and energy management systems.
A KNXnet/IP system contains at least these elements:
— one EIB line with up to 64 (255) EIB devices; or
one KNX segment (KNX-TP1, KNX-RF, KNX-PL110);
— a KNX-to-IP network connection device (called KNXnet/IP server); and typically
— additional software for remote functions residing on e.g. a workstation (may be data base application,
BACnet Building Management System, browser, etc.).
KNXnet/IP differentiates between unicast and multicast services. KNXnet/IP unicast services are used
to connect a single client to a single KNXnet/IP server (e.g. KNXnet/IP Tunnelling). KNXnet/IP multicast
services are mainly used to connect different KNX sub-networks using IP communication on the KNX
backbone. The KNXnet/IP routing services are defined for this purpose. KNXnet/IP multicast services
build on top of IP multicast.
Figure 1 — Unicast and multicast in the sense of KNX, KNXnet/IP and IP
Figure 1 shows a typical scenario where a KNXnet/IP client (e.g. running ETS) accesses multiple KNX
installed systems or KNX subnetworks via an IP network. The KNXnet/IP client may access one or more
KNXnet/IP servers at a time. For subnetwork, routing server-to-server communication is possible.
vi © ISO 2019 – All rights reserved
Figure 2 — Device types and configuration examples
Figure 2 shows device types and configuration examples. This document defines the integration
of KNX protocol implementations within the Internet protocol (IP) named KNXnet/IP. It defines a
standard protocol, which is implemented within KNX devices, Engineering Tool Software (ETS) and
other implementations to support KNX data exchange over IP networks. In fact, KNXnet/IP provides
a general framework, which accommodates several specialised “Service Protocols” in a modular and
extendible fashion.
INTERNATIONAL STANDARD ISO 22510:2019(E)
Open data communication in building automation, controls
and building management — Home and building electronic
systems — KNXnet/IP communication
1 Scope
This document defines the integration of KNX protocol implementations on top of Internet protocol
(IP) networks, called KNXnet/IP. It describes a standard protocol for KNX devices connected to an
IP network, called KNXnet/IP devices. The IP network acts as a fast (compared to KNX twisted pair
transmission speed) backbone in KNX installations.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
3.1
backbone key
key used for encryption and message authentication of secure KNXnet/IP multicast communication in a
KNXnet/IP routing multicast group, configured by ETS and a shared secret between all members of the
secure KNXnet/IP routing multicast group
3.2
cipher
generic term that denotes the encrypted data
Note 1 to entry: Cipher is the opposite of plain (3.22).
3.3
common external message interface
generic structure for medium independent KNX (3.14) messages
Note 1 to entry: cEMI (common EMI) frames are used to encapsulate KNX messages within Internet protocol (IP)
packets.
3.4
communication channel
logical connection between a KNXnet/IP client (3.16) and a KNXnet/IP server (3.20) or, in case of routing,
between two or more KNXnet/IP servers
Note 1 to entry: A communication channel consists of one or more connections on the definition of the host
protocol used for KNXnet/IP.
3.5
dynamic host configuration protocol
communication protocol for automatic assignment of IP address settings
3.6
domain name system
assigns Internet names to IP addresses
3.7
engineering tool software
software used to configure KNX (3.14) devices
3.8
european installation bus
predecessor protocol to KNX
Note 1 to entry: Standard for building controls (EN 50090).
3.9
host protocol address information
structure holding the IP host protocol address information used to address a KNXnet/IP endpoint on
another KNXnet/IP device (3.17)
3.10
individual address
unique KNX (3.14) address of a KNX device in a KNX system
3.11
IP channel
logical connection between two IP host/port endpoints
Note 1 to entry: IP channels are either a guaranteed, reliable TCP (transmission control protocol) or an unreliable
point-to-point or multicast (in case of routing) UDP (user datagram protocol) connection.
3.12
Internet control message protocol
extension to the Internet protocol (IP) for error, control, and informational messages
1)
Note 1 to entry: ICMP is defined by RFC 92 and supports packet containing error, control, and informational
messages. The PING command, for example, uses ICMP to test an Internet connection.
3.13
Internet group management protocol
extension to the Internet protocol (IP) for management of IP multicasting in the Internet
Note 1 to entry: IGMP is defined in RFC 1112 as the standard for IP multicasting in the Internet. It is used to
establish host memberships in particular multicast groups on a single network. By using Host Membership
Reports, the mechanisms of the protocol allow a host to inform its local router that it wants to receive messages
addressed to a specific multicast group. All hosts conforming to level 2 of the IP multicasting specification
require IGMP.
3.14
KNX
standard for building controls
Note 1 to entry: See EN 50090, ISO/IEC 14543-3-1 to ISO/IEC 14543-3-7.
1) Request for Comment: Internet standards defined by the Internet Engineering Task Force (IETF) are firstly
published as RFCs.
2 © ISO 2019 – All rights reserved
3.15
KNX node
device implementing a KNX (3.14) protocol stack and fulfilling the requirements according to the KNX
standard
3.16
KNXnet/IP client
application using the KNXnet/IP client protocol to get access to a KNX (3.14) subnetwork over an IP
network channel
3.17
KNXnet/IP device
implementation of KNXnet/IP services on a KNX node (3.15) (KNXnet/IP server (3.20)) or any other
hardware (KNXnet/IP client (3.16))
3.18
KNX/IP domain
all KNXnet/IP devices (3.17) in the same network with the same multicast address and the same
backbone encryption (either no encryption or encryption with the same key)
3.19
KNXnet/IP router
special type of KNXnet/IP device (3.17) that routes KNX (3.14) protocol packets between KNX sub-
networks
3.20
KNXnet/IP server
KNX (3.14) device with physical access to a KNX network implementing the KNXnet/IP server protocol
to communicate with KNXnet/IP clients (3.16) or other KNXnet/IP servers (in case of routing) on an IP
network channel
Note 1 to entry: A KNXnet/IP server is by design always also a KNX node (3.15).
3.21
KNXnet/IP tunnelling
services for point-to-point exchange of KNX (3.14) telegrams over an IP network between a KNXnet/IP
device (3.17) acting as a server and a KNXnet/IP client (3.16)
3.22
plain
generic term that denotes unencrypted data, of which the content depends on the service and the user
and not of confidentiality and authentication
Note 1 to entry: Plain is the opposite of cipher (3.2).
3.23
secure session
authenticated, authorized and encrypted communication channel (3.4) between one KNXnet/IP client
(3.16) and one KNXnet/IP server (3.20) for unicast communication
3.24
session key
key used for encryption and message authentication in a secure session (3.23) between two KNXnet/IP
communication parties, created using ECDH in the secure session setup procedure (providing perfect
forward secrecy) and only valid for this individual session
3.25
subnet
portion of a network that shares a common address component known as the "subnet address"
Note 1 to entry: Different network protocols specify the subnet address in different ways.
3.26
time to live
maximum number of IP routers a multicast UDP/IP datagram may be routed through
Note 1 to entry: Each IP router the datagram passes decrements the TTL by one; the local host adapter also does
this. When the TTL has reached zero, the router discards the datagram. When sending a datagram from the local
host adapter, a TTL of zero means that the datagram never leaves the host. A TTL of one means that the datagram
never leaves the local network (it is not routed).
3.27
transmission control protocol over Internet protocol
connection-oriented communication over the Internet
3.28
user datagram protocol over Internet protocol
connection-less communication over the Internet
4 Abbreviated terms
Abbreviated term Description
AddIL Length of additional information
AES Advanced Encryption Standard
Cn Conditions are specified under note “n”
CBC Cipher Block Chaining
CCM Counter with CBC-MAC
cEMI Common External Message Interface
CTR Counter Mode (of Operation)
DDoS Distributed Denial of Service
DHCP Dynamic Host Configuration Protocol
DNS Domain Name System
DoS Denial of Service
ECDH Elliptic Curve Diffie–Hellman
EIB European Installation Bus
ETS Engineering Tool Software
FDSK Factory Default Setup Key
HPAI Host Protocol Address Information
IA Individual Address
ICMP Internet Control Message Protocol
IGMP Internet Group Management Protocol
IP Internet Protocol
IV Initialisation Vector
M Mandatory
MAC Message Authentication Code
MC Message Code
MiM Man-in-the-Middle
n/a Not applicable
O Optional
PBKDF2 Password-Based Key Derivation Function 2
R Required
SHA Secure Hash Algorithm
4 © ISO 2019 – All rights reserved
Abbreviated term Description
TCP/IP Transmission Control Protocol over Internet Protocol
TTL Time To Live
X Not allowed
UDP/IP User Datagram Protocol over Internet Protocol
5 Requirements
5.1 Overview
5.1.1 KNXnet/IP document parts
5.1.1.1 General
This document defines the integration of KNX protocol implementations within the Internet protocol
(IP) named KNXnet/IP.
This document defines a standard protocol, which is implemented within KNX devices, Engineering
Tool Software and other implementations to support KNX data exchange over IP networks. In fact,
KNXnet/IP provides a general framework, which accommodates several specialised “Service Protocols”
in a modular and extendible fashion.
The KNXnet/IP specification consists of the following parts:
— Overview;
— Core specification;
— Device management;
— Tunnelling;
— Routing;
— Remote diagnosis and configuration;
— Secured communication.
KNXnet/IP supports different software implementations on top of the protocol. More specifically, these
software implementations can be Building Management, Facility Management, Energy Management, or
simply Data Base and SCADA (Supervision, Control and Data Acquisition) packages.
Most of these packages need be configured for the specific user application. In order to simplify this
process and cut costs for engineering, KNXnet/IP provides simple engineering interfaces, namely a
description “language” for the underlying KNX system. This may be done offline, for example generated
as an ETS export file, or online by a mechanism that self-describes the underlying KNX system (reading
data from the system itself).
KNXnet/IP supports:
— on-the-fly change-over between operational modes (configuration, operation);
— event driven mechanisms;
— connections with a delay time greater than t (e.g. network connection via satellite).
KNX_transfer_timeout
5.1.1.2 Overview
"Overview" is this clause.
5.1.1.3 Core specification
“Core specification” defines a standard protocol, which is implemented within KNXnet/IP devices and
the Engineering Tool Software (ETS) to support KNX data exchange over IP networks.
This specific implementation of the protocol over the Internet protocol (IP) is called KNXnet/IP.
This specification addresses:
— definition of data packets sent over the IP host protocol network for KNXnet/IP communication;
— discovery and self-description of KNXnet/IP servers;
— configuration and establishment of a communication channel between a KNXnet/IP client and a
KNXnet/IP server.
5.1.1.4 Device management
“Device management” defines services for remote configuration and remote management of KNXnet/
IP servers.
5.1.1.5 Tunnelling
“Tunnelling” defines services for point-to-point exchange of KNX telegrams over an IP network
between a KNXnet/IP device acting as a server and a KNXnet/IP client. This point-to-point exchange
may be established by a super ordinate system for building automation or management functions or
by an Engineering Tool Software. It supports all ETS functions for download, test, and analysis of KNX
devices on KNX networks connected via KNXnet/IP servers. This includes changes of single KNX device
object properties.
Tunnelling assumes that a data transmission round-trip between ETS or a KNXnet/IP tunnelling client
and KNXnet/IP servers takes less than t .
KNX-transfer_timeouts
5.1.1.6 Routing
“Routing” defines services, which route KNX telegrams between KNXnet/IP servers through the IP
network.
5.1.1.7 Remote diagnosis and configuration
“Remote diagnosis and configuration” defines services for a point-to-point exchange of KNX telegrams
over an IP network between KNXnet/IP routers and/or KNX/IP devices. The services provide means
for diagnosing communication settings and for changing these remotely.
5.1.1.8 Secured communication
“Secured communication” defines services for a secured point-to-point exchange of KNX telegrams
over an IP network between a KNXnet/IP client and a KNX/IP server. The services provide means for
establishing secured communication sessions by authorized KNXnet/IP clients.
5.1.1.9 List of codes
Annex A gives a complete listing of all codes used by KNXnet/IP, to which KNXnet/IP implementations
shall conform, depending on the parts of this document supported.
5.1.1.10 Binary examples
Annex B gives binary examples of KNXnet/IP frames.
6 © ISO 2019 – All rights reserved
5.1.2 Mandatory and optional implementation of IP protocols
5.1.2.1 General
KNXnet/IP uses existing IP protocols where possible unless their use implies an undue burden with
regard to memory and implementation requirements for the intended service.
The following table shows mandatory (M) and optional (O) implementation of IP protocols by KNXnet/
IP service types. Although this table refers to the KNXnet/IP server, it also indicates which IP protocols
shall be implemented by the KNXnet/IP client. Any non-applicable IP protocol is marked as “n/a”.
Table 1 shows KNXnet/IP service types and IP protocols.
Table 1 — KNXnet/IP service types and IP protocols
Service type
Secured
Remote
Device com-
IP protocol Core Tunnelling Routing diagnosis and
management muni-
configuration
cation
ARP M M M M M M
RARP O O O O O O
Support of fixed IP address M M M M M M
BootP (client) M M M M M M
DHCP (client) M M M M M M
UDP M M M M M M
TCP O O O n/a n/a M
ICMP M M M M M M
IGMP M M n/a M O M
It is essential that either BootP or DHCP is implemented by a KNXnet/IP device.
TCP is mandatory for tunnelling v2 required for secured communication.
Other Internet protocols like NTP (network time protocol), FTP (file transfer protocol), HTTP
(hypertext transfer protocol), SMTP (simple message transfer protocol), DNS (domain name system),
and SNMP (simple network management protocol) may be used but are not within the scope of the
KNXnet/IP protocol.
5.1.2.2 Minimum KNXnet/IP device requirements
KNXnet/IP service types as defined in this document require the implementation of a minimal set of IP
protocols for interworking.
KNXnet/IP servers shall implement these IP protocols: ARP, BootP, UDP, ICMP and IGMP. Other IP
protocols may be required for specific services.
A KNXnet/IP client shall not assume that a KNXnet/IP server supports KNXnet/IP frames with a total
length of more than 508.
5.1.2.3 Network environment
Because KNXnet/IP servers use IP, this document does not require any specific medium carrying the IP
datagrams.
It is recommended to use a medium, which carries at least twice the bit rate of all KNXnet/IP routers
connected to this medium. For a point-to-point connection, for example PPP, this would be at least
19 200 bit/s; for a network with up to 400 KNXnet/IP servers, this would be at least 8 Mbit/s.
10BaseT is recommended as a minimum for KNXnet/IP servers using Ethernet as physical medium.
5.1.2.4 Addressing
KNXnet/IP servers are typically connected to one KNX subnetwork and to an IP network. Hence,
KNXnet/IP servers have one distinct address for each network they are connected to: one KNX
individual address and one IP address.
Additionally, KNXnet/IP servers are assigned to a KNXnet/IP project-installation using the same IP
multicast address for all KNXnet/IP servers in a KNXnet/IP project-installation.
5.1.2.5 KNXnet/IP device classes
A KNXnet/IP device can be a software implementation running on a PC. Hence, ETS or any other
software implementing KNXnet/IP services is viewed as a KNXnet/IP device.
Definition of KNXnet/IP device classes ensures interoperability between KNXnet/IP devices as well as
a minimum set of supported KNXnet/IP services for a given KNXnet/IP device class.
Table 2 lists mandatory and optional service types for device classes.
Device class A encompasses configuration and system maintenance tools. Except for object server
services, all other KNXnet/IP services shall be implemented. ETS is a member of this device class.
Device class B defines the minimum set of KNXnet/IP services for KNXnet/IP routers.
Device class C defines the minimum set of KNXnet/IP services for any other KNXnet/IP device. Building,
energy and facilities management systems are members of this KNXnet/IP device class. KNXnet/IP
device classes are shown in Table 2.
Table 2 — KNXnet/IP device classes
Service type
Core Device Tunnelling Routing Remote Secured
manage- diagnosis communi-
Device class
ment and con- cation
figuration
A (Configuration and system M M M M M M
maintenance tools)
a a
B (KNXnet/IP router) M M M M O O
C (any other KNXnet/IP device) M M O O O O
a
If secure communication is supported, support of remote diagnosis and configuration is not allowed.
5.2 Core
5.2.1 Use
The "Core" of the KNXnet/IP specification provides a general host protocol-independent framework,
which accommodates several specialised “Service Protocols” in a modular and extendible fashion.
This specification addresses:
— definition of data packets sent over the non-KNX “host protocol” network for KNXnet/IP
communication;
— discovery and self-description of KNXnet/IP servers; and
— configuration, establishment and maintenance of a communication channel between a KNXnet/IP
client and a KNXnet/IP server.
8 © ISO 2019 – All rights reserved
5.2.2 KNXnet/IP frames
5.2.2.1 General definitions
5.2.2.1.1 Data format
The KNXnet/IP frames described within this document are coded binary.
The data structure specifications are always noted in binary format.
5.2.2.1.2 Byte order
For binary structures, if not explicitly stated otherwise, the byte order shall be big endian mode
(Motorola, non-swapped). For plain text formats, the byte order and formatting shall be according to
the related protocol specifications.
5.2.2.1.3 Structures
All KNXnet/IP structures follow a common rule: the first octet is always the length of the complete
structure (as some structures may have fields of variable length, e.g. strings) and the second octet is
always an identifier that specifies the type of the structure. From the third octet on, the structure data
follows. If the amount of data exceeds 252 octets, the length octet shall be FFh and the next two octets
will contain the length as a 16 bit value. Then the structure data starts at the fifth octet.
5.2.2.2 Frame format
The communication between KNXnet/IP devices is based on KNXnet/IP frames. A KNXnet/IP frame
is a data packet sent over the non-KNX network protocol that consists of a header, comparable to the
IP header of an Internet protocol data packet and an optional body of variable length. Figure 3 shows
KNXnet/IP frame binary format.
Figure 3 — KNXnet/IP frame binary format
The type of KNXnet/IP frame is described by a KNXnet/IP service type identifier in the header.
KNXnet/IP services include, but are not limited to, information regarding discovery and description,
communication channel (connection) management and KNX data transfer.
5.2.2.3 Header
5.2.2.3.1 Description
Every KNXnet/IP frame, without any exception, consists at least of the common KNXnet/IP header that
contains information about the protocol version, the header and total packet length and the KNXnet/IP
service type identifier. The KNXnet/IP header may be followed by a KNXnet/IP body, depending on the
KNXnet/IP service.
Timestamp information and frame counters are not included in the common KNXnet/IP frame header
as this information is closely linked with certain KNXnet/IP service types and will therefore be
included in the body of these services as additional information for certain communication channel
types. Figure 4 shows the KNXnet/IP header binary format.
Figure 4 — KNXnet/IP header binary format
5.2.2.3.2 Header length
Although the length of the header is always fixed, it is possible that the size of the header changes with
a new version of the protocol. The header length can be used as an index into the KNXnet/IP frame data
to find the beginning of the KNXnet/IP body.
5.2.2.3.3 Protocol version
The protocol version information states the revision of the KNXnet/IP protocol that the following
KNXnet/IP frame is subject to. It will be stored in binary coded decimal format. The only valid protocol
version at this time is 1.0 (represented as hexadecimal 10h).
5.2.2.3.4 KNXnet/IP service
The KNXnet/IP service type identifier defines the kind of action to be performed and the type of the
data payload contained in the KNXnet/IP body if applicable. The high octet of the KNXnet/IP service
type identifier denotes the service type family and the low octet the actual service type in that family.
For a detailed description of the services, see below.
5.2.2.3.5 Total length
The total length is expressing the total KNXnet/IP frame length in octets. The length includes the
complete KNXnet/IP frame, starting with the header length of the KNXnet/IP header and including the
whole KNXnet/IP body.
5.2.3 Host protocol independence
5.2.3.1 Host protocol
The KNXnet/IP core specification defines the integration of KNX protocol implementations on top of
the Internet protocol (IP). It describes the general and host protocol independent as well as the host
protocol specific parts of the KNXnet/IP communication.
5.2.3.2 Endpoints
KNXnet/IP defines the Host Protocol Address Information (HPAI) structure, which is the combination
of IP address and port number. The HPAI is the data required to send a KNXnet/IP frame to another
device. The KNXnet/IP specification uses the term KNXnet/IP endpoint as a logical view of a HPAI to
address another KNXnet/IP device for certain well-defined purposes.
Every KNXnet/IP device shall support exactly one device related, bidirectional and connectionless
endpoint for discovery if the host protocol requires discovery services. It shall support at least one
bidirectional and connectionless endpoint for controlling and at least one bidirectional and connection-
oriented endpoint for service type related data transmission. Figure 5 shows the KNXnet/IP server
endpoints sample configuration.
10 © ISO 2019 – All rights reserved
Figure 5 — KNXnet/IP server endpoints sample configuration
The control endpoint uniquely addresses one entity inside the KNXnet/IP server device that shall be
capable of providing at least one KNXnet/IP service type.
This entity, called service container, may be connected to a KNX subnetwork. If the KNXnet/IP server
device supports more than one KNX subnetwork connection, it is required that every KNX subnetwork
shall be represented by a different control endpoint. The KNXnet/IP client therefore considers every
service container represented by a control endpoint as one independent entity no matter if they are
implemented in only one or two separate KNXnet/IP server devices.
These KNXnet/IP endpoints present a logical view to the communication of a KNXnet/IP device. The
actual implementation of these endpoints with different host protocols may use transport medium
dependent approaches that differ from this logical view. For example, the bidirectional KNXnet/IP
endpoints could be implemented using two unidirectional channels with the host protocol. Therefore, it
is possible for one KNXnet/IP endpoint to be represented by multiple HPAIs.
5.2.4 Discovery and self description
5.2.4.1 General
Particularly for networks supporting hot-plug, and where even the address assignment may take place
at runtime (e.g. IP address assignment via BootP or DHCP), it is of significant importance to search for
devices within a subnetwork without having the need to retrieve network parameters through a non-
standardised way and manually input them in the client tool to establish a connection. Furthermore, to
get a precise picture of the services supported by the KNXnet/IP server without implementing trial and
error, a self-description mechanism is an important feature.
5.2.4.2 Discovery
Any KNXnet/IP server shall implement discovery according to this procedure. If applicable for the host
protocol, it is recommended that a KNXnet/IP client implementation supports searching for KNXnet/IP
servers instead of requiring manual input.
The discovery operation consists of a SEARCH_REQUEST data packet, sent via multicast using the
discovery endpoint, which contains the HPAI of the KNXnet/IP client’s discovery endpoint. The HPAI
may contain a unicast IP address to receive the answers from the different KNXnet/IP servers directly
in a point-to-point manner. Typically, it should contain the KNXnet/IP system setup multicast address
to ensure reception from KNXnet/IP servers that are on a different subnetwork. Figure 6 shows the
discovery procedure.
Figure 6 — Discovery procedure
After sending the request, the KNXnet/IP client shall wait for time SEARCH_TIMEOUT for SEARCH_
RESPONSE frames from KNXnet/IP servers. After that period of time, any received SEARCH_RESPONSE
frame shall be ignored by that client until it starts another discovery cycle. SEARCH_REQUEST frames
received by clients from other clients shall be ignored.
Any KNXnet/IP server receiving a SEARCH_REQUEST service shall respond immediately with a
SEARCH_RESPONSE data packet to the given HPAI using its discovery endpoint. Such a response
contains only the HPAI of the KNXnet/IP server’s control endpoint for all further communication.
Any KNXnet/IP server shall support discovery by processing search requests and sending correct
responses. A KNXnet/IP server may support links to more than one KNX subnetwork, it shall however
send a SEARCH_RESPONSE data packet for the control endpoint of each KNX subnetwork it supports
connections to, even if it supports only one data connection at a time.
5.2.4.3 Self-description
Typically, after discovering a KNXnet/IP server, the KNXnet/IP client sends a DESCRIPTION_REQUEST
through a unicast or point-to-point connection to all control endpoints of the KNXnet/IP server. It is
REQUIRED that every KNXnet/IP implementation supports description requests. Furthermore, before
a KNXnet/IP client communicates with a KNXnet/IP server, it should check if the server supports the
services requested by the client using the self-description mechanism.
If a KNXnet/IP server receives a valid description request, it shall reply with a DESCRIPTION_RESPONSE
packet providing information on the supported protocol version range, its own capabilities, state
information and optionally a friendly name for this KNXnet/IP server’s KNX connection. As a KNXnet/
IP server may support links to more than one KNX subnetwork, it shall support responding to discovery
requests for each potential KNX subnetwork connection announced by the discove
...
Norme
internationale
ISO 22510
Première édition
Communication de données
2019-11
ouverte dans l'automatisation,
les contrôles et la gestion du
bâtiment — Systèmes électroniques
de la maison et du bâtiment —
Communication KNXnet/IP
Open data communication in building automation, controls and
building management — Home and building electronic systems
— KNXnet/IP communication
Numéro de référence
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2019
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii
Sommaire Page
Avant-propos .v
Introduction .vi
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Termes abrégés . 4
5 Exigences . 5
5.1 Vue d'ensemble .5
5.1.1 Pièces du document KNXnet/IP.5
5.1.2 Implémentation obligatoire et facultative des protocoles IP . .7
5.2 Noyau .8
5.2.1 Usage .8
5.2.2 Trames KNXnet/IP .9
5.2.3 Indépendance vis-à-vis du protocole de l'hôte .10
5.2.4 Découverte et auto-description .11
5.2.5 Canaux de communication . 13
5.2.6 Directives générales d’implémentation .16
5.2.7 Structures des paquets de données .19
5.2.8 IP Networks . 39
5.2.9 Services minimums supportés . 48
5.3 Spécification de la gestion des dispositifs . 49
5.3.1 Utilisation . 49
5.3.2 Gestion des dispositifs KNXnet/IP . 49
5.3.3 Règles et directives d’implémentation . 60
5.3.4 Structures de paquets de données .61
5.3.5 Profils minimums . 64
5.4 Tunnelling . 65
5.4.1 Utilisation . 65
5.4.2 Tunnelling des télégrammes KNX . 65
5.4.3 Configuration et gestion . 69
5.4.4 Structures d'encadrement .71
5.4.5 Profils minimums . 79
5.5 Routage. 79
5.5.1 Utilisez . 79
5.5.2 Routage KNXnet/IP des télégrammes KNX . . 79
5.5.3 Règles et directives d’implémentation . 90
5.5.4 Configuration et gestion . 92
5.5.5 Structures de paquets de données . 93
5.5.6 Profils minimums . 95
5.6 Diagnostic et configuration à distance . 96
5.6.1 Utilisez . 96
5.6.2 Diagnostic à distance des appareils KNXnet/IP . . 96
5.6.3 Configuration et gestion . 97
5.6.4 Structures de paquets de données . 97
5.6.5 Certification . 103
5.7 Communication sécurisée . 103
5.7.1 Usage . 103
5.7.2 Pile et communication . 104
5.7.3 Procédures de gestion . 150
5.7.4 Synchronisation des minuteries . 152
Annexe A (normative) Liste des codes .155
Annexe B (normative) Exemples binaires de trames KNXnet/IP .163
iii
Annexe C (normative) Objet du paramètre KNXnet/IP .182
Annexe D (normative) Interface de messagerie externe commune (cEMI) .185
Annexe E (normative) Ressources du coupleur .217
Bibliographie .229
iv
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale de comités nationaux
de normalisation (comités membres de l'ISO). Les travaux d'élaboration des Normes internationales sont
normalement réalisés par les comités techniques de l'ISO. Chaque comité membre intéressé par un sujet
pour lequel un comité technique a été créé a le droit d'être représenté au sein de ce comité. Des organisations
internationales, gouvernementales et non gouvernementales, en liaison avec l'ISO, prennent également part
aux travaux. L'ISO collabore étroitement avec la Commission électrotechnique internationale (CEI) sur
toutes les questions de normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour ultérieure
sont décrites dans les Directives ISO/CEI, Partie 1. En particulier, il convient de noter les différents critères
d'approbation nécessaires pour les différents types de documents ISO. Le présent document a été rédigé
conformément aux règles éditoriales des Directives ISO/CEI, Partie 2 (voir www.iso.org/directives).
L'attention est attirée sur la possibilité que certains des éléments du présent document puissent faire l'objet
de droits de brevet. L'ISO ne peut être tenue responsable de l'identification de l'un ou de tous ces droits de
brevet. Les détails de tout droit de brevet identifié au cours de l'élaboration du document figureront dans
l'introduction et/ou sur la liste ISO des déclarations de brevet reçues (voir www.iso.org/patents).
Tout nom commercial utilisé dans ce document est une information donnée pour la commodité des
utilisateurs et ne constitue pas une approbation.
Pour une explication de la nature volontaire des normes, de la signification des termes et expressions
spécifiques de l'ISO liés à l'évaluation de la conformité, ainsi que des informations sur l'adhésion de l'ISO
aux principes de l'Organisation mondiale du commerce (OMC) dans le domaine des obstacles techniques au
commerce (OTC), voir www.iso.org/iso/foreword.html.
Le présent document a été préparé par le Comité technique du Comité européen de normalisation (CEN)
CEN/TC 247, Automatisation, régulation et gestion technique du bâtiment, en collaboration avec le Comité
technique ISO TC 205, Conception de l’environnement intérieur des bâtiments, conformément à l'accord de
coopération technique entre l'ISO et le CEN (Accord de Vienne).
Une liste de toutes les pièces de la série ISO 16484 est disponible sur le site web de l'ISO.
Tout commentaire ou question sur ce document doit être adressé à l'organisme national de normalisation de
l'utilisateur. Une liste complète de ces organismes peut être consultée à l'adresse www.iso.org/members.html.
v
Introduction
Ce document est destiné à la conception de nouveaux bâtiments et à la rénovation de bâtiments existants en
termes d'environnement intérieur acceptable, d'économie d'énergie pratique et d'efficacité.
KNXnet/IP est un protocole conçu pour transporter les trames de contrôle des systèmes électroniques
pour la maison et le bâtiment (HBES) de KNX sur un réseau IP. Il est utilisé comme colonne vertébrale de
l'infrastructure pour connecter les sous-réseaux KNX, comme moyen de communication pour les dispositifs
KNX-IP et pour fournir des services basés sur IP aux clients (par exemple, connecter un logiciel d'outils à une
installation KNX). Les avantages principaux d'employer l'IP pour ces buts sont que l'infrastructure de réseau
d'IP est peu coûteuse, disponible presque partout et que la distance de deux parties de communication sur
un réseau d'IP est pratiquement illimitée.
Le déploiement généralisé des réseaux de données utilisant le protocole Internet (IP) offre la possibilité
d'étendre la communication de contrôle des bâtiments au-delà du bus de contrôle local KNX, en fournissant:
— Une configuration à distance;
— Une utilisation à distance (y compris la commande et l'annonce);
— Une interface rapide de LAN à KNX et vice versa;
— Une connexion WAN entre les systèmes KNX (où un système KNX installé est au moins une ligne);
— Une interface pour les systèmes super ordonnés de gestion des bâtiments et de gestion de l'énergie.
Un système KNXnet/IP contient au moins ces éléments:
— Une ligne EIB avec jusqu'à 64 (255) dispositifs EIB; ou
un segment KNX (KNX-TP1, KNX-RF, KNX-PL110);
— Un dispositif de connexion au réseau KNX-to-IP (appelé serveur KNXnet/IP); et généralement
— Un logiciel supplémentaire pour les fonctions à distance résidant par exemple sur un poste de travail (il
peut s'agir d'une application de base de données, d'un système de gestion des bâtiments BACnet, d'un
navigateur, etc.)
KNXnet/IP différencie les services unicast et multicast. Les services unicast KNXnet/IP sont utilisés pour
connecter un seul client à un seul serveur KNXnet/IP (par exemple KNXnet/IP Tunnelling). Les services
de multidiffusion KNXnet/IP sont principalement utilisés pour connecter différents sous-réseaux KNX en
utilisant la communication IP sur le backbone KNX. Les services de routage KNXnet/IP sont définis dans ce
but. Les services de multidiffusion KNXnet/IP sont basés sur la multidiffusion IP.
Figure 1 — Unicast et multicast au sens de KNX, KNXnet/IP et IP
La Figure 1 montre un scénario typique où un client KNXnet/IP (par exemple, exécutant ETS) accède à
plusieurs systèmes installés KNX ou sous-réseaux KNX via un réseau IP. Le client KNXnet/IP peut accéder à
un ou plusieurs serveurs KNXnet/IP à la fois. Pour les sous-réseaux, la communication de serveur à serveur
de routage est possible.
vi
Figure 2 — Types de dispositifs et exemples de configuration
La Figure 2 montre les types de dispositifs et les exemples de configuration. Ce document définit l'intégration
des implémentations du protocole KNX dans le protocole Internet (IP) nommé KNXnet/IP. Il définit un
protocole standard, qui est implémenté dans les dispositifs KNX, le logiciel d'outil d'ingénierie (ETS) et
d'autres implémentations pour soutenir l'échange de données KNX sur les réseaux IP. En fait, KNXnet/IP
fournit un cadre général, qui accueille plusieurs “protocoles de service” spécialisés d'une manière modulaire
et extensible.
vii
Norme internationale ISO 22510:2019(fr)
Communication de données ouverte dans l'automatisation,
les contrôles et la gestion du bâtiment — Systèmes
électroniques de la maison et du bâtiment — Communication
KNXnet/IP
1 Domaine d’application
Ce document définit l'intégration des implémentations du protocole KNX sur les réseaux de protocole
Internet (IP), appelés KNXnet/IP. Il décrit un protocole standard pour les dispositifs KNX connectés à un
réseau IP, appelés dispositifs KNXnet/IP. Le réseau IP agit comme une dorsale rapide (comparée à la vitesse
de transmission de la paire torsadée KNX) dans les installations KNX.
2 Références normatives
Il n'y a pas de références normatives dans ce document.
3 Termes et définitions
Aux fins du présent document, les termes et définitions suivants s'appliquent.
L'ISO et la CEI maintiennent des bases de données terminologiques à utiliser en normalisation aux adresses
suivantes:
— ISO Plate-forme de navigation en ligne: disponible sur https:// www .iso .org/ obp.
— CEI Electropedia: disponible à l'adresse https:// www .electropedia .org/ .
3.1
clé de voûte
clé utilisée pour le cryptage et l'authentification des messages de la communication multidestinataire
KNXnet/IP sécurisée dans un groupe multidestinataire de routage KNXnet/IP, configurée par l'ETS et un
secret partagé entre tous les membres du groupe multidestinataire de routage KNXnet/IP sécurisé
3.2
Chiffre
terme générique qui désigne les données cryptées
Note 1 à l'article: Cipher est le contraire de plain (3.22).
3.3
interface commune de messages externes
structure générique pour les messages KNX indépendants du support (3.14)
Note 1 à l'article: les trames cEMI (common EMI) sont utilisées pour encapsuler les messages KNX dans des paquets de
protocole Internet (IP).
3.4
canal de communication
connexion logique entre un client KNXnet/IP (3.16) et un serveur KNXnet/IP (3.20) ou, en cas de routage,
entre deux ou plusieurs serveurs KNXnet/IP
Note 1 à l'article: Un canal de communication est constitué d'une ou plusieurs connexions sur la définition du protocole
hôte utilisé pour KNXnet/IP.
3.5
protocole de configuration dynamique des hôtes
protocole de communication pour l'attribution automatique des paramètres de l'adresse IP
3.6
système de nom de domaine
attribue les noms Internet aux adresses IP
3.7
logiciels d'outils d'ingénierie
logiciel utilisé pour configurer les dispositifs KNX (3.14)
3.8
bus d'installation européen
protocole prédécesseur de KNX
Note 1 à l'article: Norme pour les contrôles de bâtiments (EN 50090).
3.9
informations sur l'adresse du protocole hôte
structure contenant l'information de l'adresse du protocole hôte IP utilisée pour adresser un point
d'extrémité KNXnet/IP sur un autre dispositif KNXnet/IP (3.17)
3.10
adresse individuelle
adresse KNX unique (3.14) d'un dispositif KNX dans un système KNX
3.11
Canal IP
connexion logique entre deux points d'extrémité hôte/port IP
Note 1 à l'article: Les canaux IP sont soit une connexion TCP (transmission control protocol) garantie et fiable, soit une
connexion UDP (user datagram protocol) point à point ou multicast (en cas de routage) non fiable.
3.12
Protocole de messages de contrôle Internet
extension au protocole Internet (IP) pour les messages d'erreur, de contrôle et d'information
1)
Note 1 à l'article: ICMP est défini par la RFC 92 et prend en charge les paquets contenant des messages d'erreur, de
contrôle et d'information. La commande PING, par exemple, utilise ICMP pour tester une connexion Internet.
3.13
Protocole de gestion des groupes Internet
extension du protocole Internet (IP) pour la gestion de la multidiffusion IP sur Internet
Note 1 à l'article: IGMP est défini dans la RFC 1112 comme la norme pour la multidiffusion IP sur Internet. Il est utilisé
pour établir l'appartenance des hôtes à des groupes de multidiffusion particuliers sur un même réseau. En utilisant les
rapports d'adhésion des hôtes, les mécanismes du protocole permettent à un hôte d'informer son routeur local qu'il
souhaite recevoir des messages adressés à un groupe de multidiffusion spécifique. Tous les hôtes conformes au niveau
2 de la spécification de multidiffusion IP ont besoin d'IGMP.
3.14
KNX
norme pour les contrôles de bâtiments
Note 1 à l'article: Voir EN 50090, ISO/IEC 14543-3-1 à ISO/IEC 14543-3-7.
3.15
Nœud KNX
dispositif mettant en œuvre une pile de protocoles KNX (3.14) et répondant aux exigences de la norme KNX
1) Demande de commentaires : Les normes Internet définies par l'Internet Engineering Task Force (IETF) sont d'abord
publiées sous forme de RFC.
3.16
Client KNXnet/IP
application utilisant le protocole client KNXnet/IP pour obtenir l'accès à un sous-réseau KNX (3.14) sur un
canal de réseau IP
3.17
Dispositif KNXnet/IP
implémentation des services KNXnet/IP sur un nœud KNX (3.15) (serveur KNXnet/IP (3.20)) ou tout autre
matériel (client KNXnet/IP (3.16))
3.18
Domaine KNX/IP
tous les appareils KNXnet/IP (3.17) du même réseau avec la même adresse multicast et le même cryptage
dorsal (pas de cryptage ou cryptage avec la même clé)
3.19
Routeur KNXnet/IP
type spécial de dispositif KNXnet/IP (3.17) qui achemine les paquets de protocole KNX (3.14) entre les sous-
réseaux KNX
3.20
Serveur KNXnet/IP
Dispositif KNX (3.14) avec accès physique à un réseau KNX mettant en œuvre le protocole de serveur
KNXnet/IP pour communiquer avec des clients KNXnet/IP (3.16) ou d'autres serveurs KNXnet/IP (en cas de
routage) sur un canal de réseau IP
Note 1 à l'article: Un serveur KNXnet/IP est par conception toujours aussi un nœud KNX (3.15).
3.21
Tunnelling (Encapsulation) KNXnet/IP
services pour l'échange point à point de télégrammes KNX (3.14) sur un réseau IP entre un dispositif KNXnet/
IP (3.17) agissant comme un serveur et un client KNXnet/IP (3.16)
3.22
plain
terme générique qui désigne des données non cryptées, dont le contenu dépend du service et de l'utilisateur
et non de la confidentialité et de l'authentification
Note 1 à l'article: Plain est le contraire de cipher (3.2).
3.23
session sécurisée
canal de communication authentifié, autorisé et crypté (3.4) entre un client KNXnet/IP (3.16) et un serveur
KNXnet/IP (3.20) pour une communication unicast
3.24
clé de session
clé utilisée pour le cryptage et l'authentification des messages dans une session sécurisée (3.23) entre deux
parties à la communication KNXnet/IP, créée à l'aide de l'ECDH dans la procédure d'établissement de la
session sécurisée (assurant un secret parfait) et uniquement valable pour cette session individuelle
3.25
sous-réseau
partie d'un réseau qui partage un composant d'adresse commun appelé “adresse de sous-réseau”
Note 1 à l'article: Les différents protocoles réseau spécifient l'adresse de sous-réseau de différentes manières.
3.26
Durée de vie
nombre maximal de routeurs IP par lesquels un datagramme UDP/IP multicast peut être acheminé
Note 1 à l'article: Chaque routeur IP que le datagramme traverse décrémente le TTL d'une unité; l'adaptateur hôte
local le fait également. Lorsque le TTL atteint zéro, le routeur rejette le datagramme. Lors de l'envoi d'un datagramme
depuis l'adaptateur hôte local, un TTL de zéro signifie que le datagramme ne quitte jamais l'hôte. Un TTL de un signifie
que le datagramme ne quitte jamais le réseau local (il n'est pas acheminé).
3.27
protocole de contrôle de la transmission sur le protocole Internet
communication orientée connexion sur Internet
3.28
protocole de datagramme utilisateur sur le protocole Internet
communication sans connexion sur Internet
4 Termes abrégés
Terme abrégé Description
AddIL Longueur de l'information supplémentaire
AES Norme de cryptage avancée
Cn Les conditions sont précisées dans la note “n”.
CBC Chaîne de blocs de chiffrement
CCM Compteur avec CBC-MAC
cEMI Interface commune de messages externes
CTR Mode compteur (de fonctionnement)
DDoS Déni de service distribué
DHCP Protocole de configuration dynamique des hôtes
DNS Système de nom de domaine
DoS Déni de service
ECDH Courbe Elliptique Diffie-Hellman
BEI Bus d'installation européen
ETS Logiciels d'outils d'ingénierie
FDSK Touche de configuration par défaut
IAHP Informations sur l'adresse du protocole de l'hôte
IA Adresse individuelle
ICMP Protocole de messages de contrôle Internet
IGMP Protocole de gestion de groupe Internet
IP Protocole Internet
IV Vecteur d'initialisation
M Obligatoire
MAC Code d'authentification du message
MC Code du message
MiM Man-in-the-Middle
s/o Non applicable
O En option
PBKDF2 Fonction de dérivation de clés basée sur un mot de passe 2
R Requis
SHA Algorithme de hachage sécurisé
Terme abrégé Description
TCP/IP Protocole de contrôle de transmission sur le protocole Internet
TTL Le durée de vie
X Non autorisé
UDP/IP Protocole de datagramme utilisateur sur le protocole Internet
5 Exigences
5.1 Vue d'ensemble
5.1.1 Pièces du document KNXnet/IP
5.1.1.1 Général
Ce document définit l'intégration des implémentations du protocole KNX dans le protocole Internet (IP)
nommé KNXnet/IP.
Ce document définit un protocole standard, qui est implémenté dans les dispositifs KNX, le logiciel d'outil
d'ingénierie et d'autres implémentations pour soutenir l'échange de données KNX sur des réseaux IP. En
fait, KNXnet/IP fournit un cadre général, qui accueille plusieurs "protocoles de service" spécialisés d'une
manière modulaire et extensible.
La spécification KNXnet/IP se compose des parties suivantes:
— Visualisation;
— Spécification de base;
— Gestion des périphériques;
— Tunnelling (Encapsulation);
— Routage;
— Diagnostic et configuration à distance ;
— Communication sécurisée.
KNXnet/IP supporte différentes implémentations logicielles sur le protocole. Plus précisément, ces
implémentations logicielles peuvent être des logiciels de gestion de bâtiments, de gestion d'installations, de
gestion de l'énergie, ou simplement des bases de données et des progiciels SCADA (supervision, contrôle et
acquisition de données).
La plupart de ces paquets doivent être configurés pour l'application spécifique de l'utilisateur. Afin de
simplifier ce processus et de réduire les coûts d'ingénierie, KNXnet/IP fournit des interfaces d'ingénierie
simples, à savoir un "langage" de description pour le système KNX sous-jacent. Cela peut être fait hors ligne,
par exemple généré comme un fichier d'exportation ETS, ou en ligne par un mécanisme qui auto-décrit le
système KNX sous-jacent (en lisant les données du système lui-même).
Supports KNXnet/IP:
— changement à la volée entre les modes opérationnels (configuration, exploitation);
— des mécanismes basés sur les événements;
— connexions dont le délai d'attente est supérieur à tKNX_transfer_timeout (par exemple, connexion réseau
par satellite).
5.1.1.2 Vue d'ensemble
La "vue d'ensemble" est cette clause.
5.1.1.3 Spécification de base
La "spécification de base" définit un protocole standard, qui est mis en œuvre dans les dispositifs KNXnet/
IP et le logiciel d'outil d'ingénierie (ETS) pour soutenir l'échange de données KNX sur les réseaux IP.
Cette implémentation spécifique du protocole sur le protocole Internet (IP) est appelée KNXnet/IP.
Cette spécification porte sur:
— définition des paquets de données envoyés sur le réseau du protocole hôte IP pour la communication
KNXnet/IP;
— découverte et auto-description des serveurs KNXnet/IP;
— configuration et établissement d'un canal de communication entre un client KNXnet/IP et un serveur
KNXnet/IP.
5.1.1.4 Gestion des dispositifs
"Gestion des appareils" définit les services de configuration et de gestion à distance des serveurs KNXnet/IP.
5.1.1.5 Tunnelling (Encapsulation)
"Tunnelling" définit des services pour l'échange point à point de télégrammes KNX sur un réseau IP entre un
dispositif KNXnet/IP agissant comme un serveur et un client KNXnet/IP. Cet échange point à point peut être
établi par un système super ordonné pour l'automatisation du bâtiment ou des fonctions de gestion ou par
un logiciel d'outil d'ingénierie. Il supporte toutes les fonctions ETS pour le téléchargement, le test et l'analyse
des dispositifs KNX sur les réseaux KNX connectés via des serveurs KNXnet/IP. Cela inclut les modifications
des propriétés d'un seul objet de dispositif KNX.
Le tunnelling suppose qu'un aller-retour de transmission de données entre l'ETS ou un client de tunnelling
KNXnet/IP et les serveurs KNXnet/IP prend moins de tKNX-transfer_timeouts.
5.1.1.6 Routage
"Routage" définit les services qui acheminent les télégrammes KNX entre les serveurs KNXnet/IP à travers
le réseau IP.
5.1.1.7 Diagnostic et configuration à distance
"Diagnostic et configuration à distance" définit des services pour un échange point à point de télégrammes
KNX sur un réseau IP entre des routeurs KNXnet/IP et/ou des appareils KNX/IP. Les services fournissent
des moyens pour diagnostiquer les paramètres de communication et pour les modifier à distance.
5.1.1.8 Communication sécurisée
"Communication sécurisée" définit des services pour un échange sécurisé point à point de télégrammes KNX
sur un réseau IP entre un client KNXnet/IP et un serveur KNX/IP. Les services fournissent des moyens pour
établir des sessions de communication sécurisées par des clients KNXnet/IP autorisés.
5.1.1.9 Liste des codes
L'Annexe A donne une liste complète de tous les codes utilisés par KNXnet/IP, auxquels les implémentations
KNXnet/IP doivent se conformer, selon les parties de ce document supportées.
5.1.1.10 Exemples binaires
L'Annexe B donne des exemples binaires de trames KNXnet/IP.
5.1.2 Implémentation obligatoire et facultative des protocoles IP
5.1.2.1 Général
KNXnet/IP utilise les protocoles IP existants dans la mesure du possible, sauf si leur utilisation implique une
charge excessive en termes de mémoire et d'exigences d’implémentation pour le service prévu.
Le tableau suivant montre l'implémentation obligatoire (M) et optionnelle (O) des protocoles IP par les
types de service KNXnet/IP. Bien que ce tableau se réfère au serveur KNXnet/IP, il indique également quels
protocoles IP doivent être implémentés par le client KNXnet/IP. Tout protocole IP non applicable est marqué
comme "n/a". Le Tableau 1 montre les types de service KNXnet/IP et les protocoles IP.
Tableau 1 — Types de services KNXnet/IP et protocoles IP
Type de service
Tunnelling Diagnostic et Com-
Gestion des
Protocole IP Core (Encapsula- Routage configuration à munication
dispositifs
tion) distance garantie
ARP M M M M M M
RARP O O O O O O
Prise en charge de l'adresse
M M M M M M
IP fixe
BootP (client) M M M M M M
DHCP (client) M M M M M M
UDP M M M M M M
TCP O O O s/o s/o M
ICMP M M M M M M
IGMP M M s/o M O M
Il est essentiel que BootP ou DHCP soit implémenté par un dispositif KNXnet/IP.
TCP est obligatoire pour le tunnelling v2 requis pour la communication sécurisée.
D'autres protocoles Internet comme NTP (network time protocol), FTP (file transfer protocol), HTTP
(hypertext transfer protocol), SMTP (simple message transfer protocol), DNS (domain name system),
et SNMP (simple network management protocol) peuvent être utilisés mais ne sont pas dans le cadre du
protocole KNXnet/IP.
5.1.2.2 Exigences minimales pour les appareils KNXnet/IP
Les types de services KNXnet/IP tels que définis dans ce document nécessitent l’implémentation d'un
ensemble minimal de protocoles IP pour l'interfonctionnement.
Les serveurs KNXnet/IP doivent mettre en œuvre ces protocoles IP: ARP, BootP, UDP, ICMP et IGMP. D'autres
protocoles IP peuvent être nécessaires pour des services spécifiques.
Un client KNXnet/IP ne doit pas supposer qu'un serveur KNXnet/IP supporte des trames KNXnet/IP d'une
longueur totale supérieure à 508.
5.1.2.3 Environnement réseau
Comme les serveurs KNXnet/IP utilisent le protocole IP, ce document ne requiert pas de support spécifique
pour transporter les datagrammes IP.
Il est recommandé d'utiliser un support qui transporte au moins deux fois le débit binaire de tous les
routeurs KNXnet/IP connectés à ce support. Pour une connexion point à point, par exemple PPP, ce serait au
moins 19 200 bit/s; pour un réseau avec jusqu'à 400 serveurs KNXnet/IP, ce serait au moins 8 Mbit/s.
10BaseT est recommandé comme un minimum pour les serveurs KNXnet/IP utilisant Ethernet comme
support physique.
5.1.2.4 Adressage
Les serveurs KNXnet/IP sont typiquement connectés à un sous-réseau KNX et à un réseau IP. Par conséquent,
les serveurs KNXnet/IP ont une adresse distincte pour chaque réseau auquel ils sont connectés: une adresse
individuelle KNX et une adresse IP.
En outre, les serveurs KNXnet/IP sont affectés à une installation de projet KNXnet/IP en utilisant la même
adresse IP multicast pour tous les serveurs KNXnet/IP dans une installation de projet KNXnet/IP.
5.1.2.5 Classes de dispositifs KNXnet/IP
Un dispositif KNXnet/IP peut être une implémentation logicielle fonctionnant sur un PC. Par conséquent,
l'ETS ou tout autre logiciel mettant en œuvre des services KNXnet/IP est considéré comme un dispositif
KNXnet/IP.
La définition des classes de dispositifs KNXnet/IP assure l'interopérabilité entre les dispositifs KNXnet/IP ainsi
qu'un ensemble minimum de services KNXnet/IP supportés pour une classe de dispositifs KNXnet/IP donnée.
Le Tableau 2 énumère les types de services obligatoires et facultatifs pour les classes de dispositifs.
La classe de dispositif A englobe les outils de configuration et de maintenance du système. À l'exception des
services du serveur d'objets, tous les autres services KNXnet/IP doivent être mis en œuvre. L'ETS est un
membre de cette classe de dispositif.
La classe d'appareils B définit l'ensemble minimal de services KNXnet/IP pour les routeurs KNXnet/IP.
La classe d'appareils C définit l'ensemble minimal de services KNXnet/IP pour tout autre appareil KNXnet/
IP. Les systèmes de gestion des bâtiments, de l'énergie et des installations font partie de cette classe de
dispositifs KNXnet/IP. Les classes de dispositifs KNXnet/IP sont présentées dans le Tableau 2.
Tableau 2 — Classes d'appareils KNXnet/IP
Type de service
Core Gestion des Tunnelling Routage Diagnostic et Commu-
Classe de dispositif dispositifs configuration nication
à distance sécurisée
A (Outils de configuration et de M M M M M M
maintenance du système)
a a
B (routeur KNXnet/IP) M M M M O O
C (tout autre dispositif KNXnet/IP) M M O O O O
a
Si la communication sécurisée est prise en charge, la prise en charge du diagnostic et de la configuration à distance n'est pas
autorisée.
5.2 Noyau
5.2.1 Usage
Le “noyau” de la spécification KNXnet/IP fournit un cadre général indépendant du protocole hôte, qui
accueille plusieurs “protocoles de service” spécialisés de manière modulaire et extensible.
Cette spécification porte sur:
— définition des paquets de données envoyés sur le réseau non-KNX “protocole hôte” pour la communication
KNXnet/IP;
— découverte et auto-description des serveurs KNXnet/IP; et
— configuration, établissement et maintenance d'un canal de communication entre un client KNXnet/IP et
un serveur KNXnet/IP.
5.2.2 Trames KNXnet/IP
5.2.2.1 Définitions générales
5.2.2.1.1 Format des données
Les trames KNXnet/IP décrites dans ce document sont codées en binaire.
Les spécifications des structures de données sont toujours notées en format binaire.
5.2.2.1.2 Ordre des octets
Pour les structures binaires, sauf indication contraire explicite, l'ordre des octets doit être en mode big
endian (Motorola, non décalé). Pour les formats de texte brut, l'ordre des octets et le formatage doivent être
conformes aux spécifications du protocole correspondant.
5.2.2.1.3 Structures
Toutes les structures KNXnet/IP suivent une règle commune: le premier octet est toujours la longueur de la
structure complète (car certaines structures peuvent avoir des champs de longueur variable, par exemple
des chaînes de caractères) et le deuxième octet est toujours un identifiant qui spécifie le type de la structure.
À partir du troisième octet, les données de la structure suivent. Si la quantité de données dépasse 252 octets,
l'octet de longueur est FFh et les deux octets suivants contiennent la longueur sous la forme d'une valeur de
16 bits. Ensuite, les données de structure commencent au cinquième octet.
5.2.2.2 Format des trames
La communication entre les dispositifs KNXnet/IP est basée sur les trames KNXnet/IP. Une trame KNXnet/IP
est un paquet de données envoyé sur le protocole de réseau non-KNX qui consiste en un en-tête, comparable
à l'en-tête IP d'un paquet de données du protocole Internet et un corps optionnel de longueur variable. La
Figure 3 montre le format binaire de la trame KNXnet/IP.
Figure 3 — Format binaire de la trame KNXnet/IP
Le type de trame KNXnet/IP est décrit par un identifiant de type de service KNXnet/IP dans l'en-tête. Les
services KNXnet/IP incluent, mais ne sont pas limités à, des informations concernant la découverte et la
description, la gestion du canal de communication (connexion) et le transfert de données KNX.
5.2.2.3 En-tête
5.2.2.3.1 Description
Chaque trame KNXnet/IP, sans exception, consiste au moins en un en-tête KNXnet/IP commun qui contient
des informations sur la version du protocole, la longueur de l'en-tête et du paquet total et l'identifiant du type
de service KNXnet/IP. L'en-tête KNXnet/IP peut être suivi d'un corps KNXnet/IP, selon le service KNXnet/IP.
Les informations d'horodatage et les compteurs de trames ne sont pas inclus dans l'en-tête de trame
commune KNXnet/IP car ces informations sont étroitement liées à certains types de services KNXnet/IP et
seront donc incluses dans le corps de ces services comme informations supplémentaires pour certains types
de canaux de communication. La Figure 4 montre le format binaire de l'en-tête KNXnet/IP.
Figure 4 — Format binaire de l'en-tête KNXnet/IP
5.2.2.3.2 Longueur de l'en-tête
Bien que la longueur de l'en-tête soit toujours fixe, il est possible que la taille de l'en-tête change avec une
nouvelle version du protocole. La longueur de l'en-tête peut être utilisée comme un index dans les données
de la trame KNXnet/IP pour trouver le début du corps KNXnet/IP.
5.2.2.3.2.1 Version du protocole
L'information sur la version du protocole indique la révision du protocole KNXnet/IP à laquelle est soumise
la trame KNXnet/IP suivante. Elle est enregistrée au format décimal codé en binaire. La seule version de
protocole valide à l'heure actuelle est la version 1.0 (représentée en hexadécimal 10h).
5.2.2.3.3 Service KNXnet/IP
L'identificateur de type de service KNXnet/IP définit le type d'action à effectuer et le type de données utiles
contenues dans le corps KNXnet/IP, le cas échéant. L'octet supérieur de l'identificateur de type de service
KNXnet/IP indique la famille de type de service et l'octet inférieur le type de service réel dans cette famille.
Pour une description détaillée des services, voir ci-dessous.
5.2.2.3.4 Longueur totale
La longueur totale exprime la longueur totale de la trame KNXnet/IP en octets. La longueur comprend la
trame KNXnet/IP complète, en commençant par la longueur de l'en-tête KNXnet/IP et en incluant tout le
corps KNXnet/IP.
5.2.3 Indépendance vis-à-vis du protocole de l'hôte
5.2.3.1 Protocole de l'hôte
La spécification de base KNXnet/IP définit l'intégration des implémentations de protocole KNX sur le
protocole Internet (IP). Elle décrit les parties générales et indépendantes du protocole hôte ainsi que les
parties spécifiques du protocole hôte de la communication KNXnet/IP.
5.2.3.2 Points finaux
KNXnet/IP définit la structure HPAI (Host Protocol Address Information), qui est la combinaison de
l'adresse IP et du numéro de port. L'HPAI est la donnée requise pour envoyer une trame KNXnet/IP à un
autre dispositif. La spécification KNXnet/IP utilise le terme de point de terminaison KNXnet/IP comme une
vue logique d'une HPAI pour adresser un autre dispositif KNXnet/IP à certaines fins bien définies.
Chaque dispositif KNXnet/IP doit supporter exactement un point d'extrémité bidirectionnel et sans
connexion lié au dispositif pour la découverte si le protocole hôte exige des services de découverte. Il doit
supporter au moins un point d'extrémité bidirectionnel et sans connexion pour le contrôle et au moins un
point d'extrémité bidirectionnel et orienté connexion pour la transmission de données liées au type de
service. La Figure 5 montre un exemple de configuration des points d'extrémité du serveur KNXnet/IP.
Figure 5 — Exemple de configuration des terminaux du serveur KNXnet/IP
Le point final de contrôle adresse de façon unique une entité à l'intérieur du dispositif serveur KNXnet/IP
qui doit être capable de fournir au moins un type de service KNXnet/IP.
Cette entité, appelée conteneur de service, peut être connectée à un sous-réseau KNX. Si le serveur KNXnet/
IP supporte plus d'une connexion à un sous-réseau KNX, il est nécessaire que chaque sous-réseau KNX soit
représenté par un point final de contrôle différent. Le client KNXnet/IP
...
ISO/TC 205/SC
Date : 2019-11
ISO/TC 205/SC /WG
Secrétariat : ANSI
Première édition
2019-11
Date: 2025-05-252025-03-05
Communication de données ouverte dans l'automatisation, les
contrôles et la gestion du bâtiment - — Systèmes électroniques de la
maison et du bâtiment -— Communication KNXnet/IP
Open data communication in building automation, controls and building management — Home and building
electronic systems — KNXnet/IP communication
DOCUMENT PROTÉGÉ PAR LE DROIT D'AUTEUR
Tous droits réservés. Sauf indication contraireprescription différente ou nécessité dans le contexte de sa mise en oeuvre,
aucune partie de cette publication ne peut être reproduite ouni utilisée autrement sous quelque forme ou par quelque
moyen que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie, ou l'affichagela diffusion
sur l'Internetl’internet ou sur un intranet, sans autorisation écrite préalable. CetteUne autorisation peut être demandée
soit à l'ISOl’ISO à l'adressel’adresse ci-dessous, soit après ou au comité membre de l'ISOl’ISO dans le pays du demandeur.
Bureau du droit d'auteur ISO
ISO copyright office
CP 401 • Ch. de Blandonnet 8 - CP 401
CH-1214 Vernier, Genève, SuisseGeneva
Tel. Phone: + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail: copyright@iso.org
Website: www.iso.org
Publié en Suisse
ii
Sommaire Page
Avant-propos . v
Introduction . vi
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Termes abrégés . 4
5 Exigences . 5
5.1 Vue d'ensemble . 5
5.2 Noyau . 9
5.3 Spécification de la gestion des dispositifs . 67
5.4 Tunnelling . 86
5.5 Routage . 107
5.6 Diagnostic et configuration à distance . 130
5.7 Communication sécurisée . 141
Annexe A (normative) Liste des codes . 210
Annexe B (normative) Exemples binaires de trames KNXnet/IP . 218
Annexe C (normative) Objet du paramètre KNXnet/IP . 257
Annexe D (normative) Interface de messagerie externe commune (cEMI) . 261
Annexe E (normative) Ressources du coupleur . 302
Bibliographie . 315
iii
Avant-propos national
Le présent document européen a été initialement rédigé en langue anglaise. Les experts français ont
participé activement aux travaux de sa rédaction, en langue anglaise, et ont voté favorablement pour
l’adoption de ce projet lors de l'enquête CEN.
Les utilisateurs de ce document n’exerçant pas sur le territoire français, tous les codes décrits dans ce
document sont intégrés en anglais et doivent l'être, ceci implique que l'intégration des codes doit se faire
uniquement sur la base de la version anglaise. La version française est utilisée uniquement comme
document support informatif pour les utilisateurs francophones.
iv
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale de comités nationaux de
normalisation (comités membres de l'ISO). Les travaux d'élaboration des Normes internationales sont
normalement réalisés par les comités techniques de l'ISO. Chaque comité membre intéressé par un sujet pour
lequel un comité technique a été créé a le droit d'être représenté au sein de ce comité. Des organisations
internationales, gouvernementales et non gouvernementales, en liaison avec l'ISO, prennent également part
aux travaux. L'ISO collabore étroitement avec la Commission électrotechnique internationale (CEI) sur toutes
les questions de normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour ultérieure sont
décrites dans les Directives ISO/CEI, Partie 1. En particulier, il convient de noter les différents critères
d'approbation nécessaires pour les différents types de documents ISO. Le présent document a été rédigé
conformément aux règles éditoriales des Directives ISO/CEI, Partie 2 (voir www.iso.org/directives 2
(www.iso.org/directives).).
L'attention est attirée sur la possibilité que certains des éléments du présent document puissent faire l'objet
de droits de brevet. L'ISO ne peut être tenue responsable de l'identification de l'un ou de tous ces droits de
brevet. Les détails de tout droit de brevet identifié au cours de l'élaboration du document figureront dans
l'introduction et/ou sur la liste ISO des déclarations de brevet reçues (voir
www.iso.org/patentswww.iso.org/patents).).
Tout nom commercial utilisé dans ce document est une information donnée pour la commodité des
utilisateurs et ne constitue pas une approbation.
Pour une explication de la nature volontaire des normes, de la signification des termes et expressions
spécifiques de l'ISO liés à l'évaluation de la conformité, ainsi que des informations sur l'adhésion de l'ISO aux
principes de l'Organisation mondiale du commerce (OMC) dans le domaine des obstacles techniques au
commerce (OTC), voir www.iso.org/iso/foreword.htmlwww.iso.org/iso/foreword.html.
Le présent document a été préparé par le Comité technique du Comité européen de normalisation (CEN)
CEN/TC 247, Building Automation, Controls and Building Management, en collaboration avec le Comité
technique ISO TC 205, Building environment design, conformément à l'accord de coopération technique entre
l'ISO et le CEN (Accord de Vienne).
Une liste de toutes les pièces de la série ISO 16484 est disponible sur le site web de l'ISO.
Tout commentaire ou question sur ce document doit être adressé à l'organisme national de normalisation de
l'utilisateur. Une liste complète de ces organismes peut être consultée à l'adresse
www.iso.org/members.htmlwww.iso.org/members.html.
v
Introduction
Ce document est destiné à la conception de nouveaux bâtiments et à la rénovation de bâtiments existants en
termes d'environnement intérieur acceptable, d'économie d'énergie pratique et d'efficacité.
KNXnet/IP est un protocole conçu pour transporter les trames de contrôle des systèmes électroniques pour
la maison et le bâtiment (HBES) de KNX sur un réseau IP. Il est utilisé comme colonne vertébrale de
l'infrastructure pour connecter les sous-réseaux KNX, comme moyen de communication pour les dispositifs
KNX-IP et pour fournir des services basés sur IP aux clients (par exemple, connecter un logiciel d'outils à une
installation KNX). Les avantages principaux d'employer l'IP pour ces buts sont que l'infrastructure de réseau
d'IP est peu coûteuse, disponible presque partout et que la distance de deux parties de communication sur un
réseau d'IP est pratiquement illimitée.
Le déploiement généralisé des réseaux de données utilisant le protocole Internet (IP) offre la possibilité
d'étendre la communication de contrôle des bâtiments au-delà du bus de contrôle local KNX, en fournissant:
— Une configuration à distance;
— Une utilisation à distance (y compris la commande et l'annonce) ;);
— Une interface rapide de LAN à KNX et vice versa;
— Une connexion WAN entre les systèmes KNX (où un système KNX installé est au moins une ligne) ;);
— Une interface pour les systèmes super ordonnés de gestion des bâtiments et de gestion de l'énergie.
Un système KNXnet/IP contient au moins ces éléments:
— Une ligne EIB avec jusqu'à 64 (255) dispositifs EIB; ou
un segment KNX (KNX-TP1, KNX-RF, KNX-PL110) ;);
— Un dispositif de connexion au réseau KNX-to-IP (appelé serveur KNXnet/IP) ;); et généralement
— Un logiciel supplémentaire pour les fonctions à distance résidant par exemple sur un poste de travail (il
peut s'agir d'une application de base de données, d'un système de gestion des bâtiments BACnet, d'un
navigateur, etc.)
KNXnet/IP différencie les services unicast et multicast. Les services unicast KNXnet/IP sont utilisés pour
connecter un seul client à un seul serveur KNXnet/IP (par exemple KNXnet/IP Tunnelling). Les services de
multidiffusion KNXnet/IP sont principalement utilisés pour connecter différents sous-réseaux KNX en
utilisant la communication IP sur le backbone KNX. Les services de routage KNXnet/IP sont définis dans ce
but. Les services de multidiffusion KNXnet/IP sont basés sur la multidiffusion IP.
vi
Figure 1 - — Unicast et multicast au sens de KNX, KNXnet/IP et IP
La Figure 1Figure 1 montre un scénario typique où un client KNXnet/IP (par exemple, exécutant ETS) accède
à plusieurs systèmes installés KNX ou sous-réseaux KNX via un réseau IP. Le client KNXnet/IP peut accéder à
un ou plusieurs serveurs KNXnet/IP à la fois. Pour les sous-réseaux, la communication de serveur à serveur
de routage est possible.
vii
Figure 2 - — Types de dispositifs et exemples de configuration
La Figure 2Figure 2 montre les types de dispositifs et les exemples de configuration. Ce document définit
l'intégration des implémentations du protocole KNX dans le protocole Internet (IP) nommé KNXnet/IP. Il
définit un protocole standard, qui est implémenté dans les dispositifs KNX, le logiciel d'outil d'ingénierie (ETS)
et d'autres implémentations pour soutenir l'échange de données KNX sur les réseaux IP. En fait, KNXnet/IP
fournit un cadre général, qui accueille plusieurs "“protocoles de service"” spécialisés d'une manière modulaire
et extensible.
viii
Communication de données ouvertesouverte dans l'automatisation,
les contrôles et la gestion des bâtiments -du bâtiment — Systèmes
électroniques de la maison et du bâtiment -— Communication
KNXnet/IP
1 Domaine d’application
Ce document définit l'intégration des implémentations du protocole KNX sur les réseaux de protocole Internet
(IP), appelés KNXnet/IP. Il décrit un protocole standard pour les dispositifs KNX connectés à un réseau IP,
appelés dispositifs KNXnet/IP. Le réseau IP agit comme une dorsale rapide (comparée à la vitesse de
transmission de la paire torsadée KNX) dans les installations KNX.
2 Références normatives
Il n'y a pas de références normatives dans ce document.
3 Termes et définitions
Aux fins du présent document, les termes et définitions suivants s'appliquent.
L'ISO et la CEI maintiennent des bases de données terminologiques à utiliser en normalisation aux adresses
suivantes:
— ISO Plate-forme de navigation en ligne: disponible sur https://www.iso.org/obp.
— CEI Electropedia: disponible à l'adresse https://www.electropedia.org/.
3.1 3.1
clé de voûte
clé utilisée pour le cryptage et l'authentification des messages de la communication multidestinataire
KNXnet/IP sécurisée dans un groupe multidestinataire de routage KNXnet/IP, configurée par l'ETS et un
secret partagé entre tous les membres du groupe multidestinataire de routage KNXnet/IP sécurisé.
3.2 3.2
Chiffre
terme générique qui désigne les données cryptées
Note 1 à l'entrée : l'article: Cipher est le contraire de plain (3.22(3.22).).
3.3 3.3
interface commune de messages externes
structure générique pour les messages KNX indépendants du support (3.14(3.14))
Note 1 à l'entrée : l'article: les trames cEMI (common EMI) sont utilisées pour encapsuler les messages KNX dans des
paquets de protocole Internet (IP).
3.53.4 3.4
canal de communication
connexion logique entre un client KNXnet/IP (3.16(3.16)) et un serveur KNXnet/IP (3.20(3.20)) ou, en cas de
routage, entre deux ou plusieurs serveurs KNXnet/IP
Note 1 à l'entrée : l'article: Un canal de communication est constitué d'une ou plusieurs connexions sur la définition du
protocole hôte utilisé pour KNXnet/IP.
3.63.5 3.5
protocole de configuration dynamique des hôtes
protocole de communication pour l'attribution automatique des paramètres de l'adresse IP
3.73.6 3.6
système de nom de domaine
attribue les noms Internet aux adresses IP
3.83.7 3.7
logiciels d'outils d'ingénierie
logiciel utilisé pour configurer les dispositifs KNX (3.14(3.14))
3.93.8 3.8
bus d'installation européen
protocole prédécesseur de KNX
Note 1 à l'entrée : l'article: Norme pour les contrôles de bâtiments (EN 50090).
3.103.9 3.9
informations sur l'adresse du protocole hôte
structure contenant l'information de l'adresse du protocole hôte IP utilisée pour adresser un point d'extrémité
KNXnet/IP sur un autre dispositif KNXnet/IP (3.17(3.17))
3.113.10 3.10
adresse individuelle
adresse KNX unique (3.14(3.14)) d'un dispositif KNX dans un système KNX
3.123.11 3.11
Canal IP
connexion logique entre deux points d'extrémité hôte/port IP
Note 1 à l'entrée : l'article: Les canaux IP sont soit une connexion TCP (transmission control protocol) garantie et fiable,
soit une connexion UDP (user datagram protocol) point à point ou multicast (en cas de routage) non fiable.
3.133.12 3.12
Protocole de messages de contrôle Internet
extension au protocole Internet (IP) pour les messages d'erreur, de contrôle et d'information
1)
Note 1 à l'entrée : l'article: ICMP est défini par la RFC 92 et prend en charge les paquets contenant des messages
d'erreur, de contrôle et d'information. La commande PING, par exemple, utilise ICMP pour tester une connexion Internet.
3.143.13 3.13
Protocole de gestion des groupes Internet
extension du protocole Internet (IP) pour la gestion de la multidiffusion IP sur Internet
Note 1 à l'entrée : l'article: IGMP est défini dans la RFC 1112 comme la norme pour la multidiffusion IP sur Internet. Il
est utilisé pour établir l'appartenance des hôtes à des groupes de multidiffusion particuliers sur un même réseau. En
utilisant les rapports d'adhésion des hôtes, les mécanismes du protocole permettent à un hôte d'informer son routeur
local qu'il souhaite recevoir des messages adressés à un groupe de multidiffusion spécifique. Tous les hôtes conformes
au niveau 2 de la spécification de multidiffusion IP ont besoin d'IGMP.
1)
Demande de commentaires : Les normes Internet définies par l'Internet Engineering Task Force (IETF) sont d'abord
publiées sous forme de RFC.
3.153.14 3.14
KNX
norme pour les contrôles de bâtiments
Note 1 à l'entrée : l'article: Voir EN 50090, ISO/IEC 14543-3-1 à ISO/IEC 14543-3-7.
3.163.15 3.15
Nœud KNX
dispositif mettant en œuvre une pile de protocoles KNX (3.14(3.14)) et répondant aux exigences de la norme
KNX
3.173.16 3.16
Client KNXnet/IP
application utilisant le protocole client KNXnet/IP pour obtenir l'accès à un sous-réseau KNX (3.14(3.14)) sur
un canal de réseau IP
3.183.17 3.17
Dispositif KNXnet/IP
implémentation des services KNXnet/IP sur un nœud KNX (3.15(3.15)) (serveur KNXnet/IP (3.20(3.20)))) ou
tout autre matériel (client KNXnet/IP (3.16(3.16)) ))
3.193.18 3.18
Domaine KNX/IP
tous les appareils KNXnet/IP (3.17(3.17)) du même réseau avec la même adresse multicast et le même
cryptage dorsal (pas de cryptage ou cryptage avec la même clé)
3.203.19 3.19
Routeur KNXnet/IP
type spécial de dispositif KNXnet/IP (3.17(3.17)) qui achemine les paquets de protocole KNX (3.14(3.14)) entre
les sous-réseaux KNX.
3.213.20 3.20
Serveur KNXnet/IP
Dispositif KNX (3.14(3.14)) avec accès physique à un réseau KNX mettant en œuvre le protocole de serveur
KNXnet/IP pour communiquer avec des clients KNXnet/IP (3.16(3.16)) ou d'autres serveurs KNXnet/IP (en
cas de routage) sur un canal de réseau IP.
Note 1 à l'entrée : l'article: Un serveur KNXnet/IP est par conception toujours aussi un nœud KNX (3.15(3.15).).
3.223.21 3.21
Tunnelling (Encapsulation) KNXnet/IP
services pour l'échange point à point de télégrammes KNX (3.14(3.14)) sur un réseau IP entre un dispositif
KNXnet/IP (3.17(3.17)) agissant comme un serveur et un client KNXnet/IP (3.16(3.16))
3.243.22 3.22
plain
terme générique qui désigne des données non cryptées, dont le contenu dépend du service et de l'utilisateur
et non de la confidentialité et de l'authentification.
Note 1 à l'entrée : l'article: Plain est le contraire de cipher (3.2(3.2).).
3.253.23 3.23
session sécurisée
canal de communication authentifié, autorisé et crypté (3.4(3.4)) entre un client KNXnet/IP (3.16(3.16)) et un
serveur KNXnet/IP (3.20(3.20)) pour une communication unicast
3.263.24 3.24
clé de session
clé utilisée pour le cryptage et l'authentification des messages dans une session sécurisée (3.23(3.23)) entre
deux parties à la communication KNXnet/IP, créée à l'aide de l'ECDH dans la procédure d'établissement de la
session sécurisée (assurant un secret parfait) et uniquement valable pour cette session individuelle.
3.273.25 3.25
sous-réseau
partie d'un réseau qui partage un composant d'adresse commun appelé "“adresse de sous-réseau".”
Note 1 à l'entrée : l'article: Les différents protocoles réseau spécifient l'adresse de sous-réseau de différentes manières.
3.283.26 3.26
Durée de vie
nombre maximal de routeurs IP par lesquels un datagramme UDP/IP multicast peut être acheminé
Note 1 à l'entrée : l'article: Chaque routeur IP que le datagramme traverse décrémente le TTL d'une unité; l'adaptateur
hôte local le fait également. Lorsque le TTL atteint zéro, le routeur rejette le datagramme. Lors de l'envoi d'un
datagramme depuis l'adaptateur hôte local, un TTL de zéro signifie que le datagramme ne quitte jamais l'hôte. Un TTL de
un signifie que le datagramme ne quitte jamais le réseau local (il n'est pas acheminé).
3.293.27 3.27
protocole de contrôle de la transmission sur le protocole Internet
communication orientée connexion sur Internet
3.303.28 3.28
protocole de datagramme utilisateur sur le protocole Internet
communication sans connexion sur Internet
4 Termes abrégés
Terme abrégé Description
AddIL Longueur de l'information supplémentaire
AES Norme de cryptage avancée
Cn Les conditions sont précisées dans la note "“n".”.
CBC Chaîne de blocs de chiffrement
CCM Compteur avec CBC-MAC
cEMI Interface commune de messages externes
CTR Mode compteur (de fonctionnement)
DDoS Déni de service distribué
DHCP Protocole de configuration dynamique des hôtes
DNS Système de nom de domaine
DoS Déni de service
ECDH Courbe Elliptique Diffie-Hellman
Terme abrégé Description
BEI Bus d'installation européen
ETS Logiciels d'outils d'ingénierie
FDSK Touche de configuration par défaut
IAHP Informations sur l'adresse du protocole de l'hôte
IA Adresse individuelle
ICMP Protocole de messages de contrôle Internet
IGMP Protocole de gestion de groupe Internet
IP Protocole Internet
IV Vecteur d'initialisation
M Obligatoire
MAC Code d'authentification du message
MC Code du message
MiM Man-in-the-Middle
s/o Non applicable
O En option
PBKDF2 Fonction de dérivation de clés basée sur un mot de passe 2
R Requis
SHA Algorithme de hachage sécurisé
TCP/IP Protocole de contrôle de transmission sur le protocole Internet
TTL Le durée de vie
X Non autorisé
UDP/IP Protocole de datagramme utilisateur sur le protocole Internet
5 Exigences
5.1 Vue d'ensemble
5.1.1 Pièces du document KNXnet/IP
5.1.1.1 Général
Ce document définit l'intégration des implémentations du protocole KNX dans le protocole Internet (IP)
nommé KNXnet/IP.
Ce document définit un protocole standard, qui est implémenté dans les dispositifs KNX, le logiciel d'outil
d'ingénierie et d'autres implémentations pour soutenir l'échange de données KNX sur des réseaux IP. En fait,
KNXnet/IP fournit un cadre général, qui accueille plusieurs "protocoles de service" spécialisés d'une manière
modulaire et extensible.
La spécification KNXnet/IP se compose des parties suivantes:
— Visualisation;
— Spécification de base;
— Gestion des périphériques;
— Tunnelling (Encapsulation);
— Routage;
— Diagnostic et configuration à distance ;
— Communication sécurisée.
KNXnet/IP supporte différentes implémentations logicielles sur le protocole. Plus précisément, ces
implémentations logicielles peuvent être des logiciels de gestion de bâtiments, de gestion d'installations, de
gestion de l'énergie, ou simplement des bases de données et des progiciels SCADA (supervision, contrôle et
acquisition de données).
La plupart de ces paquets doivent être configurés pour l'application spécifique de l'utilisateur. Afin de
simplifier ce processus et de réduire les coûts d'ingénierie, KNXnet/IP fournit des interfaces d'ingénierie
simples, à savoir un "langage" de description pour le système KNX sous-jacent. CeciCela peut être fait hors
ligne, par exemple généré comme un fichier d'exportation ETS, ou en ligne par un mécanisme qui auto-décrit
le système KNX sous-jacent (en lisant les données du système lui-même).
Supports KNXnet/IP:
— changement à la volée entre les modes opérationnels (configuration, exploitation) ;);
— des mécanismes basés sur les événements;
— connexions dont le délai d'attente est supérieur à tKNX_transfer_timeout (par exemple, connexion réseau
par satellite).
5.1.1.2 Vue d'ensemble
La "vue d'ensemble" est cette clause.
5.1.1.3 Spécification de base
La "spécification de base" définit un protocole standard, qui est mis en œuvre dans les dispositifs KNXnet/IP
et le logiciel d'outil d'ingénierie (ETS) pour soutenir l'échange de données KNX sur les réseaux IP.
Cette implémentation spécifique du protocole sur le protocole Internet (IP) est appelée KNXnet/IP.
Cette spécification porte sur:
— définition des paquets de données envoyés sur le réseau du protocole hôte IP pour la communication
KNXnet/IP;
— découverte et auto-description des serveurs KNXnet/IP;
— configuration et établissement d'un canal de communication entre un client KNXnet/IP et un serveur
KNXnet/IP.
5.1.1.4 Gestion des dispositifs
"Gestion des appareils" définit les services de configuration et de gestion à distance des serveurs KNXnet/IP.
5.1.1.5 Tunnelling (Encapsulation)
"Tunnelling" définit des services pour l'échange point à point de télégrammes KNX sur un réseau IP entre un
dispositif KNXnet/IP agissant comme un serveur et un client KNXnet/IP. Cet échange point à point peut être
établi par un système super ordonné pour l'automatisation du bâtiment ou des fonctions de gestion ou par un
logiciel d'outil d'ingénierie. Il supporte toutes les fonctions ETS pour le téléchargement, le test et l'analyse des
dispositifs KNX sur les réseaux KNX connectés via des serveurs KNXnet/IP. CeciCela inclut les modifications
des propriétés d'un seul objet de dispositif KNX.
Le tunnelling suppose qu'un aller-retour de transmission de données entre l'ETS ou un client de tunnelling
KNXnet/IP et les serveurs KNXnet/IP prend moins de tKNX-transfer_timeouts.
5.1.1.6 Routage
"Routage" définit les services qui acheminent les télégrammes KNX entre les serveurs KNXnet/IP à travers le
réseau IP.
5.1.1.7 Diagnostic et configuration à distance
"Diagnostic et configuration à distance" définit des services pour un échange point à point de télégrammes
KNX sur un réseau IP entre des routeurs KNXnet/IP et/ou des appareils KNX/IP. Les services fournissent des
moyens pour diagnostiquer les paramètres de communication et pour les modifier à distance.
5.1.1.8 Communication sécurisée
"Communication sécurisée" définit des services pour un échange sécurisé point à point de télégrammes KNX
sur un réseau IP entre un client KNXnet/IP et un serveur KNX/IP. Les services fournissent des moyens pour
établir des sessions de communication sécurisées par des clients KNXnet/IP autorisés.
5.1.1.9 Liste des codes
L'annexe AL'Annexe A donne une liste complète de tous les codes utilisés par KNXnet/IP, auxquels les
implémentations KNXnet/IP doivent se conformer, selon les parties de ce document supportées.
5.1.1.10 Exemples binaires
L'annexe BL'Annexe B donne des exemples binaires de trames KNXnet/IP.
5.1.2 Implémentation obligatoire et facultative des protocoles IP
5.1.2.1 Général
KNXnet/IP utilise les protocoles IP existants dans la mesure du possible, sauf si leur utilisation implique une
charge excessive en termes de mémoire et d'exigences d’implémentation pour le service prévu.
Le tableau suivant montre l'implémentation obligatoire (M) et optionnelle (O) des protocoles IP par les types
de service KNXnet/IP. Bien que ce tableau se réfère au serveur KNXnet/IP, il indique également quels
protocoles IP doivent être implémentés par le client KNXnet/IP. Tout protocole IP non applicable est marqué
comme "n/a". Le Tableau 1Tableau 1 montre les types de service KNXnet/IP et les protocoles IP.
Tableau 1 - — Types de services KNXnet/IP et protocoles IP
Type de service
Tunnelling Diagnostic et Com-
Gestion des Routag
Protocole IP Core (Encapsula configuration municatio
dispositifs e
tion) à distance n garantie
ARP M M M M M M
RARP O O O O O O
Prise en charge de l'adresse
M M M M M M
IP fixe
BootP (client) M M M M M M
DHCP (client) M M M M M M
UDP M M M M M M
TCP O O O s/o s/o M
ICMP M M M M M M
IGMP M M s/o M O M
Il est essentiel que BootP ou DHCP soit implémenté par un dispositif KNXnet/IP.
TCP est obligatoire pour le tunnelling v2 requis pour la communication sécurisée.
D'autres protocoles Internet comme NTP (network time protocol), FTP (file transfer protocol), HTTP
(hypertext transfer protocol), SMTP (simple message transfer protocol), DNS (domain name system), et SNMP
(simple network management protocol) peuvent être utilisés mais ne sont pas dans le cadre du protocole
KNXnet/IP.
5.1.2.2 Exigences minimales pour les appareils KNXnet/IP
Les types de services KNXnet/IP tels que définis dans ce document nécessitent l’implémentation d'un
ensemble minimal de protocoles IP pour l'interfonctionnement.
Les serveurs KNXnet/IP doivent mettre en œuvre ces protocoles IP: ARP, BootP, UDP, ICMP et IGMP. D'autres
protocoles IP peuvent être nécessaires pour des services spécifiques.
Un client KNXnet/IP ne doit pas supposer qu'un serveur KNXnet/IP supporte des trames KNXnet/IP d'une
longueur totale supérieure à 508.
5.1.2.3 Environnement réseau
Comme les serveurs KNXnet/IP utilisent le protocole IP, ce document ne requiert pas de support spécifique
pour transporter les datagrammes IP.
Il est recommandé d'utiliser un support qui transporte au moins deux fois le débit binaire de tous les routeurs
KNXnet/IP connectés à ce support. Pour une connexion point à point, par exemple PPP, ce serait au moins
19 200 bit/s; pour un réseau avec jusqu'à 400 serveurs KNXnet/IP, ce serait au moins 8 Mbit/s.
10BaseT est recommandé comme un minimum pour les serveurs KNXnet/IP utilisant Ethernet comme
support physique.
5.1.2.4 Adressage
Les serveurs KNXnet/IP sont typiquement connectés à un sous-réseau KNX et à un réseau IP. Par conséquent,
les serveurs KNXnet/IP ont une adresse distincte pour chaque réseau auquel ils sont connectés: une adresse
individuelle KNX et une adresse IP.
En outre, les serveurs KNXnet/IP sont affectés à une installation de projet KNXnet/IP en utilisant la même
adresse IP multicast pour tous les serveurs KNXnet/IP dans une installation de projet KNXnet/IP.
5.1.2.5 Classes de dispositifs KNXnet/IP
Un dispositif KNXnet/IP peut être une implémentation logicielle fonctionnant sur un PC. Par conséquent, l'ETS
ou tout autre logiciel mettant en œuvre des services KNXnet/IP est considéré comme un dispositif KNXnet/IP.
La définition des classes de dispositifs KNXnet/IP assure l'interopérabilité entre les dispositifs KNXnet/IP
ainsi qu'un ensemble minimum de services KNXnet/IP supportés pour une classe de dispositifs KNXnet/IP
donnée.
Le Tableau 2Tableau 2 énumère les types de services obligatoires et facultatifs pour les classes de dispositifs.
La classe de dispositif A englobe les outils de configuration et de maintenance du système. À l'exception des
services du serveur d'objets, tous les autres services KNXnet/IP doivent être mis en œuvre. L'ETS est un
membre de cette classe de dispositif.
La classe d'appareils B définit l'ensemble minimal de services KNXnet/IP pour les routeurs KNXnet/IP.
La classe d'appareils C définit l'ensemble minimal de services KNXnet/IP pour tout autre appareil KNXnet/IP.
Les systèmes de gestion des bâtiments, de l'énergie et des installations font partie de cette classe de dispositifs
KNXnet/IP. Les classes de dispositifs KNXnet/IP sont présentées dans le Tableau 2Tableau 2.
Tableau 2 - — Classes d'appareils KNXnet/IP
Type de service
Core Gestion des Tunnellin Routage Diagnostic et Communi
Classe de dispositif dispositifs g configuratio cation
n à distance sécurisée
A (Outils de configuration et de M M M M M M
maintenance du système)
a a
B (routeur KNXnet/IP) M M M M O O
C (tout autre dispositif KNXnet/IP) M M O O O O
a Si la communication sécurisée est prise en charge, la prise en charge du diagnostic et de la configuration à distance n'est pas
autorisée.
5.2 Noyau
5.2.1 Usage
Le "“noyau"” de la spécification KNXnet/IP fournit un cadre général indépendant du protocole hôte, qui
accueille plusieurs "“protocoles de service"” spécialisés de manière modulaire et extensible.
Cette spécification porte sur:
— définition des paquets de données envoyés sur le réseau non-KNX "“protocole hôte"” pour la
communication KNXnet/IP;
— découverte et auto-description des serveurs KNXnet/IP; et
— configuration, établissement et maintenance d'un canal de communication entre un client KNXnet/IP et
un serveur KNXnet/IP.
5.2.2 Trames KNXnet/IP
5.2.2.1 Définitions générales
5.2.2.1.1 Format des données
Les trames KNXnet/IP décrites dans ce document sont codées en binaire.
Les spécifications des structures de données sont toujours notées en format binaire.
5.2.2.1.2 Ordre des octets
Pour les structures binaires, sauf indication contraire explicite, l'ordre des octets doit être en mode big endian
(Motorola, non décalé). Pour les formats de texte brut, l'ordre des octets et le formatage doivent être
conformes aux spécifications du protocole correspondant.
5.2.2.1.3 Structures
Toutes les structures KNXnet/IP suivent une règle commune: le premier octet est toujours la longueur de la
structure complète (car certaines structures peuvent avoir des champs de longueur variable, par exemple des
chaînes de caractères) et le deuxième octet est toujours un identifiant qui spécifie le type de la structure. À
partir du troisième octet, les données de la structure suivent. Si la quantité de données dépasse 252 octets,
l'octet de longueur est FFh et les deux octets suivants contiennent la longueur sous la forme d'une valeur de
16 bits. Ensuite, les données de structure commencent au cinquième octet.
5.2.2.2 Format des trames
La communication entre les dispositifs KNXnet/IP est basée sur les trames KNXnet/IP. Une trame KNXnet/IP
est un paquet de données envoyé sur le protocole de réseau non-KNX qui consiste en un en-tête, comparable
à l'en-tête IP d'un paquet de données du protocole Internet et un corps optionnel de longueur variable. La
Figure 3Figure 3 montre le format binaire de la trame KNXnet/IP.
Figure 3 - — Format binaire de la trame KNXnet/IP
Le type de trame KNXnet/IP est décrit par un identifiant de type de service KNXnet/IP dans l'en-tête. Les
services KNXnet/IP incluent, mais ne sont pas limités à, des informations concernant la découverte et la
description, la gestion du canal de communication (connexion) et le transfert de données KNX.
5.2.2.3 En-tête
5.2.2.3.1 Description
Chaque trame KNXnet/IP, sans exception, consiste au moins en un en-tête KNXnet/IP commun qui contient
des informations sur la version du protocole, la longueur de l'en-tête et du paquet total et l'identifiant du type
de service KNXnet/IP. L'en-tête KNXnet/IP peut être suivi d'un corps KNXnet/IP, selon le service KNXnet/IP.
Les informations d'horodatage et les compteurs de trames ne sont pas inclus dans l'en-tête de trame commune
KNXnet/IP car ces informations sont étroitement liées à certains types de services KNXnet/IP et seront donc
incluses dans le corps de ces services comme informations supplémentaires pour certains types de canaux de
communication. La Figure 4Figure 4 montre le format binaire de l'en-tête KNXnet/IP.
Figure 4 - — Format binaire de l'en-tête KNXnet/IP
5.2.2.3.2 Longueur de l'en-tête
Bien que la longueur de l'en-tête soit toujours fixe, il est possible que la taille de l'en-tête change avec une
nouvelle version du protocole. La longueur de l'en-tête peut être utilisée comme un index dans les données de
la trame KNXnet/IP pour trouver le début du corps KNXnet/IP.
5.2.2.3.2.1 Version du protocole
L'information sur la version du protocole indique la révision du protocole KNXnet/IP à laquelle est soumise
la trame KNXnet/IP suivante. Elle est enregistrée au format décimal codé en binaire. La seule version de
protocole valide à l'heure actuelle est la version 1.0 (représentée en hexadécimal 10h).
5.2.2.3.3 Service KNXnet/IP
L'identificateur de type de service KNXnet/IP définit le type d'action à effectuer et le type de données utiles
contenues dans le corps KNXnet/IP, le cas échéant. L'octet supérieur de l'identificateur de type de service
KNXnet/IP indique la famille de type de service et l'octet inférieur le type de service réel dans cette famille.
Pour une description détaillée des services, voir ci-dessous.
5.2.2.3.4 Longueur totale
La longueur totale exprime la longueur totale de la trame KNXnet/IP en octets. La longueur comprend la trame
KNXnet/IP complète, en commençant par la longueur de l'en-tête KNXnet/IP et en incluant tout le corps
KNXnet/IP.
5.2.3 Indépendance vis-à-vis du protocole de l'hôte
5.2.3.1 Protocole de l'hôte
La spécification de base KNXnet/IP définit l'intégration des implémentations de protocole KNX sur le
protocole Internet (IP). Elle décrit les parties générales et indépendantes du protocole hôte ainsi que les
parties spécifiques du protocole hôte de la communication KNXnet/IP.
5.2.3.2 Points finaux
KNXnet/IP définit la structure HPAI (Host Protocol Address Information), qui est la combinaison de l'adresse
IP et du numéro de port. L'HPAI est la donnée requise pour envoyer une trame KNXnet/IP à un autre dispositif.
La spécification KNXnet/IP utilise le terme de point de terminaison KNXnet/IP comme une vue logique d'une
HPAI pour adresser un autre dispositif KNXnet/IP à certaines fins bien définies.
Chaque dispositif KNXnet/IP doit supporter exactement un point d'extrémité bidirectionnel et sans connexion
lié au dispositif pour la découverte si le protocole hôte exige des services de découverte. Il doit supporter au
moins un point d'extrémité bidirectionnel et sans connexion pour le contrôle et au moins un point d'extrémité
bidirectionnel et orienté connexion pour la transmission de données liées au type de service. La Figure 5Figure
5 montre un exemple de configuration des points d'extrémité du serveur KNXnet/IP.
Figure 5 - — Exemple de configuration des terminaux du serveur KNXnet/IP
Le point final de contrôle adresse de façon unique une entité à l'intérieur du dispositif serveur KNXnet/IP qui
doit être capable de fournir au moins un type de service KNXnet/IP.
Cette entité, appelée conteneur de service, peut être connectée à un sous-réseau KNX. Si le serveur KNXnet/IP
supporte plus d'une connexion à un sous-réseau KNX, il est nécessaire que chaque sous-réseau KNX soit
représenté par un point final de contrôle différent. Le client KNXnet/IP considère donc chaque conteneur de
service représenté par un point de contrôle comme une entité indépendante, peu importe s'il est implémenté
dans un ou deux serveurs KNXnet/IP distincts.
Ces points d'extrémité KNXnet/IP présentent une vue logique de la communication d'un dispositif KNXnet/IP.
L'implémentation réelle de ces points d'extrémité avec différents protocoles hôtes peut utiliser des approches
dépendantes du support de transport qui diffèrent de cette vue logique. Par exemple, les points d'extrémité
bidirectionnels KNXnet/IP pourraient être mis en œuvre en utilisant deux canaux unidirectionnels avec le
protocole hôte. Par conséquent, il est possible qu'un point final KNXnet/IP soit représenté par plusieurs HPAI.
5.2.4 Découverte et auto-description
5.2.4.1 Général
Particulièrement pour les réseaux supportant le hot-plug, et où même l'assignation d'adresse peut avoir lieu
au moment de l'exécution (par exemple l'assignation d'adresse IP par BootP ou DHCP), il est d'importance
significative de rechercher des dispositifs dans un sous-réseau sans avoir le besoin de récupérer des
paramètres de réseau par une manière non standardisée et de les entrer manuellement dans l'outil de client
pour établir une connexion. De plus, pour obtenir une image précise des services supportés par le serveur
KNXnet/IP sans avoir à procéder par essais et erreurs, un mécanisme d'auto-description est une
caractéristique importante.
5.2.4.2 Découverte
Tout serveur KNXnet/IP doit mettre en œuvre la découverte selon cette procédure. Si cela est applicable au
protocole hôte, il est recommandé qu'une implémentation client KNXnet/IP supporte la recherche de serveurs
KNXnet/IP au lieu de nécessiter une entrée manuelle.
L'opération de découverte consiste en un paquet de données SEARCH_REQUEST, envoyé par multicast en
utilisant le point de terminaison de découverte, qui contient le HPAI du point de terminaison de découverte
du client KNXnet/IP. Le HPAI peut contenir une adresse IP unicast pour recevoir les réponses des différents
serveurs KNXnet/IP directement d'une manière point à point. Typiquement, il devrait contenir l'adresse
multicast de configuration du système KNXnet/IP pour assurer la réception des serveurs KNXnet/IP qui sont
sur un sous-réseau différent. La Figure 6Figure 6 montre la procédure de découverte.
Figure 6 - — Procédure de découverte
Après avoir envoyé la demande, le client KNXnet/IP doit attendre pendant le temps SEARCH_TIMEOUT les
trames SEARCH_RESPONSE des serveurs KNXnet/IP. Après cette période, toute trame SEARCH_RESPONSE
reçue doit être ignorée par ce client jusqu'à ce qu'il commence un autre cycle de découverte. Les trames
SEARCH_REQUEST reçues par les clients en provenance d'autres clients doivent être ignorées.
Tout serveur KNXnet/IP recevant un service SEARCH_REQUEST doit répondre immédiatement avec un
paquet de données SEARCH_RESPONSE au HPAI donné en utilisant son endpoint de découverte. Une telle
réponse ne contient que le HPAI du terminal de contrôle du serveur KNXnet/IP pour toute communication
ultérieure.
Tout serveur KNXnet/IP doit supporter la découverte en traitant les demandes de recherche et en envoyant
des réponses correctes. Un serveur KNXnet/IP peut supporter des liens vers plus d'un sous-réseau KNX, il doit
cependant envoyer un paquet de données SEARCH_RESPONSE pour le point final de contrôle de chaque sous-
réseau KNX auquel il supporte des connexions, même s'il ne supporte qu'une seule connexion de données à la
fois.
5.2.4.3 Auto-description
Typiquement, après avoir découvert un serveur KNXnet/IP, le client KNXnet/IP envoie une
DESCRIPTION_REQUEST par une connexion unicast ou point à point à tous les points de contrôle du serveur
KNXnet/IP. Il est OBLIGATOIRE que chaque implémentation KNXnet/IP supporte les requêtes de description.
De plus, avant qu'un client KNXnet/IP ne communique avec un serveur KNXnet/IP, il doit vérifier si le serveur
supporte les services demandés par le client en utilisant le mécanisme d'auto-description.
Si un serveur KNXnet/IP reçoit une demande de description valide, il doit répondre avec un paquet
DESCRIPTION_RESPONSE fournissant des informations sur la gamme de version de protocole supportée, ses
propres capacités, des informations d'état et optionnellement un nom amical pour la connexion KNX de ce
serveur KNXnet/IP. Comme un serveur KNXnet/IP peut supporter des liens vers plus d'un sous-réseau KNX,
il doit répondre aux demandes de découverte pour chaque connexion potentielle de sous-réseau KNX
annoncée par les réponses de découverte.
5.2.5 Canaux de communication
5.2.5.1 Général
Un canal de communication est la connexion d'extrémité de données entre un client KNXnet/IP et un serveur
KNXnet/IP. Les connexions d'extrémité de données sont établies pour les services nécessitant une
c
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...