SIST EN 14908-4:2014

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Odprta izmenjava podatkov v avtomatizaciji stavb in izvršnih elementov ter pri upravljanju stavb - Protokol regulacijske mreže - 4. del: Komunikacija IPFirmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Gebäudedatennetzprotokoll - Teil 4: Kommunikation mittels Internet Protokoll (IP)Réseau ouvert de communication de données pour l'automatisation, la régulation et la gestion technique du bâtiment - Protocole de contrôle du réseau - Partie 4: Communication par IPOpen Data Communication in Building Automation, Controls and Building Management - Control Network Protocol - Part 4: IP Communication97.120Avtomatske krmilne naprave za domAutomatic controls for household use35.240.99IT applications in other fieldsICS:Ta slovenski standard je istoveten z:EN 14908-4:2014SIST EN 14908-4:2014en,fr,de01-julij-2014SIST EN 14908-4:2014SLOVENSKI
STANDARDSIST EN 14908-4:20071DGRPHãþD



SIST EN 14908-4:2014



EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 14908-4
April 2014 ICS 35.240.99; 91.140.01; 97.120 Supersedes EN 14908-4:2006English Version
Open Data Communication in Building Automation, Controls and Building Management - Control Network Protocol - Part 4: IP Communication
Réseau ouvert de communication de données pour l'automatisation, la régulation et la gestion technique du bâtiment - Protocole de contrôle du réseau - Partie 4: Communication par IP
Offene Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Gebäude-Netzwerk-Protokoll -Teil 4: Kommunikation mittels Internet Protokoll (IP) This European Standard was approved by CEN on 12 April 2013.
CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management Centre has the same status as the official versions.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre:
Avenue Marnix 17,
B-1000 Brussels © 2014 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. EN 14908-4:2014 ESIST EN 14908-4:2014



EN 14908-4:2014 (E) 2 Contents
Foreword . 4 Introduction . 5 1 Scope. 6 2 Normative references . 6 3 Terms, definitions and abbreviations . 7 3.1 Terms and definitions . 7 3.2 Abbreviations . 8 4 Requirements . 8 5 CNP/IP device specification . 9 5.1 IP Related device specifications . 9 5.2 CNP related device specifications . 9 5.2.1 Packet formats . 9 5.2.2 Addressing schemes . 9 6 IP channel . 10 6.1 Specification . 10 6.2 IP transport mechanisms . 12 6.2.1 General . 12 6.2.2 Informative considerations . 13 7 CNP/IP device . 13 7.1 Configuration of a CNP/IP device . 13 7.2 Configuration parameters . 14 7.2.1 General . 14 7.2.2 Channel definition parameters . 14 7.2.3 Send List arameters . 15 7.2.4 Device parameters . 15 7.3 Configuration techniques. 15 7.3.1 General . 15 7.3.2 Manual configuration . 16 7.3.3 BOOTP and DHCP . 16 7.3.4 Configuration servers . 16 8 CNP/IP messages . 17 8.1 Definition of CNP/IP messages and modes of operation . 17 8.2 Common message header . 17 8.3 Packet segmentation . 19 8.3.1 Overview . 19 8.3.2 Segment exchange . 20 8.3.3 Discussion . 21 8.4 Data packet exchange . 22 8.4.1 General . 22 8.4.2 Out of order packets . 23 8.4.3 Duplicate packet detection . 24 8.4.4 Stale packet detection . 24 8.5 Configuration server interactions . 25 SIST EN 14908-4:2014



EN 14908-4:2014 (E) 3 8.5.1 General device interaction . 25 8.5.2 General protocol interaction . 27 8.5.3 Packet Segmentation . 27 8.5.4 Device Registration . 28 8.5.5 Channel Membership . 30 8.5.6 Send List . 31 8.5.7 Channel Routing . 32 8.6 Miscellaneous Status Messages . 34 8.6.1 General . 34 8.6.2 CNP/IP Device Status. 34 8.6.3 Device Configuration . 36 8.6.4 Device Send List . 36 8.6.5 Channel Membership List . 37 8.6.6 Channel routing information . 37 8.7 Vendor Specific Messages . 37 8.8 Authentication of CNP Packets . 38 9 Packet formats . 39 9.1 Packet Types . 39 9.2 Common CNP/IP Header . 40 9.3 Segment Packet . 42 9.4 CNP Data Packets . 43 9.5 CNP/IP Device Registration/configuration packets . 44 9.6 Channel Membership Packet . 48 9.7 Channel Routing Packet . 49 9.8 Request Packet . 52 9.9 Acknowledge Packet . 54 9.10 Send List Packet . 55 9.11 Node Status/Health/Statistics Response Message . 55 Annex A (normative)
Specifications for the CNP standard . 59 Annex B (informative)
Specifications for CNP. 61 Bibliography . 62
SIST EN 14908-4:2014



