BACnet is composed of two intertwined specifications; one for the encoding of communications messages over some medium (wired or wireless) between two devices, and one for the presentation of the organization of information within a device. BACnet does not specify how information is organized within a device, that is left up the manufacturer, but it does specify what kinds of information must be available, including its data type, and how that information is encoded when it is being exchanged between devices.
The encoding of communications messages, hereafter referred to as a Protocol Data Unit (PDU), is specified using a limited subset of ASN.1, as an implementation language agnostic formal way to describe the parts of PDUs. None of the other companion standards such as the Basic Encoding Rules (BER), Packed Encoding Rules (PER), or XML Encoding Rules (XER) are used, BACnet specifies its own.
The organization of information within a device uses terminology loosly derived from object oriented programming paradigms; that there are “objects” which have individually referenceable “properties”. While most OOP paradigms use the term “methods” to refer to functions and procedures that operate on or with objects, BACnet uses the term “services”. Other common terminology such as “inheritance” and “polymorphism” is not used but can be inferred, for example, that all BACnet objects have an identifier with a specific format, or that the same service can be used with different types of objects.
The BACowl specification follows the BACnet standard by being divided into four sections; primitive (also called “atomic”) data, composite data structures, PDUs, and objects. Each BACowl includes labels for specific concepts within BACnet, the semantics of the relationships between these concepts, and rules for what relationships can and cannot be specified. Unlike other ontologies that are designed to be mixed together at an “upper semantic” level, BACowl can be used to marshal BACnet PDUs in RDF.
In the BACnet standard there are many common expressions that refer to a specific concept, such as a structural element being “context encoded”. BACowl gives these concepts specific labels to facilitate ontological analysis and uses OWL to formally encode concepts that might not be clearly stated in the standard, such as a structural element cannot be both “context encoded” and “application encoded” at the same time, and that all structural elements must be at least one of these two.
Standards documents are notorious for being difficult to read and understand. While the text of most standards have constrained themselves to specific meanings of terms like MUST, SHOULD, and CAN, they have not constrained themselves with mereological concepts like HAS or PART OF. There are published ontologies for some of these structural concepts such as the Simple Knowledge Organization System (SKOS), but these ontologies do not provide the level of specificity that matches the terminology in the BACnet standard. Adding sufficient constraints to these standards may break their intended usage, so BACowl includes some structual components that are not explicitly defined in the standard but are necessary to fully realize the ontology.
Users of the BACowl ontology for specific applications may find the RDF description of some concepts like primitive data to be unnaturally verbose, similar to what would appear if the relationship was reified:
x:some_object x:some_property [ rdf:value 12 ] .
This is purposfully done to facilitate an RDF node being bound to a concept that has a value, where that concept may also be referenced by other communications protocols like MODBUS. Every “thing” in RDF has a unique identifier so it can be referenced directly rather than using a path expression such as XPath, or requiring additional globally or locally scoped identifiers.
Understanding the relationship between the BACowl specification and other ontologies, specifically the Building Information Model (BIM), the Facilities Smart Grid Information Model (FSGIM), and taxonomies such as Project Haystack is the subject of ongoing research.
There are a few places in the BACnet standard where very similar terms are used to describe very different concepts, such as “device”, “device object”, “object identifier”, and “device identifier”. BACowl follows the BACnet standard and gives these concepts distinct labels and rules. Generating a visualization of the graph of the relationship between these terms is a facinating exercize.
There are also terms such as “remote broadcast” and “directed broadcast” that have very similar semantics (both referring to an address that is used to communicate with many devices on another network), BACowl does not attempt to reconcile these into one semantic concept.
There are a number of other components of the BACnet standards
BACnet provides additional communications protocols in the form of web services that can be used to exchange BACnet content and the content of other devices that do not exchange BACnet PDUs. There are additional protocols under development now such as RESTful web services that provide even more options to the building automation systems integrator. BACowl does not currently model these protocols and the authors anticipate that these other services, which define their own ontologies and use terminology from other standards, will be modular additions to BACowl.