SwarmL: A Language for Programming Fully Distributed Intelligent Building Systems

Abstract

Fully distributed intelligent building systems can be used to effectively reduce the complexity of building automation systems and improve the efficiency of the operation and maintenance management because of its self-organization, flexibility, and robustness. However, the parallel computing mode, dynamic network topology, and complex node interaction logic make application development complex, time-consuming, and challenging. To address the development difficulties of fully distributed intelligent building system applications, this paper proposes a user-friendly programming language called SwarmL. Concretely, SwarmL (1) establishes a language model, an overall framework, and an abstract syntax that intuitively describes the static physical objects and dynamic execution mechanisms of a fully distributed intelligent building system, (2) proposes a physical field-oriented variable that adapts the programming model to the distributed architectures by employing a serial programming style in accordance with human thinking to program parallel applications of fully distributed intelligent building systems for reducing programming difficulty, (3) designs a computational scope-based communication mechanism that separates the computational logic from the node interaction logic, thus adapting to dynamically changing network topologies and supporting the generalized development of the fully distributed intelligent building system applications, and (4) implements an integrated development tool that supports program editing and object code generation. To validate SwarmL, an example application of a real scenario and a subject-based experiment are explored. The results demonstrate that SwarmL can effectively reduce the programming difficulty and improve the development efficiency of fully distributed intelligent building system applications. SwarmL enables building users to quickly understand and master the development methods of application tasks in fully distributed intelligent building systems, and supports the intuitive description and generalized, efficient development of application tasks. The created SwarmL support tool supports the downloading and deployment of applications for fully distributed intelligent building systems, which can improve the efficiency of building control management and promote the application and popularization of new intelligent building systems.

1. Introduction

Intelligent buildings are becoming a trend in the construction of future buildings; they are large-scale dynamic systems with a high complexity and a very large amount of information [1]. Combining the available information with the effective control of the entire building system and reducing the energy consumption of a building are considerable challenges [2,3,4]. Swarm intelligence [5] is the emergent collective intelligence of groups of simple autonomous agents with a centerless and distributed structure [6], which has been proven to be an effective method of dealing with dynamic and complex building automation systems [7,8]. In the fully distributed intelligent building system (FDIBS) framework, a building is modeled as a centerless and decentralized computing network composed of a group of smart nodes with computing and communication functions, where each node corresponds to a building space area or piece of large electromechanical equipment, as shown in Figure 1. Each node is preset with a standard information model, which stores all kinds of parameter information for the building space or large electromechanical equipment in a standardized manner. Through node interaction and communication, cooperation behaviors and complex actions at the system level are generated to perform various building control tasks. Based on plug-and-play nodes and standard information models, this decentralized framework of information and control technology can address the deficiencies of traditional centralized control schemes [9], such as the complex design process, the difficulties of automatic configuration and deployment [7], self-organization, and scalability. Similar to building information model (BIM) technology [10,11,12] and wireless sensor network (WSN) technology [13], an FDIBS improves the level of digitization and informatization of buildings by applying sensors and information technology (IT) to building automation systems [14]. An FDIBS allows building control tasks to be developed as downloadable and generalized applications (APPs) that are independent of specific network topologies and building structures. This development mode makes buildings more efficient and smarter. However, APP development is challenging due to inconsistency between the parallel programming mode of the FDIBS platform and the serial programming style in accordance with human thinking, the gap between global-oriented functional requirements and single-node-oriented programming, and the dynamics and uncertainty of the applied network topology (e.g., due to failure, mobility, or openness issues).

General-purpose programming languages such as C and Java involve a single instruction stream and a traditional centralized memory management mode, which are not well suited for this new parallel platform architecture. Currently, popular distributed programming models, such as the open multiprocessing (OpenMP) [15] and message passing interface (MPI) [16] models, require users to be familiar with the underlying structure of the system, which requires complex task division, data communication, and synchronous design when designing parallel programs. Establishing spatial abstraction oriented toward a distributed network architecture can effectively reduce the programming complexity. For example, Hood [17] and Spidey [18] in WSN programming and the INR (individual, neighborhood, and region) model [19] designed by our team to establish a group-level programming abstraction [20,21] according to the physical distances and logical attributes of the nodes. Although these methods enable flexible access to data among a set of nodes and reduce the complexity of communication and storage, they can only characterize global calculations within local ranges. Since the functional requirements of FDIBS control tasks are expressed at the global level of the network, the lack of programming abstractions that define the globally distributed physical fields of buildings makes it difficult to concisely describe global parallel computing tasks.

To solve global-to-local problems, the Touch language [22] and a graphical programming language [23] previously proposed by our team are used to define programming abstractions for single nodes, neighborhoods, and global networks to provide intuitive descriptions of parallel control tasks for insect intelligent buildings (I²Bs) [7]. Similarly, Buzz [24,25], for swarm robot programming, combines a bottom-up behavioral deployment strategy for a single robot [26] with a top-down swarm strategy [27], and it can effectively describe a large number of swarm behaviors. However, these programming languages do not include variable definitions at the global perspective to intrinsically support parallel computing mechanisms. Moreover, their tight coupling to node addresses or the unique identifiers of robots makes it difficult to directly deal with FDIBS scenarios with dynamic changes in the network topology; therefore, they are not conducive to supporting the generalized development of FDIBS APPs.

To address these challenges of FDIBS APP development and reduce the programming difficulty, a novel programming language called SwarmL is proposed, and a corresponding support tool is implemented for the efficient development of APPs. SwarmL employs a serial programming style in accordance with human thinking to implement parallel FDIBS APPs and supports the generalized development of FDIBS APPs. The main contributions of this study are as follows.

(1)

An entire language system is introduced for SwarmL. The language model, overall framework, and abstract syntax of SwarmL are established to abstractly define and map building entity objects, physical fields, and their dynamic interaction relations into basic data types, variables, and parallel operators, making buildings direct programming objects. By defining an innovative field-oriented variable that depicts the spatially distributed physical field of a building and the computational scope that dynamically specifies the object set of node interactions, SwarmL endogenously describes parallel FDIBS control tasks in a manner consistent with human serial thinking and supports the generalized development of FDIBS APPs, thus effectively reducing the programming difficulty.

(2)

The key implementation mechanisms of SwarmL are determined, and an integrated development tool is established. Based on field-oriented variables and the computational scope, SwarmL enables the intuitive programming of universal parallel tasks such as global synchronous diffusion and global computing in FDIBSs, thus separating the computational logic of applications from the node interaction logic and shielding the complex communication details involved in the interaction process. Furthermore, the SwarmL editor and compiler are integrated by implementing a visual development tool for SwarmL to support program editing and object code generation functions.

(3)

Experiments are conducted to evaluate the descriptive capability, effectiveness, and efficiency of SwarmL. SwarmL is applied to develop control APPs for a variable air volume (VAV) air conditioning system in an FDIBS. The experimental results in the actual scenario verify that the APP developed by SwarmL can successfully run on the selected building platform. Additionally, the results of a subject-based empirical evaluation show that SwarmL is more efficient than the existing APP development methods. Furthermore, SwarmL is a good example and provides a reference for developing swarm intelligence systems with centerless and node interaction features.

The rest of this paper is organized as follows. Section 2 introduces the related works. In Section 3, a motivating example of the FDIBS control task is given. Section 4 defines the entire Swarm language system and introduces the key implementation mechanisms and an integrated development tool of SwarmL. In Section 5, the ability of SwarmL to describe the FDIBS control tasks is verified, as are the effectiveness and efficiency of the new language. Finally, Section 6 concludes the paper.

