add-135-2008l-pub-draft chair-approved -pdf · 135-2008l-1. add new workstation bibbs and profiles,...

ASHRAE STANDARDASHRAE STANDARD

ANSI/ASHRAE Addendum l toANSI/ASHRAE Standard 135-2008

BACnet®—A DataCommunication Protocolfor Building Automationand Control Networks

Approved by the ASHRAE Standards Committee on June 20, 2009; by the ASHRAE Board of Directors onJune 24, 2009; and by the American National Standards Institute on June 25, 2009.

This standard is under continuous maintenance by a Standing Standard Project Committee (SSPC) for whichthe Standards Committee has established a documented program for regular publication of addenda or revi-sions, including procedures for timely, documented, consensus action on requests for change to any part ofthe standard. The change submittal form, instructions, and deadlines may be obtained in electronic form fromthe ASHRAE Web site, http://www.ashrae.org, or in paper form from the Manager of Standards. The latest edi-tion of an ASHRAE Standard may be purchased from ASHRAE Customer Service, 1791 Tullie Circle, NE,Atlanta, GA 30329-2305. E-mail: [email protected]. Fax: 404-321-5478. Telephone: 404-636-8400 (world-wide), or toll free 1-800-527-4723 (for orders in US and Canada).

© Copyright 2009 American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc.

ISSN 1041-2336

American Society of Heating, Refrigeratingand Air-Conditioning Engineers, Inc.

1791 Tullie Circle NE, Atlanta, GA 30329www.ashrae.org

ASHRAE Standing Standard Project Committee 135Cognizant TC: TC 1.4, Control Theory and Application

SPLS Liaison: Douglas T. Reindl

*Denotes members of voting status when the document was approved for publication

David Robin, Chair* David G. Holmberg Carl J. RutherCarl Neilson, Vice-Chair Bernhard Isler* David G. ShikeSharon E. Dinges, Secretary* Robert L. Johnson Ted SunderlandDonald P. Alexander* Stephen Karg* William O. Swan, IIIBarry B. Bridges* Simon Lemaire David B. Thompson*Coleman L. Brumley, Jr.* J. Damian Ljungquist* Stephen J. Treado*Ernest C. Bryant James G. Luth J. Michael Whitcomb*

John J. Lynch

ASHRAE STANDARDS COMMITTEE 2008–2009

Hugh F. Crowther, ChairSteven T. Bushby, Vice-ChairRobert G. BakerMichael F. BedaDonald L. BrandtPaul W. CabotKenneth W. CooperSamuel D. Cummings, JrK. William DeanMartin DierycxkRobert G. DoerrAllan B. FraserNadar R. JayaramanByron W. Jones

Jay A. KohlerCarol E. MarriottMerle F. McBride

Frank MyersH. Michael Newman

Janice C. PetersonDouglas T. Reindl

Lawrence J. SchoenBoggarm S. Setty

Bodh R. SubherwalWilliam F. Walter

Michael W. WoodfordDavid E. Knebel, BOD ExO

Andrew K. Persily, COStephanie Reiniche, Manager of Standards

SPECIAL NOTE

This American National Standard (ANS) is a national voluntary consensus standard developed under the auspices of the AmericanSociety of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE). Consensus is defined by the American National StandardsInstitute (ANSI), of which ASHRAE is a member and which has approved this standard as an ANS, as “substantial agreement reached bydirectly and materially affected interest categories. This signifies the concurrence of more than a simple majority, but not necessarily unanimity.Consensus requires that all views and objections be considered, and that an effort be made toward their resolution.” Compliance with thisstandard is voluntary until and unless a legal jurisdiction makes compliance mandatory through legislation.

ASHRAE obtains consensus through participation of its national and international members, associated societies, and public review.ASHRAE Standards are prepared by a Project Committee appointed specifically for the purpose of writing the Standard. The Project

Committee Chair and Vice-Chair must be members of ASHRAE; while other committee members may or may not be ASHRAE members, allmust be technically qualified in the subject area of the Standard. Every effort is made to balance the concerned interests on all ProjectCommittees.

The Manager of Standards of ASHRAE should be contacted for:a. interpretation of the contents of this Standard,b. participation in the next review of the Standard,c. offering constructive criticism for improving the Standard, ord. permission to reprint portions of the Standard.

DISCLAIMER

ASHRAE uses its best efforts to promulgate Standards and Guidelines for the benefit of the public in light of available information andaccepted industry practices. However, ASHRAE does not guarantee, certify, or assure the safety or performance of any products, components,or systems tested, installed, or operated in accordance with ASHRAE’s Standards or Guidelines or that any tests conducted under itsStandards or Guidelines will be nonhazardous or free from risk.

ASHRAE INDUSTRIAL ADVERTISING POLICY ON STANDARDS

ASHRAE Standards and Guidelines are established to assist industry and the public by offering a uniform method of testing for ratingpurposes, by suggesting safe practices in designing and installing equipment, by providing proper definitions of this equipment, and by providingother information that may serve to guide the industry. The creation of ASHRAE Standards and Guidelines is determined by the need for them,and conformance to them is completely voluntary.

In referring to this Standard or Guideline and in marking of equipment and in advertising, no claim shall be made, either stated or implied,that the product has been approved by ASHRAE.

© 2009, American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc. (www.ashrae.org). For personal use only. Additional reproduction, distribution, or transmission in either print or digital form is not permitted without ASHRAE’s prior written permission.

© 2009 American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc. (www.ashrae.org). For personal use only. Additional reproduction, distribution, or transmission in either print or digital form is not permitted without ASHRAE’s prior written permission. [This foreword and the “rationale” on the following page are not part of this standard. They are merely informative and do not contain requirements necessary for conformance to the standard.]

FOREWORD Addendum 135l to ANSI/ASHRAE Standard 135-2008 contains a number of changes to the current standard. These modifications are the result of change proposals made pursuant to the ASHRAE continuous maintenance procedures and of deliberations within Standing Standard Project Committee 135. The changes are summarized below. 135-2008l-1. Add new workstation BIBBs and profiles, p. 2. In the following document, language to be added to existing clauses of ANSI/ASHRAE 135-2008 and Addenda is indicated through the use of italics, while deletions are indicated by strikethrough. Where entirely new subclauses are added, plain type is used throughout.

© 2009 American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc. (www.ashrae.org). For personal use only. Additional reproduction, distribution, or transmission in either print or digital form is not permitted without ASHRAE’s prior written permission.

2 ANSI/ASHRAE Addendum l to ANSI/ASHRAE Standard 135-2008

