BS EN 14908-1-2014 Open Data Communication in Building Automation Controls and Building Management Control Network Protocol Protocol Stack《建筑自动化 控制和建筑管理的开放式数据通信 控制网络协议 协议栈》.pdf

1、BSI Standards PublicationBS EN 14908-1:2014Open Data Communication inBuilding Automation, Controlsand Building Management Control Network ProtocolPart 1: Protocol StackBS EN 14908-1:2014 BRITISH STANDARDNational forewordThis British Standard is the UK implementation of EN 14908-1:2014.It supersedes

2、BS EN 14908-1:2005 which is withdrawn.The UK participation in its preparation was entrusted to TechnicalCommittee RHE/16, Performance requirements for control systems.A list of organizations represented on this committee can beobtained on request to its secretary.This publication does not purport to

3、 include all the necessaryprovisions of a contract. Users are responsible for its correctapplication. The British Standards Institution 2014. Published by BSI StandardsLimited 2014ISBN 978 0 580 79424 7ICS 35.240.99; 91.140.01; 97.120Compliance with a British Standard cannot confer immunity fromlega

4、l obligations.This British Standard was published under the authority of theStandards Policy and Strategy Committee on 31 May 2014.Amendments issued since publicationDate Text affectedBS EN 14908-1:2014EUROPEAN STANDARD NORME EUROPENNE EUROPISCHE NORM EN 14908-1 April 2014 ICS 35.240.99; 91.140.01;

5、97.120 Supersedes EN 14908-1:2005English Version Open Data Communication in Building Automation, Controls and Building Management - Control Network Protocol - Part 1: Protocol Stack Rseau ouvert de communication de donnes pour lautomatisation, la rgulation et la gestion technique du btiment - Protoc

6、ole de contrle du rseau - Partie 1: Niveaux du protocole Offene Datenkommunikation fr die Gebudeautomation und Gebudemanagement - Gebude-Netzwerk-Protokoll -Teil 1: Datenprotokollschichtenmodell This European Standard was approved by CEN on 12 April 2013. CEN members are bound to comply with the CEN

7、/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 Cen

8、tre 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 th

9、e 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, Nether

10、lands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom. EUROPEAN COMMITTEE FOR STANDARDIZATION COMIT EUROPEN DE NORMALISATION EUROPISCHES KOMITEE FR NORMUNG CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels 2014 CEN All righ

11、ts of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. EN 14908-1:2014 EBS EN 14908-1:2014EN 14908-1:2014 (E) 2 Contents Foreword 5 Introduction .6 1 Scope.7 2 Normative references 7 3 Terms and definitions 7 4 Symbols and abbreviations 9 4.1 Symbols an

12、d graphical representations 9 4.2 Abbreviations 10 5 Overview of protocol layering . 11 6 MAC sublayer 13 6.1 General . 13 6.2 Service provided . 13 6.3 Interface to the link layer 13 6.4 Interface to the physical layer . 14 6.5 MPDU format . 15 6.6 Predictive p-persistent CSMA overview description

13、15 6.7 Idle channel detection 16 6.8 Randomising . 17 6.9 Backlog estimation . 17 6.10 Optional priority 18 6.11 Optional collision detection . 19 6.12 Beta1, Beta2 and Preamble Timings . 20 7 Link layer . 22 7.1 Assumptions . 22 7.2 Service provided . 22 7.3 CRC. 22 7.4 Transmit algorithm 23 7.5 Re

14、ceive Algorithm . 23 8 Network layer . 23 8.1 Assumptions . 23 8.2 Service provided . 25 8.3 Service interface . 25 8.4 Internal structuring of the network layer 26 8.5 NPDU format 26 8.6 Address recognition . 27 8.7 Routers . 27 8.8 Routing algorithm . 28 8.9 Learning algorithm subnets 28 9 Transac