2. Related Work

With the development of decentralized systems such as WSNs [28,29], Internet of Thing systems [30,31], and robotic swarms [32], much research has been conducted to provide support for application programming. Below, this section introduces some mainstream programming paradigms and methods for addressing the complexity of node interaction and parallel computing mode, global-to-local mapping problems, and dynamic network topologies.

Introducing spatial abstraction oriented toward a distributed network architecture into program design is an effective method of simplifying node interactions and reducing programming difficulty. In WSN programming, group-level abstractions [20] are constructed according to a grouping of the physical distance of nodes [17] or logical attributes (e.g., the node type and sensor input) [18]. JaCaMo (Jason, Cartago, and Moise), for multiagent system programming [33], uses roles to define complex interactions between objects. The INR model [19] previously proposed by our team for I²B APP development defines neighborhood abstractions to describe the location attributes of variables according to the logical addresses of the nodes. These methods support a declarative description of application functionality to program a set of nodes, shielding the user from the details of communication between nodes. Unlike our method, global computing tasks are programmed by describing local node interactions, and the focus is not on raising the level of abstraction beyond local interaction rules and aggregation-level descriptions, which makes it difficult to directly map the global functional requirements of the parallel tasks to the behavior of single nodes.

In terms of solving global-to-local problems [34], aggregate computing [35,36] and general spatial computing [37,38] propose a global perspective for design and programming. They specify a collective behavior by combining building block algorithms [39], each with a known mapping from a collective behavior to a set of local interactions that produce that behavior, which simplifies the design, creation, and maintenance of distributed systems. Many aggregate programming methods have been presented [40], such as knowledge-based integration [41], Scafi [42] for adaptive large-scale situated systems, and the nature-inspired coordination model [43]. However, these approaches are not applicable to the development of FDIBS APPs due to differences in the domain characteristics. In swarm robotics system programming, Buzz [24,25] combines a bottom-up behavior deployment strategy based on the capabilities of a single robot (e.g., the robot operating system (ROS) [26]) with the top-down swarm strategy (e.g., Protelis [27] for aggregate programming), which can express a large number of swarm behaviors and solve the mapping problem between swarm-level needs and individual behaviors. Our team proposes the textual Touch language [22] and a graphical language [23], which establish individual, neighborhood, and global programming abstractions to describe physical objects in buildings and the distributed and parallel execution mechanism of the control tasks in I²B. However, their dependence on node addresses or the unique identifiers of robots may make it difficult to support dynamically changing network topologies and generalized APP development. In contrast to these methods, SwarmL directly defines physical field-oriented variables as global programming concepts with spatial location attributes to achieve automatic global-to-local mapping rather than merely establishing programming abstractions that describe a set of node locations. Defining field-oriented variables as global concepts can enable parallel and synchronous computation tasks to be represented endogenously and effectively reduce the programming difficulty.

In terms of supporting programming that is oriented toward a dynamic network topology, a computational field [44,45] is a distributed data structure that maps devices to computing objects across time and can dynamically specify a set of node locations [46]. TOTA (tuples on the air) [47], for the development of pervasive computing applications, is an example of a computational field. TOTA relies on spatially distributed tuples [48], which are propagated adaptively across the network according to application-specific rules, for both representing contextual information and supporting uncoupled interactions between application components. Moreover, the Agent programming language 2OPL (organization-oriented programming language) [49] uses the organization and role to encapsulate the variable behavior of an object and achieves dynamic changes in the object behavior through a dynamic binding relationship between the object and role. These methods are robust to changes in the underlying topology and unexpected interactions with the external environment, freeing programmers from the need to deal with low-level problems related to network dynamics. Unlike these methods, the computational scope-based communication mechanism proposed in this paper considers the more diversified network structures of FDIBSs. For instance, nodes can be divided into starting and participating nodes based on an event-triggering mechanism, and upstream and downstream nodes based on the spanning tree mechanism.

3. Motivation and Research Challenges

This section analyzes the challenges faced in APP development with a typical case of an FDIBS.

3.1. Motivating Example

The VAV air conditioning system is a typical all-air air conditioning system in buildings that can meet the comfort requirements of indoor personnel by coordinating the control of the damper opening and fan speed [50,51]. As shown in Figure 2, this system consists of an air handling unit (AHU) and terminal VAV boxes in several rooms. Both the AHU as a smart equipment unit and the room as a building space unit are configured with a smart node, and these nodes are connected to form a centerless, self-organizing, self-identifying computing network. In each building unit, the node is connected to a local drive controller unit (DCU), which is connected to various local sensors, actuators, and device controllers. The node integrates and manages all the local information, which is the mapping of standard data tables within the local DCU.

In this system, the AHU adjusts the fan speed according to the load demand of the room to provide a cold/hot air volume, and the VAV box adjusts the damper opening according to the indoor load change to control the air supply volume of each room. Once the APP is deployed on the nodes, each node runs its local copy. The optimization control algorithm applied to the VAV system of an FDIBS can automatically coordinate the damper opening at the adjacent end of the pipeline and cancel the pressure-related coupling relationship between them [52]. Without a pressure sensor, the algorithm adjusts the speed of the air supply fan of the AHU according to the sum of the actual air volume at the end of each VAV to meet the demand for the end air volume and reduce the energy consumption of the fan [53]. The specific steps of the algorithm are shown in Figure 3.

Step 1: Calculate the damper opening. Each room node periodically calculates the expected value of the damper opening change ΔV₀ according to T_act and T_set and the fuzzy control function f₁.

Step 2: Correct the damper opening. When the system detects that ΔV₀ for any room node is not equal to 0, this node is used as the starting node to trigger the correction calculation. Each room node receives the damper opening change ΔV_i (i ≤ 6) of the neighbor nodes, and the correction value of the local damper opening change is calculated as $\Delta V_{cor}=max(\Delta V_i)\ast \delta$. Then, the set value of the local damper opening is updated, $V_{set}{=V}_{fb}+\Delta V_{cor}$.

Step 3: Calculate the total required air volume. The AHU node triggers this calculation and acts as the root node to automatically create a communication spanning tree with upstream and downstream relationships. Each room node sums the required air volume values of the downstream nodes and itself and transmits it to the upstream node. Finally, the AHU node obtains the sum Q_sum of the required air volumes of all rooms in the system.

Step 4: Calculate the fan speed. The AHU node substitutes Q_sum into the local function f₂ to calculate the fan speed F_s.

This application task adopts periodic triggering and event triggering mechanisms. All nodes complete the task through data interaction (e.g., Steps 2 and 3) and parallel computation. Moreover, Steps 1 and 4 are local tasks of the end room nodes and the AHU node, while Steps 2 and 3 are the network computing activities based on the node interactions. This task has the following characteristics:

(1)

The range of nodes participating in the calculations varies. The nodes participating in Step 3 include the AHU and all room nodes, while Step 2 only includes all room nodes.

(2)

The types of starting nodes in the two steps are different. In Step 2, any room node whose ΔV₀ is not equal to 0 can trigger the calculation, i.e., the starting node is not fixed. In Step 3, the starting node must be an AHU node because only the starting node can obtain the result of the network summation.

(3)

The interaction objects of the nodes are different. In Step 2, the room nodes interact with all logical neighbors in the network topology of the VAV system. In Step 3, the nodes determine different interaction objects and computing logics according to the upstream and downstream topological relationships of the spanning tree.