135-2008l-1. Add new workstation BIBBs and profiles. Rationale The original B-OWS profile is insufficient for specifying the minimum capabilities of a basic operator workstation; additional BIBBs are required. Also needed are new profiles for other kinds of workstations. Addendum 135-2008l-1 [Add new Clauses 3.2.55 and 3.2.56 and renumber following clauses, p. 5]

3.2.55 standard object type: an object type defined by this standard where the numerical value is within the range reserved for ASHRAE. 3.2.56 standard property: a required or optional property of a standard object type where the numerical value of the property identifier is within the range reserved for ASHRAE and the property is listed in the object type’s properties table in Clause 12.

[Add new Clause K.1.X1, p.629.]

K.1.X1 BIBB - Data Sharing - View - A (DS-V-A)

The A device retrieves values from a minimum set of objects and properties and presents them to the user. Devices claiming conformance to DS-V-A shall support DS-RP-A. Device A shall be capable of using ReadProperty to retrieve any of the properties listed below. Device A may use alternate services where support for execution of the alternate service is supported by Device B.

BACnet Service Initiate Execute

ReadProperty x

Devices claiming conformance to DS-V-A shall be capable of reading and displaying the object properties listed in Table K-X1.

Table K-X1. Properties for Which Presentation Is Required

Analog Objects Binary Objects Accumulator Averaging Object_Name Present_Value Status_Flags Units

Object_Name Present_Value Status_Flags

Object_Name Present_Value Status_Flags Value_Before_Change Value_Set Pulse_Rate

Object_Name Minimum_Value Average_Value Maximum_Value

Command Device Event Enrollment Load Control Object_Name Present_Value In_Process All_Writes_Successful

Object_Name System_Status

Object_Name Event_State Object_Property_Reference

Object_Name Present_Value Status_Flags State_Description

Loop Multi-state Objects Program Pulse Converter Object_Name Present_Value Status_Flags Setpoint

Object_Name Present_Value Status_Flags

Object_Name Program_State

Object_Name Present_Value Status_Flags Adjust_Value

The format of a presented property value is unrestricted; the intent of this BIBB is not to impose how, or in what form, a device displays data values. For example, enumerated values could be displayed as icons, references could be displayed using the referenced object's name, numerical values could be displayed graphically.


ANSI/ASHRAE Addendum l to ANSI/ASHRAE Standard 135-2008 3

Actions taken by Device A when retrieval of a value for display fails are a local matter.

Devices claiming conformance to this BIBB are not required to support presentation of objects and properties that are introduced in a Protocol_Revision newer than that claimed by the A device. A device claiming support for DS-V-A is interoperable with devices that support DS-RP-B and support one or more of the objects listed in table K-X1.

[Add new Clause K.1.X2, p.629.]

K.1.X2 BIBB - Data Sharing - Advanced View - A (DS-AV-A)

The A device retrieves property values and presents them to the user. Device A shall be capable of using ReadProperty to retrieve any standard property of any standard object type excluding the Life Safety and Access Control objects (e.g., Life Safety Point, Life Safety Zone, Access Door), except for those properties listed in Table K-X2 and any property defined by the standard as not readable via ReadProperty. Device A may use alternate services where support for execution of the alternate service is supported by Device B.


ReadProperty x

The information conveyed by the properties in Table K-X2 can be otherwise determined and as such need not be read and presented by devices claiming conformance to DS-AV-A.

Table K-X2. Excluded Standard Properties

Object_Identifier Object_Type



In order to ensure that products that claim support for DS-AV-A are capable of presenting accurate data values across the full range of values for each data type, devices claiming support for DS-AV-A shall be able to meet the requirements described in Table K-X3.

Table K-X3. Presentation Requirements by Datatype

Enumerated Present the complete range of standard values defined for all standard enumeration types for the Protocol_Revision claimed by the A device. The actual presentation of the values is unrestricted (text, numeric, iconic, etc) as long as the individual values are distinguishable.

REAL, Double

Present the complete value range, including special values such as +-INF and NaN, unless specifically restricted by the standard for the property being displayed.

Unsigned, Unsigned8, Unsigned16, Unsigned32

Present the complete value range, unless specifically restricted by the standard for the property being displayed. The minimum displayable range for Unsigned by DS-AV-A devices is the same as Unsigned32 with the exception of array indexes, which shall have a minimum displayable range of Unsigned16. In addition, any Unsigned property whose value is also used as an array index, such as a Multi-state object's Present_Value, shall have a minimum displayable range of Unsigned16.

INTEGER Present the complete value range, unless specifically restricted by the standard for the property being displayed. The minimum displayable range for INTEGER shall be -2147483648...2147483647.

Date Present all valid dates, including values that contain unspecified values (0xFF) or special values (such as ‘even days’). Where the month, day and year fields all contain singular specified values, the content of the DayOfWeek field may be ignored. The format is unrestricted as long as each valid value is uniquely presented.

Time Present all valid times, including values that contain unspecified values. The format is unrestricted as long as each valid value is uniquely presented.

BIT STRING Present the complete range of standard values defined for all standard bit string types for the Protocol_Revision claimed by the A device. The actual presentation of the values is unrestricted (text, numeric, iconic, etc) as long as the individual values are distinguishable.

BOOLEAN Present all valid values. The format is unrestricted as long as each valid value is distinguishable.

NULL Present NULL values. The format is unrestricted as long as NULL is distinguishable from other values.

BACnetObjectIdentifier Present all valid values. The format is unrestricted as long as each valid value is distinguishable. It is acceptable that BACnetObjectIdentifier values be replaced with unique object identification values such as the object’s name, where available.



For Character String property values, the A device shall be capable of presenting string values for specific BACnet properties with at least the number of characters, independent of their encoding, specified in Table K-X4.

Table K-X4. Minimum Character-String Lengths

Action_Text 32 Application_Software_Version 64 Description 255 Description_Of_Halt 64 Device_Type 64 File_Type 32 Firmware_Revision 64 Inactive_Text/Active_Text 32 Instance_Of 64 Location 64 Model_Name 64 Object_Name 64 Profile_Name 64 State_Text 32 Vendor_Name 64 All other character string properties 32

The above presentation requirements are not required to be applied in all circumstances, but rather shall be available for every property value in the system. This should allow a product to restrict its presentation under specific conditions yet still allow the user full access to any specific property value.

The A device shall be capable of reading and presenting all standard forms of the datatypes as defined per the A device's claimed Protocol_Revision. Actions taken by Device A when retrieval of a value for display fails are a local matter.

Devices claiming conformance to this BIBB are not required to support presentation of objects and properties that are introduced in a Protocol_Revision newer than that claimed by the A device. A device claiming support for DS-AV-A is interoperable with devices that support DS-RP-B.