15、tion control sublayer . 28 9.1 Assumptions . 28 9.2 Service provided . 29 9.3 Service interface . 29 9.4 State variables . 30 BS EN 14908-1:2014EN 14908-1:2014 (E) 3 9.5 Transaction control algorithm . 30 10 Transport layer 31 10.1 Assumptions . 31 10.2 Service provided . 31 10.3 Service interface .

16、 31 10.4 TPDU types and formats 32 10.5 Protocol diagram . 33 10.6 Transport protocol state variables 34 10.7 Send algorithm 34 10.8 Receive algorithm . 34 10.9 Receive transaction record pool size and configuration engineering 34 11 Session layer . 37 11.1 Assumptions . 37 11.2 Service Provided . 3

17、7 11.3 Service interface . 38 11.4 Internal structure of the session layer 38 11.5 SPDU types and formats 39 11.6 Protocol timing diagrams . 40 11.7 Request-response state variables . 43 11.8 Request-response protocol client part 43 11.9 Request-response protocol server part . 43 11.10 Request-respo

18、nse protocol timers . 44 11.11 Authentication protocol 44 11.12 Encryption algorithm 44 11.13 Retries and the role of the checksum function 44 11.14 Random Number Generation . 45 11.15 Using Authentication 45 12 Presentation/application layer . 45 12.1 Assumptions . 45 12.2 Service provided . 45 12.

19、3 Service interface . 46 12.4 APDU types and formats 47 12.5 Protocol diagrams . 48 12.6 Application protocol state variables . 50 12.7 Request - response messaging in offline state . 50 12.8 Network variables . 51 12.9 Error notification to the application program 52 13 Network management the norma

20、tive Annex A has been re-worked for a better understanding. The reference implementation of the standard shows in detail which part is normative and hardware independent, which one is normative but hardware dependent and which one is not normative because it is hardware dependent. This information s

21、upports the development of a protocol stack and the understanding of the specified communication services. EN 14908-1 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 co

22、mmunication; 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: Aus

23、tria, 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, Swed

24、en, Switzerland, Turkey and the United Kingdom. BS EN 14908-1:2014EN 14908-1:2014 (E) 6 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 standardise

25、d way. It defines communication capabilities. This European Standard will be used by all involved in design, manufacture, engineering, installation and commissioning activities. BS EN 14908-1:2014EN 14908-1:2014 (E) 7 1 Scope This European Standard applies to a communication protocol for networked c

26、ontrol systems in commercial Building Automation, Controls and Building Management. The protocol provides peer-to-peer communication for networked control and is suitable for implementing both peer-to-peer and master-slave control strategies. This specification describes services in layers 2 to 7. I

27、n the layer 2 (data link layer) specification, it also describes the MAC sub-layer interface to the physical layer. The physical layer provides a choice of transmission media. The interface described in this specification supports multiple transmission media at the physical layer. In the layer 7 spe

28、cification, it includes a description of the types of messages used by applications to exchange application and network management data. 2 Normative references The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dat

29、ed references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. EN 14908-5, Open Data Communication in Building Automation, Controls and Building Management Implementation Guideline - Control Network Protocol -

30、Part 5: Implementation 3 Terms and definitions For the purposes of this document, the following terms and definitions apply. For the purposes of this European Standard, the following subclause introduces the basic terminology employed throughout this European Standard. Most of it is commonly used an

31、d the terms have the same meaning in both the general and the standard context. However, for some terms, there are subtle differences. For example, in general, bridges do selective forwarding based on the layer 2 destination address. There are no layer 2 addresses in this standard protocol, so bridg

32、es forward all packets, as long as the domain address in the packet matches a domain of which the bridge is a member. Routers, in general, perform network address modification so that two protocols with the same transport layer but different network layers can be connected to form a single logical n

33、etwork. Routers of this standard may perform network address modification, but typically, they only examine the network address fields and selectively forward packets based on the network layer address fields. 3.1 channel physical unit of bandwidth linking one or more communication nodes. Note 1 to