(4)

Universality. The algorithm is automatically applicable to VAV systems with different numbers of end rooms and different air duct structures.

(5)

The spatial requirements for the building operations depend on what needs to be measured and controlled (such as the temperature, humidity, or illumination). For example, in closed-loop daylight acquisition [54], the intelligent building system needs to stream data from 51 workstations in two rooms to collect physical data on daylight and artificial lighting. In contrast, the distribution of temperature in the VAV system’s optimization control case in this paper is limited to a single room. The spatial data required for a local building operation generally does not exceed the range of the space unit or equipment unit to which it belongs, and when it exceeds this range, data processing and calculation are performed through node interaction.

The fully distributed intelligent building system applies to a variety of building services (e.g., closed-loop control of lights and curtains, group control of chiller units [55], sensor fault diagnosis [56], etc.), enabling energy savings, better maintenance, improved human comfort, and reduced costs. This system is explained from the context of VAV systems, as these are widely used in buildings and tend to use a lot of operation energy. However, the concepts explained in this paper can be applied more widely to other services, which are briefly mentioned in Section 4 of this paper.

3.2. Key Challenges of APP Development

The complex characteristics of the algorithm bring the following research challenges (RC) for APP development:

(RC1) How to explicitly depict the spatially distributed building information to concisely program the parallel computing task of an FDIBS in a manner consistent with human serial thinking? The building information used for node interaction is defined as a series of variables in the program; this information has spatial attributes (e.g., types of nodes and functional systems) and may be distributed on different nodes in the network, such as the temperature T_act and fan speed F_s in Figure 3. During programming, users need to describe the spatial attributes of variables, resulting in the tight coupling of spatial attributes and computational logic and complicated programming. Furthermore, the functional requirements of a VAV system are expressed at the global level, but variable definitions are limited to a single node, which makes it difficult to map global functional requirements to the behaviors of single nodes and to intuitively program parallel computing tasks. Existing approaches mostly program decentralized computing systems based on local interaction behaviors without providing a holistic view to program the entire system.

(RC2) How should the scope of node interaction be specified dynamically to adapt to changes in the system structure? The VAV system runs in an open environment, and its network topology is highly dynamic and uncertain, which makes it difficult to specify the node interaction scope when programming network calculations; that is, to specify which nodes should interact, to which nodes the calculation results should be published, etc. Moreover, nodes may perform different functions in the same task; for example, the control strategies of AHU nodes and room nodes are different. The diverse range of functional roles played by nodes (e.g., starting nodes and participating nodes) and the complexity of the network topology (e.g., upstream and downstream relationships) also make it difficult to describe the interaction scope of nodes.

4. Methodology

4.1. Defining SwarmL

To address the above challenges, SwarmL, a user-friendly programming language that is attuned to human thinking, is proposed for FDIBS APP development. The language model, overall framework, and abstract syntax of SwarmL are first established. Additionally, the paper presents two special programming concepts of SwarmL, the field-oriented variable that supports the endogenous description of parallel computing tasks and the computational scope, which that dynamically specifies the interaction range of smart nodes.

4.1.1. SwarmL Model

The SwarmL language model defines the main domain concepts in an FDIBS and the relevant language elements and relationships among them, as shown in Figure 4.

Definition 1 (Node). 

Smart nodes are the basic units that constitute an FDIBS. An FDIBS is a decentralized network composed of building space units and large electromechanical equipment. Each basic unit is equipped with a smart node with information processing and decision-making capabilities, and these nodes are connected to form the building. The type of node is the type of basic building unit to which the node corresponds, such as building space units and pumps.

Definition 2 (Domain). 

A domain is a functional subnetwork composed of several nodes in an FDIBS according to some specific constraints, such as the VAV system. A domain specifies a collection of nodes that run a particular piece of a program. The domain name is the unique identifier of a domain in the FDIBS.

Definition 3 (Standard information model). 

Each node has a built-in standard information model that stores all the building information data for the area managed by the node in a standardized manner for unified maintenance and management. As shown in Figure 1, each node is connected to a local drive controller unit (DCU), which is connected to various local sensors, actuators, and device controllers. Based on the standard information model, after a node is connected to the corresponding DCU, the node can automatically determine whether the corresponding DCU is a building space unit or an electromechanical equipment unit (e.g., chiller, pump, or other device) based on the exchanged information. Then, the database of this standard information model is automatically loaded and matched with the information set of the connected DCU to perform data mapping. Therefore, a smart node can integrate and manage all the local information and control local devices. The building information stored in the standard information model is the main object of node interaction. The program can control the equipment system in a building by reading and writing the values of these physical quantities.

Definition 4 (Physical field). 

The building physical fields represent the environmental or system parameters that are spatially distributed in the building, the feedback value and set value of equipment operation states, and other physical quantities, such as temperature and humidity. Sensors in the building unit collect information about the physical fields in the building every 5 min and send this information to a smart node. The information is then stored in a unified format in the standard information model of the node and can be displayed in real time on a fully distributed intelligent building system platform.

A field-oriented variable is mapped from a physical field element and is the distribution field of a quantity with a specific meaning in an FDIBS, i.e., the set of distribution data of this quantity on nodes. A field-oriented variable contains data and distribution properties. Among them, the node type and domain name describe the distribution properties of the variable, i.e., on which nodes the variable has valid values. In the FDIBS control task, the space or dimension required for a building operation can be specified by defining the node type and domain name of the field-oriented variable. The data and updated time describe the data properties of the field-oriented variable. Since field-oriented variables are globally defined for FDIBS networks, it is neither convenient nor flexible to substitute field-oriented variables directly into program operations when describing the specific calculation process of FDIBS control tasks.

A parameter is a projection of a field-oriented variable onto a computational scope, which represents a collection of nodes with specific functional roles commonly used in FDIBS control tasks, such as starting nodes that trigger network computing tasks, and upstream and downstream nodes. A domain is a static network or set of nodes defined in an FDIBS, while the computational scope dynamically specifies the range of nodes covered by a certain calculation and provides a general description for defining the corresponding relationships involving projection of variables and parameters. Therefore, parameters are characterized based on the relevant data, update time, and computational scope. By defining the field-oriented variables corresponding to the operating information of the building space and electromechanical equipment systems in an FDIBS APP and then connecting the field-oriented variables with the information provided by real existing devices such as sensors and actuators, the APP can read and write physical equipment-based data to operate the equipment. During programming, the computational scope can be flexibly selected according to the task requirements to substitute the parameters of different node ranges into the expression calculation to perform the corresponding network computation tasks. The field-oriented variables, parameters, and computational scopes in SwarmL are the basis for implementing the concise description of parallel computing tasks and supporting the generalized development of FDIBS APPs.

4.1.2. Framework of SwarmL

Rooted in FDIBSs, SwarmL is different from existing languages in terms of data types, variables, statements, etc. It intuitively depicts the static physical objects and dynamic operating mechanisms of the control tasks of FDIBSs. The overall framework of SwarmL is established and is divided into three types of language elements, as shown in Figure 5.

In the first part, the static physical objects of the building at different levels in the FDIBS are abstracted into the domain-specific data types of SwarmL to directly program domain concepts, as shown in

Table 1. Data types of SwarmL.

Domain-Specific Data Types			Generic Data Types
Nodes	Domains	Field-Oriented Variables
ROOM	VAV system	Temperature	int
AHU	Lighting system	Light	float
PUMP	Evacuation system	Humidity	bool
CHILLER	Chilled water system	Pressure	string
…	…	…	…