[Add new Clause K.1.X3, p. 629.]

K.1.X3 BIBB - Data Sharing – Modify - A (DS-M-A)

The A device writes properties that are generally expected to be adjusted during normal operation of the system. Devices claiming support for this BIBB are not expected to be capable of fully configuring BACnet devices, although they are not inherently restricted from doing so.


WriteProperty x



Devices claiming conformance to DS-M-A shall be capable of commanding and relinquishing standard commandable properties at priority 8 (other priorities may also be supported), and writing the properties listed in Table K-X5.

Table K-X5. Standard Properties That DS-M-A Devices Shall Be Capable of Writing

Analog Objects, Binary Objects, Accumulator, Averaging, Loop, Multi-state Objects, Pulse Converter

Command, Event Enrollment, Program

Pulse Converter Program Accumulator Loop

Present_Value Out_Of_Service

Present_Value Adjust_Value Program_Change Value_Before_Change Value_Set Pulse_Rate

Setpoint

Devices claiming support for this BIBB shall be capable of writing values within the full range as defined in Table K-X6.

Table K-X6. Minimum Writable Value Ranges Datatype Value Range NULL NULL Boolean All valid values. Unsigned8 The complete value range (0..255). Unsigned16 The complete value range (0..65535). Unsigned, Unsigned32 The complete value range (0..4294967295) with the exception of array

indexes which shall have a minimum writable range of Unsigned16. In addition, any Unsigned property whose value is also used as an array index, such as a Multi-state object's Present_Value, shall have a minimum writable range of Unsigned16.

INTEGER The complete value range (-2147483648...2147483647) REAL Valid values across the complete range of the datatype except the special

values such as INF, -INF, NaN, etc. The presision of values that can be written may be restricted.

Double Valid values across the complete range of the datatype except the special values such as INF, -INF, NaN, etc. The precision of values that can be written may be restricted.

Enumerated The standard values defined for the property being modified as defined by the claimed Protocol_Revision of the A device.

BACnetObjectIdentifier All valid values. Character String Strings up to lengths described in Table K-X4.

Devices claiming conformance to this BIBB are not required to support presentation and modification of objects and properties that are introduced in a Protocol_Revision newer than that claimed by the A device. A device claiming support for DS-M-A is interoperable with devices that support DS-WP-B and support one or more of the objects listed in table K-X1.


K.1.X4 BIBB - Data Sharing – Advanced Modify - A (DS-AM-A)

The A device is able to use WriteProperty to modify any standard property of any standard object type excluding the Life Safety and Access Control objects (e.g., Life Safety Point, Life Safety Zone, Access Door) where the property is not required to be read-only, or to which access is otherwise restricted by the standard (e.g. Log_Buffer). Devices shall be



capable of commanding and relinquishing standard commandable properties at any priority. Device A may use alternate services where support for execution of the alternate service is supported by Device B.


WriteProperty x

Devices claiming support for this BIBB shall be capable of writing values within the full range as defined in Table K-X6.

The A device shall be capable of writing all standard forms of the datatypes as defined per the A device's claimed Protocol_Revision.

Devices claiming conformance to this BIBB are not required to support presentation and modification of objects and properties that are introduced in a Protocol_Revision newer than that claimed by the A device.

A device claiming support for DS-AM-A is interoperable with devices that support DS-WP-B and support one or more of the objects listed in table K-X1.


K.2.X1 BIBB - Alarm and Event Management – View Notifications - A (AE-VN-A)

Device A presents basic alarm and event notifications to the user. Device A shall support AE-N-A and shall be capable of presenting any alarm or event notifications covered by AE-N-A to the user. The information conveyed to the user shall include identification of the event-generating object or the monitored object, the event's timestamp and the event's Message Text. Any other information conveyed to the user shall be consistent with the data contained in the notification.


ConfirmedEventNotification x UnconfirmedEventNotification x

Device A shall be capable of presenting at least 32 characters of Message Text, although it is suggested that devices claiming this BIBB be capable of displaying 255 characters of Message Text.

A device claiming support for AE-VN-A is interoperable with devices that support AE-N-B.


K.2.X2 BIBB - Alarm and Event Management – Advanced View Notifications - A (AE-AVN-A)

Device A presents complete alarm and event notifications to the user. Device A shall support AE-VN-A. In addition to the requirements of AE-VN-A, Device A shall be capable of presenting the event Notification Class, Priority, Notify Type, Ack Required, To State and Event Values to the user. Device A shall be capable of presenting at least 255 characters of Message Text.


ConfirmedEventNotification x UnconfirmedEventNotification x

A device claiming support for AE-AVN-A is interoperable with devices that support AE-N-B.


K.2.X3 BIBB - Alarm and Event Management - View and Modify - A (AE-VM-A)

Device A displays and modifies limits and related parameters in alarm generating objects.



Device A shall support DS-RP-A and DS-WP-A. The A device shall be capable of using ReadProperty to retrieve and WriteProperty to modify any of the properties listed below. Device A may use alternate services where support for execution of the alternate service is supported by Device B.


ReadProperty x WriteProperty x

Devices claiming conformance to AE-VM-A shall be capable of reading, presenting and writing alarming related properties from the following standard object types:

Table K-X7. Object Types for Which Presentation Is Required

Accumulator Analog Input Analog Output Analog Value

Event Enrollment Loop Pulse Converter

Table K-X8. Properties AE-VM-A That Devices Shall Be Capable of Presenting and Modifying

Accumulator Analog Objects Event Enrollment Loop Pulse Converter High_Limit Low_Limit Limit_Monitoring_Interval

High_Limit Low_Limit Deadband

Event_Parameters Error_Limit High_Limit Low_Limit Deadband

Devices claiming support for this BIBB shall be capable of writing values within the full range as defined in Tables K-X3 and K-X4. Such devices need only be capable of presenting and modifying Event_Parameters for the standard algorithms that have high and low numerical limits, such as OUT_OF_RANGE, and FLOATING_LIMIT


A device claiming support for AE-VM-A is interoperable with devices that support AE-N-B.


K.2.X4 BIBB - Alarm and Event Management - Advanced View and Modify - A (AE-AVM-A)

Device A configures alarm generating objects and Notification class objects in Device B. Device A shall support DS-RP-A, DS-WP-A, and DM-OCD-A. The A device shall be capable of using ReadProperty to retrieve and WriteProperty to modify any of the properties listed below. Device A may use alternate services where support for execution of the alternate service is supported by Device B. Device A shall be capable of creating/deleting Event Enrollment and Notification Class objects in the B device.


CreateObject x DeleteObject x ReadProperty x WriteProperty x



