1 Introduction
In the 1990s, the Internet experienced explosive growth, becoming a globally dominant computer network. Companies like Cisco and Sun leveraged this wave to become among the world's leading corporations. A similar process is unfolding in the field of intelligent buildings. In the 1980s, the emergence of Direct Digital Controllers (DDCs) significantly improved the accuracy and flexibility of building control systems. However, as intelligent buildings have expanded to include areas such as HVAC, lighting, fire protection, and security, discrete control equipment can no longer meet the demands for interoperability and communication between devices and systems. Furthermore, with the increasing integration of building control systems, communication is required not only between devices within a single building or community, but also between control devices at the regional, national, and even global levels. Therefore, establishing a communication mechanism between heterogeneous systems and devices from different manufacturers has become an urgent need for building intelligence. The BACnet protocol emerged in response to this need.
2. Introduction to the BACnet Protocol
BACnet is a data communication protocol specifically developed for building automation control networks. It was initially developed by the American Society of Refrigeration, Heating, and Air-Conditioning Engineers (ASHRAE) in 1995. Its fundamental purpose is to provide a method for interoperability between building automation control systems. Interoperability refers to the ability of distributed control system devices to work collaboratively through the digital exchange of relevant information to achieve a common goal. BACnet solves the problem of incompatibility and integration difficulties among multi-vendor systems and devices in building automation systems, providing a method for interoperability between different building automation control systems, and is expected to become the TCP/IP protocol in control networks. In January 2003, BACnet became an official international standard (ISO 16484 standard). BACnet has the following characteristics:
• Openness: This is a current U.S. national standard and an ISO international standard.
• Object-oriented: The BACnet protocol uses object-oriented technology, thus possessing scalability and reusability.
• Interoperability: The BACnet committee of ASHRAE proposed a new method for describing the functionality of automatic control systems, called “Interoperability Areas”, which specifies five interoperability areas: data sharing, alarm and event management, timing, trend logging, and device and network management.
2.1 BACnet Architecture
BACnet uses the OSI model as a reference and combines it with the actual needs of the building automation control field to form a simplified model. BACnet makes full use of existing mature network technologies, is compatible with five network structures at the underlying level, reduces development costs, and also facilitates system integration.
2.2 Application Layer
Application layer protocol data units (APDUs) transmit information contained in application service primitives and related parameters. Because BACnet uses a simplified OSI architecture and does not include any presentation layer functionality, encoding rules that communication devices must consistently adhere to must be predefined. BACnet's encoding rules are designed with the simplification and compactness requirements of building automation systems in mind. Therefore, these encoding rules differ from ISO 8825 in some aspects. However, ASN.1 is still permitted for encoding BACnet APDUs.
2.3 Network Layer
The network layer provides network routing capabilities, enabling packets to be directly delivered to a remote device, all devices on a remote network, or all devices on all networks. A BACnet device is uniquely identified by a network number and a MAC address. Because the BACnet protocol stipulates that there can only be one valid path between two BACnet devices, this restriction significantly reduces the complexity of the network layer and simplifies routing algorithms.
2.4 Data Link Layer (MS/TP)
The data link layer is responsible for transmitting messages from one device to another, or to all local network devices. This article discusses only MS/TP networks. MS/TP uses master/slave tokens to control access to the bus network. The MS/TP protocol provides the same services to the network layer as the ISO 8802-2 logical link control protocol; and uses the services provided by the EIA-485 physical layer.
3. Program Implementation
3.1 Protocol Stack Software Structure
On high-end machines (such as workstations), we can effectively utilize the object-oriented features of the C++ language to fully implement the entire BACnet protocol stack. However, on low-end MCUs, program and data space are very limited, so it is necessary to simplify the protocol stack software architecture as much as possible. Furthermore, the protocol stack software needs to be tailored and configured according to different DDC models. Figure 2 (omitted) illustrates the interface relationships between the various modules in the protocol stack software. The most complex module in the entire structure is the application layer module, which includes the BACnet object module, basic data type module, APDU parsing/distribution module, and APDU assembly module.
3.2 Application Layer Module
To simplify its hierarchical structure, the BACnet application layer encompasses the functionalities of the session, presentation, and application layers in the Open Systems Interconnection (OSI) reference model. The BACnet application layer module is the foundation of BACnet application software; it implements the application layer content of the BACnet protocol and is responsible for providing communication services between the workstation's various functional modules and physical devices. Based on functional analysis, the application layer can be divided into the following modules: object module, service module, and basic data type module.
The object module defines BACnet objects. BACnet objects can be divided into two categories based on their function: one category consists of data acquisition objects, such as analog input/output objects, which require access to the device hardware; the other category consists of objects that perform complex functions based on the acquired data, such as loop objects and other objects that implement alarm event functions, which do not require hardware access. Additionally, certain object attributes (such as the buffer size attribute of the trend login object) require initial configuration by the device manufacturer based on the DDC model; the protocol stack provides configuration function interfaces for these attributes.
The service module handles message distribution, parsing, and assembly. For APDUs coming from the network layer, the service module calls the appropriate service parsing module based on the APDU type and service selection parameters. The service parsing module decodes the APDU information and interacts with the BACnet object in the DDC as needed. On the other hand, the DDC may send response messages (such as read attribute responses) or proactively send certain messages (such as event and alarm services), therefore the service module also provides function interfaces for service message assembly.
The Basic Data Types module is a utility library containing definitions of basic data types and their encoding and decoding functions. BACnet includes 13 application data types as well as other basic data types. BACnet application data types can be directly encoded and decoded. BACnet basic data types correspond to composite data types in ASN.1, which are composed of BACnet application data types combined with tags according to a specific structure. Therefore, encoding/decoding of basic data types is actually implemented by calling the encoding/decoding methods of application data types and tags according to certain rules.
3.3 Network Layer Module
For DDC (Data Controller), the network layer provides an unacknowledged, connectionless data unit (DMU) transmission service to the application layer. The service primitives for interaction between the network and application layers are the Network Layer Data Unit Request (N-UNITDATA.request) and the Network Layer Data Unit Indication (N-UNITDATA.indication). Their primitive parameters are as follows: N-UNITDATA.request(destination_address, data, network_priority, data_expecting_reply) N-UNITDATA.indication(source_address, destination_address, data, network_priority, data_expecting_reply)
When the DDC receives data from the link layer, it parses out the corresponding address information, binds the address information and APDU together, stores it in a structure, and sends it to the application layer. This way, when the application layer needs to reply to a message, it can obtain the target address.
3.4 Data Link Layer (MS/TP) Module
MS/TP is a master-slave/token passing data link protocol, with the physical layer adopting the RS-485 half-duplex communication standard. The MS/TP layer contains two state machines: a master node state machine and a receive frame state machine. The receive frame state machine is responsible for receiving frames; if it is a data frame, it calls the network layer interface to upload it to the network layer. The master node state machine is responsible for sending frames (including data frames and control frames). The two state machines are implemented in a time-sharing manner. Based on their relationship, the receive frame state machine can be placed within the master node state machine for unified scheduling. Figure 3 (omitted) shows the BACnet data link layer module structure. Figure 3 illustrates the sub-modules of the BACnet data link layer: the receive module implements the receive frame state machine; the send module implements the master node state machine; and the serial port control module implements serial port driving and transmit/receive control, with serial port read/write using interrupt mode.
The network layer interface module defines the interface and interface function call module, which is implemented using the service primitives DL_UNITDATA.request() and DL_UNITDATA.indication().
4. Conclusion
This paper proposes a software implementation scheme for the BACnet-MS/TP protocol in an MCU, solving the communication function of the BACnet controller. By further employing an embedded operating system to implement multi-tasking, and combining it with data acquisition, control, and configuration modules, a practical BACnet controller can be developed.