. Among them, nodes describe the basic building units (i.e., building space areas and large electromechanical equipment) and can be instantiated as objects of different types, such as ROOM, AHU, and PUMP. A domain describes a functional building system connected by basic unit nodes according to the spatial position and specifies a collection of nodes that run an application. Depending on constraints such as the types of nodes they contain, domains can also be instantiated as objects of different types, e.g., VAV systems, lighting systems, and evacuation systems. For example, the name of the domain defined in line 1 in Figure 6 is VAVsystem, which consists of room nodes and AHU nodes. Furthermore, unlike variables that describe memory addresses in general-purpose programming languages, the field-oriented variables in SwarmL describe the globally distributed physical fields of buildings, such as the temperature field and humidity field. A field-oriented variable represents a collection of physical quantities on nodes and endogenously supports the description of the parallel and synchronous execution of tasks. For example, the field-oriented variable Temperature defined in line 3 represents the set of actual temperatures on all room nodes. A parameter is the numerical projection of a field-oriented variable on the set of nodes with functional roles, and it can be directly substituted into programs for operation. The parameter TemperatureP defined in line 7 represents the numerical projection of Temperature onto the starting node that triggers the computing task.

The second part describes the execution mechanisms of distributed application tasks of the FDIBS, including the computational scope, Swarm parallel statements, and processes. The computational scope represents the location attribute of the parameter, which is used to describe the node interaction objects. Unlike general-purpose programming languages that use fixed node addresses to specify the interaction objects, the computational scope dynamically specifies the range of node interactions according to the functional roles of nodes, which decouples the application from the node address and supports the dynamic network topology. Moreover, the computational scope provides global and local perspectives to describe global parallel computations, which yields greater completeness. For example, line 9 in Figure 6 defines the global parameter dOpen_ExpectedP, the computational scope of which is All, representing the set of values of the field-oriented variable damperOpen_Expected on all room nodes. The local parameter dOpen_Expected_U defined in line 12 representing the set of values of damperOpen_Expected on upstream neighbors. Unlike the serial description of general statements, Swarm parallel statements support direct programming from a parallel perspective and describe the parallel processing mechanisms of application tasks. As shown in line 10, each node executes each sub-statement in a Swarm parallel statement in parallel. Unlike traditional event triggering, the processes concisely describe the periodic triggering mechanisms of application tasks and support the synchronous execution and processing of multiple tasks. Line 8 indicates that the code in the process is executed every five minutes. The third part is general language elements, including expressions that describe general operations; general statements with branch, jump, and loop relationships; and system functions. Combining declarative and imperative programming paradigms, SwarmL ensures a short learning curve for beginners and easy-to-read and familiar programs. The core parts of SwarmL syntax in Backus–Naur form is presented in Figure A1 of Appendix A.

4.1.3. Physical Field-Oriented Variables

Each smart node in the FDIBS integrates all the kinds of information inside the building space and electromechanical equipment unit, which is the primary object for the interaction between nodes and can be read or written to control the state of a local device. Based on smart nodes and building information, the building becomes a large information network, in which each information point has significant geographical location characteristics. The distributed processing required by building application tasks may span different parts of the physical space of the building, and the interoperability of information is often closely related to the geographical location. Therefore, when developing an APP, it is necessary to describe not only the data attributes of building information but also its spatial distribution attributes to perform calculations on building information with different nodes. However, this computing pattern is difficult to obtain under the programming paradigm of general-purpose languages.

To address this challenge, this paper examines the building system from a new global perspective based on the characteristics of environmental building elements. A building can be regarded as being composed of basic physical facilities (including physical entities, spaces, and electromechanics) and environmental elements that describe the attributes and status of basic physical facilities. The latter can not only be sensed and read by end devices (e.g., sensors) to reflect the state of the building environment but can also control the devices by actively changing the set values so that the building environment always meets the needs of people. Each objectively existing environmental element in the building has a spatial regional distribution, which is a physical quantity dispersed in space and time. Therefore, the built environment is essentially a multi-physical field integrating a variety of building information, and each kind of which can be regarded as a physical field. For instance, the temperature parameters of all building units form a two-dimensional plane of temperature, that is, the temperature field, as shown in Figure 7. Therefore, this paper directly abstracts the spatially distributed physical field into a first-order programming entity and proposes the programming abstraction of a field-oriented variable.

Definition 5 (Field-oriented variable). 

The field-oriented variable is the distribution field of a quantity with a specific meaning in the FDIBS and contains the data and distribution attributes of a variable. It can be formally represented as a binary value:

Field-oriented vaviable = <Var_Data, Var_Dist>

where

• Var_Data: The data attribute of the variable, also called a parameter, represents the data values of the variable onto a collection of nodes with specific functional roles and the time at which each value is generated. Parameters can be directly substituted into expressions or functions for operations in programming.
• Var_Dist: The distribution attribute represents the set of nodes where valid values of the variable exist and is represented by the node type and the domain name to which the node belongs.

Figure A2 in Appendix A shows the sample code for defining field-oriented variables and parameters. The field-oriented variable effectively solves the challenge RC1 in Section 3.2, improves the perspective of variable definitions from the previous perspective of a single node to the global perspective, and explicitly describes the spatial distribution characteristics of the building information. It decouples the computational logic and the spatial attributes of variables and reduces the programming complexity.

4.1.4. Dynamic Computational Scope

In application tasks of FDIBSs, a smart node does not necessarily need to interact with all nodes. On the one hand, in the global scope of the functional system, the smart nodes do not necessarily need to interact with all nodes in the functional system of the building and may only establish a communication relationship with a certain type of node. On the other hand, within the neighborhood, a node may only interact with downstream nodes instead of all neighbor nodes. For example, in Step 3 of Figure 3, each room node only collects the sum of the required air volume of all downstream neighbors in the spanning tree and sends it to its upstream neighbor. However, the self-organizing and plug-and-play nature of the FDIBS makes the network topology highly dynamic and uncertain (e.g., due to mobility or openness). The various functional roles that nodes play in the network are difficult to identify effectively in programming. These factors make it a challenge to dynamically and completely describe the scope of the nodes and interaction objects involved in network computing. Since developers generally do not know the network topology and scale of the building system during APP development, it is difficult to specify the range of the node set. However, starting from the computing mechanism and the characteristics of application tasks of FDIBSs, several common node sets can always be defined according to the following principles:

(P1) Physical attributes. A functional system is a virtual network on a physical network formed by node connections, and all computing tasks are performed on the corresponding functional subnet. The set of all neighbors of a node can be specified according to the physical or logical connection relationship in the subnet.

(P2) Triggering characteristics. In application tasks of FDIBSs, the nodes in the functional system can be divided into the starting node that triggers the computing tasks and other nodes that participate in the computation. The starting node triggers computing tasks to other nodes by diffusing broadcasting and may also receive computing results, as the AHU node does in Step 3 of Figure 3.

(P3) Network topology. To effectively support computing logic, e.g., network summation and diffusion, some application tasks dynamically generate a tree-shaped computing network when the network topology is established, in which nodes can identify the local system topology through interaction [57]. Neighbor nodes may have conceptual relationships such as being upstream and downstream, based on which a set of upstream and downstream nodes within the neighborhood can be established.

