Backup and Restore procedures employ File objects to contain and move configuration data. The specific content and format of this data is a concern for the developer. In addition, the choice of whether to use stream-based or record-based files is also a matter of decision for the developer.

The following is a list of services required for both Backup and Restore procedures from the standard:

• Reinitialize Device
• Read Property
• Write Property
• Atomic Read
• Atomic Write
• Create Object (optional)

Both of these procedures operate in a similar with only a singular difference. The standard further defines the following events to perform the Backup or Restore procedures:

• Procedure Initiation
• Procedure Preparation
• Load Parameters (Backup Procedure only)
• Configuration of Files
• Procedure Ending

In the Initiation phase, a Reinitialize Device message is sent from one device to another using the following structure:

• ReinitializeDevice(STARTBACKUP or RESTORE, <password>)

The sender device will wait for a response from the receiver device before continuing either procedure.

The Preparation phase entails receiving an approval or rejection from the previous phase. The following codes will indicate approval or rejection conditions:

• ‘Result(+)’ – Approval
• ‘Result(-)’ – Rejection

The Backup procedure has an additional step referred to as: Loading Parameters. At receiving an approval result, the sender device will the Configuration_Files property within the Device object. These configuration files contains vendor-specific data related to the procedures.

The next phase involves the actual Backup or Restore operation. This task is accomplished with the information from the Configuration_Files property, and through the Atomic Read and Write services.

The Ending phase for both procedures involves another Reinitialize Device message from the sender to the receiver device in the following structure from the standard:

• ReinitializeDevice (ENDBACKUP or RESTORE, <password>)

Both of the procedures will end with the approval and receipt from the previous message.

In building control applications, many automation devices have configuration data developed by the manufacturer. The developer should be aware of the procedures that the BACnet standard will use if an interoperable device Backup and Restore feature is made available in the automation device.

Written by: Scott Cosby
© Chipkin Automation Systems 2007

The developer should be aware of the manner in which this property type functions concerning priorities within building control systems.

The Priority Array is further defined by the standard as a read-only property that consists of commands that categorized by priority levels of decreasing order. NULLs may also exist in this property type as well. The highest priority will reside with the lowest array index and a non-NULL value will represent the active command.

Prioritized commands are essentially those commands that are specific towards commandable properties. The following is a parameter example from the BACnet standard:

• Property Identifier: Commandable_Property
• Property Value: Desired Value
• Priority: Priority

The following table from the BACnet standard will examine the common command priorities of the priority array:

Command entities are assigned one of the sixteen priority levels. These assignments are usually a matter for the developer.

The table may include other commands such as the following building automation related applications mentioned in the BACnet standard:

• Temperature Override
• Demand Limiting
• Duty Cycling
• Scheduling

The following priority array structure example from an actual building automation application was obtained from the Synergy lighting control system developed by Lithonia
Lighting. The following are the local priorities used for the Synergy system:

#define PRIO_PRIORITY_ON 3 /* Synergy Unique */
#define PRIO_PRIORITY_OFF 4 /* Synergy Unique */
#define PRIO_MANUAL_OPERATION 8 /* only used with flash to find */
#define PRIO_NORMAL_OPERATION 10 /* Synergy Unique */
#define PRIO_PRIORITY_LOW 13 /* Synergy Unique */

Because the BACnet standard does not specifically indicate the automation application of lighting controls. The developers at Lithonia Lighting essentially made their own priority decisions when they implemented the BACnet protocol in the Synergy design.

The following paragraph was obtained from a PDF source that describes the priority assignment for effective operation of the lighting control system by Lithonia Lighting:

“It is strongly suggested that writes intending to turn lighting ON be made at command priority 10 and writes intending to turn lighting OFF write a NULL unless the intention is to forcibly override the normal functioning of the lighting controls.”

Written by: Scott Cosby
© Chipkin Automation Systems 2007

This product has unique qualities that would be beneficial to the following areas of building automation:

• Data Management
• Building Safety
• Security Applications
• Environmental Controls

The Primer Pack/IP will offer the end-user the option to move from a static, wired system to a dynamic wireless network able to share valuable data and information to all areas of operation through Ethernet, WiFi, and other connections. The wireless network allows the user a more effective and simple integration process as well.

The Primer Pack/IP is described as a complete standards-based, wireless sensor network (WSN) application development and deployment platform. Composed of a service-oriented architecture (SOA), Internet Protocol (IP)-based networking, and a secure, reliable, responsive, low-power mesh networking.

Primer Pack/IP Set-up

The process requires the separation of the logical communication of data in such functions as naming, routing and security from the physical links that carry the data.

Recently, developers of communication networks have adopted the Internet Protocol (IP) as their common routing protocol, along with transport protocols that enable data bits to be delivered properly to their destination.
The Primer Pack/IP product should work well within BACnet due to the protocol’s communication through RS232, RS485, Ethernet, and others that conform to BACnet.

Another advantage for the BACnet protocol would be through the various services included in the protocol. Such as the following services:

• Data Sharing
• Alarms
• Scheduling
• Remote Device Management

Primer Pack/IP users can actually develop custom applications to monitor physical conditions without special programming that’s usually required to build sensor network applications. Sensor data becomes immediately available to the plant manager or field worker on the desired mobile IP device, or to the office worker in a web browser environment.

This technology removes the limitations of wired sensors, and develops networks to make that information readily accessible. In addition, the leading internet and web technology provides a platform for the networks and to further the development of varying information sources.

The San Francisco-based Arch Rock Corporation is a developer that concentrates on products and technology for wireless sensor networks. The corporation’s goal is to connect the physical and digital world through wireless sensor networks, where the data can be simply viewed, analyzed, and managed by the user.

For more information about the Arch Rock Corporation and its products, visit the following link: http://www.archrock.com/
Written by: Scott Cosby
© Chipkin Automation Systems 2007

• Life Safety Point Object Type
• Life Safety Zone Object Type

The Life Safety Point object type is defined by the standard as those objects related to fire, safety, and security applications. The condition of this object type is determined by the following two factors:

• Mode
• State

The object mode is usually under the control of the device operator. The object state indicates the controller condition depending on the internal logic of the device.

Life Safety Point object applications can include the following automation related devices:

• Automatic Fire Detectors
• Sirens
• Pull Stations

The following table will present the properties and related datatypes of the Life Safety Point object from the BACnet standard:

The Life Safety Zone object type has similar conditional and property qualities as the Life Safety Point object type, but the focus is concentrated on a group of Life Safety Point and Zone objects.

The following table will present the properties and related datatypes of the Life Safety Zone object from the BACnet standard:

The developer should pay attention to the Mode and State qualities of both Life Safety object types.

The following structure example from the standard will examine both Life Safety object types from actual automation applications. Specifically, the Point object will focus on a building smoke detector. The Zone object will examine the fire zone within a building.

Life Safety Point Object Example:
Property: Object_Identifier = (Life Safety Point, Instance 2)
Property: Object_Name = “SMK3W”
Property: Object_Type = LIFE_SAFETY_POINT
Property: Present_Value = PREALARM
Property: Tracking_Value = PREALARM
Property: Description = “Floor 3, West Zone Smoke Detector”
Property: Device_Type = “Old Smokey model 123″
Property: Status_Flags = {TRUE, FALSE, FALSE, FALSE}
Property: Event_State = LIFE_SAFETY_ALARM
Property: Reliability = NO_FAULT_DETECTED
Property: Out_Of_Service = FALSE
Property: Mode = ON
Property: Accepted_Modes = {ENABLED, DISABLED, TEST}
Property: Time_Delay = 10
Property: Notification_Class = 39
Property: Life_Safety_Alarm_Values = (ALARM)
Property: Alarm_Values = (PREALARM)
Property: Fault_Values = (FAULT)
Property: Event_Enable = {TRUE, TRUE, TRUE}
Property: Acked_Transitions = {TRUE, TRUE, TRUE}
Property: Notify_Type = ALARM
Property: Event_Time_Stamps = ((23-MAR-95, 18:50:21.2), (*-*-*, *:*:*.*),(23-MAR-95, 19:01:34.0))
Property: Silenced = SILENCE_AUDIBLE
Property: Operation_Expected = RESET_ALARM
Property: Maintenance_Required = NONE
Property: Setting = 50
Property: Direct_Reading = 84.3
Property: Units = PERCENT-OBSCURATION-PER-METER
Property: Member_Of = ((Life Safety Zone, Instance 5))

