SIST EN 14908-4:2007
Open Data Communication in Building Automation, Controls and Building Management - Control Network Protocol - Part 4: IP Communication
Open Data Communication in Building Automation, Controls and Building Management - Control Network Protocol - Part 4: IP Communication
This European Standard specifies the transporting of Control Network Protocol (CNP) packets over Internet Protocol (IP) networks using a tunnelling mechanism wherein the CNP packets are encapsulated within the IP packets. It applies to both CNP nodes and CNP routers.
The purpose of this European Standard is to insure 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.
Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Gebäude Netzwerk Protokoll - 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 réseau pour le bâtiment - Partie 4: Communication par IP
La présente Norme européenne spécifie le transport des paquets du protocole de réseau CNP (Control Network Protocol) sur le protocole IP (Internet Protocol) en utilisant un mécanisme d’encapsulation où les paquets CNP sont encapsulés dans les paquets IP. Il s’applique autant aux nœuds CNP qu’aux routeurs CNP.
L’objectif de la présente Norme européenne est d’assurer l’interopérabilité entre différents équipements CNP qui désirent utiliser les réseaux IP pour communiquer avec le protocole CNP.
La partie principale de la présente Norme européenne est indépendante du protocole CNP, celui qui est transporté par le réseau IP. Le lecteur est invité à lire l’Annexe A et l’Annexe B pour les aspects respectivement normatifs et informatifs de cette spécification, spécifiques à l’EN 14908-1.
La Figure 1 montre une configuration possible de tels équipements CNP et les réseaux connectés à un réseau IP.
Figure 1 — Application CNP/IP type
La Figure 1 représente deux types d’équipements CNP : les nœuds et routeurs CNP. Il convient de noter que les routeurs peuvent router des paquets entre des canaux CNP types (tels que paires torsadées ou courants porteurs) et un canal IP, il peut aussi router des paquets entre deux canaux IP. Dans la présente Norme européenne, le canal IP sera défini de telle façon qu’il permette d’être utilisé comme n’importe quel autre canal CNP.
Dans le diagramme ci-dessus, le réseau IP peut être considéré comme un ou plusieurs canaux IP. La présente Norme européenne couvre seulement la manière dont sont transportés des paquets CNP sur des canaux IP. Elle ne s’intéresse pas à la manière dont les paquets CNP sont routés entre des canaux CNP standard et des canaux IP. Cette spécification n’est pas destinée à couvrir les couches basses : c’est-à-dire les couches physique, réseau (MAC) et liaison.
Odprta izmenjava podatkov v avtomatizaciji stavb in izvršnih elementov ter pri upravljanju stavb - Protokol regulacijske mreže - 4. del: IP komunikacija
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 - Control Network Protocol - Part 4: IP CommunicationOdprta izmenjava podatkov v avtomatizaciji stavb in izvršnih elementov ter pri upravljanju stavb - Protokol regulacijske mreže - 4. del: IP komunikacijaRéseau ouvert de communication de données pour l'automatisation, la régulation et la gestion technique du bâtiment - Protocole de réseau pour le bâtiment - Partie 4: Communication par IPFirmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Gebäude Netzwerk Protokoll - Teil 4: Kommunikation mittels Internet Protokoll (IP)Ta slovenski standard je istoveten z:EN 14908-4:2006SIST EN 14908-4:2007en97.120Avtomatske krmilne naprave za domAutomatic controls for household use35.240.99IT applications in other fieldsICS:SLOVENSKI
STANDARDSIST EN 14908-4:200701-februar-2007
EUROPEAN STANDARDNORME EUROPÉENNEEUROPÄISCHE NORMEN 14908-4November 2006ICS 35.240.99; 97.100 English VersionOpen Data Communication in Building Automation, Controls andBuilding Management - Control Network Protocol - Part 4: IPCommunicationRéseau ouvert de communication de données pourl'automatisation, la régulation et la gestion technique dubâtiment - Protocole de réseau pour le bâtiment - Partie 4:Communication par IPFirmenneutrale Datenkommunikation für dieGebäudeautomation und Gebäudemanagement - GebäudeNetzwerk Protokoll - Teil 4: Kommunikation mittels InternetProtokoll (IP)This European Standard was approved by CEN on 11 September 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 14908-4:2006: E
EN 14908-4:2006 (E) 2 Contents Page Foreword.4 Introduction.5 1 Scope.6 2 Normative references.7 3 Terms and definitions.7 4 Requirements.8 5 CNP/IP device specification.8 5.1 IP Related device specifications.8 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.13 7.2.1 General.13 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.15 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.18 8.3.1 Overview.18 8.3.2 Segment exchange.19 8.3.3 Discussion.20 8.4 Data packet exchange.21 8.4.1 General.21 8.4.2 Out of order packets.22 8.4.3 Duplicate packet detection.23 8.4.4 Stale packet detection.23 8.5 Configuration server interactions.24 8.5.1 General device interaction.24 8.5.2 General protocol interaction.26 8.5.3 Packet Segmentation.26 8.5.4 Device Registration.27 8.5.5 Channel Membership.29
EN 14908-4:2006 (E) 3 8.5.6 Send List.30 8.5.7 Channel Routing.31 8.6 Miscellaneous Status Messages.33 8.6.1 General.33 8.6.2 CNP/IP Device Status.33 8.6.3 Device Configuration.35 8.6.4 Device Send List.35 8.6.5 Channel Membership List.36 8.6.6 Channel routing information.36 8.7 Vendor Specific Messages.36 8.8 Authentication of CNP Packets.37 9 Packet formats.38 9.1 Packet Types.38 9.2 Common CNP/IP Header.39 9.3 Segment Packet.41 9.4 CNP Data Packets.42 9.5 CNP/IP Device Registration/configuration packets.43 9.6 Channel Membership Packet.46 9.7 Channel Routing Packet.47 9.8 Request Packet.50 9.9 Acknowledge Packet.51 9.10 Send List Packet.52 9.11 Node Status/Health/Statistics Response Message.53 Annex A (normative)
Specifications for the CNP standard.57 Annex B (informative)
Specifications for CNP.59 Bibliography.60
EN 14908-4:2006 (E) 4 Foreword This document (EN 14908-4:2006) 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 May 2007, and conflicting national standards shall be withdrawn at the latest by May 2007. This European Standard is part of the standard EN 14908 Open Data Communication in Building Automation, Controls and Building Management — Control Network Protocol and consists of 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 Guideline The content of this European Standard covers the data communications used for management, automation/control and field functions. This European Standard is based on the American standard EIA/CEA-852 Tunnelling Component Network Protocols Over Internet Protocol Channels. 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 14908-4:2006 (E) 5 Introduction This European Standard has been prepared to provide mechanisms through which various vendors of building automation, control and of building management systems may exchange information in a standardised way. It defines communication capabilities. This European Standard is used by all involved in design, manufacture, engineering, installation and commissioning activities. The European Committee for Standardization (CEN) draws attention to the fact that it is claimed that compliance with this European Standard may involve the use of a patent concerning this European Standard. CEN takes no position concerning the evidence, validity and scope of this patent right. The holder of this patent right has assured to CEN that he/she is willing to negotiate licences under reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this respect, the statement of the holder of this patent right is registered with CEN. Information may be obtained from: ECHELON Corp 550 Meridian Avenue San Jose, California 95126 Phone: +1-408-938-5200 Fax: +1-408-790-3800 Email: lonworks@echelon.com http://www.echelon.com Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights other than those identified above. CEN shall not be held responsible for identifying any or all such patent rights.
EN 14908-4:2006 (E) 6
1 Scope This European Standard specifies the transporting of Control Network Protocol (CNP) packets over Internet Protocol (IP) networks using a tunnelling mechanism wherein the CNP packets are encapsulated within the IP packets. It applies to both CNP nodes and CNP routers. The purpose of this European Standard is to insure 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. CNPChannelCNPNodesCNP/IP RouterINTERNETIP ChannelIP ChannelWorkstationrunningCNP StackEmbeddedCNPDeviceCNP/IP to CNP/IPRouterCNP/IP to CNP/IPRouterCNP/IP RouterCNP/IP RouterCNPNodesCNPNodesCNPChannelCNPChannel 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.
EN 14908-4:2006 (E) 7 2 Normative references Not applicable. 3 Terms and definitions For the purposes of this document, the following terms and definitions apply. 3.1 Control Network Protocol CNP communication standard using a network of nodes (devices) that are capable of computing, sensing, and actuating NOTE 1 Typically these devices are used for control and telemetry purposes including applications such as HVAC, security, energy management, machine control etc. NOTE 2 These devices are typically not used for data processing or general purpose computing purposes. 3.2 Tunneling encapsulation of one protocol’s packet within the payload of another protocol’s packets 3.3 channel common communications transport mechanism that a specific collection of CNP devices share and communicate over without the use of a router NOTE 1 Channels are used to transport CNP packets below the link layer of the CNP protocol stack. NOTE 2 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.4 CNP device device that uses the CNP protocol to communicate with other CNP devices NOTE Specifically a CNP/IP device is a CNP device that communicates with other CNP devices over an IP channel. 3.5 CNP router special type of CNP device that routes CNP protocol packets between two or more channels NOTE 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.6 CNP node special type of CNP device that can send or receive CNP protocol packets, but does not route them between channels NOTE 1 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 All CNP devices are either routers, nodes or both.
EN 14908-4:2006 (E) 8 3.7 CNP group collection of CNP devices that share a common multicast address 3.8 node ID logical network address that differentiates nodes within the same subnet or domain 3.9 Must Be Zero MBZ reserved field that may be used in the following versions of the protocol NOTE Such fields shall be sent as zero and ignored by the receiver in implementations conforming to the current version of the specification. 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; insure that CNP packet ordering is preserved; insure 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. 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 uni-cast 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.
EN 14908-4:2006 (E) 9 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. 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.
EN 14908-4:2006 (E) 10 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. On reception 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 reception 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 uni-cast 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 uni-cast 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 uni-cast 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: 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 uni-cast 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 CNP/IP device is a router then the
EN 14908-4:2006 (E) 11 information necessary to perform selective forwarding is the routing tables of the CNP/IP router. If the device is simply a node then the domain, subnet, node id, unique id, and CNP groups that the node belongs to should be known. Therefore all this information is also part of a complete IP channel definition. In short a complete IP channel definition contains all known information that may be relevant to the forwarding of packets to the other CNP/IP devices in the IP channel. It is the universe of all relevant knowledge about the IP channel. It is important that whatever forwarding scheme is used by a CNP/IP device the following conditions are always true: a) CNP protoco
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.