P1 specifies node sets according to physical attributes while P2 and P3 according to the functional roles of nodes. Previous studies proposed the concepts of a basic unit, neighborhood, and domain [19,22] for P1 but neglected P2 and P3. Moreover, existing methods only support programming from the perspective of a single node and neighborhood, and the lack of a global perspective makes it difficult for users to concisely describe the global computing logic. Therefore, based on the static basic unit, neighborhood and domain, this paper proposes a dynamic computational scope with greater completeness to represent the node interaction scope, which adds the common programming abstraction of the functional roles of nodes and combines the global and local perspectives. Figure 8 shows a schematic of the computational scope.

Definition 6 (Computational scope). 

The computational scope is a set of nodes with common functional roles and attributes that are commonly used to describe distributed application tasks of FDIBSs and is also a general description method used to define the mapping relationship between field-oriented variables and parameters. It can be formally represented as a six-tuple.

Computational scope = <G_StartNode, G_All, L_Me, L_AllNeighbors, L_Upstream, L_Downstream>

where

• G_StartNode: The node that triggers the computing tasks from the global perspective of the computing network.
• G_All: All nodes in the domain from the global perspective of the computing network.
• L_Me: When describing a local computing mechanism, this represents a node itself.
• L_AllNeighbors: When describing a local computing mechanism, this represents the set of all existing neighbors around a node.
• L_Upstream: When the computing network forms a spanning tree with the starting node as the root node, this represents the upstream neighbor node.
• L_Downstream: When the computing network forms a spanning tree with the starting node as the root node, this represents the set of downstream neighbor nodes.

G_StartNode and G_All are descriptions from the perspective of the whole functional system, which are collectively referred to as the global scope. L_Me, L_AllNeighbors, L_Upstream, and L_Downstream are all descriptions from the perspective of a certain node, which can be collectively referred to as the local scopes. The parameters are also divided into global parameters and local parameters according to the difference in the computational scope. When describing the specific calculation process of an FDIBS application task, the numerical field of the global parameter may be substituted into the calculation macroscopically, or it may only focus on the local part, and illustrate the overall calculation mechanism by describing the local numerical calculation between the node and its neighbors. The sample code for defining the parameters and computational scopes is presented in Figure A3 of Appendix A. The specific implementation mechanisms involving the parameter and computational scope is introduced in Section 4.2.

The computational scope is generally defined declaratively in the APP but can dynamically specify the set of nodes that will be affected by computation during program execution. Each time the program is executed, the computational scope changes dynamically when it is executed on different parts. The computational scope eliminates the application’s dependence on the specific neighbor node number or location and can adapt to buildings with different topologies. It effectively solves the challenge RC2 in Section 3.2 and supports the generalized development of the FDIBS APP.

4.2. Key Implementation Mechanisms of SwarmL

The field-oriented variable and computational scope form a set of simple and powerful basic building blocks that developers can use to express the typical operation task logic of FDIBSs to cover a wide range of application scenarios. This section introduces a series of key programming functions that can be realized by using SwarmL in APP development, including global diffusion, global calculation, and masking complex variable read and write mechanisms. Furthermore, an integrated development tool for SwarmL is implemented with the functions of program editing and object code generation.

4.2.1. Global Synchronous Diffusion

The parameters with the computational scope attribute represent the numerical set of a certain field-oriented variable on several nodes. Therefore, the semantics of the SwarmL expressions composed of parameters and operators may be different from those of general expressions, which can intuitively express parallel computing logic. Taking the assignment operation as an example, the number of data values in the parameters defined by different computational scopes may be different because the ranges of nodes covered by different computational scopes may be different. If the computational scope of the left parameter of “=” has multiple nodes and the computational scope of the right parameter has only one node, the value of the only node of the right parameter will be assigned to the multiple nodes in the computational scope of the left parameter. The typical global synchronous diffusion operation in the application task of the FDIBS can be described concisely in programming by taking advantage of the difference in computational scope, which is illustrated by line 7 of the program in Figure 9.

The first line defines the field-oriented variable, i.e., FireAlarm, which is only valid in the evacuation system and nodes of type “ROOM”. The global parameters FireSource and Alarm defined in lines 3 and 4 are both derived from FireAlarm, where their computational scopes are StartNode and All, respectively. In line 7, the fire alarm signal of the starting node is diffused to the entire evacuation system network by assigning the FireSource, whose computational scope is StartNode, to the Alarm, whose computational scope is All, as shown in Case 1 in Figure 9. In contrast, when the right side of “=” is a constant and the computational scope of the parameter on the left is All, it means that the constant is used to assign values to variables on all room nodes in the system. For example, line 8 assigns the parameter Alarm on all nodes to 1, which does not involve an interaction between the nodes and belongs to the local calculation of each room node, as shown in Case 3 in Figure 9.

The combination of parameters and computational scope maps the global task requirements directly to the behaviors of single nodes, endogenously characterizing the global synchronous diffusion task and parallel execution mechanism. What previously required dozens of lines of the platform-dependent C code can now attain a greatly reduced programming complexity.

4.2.2. Global Calculation

When faced with operations such as the global summation and global quadrature of node networks with data transfer properties, traditional methods usually perform these tasks from a local perspective. Taking network global summation as an example, after the starting node is used as the root node to automatically generate a virtual spanning tree, each node collects the values of the downstream neighbors, sums them with its own value, and sends the result to the upstream neighbor. Finally, the starting node obtains the sum of the data of all nodes in the network. Although this programming method can completely describe the algorithm logic, it requires effort to describe the computing operations of nodes and upstream and downstream neighbors separately.

SwarmL combines global parameters with a single operator to concisely describe this task from a global perspective in a way that is close to human thinking. As shown in Figure 9, the global parameters SumTemp and Temp defined in lines 5 and 6 are both derived from the field-oriented variable Temperature defined in line 2, and their global computational scopes are StartNode and All, respectively. In line 9, the sum of Temp for all room nodes in the evacuation functional network is directly obtained through the simple operator “+”, and the sum is assigned to SumTemp on the starting node, as shown in Case 2 of Figure 9. For global calculation tasks, SwarmL, based on a global perspective, can greatly reduce the programming difficulty and makes the program easier to maintain, while in most other high-level languages, complex synchronization and message passing are required.

4.2.3. Masking the Details of Variable Read and Write Mechanisms

The above two methods describe the computing logic from the perspective of all nodes in a functional system. Although these methods are concise, some application tasks are still suitable for programming from the perspective of a single node or neighborhood, e.g., the neighboring damper opening correction in Step 2 of Figure 3. If the complexity of the calculation description is not considered, the APP may read or write the parameters of the node itself or neighbor nodes from the perspective of a single node.

As shown in Figure 10, when programming in a general-purpose programming language, the read-only local parameters are usually called local input variables or Ar variables. The local parameters that support modification are called local output variables or Aw variables. Reading data from neighbor nodes can also be viewed as the neighbors’ writing data to a local computation. Since the calculation logic of the node itself and neighbor nodes is the same, from the perspective of a single node, it is difficult to determine whether to read or write the neighbor parameters. Therefore, the variables corresponding to the parameters read or written to the neighbor nodes are called interactive variables, namely, X variables. The X variables usually read the values from the Ar or Aw variable interfaces according to the requirements of the algorithm. After the calculation, the results are finally written to the Aw variable interfaces and assigned to the parameter of each neighbor node.