Life Safety Zone Object Example:
Property: Object_Identifier = (Life Safety Zone, Instance 2)
Property: Object_Name = “SMK3″
Property: Object_Type = LIFE_SAFETY_ZONE
Property: Present_Value = PREALARM
Property: Tracking_Value = PREALARM
Property: Description = “Floor 3 Smoke”
Property: Status_Flags = {TRUE FALSE, FALSE, FALSE}
Property: Event_State = LIFE_SAFETY_ALARM
Property: Reliability = NO_FAULT_DETECTED
Property: Out_Of_Service = FALSE
Property: Mode = ON
Property: Accepted_Modes = {ENABLED, DISABLED, TEST}
Property: Time_Delay = 10
Property: Notification_Class = 39
Property: Life_Safety_Alarm_Values = (ALARM)
Property: Alarm_Values = (PREALARM)
Property: Fault_Values = (FAULT)
Property: Event_Enable = {TRUE, TRUE, TRUE}
Property: Acked_Transitions = {TRUE, TRUE, TRUE}
Property: Notify_Type = ALARM
Property: Event_Time_Stamps = ((23-MAR-95, 18:50:21.2), (*-*-*, *:*:*.*),(23-MAR-95,19:01:34.0))
Property: Silenced = UNSILENCED
Property: Operation_Expected = SILENCE_AUDIBLE
Property: Maintenance_Required = NONE
Property: Zone_Members = ((Life Safety Point, Instance 22),(Life Safety Point, Instance 23))
Property: Member_Of = ((Life Safety Zone, Instance 5))

Written by: Scott Cosby

© Chipkin Automation Systems 2007

• Boolean
• Integer
• Unsigned
• Enumerated
• Real

The following table will present the actual properties and associated datatypes of the Averaging object from the BACnet standard:

The developer should pay particular attention to the following properties of this object:

• Window_Interval property
• Window_Samples property
• Object_Property_Reference property

The Window_Interval property indicates the period of time, usually in seconds which the minimum, maximum, and average values are calculated.

The Window_Samples property represents the number of samples to be taken during the timeperiod within the Window_Interval property. In addition, the Window_Samples must be greater than zero and all implementations should support at least 15 samples. The sample may represent an instant or continuously calculated sample, which will be considered a matter for the developer.

The Object_Property_Reference property identifies the object and property whose value will be sample during the Window_Interval. The referenced object may reside in the device that contains the Averaging object or within other supported devices.

The Averaging object uses a specialized technique referred by the standard as a “sliding window” that maintains a buffer of samples distributed over the specified time interval. At every time interval a new sample is replaces the oldest sample from the buffer.

The buffer maintains an indication for each sample that permits the average calculation and minimum/maximum algorithm to determine the number of valid samples in the buffer.

The following example from the BACnet standard will present the Averaging object structure from an actual automation application. Specifically, this example focuses on the average and maximum electrical usage in kilowatts (KW) on a specific floor of a building:

Property: Object_Identifier = (Averaging, Instance 1)
Property: Object_Name = “FLR 12 DEMAND”
Property: Object_Type = AVERAGING
Property: Minimum_Value = 2.4
Property: Minimum_Value_Timestamp = (16-DEC-1999,13:15:07.32)
Property: Average_Value = 12.7
Property: Maximum_Value = 18.8
Property: Maximum_Value_Timestamp = (16-DEC-1999,13:06:12.19)
Property: Description = “Floor 12 Electrical Demand”
Property: Attempted_Samples = 15
Property: Valid_Samples = 14
Property: Object_Property_Reference = (Analog Input, Instance 12)
Property: Window_Interval = 900
Property: Window_Samples = 15

Written by: Scott Cosby

© Chipkin Automation Systems 2007

The type of processes monitored can include those tasks in maintaining a building. Such as the following examples:

• Power Usage
• Water Usage
• Natural Gas Usage

The Pulse Converter object might represent a physical input. As an alternative, it might acquire the data from the Present_Value of an Accumulator object, representing an input in the same device as the Pulse Converter object.

The following table will present the actual properties and associated datatypes of the Group object from the BACnet standard:

The developer should pay close attention to a specific property in the preceding table. The specific property is the Adjust_Value property. This property allows the developer to adjust the Present_Value property by writing to the Adjust_Value property, which also causes an adjustment to the Count property as well.

The following example from the BACnet standard will present the Pulse Converter object structure from an actual automation application. This example will specifically focus on the utility usage in a building:

Property: Object_Identifier = (Pulse Converter, Instance 1)
Property: Object_Name = “Meter 5″
Property: Object_Type = PULSE_CONVERTER
Property: Description = “”
Property: Present_Value = 125.0
Property: Input_Reference = ((Accumulator, Instance 1), Present_Value)
Property: Status_Flags = {FALSE, FALSE, FALSE, FALSE}
Property: Event_State = NORMAL
Property: Out_Of_Service = FALSE
Property: Units = LITERS_PER_HOUR
Property: Scale_Factor = 0.5
Property: Adjust_Value = 500.0
Property: Count = 250
Property: Update_Time = (10-JUL-01,11:40:21.0),
Property: Count_Change_Time = (10-JUL-01,11:30:01.0),
Property: Count_Before_Change = 523
Property: COV_Increment = 10.0
Property: COV_Period = 3600
Property: Notification_Class = 5
Property: Time_Delay = 0
Property: High_Limit = 1000.0
Property: Low_Limit = 0.0
Property: Deadband = 0.0
Property: Limit_Enable = {FALSE, TRUE}
Property: Event_Enable = {TRUE, FALSE, TRUE}
Property: Acked_Transitions = {TRUE, TRUE, TRUE}
Property: Notify_Type = ALARM
Property: Event_Time_Stamps = ((12-JUL-01,18:50:21.2), (*-*-*,*:*:*.*), (12-JUL-01,19:01:34.0))

Written by: Scott Cosby

© Chipkin Automation Systems 2007

BACnet emphasizes efficient, lightweight communication and optimized for small networks, small inter-networks, and short messages.

BACnet consists of a collapsed architecture that corresponds to four layers of the Open Systems Interconnection (OSI) model. The seven layer reference model is an international standard for conceptualizing network communication protocols and is widely used as the basis of many data communications standards.

The four layers from the OSI model within the BACnet architecture includes:

• Application
• Network
• Data Link
• Physical

Since BACnet is a non-connection protocol, the need for message segmentation and end-to-end error checking is much less than in a connection-based protocol. Thus, the overhead of a discrete transport layer is not justified and the functions normally in a transport layer are delegated to the application layer. In addition, the session layer is not needed, and since BACnet uses a fixed encoding scheme and offloads security to the application layer, a separate presentation layer is not needed.

The following figure from the standard examines the basic structure of the OSI model:

Figure 1. Basic OSI Structure.

The next figure from the standard will present the BACnet architecture with the equivalent OSI layers to the developer:

Figure 2. BACnet Architecture.The collapsed architecture was chosen due to the specific features and requirements of BAC networks, including a requirement that the protocol overhead be minimized as much as possible.