EN 14908-4:2014 (E) 4 Foreword This document (EN 14908-4:2014) has been prepared by Technical Committee CEN/TC 247 “Building Automation, Controls 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 October 2014 and conflicting national standards shall be withdrawn at the latest by October 2014. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights. This document supersedes EN 14908-4:2006. This European Standard is part of a series of standards for open data transmission in building automation, control and in building management systems. The content of this European Standard covers the data communications used for management, automation/control and field functions. EN 14908-4 is part of a series of European Standards under the general title Control Network Protocol (CNP), which comprises the following parts: Part 1: Protocol stack Part 2: Twisted pair communication Part 3: Power line channel specification Part 4: IP-Communication Part 5: Implementation Part 6: Application elements According to the CEN-CENELEC Internal Regulations, the national standards organizations of the following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom. SIST EN 14908-4:2014



EN 14908-4:2014 (E) 5 Introduction This European Standard has been prepared to provide mechanisms through which various vendors of building automation, control, and building management systems may exchange information in a standardised way. It defines communication capabilities. This European Standard will be used by all involved in design, manufacture, engineering, installation and commissioning activities. SIST EN 14908-4:2014



EN 14908-4:2014 (E) 6 1 Scope This European Standard specifies the transporting of the Control Network Protocol (CNP) packets for commercial Building Automation, Controls and Building Management over Internet Protocol (IP) networks using a tunnelling mechanism wherein the CNP packets are encapsulated within IP packets. It applies to both CNP nodes and CNP routers. The purpose of this European Standard is to ensure interoperability between various CNP devices that wish to use IP networks to communicate using the CNP protocol. The main body of this European Standard is independent of the CNP protocol being transported over the IP network. The reader is directed to Annex A and Annex B for the normative and informative, respectively, aspects of this specification that are specific to EN 14908-1. Figure 1 shows a possible configuration of such CNP devices and networks connected to an IP network.
Figure 1 — Typical CNP/IP application Figure 1 depicts two types of CNP devices: CNP nodes and CNP routers. It should be noted that the routers shown can route packets between typical CNP channels (such as twisted pair or power line) and an IP channel or it can route CNP packets between two IP channels. In this European Standard the IP channel will be defined in such a way to allow it to be used like any other CNP channel. In the above diagram, the IP network can be considered to be one or more IP channels. This European Standard covers only how CNP packets are transported over IP channels. It does not cover how CNP packets are routed between standard CNP channels and IP channels. This specification is not intended to cover the lower layers (physical, MAC and link layers) of either standard CNP or IP channels. 2 Normative references Not applicable. SIST EN 14908-4:2014



EN 14908-4:2014 (E) 7 3 Terms, definitions and abbreviations 3.1 Terms and definitions For the purposes of this document, the following terms and definitions apply. 3.1.1 tunnelling encapsulation of one protocol’s packet within the payload of another protocol’s packets 3.1.2 channel common communications transport mechanism that a specific collection of CNP devices share and communicate over without the use of a router Note 1 to entry: Channels are used to transport CNP packets below the link layer of the CNP protocol stack. Note 2 to entry: Typically this refers to some type of physical media such as power line, RF, or twisted pair, but in the case of IP networks this channel is not physical, but a protocol tunnel. 3.1.3 CNP device
device that uses the CNP protocol to communicate with other CNP devices Note 1 to entry: Specifically, a CNP/IP device is a CNP device that communicates with other CNP devices over an IP channel. 3.1.4
CNP router special type of CNP device that routes CNP protocol packets between two or more channels Note 1 to entry: Specifically, a CNP/IP router is a CNP router in which at least one of the channels it routes packets over is an IP channel. 3.1.5
CNP node special type of CNP device that can send or receive CNP protocol packets, but does not route them between channels Note 1 to entry: Specifically a CNP/IP node is a CNP node in which at least one of the channels it sends and receives packets over is an IP channel. Note 2 to entry: All CNP devices are either routers, nodes or both. 3.1.6
CNP group collection of CNP devices that share a common multicast address 3.1.7
node ID logical network address that differentiates nodes within the same subnet or domain 3.1.8
Must Be Zero (MBZ) reserved field that may be used in the following versions of the protocol SIST EN 14908-4:2014



