Abstract: This paper describes the architecture of the BACnet protocol, analyzes the functions of the BACnet controller, and demonstrates the feasibility of developing a BACnet controller based on embedded Linux. The architecture and software design of the BACnet controller software are also presented. Keywords: BACnet, controller, building control equipment, embedded Linux, architecture. The BACnet protocol is a data communication protocol developed for building automation control networks. This protocol has become a US national standard (ANSI/ASHRAE 135-1995) and a draft European Union standard, and became a draft international standard in 2000. It defines 23 objects and 42 services, as well as a LAN underlying network structure of 5 data links. Annex 135a was officially released in January 1999, becoming Annex J of the standard, defining the sixth underlying technology for LAN interconnection in BACnet/IP technology. 1 BACnet Network Architecture and Controller Function Analysis 1.1 BACnet Network Architecture BACnet is built on a simplified layered architecture containing four layers. These four layers correspond to the physical layer, data link layer, network layer, and application layer in the OSI model. The BACnet standard defines its own application layer and simple network layer. For its data link layer and physical layer, it provides five options, and IP support is added in Annex J-BACnet/IP. Figure 1 shows the BACnet/IP network architecture hierarchy. BACnet does not correspond to OSI layers four, five, and six; that is, BACnet lacks transport, session, and presentation layers. The BACnet network layer shields the differences in underlying network technologies. 1.2 Functional Analysis of the BACnet Controller In a BACnet control network, a BACnet controller is typically directly connected to multiple control devices, responsible for monitoring their operation. In summary, a BACnet controller should have three main functions: ① Communication Function. As a network controller, the BACnet controller must be able to send and receive BACnet messages and communicate with other BACnet devices. ② Monitoring Function. The BACnet controller must monitor the status of the control devices directly connected to it. Therefore, it must provide data structures to describe this status. In the BACnet protocol, these statuses are described using BACnet objects. The BACnet protocol provides 42 standard objects. ③ Control Functions. The BACnet controller needs to control the operation of its connected devices, enabling interaction not only between these devices but also between these devices and remote devices within the system. Therefore, the BACnet controller should include a logic control module to achieve this function. It's worth noting that the control logic within the BACnet controller may differ at different times and locations; therefore, the BACnet controller should provide tools to modify the control flow. Ideally, these tools should have a graphical interface for user convenience. 2. Feasibility of Software Development Based on Embedded Linux ① Linux is a kernel-based, fully memory-protected, multi-tasking, multi-process operating system similar to Unix. During development, the Linux kernel functionality can be tailored using kernel building tools to create a very small embedded operating system, potentially reaching 500KB or less. ② In terms of real-time applications, general-purpose Linux is lacking in strong real-time applications. The Linux scheduler was originally designed primarily for desktop operating systems. Its focus was on application throughput, employing a "fair sharing" strategy to ensure all processes receive an average amount of CPU time. In building control equipment, which requires weak real-time performance, advanced kernel mechanisms, process scheduling algorithms, and small-granularity system time (10ms) can meet the requirements. Therefore, Linux can be used in building automation systems. ③ Linux is an open-source operating system, making it easy to obtain the kernel interface and source code. We can integrate the BACnet protocol implementation into the kernel. ④ Linux is free software. Under the GNU GPL license, it can be freely used, modified, and distributed. Therefore, using embedded Linux can reduce the cost of the BACnet controller. 3. Implementation of BACnet Controller Software 3.1 Architecture of BACnet Controller Software Based on the architecture of the BACnet protocol and the above analysis of the BACnet controller's functions, the BACnet controller software includes the following modules: BACnet protocol stack, BACnet objects and services, low-level driver module, application control logic module, and control configuration module. Unnecessary modules in the Linux kernel are removed, and some modules of the BACnet controller are embedded into the Linux kernel. The final development architecture is shown in Figure 2. 3.2 Implementation of the BACnet Protocol Stack The layered architecture of the BACnet protocol supports multiple underlying communication protocols. The network layer of BACnet abstracts different physical and data link layers, its principle being similar to the IP layer of TCP/IP. In the BACnet application layer, standard objects and services are defined to enable interconnection of BACnet products from different manufacturers. Therefore, from the perspective of the protocol content of each layer in the BACnet architecture, the BACnet architecture is "dumbbell-shaped," with the lowest layer encompassing different communication protocols and the highest layer handling diverse "entities" and applications. In the BACnet protocol, the BACnet network layer is a relatively stable part and the core of the BACnet protocol, and should be placed within the kernel. Its application programming interface (API) should be provided in the form of system calls (sys-calls). This configuration not only allows for efficient processing of the BACnet network layer within the kernel but also provides a concise and efficient calling method for external modules, making the external module code compact. The lower-level protocols and application layers of BACnet should be placed outside the kernel, either as external modules or as system programs. In this development process, the low-level protocols are compiled into the kernel in source code form. The reason is that for specific applications, the low-level protocols are usually fixed; that is, once a device connects to a network system, its low-level communication protocol will not change, thus forming a category of building automation products. 3.3 Implementation of BACnet Objects and Services BACnet objects are data structures residing in BACnet devices, providing an abstract description of the "network-visible" part of a building automation device. Each object has a set of attributes describing its characteristics and structure. BACnet objects can be divided into two categories according to their function. One category is data acquisition objects, such as analog input/output objects. These objects need to access the device hardware, and their implementation varies depending on the device hardware; therefore, if the hardware changes, the driver must be rewritten. The other category of objects performs complex functions based on the acquired data, such as loop objects and other objects that implement alarm event functions. These objects do not need to access the hardware. Each BACnet controller needs to configure the implemented objects. The BACnet service provides commands for accessing and manipulating BACnet objects on a device, and defines the format and content of these commands (i.e., service primitives). BACnet groups different services into seven parts based on device functionality: data sharing, alarm and event management, schedule, trend logging, device management, network management, and virtual terminals. The communication devices defined by BACnet consistently adhere to the ASN.1 encoding rule. Both BACnet objects and service primitives are encoded using ASN.1; therefore, the core of object and service implementation is the BACnet encoder/decoder and the abstract data types of BACnet standard data types, objects, and service primitives. The processing of BACnet objects must be handled outside the kernel. This is because different BACnet controllers have different sets of BACnet objects, and there are many types of BACnet objects. This requires embedded systems to have flexible configuration methods for BACnet objects. Implementing this flexible configuration method still requires the abstraction methods commonly used in Linux, abstracting different concrete BACnet objects to form the concept of "virtual BACnet objects." Here, "virtual objects" are different from the "virtual objects" in object-oriented programming languages. These two concepts are distinct. The former refers to the specific objects defined in the BACnet protocol. Its role is to manage the specific BACnet objects defined in the BACnet protocol, providing the kernel with an interface for configuring and manipulating these objects, similar to a "virtual file system" in the Linux kernel. 3.4 Driver Implementation BACnet supports multiple low-level communication protocols. In the BACnet controller, drivers must be written for these communication protocols. Drivers for devices such as data acquisition cards also need to be written in the BACnet controller. Drivers in the Linux operating system exist as modules and can be dynamically loaded. Different drivers can be flexibly loaded for different underlying architectures. Developing device drivers requires strict kernel requirements. Its main content involves developing corresponding device operation functions based on the kernel's `file_operations` data structure and filling in the data structure. If the peripheral device has interrupt functionality, interrupt handling functions need to be developed and installed. The structure of the `file_operations` data structure may differ depending on the kernel version; the specific structure can be determined by referring to the `linux/fs.h` header file. Among the many function pointer members of `file_operations`, usually only `reax`, `write`, `open`, and `release` need to be implemented; `ioctl` can be implemented as needed to enhance the control and management functions of peripheral devices. 3.5 BACnet Controller Application Layer Implementation The application logic layer is a specific application built on top of an embedded operating system. According to the BACnet protocol, three levels of BACnet controllers are defined—building controller, advanced application controller, and application controller—implementing the interoperability areas specified for different types of BACnet devices. Thus, the five interoperability areas specified in the protocol can be implemented in the application logic layer. This approach not only simplifies the development of the protocol's interoperability areas but also makes their development manageable. These five operation areas are: data sharing, alarm and event management, timing scheduling, trend recording, and device and network management. ① Data sharing functions include data document storage, data representation, monitoring objects, device points, and parameter modification. The BACnet controller needs to transmit locally collected data to the operator workstation for storage, mainly those values ​​that need to be viewed historically, such as the current value attributes of analog inputs/outputs, etc. For data update intervals, use 1-5 seconds for fast sampling and 30-60 seconds for slow processes, such as space temperature monitoring. When the controller receives a WriteProperty/WritePropertyMultiple service requesting endpoint reset and parameter modification, it calls local methods to modify the property values ​​of certain objects. ② Alarm and event management supports predefined value change reports, value change notifications, and event notifications. When the property value of an object changes, the controller sends a value change notification service to the devices that predefined this service, informing the recipient of the change. The controller sends an event notification service to notify remote devices that an event has occurred. The controller also supports responding to GetAlarmSummary to notify alarm status and event information. ③ Timing scheduling. The controller supports responding to WriteProperty service requests used to modify the Calendar and Shedular objects of the device. Upon receiving this service, it modifies the controller's timing table. ④ Trend logging. It supports responding to WriteProperty services used to modify TrendLog object properties. Upon receiving this service, it modifies the logged data points, sampling rate, and interval. ⑤ Device and Network Management. This operating domain supports the Device CommunicationControl service, which allows operators to disable controllers. It also supports TimeSynchronization and UTCTimeSynchronization services to ensure time synchronization; and supports the AtomicReadFile service, allowing remote reading/modification of controller configuration files and enabling configuration recovery via network backup. Conclusion: BACnet is a practical international standard building control network protocol. Controllers are one of the important devices in the BACnet control network. The successful development of BACnet controllers is of great significance for promoting the application of the BACnet protocol in building automation in China.