ISO / IEC JTC1/SC25 WG1
N786
WG1 (Tokyo-2, Bertsch) 3
Date: May 25, 1998
ISO / IEC JTC1 SC25 WG1
Interconnection of Information Technology Equipment
Home Electronic System
Title:
Comparison of CAB, CAL, CEN and BACnet Binary Output
Objects
Source:
Canada
Project:
Working Group 1
Requested Action: To be used in developing building automation standards
Update documents N664 Rev B and N616
Obsolete:
None
Reason:
Recommendation for Working Group
Thread:
2 (Objects and Messages for HES Building Control Systems)
5 (HES Applications Model and Services)
8 (Terminology)
Distribution:
All Working Group 1 members
COMPARISON OF CAB, CAL, CEN and BACnet BINARY OUTPUT OBJECTS
Introduction
Over the last several years, discussions within WG1 have revolved around several Home and
Building Automation systems. It is a monumental task indeed to produce a worldwide
standard with such a diverse range of needs and various market forces. WG1 has recognized
this through the development of interim steps (stepping stones) such as the UI, technical
reports and comparison reports; a number of which passed majority agreement. This
document provides another stepping stone, which may be a very useful end-goal on its own.
“Thread 2” (Objects and Messages for HES Building Control Systems) discussions have
typically revolved around listing the objects and methods of various systems and proposing
them. Although this does move us forward, perhaps another important task should be done.
If we look at just one object, even a simple object such as a Binary Output object, there is a
tremendous variation on various systems’ specifications.
Perhaps, even more important, the methods to compare them are very difficult. Each uses its
own terminology, and sometimes contradict other systems’ terminology. In some cases
information is missing, or unclear. There are cases where references must be made in many
places in the documents to reveal certain information.
At lot of progress around the world was made with the OSI model for layer communications
systems. The model is basically a specification on how to specify using common terms and
references.
Similiarly, there seems to be a need to do the same for the Home and Building Automation
Systems.
Therefore, we propose that standard terminology and requirements be established for
HBES systems. The Home and Building Automation systems that follow the rules would
then meet the “HBES Terminology Standard”.
For example, CAL, CAB, BACnet, CEN or any other system would produce their standards
as they have in the past, but in order to meet the international “HBES Terminology
Standard”, must include a section that is written as defined as in HBES standard. It would
not dictate the details of the standard, but how it is to be presented.
-1-
This accomplishes a number of things:
1) Users of the systems would have a common format to help them decide on which
system to use.
2) Developers of each system would have a good opportunity to see the differences
of the various other systems, and potentially move toward the “better system” or
incorporate the benefits of other systems (without the common standard; there
would too much exploratory work to investigate).
3) WG1 would be able to more readily more toward a common HBES system by
having the proponents described in common terminology; it is an appropriate
stepping stone to full standardization.
4) The deliverables are clear and obtainable for WG1 to achieve.
5) In the process of converting to the common terminology the systems may discover
mistakes or areas needing clarifications and therefore improve their own
specifications.
6) A higher profile, and potentially more participation, is given to WG1 by providing
much needed information to the industry.
7) Clarifies what each system means by certain terms, as example, “binary output
object” is a simple object in CAL without timers, whereas CAB includes timers.
8) Any new system being designed in the future can more readily build upon the
success and failures of systems in the past, without having to learn all the details
and particulars of each system'’ terminology. It helps to stop the divergent
directions of new systems.
9) It improves the specifications for gateways and communications across different
systems.
In section #1 below, the various systems are listed in tables with their existing Binary Output
Object (or equivalent) specifications. The original terminology will be listed. Where
possible the tables have been expanded to include additional relevant information.
Section #2 defines the specifications for complying to the “HBES Terminology Standard”.
Section #3 includes example tables that would meet the “HBES Terminology Standard” for
the Binary Output Object for BACnet, CAB, CAL and CEN.
Section #4 summarizes the recommendations.
-2-
SECTION 1 – ORIGINAL SYSTEM SPECIFICATIONS
BACNet Original Specification
Binary Output Object Type
Property Identifier
Property Datatype
Conformance Code
Object_Identifier
Object_Name
Object_Type
Present_Value
Description
Device_Type
Status_Flag
Event_State
Reliability
Out_Of_service
Polarity
Inactive_Text
Active_Text
Change_Of_State_Time
Change_Of_State_Count
Time_Of_State_Count_Reset
Elapsed_Active_Time
Time_Of_Active_Time_Reset
Minimum_Off_Time
Minimum_On_Time
Priority_Array
Relinquish_Default
Time_Delay
Notification_Class
Feedback_Value
Event_Enable
Acked_Transitions
Notify_Type
BACnetObjectIdentifier
CharacterString
BACnetObjectType
BACnetBinaryPV
CharacterString
CharacterString
BACnetStatusFlags
BACnetEventState
BACnetReliability
BOOLEAN
BACnetPolarity
CharacterString
CharacterString
BACnetDateTime
Unsigned
BACnetDateTime
Unsigned32
BACnetDateTime
Unsigned32
Unsigned32
BACnetPriorityArray
BACnetBinaryPV
Unsigned
Unsigned
BACnetBinaryPV
BACnetEventTransitionBits
BACnetEventTransitionBits
BACnetNotifyType
Read
Read
Read
Read/Write
Optional
Optional
Read
Read
Optional
Read
Read
Optional1
Optional1
Optional2
Optional2
Optional2
Optional3
Optional3
Optional
Optional
Read
Read
Optional4
Optional4
Optional4
Optional4
Optional4
Optional4
-3-
CAB Original Specification
Digital-Output
Property
Descriptor
CAB Data Type
Response Values
Read/Write
pv-discrete
state
alarm-state
alarm-category
contact-condition
condition-to-alarm
operating-mode
digital-feedback
pv-on-text
pv-off-text
schedule
runtime-enable
runtime-value
runtime-time
runtime-date
runtime-limit
runtime-alarm-cat
runtime-reset
cos-count-enable
cos-count
cos-count-limit
cos-count-window
cos-count-alarm-cat
point-text-1
point-text-2
point-alarm-text-1
point-alarm-text-2
point-mask
CAB-String-10
CAB-State
CAB-Event-Type
CAB-Alarm-Category
CAB-Contact-Condition
CAB-Condition-To-Alarm
CAB-Operating-Mode
CAB-On-Off
CAB-String-10
CAB-String-10
CAB-String-12
CAB-State
INTEGER(0..65535)
CAB-Time
CAB-Date
INTEGER(0..65535)
CAB-Alarm-Category
INTEGER(0..65535)
CAB-State
INTEGER(0..65535)
INTEGER(0..65535)
INTEGER(0..65535)
CAB-Alarm-Category
CAB-String-40
CAB-String-40
CAB-String-80
CAB-String-80
Printable Text
Enable/Disable
Event Type 1,2,3,4,11,15
Critical/Cautionary/Maintenance
On/Off
On/Off/Not-equal-To-Feedback
Auto/Manual
On/Off
Printable Text
Printable Text
Printable Text
Enabled/Disabled
Hours
Time
Date
Maximum Accumulated Value
Critical/Cautionary/Maintenance
Reset Accumulated Value
Enabled/Disabled
Accumulated Count
Maximum Accumulated Count
Count
Critical/Cautionary/Maintenance
Printable Text
Printable Text
Printable Text
Printable Text
Read/Write
Read/Write
Read
-4-
Read/Write
Read/Write
Read/Write
Read
Read/Write
Read/Write
Read/Write
Read/Write
Read/Write
Read
Read
Read/Write
Read/Write
Read/Write
Read/Write
Read/Write
Read/Write
Read/Write
Read/Write
Read/Write
Read/Write
Read/Write
Read/Write
CAL Original Specification
Binary Switch
Instance Variables
Name
Category
Type
Mandatory
current_position
default_position
function_of_position
persistence
reporting_condition
dest_address
previous_value
report_header
Read/Write
Read
Read
Read
Read/Write
Read/Write
Read
Read/Write
boolean
boolean
data(8)
boolean
data
data(2-16)
Mandatory
Optional
Optional
Optional
Optional
Optional
Optional
Optional
data
-5-
CEN Original Specification
Binary Output FLN
Property Identifier
Property
Datatype
Read/Write
Property
Kind
Object_Id_Number
Object_Type
Object_Name
Present_Value
Status
Statetext
Priority
Description
Commanded_Value
Total_Runtime
Intervall_Runtime
Intervall_Runtime_Limit
Maintenance/Out_Of_Service_Fla
g
Event_Disabled
Alarm_Disabled
Acknowledged_States
Alarm_Acknowledge
Default
Polarity
Minimum_Off_Time
Minimum_On_Time
Time_Delay
24 bits
8 bits
Character String
8 bits
8 bits
8 bits
8 bits
Character String
8 bits
32 bits
32 bits
32 bits
8 bits
Read
Read
Read
Read/Write
Read
Read
Read/Write
Read
Read
Read
Read/Write
Read/Write
Read
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
8 bits
8 bits
8 bits
8 bits
8 bits
8 bits
32 bits
32 bits
32 bits
Read/Write
Read/Write
Read/Write
Read
Read
Read
Read
Read
Read
Optional
Optional
Optional
Optional
Engineering
Engineering
Engineering
Engineering
Engineering
-6-
COMMENTS ON ORIGINAL SPECIFICATIONS
Some example issues with the existing terminology of the systems include:
1. The BACnet spec includes specific enumerated data types in the data type columns,
instead of only showing the basic data types and “normalizing” (data type only, not
dependant on specific usage). It would be useful to know what range of values can be
expected, without getting complicated by the specifics of the particular data member.
For example, in BACnet, “Event_State” and “Reliability” are the same data type and
same limits (65535), but are listed differently in the tables as “BACnetEventState” and
“BACnetReliability”. It would be useful to know that they are the same without further
investigations. A similar situation occurs for CAB.
2. The CAB spec does not include “Mandatory” descriptions for the data members. In the
main document (section 6.0) there is a mention that “mandatory” is described in the
Appendix E. However, Appendix E does not include such references.
3. At first glance, the CAL spec seems to include single bit data for some of its data
members. However, only upon further examination is it clarified that “boolean” (e.g.
“current_position”) is represented by using “00 Hex” and “01 Hex” 8-bit bytes.
4. The CAL spec for “function_of_position” indicates “data(8)” which one would assume
to allow any valid data, but upon further examination is actually intended to be a
character string.
5. Each system deals with dates, times and character strings differently, including the “Year
2000” issue. Again, this is not initially apparent.
6. The BACnet spec is inconsistent in its use of the data type; sometimes they are
“normalized” (such as “Unsigned32”) and other times they are not “normalized” (such as
“BACnetObjectEventState”).
The enumeration of even simple functions such as “binary” are not common through the
systems, and therefore, perhaps we also should include the actual enumerated actual values
(for binary?). For example, the CEN spec allows a third value, “invalid” while the others do
not. To further complicate matters, CAB uses “2” for false, while the others use “0” for false.
-7-
SECTION 2 – HBES SYSTEM SPECIFICATIONS
Our proposal is to insert into section 6 of document N664 Rev B the following text (or into a new
document) -------------------To be classified as an “HBES terminology standard”, the system must include the following
table for each object:
HBES-Object Identifier:
Object)
HBES-Data Member
Identifier
(Identifier given to the
HBES-Data Member
Data Type
HBES-Data HBES-Data
Member
Member
Read/Write Mandatory
Type
HBES DEFINITIONS
HBES-Object Identifier
Identifier or name given to the object
HBES-Data-Member Identifier
Identifier or name given to the data members within the
object
HBES-Data Member Data Type
Only HBES standardized terms for the type of data for
each data member should be used. The data type
defines:
a) size of the data member (maximum size
expected; e.g. “Unsigned-8” is 8 bits)
b) whether the size is fixed or variable (e.g.
“Unsigned-8” is fixed, while “UnsignedInteger” is variable length)
c) basic structure utilized (e.g. “Bit-Array(8)”
infers that individual bits contain
-8-
information, while “Unsigned-8” does not).
The standardized allowed “HBES-Data-Member Data Types” are:
Bit
This is to be used for data members restricted to only two choices and intended to be
carried in one bit of data.
Bit-Array(length)
This is to be used for data members containing a number of binary selections that are
grouped together or where there is meaning attached to individual bits within the array.
Appropriate usage includes “Status” for CEN Binary Object and “Status_Flags” for
BACnet Binary Output Object. The length must be either a range of values or more than
one.
Unsigned-8
Used for 8-bit information (00 Hex to FF Hex), where the individual bits do not have
meaning, but the overall value does have meaning. This is to be used for 8-bit data which
is not specified in any other type definition.
Signed-8
Used for 8 bit information (00 Hex to FF Hex), where the individual bits do not have
meaning, but the overall value does have meaning and is to be used only if the numbers
represented are in the range of –128 to 127.
Byte-Array(length)
This is to be used for items containing a number of bytes that are grouped together and
are not specified in any other type definition. The length must be either a range of values
more than one.
Character-String(length)[Variant Z]
This is to be used for items containing a number of bytes that are grouped together in
which the bytes are intended to be limited to printable ASCII values. This variant
contains the string of printable ASCII characters with no leading or trailing reference
bytes. The length can be single values or a range of values. This variant is used for the
CAB and CAL systems.
-9-
Character-String[Variant #]
This is to be used for items containing a number of bytes that are grouped together in
which the bytes are intended to be limited to printable ASCII values. This variant
includes the first byte as the length of the string. This variant is used for the CEN
protocol. Maximum length of string is 254.
Character-String[Variant Diff]
This is to be used for items containing a number of bytes that are grouped together in
which the bytes are intended to be limited to printable ASCII values. This variant allows
a number of different ASCII formats to be used. This variant is used for the BACnet
protocol.
Unsigned-16
2 bytes, 16 bits, 0 to 65535
Signed-16
2 bytes, 16 bits, -32768 to 32767
Unsigned-24
3 bytes, 24 bits, 0 to 16,777,215
Unsigned-32
4 bytes, 32 bits, 0 to 4,294,967,296
Signed-32
4 bytes, 32 bits, -2,147,483,648 to 2,147,483,647
Unsigned-Integer
1 and up(L) bytes, 0 to (2(8*L)-1)
Signed-Integer
1 and up(L) bytes, -2(8*L-1) to (2(8*L-1)-1)
-10-
Time[Variant 3I]
Three unsigned integers are used to hold the time value; the hour (first integer), the
minute (second integer) and the second (third integer). This variant is used in the CAB
system.
Time[Variant 3C]
Three character pairs are used to hold the time value; the hour (first character pair), the
minute (second character pair) and the second (third character pair). “Don’t care” fields
are done through the use of non-ASCII characteristics in its place (in order from last to
first). This variant is used in the CAL system.
Time[Variant 4I]
Four unsigned integers are used to hold the time value; the hour (first integer), the minute
(second integer), the second (third integer) and the hundredths of second (four integer).
“Don’t care” fields are done through the use of FF Hex. This variant is used in the
BACnet system.
Date[Variant 3I]
Three unsigned integers are used to hold the data value; day of month (first integer),
month (second integer) and year (third integer from 1980). This variant is used in the
CAB protocol.
Date[Variant 3C]
Three character pairs are used to hold the data value; year (first character pair), month
(second character pair) and day of month (third character pair). “Don’t care” fields are
done through the use of non-ASCII characteristics in its place (in order from last to first).
This variant is used in the CAL protocol.
Date[Variant 4I]
Four unsigned integers are used to hold the data value; year (first integer from 1900),
month (second integer), day of month (third integer) and day of week (fourth integer).
“Don’t care” fields are done through the use of FF Hex. This variant is used in the
BACnet protocol.
HBES-Data Member Read/Write Type Read and/or Write capacity for data member
There are three options allowed:
-11-
Read-only – information can be read only. It is also used for engineering
information (such as “Polarity” in CEN), and for data that cannot
be directly written to but might change due to other circumstances
(such as “Acked-Transistions” in BACnet)
Read/Write – information can be read from or written to over the network
Write-only – information such as passwords that can only be written to
HBES-Data Member Mandatory
Whether the data member is mandatory or not
There are three options allowed:
Mandatory – object must contain the data member
Optional – object may contain the data member
Engineering – data members of object which are not handled during
normal operation, but only during commissioning and maintenance
(such as “Polarity” in CEN)
We also propose that all of the above defined terms be inserted into the Terminology document
(N616).
-12-
SECTION 3 – HBES EXAMPLES
[In the document N664B it may or may not be appropriate to also include the following
examples.]
Using the Binary Output Object (or nearest equivalent) for BACnet, CAB, CAL and CEN, the
appropriate tables are written. Although the tables are intended to follow the specifications of
the various systems, they may contain errors, and should only be taken as examples. This is
because the appropriate committees have not reviewed this document, that misinterpretations
may have occurred, or plan errors may have been incorporated. It is suggested that each
committee review the appropriate tables and respond with corrections.
-13-
BACnet in HBES Terminology
HBES-Object Identifier:
Binary Output Object Type
HBES-Data Member
Identifier
HBES-Data Member
Data Type
Object_Identifier
Object_Name
Object_Type
Present_Value
Description
Device_Type
Status_Flag
Event_State
Reliability
Out_Of_service
Polarity
Inactive_Text
Active_Text
Change_Of_State_Time
Change_Of_State_Count
Time_Of_State_Count_Reset
Elapsed_Active_Time
Time_Of_Active_Time_Rese
t
Minimum_Off_Time
Minimum_On_Time
Priority_Array
Relinquish_Default
Time_Delay
Notification_Class
Feedback_Value
Event_Enable
Acked_Transistions
Notify_Type
Unsigned-32
CharacterString[Variant Diff]
Unsigned-16
Unsigned-8
CharacterString[Variant Diff]
CharacterString[Variant Diff]
Bit-Array(4)
Unsigned-16
Unsigned-16
Unsigned-8
Unsigned-8
CharacterString[Variant Diff]
CharacterString[Variant Diff]
Date[Variant 4I], Time[Variant 4I]
Unsigned-Integer
Date[Variant 4I], Time[Variant 4I]
Unsigned-32
Date[Variant4I], Time[Variant 4I]
Read-only
Read-only
Read-only
Read/Write
Read/Write
Read/Write
Read-only
Read-only
Read/Write
Read-only
Read-only
Read/Write
Read/Write
Read-only
Read/Write
Read-only
Read/Write
Read-only
Mandatory
Mandatory
Mandatory
Mandatory
Optional
Optional
Mandatory
Mandatory
Optional
Mandatory
Mandatory
Optional1
Optional1
Optional2
Optional2
Optional2
Optional3
Optional3
Unsigned-32
Unsigned-32
Read/Write
Read/Write
Read-only
Read/Write
Read/Write
Read/Write
Read-only
Read/Write
Read-only
Read/Write
Optional
Optional
Mandatory
Mandatory
Optional4
Optional4
Optional4
Optional4
Optional4
Optional4
Unsigned-8
Unsigned-Integer
Unsigned-Integer
Unsigned-8
Bit-Array(3)
Bit-Array(3)
Unsigned-8
-14-
HBES-Data HBES-Data
Member
Member
Read/Write Mandatory
Type
CAB in HBES Terminology
HBES-Object Identifier:
HBES-Data Member
Identifier
pv-discrete
State
alarm-state
alarm-category
contact-condition
Condition-to-alarm
Operating-mode
digital-feedback
pv-on-text
pv-off-text
Schedule
runtime-enable
runtime-value
runtime-time
runtime-date
runtime-limit
runtime-alarm-cat
runtime-reset
cos-count-enable
cos-count
cos-count-limit
cos-count-window
cos-count-alarm-cat
point-text-1
point-text-2
point-alarm-text-1
point-alarm-text-2
point-mask
Digital-Output
HBES-Data Member
Data Type
Character-String(0-10)[Variant Z]
Unsigned-8
Unsigned-8
Unsigned-8
Unsigned-8
Unsigned-8
Unsigned-8
Unsigned-8
Character-String(0-10)[Variant Z]
Character-String(0-10)[Variant Z]
Character-String(0-12)[Variant Z]
Unsigned-8
Unsigned-16
Time[Variant 3I]
Date[Variant 3I]
Unsigned-16
Unsigned-8
Unsigned-16
Unsigned-8
Unsigned-16
Unsigned-16
Unsigned-16
Unsigned-8
Character-String(0-40)[Variant Z]
Character-String(0-40)[Variant Z]
Character-String(0-80)[Variant Z]
Character-String(0-80)[Variant Z]
Bit-Array(16)
-15-
HBES-Data
Member
Read/Write
Type
HBES-Data
Member
Mandatory
Read/Write
Read/Write
Read-only
Read/Write
Read/Write
Read/Write
Read-only
Read/Write
Read/Write
Read/Write
Read/Write
Read/Write
Read-only
Read-only
Read/Write
Read/Write
Read/Write
Read/Write
Read/Write
Read/Write
Read/Write
Read/Write
Read/Write
Read/Write
Read/Write
Read/Write
Read-only
Engineering
CAL in HBES Terminology
HBES-Object Identifier:
HBES-Data Member
Identifier
current_position
default_position
function_of_position
persistence
reporting_condition
dest_address
previous_value
report_header
Binary Switch
HBES-Data Member
Data Type
Unsigned-8
Unsigned-8
Character-String(8)[Variant Z]
Unsigned-8
Byte-Array()
Byte-Array(2-16)
Unsigned-8
Byte-Array()
-16-
HBES-Data
Member
Read/Write
Type
HBES-Data
Member
Mandatory
Read/Write
Read-only
Read-only
Read-only
Read/Write
Read/Write
Read-only
Read/Write
Mandatory
Optional
Optional
Optional
Optional
Optional
Optional
Optional
CEN in HBES Terminology
HBES-Object Identifier:
HBES-Data Member
Identifier
Object_Id_Number
Object_Type
Object_Name
Present_Value
Status
Statetext
Priority
Description
Commanded_Value
Total_Runtime
Intervall_Runtime
Intervall_Runtime_Limit
Maintenance/Out_Of_Service
_Flag
Event_Disabled
Alarm_Disabled
Acknowledged_States
Alarm_Acknowledge
Default
Polarity
Minimum_Off_Time
Minimum_On_Time
Time_Delay
Binary Output FLN
HBES-Data Member
Data Type
HBES-Data
Member
Read/Write
Type
HBES-Data
Member
Mandatory
Unsigned-24
Unsigned-8
Character-String[Variant #]
Unsigned-8
Bit-Array(8)
Unsigned-8
Unsigned-8
Character-String[Variant #]
Unsigned-8
Unsigned-32
Unsigned-32
Unsigned-32
Unsigned-8
Read-only
Read-only
Read-only
Read/Write
Read-only
Read-only
Read/Write
Read-only
Read-only
Read-only
Read/Write
Read/Write
Read-only
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Unsigned-8
Unsigned-8
Unsigned-8
Unsigned-8
Unsigned-8
Unsigned-8
Unsigned-32
Unsigned-32
Unsigned-32
Read/Write
Read/Write
Read/Write
Read-only
Read-only
Read-only
Read-only
Read-only
Read-only
Optional
Optional
Optional
Optional
Engineering
Engineering
Engineering
Engineering
Engineering
-17-
SECTION 4 – RECOMMENDATIONS
In summary, we recommend that document N664 Rev B (or new document) and Terminology
(N616) documents be updated to include the above tables. Also, it is recommended that the
various committees be tasked to check and accurately update the example tables submitted in this
document.
Further improvements on the wording throughout this document would also be useful.
Author information:
Ludo Bertsch
Horizon Technologies Inc.
1552 Fort St.
Victoria, B.C.
Canada V8S 5J2
Tel: +1 250 592-0487, Fax: +1 250 592-1366
Email: lbertsch@islandnet.com
-18-