Open data communication in building automation, controls and building management - Mapping between Lonworks and BACnet

The LONWORKS communication system is widely used in building automation systems for field-level and application-level functions for residential and non-residential controls in lighting, sun protection, HVAC, energy management and security applications. The BACnet communication system as well is also used in building automation systems for management-level and application-level functions. This technical specification defines the methods for combining BACnet networks with LONWORKS networks, and standardizes the interface between BACnet and LONWORKS systems.

Offene Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Gegenseitige Abbildung von LONWORKS- und BACnet-Objekten

Réseau ouvert de communication de données pour l'automatisation, la régulation et la gestion technique du bâtiment - Intégration des fonctionnalités (mappage) entre LONWorks et BACnet

Le système de communication LONWORKS est largement utilisé dans les systèmes d'automatisation de bâtiment pour les fonctions locales et relatives aux applications des commandes résidentielles et non résidentielles des applications d'éclairage, de protection solaire, de CVC (Chauffage, Ventilation, Climatisation), de gestion de l'énergie et de sécurité. Le système de communication BACnet est également utilisé dans les systèmes d'automatisation de bâtiment pour les fonctions de gestion et relatives aux applications. La présente spécification technique définit les méthodes permettant de combiner les réseaux BACnet avec les réseaux LONWORKS et normalise l'interface entre les systèmes BACnet et LONWORKS.

Odprta izmenjava podatkov v avtomatizaciji stavb in izvršnih elementov ter pri upravljanju stavb - Preslikava med Lonworks in BACnet

General Information

Status
Published
Publication Date
23-May-2006
Current Stage
9093 - Decision to confirm - Review Enquiry
Due Date
30-Oct-2009
Completion Date
30-Oct-2009

Buy Standard

Technical specification
-TS CEN/TS 15231:2007
English language
35 pages
sale 10% off
Preview
sale 10% off
Preview

e-Library read for
1 day

Standards Content (sample)

SLOVENSKI STANDARD
SIST-TS CEN/TS 15231:2007
01-februar-2007
Odprta izmenjava podatkov v avtomatizaciji stavb in izvršnih elementov ter pri
upravljanju stavb - Preslikava med Lonworks in BACnet

Open data communication in building automation, controls and building management -

Mapping between Lonworks and BACnet
Offene Datenkommunikation für die Gebäudeautomation und Gebäudemanagement -
Gegenseitige Abbildung von LONWORKS- und BACnet-Objekten

Réseau ouvert de communication de données pour l'automatisation, la régulation et la

gestion technique du bâtiment - Intégration des fonctionnalités (mapping) entre
LONWorks et BACnet
Ta slovenski standard je istoveten z: CEN/TS 15231:2006
ICS:
35.240.99 8SRUDEQLãNHUHãLWYH,7QD IT applications in other fields
GUXJLKSRGURþMLK
97.120 Avtomatske krmilne naprave Automatic controls for
za dom household use
SIST-TS CEN/TS 15231:2007 en

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
TECHNICAL SPECIFICATION
CEN/TS 15231
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
May 2006
ICS 35.240.99
English Version
Open data communication in building automation, controls and
building management - Mapping between Lonworks and BACnet

Réseau ouvert de communication de données pour Offene Datenkommunikation für die Gebäudeautomation

l'automatisation, la régulation et la gestion technique du und Gebäudemanagement - Gegenseitige Abbildung von

bâtiment - Intégration des fonctionnalités (mapping) entre LONWORKS- und BACnet-Objekten

LONWorks et BACnet

This Technical Specification (CEN/TS) was approved by CEN on 22 August 2005 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit their

comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS available

promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS)

until the final decision about the possible conversion of the CEN/TS into an EN is reached.

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 STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36 B-1050 Brussels

© 2006 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 15231:2006: E

worldwide for CEN national Members.
---------------------- Page: 2 ----------------------
CEN/TS 15231:2006 (E)
Contents Page

Foreword..............................................................................................................................................................4

Introduction.........................................................................................................................................................5

1 Scope ......................................................................................................................................................6

2 Normative references ............................................................................................................................6

3 Terms and definitions ...........................................................................................................................6

4 Object Structures...................................................................................................................................7

4.1 LONWORKS Objects (Functional Profile) ...........................................................................................7

4.2 BACnet Objects......................................................................................................................................8

4.3 Relationship of LONWORKS to BACnet..............................................................................................8

5 Properties Needed for Mapping ...........................................................................................................9

5.1 Object_Identifier.....................................................................................................................................9