Devices claiming conformance to AE-AVM-A shall be capable of reading, presenting and writing alarming-related properties from the standard object types listed in Table X-9.

Table K-X9. Object Types for Which Presentation Is Required

Accumulator Analog Input Analog Output Analog Value Binary Input

Binary Output Binary Value Event Enrollment Loop Multi-state Input

Multi-state Output Multi-state Value Notification Class Pulse Converter

Table K-X10. Properties That AE-AVM-A Devices Shall Be Capable of Presenting and Modifying All Object Types1 (from Table K-X9) Accumulator Analog Objects Acked_Transitions2 Event_State2 Event_Enable Notification_Class Event_Time_Stamps2

Time_Delay

Pulse_Rate High_Limit Low_Limit Limit_Monitoring_Interval

Limit_Enable High_Limit Low_Limit Deadband

Binary Input, Binary Value Binary Output Event Enrollment Alarm_Value Feedback_Value2 Object_Property_Reference

Event_Parameters Notify_Type

Loop Multi-state Input, Multi-state Value Multi-state Output Error_Limit Alarm_Values

Fault_Values Feedback_Value1

Notification Class Pulse Converter Priority Ack_Required Recipient_List

Limit_Enable High_Limit Low_Limit Deadband

1 For object types that include these properties. 2 AE-AVM-A devices need only be capable of presenting these properties; not modifying them.

Devices claiming support for this BIBB shall be capable of writing the full range of values as defined in Tables K-X3 and K-X4. Such devices shall also be capable of writing any standard form of the Event_Parameters property to any Event Enrollment object (excluding BUFFER_READY) and any standard form of BACnetDestination to any Notification Class object's Recipient_List property. Actions taken by Device A when retrieval of a value for display fails are a local matter.


A device claiming support for AE-AVM-A is interoperable with devices that support AE-N-I-B or AE-N-E-B.



[Change Clause K.2.6, p.632, and renumber subsequent clauses.]

K.2.6 BIBB - Alarm and Event-Alarm Summary-A (AE-ASUM-A) { TC " K.2.6 BIBB - Alarm and Event-Alarm Summary-A (AE-ASUM-A)" \l 3 }

This BIBB has been deprecated and is included solely for historical purposes. This BIBB should not be used when describing the functionality of BACnet devices.

Device A requests summaries of alarms from device B.


GetAlarmSummary x { TC " K.2.6 BIBB - Alarm and Event-Alarm Summary-A (AE-ASUM-A)" \l 3 } [Change Clause K.2.8, p. 633, and renumber subsequent clauses.]

K.2.8 BIBB - Alarm and Event-Enrollment Summary-A (AE-ESUM-A) { TC " K.2.8 BIBB - Alarm and Event-Enrollment Summary-A (AE-ESUM-A)" \l 3 } This BIBB has been deprecated and is included solely for historical purposes. This BIBB should not be used when describing the functionality of BACnet devices. Device A requests event enrollments from device B.


GetEnrollmentSummary x [Change Clause K.2.10, p. 633, and renumber subsequent clauses.]

K.2.10 BIBB - Alarm and Event-Information-A (AE-INFO-A)

This BIBB has been deprecated and is included solely for historical purposes. This BIBB should not be used when describing the functionality of BACnet devices.

Device A requests event information from device B.


GetEventInformation x [Add new Clause K.2.X5, p. 633.]

K.2.X5 BIBB - Alarm and Event Management - Alarm Summary View - A (AE-AS-A)

Device A presents alarm summary information to the user. Device A uses GetEventInformation to retrieve or update alarm summary information presented to the user. When confronted with a device that does not support execution of GetEventInformation, Device A uses GetAlarmSummary instead. Device A may use alternate alarm and event summary services where support for execution of the alternate service is supported by Device B.


GetEventInformation x GetEnrollmentSummary x GetAlarmSummary x



Device A is not required to rely solely on the event summary services for retrieval of event information. It may use the information contained in received event notifications to build the alarm summary. In such a case, a device claiming conformance to this BIBB shall use the summarization services to update this information. Presentation content and format is a local matter.

A device claiming support for AE-AS-A is interoperable with devices that support AE-INFO-B, AE-ESUM-B or AE-ASUM-B.


K.2.X6 BIBB - Alarm and Event Management - Event Log View - A (AE-ELV-A)

The A device displays event log data from the B device.

BACnet Service Initiate Execute ReadRange x

The A device uses ReadRange to retrieve and display the Event Log object’s Log_Buffer property. Devices claiming support for this BIBB shall be capable of presenting Event Logs containing any type event notifications but are not required to display the Event_Values field of event notifications for Event_Types that are defined in a Protocol_Revision newer than that of the A device. The A device has to be able to display the information, with the same data requirments, indicated in AE-VN-A.

A device claiming support for AE-ELV-A is interoperable with devices that support AE-EL-I-B or AE-EL-E-B.


K.2.X7 BIBB - Alarm and Event Management - Event Log View and Modify - A (AE-ELVM-A)

The A device displays event log data from the B device and manipulates event log collection parameters in the B device. Devices claiming support for this BIBB shall support DS-RP-A and DS-WP-A.


ReadRange x ReadProperty x WriteProperty x

The A device shall be capable of using ReadRange to retrieve and display the Event Log’s Log_Buffer property, ReadProperty to retrieve and display Event Log properties, WriteProperty to modify Event Log properties. The properties that the A device shall be capable of reading and writing are listed below. Device A may use alternate services where support for execution of the alternate service is supported by the B Device.

Table K-X11. Event Log Object Properties That AE-ELVM-A Devices Shall Be Capable of Presenting and Modifying

Enable Start_Time Stop_Time Stop_When_Full Buffer_Size Record_Count Total_Record_Count (retrieve only)

Notification_Threshold Last_Notify_Record (retrieve only) Event_State (retrieve only) Notification_Class Event_Enable Event_Time_Stamps (retrieve only)

Devices claiming support for this BIBB shall be capable of presenting all of the fields of the Log_Buffer records, and all types of event notifications but are not required to display the Event_Values field of event notifications for Event_Types that are defined in a Protocol_Revision newer than that claimed by the A device.



Devices claiming support for this BIBB shall be capable of writing values within the full range as defined in tables K-X3 and K-X4. A device claiming support for AE-ELVM-A is interoperable with devices that support AE-EL-I-B or AE-EL-E-B.


K.2.X8 BIBB - Alarm and Event Management - Event Log - Internal - B (AE-EL-I-B)

The B device collects the event notifications in an internal buffer. Each device claiming conformance to AE-EL-I-B must be able to support at least one Event Log object.


ReadRange x [Add new Clause K.2.X9, p. 633.]

