SIST-TS CEN/TS 15231:2007

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
2

---------------------- 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

3

---------------------- 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.
4

---------------------- 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.
5

---------------------- 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
FP
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
NV
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
6

---------------------- 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
7

---------------------- 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.
8

---------------------- 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
th
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
9

---------------------- 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”
10

---------------------- 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.
11

---------------------- 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
10
...