EN 14908-4:2014 (E) 8 Note 1 to entry: Such fields will be sent as zero and ignored by the receiver in implementations conforming to the current version of the specification. 3.2 Abbreviations CTP Channel Timeout Period CNP Control Network Protocol LFS Last Forwarded Sequence MBZ Must Be Zero NTP Network Time Protocol PSN Packet Sequence Number SA/DA Source Address / Destination Address SID Session Identifier SNTP Simple Network Time Protocol UDP User Datagram Protocol 4 Requirements The following is a set of general requirements for the transporting of CNP packets over IP channels: — be as efficient as possible to allow quasi real-time operation; — be independent of the application level interface used to receive the packets. For example the tunnelling protocol should not rely on the existence of a socket interface or how that interface may be used; — ensure that CNP packet ordering is preserved; — ensure that CNP packets that are “stale” (outside the maximum timeout characteristics of the IP channel) are not forwarded; — detect packets that get duplicated in the IP network; — support IP routing devices that prioritise IP packets; — optional security measures to prevent malicious users from tampering with devices; — scalable; — allow status information to be extracted from CNP/IP devices; — support the exchange of configuration information between CNP/IP devices and configuration servers. SIST EN 14908-4:2014



EN 14908-4:2014 (E) 9 5 CNP/IP device specification 5.1 IP Related device specifications A CNP/IP device shall behave like any standard IP host capable of exchanging IP packets with any other IP host either on the same IP subnet or anywhere else in the Internet cloud. A CNP/IP device shall have a single unicast IP address and may be capable belonging to as many as 32 multi-cast groups. It is optional that a CNP/IP device support multi-casting. This document does not address the routing of IP packets between subnets or through the Internet. The CNP/IP devices shall be compatible with whatever standard mechanisms (IP routers, switches etc.) are required to perform the IP routing functions. 5.2 CNP related device specifications 5.2.1 Packet formats The general format of CNP packets which are tunnelled over the IP channel are those packets that are received from or sent to the Link layer (layer 2) of the CNP protocol stack. Refer to Annex A for a precise specification of the packet formats corresponding to the CNP protocol. 5.2.2 Addressing schemes Different CNP protocols generally use different addressing schemes to exchange packets. Although it is generally not necessary to understand the contents of a CNP packet or its addresses in order to tunnel CNP packets over IP, some aspects of the CNP addressing scheme are reflected in the process of configuration. This is especially true when it comes to setting up the IP channels that are used for tunnelling. Since CNP protocols use different addressing schemes the terminology used in the main body of this specification for describing addresses are meant to be general and rich enough to describe the superset of addressing schemes used in all CNP protocols. The following CNP addressing terms are used in this specification. — Unique ID. This refers to an ID that is globally unique to all devices within a specific protocol. Unique ID’s are generally fixed in nature in that they never change through the life of a device. — Domain. This is the highest level of a three level hierarchical addressing scheme. Domain ID’s should be unique within a particular network. This means that in a particular network where Domains are used if two devices have the same Domain ID they belong to the same Domain. Domain ID’s are generally logical in nature and can be changed and configured. — Subnet. This is the middle level of a three level hierarchical addressing scheme. Subnet ID’s should be unique within a particular domain. This means that in a particular network where subnet ID’s are used if two devices have the same Domain ID and the same Subnet ID then they belong to the same Subnet. Some CNP's do not use Domains in which case the Subnet may be the highest level of address for a device. Subnet ID’s are generally logical in nature and can be changed and configured. — Node. This is the lowest level of any hierarchical addressing scheme. Node ID’s should be unique within a particular Subnet. No two devices within the same subset should have the same Node ID. Node ID’s are generally logical in nature and can be changed and configured. — Group. Groups are an orthogonal addressing scheme to the hierarchical Domain/Subnet/Node triplet just described. Groups are used to allow multi-casting of messages. Some CNP’s may not support group addresses and even those that do will have different rules for how they relate to the other addressing schemes. These considerations are not relevant to this specification. SIST EN 14908-4:2014