K.2.X9 BIBB - Alarm and Event Management - Event Log - External - B (AE-EL-E-B)

The B device collects, in an internal buffer, confirmed and unconfirmed event notifications that are received from other devices. Each device claiming conformance to AE-EL-E-B must be able to support at least one Event Log object and shall be capable of logging all forms of event notifications.


ReadRange x ConfirmedEventNotification x UnconfirmedEventNotification x

[Change Clause K.3.1, p 634.]

K.3.1 BIBB - Scheduling-A (SCHED-A)

This BIBB has been deprecated and is included solely for historical purposes. This BIBB should not be used when describing the functionality of BACnet devices. The A device manipulates schedules and calendars on the B device. The A device must shall support the DS-RP-A and DS-WP-A BIBBs.

[Add Clause K.3.X1, p. 634.]

K.3.X1 BIBB - Scheduling-Advanced View and Modify-A (SCHED-AVM-A)

The A device manipulates schedules and calendars on the B device. The A device must shall support the DM-OCD-A, DS-RP-A and DS-WP-A BIBBs.


CreateObject x DeleteObject x ReadProperty x WriteProperty x

The A device uses ReadProperty to retrieve for presentation and WriteProperty to modify each of the Schedule and Calendar properties listed below. The A device shall be capable of using the CreateObject and DeleteObject services to create and delete Schedule and Calendar objects on the B device. Device A may use alternate services where support for execution of the alternate service is supported by Device B.



Table K-X12. Properties SCHED-AVM-A That Devices Shall Be Capable of Presenting and Modifying

Schedule Calendar Effective_Period Weekly_Schedule Exception_Schedule Schedule_Default List_Of_Object_Property_References Priority_For_Writing Out_Of_Service

Date_List

The A device shall support the creation, presentation and modification of all forms of the Weekly_Schedule, Exception_Schedule and Date_List properties with the following limitations. At a minimum, the A device shall be capable of handling Exception_Schedule properties with up to 255 entries, and 12 BACnetTimeValue tuples per entry, Weekly_Schedule properties with up to 6 entries per day, and Date_List properties with up to 32 entries.

Devices claiming support for this BIBB shall be capable of creating, deleting, presenting, and modifying Schedule objects that schedule any of the following types:

REAL, ENUMERATED, Unsigned32 and which may contain NULL values and shall be capable of changing the datatype that a Schedule object schedules. Schedule objects contain a number of properties that need to be consistent in the datatype of the values they contain. Devices claiming support for this BIBB shall be prepared to interact, allow display and modification of, Schedule objects that are self-inconsistent. A self-inconsistent Schedule object is one in which the scheduled values in the Weekly_Schedule, Exception_Schedule, and Schedule_Default properties are not all of the same datatype or in which the controlled objects are not all of the same datatype or are of a datatype different than the scheduled values. The A device shall be capable of creating, deleting, presenting and modifying schedules in any B device regardless of the B device’s claimed Protocol_Revision.

The A device shall be capable of creating, deleting, presenting and modifying schedule objects that do not contain an Exception_Schedule.

Devices claiming support for this BIBB shall be capable of providing times and values in the time/value pairs within the full range as defined in Tables K-X3 and K-X4. Actions taken by Device A when retrieval of a value for display fails are a local matter.

A device claiming support for SCHED-AVM-A is interoperable with devices that support any of the B side schedule BIBBs.


K.3.X2 BIBB - Scheduling-View and Modify-A (SCHED-VM-A)

The A device manipulates schedules and calendars on the B device. The A device shall support the DS-RP-A and DS-WP-A BIBBs.



Device A shall be capable of using ReadProperty to retrieve for presentation and WriteProperty to modify each of the Schedule and Calendar properties listed below. Device A may use alternate services where support for execution of the alternate service is supported by Device B.



Table K-X13. Properties That SCHED-VM-A Devices Shall Be Capable of Presenting and Modifying

Schedule Calendar Effective_Period Date_List Weekly_Schedule Exception_Schedule

The A device shall support the presentation and modification of all forms of the Weekly_Schedule, Exception_Schedule and Date_List properties with the following limitations. At a minimum, the A device shall be capable of handling Exception_Schedule properties with up to 255 entries, and 12 BACnetTimeValue tuples per entry, Weekly_Schedule properties with up to 6 entries per day, and Date_List properties with up to 32 entries.

Devices claiming support for this BIBB shall be capable of presenting, and modifying Schedule objects that schedule any of the following types:

REAL, ENUMERATED, Unsigned32 and which may contain NULL values.

The A device shall be capable of presenting and modifying schedules in any B devices regardless of the B device’s claimed Protocol_Revision.

The A device shall be capable of presenting and modifying schedule objects that do not contain an Exception_Schedule.

Devices claiming support for this BIBB shall be capable of providing times and values in the time/value pairs within the full range as defined in Table K-X3. A device claiming support for SCHED-VM-A is interoperable with devices that support any of the B-side schedule BIBBs.

[Add new K.3.X3, p. 634.]

K.3.X3 BIBB - Scheduling-Weekly Schedule-A (SCHED-WS-A)

The A device manipulates the weekly schedule portion of schedules on the B device. The A device shall support the DS-RP-A and DS-WP-A BIBBs.



The A device shall be capable of using ReadProperty to retrieve for presentation and WriteProperty to modify each of the Schedule properties listed below. Device A may use alternate services where support for execution of the alternate service is supported by Device B.

Table K-X14. Properties That SCHED-WS-A Devices Shall Be Capable of Presenting and Modifying

Schedule Weekly_Schedule Schedule_Default

The A device shall support the presentation and modification of all forms of the Weekly_Schedule, property with the following limitations. At a minimum, the A device shall be capable of handling Weekly_Schedule properties with up to 6 entries per day.

Devices claiming support for this BIBB shall be capable of presenting, and modifying Schedule objects that schedule any of the following types:

ENUMERATED, REAL and which may contain NULL values.



The A device shall be capable of presenting and modifying Schedule objects of the forms defined in Protocol_Revision 0 and Protocol_Revision 4.


K.3.X4 BIBB - Scheduling-Weekly Schedule Internal-B (SCHED-WS-I-B)

The B device provides weekly scheduling of the values of specific properties of specific objects within the device via Schedule objects that do not contain Exception_Schedules. In addition to supporting the DS-RP-B and DS-WP-B BIBBs, each device claiming conformance to SCHED-WS-I-B shall also be capable of possessing at least one Schedule object. Devices claiming conformance to SCHED-WS-I-B shall also support either DM-TS-B or DM-UTC-B.


ReadProperty x WriteProperty x TimeSynchonization x UTCTimeSynchronization x

