SIST EN 13321-2:2007
(Main)Open data communication in building automation, controls and building management - Home and building electronic systems - Part 2: KNXnet/IP Communication
Open data communication in building automation, controls and building management - Home and building electronic systems - Part 2: KNXnet/IP Communication
This specification 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 transmission speed) backbone in KNX installations.
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)
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-TP0, KNX-RF, KNX-PL110, KNX-PL132),
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 iETS, data base application, BACnet Building Management System, browser, ...).
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. This document also supersedes parts BatiBUS, EHS and EIB of ENV 13154-1:1998.
Offene Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Elektrische Systemtechnik für Heim und Gebäude - Teil 2: KNXnet/IP Kommunikation
Réseau ouvert de communication de données pour l'automatisation, la régulation et la gestion technique du bâtiment - Systemes électroniques pour les foyers domestiques et les bâtiments - Partie 2 : Communication KNX/IP
Odprta izmenjava podatkov v avtomatizaciji stavb in izvršnih elementov ter pri upravljanju stavb - Elektronski sistemi za stanovanja in stavbe - 2. del: KNTnet/IP
General Information
Relations
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Open data communication in building automation, controls and building management - Home and building electronic systems - Part 2: KNXnet/IP CommunicationOdprta izmenjava podatkov v avtomatizaciji stavb in izvršnih elementov ter pri upravljanju stavb - Elektronski sistemi za stanovanja in stavbe - 2. del: KNTnet/IPRéseau ouvert de communication de données pour l'automatisation, la régulation et la gestion technique du bâtiment - Systemes électroniques pour les foyers domestiques et les bâtiments - Partie 2 : Communication KNX/IPOffene Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Elektrische Systemtechnik für Heim und Gebäude - Teil 2: KNXnet/IP KommunikationTa slovenski standard je istoveten z:EN 13321-2:2006SIST EN 13321-2:2007en97.120Avtomatske krmilne naprave za domAutomatic controls for household use35.240.99IT applications in other fieldsICS:SLOVENSKI
STANDARDSIST EN 13321-2:200701-februar-2007
EUROPEAN STANDARDNORME EUROPÉENNEEUROPÄISCHE NORMEN 13321-2October 2006ICS 35.240.99; 97.120Supersedes ENV 13321-2:2000
English VersionOpen data communication in building automation, controls andbuilding management - Home and building electronic systems -Part 2: KNXnet/IP CommunicationRéseau ouvert de communication de données pourl'automatisation, la régulation et la gestion technique dubâtiment - Systèmes électroniques pour les foyersdomestiques et les bâtiments - Partie 2 : CommunicationKNX/IPOffene Datenkommunikation für die Gebäudeautomationund Gebäudemanagement - Elektrische Systemtechnik fürHeim und Gebäude - Teil 2: KNXnet/IP KommunikationThis European Standard was approved by CEN on 28 August 2006.CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this EuropeanStandard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such nationalstandards may be obtained on application to the Central Secretariat or to any CEN member.This European Standard exists in three official versions (English, French, German). A version in any other language made by translationunder the responsibility of a CEN member into its own language and notified to the Central Secretariat has the same status as the officialversions.CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France,Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania,Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.EUROPEAN COMMITTEE FOR STANDARDIZATIONCOMITÉ EUROPÉEN DE NORMALISATIONEUROPÄISCHES KOMITEE FÜR NORMUNGManagement Centre: rue de Stassart, 36
B-1050 Brussels© 2006 CENAll rights of exploitation in any form and by any means reservedworldwide for CEN national Members.Ref. No. EN 13321-2:2006: E
EN 13321-2:2006 (E) 2 Contents Page Foreword.4 Introduction.5 1 Scope.7 2 Normative references.8 3 Terms and definitions.8 3.1 subnet.8 3.2 Engineering Tool Software (ETS).8 3.3 Host Protocol Address Information (HPAI).8 3.4 communication channel.9 3.5 KNX node.9 3.6 KNXnet/IP server.9 3.7 KNXnet/IP client.9 3.8 KNXnet/IP devices.9 3.9 KNXnet/IP router.9 3.10 Time To Live (TTL).9 3.11 KNXnet/IP Tunneling.9 3.12 Internet Control Message Protocol (ICMP).10 3.13 Internet Group Management Protocol (IGMP).10 3.14 IP channel.10 3.15 communication channel.10 4 Symbols, abbreviations and acronyms.10 4.1 DHCP.10 4.2 DNS.10 4.3 EIB.10 4.4 IP.10 4.5 KNX.11 4.6 TCP/IP.11 4.7 UDP/IP.11 5 Requirements.11 5.1 Clause 1: Overview.11 5.1.1 KNXnet/IP Document Clauses.11 5.1.2 Mandatory and optional implementation of IP protocols.12 5.1.3 Security considerations.14 5.2 Clause 2: Core.16 5.2.1 Scope.16 5.2.2 KNXnet/IP frames.17 5.2.3 Host protocol independence.18 5.2.4 Discovery and self description.20 5.2.5 Communication Channels.21 5.2.6 General implementation guidelines.24 5.2.7 Data Packet structures.28 5.2.8 IP Networks.42 5.2.9 Certification.48 5.3 Clause 3: Device Management Specification.49 5.3.1 Scope.49 5.3.2 KNXnet/IP Device Management.49 5.3.3 Implementation rules and guidelines.60 5.3.4 Data packet structures.62 5.3.5 Certification.64
EN 13321-2:2006 (E) 3 5.3.6 Clause 4: Tunneling.65 5.3.7 Tunneling of KNX telegrams.66 5.3.8 Configuration and Management.70 5.3.9 Data packet structures.70 5.3.10 Certification.73 5.4 Clause 5: Routing.73 5.4.1 Scope.73 5.4.2 KNXnet/IP Routing of KNX telegrams.74 5.4.3 Implementation rules and guidelines.79 5.4.4 Configuration and Management.81 5.4.5 Data packet structures.82 5.4.6 Certification.83 Annex A (normative) List of codes.85 A.1 Common constants.85 A.2 KNXnet/IP services.85 A.2.1 Service type number ranges.85 A.2.2 Core KNXnet/IP services.86 A.2.3 Device Management services.86 A.2.4 Tunneling services.87 A.2.5 Routing services.87 A.2.6 Remote Logging services.87 A.2.7 Remote Configuration and Diagnosis.87 A.2.8 Object Server services.87 A.3 Connection types.87 A.4 Error codes.88 A.4.1 Common error codes.88 A.4.2 CONNECT RESPONSE status codes.88 A.4.3 CONNECTIONSTATE_RESPONSE status codes.88 A.4.4 Tunnelling CONNECT_ACK error codes.89 A.4.5 Device Management DEVICE_CONFIGURATION_ACK status codes.89 A.5 Description Information Block (DIB).89 A.6 Host protocol codes.90 A.7 Timeout constants.90 A.8 Internet Protocol constants.90 Annex B (informative) Binary examples of KNXnet/IP IP frames.91 B.1 SEARCH_REQUEST.91 B.2 SEARCH_RESPONSE.91 B.3 DESCRIPTION_REQUEST.94 B.4 DESCRIPTION_RESPONSE.94 B.5 CONNECT_REQUEST.97 B.6 CONNECT_RESPONSE.98 B.7 CONNECTIONSTATE_REQUEST.99 B.8 CONNECTIONSTATE_RESPONSE.99 B.9 DISCONNECT_REQUEST.100 B.10 DISCONNECT_RESPONSE.100 B.11 DEVICE_CONFIGURATION_REQUEST.101 B.12 DEVICE_CONFIGURATION_ACK.101 B.13 TUNNELING_REQUEST.102 B.14 TUNNELING_ACK.102 B.15 ROUTING_INDICATION.103 B.16 ROUTING_LOST_MESSAGE.103 Bibliography.104
EN 13321-2:2006 (E) 4 Foreword This document (EN 13321-2:2006) has been prepared by Technical Committee CEN/TC 247 “Building Automation, Control and Building Management”, the secretariat of which is held by SNV. This European Standard shall be given the status of a national standard, either by publication of an identical text or by endorsement, at the latest by April 2007, and conflicting national standards shall be withdrawn at the latest by April 2007. This document supersedes ENV 13321-2:2000 Data communication for HVAC application - Automation net -Part 2: EIBnet.
This document also supersedes parts BatiBUS, EHS and EIB of ENV 13154-1:1998.
Whereas ENV 13321-2:2000 described the transmission of EIB packets over Ethernet including the frame encoding this document describes the transmission of HBES packets using the Internet Protocol. Details of the HBES packet frames are covered in EN 13321-1, [9] Open Data Communication in Building Automation, Controls and Building Management — Home and Building Electronic Systems — Part 1: Product and System Requirements, removing the need to explicitly describe the HBES frames in this document.
This document is part 2 of the EN 13321 series of European Standards under the general title Open data communication in building automation, controls and building management - Home and building electronic systems, which will comprise the following parts:
Part 1: Product and system requirements
Part 2: KNXnet/IP communication
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following countries are bound to implement this European Standard: Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EN 13321-2:2006 (E) 5 Introduction This standard is intended for design of new buildings and retrofit of existing buildings for an acceptable indoor environment, practical energy conservation and efficiency. This standard defines the integration of KNX protocol implementations within the Internet Protocol (IP) named KNXnet/IP or EIBnet/IP for continuity with ENV 13221-2:2000 (EIBnet) as defined by CEN/TC 247. EIBnet was introduced as an expansion of EIB into the information technology realm and was incorporated as a building controls technology in CEN/TC 247. EIBnet/IP is the logical successor to EIBnet. As EIB has become a part of KNX, this standard is called KNXnet/IP. This specification defines a standard protocol, which is implemented within KNX devices, the EIB Tool Software Next Generation (ETS NG) and other implementations to support KNX data exchange over IP networks. In fact, KNXnet/IP provides a general framework, which accommodates several specialized “Service Protocols” in a modular and extendible fashion.
• The KNXnet/IP specification consists of these clauses: Clause 1, Overview Clause 2, Core Specification Clause 3, Device Management Clause 4, Tunnelling Clause 5, Routing Additional clauses may be added to the KNXnet/IP specification in the future at which time Clause 1 “Overview” as well as Annex A shall be updated. KNXnet/IP supports different software implementations on top of the protocol. 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 to be configured for the specific user application. In order to simplify this process and cut cost for engineering, KNXnet/IP provides simple engineering interfaces, namely a description “language” for the underlying KNX system. This may be done off-line, e.g. generated as an ETS export file, or on-line by a mechanism that self-describes the underlying KNX system (reading data from the system itself). In conjunction with the EIB/KNX-to-BACnet mapping described in EN ISO 16484-5 [11] EIB/KNX installations can very easily be integrated into BACnet system environments. • KNXnet/IP supports On-the-fly change-over between Operational modes (configuration, operation); Event driven mechanisms; Connections with a delay time greater than tEIB_transfer_timeout
(e.g. network connection via satellite). Clause 1, Overview Clause 1 “Overview” provides a general overview of KNXnet/IP and covers security considerations.
EN 13321-2:2006 (E) 6 Clause 2, Core specification Clause 2 “Core Specification” defines a standard protocol, which is implemented within KNXnet/IP devices and the EIB Tool Software Next Generation (ETS NG) 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
Configuring and establishing a communication channel between a KNXnet/IP client and a KNXnet/IP server Clause 3, Device Management Clause 3 “Device Management” defines services for remote configuration and remote management of KNXnet/IP servers. Clause 4, Tunneling Clause 4 “Tunnelling” defines services supporting 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 any other KNXnet/IP Tunnelling client and KNXnet/IP servers takes less than tKNX_transfer_timeouts. It describes direct communication between ETS and target BCU with single telegrams exchanged between both (like iETS). This mode also allows for change of properties in devices. Clause 5, Routing Clause 5 “Routing” defines services, which route KNX telegrams between KNXnet/IP servers through the IP network.
EN 13321-2:2006 (E) 7
1 Scope This specification 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 transmission speed) backbone in KNX installations. • 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) • 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-TP0, KNX-RF, KNX-PL110, KNX-PL132), 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 iETS, data base application, BACnet Building Management System, browser, .). 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.
EN 13321-2:2006 (E) 8
Figure 1 – Device types and configuration examples
2 Normative references Not applicable. 3 Terms and definitions For the purposes of this document, the following terms and definitions apply. 3.1
subnet portion of a network that shares a common address component known as the "subnet address". Different network protocols specify the subnet address in different ways 3.2
Engineering Tool Software (ETS) software used to configure KNX devices 3.3
Host Protocol Address Information (HPAI) represents the Host Protocol Address Information structure. This structure holds the IP host protocol address information and is used to address a KNXnet/IP endpoint on another KNXnet/IP device
EN 13321-2:2006 (E) 9 3.4
communication channel logical connection between a KNXnet/IP client and a KNXnet/IP server (or, in case of routing, between two or more KNXnet/IP servers). A communication channel consists of one or more connections on the definition of the host protocol used for KNXnet/IP 3.5
KNX node KNX node is considered to be any device that implements a KNX protocol stack and fulfils the requirements for certification according to the KNX standard 3.6
KNXnet/IP server KNX device that has physical access to a KNX network and implements the KNXnet/IP server protocol to communicate with KNXnet/IP clients or other KNXnet/IP servers (in case of routing) on an IP network channel. A KNXnet/IP server is by design always also a KNX node 3.7
KNXnet/IP client application that implements the KNXnet/IP client protocol to get access to a KNX subnetwork over an IP network channel 3.8
KNXnet/IP devices all KNX devices are either a KNX or a KNXnet/IP node 3.9
KNXnet/IP router special type of KNXnet/IP device that routes KNX protocol packets between KNX sub-networks 3.10
Time To Live (TTL) TTL (Time To Live) of a multicast UDP/IP datagram is the maximum number of IP routers that may route this datagram. Each IP router the datagram passes decrements the TTL by one; the local host adapter does this as well. 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.11
KNXnet/IP Tunneling refers to the encapsulation of cEMI (common EMI) frames within Internet Protocol (IP) packets
EN 13321-2:2006 (E) 10 3.12
Internet Control Message Protocol (ICMP) extension to the Internet Protocol (IP) defined by RFC1) 792. ICMP 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 (IGMP) 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. The mechanisms of the protocol allow a host to inform its local router, using Host Membership Reports, 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
IP channel logical connection between two IP host/port endpoints. 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.15
communication channel communication channel as defined by the KNXnet/IP Core specification is represented by one or two IP channels
4 Symbols, abbreviations and acronyms For the purposes of this document, the symbols, abbreviations and acronyms used are listed below. 4.1 DHCP Dynamic Host Configuration Protocol – communication protocol for automatic assignment of IP address settings 4.2 DNS Domain Name Service – assigns Internet names to IP addresses 4.3 EIB European Installation Bus – Standard for Building Controls (EN 50090) 4.4 IP Internet Protocol
1) Request for Comment: Internet Standards defined by the Internet Engineering Task Force (IETF) are firstly published as RFCs.
EN 13321-2:2006 (E) 11 4.5 KNX Konnex – Standard for Building Controls (EN 50090) 4.6 TCP/IP Transmission Control Protocol over Internet Protocol – connection-oriented communication over the Internet 4.7 UDP/IP User Datagram Protocol over Internet Protocol – connection-less communication over the Internet
5 Requirements 5.1 Clause 1: Overview 5.1.1 KNXnet/IP Document Clauses 5
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.