BAC networks are local area networks (LAN). This is true even though in some applications it is necessary to exchange information with devices in a building that is very far away. The long-distance communication is done through telephone networks. The routing, relaying, and guaranteed delivery issues are handled by the telephone system and can be considered external to the BAC network.

BAC devices are static. They don’t move from place to place and the functions that they are asked to perform do not change in the sense that a manufacturing device may make one kind of part today and some very different part tomorrow.

BACnet defines a protocol optimized for reliable and brief object messaging on a LAN. Based on the OSI model, BACnet is readily extended to many domains outside of the building automation and control networks for which it was originally intended, such as management applications and embedded control. In many of these applications, a specific part of BACnet can be applied with great benefit.

All developers should maintain an understanding of the BACnet architecture, especially when selecting devices for building automation applications.

Written by: Scott Cosby

© Chipkin Automation Systems 2007

The Group object is essentially used to simplify the information exchange between BACnet devices through a shorthand method to specify all group members at once.

The developer should be aware that a group can be formed through any combination of object types.

The following table will present the actual properties and associated datatypes of the Group object from the BACnet standard:

Property	Datatype
Object_Identifier	BACnet Object Identifier
Object_Name	Character String
Object_Type	BACnet Object Type
Description	Character String
List_of_Group_Members	List of Read Access Specification(s)
Present_Value	List of Read Access Result(s)
Profile_Name	Character String

The developer should pay close attention to two properties in the preceding table. The properties include:

• List_of_Group_Members property
• Present_Value property

The List_of_Group_Members represents a list of read access specification(s) that defines the group members that will be referenced when the object is specified in a standard transaction.

The Present_Value property represents the result from the read access specification(s). This property is a list that contains the values of all the properties specified in the List_Of_Group_Members. This is a “read only” property; and it cannot be used to write a set of values to the members of the group. The Present_Value list is reconstructed each time the property is read by retrieving the member properties. This requirement is required to reduce problems that could result if the Present_Value were stored.

Each of these read access specification(s) contains two essential parts:

• Object_Identifier
• Property Reference List

In addition, all group members should be objects that are in the same device that maintains the Group object.

The following example from the BACnet standard will present the Group object structure from an actual automation application. This example will specifically reference the air temperatures in a particular area or “zone” of a building:

Property: Object_Identifier = (Group, Instance 1)
Property: Object_Name = “ZONE1_TEMPS”
Property: Object_Type = GROUP
Property: Description = “Zone 1 Temperature Group”
Property: List_Of_Group_Members = (((Analog Input, Instance 8),(Present_Value, Reliability, Description)), ((Analog Input, Instance 9),(Present_Value, Reliability, Description)), ((Analog Input, Instance 10), (Present_Value, Reliability, Description)),
((Analog Input, Instance 11),(Present_Value, Reliability, Description)),((Analog Input, Instance 12),(Present_Value, Reliability, Description)))
Property: Present_Value = (((Analog Input, Instance 8), Present_Value, 69.7, Reliability, NO_FAULT_DETECTED, Description, “Room 1″), ((Analog Input, Instance 9), Present_Value, 71.2, Reliability, NO_FAULT_DETECTED, Description, “Room 2″),
((Analog Input, Instance 10), Present_Value, -50.0, Reliability, UNRELIABLE_OTHER, Description, “Room 3″), ((Analog Input, Instance 11), Present_Value, 69.7, Reliability,
NO_FAULT_DETECTED, Description, “Room 4″), ((Analog Input, Instance 12), Present_Value, 73.3, Reliability, NO_FAULT_DETECTED, Description, “Room 5″))

Written by: Scott Cosby

© Chipkin Automation Systems 2007

File Services is listed in the standard as Clause 14. The clause describes the access and manipulation of files within BACnet devices. The developer has two options regarding file types accessed through File Services:

• Vendor defined files
• Bacnet standard files

Any file accessible through File Services has a related File object in a BACnet device.

The primary purpose of the File object is to identify a specific file through the following descriptions:

• File Name
• File Size
• Creation Date
• File Type

The following table will present the actual properties and associated datatypes of the File object from the BACnet standard:

The developer should be aware that File Services has two specific operations:

• Atomic Read
• Atomic Write

The meaning of Atomic is defined in the standard as a singular operation in that no other similar operation is permitted for the same file. In addition, the synchronization of these operations is matter for the developer.

The following two tables will examine the structure of the Atomic Read and Write operations:

Atomic Read Structure Table

Atomic Write Structure Table:

M – Mandatory parameter.
C – Conditional parameter.
S – Selection parameter from a collection of two or more possible parameters.

The code “=” following one of the codes M, C, or S indicates that the parameter is equivalent to the parameter to its immediate left in the table.

The following example from the BACnet standard will present the File object structure from an actual automation application. This example will specifically examine a File object that contains trend information:

Property: Object_Identifier = (File, Instance 7)
Property: Object_Name = “TREND_AI1″
Property: Object_Type = FILE
Property: Description = “Trend of AI1″
Property: File_Type = “TREND”
Property: File_Size = 750
Property: Modification_Date = (1-NOV-1995, 08:30:49.0)
Property: Archive = FALSE
Property: Read_Only = FALSE
Property: File_Access_Method= RECORD_ACCESS
Property: Record_Count = 150

Written by: Scott Cosby

© Chipkin Automation Systems 2007

The central purpose for the Event Enrollment object is to define an event, and offer the developer a connection between the event occurrence and the transmission of notification messages.

The Event Enrollment object contains the following information for effective operation:

• Event Type Description
• Event Occurrence Notification
• Device Notification

The following table will present the actual properties and associated datatypes of the Event Enrollment object from the BACnet standard:

The BACnet standard states that there’s a specific relationship among three properties:

• Event_Type
• Event_State
• Event_Parameters

The Event_Type represents the algorithm used to determine the Event_State. The Event_Parameters property provides certain parameters required by the algorithm. The developer should pay special attention to the relationship of these three properties.

The following table from the standard will examine the three properties and their associated values:

The next two examples from the standard will reveal the Event Enrollment object structure from an actual automation application. Specifically, the two examples will involve temperature control in a certain room of a building:

Property: Object_Identifier = (Analog Input, Instance 2)
Property: Object_Name = "Zone1_Temp"
Property: Object_Type = ANALOG_INPUT
Property: Present_Value = 86.0
Property: Description = "Receptionist Lobby Temp"
Property: Device_Type = "PT 3K RTD"
Property: Status_Flags = {FALSE, FALSE, FALSE, FALSE}
Property: Event_State = NORMAL
Property: Reliability = NO_FAULT_DETECTED
Property: Out_Of_Service = FALSE
Property: Update_Interval = 5
Property: Units = DEGREES_FAHRENHEIT
Property: Min_Pres_Value = 55.0
Property: Max_Pres_Value = 95.0
Property: Resolution = 0.1

The Analog_Input object above is assumed for the following Change_of_Value Event example, and the object is located in Device 12.

Property: Object_Identifier = (Event Enrollment, Instance 2)
Property: Object_Name = "Zone1TempCOV"
Property: Object_Type = EVENT_ENROLLMENT
Property: Description = "Zone 1 Temperature COV"
Property: Event_Type = CHANGE_OF_VALUE
Property: Notify_Type = EVENT
Property: Event_Parameters = (5, 0.25)
Property: Object_Property_Reference = ((Device, Instance 12),(Analog Input, Instance 2), Present_Value)
Property: Event_State = NORMAL
Property: Event_Enable = (TRUE, FALSE, FALSE)
Property: Acked_Transitions = (TRUE, TRUE, TRUE)
Property: Event_Time_Stamps = ((23-MAR-95,18:50:21.2),(*-*-*,*:*:*.*),(23-MAR-95,19:01:34.0))

Written by: Scott Cosby

© Chipkin Automation Systems 2007