IzoT BACnet Developer’s Guide Develop BACnet applications using the FT 6000 EVK and the FT 6050 Smart Transceiver.
Echelon, LON, LonWorks, Neuron, 3120, 3150, Digital Home, i.LON, FTXL, LonScanner, LonSupport, LNS, LonMaker, LonMark, LonPoint, LonTalk, NodeBuilder, ShortStack, and the Echelon logo are trademarks of Echelon Corporation that may be registered in the United States and other countries. Other brand and product names are trademarks or registered trademarks of their respective holders.
Contents Getting Started with BACnet ........................................................... 4 Hardware Requirements ............................................................................... 5 Compiling the BACnet Sample Projects ................................................ 5 Using BACnet ...................................................................................... 7 BACnet Terminology......................................................................................
1 Getting Started with BACnet This chapter provides the information to get started with BACnet on the IzoT network.
Hardware Requirements The following hardware is required to develop and test a BACnet application on the FT 6050 • IzoT Router – required to translate the Ethernet packets to FT-10. This device acts as an IP packet router but also contains a module that makes the IzoT Router act as a BACnet Router, per the BACnet standard. • Echelon Series 6000 EVB - for running the demos, and for the development and testing of a complete BACnet application by the user.
user to match the requirements of their site through most standard BACnet Workstations, including the BACnet Browser for IzoT. To do so, right click on the EVB ‘Device’ icon displayed in the BACnet Browser and input the desired parameters. 7. 6 Confirm that Temperature and Lux readings appear and that the output setpoint (SP on the LCD display) can be modified from the BACnet Browser.
2 Using BACnet This chapter explains the BACnet terminology and illustrates the differences between BACnet and LONWORKS.
BACnet Terminology The following terms are a brief summary of BACnet terminology. BACnet Network – A group of BACnet Devices on a single network, which may be any of BACnet’s physical layer options, namely Ethernet, RS-485, LonTalk, and now IzoT, identified by a Network Number. BACnet Internetwork – A collection of connected BACnet Networks connected via BACnet Routers. The resulting devices are all able to communicate with one another.
Differences between BACnet and LONWORKS There is a fundamental difference between BACnet and LONWORKS “Input” and “Output” concepts pertaining to physical I/O. For example, when considering a temperature sensor; when using BACnet, the temperature sensor is viewed as an “Analog Input” and displayed and processed accordingly. In a LONWORKS example, the common approach is to process the measurement internally and expose the resulting temperature as an “Analog Output” of a Function Block.
For example, in Figure 1 there is a nviSpaceTemp that is normally connected to some other nvo output from another device. If a BACnet Client is required to supply this parameter, then the BACnet Client will execute a write to the Analog Output “AO:TempSetpoint” in the Virtual BACnet Server. Internally the BACnet Stack will map this write to the nviSpaceTemp.
This is best understood by examining a LONWORKS nvi (in Figure 2), in particular nviSpaceTemp, based on the LONMARK VAV Functional Profile. In the VAV Functional Profile specification, this input can receive data either from a physical sensor, or from another LONWORKS device. The rules for choosing which value to take are laid out by LONMARK and they say that if there is a valid value from another LONWORKS device, this will override the physical input.
BACnet Interface Overview The following figure depicts the BACnet interface. Lon Network Variables Lon Application ( User Code) BACnet to Lon Mapping Configuration and Support Mapping Table Static (Flash/ EEPROM) BACnet to Lon Mapping Function Dynamic (RAM) LonTalk Stack BACnet Stack Protocol Layer – IzoT FT 6000 Based LonWorks Device LonTalk Reads and Writes BACnet Reads and Writes Figure 3.
BACnet messages that do affect the Network Variables are routed via the Mapping Functions, and then back to the LonTalk stack, where they are presented to the Application layer completely transparently to the Application Code. Note that some BACnet properties can be stored in permanent (Flash) memory. Data Flow during a LONWORKS Write to a Network Variable The following figure shows data flow when LONWORKS writes to a Network Variable.
The modified or unmodified message is passed back to the LonTalk stack for further processing as normal at this point (3). Data Flow during a LONWORKS Read of a Network Variable The BACnet stack does not participate in this task. Data Flow during an outgoing Network Variable Update When the application program on the Neuron updates a Network Variable, an outgoing LONWORKS message is generated.
BACnet Object to LONMARK SNVT Mapping – The “Mapping Table” 1. Network Variables The first issue is that SNVTs are “Structures” and BACnet objects are effectively single point values, this means that often there is one-to-many mapping required between LONWORKS and BACnet. For example, in the VAV template, nvoUnitStatus is numbered nv4, and it is a SNVT_hvac_status which has 7 fields, which means this single NV needs to expand into 7 BACnet Objects with the following Object IDs.
Device ID and Device Name The Object ID of the BACnet Device Object (“Device ID”) is required to be unique “Internetwork Wide”, as is the Object Name of the Device Object (“Device Name”). As a default, the BACnet Stack synthesizes the ObjectID and Object Name from the Neuron ID, guaranteeing uniqueness, but for most projects, you should rename and renumber your devices.
Refer to the sample source code, in particular BACsimple.nc to see how this is used. 3. BAClon\mapping.nc a. This file contains the actual mapping tables that map Network Variables to BACnet Objects 4. BAClon\mapping.h a. A header file that contains mapping macros as used by mapping.nc. It can be extended by the user if required to support UNVTs etc. Mapping BACnet Objects to Network Variables Network Variables are mapped to BACnet Objects via entries in this file.
Complex Mapping If a Network Variable has multiple fields, each field needs to be mapped to a separate BACnet Object. mapAnaToSNVT_hvac_overid__percent ( ) provides a mapping of SNVT_hvac_overid.percent to a BACnet Analog Output or Input. It is possible for a BACnet Client to both read from and write to an Output (e.g.
2. 3rd party BACnet Clients – of course, any BACnet Client, in theory, should be able to read all BACnet points served by the BACnet stack. 3. For much more rigorous testing of your application before submitting to BTL, use the BACnet Test Client linked here: http://www.bac-test.com/downloads/ 4. Wireshark is invaluable for analyzing BACnet traffic. A ‘dissector’ for BACnet packets is built in, and a white paper on its use can be found at the following link: http://www.bacnet.
Using BACnet
Appendix A Glossary This appendix provides definitions for terms discussed in this manual.
Application Device A LONWORKS device that runs an ISO/IEC 14908-1 application (OSI Layer 7). The application may run on a Neuron Chip or Smart Transceiver, in which case the device is called a “Neuron hosted” device.
Configuration Properties (CPs) Configuration properties are data values that define the behavior of an application device by determining the manner in which device application data is manipulated and when device application data is transmitted. Configuration properties can be applied to the device, functional block, or network variable level. Configuration properties can determine the functions to be performed on the values stored in network variables.
Device A device that communicates on a LONWORKS network using CNP. A device may be an application device, network service device, or a router. Devices are sometimes referred to as nodes in LONWORKS documentation. Device Interface The logical interface to a device, abbreviated as XIF. A device’s interface specifies the number and types of functional blocks; number, types, directions, and connection attributes of network variables; and the number of message tags.
Functional Block Array A set of identical functional blocks. A functional block array is useful if your device contains two or more identical switches, lights, dials, controllers, or other I/O devices that will each have an identical external interface. In addition, a functional block array saves code space and reduces the number of when-tasks in your code. Functional Profile A template for a functional block that enables equipment specifiers to select the functionality they need for a system.
OpenLNS Server Computer A computer running the OpenLNS Server software. The OpenLNS Server computer contains the OpenLNS global database, which includes the group of LONWORKS networks being managed by the OpenLNS Server, plus a network database for each network managed by the server. Out-Of-Service A BACnet Object can be marked Out-Of-Service, which then allows writes to the Present Value to take place. However, this value is not allowed to be transferred to the hardware output itself.
Managed Network A network where a shared network management server, such as LNS, is used to perform network installation. Mandatory Network Variable/Configuration Property A network variable/configuration property that must be implemented by the functional block, as specified by the functional profile that the functional block is instantiating. Monitored Connection A network variable connection in which the current values are being monitored, typically by an HMI.
Neuron Firmware A complete operating system including an implementation of the ISO/IEC 14908-1 protocol used by a Neuron Chip or Smart Transceiver. The Neuron firmware is a program that is inserted into memory of a Neuron Chip or Smart Transceiver. Neuron ID A 48-bit number assigned to each Neuron core at manufacture time. Each Neuron Chip has a unique Neuron ID, making it like a serial number.
Priority Array BACnet Outputs are never directly written to (*). A write is achieved by writing to the Present Value with a priority of 1 to 16. (With priority 1 being the highest). If the write happens to be the highest priority in the array of writes, then this value is transferred to the Present Value. If it is not the highest priority write, then the present value remains set whatever value is at the highest priority in the array.
Service Button A push button or other actuator on a LONWORKS device that is used during installation to acquire the device’s Neuron ID. For a Neuron hosted device, the button is connected to the service pin of the Neuron Chip or Smart Transceiver. When this pin is activated, the Neuron core sends a broadcast message containing its Neuron ID and program ID, which is called service pin message or packet. The method used to implement the Service button varies from device to device.
User-defined Functional Profile A non-standard functional profile defined by a device manufacturer. A user-defined functional profile should be used only when there is no appropriate standard functional profile defined. See Functional Profile for more information about functional profile templates. The NcMulitSensor example uses four UFPTs that inherit from existing SFPTs.