When programming in a general method from a local perspective, it may be necessary to define the three variable interfaces of Ar, Aw, and X to describe operations on the same parameter, which will lead to a sharp increase in the number of variables. SwarmL can effectively solve this problem by combining parameters and different local computational scopes and establishing the following correspondence with Ar, Aw, and X variables:

• If the computational scope of a parameter is AllNeighbors, it means that the data used in the calculation are from neighbor nodes, and the parameter corresponds to the X variable. Similarly, if the computational scope of the parameter is Upstream or Downstream, it means that the calculation is performed on a temporarily generated spanning tree, and the data are from the upstream or downstream neighbors. This parameter corresponds to the X variable as well, e.g., the parameter Temp_D in Figure 10.
• If the computational scope of the parameter is Me, it means that the data used in the calculation come from the node itself, and this parameter corresponds to the Ar or Aw variable. Furthermore, if this parameter does not appear to the left of the equals sign in all programs, it means that the value of this parameter is read in all statements, and this parameter corresponds to the Ar variable, e.g., the parameters Temp_0 and TempSet. Otherwise, this parameter corresponds to the Aw variable, e.g., the parameter TempError.

Based on the local computational scope, this description method masks the complex computation details, e.g., variable reading and writing and the data access mechanism during node interaction at the syntax level but does not lose the corresponding semantics. Users can focus more on the expression of the distributed algorithmic logic.

4.2.4. Integrated Development Tool of SwarmL

To support the design and implementation of FDIBS APPs, this paper implements an integrated SwarmL development environment tool (SwDET) based on Xtext [58], a widely used framework for the development of domain-specific languages. Figure 11 shows the basic architecture of SwDET, which is composed of the editor module and compiler module. In the editor module, the SwarmL syntax file (SW.xtext), including syntax rules and highlighting rules for the keywords, is written with the Xtext tool. The SwarmL program syntax validator file (SwValidator.xtend) is developed to speed up program editing and detect syntax errors early. The SwarmL compiler includes the following three key components:

Source code structured parser: Reads, preprocesses, and structured parses the source program and generates the abstract syntax tree (AST) of the SwarmL program.

Semantic analyzer: Recursively analyzes each node and subtree of the AST, extracts relevant semantic information, and saves it in the nodes of the AST, which can be used to generate the final object code.

Code generator: Traverses the AST and generate the object code by calling the corresponding predefined translation algorithm for different syntax tree nodes. This paper uses the insect intelligent building (I²B) [7] with swarm intelligence and node collaboration features as a typical case of the FDIBS to implement the conversion of the SwarmL source program to the target code of the I²B platform.

Finally, the whole project is built by the Xtext tool, and the SwDET installation package plug-in is automatically generated so that users can install and develop FDIBS APPs. Figure 12 shows the graphical user interface (GUI) of SwDET. The main edit area (part a) is the program edit area, which enables a what-you-see-is-what-you-get (WYSIWYG) design. The project navigation view (part b) is used to switch between the different modules of a project and help users quickly locate the module of interest. The property edit view (part c) can visually display the various language elements and structures of the SwarmL program.

SwDET mainly includes the following three functions:

Basic program editing, testing, storage, and management. SwDET provides an easy-to-understand and intuitive GUI environment for users, with the functions of keyword syntax highlighting, program storage, etc. It also supports a pop-up warning message list when syntax errors occur, as well as code autocompletion.

Automatic object code generation. SwDET supports the automatic generation of the object code that can run on the FDIBS platform, which makes programming and debugging easier for users. As shown in Figure 13, after clicking the compile button on the menu bar, the object code is generated.