34、entry: Refer to Annex E for further explanation of the relationship between a channel and a subnet. 3.2 physical repeater device that reconditions the incoming physical layer signal on one channel and retransmits it onto another channel 3.3 store-and-forward repeater device that stores and then repr

35、oduces data packets onto a second channel BS EN 14908-1:2014EN 14908-1:2014 (E) 8 3.4 bridge device that connects two channels (x and y); forwards all packets from x to y and vice versa, as long as the packets originate on one of the domain(s) that the bridge belongs to 3.5 configuration non-volatil

36、e information used by the device to customise its operation. There is configuration data for the correct operation of the protocol in each device, and optionally, for application operation. The network configuration data stored in each device has a checksum associated with the data. Examples of netw

37、ork configuration data are node addresses, communication media parameters such as priority settings, etc. Application configuration information is application specific 3.6 domain virtual network that is the network unit of management and administration. Group and subnet (see below) addresses are ass

38、igned by the administrator responsible for the domain, and they have meaning only in the context of that domain 3.7 flexible domain used in conjunction with Unique_Node_ID and broadcast addressing. A node responds to a Unique_Node_ID-addressed message if the address matches, regardless of the domain

39、 on which the message was sent. To respond so that the sender receives it, the response shall be sent on the domain in which it was received. Furthermore, this domain shall be remembered for the duration of the transaction so that duplicate detection of any retries is possible. This transitory domai

40、n entry at a node is called the flexible domain. How many flexible domain entries a node supports depends on the implementation. However, a minimum of 1 is required 3.8 subnet set of nodes accessible through the same link layer protocol; a routing abstraction for a channel; in this standard subnets

41、are limited to a maximum of 127 nodes 3.9 node abstraction for a physical node that represents the highest degree of address resolvability on a network. A node is identified (addressed) within a subnet by its (logical) node identifier. A physical node may belong to more than one subnet; when it does

42、, it is assigned one (logical) node number for each subnet to which it belongs. A physical node may belong to at most two subnets; these subnets shall be in different domains. A node may also be identified (absolutely) within a network by its Unique_Node_ID 3.10 group uniquely identifiable set of no

43、des within a domain. Within this set, individual members are identified by their member number. Groups facilitate one-to-many communication and are intended to support functional addressing 3.11 router device that routes data packets to their respective destinations by selectively forwarding from su

44、bnet to subnet; a router always connects two (sets of) subnets; routers may modify network layer address fields. Routers may be set to one of four modes: repeater mode, bridge mode, learning mode, and configured mode. In repeater mode, packets are forwarded if they are received with no errors. In br

45、idge mode, packets are forwarded if they are received with no errors and match a domain that the router is a member of. Routers in learning mode learn the topology by examining packet traffic, while BS EN 14908-1:2014EN 14908-1:2014 (E) 9 routers that are set to configured mode have the network topo

46、logy stored in their memory and make their routing decisions solely upon the contents of their configured tables 3.12 (application) gateway interconnects networks at their highest protocol layers (often two different protocols). Two domains can also be connected through an application gateway 3.13 B

47、eta1 period immediately following the end of a packet cycle. A node attempting to transmit monitors the state of the channel, and if it detects no transmission during the Beta1 period, it determines the channel to be idle 3.14 Beta2 randomising slot. A node wishing to transmit generates a random del

48、ay T. This delay is an integer number of randomising slots of duration Beta2 3.15 network variable variable in an application program whose value is automatically propagated over the network whenever a new value is assigned to it 3.16 Standard Network Variable Types (SNVTs) variables with agreed-upo

49、n semantics. These variables are interpreted by all applications in the same way, and are the basis for interoperability. Definition of specific SNVTs is beyond the scope of this European Standard 3.17 manual service request message network management message containing a nodes Unique_Node_ID. Used by a network management device that receives this message to install and configure the node. May be generated by application or system code. May be triggered by external hardware event, e.g., driving a “manual service request” input low 3.18 transaction sequence of me