The Schedule object shall support at least 6 entries per day in the Weekly_Schedule property. The schedule shall support the scheduling of BACnetBinaryPV values. The Priority_For_Writing property in the Schedule object shall be writable.

[Change Clause K.3.2, p. 634.]

K.3.2 BIBB - Scheduling-Internal-B (SCHED-I-B) { TC " K.3.2 BIBB - Scheduling-Internal-B (SCHED-I-B)" \l 3 }

The B device provides date and time scheduling of the values of specific properties of specific objects within the device. In addition to supporting the DS-RP-B and DS-WP-B BIBBs, each device claiming conformance to SCHED-I-B shall also be capable of possessing at least one Calendar and one Schedule object. Devices claiming conformance to SCHED-I-B shall also support either DM-TS-B or DM-UTC-B.

The Schedule object must shall support a writable Weekly_Schedule property and at least 6 entries per day. The List_of_Object_Property_References property shall support at least one entry. The Schedule object must shall support a writable, non-empty Exception_Schedule property. The Priority_For_Writing property in the Schedule object shall be writable.


K.3.3 BIBB - Scheduling-External-B (SCHED-E-B) { TC " K.3.3 BIBB - Scheduling-External-B (SCHED-E-B)" \l 3 }

The B device provides date and time scheduling of the values of specific properties of specific objects in other devices. Devices claiming conformance to SCHED-E-B shall also support SCHED-I-B and DS-WP-A. The List_Of_Object_Property_References property shall support references to objects in external devices and be writable.

[Add new Clause K.3.4, p. 634]

K.3.4 BIBB - Scheduling-Readonly-B (SCHED-R-B) { TC " K.3.2 BIBB - Scheduling-Internal-B (SCHED-I-B)" \l 3 } The B device provides read-only Schedule object(s). Each device claiming conformance to SCHED-R-B shall be capable of possessing at least one Schedule object, support DS-RP-B and either DM-TS-B or DM-UTC-B. The Weekly_Schedule and Exception_Schedule properties of the Schedule object shall be read-only when accessed directly via BACnet services, but may be modifiable by other means.



This BIBB is primarily included in the BACnet standard to allow gateway devices to indicate support for exposing the content of schedules found in devices from other protocols.


K.4.1 BIBB - Trending- Viewing and Modifying Trends-A (T-VMT-A)

This BIBB has been deprecated and is included solely for historical purposes. This BIBB should not be used when describing the functionality of BACnet devices. The A device displays trend data from the B device and manipulates trend log collection parameters in the B device.


ReadRange x [Change Clause K.4.6, p. 635.]

K.4.6 BIBB - Trending-Viewing and Modifying Multiple Values-A (T-VMMV-A) { TC " K.4.1 BIBB - Trending-Viewing and Modifying Trends-A (T-VMT-A)" \l 3 } This BIBB has been deprecated and is included solely for historical purposes. This BIBB should not be used when describing the functionality of BACnet devices. The A device displays data from a Trend Log Multiple object in the B device and manipulates Trend Log Multiple object collection parameters in the B device.

BACnet Service Initiate Execute ReadRange x


K.4.X1 BIBB - Trending – View - A (T-V-A)

The A device displays trend data from the B device. Within the context of this BIBB, the term “trend object” shall refer to both Trend Log and Trend Log Multiple objects.


ReadRange x

The A device uses ReadRange to retrieve and display trend object Log_Buffer properties.

Devices claiming support for this BIBB shall be capable of presenting data from trend objects for the following types of data:

BOOLEAN, REAL, ENUMERATED, Unsigned32, INTEGER, BIT STRING, NULL

Devices claiming conformance to a Protocol_Revision less than 7 are not required to support these interactions with Trend Log Multiple objects. The A device need not be capable of interoperating with Trend Logs of the form defined in Protocol_Revision 1.

A device claiming support for T-V-A is interoperable with devices that support T-VMT-I-B.



[Add new Clause K.4.X2, p. 635]

K.4.X2 BIBB - Trending-Advanced View and Modify -A (T-AVM-A)

The A device displays trend data from the B device and manipulates trend log collection parameters in the B device. Devices claiming support for this BIBB shall support DS-RP-A and DS-WP-A. Within the context of this BIBB, the term “trend object” shall refer to both Trend Log and Trend Log Multiple objects.


CreateObject x DeleteObject x ReadProperty x ReadRange x WriteProperty x

The A device shall be capable of using ReadRange to retrieve and display trend object Log_Buffer properties, ReadProperty to retrieve and display trend object properties, WriteProperty to modify trend object properties, and CreateObject and DeleteObject to create and delete trend objects, Event Enrollment and Notification Class objects. The properties that the A device shall be capable of reading and writing are listed below. Device A may use alternate services where support for execution of the alternate service is supported by the B Device.

Table K-X14. Trend Object Properties That T-AVM-A Devices Shall Be Capable of Presenting and Modifying

Enable Start_Time Stop_Time Log_DeviceObjectProperty Logging_Type Log_Interval Align_Intervals Interval_Offset COV_Resubscription_Interval Client_COV_Increment

Stop_When_Full Buffer_Size Record_Count Total_Record_Count (retrieve only) Notification_Threshold Last_Notify_Record (retrieve only) Event_State (retrieve only) Notification_Class Event_Enable Event_Time_Stamps (retrieve only)

In addition, devices claiming support for T-AVM-A shall be capable of creating and configuring Event Enrollment objects to monitor trend objects using the BUFFER_READY algorithm. The A device shall also be capable of creating and configuring Notification Class objects (as described in AE-AVM-A) for setup of Automated Trend Retrieval.

Devices claiming support for this BIBB shall be capable of presenting trend object data of the following types:

BOOLEAN, REAL, ENUMERATED, Unsigned32, INTEGER, BIT STRING, NULL

Devices claiming support for this BIBB shall be capable of writing values within the full range as defined in tables K-X3 and K-X4. A device claiming support for T-AVM-A is interoperable with devices that support T-VMT-I-B or T-VMMV-I-B.

Devices claiming conformance to a Protocol_Revision less than 7, are not required to support these interactions with Trend Log Multiple objects nor properties added to the Trend Log object in Protocol_Revision 7. The A device need not be capable of interoperating with Trend Logs of the form defined in Protocol_Revision 1.

[Add new Clause K4.X3, p. 635.]

K.4.X3 BIBB - Trending-Archival-A (T-A-A) { TC " K.5.1 BIBB - Device Management-Dynamic Device Binding-A (DM-DDB-A)" \l 3 }

The A device archives trend data from Trend Log and Trend Log Multiple objects in the B device. The A device shall support T-ATR-A and T-AMVR-A and shall be capable of using the BUFFER_READY notifications to ensure that