Ease of installation, updating, and integration. As it is based on the Xtext tool dedicated to domain-specific language development, SwDET is easy to use and install. Furthermore, SwDET is developed on the Eclipse platform and requires no additional tools or platforms. The entire installation package of SwDET and a sample video for developing an FDIBS APP using SwDET have been uploaded to Github (https://github.com/Resilience2022/SwarmL-development-tool-and-its-operation-video/tree/master (accessed on 24 November 2022).

5. Evaluating SwarmL

SwarmL is evaluated in three different ways. In Section 5.1, the research compares the description ability of SwarmL with that of other development methods for FDIBS APPs by developing a case application. The effectiveness of SwarmL in APP development is evaluated in a real-world experiment in Section 5.2. Section 5.3 verifies the efficiency of SwarmL using a subject-based empirical evaluation experiment.

5.1. Description Ability Verification

This section introduces the development of a typical optimization control APP for a VAV air conditioning system and compares the description ability of SwarmL with those of existing development methods.

5.1.1. Developing a VAV Optimization Control APP Using SwarmL

The source program of the VAV optimization control APP is shown in Figure 14.

In the first line, the domain VAVsystem is defined according to the set of node types. Lines 3–8 defines a series of field-oriented variables, e.g., the expected value of the damper opening change, the rated air volume, and the fan speed. In line 9, the parameter dOpen_ExpectedP is defined, indicating that this parameter is the value set of the variable damperOpen_Expected on all room nodes in the VAV system. In the periodic trigger process defined in line 10, all room nodes calculate the expected value of the damper opening change according to the set value Temperature_svP, the actual value Temperature of the room temperature, and the system function IndoorTempControl every 5 min.

In lines 15–33, a conditional trigger process is defined to correct the damper opening according to the action of the neighbor dampers. When the damper opening change of any node is not equal to zero, the node will be used as the starting node to trigger the network calculation. The Swarm parallel statement in line 19 specifies that all room nodes execute the sub-statements in parallel. The local parameter dOpen_Expecte_0 defined in line 20 represents the value of the variable damperOpen_Expected at the node itself. The starting node assigns dOpen_Expected_0 to the damper opening correction value dOpen_Cor_0 and transmits it to the neighbors. The other nodes multiply the maximum correction value obtained from the upstream neighbors by the adjacent damper change coupling coefficient delta_0 to obtain the local correction value. When the correction value exceeds the threshold, it may cause neighbor correction, and the node transmits the correction value to neighbors to trigger neighbor calculation. Finally, all nodes obtain their own correction values and update the setting value of damper opening according to the local correction value.

In lines 34–49, a periodic triggering process is defined to calculate the total air volume of the rooms and the fan speed. Through special expressions of a single operator, the AHU node obtains the sum of the feedback value of the damper opening, the sum of rated air volume, and the sum of actual air volume in all rooms, as well as the average value of the damper opening. The fan speed is then calculated by substituting these values and the correlation coefficient alpha_0 of the total air volume method into a specific formula.

5.1.2. Developmental Summary

In this section, the following key characteristics of SwarmL in APP development are summarized. Moreover, this section compares SwarmL with the C language, INR model [19], Touch language [22], and graphical programming language [23] used in APP development for FDIBSs in terms of these five characteristic indicators.

C1. Support for endogenous description of parallel computing logic. The proposed field-oriented variable combines spatially distributed physical fields with programming mechanisms to effectively map the global functional requirements of application tasks to the behavior of single nodes, enabling SwarmL to employ serially programming style in accordance with human thinking to implement parallel FDIBS APPs. The graphical language previously proposed by our team contains graph elements that support the unified operation of groups, and thus also enables endogenous parallel programming. However, variables are defined from a local perspective in the C, INR model, and Touch language, so they need to program the parallel computing logic by describing neighbor node interactions and do not support an intuitive description of the parallel computing logic.

C2. Support for dynamic description of the node interaction scope. The proposed computational scope-based communication mechanism enables APPs to dynamically specify the set of interaction nodes at the runtime and decouples the program from specific node addresses. APPs can be transplanted to VAV systems with different numbers of nodes and network topologies, and SwarmL has a good versatility. The tag defined in the INR model and the location variable defined in Touch can decouple the specific node address from the FDIBS APP, while C and the graphical language do not have this characteristic.

C3. Completeness. The computational scope intuitively depicts the node sets with typical functional roles and complex computing properties. Based the field-oriented variable and computational scope, Swarm supports the description of computation from global and local perspectives. However, the tag defined in INR only describes the set of nodes in the neighborhood but lacks the description of the global scope (e.g., starting node). The graphical language does not contain descriptions of the set of upstream and downstream nodes in the neighborhood, and the Touch language lacks descriptions of functional roles such as starting nodes. C language is a general-purpose programming language that can realize various functions of building control tasks. Therefore, SwarmL and C languages have a better completeness.

C4. Simplicity. SwarmL provides a high-level programming abstraction close to the FDIBS and uses simple syntactical notation to describe computation and communication and masks the underlying computing details, allowing users to concisely describe distributed computing logic. Compared to C language, the INR, Touch, and graphical language provide language elements, keywords, and graphic elements that are easier for developers in the building field to understand and operate. For example, INR contains “individual”, “neighborhood”, and “region”, Touch contains “basic unit”, “neighborhood”, and “domain”, and the graphical language contains graphic elements such as process blocks and community blocks. Moreover, the number of grammar terminals and grammar non-terminals [59,60] is often used to measure the complexity of a programming language. Statistically, C language has more grammar terminals and grammar non-terminals than INR, Touch, and SwarmL. Therefore, SwarmL, INR, Touch, and the graphical language have a better simplicity than C language.

C5. The integrated development tools. The compiler of SwarmL perform an automatic conversion from SwarmL to the target instruction program, and SwDET provides an integrated development environment that supports program editing, debugging, and code generation. C, Touch, and the graphical language are programming languages with integrated development tools. However, INR is a programming model, which only supports the description of the control tasks of the fully distributed intelligent building system and does not have corresponding integrated development tools.

Table 2. Comparison between SwarmL and existing development methods.

Development Methods	Basic Concepts	C1	C2	C3	C4	C5
C language	-	⨂	⨂	✔	⨂	✔
INR model [19]	Individual, neighborhood, region, tag	⨂	✔	⨂	✔	⨂
Graphical language [23]	Graphic element, individual, group, operation	✔	⨂	⨂	✔	✔
Touch [22]	Basic unit, neighborhood, domain	⨂	✔	⨂	✔	✔
SwarmL	Field-oriented variable, computational scope	✔	✔	✔	✔	✔

✔: Support. ⨂: Not support.

shows the comparison results. Only SwarmL supports all the characteristics, while the other methods have shortcomings and limitations in some respects. Therefore, SwarmL has a better description ability and completeness.

5.2. Effectiveness Verification

The paper takes a distributed I²B platform [7] with node cooperation as an example to test the effectiveness of SwarmL in APP development for an FDIBS. The VAV optimization control APP based on SwarmL is deployed in the actual HVAC (heating, ventilation, and air conditioning) system of the I²B platform in the Beijing Water Cube Gymnasium. The detailed structure of the system and the division of the space units are shown in Figure 2. This system consists of four areas, in which room #1 contains an AHU and rooms #2, #3, and #4 each contain a VAV box. The smart nodes, CPNs, are installed in room #1 with the AHU and in rooms #2, #3, and #4 and are connected to each other through network cables.

As shown in Figure 15, the developed APP is compiled into the target code through SwDET, which are then downloaded to all CPNs for running. The test time is from 9:00 to 19:00 on 20 June 2022, and the test objects are the room #1 AHU and the three end VAV boxes. During the APP operation, the VAV box controllers and fan controller can obtain the room temperature, air volume, damper opening, and other information in real time and transmit them to the CPNs as the input information for APP calculation. After the experiment, the running data from 9:30 to 19:00 are collected to analyze the running status of the equipment. Among them, the VAV box controllers (VC in Figure 15) collected the temperature, air volume, and damper opening of rooms #2, #3, and #4, and the fan controller (FC in Figure 15) collected the AHU fan speed of room #1.

As the temperature gradually rises in summer, the indoor cooling load increases accordingly. The number of people in the room may vary at different test points, so the cooling load required in the room also varies. To meet the requirements of an indoor load, the damper opening and fan speed are constantly adjusted. As shown in Figure 16, the system starts at 9:00; at this time, the fan speed reaches the maximum, and the damper is fully open. At 11:00, the system works normally, and the fan speed decreases. At 13:00, there is a rest period; the damper in some rooms is closed, and the fan speed is low. The indoor load reaches the maximum at 15:00, so the fan speed is high. After 19:00, the staff are off duty; there are few people in the rooms, so the fan speed is the lowest. Figure 16 shows that the APP comprehensively adjusts the damper openings of the VAV boxes and the fan speed of the AHU according to the indoor and outdoor environmental changes. The system can effectively reduce the fan speed by keeping the damper open more than 80% while ensuring the indoor load demand. Therefore, the running results in the actual I²B platform verify the effectiveness of SwarmL in the FDIBS APP development. However, this experiment did not collect detailed system energy consumption data, which will be our next work.

5.3. Efficiency Verification

This paper evaluates the efficiency of SwarmL in APP development according to the goal question metric (GQM) method [61]. Efficiency means that developers can use SwarmL to develop APPs faster than is possible with other development methods. Therefore, the paper needs to study how programming languages affect the time spent on APP development. To measure the time spent, the following metrics are considered:

• M1: Time spent on designing;
• M2: Time spent on coding;
• M3: Total time spent on the development.

To fully compare the differences in the development efficiency between other current development methods and SwarmL, this paper uses the C language and Touch language [22] as the development examples without SwarmL.

5.3.1. Experimental Method

(1)

Subject

The subjects of this experiment were 15 graduate students majoring in computer science. All subjects had learned object-oriented programming, software engineering, and distributed systems and had at least basic experience in development using C, Java, Visual Studio, and the Eclipse IDE (integrated development environment). They had designed and developed software in an academic setting for at least one year, and most had basic knowledge of FDIBSs. However, none of them had used the development tools to develop FDIBS APPs.

(2)

Experimental tasks

The academic level and programming ability of the 15 subjects selected for this experiment are similar. The subjects were divided into three groups of five people each. To avoid subjects’ gradual familiarity with the experiment affecting the programming time, each group of subjects participated in only one condition of the experiment. Group 1 used the C language and Visual Studio tools, Group 2 used the Touch language and its supporting tools, and Group 3 used SwarmL and SwDET. All three groups of subjects were asked to develop a VAV optimization control APP.

(3)

Variables

The three variables in this experiment are defined as follows:

Control variables: the three groups of subjects developed the same APP and assigned the same requirements.

Independent variables: the programming languages.

Dependent variables: the designing, coding, and total time.

(4)

Process and materials

Before the actual experimental task, the three groups of subjects were given a 3 h session with the following topics: (a) an introduction to different development methods and programming exercises. The usage of SwarmL and SwDET (Section 4) were explained in detail. The Touch language and its supporting tool [22] were introduced. Moreover, the general-purpose C language and Visual Studio tool were briefly reviewed. Then, this paper used a simple application example to show how to program using the above methods. The subjects could practice writing and compiling sample programs on the provided tools. (b) A description of the task. The algorithmic logic of the distributed optimization control task of the VAV system to be developed was explained (Section 3.1).

During the experiment, the subjects were given 240 min to complete the task and were told to try to complete the task quickly while ensuring correctness. The time each subject spent on designing (including understanding the methods) and coding (including debugging) were recorded. After submitting the source code, the APPs developed by the subjects were collected and evaluated.

5.3.2. Results

In this section, the repeated measure analysis of variance (RM-ANOVA) [62] was used to investigate whether there was a significant difference in the time (dependent variable) spent when different programming languages (independent variable) were used to develop an FDIBS APP. The significance level α was 0.05. The hypotheses were as follows:

Null hypothesis (H0).

The mean difference in development time between SwarmL and C language is zero.

Alternative hypothesis (H1).

The mean difference in development time between SwarmL and C language is different from zero.

Null hypothesis (H2).

The mean difference in development time between SwarmL and the Touch language is zero.

Alternative hypothesis (H3).

The mean difference in development time between SwarmL and the Touch language is different from zero.

Table 3. Time spent by the subjects.

Metric	Approach	Mean (min)	S.D. (min)
Designing	C Language	54.00	4.90
	Touch	40.00	4.64
	SwarmL	29.20	3.19
Coding	C Language	130.20	12.20
	Touch	85.80	11.88
	SwarmL	51.40	6.43
Total	C Language	184.20	15.06
	Touch	125.80	11.52
	SwarmL	80.60	9.48

shows the means and standard deviations of the design, coding, and total time spent using different programming methods. SPSS 22.0 (Statistical Product and Service Solutions) [63] was used for the statistical analysis. The experimental data were first imported into SPSS. In this stage, the intra-group variables were designing the time, coding time, and total time, while the inter-group variables were programming languages.

Table 4. Results of multiple comparisons.

Dependent Variable	Parameter	Mean Difference	Std. Error	t	p (Sig.)	95% Confidence Interval
						Lower Bound	Upper Bound
Designing	Intercept	40	2	21	0.000	36	44
	C language	14	3	5	0.000	8	20
	SwarmL	−10	3	−4	0.002	−17	−5
	Touch	0
Coding	Intercept	85	5	18	0.000	76	96
	C language	44	7	7	0.000	30	59
	SwarmL	−34	7	−5	0.000	−49	−20
	Touch	0
Total	Intercept	125	5	23	0.000	114	138
	C language	58	8	8	0.000	42	75
	SwarmL	−45	8	−6	0.000	−62	-28
	Touch	0

shows the results of multiple comparisons of the SPSS output. In terms of the designing, coding, and total time, the significance level p is all less than the predetermined statistical significance level α (0.05), and the differences are statistically significant. This indicates that SwarmL and C and Touch have a significant difference in the development time. Therefore, hypotheses H0 and H2 are rejected and hypotheses H1 and H3 are accepted.

Figure 17 depicts the marginal means of development time for the three groups of programming languages. The figure shows that SwarmL is significantly lower than C and Touch language in terms of the designing, coding, and total time. Therefore, the conclusion of this experiment is that the difference between SwarmL and C language and Touch language in the development time of the FDIBS APP is significant. Compared to C and Touch languages, using SwarmL can effectively reduce the development time.

5.3.3. Threats to Validity

This section discusses the limitations of our study design that may affect the validity of the findings. This paper distinguishes between threats to internal validity and external validity [64].

Internal validity. Before the experiment, the subjects were asked to fill out a questionnaire on their experience with using the C language, the Touch language, Visual Studio, and Eclipse, as well as related knowledge of the distributed control of a building. To eliminate selection bias, the subjects were divided into three groups on the basis of the questionnaires. The abilities of the three groups of subjects to complete the task was similar. The subjects were given enough time to ask questions about the task to make sure they understood it. The research carefully monitored for and prevented plagiarism. No one gave up on this task.

External validity. External validity refers to the generalizability of the conclusion. This paper conducted experiments based on a VAV optimization control task. This task is a typical scenario in distributed building control, and the computing logic it involves, e.g., local computing, neighbor interaction, and global summation includes almost all the functions of SwarmL. The experimental results have general implications for this kind of application. The Eclipse tool and its Xtext plug-in were used in this experiment because they are widely used for developing domain-specific languages. However, the background of our experimental subjects was limited. This experiment selected a group of experienced graduate students as the experimental subjects. However, SwarmL is designed not only for students but also for the software engineers of the building automation system. In the future, we plan to conduct more experiments with subjects from the industry as the main body to study the efficiency of SwarmL.

5.3.4. Discussion

The experimental results show that the subjects using the C language spent the most time on the task, which is mainly because the C language lacks support for coordination between nodes, so much of the distributed logic needed to be hand coded. Moreover, the subjects using C had difficulty with event-driven programming models. They could only program in an imperative fashion and had to try to specify periodic events with for loops. Compared to the C language, the time spent using the Touch language was reduced. A very important factor is that the Touch language includes programming abstractions for domain concepts, e.g., nodes and functional systems, as well as some advanced operators, which have a higher abstraction level than the C language. The subjects could briefly describe neighborhood node communications in a declarative manner. However, the time spent using the Touch language differed significantly from the time spent using SwarmL. This is due to the lack of completeness of Touch; the subjects could only describe the global computing logic from a local perspective, and it is difficult to describe network computing with upstream and downstream relationships. In contrast, the spatial semantics of field-oriented variables and the dynamic computational scope of SwarmL greatly reduced the programming difficulty. The former supported the subjects in describing the distributed parallel computing logic from a global perspective, while the latter allowed simple programming for networks with various topological relationships. The evaluation results show that SwarmL provides a better framework to implement the control strategy of the FDIBS.

6. Conclusions

The fully distributed intelligent building system is a self-organizing, flexible, plug-and-play open platform capable of handling the complexities of building control and management. To facilitate the development of the fully distributed intelligent building system applications, this paper proposes a programming language called SwarmL and its development tool. The language model, overall framework, and abstract syntax of SwarmL are established that concisely describe the static building physical objects and parallelized execution mechanisms of the fully distributed intelligent building system’s control tasks. For the complexity of programming caused by the parallel computing mode, a field-oriented variable that supports describing the logic of the parallel algorithm endogenously in accordance with human serial thinking is proposed, which can reduce the programming difficulty. For the dynamic nature of network topology and complex interaction logic, a communication mechanism based on computational scope is proposed that can separate computational logic and interaction logic, adapt to the dynamic network topology, and support the generalized development of the fully distributed intelligent building system applications. The key implementation mechanisms of SwarmL are explained, including the implementation of global synchronous diffusion and global calculation tasks, and the masking of complex variable reading and writing mechanisms and underlying computational details. Additionally, this paper implements an integrated development tool for SwarmL that provides the user-friendly graphical interface with support for program editing and code generation. The paper evaluates SwarmL with a sample application and a subject-based experiment. The results show that SwarmL has a better description ability than existing development methods and can significantly reduce the development time of the fully distributed intelligent building system applications. The application developed by SwarmL is successfully used in the optimization control of the variable air volume system of the fully distributed intelligent building system. SwarmL also supports the closed-loop control of lights and curtains, the group control of chiller units, sensor fault diagnosis, and other building services to save energy, ensure a better maintenance, improve the human comfort, and reduce costs. In fact, many students in our labs and partner institutions are using SwarmL. In the future, we plan to extend the language elements and add advanced features to support more complex tasks, allowing us to apply SwarmL to more distributed collaborative platforms with swarm intelligence features.