5.2 Object_Name....................................................................................................................................... 10

5.3 Object_Type ........................................................................................................................................ 10

5.4 Present_Value ..................................................................................................................................... 10

5.5 Description .......................................................................................................................................... 11

5.6 Status_Flags........................................................................................................................................ 11

5.7 Event_State ......................................................................................................................................... 11

5.8 Reliability............................................................................................................................................. 11

5.9 Out_Of_Service................................................................................................................................... 11

5.10 Units ..................................................................................................................................................... 11

5.11 Priority_Array...................................................................................................................................... 16

5.12 Relinquish_Default ............................................................................................................................. 16

5.13 Profile_Name....................................................................................................................................... 16

5.14 Polarity................................................................................................................................................. 16

5.15 Max_Pres_Value.................................................................................................................................. 16

5.16 Min_Pres_Value .................................................................................................................................. 16

5.17 Resolution ........................................................................................................................................... 16

5.18 Number_Of_States.............................................................................................................................. 16

5.19 State_Text............................................................................................................................................ 17

5.20 System_Status .................................................................................................................................... 17

5.21 Vendor_Name...................................................................................................................................... 17

5.22 Vendor_Identifier ................................................................................................................................ 17

5.23 Model_Name........................................................................................................................................ 17

5.24 Firmware_Revision............................................................................................................................. 17

---------------------- Page: 3 ----------------------
CEN/TS 15231:2006 (E)

5.25 Application_Software_Revision.........................................................................................................17

5.26 Protocol_Version.................................................................................................................................18

5.27 Protocol_Revision...............................................................................................................................18

5.28 Protocol_Services_Supported ...........................................................................................................18

5.29 Protocol_Object_Types_Supported ..................................................................................................18

5.30 Object_List ...........................................................................................................................................18

5.31 Max_APDU_Length_Accepted ...........................................................................................................18

5.32 Segmentation_Supported...................................................................................................................18

5.33 APDU_Timeout ....................................................................................................................................18

5.34 Number_Of_APDU_Retries.................................................................................................................18

5.35 Device_Address_Binding ...................................................................................................................18

5.36 Database_Revision..............................................................................................................................18

5.37 COV_Increment....................................................................................................................................18

6 Mapping Rules .....................................................................................................................................19

6.1 Mapping Rules for the BACnet Device Object Type ........................................................................19

6.2 Mapping Rules for BACnet Analog Input Object Type ....................................................................19

6.3 Mapping Rules for BACnet Analog Output Object Type .................................................................20

6.4 Mapping Rules for BACnet Analog Value Object Type ...................................................................21

6.5 Mapping Rules for BACnet Binary Input Object Type .....................................................................21

6.6 Mapping Rules for BACnet Binary Output Object Type ..................................................................22

6.7 Mapping Rules for BACnet Binary Value Object Type ....................................................................22

6.8 Mapping Rules for BACnet Multi-state Input Object Type ..............................................................23

6.9 Mapping Rules for BACnet Multi-state Output Object Type ...........................................................23

6.10 Mapping Rules for BACnet Multi-state Value Object Type .............................................................24

6.11 Mapping physical and mathematical LONWORKS SNVTs..............................................................24

6.12 Mapping enumerated LONWORKS SNVTs .......................................................................................29

6.13 Mapping structured LONWORKS SNVTs..........................................................................................31

6.14 Defining Proprietary Object Types ....................................................................................................31

6.15 Defining Proprietary Properties .........................................................................................................31

6.16 Mapping other LONWORKS SNVTs...................................................................................................33

Annex A (informative) LONMARK Standard Program ID ............................................................................34

Bibliography......................................................................................................................................................35

---------------------- Page: 4 ----------------------
CEN/TS 15231:2006 (E)
Foreword