trend data is retrieved using ReadRange and archived before the trend data is removed from the Log_Buffer property due to the addition of newly collected samples. The archived data shall be stored in non-volatile storage for future access. A device claiming support for T-A-A is interoperable with devices that support T-ATR-B or T-AMVR-B.

Devices claiming conformance to a Protocol_Revision less than 7, are not required to support these interactions with Trend Log Multiple objects and thus do not need to support T-AMVR-A.


K.5.X1 BIBB - Device Management-Automatic Network Mapping-A (DM-ANM-A) { TC " K.5.1 BIBB - Device Management-Dynamic Device Binding-A (DM-DDB-A)" \l 3 }

The A device finds all devices currently connected to the BACnet internetwork that support DM-DDB-B and presents the list of those devices to the user. A device claiming support for this BIBB shall support DM-DDB-A.

The A device is not required to report the presence of devices located on the far side of a non-connected PTP link.

A device claiming support for DM-ANM-A is interoperable with devices that support DM-DDB-B.


K.5.X2 BIBB - Device Management-Automatic Device Mapping-A (DM-ADM-A) { TC " K.5.1 BIBB - Device Management-Dynamic Device Binding-A (DM-DDB-A)" \l 3 }

The A device is capable of determining and presenting a list of all objects contained in any BACnet device. Devices claiming support for this BIBB shall also support DS-RP-A to retrieve and display the Object_Name property of any object in any BACnet device. Device A may use alternate services where support for execution of the alternate service is supported by Device B. A device claiming support for DM-ADM-A is interoperable with all BACnet devices.


K.5.X3 BIBB - Device Management-Automatic Time Synchronization-A (DM-ATS-A) { TC " K.5.1 BIBB - Device Management-Dynamic Device Binding-A (DM-DDB-A)" \l 3 }

The A device provides periodic time synchronization to B devices. In order to support all types of BACnet devices, the A device shall be capable of periodically sending TimeSynchronization and UTCTimeSynchronization services to recipients listed in the A device’s Time_Synchronization_Recipients and UTC_Time_Synchronization_Recipients properties.


TimeSynchronization x UTCTimeSynchronization x

Devices claiming conformance to DM-ATS-A shall support non-empty Time_Synchronization_Recipients and UTC_Time_Synchronization_Recipients properties in its Device object and shall support all forms of the BACnetRecipient in both properties.

A device claiming support for DM-ATS-A is interoperable with devices that support DM-TS-B or DM-UTC-B.




K.5.X4 BIBB - Device Management-Manual Time Synchronization-A (DM-MTS-A) { TC " K.5.1 BIBB - Device Management-Dynamic Device Binding-A (DM-DDB-A)" \l 3 }

The A device provides time synchronization to B devices at the request of the operator. In order to support all types of BACnet devices, the A device shall be capable of sending both TimeSynchronization and UTCTimeSynchronization services to any, or all, BACnet devices in the BACnet internetwork.


TimeSynchronization x UTCTimeSynchronization x

A device claiming support for DM-MTS-A is interoperable with devices that support DM-TS-B or DM-UTC-B.



[Change Clause L.1, p. 640.] ANNEX L - DESCRIPTIONS AND PROFILES OF STANDARDIZED BACnet DEVICES (NORMATIVE){ TC "ANNEX L - DESCRIPTIONS AND PROFILES OF STANDARDIZED BACnet DEVICES (NORMATIVE)"} (This annex is part of this Standard and is required of its use.) This annex provides descriptions of six "standardized" types of BACnet devices. Any device that implements all the required BACnet capabilities for a particular device type and interoperability area may claim to be a device of that particular type. Devices may also provide additional capabilities and shall indicate these capabilities in their PICS. The devices defined herein are: BACnet Operator Workstation, BACnet Building Controller, BACnet Advanced Application Controller, BACnet Application Specific Controller, BACnet Smart Actuator, and BACnet Smart Sensor.

L.1 BACnet Operator Workstation (B-OWS)

The B-OWS is the operator's window into a BACnet system. While it is primarily used for the operation of a system, it may be used for configuration activities that are beyond the scope of this standard. It is not intended to perform direct digital control. It enables the specification of the following: The B-OWS is an operator interface with limited capabilities relative to a B-AWS. The B-OWS is used for monitoring and basic control of a system, but differs from a B-AWS in that it does not support configuration activities, nor does it provide advanced troubleshooting capabilities.

The B-OWS profile is targeted at the daily operator who needs the ability to monitor basic system status and to perform simple modifications to the operation of the system.

The B-OWS profile enables the specification of the following: Data Sharing • Ability to provide the values of any of its BACnet objects • Archival storage of data • Presentation of data (i.e., reports and graphics) • Ability to monitor the value of all BACnet object types, including all required and optional properties • Ability to modify setpoints and parameters Alarm and Event Management • Operator notification and presentation of event information • Alarm acknowledgment by operators • Alarm summarization • Adjustment of analog alarm limits • Adjustment of alarm routing Scheduling • Modification of calendars and schedules • Display of the start and stop times (schedule) of scheduled devices • Display of calendars Trending • Modification of the parameters of a trend log • Display and archive of trend data Device and Network Management • Ability to find other BACnet devices • Ability to respond to queries about its status • Ability to respond to requests for information about any of its objects • Display of information about the status of any device on the BACnet internetwork



• Ability to silence a device on the network that is transmitting erroneous data • Ability to synchronize the time in devices across the BACnet internetwork at the request of the operator • Ability to cause a remote device to reinitialize itself • Ability to backup and restore the configuration of other devices • Ability to command half-routers to establish and terminate connections



[Add new Clause L.X1, p. 644.]

L.X1 BACnet Advanced Operator Workstation (B-AWS)

The B-AWS is the advanced operator's window into a BACnet system. It is primarily used to monitor the performance of a system and to modify parameters that affect the operation of a system. It may also be used for configuration activities that are beyond the scope of this standard.

The B-AWS profile is targeted at a building operator or technician with a higher level of technical ability. It provides support for limited configuration actions and ongoing commissioning activities.

The B-AWS profile enables the specification of the following:

Data Sharing • Presentation of data (i.e., reports and graphics) • Ability to monitor the value of all BACnet object types, including all required and optional properties • Ability to modify setpoints and parameters

Alarm and Event Management • Operator notification and presentation of event information • Alarm acknowledgment by operators • Alarm summarization • Adjustment of alarm limits • Adjustment of alarm routing • Creation of new Event Enrollment and Notification Class objects • Presentation of Event Logs