EN 14908-4:2014 (E) 10 The definitions above are fairly general and are provided as a guideline for how to map the CNP protocol to these terms. In general how the various addressing schemes work within a CNP protocol are not relevant to this specification. It is only necessary to know what the various addressing terms refer to. Of special note is how these addresses are used for routing within the CNP protocol. Therefore, a table is given in the appendix that specifies how the appropriate addresses used in that protocol map to the terms given above. 6 IP channel 6.1 Specification IP channels are not like typical CNP channels that currently exist. Typical CNP channels are physical busses by nature. This implies that all devices on the channel will, by default, receive all packets transmitted on that channel. In addition, when a new device is added to the channel it is not necessary that other devices on the channel become aware of it before they can exchange packets. To transmit a packet on a channel it is only necessary that a device be capable of physically transmitting the packet on the channel, nothing more. If a device is simply physically connected to a channel it is capable of exchanging packets with other devices on the channel. By contrast an IP channel is not physical, but logical in nature. There are a number of different physical media that can support IP communications and any of them should be capable of supporting a CNP channel. Because we are dealing with a logical channel it is necessary to “construct” the channel by informing each device on the channel of the existence of the other devices on that channel. In other words, before a device can transmit a packet to some other device on an IP channel it shall be made aware of how to specifically send a packet to that device, i.e. its IP address. Another significant difference between physical and logical channels is that in the case of typical physical channels it is possible to calculate fixed upper bounds on the length of time it will take a packet to traverse from one device to another once the packet is transmitted on the channel. This is not always possible for IP networks. The deviation of packet delivery times between CNP devices on an IP channel are much higher than those experienced with typical CNP channels. As depicted in Figure 1, the IP channel is used as an intermediary transport mechanism for the CNP packets by a variety of CNP/IP devices. When a CNP packet is transported on an IP channel, an IP message encapsulating the CNP packets is sent to other CNP/IP devices on that IP channel. Upon receipt of one of the IP messages by a CNP/IP device the CNP packets are extracted and processed. A single IP message may contain more than one CNP packet. Therefore, the IP messages shall be formatted in such a way to allow the extraction of the individual CNP packets. This is referred to a packet “bunching”. CNP/IP devices shall support the receipt of bunched packets. Likewise, the bunching shall be done in such a fashion that each CNP packet contained within a bunched IP message is complete, i.e. CNP packets should not cross IP message boundaries as a result of bunching. It is also a requirement that intermediate IP devices be capable of unbundling bunched CNP packets and bunching them in a different manner before forwarding them. The IP channel is specified by the list of unicast IP addresses, exactly one for each CNP/IP device. There is no maximum to the number of CNP/IP devices on a single IP channel. If every CNP/IP device on an IP channel contained a list of unicast IP addresses for every other CNP/IP device on that IP channel, this is all that would be required to enable the tunnelling of CNP packets. In the most brute force approach, for each CNP packet to be forwarded on the IP channel a separate unicast IP message could be sent to each CNP/IP device in the channel. This does not scale very well so the following techniques will be used to reduce the IP traffic: SIST EN 14908-4:2014



EN 14908-4:2014 (E) 11 — IP multi-cast groups; — selective forwarding. IP multi-cast groups allow a single IP message to be sent to more than one CNP/IP device. Therefore, a complete definition of a CNP/IP channel should contain not only the unicast IP addresses of all the CNP/IP devices on the channel but also the IP multi-cast groups to which they belong. Each CNP/IP device can belong to up to 32 multi-cast addresses. Selective forwarding refers to examining the contents of the CNP packet before forwarding it to determine if it should be sent to a particular CNP/IP device. In order to do this additional CNP specific information shall be known about each potential destination. If the CN
...