This Technical Specification (CEN/TS 15231: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 publication is copyright under the Berne Convention and the Universal Copyright Convention. No part of

this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means,

electronic, mechanical, photocopying, recording, or otherwise, without the permission of the European

Committee for Standardization (CEN), the European Committee for Electrotechnical Standardization

(CENELEC), their National Standards Bodies and their Licensees to reproduce this document in full and

including this copyright notice for the purposes of European standardisation.

This technical specification covers the methods of mapping LONWORKS objects and services to BACnet

objects and services and vice versa. The LONWORKS objects and services are defined in the standard EN

14908-1 "Control Network Protocol" and the BACnet objects and services are defined in the standard EN ISO

16484-5 "Data Communication Protocol".

According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following

countries are bound to announce this CEN Technical Specification: 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.
---------------------- Page: 5 ----------------------
CEN/TS 15231:2006 (E)
Introduction

This Technical Specification specifies methods for the mapping of objects and services of the Control Network

Protocol (CNP) , called LONWORKS (see EN 14908-1), and the Data communication protocol, called BACnet

(see EN ISO 16484-5), for exchanging information between both systems.

This Technical Specification 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 between both LONWORKS and BACnet communication systems. It specifies communication and

internal-documentation requirements.

This Technical Specification is for use by all involved in design, manufacture, engineering, installation, and

commissioning activities; and has been made in response to the essential requirements of the Construction

Products Directive.
---------------------- Page: 6 ----------------------
CEN/TS 15231:2006 (E)
1 Scope

The LONWORKS communication system is widely used in building automation systems for field-level and

application-level functions for residential and non-residential controls in lighting, sun protection, HVAC, energy

management and security applications. The BACnet communication system is also used in building

automation systems for management-level and application-level functions. This Technical Specification

defines the methods for combining BACnet networks with LONWORKS networks, and standardizes the

interface between BACnet and LONWORKS systems.
2 Normative references

The following referenced documents are indispensable for the application of this document. For dated

references, only the edition cited applies. For undated references, the latest edition of the referenced

document (including any amendments) applies.

EN ISO 16484-5:2003, Building automation and control systems — Part 5: Data communication protocolcity

(ISO 16484-5:2003).

prEN 14908-5, Open Data Communication in Building Automation - Controls and Building Management -

Control Network Protocol - Part 5: Implementation Guideline.
3 Terms and definitions

For the purposes of this Technical Specification, the following terms and definitions apply.

3.1
Functional Profile

A template that describes common units of functional behaviour. Functional profiles are also known as profiles,

or FPs; which can be represented with a machine-readable functional-profile template (FPT). Standard

functional profiles are also known as LONMARK profiles. Each functional profile consists of a profile

description and a specified set of network variables and configuration properties designed to perform a single

function on a device. The network variables and configuration properties specified by the functional profile are

called the functional-profile members. A functional profile specifies whether the implementation of each

functional-profile member is mandatory or optional. A profile is uniquely identified by a program-ID template,

scope, and functional-profile number.
3.2
LONWORKS

LONWORKS is the name of the whole technology used in LONWORKS. It describes the language, the

transceivers and the Neuron Chips. The communication is typically based on network variables organized in

functional profiles, which are standardized by LONMARK International.
3.3
LONMARK International

LONMARK International's mission is to enable the easy integration of multi-vendor systems based on CNP

networks. LONMARK INTERNATIONAL provides an open forum for member companies to work together on

marketing and technical programs to promote the availability of open, interoperable control devices.

3.4
Network Variable

A data item that a particular device application program expects to get from other devices on a network (an

input network variable) or expects to make available to other devices on a network (an output network

---------------------- Page: 7 ----------------------
CEN/TS 15231:2006 (E)

variable). Examples are a temperature, switch value, and actuator position setting. Network variable data is

typically stored in a device’s volatile memory.
3.5
Node

A node is a physical device in LONWORKS. Each LONWORKS device can be a member of maximum two

domains. In each domain a maximum number of 255 subnets with 127 devices each can be addressed.

3.6
Standard Configuration Property Type
SCPT

A configuration property type that has been standardized by LONMARK International. A SCPT is a

standardized definition of the units, scaling, encoding, valid range, and meaning of the contents of

configuration properties.
3.7
Standard Network Variable Type
SNVT
A network variable type that has been standardized by LONMARK International.
4 Object Structures
4.1 LONWORKS Objects (Functional Profile)
4.1.1 General

The primary function of a LONMARK certified device must be implemented using one or more LONMARK

profiles which represent the application layer interface of the node. Functional Profiles are divided into

mandatory and optional network variables, configuration properties, and a manufacturer defined section that is

non-interoperable. They are based on six standard objects listed below.
Table 1 — Standard LONWORKS Objects
Standard Objects Function
Monitoring on functions inside a single node; scanning from status-
Node Object
and alert functions
Detecting devices, measuring absolute values without feedback
Open Loop Sensor Object
(temperature sensor, digital contact)
Detecting devices with feedback, making a check on an actor object
Closed Loop Sensor Object
using several sensor objects or vice versa
Open Loop Actuator Object Operating devices without feedback
Closed Loop Actuator Object Operating devices with feedback
Controller Object Control algorithms
---------------------- Page: 8 ----------------------
CEN/TS 15231:2006 (E)
4.1.2 Node Object

The Node Object in a LONWORKS node implements the application-level network management of the node

as a whole. It contains two mandatory network variables (nvi_request and nvo_status).

4.1.3 Sensor Object

Sensor objects are generic objects that can be used with any form of sensor for analog values such as

temperature, pressure, humidity or for digital values of switches or buttons. Via an output network variable

nvoValue the data can be supplied directly to an actuator object or to a control loop located within a controller

object.
4.1.4 Actuator Object

The actuator objects are generic objects that may be used with any type of actuator, such as a valve, a light

dimmer or a motor. They may be controlled by a remote controller object or directly by a sensor object.

4.1.5 Closed Loop Object

A closed loop object gives a feedback to the sensor objects. It is used to synchronize sensor(s) and

actuator(s).
4.1.6 Controller Object

A controller object is used for complex algorithms to control actuator(s). The controller object is not part of the

prEN14908-5 standard.
4.1.7 Analog Output Object

The analog output object is used to integrate devices that do not have the ability to interface directly to

LONWORKS, but rather utilize an analog output conversion device that is LONMARK compliant.

4.1.8 Analog Input Object

The analog input object is used to integrate devices that do not have the ability to interface directly to

LONWORKS, but rather utilize an analog input conversion device that is LONMARK compliant.

4.2 BACnet Objects

BACnet's object types define functions in terms of semantics and the services used to access these functions.

To accomplish this task, BACnet object types contain properties. An object type consists of a non-empty

collection of properties of which some are mandatory while others may be optional.

BACnet also defines a device object. A "BACnet Device" contains a collection of instances of object types.

Each BACnet Device contains one, and only one, Device Object. Typically, each physical device corresponds

to a single BACnet Device and contains a single Device Object.
4.3 Relationship of LONWORKS to BACnet

LONWORKS SNVTs are comparable to BACnet object types. All physical and mathematical LONWORKS

SNVTs can be directly mapped to the BACnet Analog Object types. Enumeration SNVTs can be mapped to

the BACnet Multi-State-Object type. The LONWORKS Node Object is comparable to the BACnet Device

Object. For structured LONWORKS SNVTs it is necessary to define a new BACnet Object type.

---------------------- Page: 9 ----------------------
CEN/TS 15231:2006 (E)
5 Properties Needed for Mapping
5.1 Object_Identifier

The Object_Identifier must be unique internetwork-wide. The Object Type field (the upper 10 bits) contains the

enumerated value of the BACnet ObjectType.

In this mapping, the content of the 22-bit instance number field depends on whether the Object_Identifier is

identifying a Device Object or some other type of object. Subject to the uniqueness constraint, a one-to-one

mapping of LONWORKS physical devices to BACnet devices can be achieved by setting the upper 7 bits of

the instance number (bit21 to bit15) to a unique LONWORKS Node-ID and 8 bits for the Subnet-ID (bit14 to

bit 7). The rest of the 4 octet (bit6 to bit0) is used to identify the mapped network variable. Bit6 identifies the

direction of the mapped network variable. A zero value of bit6 represents an output and the value one

represents an input. So 64 input and 64 output network variables per physical LONWORKS device can be

mapped without address conflict, but this mapping is reduced only to one LONWORKS-Domain. To address

more than one LONWORKS-Domain the network variable identifier has to be split into address fields.

Commissioning a network a divisor and the used address field or fields have to be chosen. The divisor can’t

be changed after commissioning a network. But if the address field is too small for a single device, it has to be

checked for an additional available address field. The divisor and the used address field or fields are encoded

in the object name. In the Case that the Object instance is already used by another device object from an

other physical BACnet device in the network, it is necessary to use another mapping algorithm with unique

BACnet Object Identifier internetwork-wide.
Table 2 — Mapping of the Object_Identifier
Octet 1st octet 2nd octet 3rd octet 4th octet

Bit 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Node ID Subnet ID I/O Network Variable
Identifier
10 bit Object Type 22bit Object Instance
Table 3 — Network Variable Identifier (divisor=12)
Address Network Variable Identifier max.# SNVTs per
Field Range Node
domain1 1 0 - 4 5
domain2 2 5 - 9 5
domain3 3 10 - 14 5
domain4 4 15 - 19 5
domain5 5, 6 20 - 29 10
domain6 7 30 - 34 5
domain7 8 35 - 39 5
domain8 9 40 - 44 5
domain9 10 45 - 49 5
domain10 11 50 - 54 5
domain11 12 55 - 59 5
rest 13 60 - 63 4
---------------------- Page: 10 ----------------------
CEN/TS 15231:2006 (E)
5.2 Object_Name

The object name is a CharacterString generated from the device class category and device name encoded

from the LONMARK Standard Program ID followed by the NodeID, SubnetID, the divisor and the used

address field/s.
EXAMPLE Standard Program ID: 80:00:13:52:00:06:04:99
52:00 ⇒ Device Class Number = 80.10

Address: NodeID=118, SubnetID=73, Divisor=16, used address fields= 2 and 3
The Object_Name string would be “HVAC,VAV Controller,118,73,16 (2,3)”

or the same with the address field 4 would be “HVAC,VAV Controller,118,73,16 (4)”.

5.3 Object_Type

The comparable standard BACnet object type should be used. If there is no comparable BACnet object type a

new one has to be defined. In that case the object type number should be the SNVT number plus 500.

EXAMPLE SNVT_sound_db (33) should be mapped into BACnet object type 533
Table 4 — Comparable BACnet Object Types
BACnet Object Type BACnet Object Number
analog-input 0
analog-output 1
analog-value 2
binary-input 3
binary-output 4
binary-value 5
device 8
multi-state-input 13
multi-state-output 14
multi-state-value 19
5.4 Present_Value

This property contains the present value of the object type. If available use the “Invalid Value” of the used

SNVT for commissioning.
EXAMPLE SNVT_press_p (113): Invalid Value= 32,767 (0x7FFF)
Present_Value= “32,767”
---------------------- Page: 11 ----------------------
CEN/TS 15231:2006 (E)
5.5 Description

The description is a CharacterString generated from the SNVT direction, the SNVT name, the device name,

device class category followed by the selfdocumentation of the LONWORKS Node. If there is no

selfdocumentation available, use the CharacterString ”no selfdocumentation available”.

EXAMPLE “nvi, SNVT_temp_p, VAV Controller, HVAC,VAV Controller room 8.23” or
"nvo, SNVT_temp_p, VAV Controller, HVAC, no selfdocumentation available”
5.6 Status_Flags
The values for the status flags shall be set as:
IN_ALARM Always FALSE (0), because Event-State is always NORMAL.
FAULT Logical TRUE (1) if the Reliability property does not have a value of
NO_FAULT_DETECTED, otherwise logical FALSE (0).
OVERRIDDEN Logical TRUE (1) if manual override can be detected by the LONWORKS
device and is executed, otherwise always FALSE (0).

OUT_OF_SERVICE Logical TRUE (1) if the Out_Of_Service property has a value of TRUE,

otherwise logical FALSE (0).
5.7 Event_State
The value of this property is always set to NORMAL.
5.8 Reliability

The optional "Reliability" property shall, if implemented, return at least NO_FAULT_DETECTED in case that

the LONWORKS Datapoints' Quality Codes are GOOD, and UNRELIABLE_OTHER, in case at least one

LONWORKS Datapoint's Quality Code is BAD. An LONWORKS Datapoint's Quality Code is GOOD if the

datapoint can be read from (Input) or written to (Output), otherwise its Quality Code is BAD. If an

implementation is able to distinguish different sources of a failure, it may return other reliability codes of type

BACnetReliability.
5.9 Out_Of_Service

The mandatory "Out_Of_Service" property shall be set to TRUE (1) if the corresponding LONWORKS device

cannot be reached or the Present_Value cannot be read from (input) or written to (output) the device.

Otherwise this property is set to FALSE (0).
5.10 Units

The corresponding BACnet engineering unit should be used. If there is no one available, the SNVT Number

plus 500 should be used
EXAMPLE SNVT_sound_db (33) should be mapped into BACnet engineering unit 533.
---------------------- Page: 12 ----------------------
CEN/TS 15231:2006 (E)
Table 5 — LONWORKS SNVTs
Number Name Measurement Type Category Type Size
160 SNVT_abs_humid Absolute Humidity Unsigned Long 2 bytes
114 SNVT_address Neuron Chip Address Unsigned Long 2 bytes
88 SNVT_alarm Alarm status Structure 29 bytes
1 SNVT_amp Electric current Signed Long 2 bytes
139 SNVT_amp_ac Alternating electric current Unsigned Long 2 bytes
48 SNVT_amp_f Electric current Floating Point 4 bytes
2 SNVT_amp_mil Electric current Signed Long 2 bytes
3 SNVT_angle Phase/Rotation Unsigned Long 2 bytes
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.