Scheduling • Modification of calendars and schedules • Display of the start and stop times (schedule) of scheduled devices • Display of calendars • Creation of new calendars and schedules

Trending • Modification of the parameters of a trend log • Display of trend data • Creation of new Trend Log objects

Device and Network Management • Ability to find other BACnet devices • Ability to find all objects in BACnet devices • Ability to silence a device on the network that is transmitting erroneous data • Ability to synchronize the time in devices across the BACnet internetwork at the request of the operator • Ability to cause a remote device to reinitialize itself • Ability to backup and restore the configuration of other devices • Ability to command half-routers to establish and terminate connections

[Add new Clause L.X2, p. 644.]

L.X2 BACnet Operator Display (B-OD)

The B-OD is a basic operator interface with limited capabilities relative to a B-OWS. It is not intended to perform direct digital control. The B-OD profile could be used for wall-mounted LCD devices, displays affixed to BACnet devices; hand-held terminals or other very simple user interfaces.



The B-OD profile enables the specification of the following:

Data Sharing • Presentation of basic data • Ability to modify setpoints and parameters

Alarm and Event Management • Operator notification and presentation of event information

Scheduling • No minimum requirements

Trending • No minimum requirements

Device and Network Management • Ability to find other BACnet devices



[Change Clause L.7, p. 645.] [Note: The AE-LS-A BIBB was published in Addendum 135-2004d-4.]

L.7 Profiles of the Standard BACnet Devices

The following tables indicate which BIBBs must shall be supported by each device type for each interoperability area.

B-AWS B-OWS B-OD B-BC B-AAC B-ASC B-SA B-SS Data

Sharing DS-RP-A,B DS-RP-A,B DS-RP-A,B DS-RP-A,B DS-RP-B DS-RP-B DS-RP-B DS-RP-B

DS-RPM-A DS-RPM-A DS-RPM-A,B DS-RPM-B DS-WP-A DS-WP-A DS-WP-A DS-WP-A,B DS-WP-B DS-WP-B DS-WP-B DS-WPM-A DS-WPM-A DS-WPM-B DS-WPM-B DS-AV-A DS-V-A DS-V-A DS-AM-A DS-M-A DS-M-A B-AWS B-OWS B-OD B-BC B-AAC B-ASC B-SA B-SS

Alarm & Event Mgmt

AE-N-A AE-N-A AE-N-I-B AE-N-I-B AE-ACK-A AE-ACK-A AE-ACK-B AE-ACK-B

AE-INFO-A AE-INFO-B AE-INFO-B AE-ESUM-A AE-ESUM-B AE-AS-A AE-AS-A AE-AVM-A AE-VM-A AE-AVN-A AE-VN-A AE-VN-A AE-ELVM-A2 B-AWS B-OWS B-OD B-BC B-AAC B-ASC B-SA B-SS

Scheduling SCHED-AVM-A

SCHED-A SCHED-VM-A

SCHED-E-B SCHED-I-B

B-AWS B-OWS B-OD B-BC B-AAC B-ASC B-SA B-SS

Trending T-AVM-A T-VMT-A T-V-A

T-VMT-I-B

T-ATR-A T-ATR-B B-AWS B-OWS B-OD B-BC B-AAC B-ASC B-SA B-SS

Device & Network

Mgmt

DM-DDB-A,B DM-DDB-A,B DM-DDB-A,B DM-DDB-A,B DM-DDB-B DM-DDB-B DM-DDB-B1 DM-DDB-B1 DM-ANM-A

DM-ADM-A DM-DOB-B DM-DOB-B DM-DOB-B DM-DOB-B DM-DOB-B DM-DOB-B DM-DOB-B1 DM-DOB-B1 DM-DCC-A DM-DCC-A DM-DCC-B DM-DCC-B DM-DCC-B

DM-MTS-A DM-TS-A

DM-MTS-A DM-TS-B

or DM-UTC-B

DM-TS-B or

DM-UTC-B

DM-UTC-A DM-OCD-A DM-RD-A DM-RD-A DM-RD-B DM-RD-B DM-BR-A DM-BR-A DM-BR-B NM-CE-A NM-CE-A NM-CE-A

1 Not required if the device is a BACnet MS/TP Slave. 2 Not required for devices claiming conformance to a Protocol_Revision less than 7.



[Add a new entry to History of Revisions, p. 688]

(This History of Revisions is not part of this standard. It is merely informative and does not contain requirements necessary for conformance to the standard.)

HISTORY OF REVISIONS

Protocol Summary of Changes to the Standard Version Revision

… … … 1 9 Addendum l to ANSI/ASHRAE 135-2008

Approved by the ASHRAE Standards Committee June 20, 2009; by the ASHRAE Board of Directors June 24, 2009; and by the American National Standards Institute June 25, 2009. 1. Add new workstation BIBBs and profiles.

POLICY STATEMENT DEFINING ASHRAE’S CONCERNFOR THE ENVIRONMENTAL IMPACT OF ITS ACTIVITIES

ASHRAE is concerned with the impact of its members’ activities on both the indoor and outdoor environment. ASHRAE’smembers will strive to minimize any possible deleterious effect on the indoor and outdoor environment of the systems andcomponents in their responsibility while maximizing the beneficial effects these systems provide, consistent with acceptedstandards and the practical state of the art.

ASHRAE’s short-range goal is to ensure that the systems and components within its scope do not impact the indoor andoutdoor environment to a greater extent than specified by the standards and guidelines as established by itself and otherresponsible bodies.

As an ongoing goal, ASHRAE will, through its Standards Committee and extensive technical committee structure,continue to generate up-to-date standards and guidelines where appropriate and adopt, recommend, and promote those newand revised standards developed by other responsible organizations.

Through its Handbook, appropriate chapters will contain up-to-date standards and design considerations as the material issystematically revised.

ASHRAE will take the lead with respect to dissemination of environmental information of its primary interest and will seekout and disseminate information from other responsible organizations that is pertinent, as guides to updating standards andguidelines.

The effects of the design and selection of equipment and systems will be considered within the scope of the system’sintended use and expected misuse. The disposal of hazardous materials, if any, will also be considered.

ASHRAE’s primary concern for environmental impact will be at the site where equipment within ASHRAE’s scopeoperates. However, energy source selection and the possible environmental impact due to the energy source and energytransportation will be considered where possible. Recommendations concerning energy source selection should be made byits members.

© 2009, American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc. (www.ashrae.org). For personal use only. Additional reproduction, distribution, or transmission in either print or digital form is not permitted without ASHRAE’s prior written permission.

add-135-2008l-pub-draft chair-approved -pdf · 135-2008l-1. add new workstation bibbs and profiles,...

Documents