Abstract
Insect intelligent building (I2B) is a novel decentralized, flat-structured intelligent building platform with excellent flexibility and scalability. I2B allows users to develop applications that include control strategies for efficiently managing and controlling buildings. However, developing I2B APPs (applications) is considered a challenging and complex task due to the complex structural features and parallel computing models of the I2B platform. Existing studies have been shown to encounter difficulty in supporting a high degree of abstraction and in allowing users to define control scenarios in a concise and comprehensible way. This paper aims to facilitate the development of such applications and to reduce the programming difficulty. We propose Touch, a textual domain-specific language (DSL) that provides a high-level abstraction of I2B APPs. Specifically, we first establish the conceptual programming architecture of the I2B APP, making the application more intuitive by abstracting different levels of physical entities in I2B. Then, we present special language elements to effectively support the parallel computing model of the I2B platform and provide a formal definition of the concrete Touch syntax. We also implement supporting tools for Touch, including a development environment as well as target code generation. Finally, we present experimental results to demonstrate the effectiveness and efficiency of Touch.
1. Introduction
Intelligent building (IB) and building automation (BA) systems play an important role in most complex modern buildings [1]. The current building control system is centralized, and configuring it during the deployment process requires considerable manpower. However, as the complexity of building system structures increases, it gradually becomes difficult to upgrade and reconstruct, implement cross-system functions, and apply software customizations to the existing centralized control system [2, 3].
To solve the above problems, a novel decentralized, flat-structured intelligent building control system called insect intelligent building (I2B) [4] has been proposed that regards the entire building as a network with a parallel computing model composed of a series of computing process nodes (CPNs) [5]. The I2B system changes the design pattern of the centralized system architecture of traditional intelligent buildings and has the following characteristics: efficient sharing of underlying information, self-identification, self-organization, self-coordination, easy operation, easy transformation, and easy expansion [6]. Based on a standardized network platform and a decentralized parallel computing model, the I2B system allows users to develop applications (APPs) that include building control strategies and download them to the CPN platform to execute and implement various control management tasks, for example, chiller plant control [7] or sensor fault diagnosis [8]. This approach decouples the application software from the building and achieves building application software universality. However, developing an I2B APP is quite challenging: (i) distributed system architecture requires applications to have good portability and scalability; (ii) data parallelism increases the complexity of user-designed programs; and (iii) as users’ personalized needs change and grow, a concise, friendly, and intuitive programming language should be designed that can be used to develop APPs efficiently.
General application development methods based on general-purpose programming languages (GPLs) such as C language and Python do not consider the task of domain-oriented incremental development [9], and the resulting programs are often highly complex, with poor portability and scalability; thus, they cannot support the development and maintenance of I2B applications in a flexible way. Using a domain-specific language (DSL) [10, 11] is an alternative approach to I2B APP development. A DSL provides a development tool tailored toward a particular application domain at a higher level. In some specific domains, DSLs can reduce the difficulty of programming and improve the productivity of development [12–20]. For example, DSLs applied to parallel computing, such as Spar [21], Smartlog [22], and ParDSL [23], effectively support the paradigm of parallel programming but the developer needs to specify the exact communication address during the programming process, which results in poor program portability and robustness. Although some Internet of Things (IoT) programming methods [24–26] and multiagent programming languages [27, 28] support network-parallel programming and addressless communication, these languages do not consider the domain characteristics of I2B, causing the complex interactions among nodes to be overfocused and making programming difficult. In our previous work [29], a programming model called INR (i.e., Individual, Neighborhood, and Region) is established for I2B APP development and to motivate programming language design, which abstracted and decomposed the actual application tasks of I2B into software entities in application software. The INR programming model eliminates dependencies between the application program and the CPN communication address. Its tag-based programming and clustering operation characteristics make the APP universal and parallel. Although INR is quite descriptive, the time-varying characteristics of state parameters in buildings are not considered, which limits INR’s applicability to wider application scenarios. In addition, the mailbox method used for information exchange between CPNs makes the APP development process overemphasize sending and receiving displayed messages, resulting in a more redundant program. Furthermore, INR is relatively complicated, which makes the developed programs less intuitive. More critically, the INR programming model only provides the corresponding programming abstraction and programming mechanism and does not provide a way to display language elements and syntax; therefore, it cannot be used directly for I2B APP development.
To meet these challenges, this paper provides substantial improvements over our previous study [29] and presents Touch, a DSL for I2B APP development, which can adapt to the unique features of I2B such as decentralized, distributed, and parallel and reduce the difficulty of I2B APP development. Touch comprehensively considers the time-varying characteristics of state parameters in the standard information model (SIM), simplifies the information exchange method between CPNs, and can be directly applied to I2B APP development. An APP developed with Touch has good portability and extensibility, and the developed programs are more concise and intuitive. The main contributions of this paper are as follows:(i)We propose a high-level programming conceptual architecture for Touch that describes abstract entities in I2B APPs. Touch mainly includes three key programming concepts: Basic Unit, Neighborhood, and Domain.(ii)We design a series of Touch language elements rooted in building domain requirements, CPN computing platform, and controlling program, including Special Data Type, Time Offset, Location, and Event, to facilitate the development of such applications.(iii)We implement a tool for Touch that supports I2B APP development that provides a friendly GUI for editing and testing applications in the understandable Touch language. It also automatically converts Touch-based applications into target code that can be executed on a CPN.(iv)Experiments are conducted to evaluate the effectiveness and efficiency of Touch. The proposed Touch is applied to the personnel evacuation application to prove its effectiveness. Moreover, a subject-based empirical evaluation is also conducted to evaluate the efficiency of the proposed Touch. The results show that Touch can considerably facilitate I2B APP development.
The remainder of this paper is organized as follows. In Section 2, we discuss the related work. In Section 3, we provide an introduction to I2B system architecture, a description of a typical case involving building personnel evacuation, and a domain analysis for I2B. The overall framework for Touch language development and the programming conceptual architecture of Touch is proposed in Sections 4 and 5, respectively, and the key language elements and concrete syntax of Touch are presented in Section 6. Then, we introduce the implementation of the tools for Touch in Section 7 and evaluate Touch using the personnel evacuation example in Section 8. Section 9 provides a summary and concludes the paper.
2. Related Work
Since the emergence of I2B, considerable research efforts have been devoted to the subject of I2B application tasks, and several distributed optimization methods have been proposed. Dai et al. [30] introduced a new decentralized method to solve the optimal distribution problem in heating, ventilation, and air conditioning (HVAC) systems. Yu et al. [31] presented a distributed control structure for parallel pumps in which the main controller is replaced by several independent distributed controllers that work together to handle global tasks. Zhao et al. [32] investigated a distributed optimal control method for peer-to-peer control of parallel pumps in HVAC systems. Wang et al. [33] proposed a decentralized method for optimal load distribution in an isolated power system that distributes economic load dispatching to each intelligent distributed generator without the need to monitor the host. These methods can improve the efficiency of building control. However, they all solve a specific task. Due to the diversity and difference of I2B application tasks, it is difficult for works such as these to provide a general development method.
In recent years, DSL-based application development methods for distributed, parallel systems have been extensively investigated. Membarth et al. [34] proposed a heterogeneous image processing acceleration (HIPAcc) framework, which included a DSL for image processing that captures domain-specific algorithm characteristics. They also proposed a source-to-source compiler for generating efficient parallel implementations. Janjic et al. [35] presented a refactored pattern language (RPL) used to represent the parallel structure of an application and capture the properties of its additional features. Kindlmann et al. [36] designed Diderot, a parallel DSL that allows mathematical concepts to be expressed directly in the code and supports parallel execution on modern multicore processors and GPUs. Sredojević et al. [28] introduced an extension of the agent-oriented DSL called ALAS to support distributed nonaxiomatic reasoning for developing specific types of intelligent agents. These programming languages effectively describe their intended specific domain applications, but they require users to be familiar with the underlying structure of the system and directly specify the communication address, which is difficult to apply in I2B since it requires addressless communication.
DSL in civil engineering has been the focus of many efforts. Park et al. [37, 38] introduced a DSL called KBimCode, which translates the building permit-related regulations in the Korean Building Act into computable rules, reflecting the obvious characteristics of the Korean Building Act sentences. Alves et al. [39] designed the Building Information Modeling Sensor Language (BIMSL) to help create services and application software that combines sensor data with BIM models. Lee et al. [40] presented the BERA (Building Environment Rules and Analysis) language for constructing building information models (BIM) in an intuitive way, improving the efficiency of defining, analyzing, and checking BIM rules. Grabska et al. [41] proposed two new visual languages for creating multistorey building design schemes, which support designers to design 2D floor layouts and 3D building structures, respectively. However, these methods are not suitable for the distributed and parallel I2B network architecture, and the domain characteristics are quite different from I2B, so it is difficult to apply them to I2B APP development.
Many studies have also been conducted regarding the Internet of Things (IoT) programming. Nguyen et al. [42] proposed a framework for IoT application development that separates the programming language and its execution model from the underlying operating system and hardware. Riliskis et al. [43] presented Ravel, a three-tier architecture-based IoT application programming framework that allows developers to explicitly write a three-tier architecture using models, views, and controllers like building web applications. Verriet et al. [44] introduced a virtual prototype method for IoT applications and similar distributed control applications that has clear application specifications and can detect and correct behavior errors and performance issues during the early stage of development. Salman and Al-Yasiri [45] presented the SenNet language for developing wireless sensor network applications that use macroprogramming concepts to abstract the complex tasks and operations required by developers. These programming languages support network-parallel programming and addressless communication but overfocus on the complex interactions between nodes and do not consider the domain characteristics of I2B, making programming difficult.
In our previous work [29], a programming model called INR was proposed to effectively promote the development of I2B APPs, which established programming abstractions such as “Individual,” “Neighborhood,” and “Region” and the “Tag-Based Programming and Clustering Operation” programming mechanism. Although the INR is very descriptive for I2B application tasks, it does not consider the time-varying characteristics of the state parameters in the SIM, its proposed CPN interaction mode of “mailbox” is relatively complicated, and more importantly, it does not provide the language elements, syntax, and development tools of a programming language, so it cannot be directly used in the development of I2B APP.
3. Background and Domain Analysis
An overview of I2B is provided to facilitate an understanding of Touch. The organization structure and operation mechanism of I2B are briefly introduced. Then, a motivating example is given to demonstrate the characteristics of I2B APPs. Furthermore, we conduct a domain analysis of I2B to provide information for Touch language design.
3.1. I2B System Architecture
I2B regards the entire building as a decentralized, flat-structured network of building space units and large electromechanical equipment [4]. Each building space unit and electromechanical equipment is controlled by a smart node, called a computing process node (CPN) [5], which is embedded with a microprocessor that has comprehensive information processing and calculating capabilities. In addition, each CPN is equipped with a communication port to support communication with the local drive controller unit (DCU). The DCU manages the local sensors and equipment controllers that can monitor all the information of the building space unit and large electromechanical equipment, for example, equipment operating information, physical parameters, operating feedback, set values, etc. Due to the communication relationship between the CPN and the DCU, this information can be mapped into a SIM in the CPN. The predefined, same-structured SIM enables CPN to be standardized for production, copied, and manufactured in large numbers to function as “plug-and-play” nodes in buildings. Moreover, each CPN has six data ports and can be connected to up to six CPNs for data interaction without addressing. All the CPNs are connected to form a decentralized, flat-structured parallel computing network based on the spatial distribution of the building or the operation mechanism of the equipment. The various system calculation and control tasks in the building are completed through the data interaction of adjacent CPNs [6, 7].
3.2. Motivating Example
We analyze a case of a personnel evacuation application in I2B and use it as an example to show how to solve I2B application tasks and to present the challenges faced by developing I2B APPs.
When a fire occurs in a building, people need to be evacuated immediately. In I2B, based on the building information system, real-time information can be obtained regarding the distribution of the number of people in the building. According to this real-time information, the safest and quickest evacuation route can be dynamically planned, and the crowds can be guided to evacuate reasonably by the displays placed in each room and the main traffic avenues. The escape model introduced below uses a distributed recursive method to select the shortest path. During the evacuation process, only the CPNs mounted on the space units, such as rooms and corridors, participate in this calculation. According to the building topology network, these CPNs are automatically connected to the fire escape personnel evacuation function subnet, as shown in Figure 1.
When a fire occurs in any area, the corresponding CPN in that area first sends an alarm signal to notify all areas to enter the fire protection mode through diffusion transmission and then triggers this application. Assuming that the escape direction for a current space points to space j, the escape time is the sum of the crowd’s moving time from space i to space j, the transit time through space j, and the escape time of space j [46], that is:where the moving time is related to the average distance from the space i to the entrance and exit of space j, the fire severity in the space, and the density of the personnel in space i and the passing time is related to the density of the personnel in space i, the density of the personnel in space j, and the passage opening size in space j. The escape time changes in real time as the crowd flows, the fire develops, and the crowd crowding degree changes.
When multiple adjacent spaces exist in space i, it is necessary to separately calculate the escape time for each adjacent space as the escape direction and adopt the space with the smallest escape time as the best escape direction to define the escape path. For example, space i has two neighbors j and k, and the escape time is the minimum of and . The calculation process uses a recursive algorithm continuously. The CPN in each space unit continuously exchanges information with its neighboring CPNs to continuously establish a path from the security exit to the internal space. In the end, all the rooms will find the fastest escape path. The specific calculation steps are shown in Figure 2.
In this scenario, several difficulties occur when developing I2B APPs:(i)How to concisely describe the application tasks involved in personnel evacuation(ii)How to set constraints to allow CPNs that meet the conditions to participate in the calculation(iii)How to describe the interaction mechanism of CPN(iv)How to directly and quickly call the data in SIM during programming(v)How to reuse the personnel evacuation application in buildings with different structures
3.3. Domain Analysis
Domain analysis is concerned with the analysis of the basic properties and requirements of the problem domain [47]. I2B integrates human and machine, information and physics, and hardware and software and is a comprehensive and cross-cutting building intelligent platform. We divide the analysis of the I2B domain characteristics into three aspects: human, buildings, and platform, as shown in Table 1.
Based on the analysis of domain characteristics of I2B, the core requirements of the programming language used for I2B APP development are summarized in Figure 3.
3.3.1. Simple and Friendly (R1)
Due to the weak programming ability of most users and the difficulty in understanding and mastering the control logic of I2B application tasks, a simple, friendly, and easy-to-use programming language with a high level of abstraction is needed, and complex details need to be encapsulated and hidden to reduce the burden of users. Furthermore, the programming language should have good integrability with existing development tools (e.g., Eclipse) to lower the user’s threshold.
3.3.2. Focus on Building Element Characteristics (R2)
The programming language should be oriented to building element characteristics and support an explicit description of electromechanical equipment information (operation state and operation mechanism), spatial unit information (environment state), the topology of the equipment pipe network, and spatial distribution so that developers can quickly describe building elements and easily maintain I2B applications.
3.3.3. Focus on I2B Platform Characteristics (R3)
The programming language should be able to effectively describe I2B platform characteristics, specific domain concepts (e.g., CPN, SIM, and decentralized CPN network), and distributed and parallel computing processes (e.g., adjacent CPN interaction and trigger mechanism) and improve the accuracy and efficiency of APP development.
4. Overall Framework for Touch Language Development
The Touch language development solution proposed in this paper follows the consistent DSL development method proposed in the literature. The iterative process proposed by Mernik et al. [10] includes four phases, namely, (i) decision (ii) analysis, (iii) design, and (iv) implementation. These phases constitute the formal definition of the DSL development process [47], as shown in Figure 4. In this section, each development phase of Touch is introduced in detail, and the DSL patterns used in each phase are also discussed.
4.1. Decision Phase
The goal of the decision phase is to determine the requirements for Touch language in the I2B domain and to demonstrate that the investment in creating the Touch language can be compensated in the subsequent development and maintenance of the I2B APP. The Touch language is designed to enable users with little I2B domain knowledge and programming expertise and even end-users with I2B domain knowledge but virtually no programming expertise to develop I2B APPs. To make a decision, stakeholders (including domain experts and language engineers) need to discuss the requirements of the I2B domain by the DSL development patterns.
For the decision phase, the AVOPT (analysis, verification, optimization, parallelization, and transformation) [10] pattern is used in this paper to help the decision-making process. Analysis, verification, optimization, parallelization, and application transformation that are specific to the I2B domain and written in GPL (e.g., C language) are usually not feasible because the source code patterns involved are too complex or not well defined, so using Touch language makes these operations possible.
4.2. Analysis Phase
At this phase, the domain characteristics of I2B are analyzed. Domain experts help language engineers define I2B domain concepts, feature descriptions, and functions and establish the core requirements of programming languages used for I2B APP development.
For the analysis phase, an informal (the domain is analyzed in an informal way) [10] pattern is used. This is because this paper does not use formal domain analysis methods such as DARE (Domain Analysis and Reuse Environment) [48] and FAST (Family Oriented Abstractions, Specification, and Translation) [49] in this phase. Moreover, after the domain analysis, several terminologies specific to the I2B domain are given instead of a formal domain model. Furthermore, I2B domain knowledge in the process of analysis is derived from existing technical documents, knowledge provided by domain experts, and customer surveys, rather than existing GPL codes.
4.3. Design Phase
At this phase, the programming conceptual architecture of the Touch language is proposed, including three basic programming concepts: Basic Unit, Neighborhood, and Domain. The metamodels of the Touch language are also established using different abstract objects and UML notations of relations. Furthermore, we provide the key language elements and formal concrete syntax of Touch.
For the design phase, the DSL design method can be described along two orthogonal dimensions: (i) the relationship between DSL and existing languages and (ii) the formal nature of the design description. For the first dimension, the language exploitation pattern (DSL uses (part of) existing GPL or DSL) [10] is used. Because the Touch language is built based on existing C language, Touch piggybacks special language elements specific to the I2B domain to part of the C language (e.g., common data types, if and while statements, etc.). For the second dimension, the formal [10] pattern is partially used because this paper specifies the syntax of Touch using formal symbols (e.g., regular expressions and grammars for syntax specification). However, this paper does not use attribute syntax, rewrite rules, and an abstract state machine to give the semantic specification of the Touch language, which will be our next work.
4.4. Implementation Phase
At this phase, Touch language support tools (i.e., I2B APP development tools) are implemented, including the editor and code generator. This tool has the functions of keyword syntax highlighting, syntax error-checking, the automatic recommendation of standard information model parameters, and code generation and can effectively support Touch language program editing and the conversion of Touch to CPN-executable target code, improving the efficiency of I2B APP development.
For the implementation phase, the compiler/application generator [10] pattern is used. Because this paper does not implement the Touch language through preprocessing, embedding, extending existing compilers, etc., but uses the Xtext tool (a widely used framework for DSL development) [50] to fully develop the editor and code generator of the Touch language, it can directly convert Touch programs into CPN-executable target code.
5. Programming Conceptual Architecture of Touch
Motivated by the example of personnel evacuation and the domain analysis of I2B, the conceptual programming architecture of Touch is first designed. Our previous work [29] proposed INR, a programming model for I2B APP development. INR contains three submodels, namely, Individual, Neighborhood, and Region, which are defined and implemented for describing different task requirements. However, after using the proposed INR programming model for two years, we find it still has the following limitations: Limitation 1: the Individual submodel ignores the characteristics of some parameters in CPN SIM that change with time. Therefore, the INR programming model can operate only on the SIM parameters that exist at the current moment, which limits its ability to describe the I2B application tasks. Limitation 2: in the Neighborhood submodel, the “mailbox” type of adjacent CPN interaction method is too concerned with the complex message sending and receiving mechanism at the base of the node architecture, resulting in redundant, overly complex programs. Limitation 3: in the Region submodel, the “originator” concept violates the principle that all CPNs in I2B are equal. The explicit definition of “originator” results in poor application portability. Since the same application will be downloaded and run on all the CPN nodes, the same variables are defined in each CPN; thus, the concept of “regional variables” is redundant. Limitation 4: the INR programming model is generally more complex and pays too much attention to specific computer calculation methods, resulting in low code readability and raising the learning cost for I2B users.
In addition to the deficiencies in INR, this paper analyzes the physical entities that comprise the I2B platform, improves the level of programming abstraction and the programming mechanism over that of the INR programming model, and provides Touch programs that are more readable and better suited to users. We propose a new programming conceptual architecture for I2B APPs that includes three basic concepts to support I2B APP development, i.e., the Basic Unit, Neighborhood, and Domain, as shown in Figure 5.
To improve readability and intuitiveness, we also establish metamodels for each of the three basic programming concepts using different abstract objects and UML notations of relations.
5.1. Basic Unit Programming Concept
5.1.1. Requirement Analysis
Each unit is managed by a CPN, which forms the “base” of the entire I2B system. The SIM preset in a CPN contains various state parameters and physical property parameters of the unit. Due to functional differences, many types of units exist in I2B, including building space, chillers, cooling towers, etc. An application must be executed in a matching type of unit. For example, the personnel evacuation application task requires only CPNs corresponding to building space units to participate in the calculation. A building space unit can control and solve local tasks through its built-in control logic. For example, in the personnel evacuation case, the CPNs can be used to solve the problem of how fast people are moving locally by using known parameters such as the local personnel density and the fire severity. This paper defines the minimum component unit for a CPN of I2B, which is called a basic unit. The metamodel of the basic unit programming concept is shown in Figure 6, which uses programming abstractions, status attributes, functional attributes, and physical entities to describe different abstract objects and UML relations between them. Programming abstraction is used to describe the basic elements of control objects in application tasks. Status attributes and functional attributes are used to describe the structure of required data and functional effects of programming abstractions.
Definition 1. Basic Unit. The basic unit is the smallest unit participating in I2B network calculations. Basic units are abstractions of the basic building units in the physical world. A basic unit can be defined as a quad:where(i) represents a unique name that identifies the basic unit in the APP and must be defined manually.(ii) represents the type attribute of each basic unit, reflecting the functional characteristics of that particular basic unit.(iii)represents a collection of basic unit data members, corresponding to the SIM contained in the CPN. , where represents the set of state parameters of the basic unit, including various operating state parameters such as the temperature and the density of people in the building space unit and is a function of time, recorded in the form of time-series variables, . represents a set of physical attribute parameters for a basic unit, such as the area of a building space unit and the power of a chiller, where .(iv)represents an autonomous function of the basic unit, and it is the entry point for APP execution inside the basic unit. is unique in an APP and contains a special type of dynamic behavior—events E, which corresponds each specific application task. , where represents a set of nontriggering events and represents a set of triggering events. For example, the personnel evacuation case is a triggered event. When a building space unit detects a fire, the application task is triggered. Events must be created in autonomous functions, and a parallel relationship exists between events.The basic unit programming concept accurately describes the time-varying characteristics of the information in the SIM using and eliminates the “slave devices” concept bound to the tags and the redundant “static functions” concept of the individual programming model in INR [29], which can better meet the programming requirements of local tasks.
5.2. Neighborhood Programming Concept
5.2.1. Requirement Analysis
The basic unit programming concept can be used to describe local control tasks. However, global control of the I2B building system is achieved through data interactions between the basic units. Each CPN in I2B supports connections with up to 6 neighboring CPNs through data lines; thus, a basic unit communicates only with other basic units that are physically or logically adjacent without requiring addressing. The basic units that can communicate directly in this way are called neighbors. Through data interactions between neighboring basic units, a network parallel computing mode is formed. Based on this, we define a neighbor set of the basic unit in I2B, called a neighborhood. The metamodel of the neighborhood programming concept is shown in Figure 7, where the identity attribute is used to describe the identifying features of programming abstractions. Moreover, the connotation abstraction means that it is not used in the description process, but the actual affected object.
Definition 2. Neighborhood. The neighborhood is a collection of nodes that are adjacent to the basic units participating in I2B network tasks. A neighborhood can be defined as a quad:where(i) represents the abstraction of the basic unit in the neighborhood relationship.(ii) indicate the set of neighboring basic units that form a neighborhood relationship within the ontology.(iii) represents the type of functional network to which the basic unit in the neighborhood belongs. For example, the neighborhood of a building space unit X in I2B may include a water pump basic unit Y and a building space basic unit Z, where Y belongs to the water supply function network and X and Z belong to the personnel evacuation function network. In the personnel evacuation case, X interacts only with Z, so when data must be exchanged with a neighbor, the functional network type to which the neighbor belongs must be specified.(iv) represents a set of neighborhood operations, including various complex operations performed by a basic unit itself on the neighbor nodes, such as maximizing or summing certain data in the neighbor.The proposed neighborhood programming concept in this paper uses a “direct” neighbor CPN interaction method, that is, the node can directly fetch the neighbor node’s data without the need for displayed sending or receiving operations. Compared with the “mailbox” interaction method in INR [29], this method simplifies the message sending and receiving mechanism, shields the data dependency and sequence dependency of variables, and reduces the size of the program. In addition, we propose the concept of “neighborhood type” to replace the “tag” concept in INR that requires a lot of cumbersome configuration due to its flexibility to identify the functional subnet type to which the CPN’s neighbors belong and then select the corresponding neighbors for calculation.
5.3. Domain Programming Concept
5.3.1. Requirement Analysis
Based on the I2B system network, various functional subnetworks can be defined based on the specific type of attributes and physical parameter information of each basic unit coupled with specific service function requirements. These subnetworks directly correspond to various types of physical networks and electromechanical systems in the physical space of the building, such as air conditioning system networks and personnel evacuation networks. Because the programming concept of a neighborhood is locally oriented, communication and control are limited to the basic unit and its neighboring nodes; thus, the network computing tasks within the functional subnetwork range cannot be described globally. This paper terms such a functional subnet of I2B as a domain. The metamodel of the domain programming concept is shown in Figure 8.
Definition 3. Domain. A domain is a virtual network with a certain function formed by several basic units arranged in a certain topology. The nodes constituting a domain can include different types of basic units. A domain can be defined as a triple:where(i) represents the type of domain, which corresponds to the type of functional subnets. describes several types of basic units that the domain must contain, and the definition of is clearly stated in the APP.(ii) represents the name identifier of the domain, defined by the APP developer according to ; one can instantiate multiple . After the types and locations of all the CPNs in the I2B network have been determined, various types of domains are automatically generated such that the of each domain is unique. In other words, a corresponds to a specific domain in I2B and is also unique within the same APP.(iii) represents the set of specific basic units contained in the domain. After a domain is determined, the configuration personnel of the CPN network can establish the mapping relationship between a domain name and the basic unit members in that domain. , where represents the basic unit name and represents the basic unit number. When a basic unit in the domain reaches the trigger condition for an application task, it becomes the originator of that application task and triggers the application task to be executed on all basic units in the domain. Then, according to the principle of depth-first traversal, each basic unit in the domain is numbered from the origination point: the originator number is 0, and the remaining basic unit numbers are assigned numbers incrementally. There is a one-to-one mapping relationship between and .The domain programming concept uses the “domain type” to describe different types of functional subnets and to show the constraints that participate in network computing, which is more intuitive than the “region constraints” concept of INR [29]. In addition, we propose representing the mapping relationship between the basic unit name and number to realize the precise positioning of a node in the domain. Furthermore, the concept of “originator” that is not conducive to application portability and redundant “regional variables” concept of INR are eliminated.
6. Key Language Elements of Touch
Based on the programming conceptual architecture in Section 5, we provide the key language elements of Touch. An excerpt of the metamodel of Touch language elements is established, as shown in Figure 9. According to the service object, the key language elements are divided into three parts: one part serves the building domain (basic unit, neighborhood, and domain), one part is dedicated to CPN computing, and one is for controlling program. Furthermore, we use abstract objects and UML notation to describe the relationships between the key language elements. Each programming language element is formally defined.
6.1. Language Elements for the Building Domain
This paper proposes language elements for the building domain that can effectively describe the physical entities of I2B and enhance the descriptive nature of Touch for I2B application tasks. These language elements represent building domain elements in the form of syntax symbols that can be used directly in programming; they include both special data types and domain-specific variables, as shown in Table 2.
6.1.1. Special Data Type
When developing the I2B APP, it is usually necessary to effectively describe the building elements in the I2B, such as the attribute characteristics of the basic unit and the CPN functional network. However, due to the lack of language elements that directly reflect the characteristics of building elements, it is difficult for humans (e.g., building engineers and domain experts) in the I2B domain to develop and maintain applications in a concise manner. To conveniently describe the type attributes of building elements, we propose special data types, which correspond to some of the programming concepts in Section 5, including the class type, domain type, and neighborhood type.
(1) Class Type. Because the types of basic units are quite diverse, such as the building spaces, boilers, and chillers, the functions of different types of basic units are also different. To identify the type of the basic unit, we propose the class type concept, which is mapped from the described in Section 5.1 and shown in Table 2. The kind of class type is determined and corresponds to several basic units [6] specified in the I2B system.
(2) Domain Type. Each type of functional subnet performs the same functions and contains the same basic unit types, but it instantiates multiple functional subnets of the same type according to the different spatial distributions and pipe network connections. When participating in an I2B application task, the CPN must determine whether it belongs to the functional subnet type corresponding to the application task. Therefore, the type of functional subnet must be reflected in the programming language. We propose the domain type concept, which is mapped from in Section 5.3 and includes such domain types as “domainTypeEscape,” “domainTypeAHU,” and “domainTypePump”.
(3) Neighborhood Type. The neighboring nodes that are physically connected to the CPN with data lines may belong to different domains. To facilitate the unified operation of neighbor nodes belonging to the same domain, we propose a neighborhood type. The neighborhood type is mapped from the in Section 5.2 and is used to describe the domain type to which the neighbor belongs.
6.1.2. Domain-Specific Variable
There is an instantiation relationship between a type and a real object. To facilitate direct manipulation of objects, this paper proposes domain-specific variables that are divided into domain name variables and neighborhood name variables.
(1) Domain Name Variable. A domain type in I2B may correspond to multiple domains. For example, there may be several domains with a type of “domainTypeEscape” in a building. While these domains have the same domain type, the specific CPN nodes they contain are different. Therefore, this paper proposes the domain name variables, which are mapped from the in Section 5.3 and are variables instantiated from the domain type to characterize the domain name. Assigning different values to the domain name variable of the domain type creates different domain type instances. To distinguish domain name variables from other variables, Touch specifies that domain name variables must begin with “D_.” In the example of the personnel evacuation application shown below, a domain whose domain type is an escape domain is defined with the domain name D_Floor1, signifying that the domain is located on the first floor. domainTypeEscape D_Floor1;
(2) Neighborhood Name Variable. The physically connected neighbors of a basic unit may belong to different domains, and basic units that participate in network calculations interact with their neighboring nodes in the same domain; therefore, the domains of the neighboring nodes must be identified. The neighborhood name variable is a variable obtained by instantiating a neighborhood type and is used to characterize the domain of the neighbors involved in the calculation. The neighborhood name variables must begin with “NB_” in Touch. The following example of the personnel evacuation application defines a neighborhood whose type is an escape domain, and the neighborhood name is NB_Floor1. domainTypeNB NB_Floor1;
6.2. Language Elements for CPN Computing
I2B application tasks are accomplished through data interactions between neighboring CPNs. A CPN must continuously read data from its neighboring nodes, perform operations using the data from those nodes, and perform subsequent operations based on the operational results. However, due to differences in the number of neighbors during an interaction, it is difficult for an application design to eliminate dependence on the node number or the communication address, which reduces portability and complicates the underlying communication mechanism of the CPN, making it difficult to describe interaction modes concisely. To this end, this paper proposes language elements that represent CPN computing, including those for single variables, time offsets, locations, special statements, and special operators, as shown in Table 3.
6.2.1. Single Variable
I2B effectively integrates the physical information in the building with the CPN computing platform, making part of the information have time attributes, which is very different from ordinary variables. To effectively support the CPN calculation and processing process, we propose a single variable, which is the basic object of I2B APP calculation processing and includes permanent variables and calculation variables.
(1) Permanent Variable. In the process of CPN interactive calculation, the physical information parameters in the building, such as room temperature and the power consumption of the chiller, are calculated to achieve control of the building. Moreover, the types of physical information parameters in the building are very complicated and can reach thousands. In addition, these parameters involve cumbersome parameter data types, byte lengths, and other attributes, so the workload of variable definition for these parameters in I2B applications is massive. The SIM in I2B has classified all information parameters, specifying that the types of information parameters contained in the same type of basic unit are the same. Since SIM parameters are necessary to perform calculations in the application and to reduce the difficulty of using those parameters, from the perspective of APP development, we propose a permanent variable, which corresponds to the values in Section 5.1 and is a variable used to characterize state and physical attribute parameters in the SIM.
During I2B APP development, when the programmer enters a class type, the system automatically recommends a parameter list corresponding to the basic unit of the class type. The user selects the appropriate parameter name from the recommended list to define the corresponding permanent variable. This implements read-write access to various parameters in the SIM, saves complicated system configuration and information definitions, and achieves a connection between the application software and building entities. Touch specifies that permanent variables must begin with “P_.” In the following example of the personnel evacuation application, a permanent variable is defined corresponding to the density of people in the basic unit of building space. classSpace.PersonnelDensity, D_Floor1 P_Density;
(2) Calculation Variable. When developing an APP, some variables must be defined to store data and calculation results. However, because the permanent variable has fixed physical properties, it can only be used for calculation in the calculation process and cannot be directly used as the load of the calculation result. We propose the concept of a calculation variable, which is an intermediate variable defined in the APP whose stored value is valid during the current life cycle of the APP. Moreover, the calculation variables must start with “C_.” In the following code, a calculation variable is defined that corresponds to the movement times of people in the building space of a specific basic unit. float,APP,D_Floor1 C_MoveTime;
6.2.2. Time Offset and Location
To characterize the time and spatial attributes of single variables, time offsets and locations are proposed.
(1) Time Offset. Since some parameter values in SIM are a function of time, their corresponding permanent variables consist of a set of sequenced data. The permanent variables involved in the calculation may be at different moments; to simply represent their time-series characteristics, the concept of a time offset is proposed. A time offset corresponds to in in Section 5.1, which is the time attribute of a permanent variable and appears in the form of a suffix of the permanent variable in the program. The time offset allows users to accurately describe the value of permanent variables at different times, enhances the descriptiveness of the Touch language for I2B application tasks, and enables the close integration of building information with I2B application development. The following example of the personnel evacuation application represents judging whether the value of P_FireJudge before 5 seconds is equal to 0, where the first 0 represents that this permanent variable belongs to the local CPN. while (P_FireJudge(−5, 0) ! = 0)
(2) Location. In I2B, each basic unit in the same domain runs the same APP; thus, each basic unit includes the same variables. Touch proposes a “direct” communication mechanism in which data sent and received by the node are not required in the syntax, but data of the target node identified by location can be requested directly. To achieve this “direct” communication mechanism, we propose the concept of location, which is the spatial attribute of a single variable. Location is oriented to neighborhood interactions and is the distinguished name of the node in the neighborhood. It takes a value from “0, U, D, L, R, F, B,” which represent the basic unit itself and the basic unit’s upper, lower, left, right, front, and back physically connected neighbors, respectively. The location appears in the form of suffixes of single variables in the program. Due to the time offset, permanent variables are not referenced in the same way as calculation variables; instead, permanent variables are referenced as “<permanent variable>‘(’ <time offset> ‘,’ <location> ‘)’,” while calculation variables are referenced as “<calculation variable> ‘(’ <location> ‘)’.” The following code represents that the value of the local calculation variable C_MoveTime is equal to the value of C_MoveTime of its right neighbor. C_MoveTime(0) = C_MoveTime(R);
6.2.3. Special Statement
During the process of solving I2B application tasks, the basic unit usually traverses each neighbor node in the same domain as itself and calculates relevant values based on each neighbor node. For example, in the personnel evacuation application task, the basic unit calculates the time required to move from itself to its neighbors. Loops are commonly used in general programming languages to implement traversal. However, the differences in the number of neighbors attached to different nodes make it impossible to determine the upper limit of the incremental variable in the for statement, making it difficult to build generalizable applications. The traversal process of the for statement is a serial operation over several nodes semantically; however, that makes it difficult to reflect the data synchronization and parallelism characteristics of the I2B system.
To solve the above problem, this paper proposes some special statements, including a DO statement and a TRACE statement, which act on different objects. The DO statement implements parallel operations on basic units of the same type in the same domain. The TRACE statement traverses all the nodes in the neighborhood by specifying the neighborhood name, enabling the implementation of parallel operations on basic units in the neighborhood. The following example of the personnel evacuation application traverses the nodes in the neighborhood where the neighborhood name is NB_Escape. Dividing the distance from the local node to the neighbor node by the speed is equal to the time required to move from the local node to the neighbor. Using this statement, the local node can quickly find the moving time from the local node to each of its neighbors. Such operations reduced the amount of program code that must be written and exhibited universality. TRACE node (NB_Escape) C_MoveTime (0) = P_Length(0,0)/C_MoveSpeed(0);
6.2.4. Special Operator
The basic units in I2B application tasks usually need to perform complex operations on node data in a domain or neighborhood, such as maximizing or summing a variable in the neighborhood. This leads users to design specific algorithms to solve problems when programming. Since such algorithms must consider the number of basic units involved in the calculation and implement a complex underlying interaction mechanism, users consequently have to focus too much on the algorithm level instead of the application level. In addition, the code bindings to basic unit numbers cause difficulties when trying to achieve portability.
To improve the friendliness of the language and reduce the programming difficulty, this paper proposes special operators for network computing. According to the range of basic units that the operator acts on, the special operators are divided into domain operators and neighborhood operators. The syntax of a neighborhood operator is “<neighborhood name> ‘.’ <single-variable expression> ‘.’<special operator type>,” where neighborhood name specifies the scope of the operator, the single-variable expression represents the calculation object, and the special operator type includes Maximum, Minimum, Sum, and so on. Note that when referring to a single variable here, there is no need to add a location suffix because the operation is a unified operation on nodes in the neighborhood. The neighborhood operator replaces the node number with the neighbor name variables, which makes the program design effectively get rid of the dependency on the node number and become more flexible.
The following example specifies that in the personnel evacuation application, the minimum value of the sum of C_EscapeTime, C_PassTime, and C_MoveTime of the nodes in the neighborhood named NB_Escape is calculated, and the minimum value is assigned to the variable t. When special operators are used for network calculations, the complex algorithmic details and low-level interactions among nodes are shielded from both the user and the code, which improves program portability. t = NB_Escape. [C_EscapeTime + C_PassTime + C_MoveTime].Minimum;
6.3. Language Elements for Controlling Program
When a user writes an I2B APP in a GPL, the lack of corresponding language elements constricts the APP, resulting in a lack of modularity and poor program readability. To provide the entry point for the APP and improve the encapsulation of the Touch program, we propose AutoMain function and events for controlling program.
6.3.1. AutoMain Function
The AutoMain function is the entry point and main function of the Touch language program and is mapped from the programming concept in Section 5.1. I2B applications execute by starting at the beginning of the AutoMain function and continuing until the AutoMain function ends.
6.3.2. Event
A basic unit in I2B may perform several different application tasks, some of which are characterized by event triggering. When using a GPL for programming, because the code organizational structure of the application program is not tightly constrained, it is often nonmodular, and programs involving different functional application tasks are often tightly coupled. This also makes it more difficult to achieve code reuse and can affect the reliability and maintainability of the program. To effectively describe the event triggering characteristics of application tasks and to enhance the modularity of application task programs, we propose events, which correspond to specific application tasks in I2B. Events are mapped from the programming concept in Section 5.1 and are divided into triggered events and nontriggered events according to the operation mechanism of application tasks. Triggered events are not triggered immediately after they are created in the AutoMain function; instead, they are launched when a triggering condition is met. The following example of the personnel evacuation application indicates that the trigger condition is reached when the permanent variable P_Fire (0,0) that corresponds to the fire judgment parameter is greater than 0, at which point the application task is executed and the local fire alarm is then turned on. event PersonnelEvacuation(P_Fire(0, 0) > 0) {P_AlarmSetValue(0, 0) = 1;}
Events are the key to parallel and triggered programming. They are the smallest unit of program execution flow in Touch, and different events can be executed in parallel. Events can effectively describe the event triggering characteristics of application tasks and encapsulate a program describing an application task to achieve program modularization.
6.4. Touch Concrete Syntax
Based on the conceptual programming architecture and key language elements, we provide an excerpt of the Touch syntax to show the most relevant features, as shown in Figure 10. The Touch program consists of a set of variable definitions and a main program. The variable definition statements can include both domain-specific variable definitions and single variable definitions. The main program contains a series of events. SingleVarRef represents the syntax when referencing a single variable, which is different from the definition of a single variable, and it has a suffix of time offset or location. Moreover, stmt represents various statements and exp represents expressions. LibraryFunction in the syntax refers to some library functions included in Touch, e.g., Record is used to record the best escape path. Due to space limitations, we did not show the syntax of the terminators corresponding to language elements such as DomainVar, PermanentVar, and TimeOffset.
7. Touch Language Support Tool Implementation
Because the Touch language has many special language elements oriented to the characteristics of I2B domain and supports real-time read and write interaction with the SIM in CPN, it is quite different from the existing programming languages. Therefore, it is difficult for existing application development tools to directly support Touch language program editing and implement functions such as keyword syntax highlighting and syntax error-checking. In addition, the Touch language cannot be directly executed on the CPN, it first needs to be converted into a hexadecimal target code form that the CPN can recognize. Therefore, tools to effectively support the development of I2B APP are still lacking. To improve the efficiency of users developing I2B APPs, this paper builds IBADT (I2B APP Development Tool) to automate the development process of I2B APPs. The novelty of this tool lies in two aspects:(i)IBADT provides a friendly GUI (graphical user interface) for editing and testing I2B applications in an understandable Touch language.(ii)IBADT can automatically convert I2B applications based on Touch into hexadecimal CPN-executable code and insert it directly into the target software system, which effectively reduces the development burden of users who lack I2B application task management control knowledge.
7.1. Functional Requirements of IBADT
IBADT aims to promote I2B APP development and bridge the gap between I2B application control and software development for users. Our functional requirements for IBADT are as follows: RQ1: Effectiveness. The tool should effectively support the I2B APP development process and should be able to edit and test I2B application task control strategies based on Touch. RQ2: Efficiency. The tool should have certain automation capabilities, such as automatic keyword syntax highlighting and syntax error-checking in Touch programs, and should be able to recommend various SIM parameters based on the class type entered and generate I2B APP code files based on executable object code. RQ3: Availability. The tool should be friendly and easy for I2B APP developers (users) to use, and it should provide an intuitive user interface. RQ4: Reusability. The tool should store I2B applications in standard and open file formats to foster sharing and reuse.
7.2. Key Approach to IBADT Development
To achieve these specific functions, a Touch-to-Hex-based IBADT development method is proposed. Figure 11 shows the general concepts behind this method. Combining the Touch language and the CPN-executable target code specification, we implement the I2B APP development tool (IBADT) in Xtext [50], a widely used framework for the development of DSLs. When using IBADT to develop an I2B APP, we can first edit and test the I2B application using Touch language rules and then automatically convert the I2B application from the Touch language into hexadecimal CPN-executable object code.
IBADT consists of three key parts: the editing and testing module, the persistent storage module, and the code generation module. Figure 12 shows a high-level view of IBADT architecture.
7.2.1. Editing and Testing Module
The editing and testing module is a basic component in IBADT that mainly supports editing and checking I2B applications. First, Touch syntax rules are listed in the IBADT rule-editing area, and IBADT managers can modify these rules based on the actual needs of I2B application tasks. When developing an I2B APP, this module performs keyword highlighting and syntax-checking to ensure that the application meets the Touch standards. If a syntax error exists in the program, the incorrect code block is indicated with a red underline.
This module supports functionality such that when a class type of a basic unit is entered in the program editing area, all the parameters of the class type can be automatically recommended in the form of a member list from which users can select and apply. By defining and calling permanent variables, interoperation with SIM parameters is realized. Essentially, this feature points to the permanent variable memory in the SIM parameter table.
7.2.2. Persistent Storage Module
To achieve reading real-time parameter data from the SIM, a persistent storage module is designed. The persistent storage module provides storage and sharing services for SIM data. Because the SIM information has the characteristics of a tabular data structure, we use the standard MySQL database as a storage carrier and design a MySQL file structure for storing SIM data. This module inserts the class type of all basic units in the SIM and all the parameter names corresponding to each class type into the MySQL data table. The storage structure of the MySQL file is divided into two areas to store the SIM data: the SimClassType area and the SimParameter area. The SimClassType area is used to store the class type names in the SIM, and the SimParameter area is used to store the specific parameters and their various attributes corresponding to each class type, such as a parameter’s name, attribute value, data type, and so on.
7.2.3. Code Generation Module
The ultimate goal of IBADT is to generate hexadecimal CPN-executable code and insert the I2B application task logic directly into the target software to build the I2B software system. To achieve this goal, we implement a code generator with Xtend [51], which is a Java-like general-purpose programming language tightly integrated with Java that allows writing much simpler and much cleaner programs. This generator parses each element in the I2B APP and creates the corresponding CPN-executable code. Furthermore, this generator is integrated in the Xtext-based IDE (integrated development environment) of the Touch language.
7.3. Functional Description of IBADT
The main interface of the IBADT tool is shown in Figure 13. The program shown in the figure is the personnel evacuation application example of this paper. The left side of the main interface shows the project file directory. Users can view existing project files as well as the object code files generated by the code conversion module. The right side of the main interface shows the newly created variable in the program and the data type corresponding to that variable. IBADT has the following functions.
7.3.1. Program Editing
The program in Figure 13 defines some permanent variables, such as P_FireJudge and P_Intensity, which represent the fire judge parameter and the fire intensity parameter, respectively. IBADT supports keyword highlighting in the Touch language, including data types and commands such as “domainTypeEscape,” “classSpace,” and “float”. In addition, we can check the syntax of the Touch program at any point during the editing process. As shown in Figure 13, due to carelessness, we wrote “DFloor4” instead of “D_Floor4,” which does not follow the rule that a domain type must start with “D_.” However, IBADT intelligently found the problem segment “DFloor4,” inserted underscores to indicate the problematic code segment, and displayed a “Domain name should start with D_” prompt.
7.3.2. Parameter Recommendation
Figure 13 shows that when the programmer enters “classSpace,” IBADT automatically displays a SIM parameter list corresponding to the “classSpace.” The parameter list contains “ChannelLength,” “AirTemperature,” and other values from which the user can select to rapidly define permanent variables.
7.3.3. Code Generation
Clicking the Project- > Build Automatically generates the executable object code file automatically on the CPN. The source file is the Touch program code file (.touch) written by the user using the Touch language, and the automatically generated file is the object code file (.hex).
8. Experimental Evaluation
In this section, the proposed method is evaluated to verify the effectiveness and the efficiency of Touch compared to traditional development methods. Effectiveness is examined from the applicability, portability, and maintainability of the application. Efficiency means that users must be able to develop I2B APPs faster when using Touch than when using traditional development methods.
8.1. Experiment of Effectiveness
The personnel evacuation case (described in Section 3.2) is used to verify the effectiveness of Touch and its supporting tools. The experiment is designed to answer these questions:(i)Can Touch be used in practical scenarios?(ii)Can applications developed with Touch adapt to different network topologies?(iii)Is the application developed using Touch easy to maintain?
We first develop a personnel evacuation application using Touch. Then, in the actual experimental scenario, the application is tested and compared with the execution effect of an application developed in C language.
8.1.1. Experimental Scenario
In this experiment, we select the first floor of our research group’s experimental building as the experimental scenario. The first floor contains two emergency escape exits to the outside; these exits are located at both ends of the corridor and are termed Exit 1 and Exit 2. A floor plan view is shown in Figure 1. According to the building space unit division and passage connection rules, the building is partitioned into 12 building zones. Each zone is equipped with basic data acquisition and processing equipment such as a CPN, sensors, universal controllers, and dynamic evacuation indicators. The smoke temperature composite sensor in the zone can monitor fire information in real time. Simultaneously, personnel monitoring equipment installed in the partition monitors the location distribution information of the personnel present in each partition [52]. The dynamic evacuation indicator can change the escape direction based on the conditions to effectively guide decisions of trapped people to follow the best evacuation direction and route. The CPNs on the first floor of the experimental building are wired to construct a network. Figure 1 shows a CPN connection network topology diagram corresponding to the building zones. The initial distribution of people in the building is shown in Table 4, and the total number of people on the first floor is 64.
8.1.2. Development with Touch
Figure 14 shows the Touch-based application of personnel evacuation. Lines 1 and 2 define a domain name variable and a neighborhood name variable. This application task belongs to the personnel evacuation function subnet; therefore, the domain type is domainTypeEscape. Lines 3 to 6 define a series of permanent variables. Due to a large number of variables, only a few are listed here. Lines 7 to 9 define calculation variables that represent the moving time, passing time, and escape time. Line 12 indicates that an event named PersonnelEvacuation is defined in the AutoMain function. When the fire parameter P_Fire (0,0) is greater than 0, the event is triggered, and then all nodes in the domain begin computing in parallel. Lines 13 to 16 indicate that the local escape time is initialized according to the attributes of the building space unit. When this node is an emergency exit node, the escape time is 0; however, when it is an internal node, the escape time is NULL, where NULL represents infinity. Lines 18 to 21 use the TRACE statement to traverse the neighborhood nodes to calculate the passing time and moving time from the local node to each neighbor node. Line 22 uses the neighborhood operator to find the minimum of the sum of the passing times and moving times of the local CPN to each neighbor and the escape time of the neighbor. The escape paths of the corresponding neighbor nodes are also recorded, and finally, the local escape time is updated. Through iteratively computing these values, the escape path is updated in each iteration until the iteration termination condition of line 17 is finally met. When the number of people in all spaces is 0, the calculation ends, and the personnel evacuation task is complete.
8.1.3. Experimental Process and Results
Based on the experimental scenario, we conduct three groups of personnel evacuation experiments. In Group 1, no dynamic evacuation instructions are given, while for Group 2 and Group 3, we compile and download the personnel evacuation APPs written in the C language and Touch, respectively, to the CPN. In both programs, the information interactions between the nodes are used calculate the evacuation instructions. During the experiment, personnel are evacuated in strict accordance with the provided instructions. After the hardware platform is prepared, IBADT is used to convert the personnel evacuation APP written in Touch to CPN-executable hexadecimal object code (stored in Touch.hex). Simultaneously, the GNU Compiler Collection (GCC) is used to convert the personnel evacuation APP written in the C language to C.hex files. We use the serial debugging assistant to download the code in both Touch.hex and C.hex to the CPN. Then, we run the APP corresponding to the C.hex code in Group 2 and the APP corresponding to the Touch.hex code in Group 3.
As listed in Table 5, in Group 1 (without instructions), the number of people who chose Exit 1 and Exit 2 accounted for 24.1% and 75.9% of the total population, respectively, while in Group 2 (with instructions), the number of people who chose Exit 1 and Exit 2 accounted for 45.3% and 54.7% of the total population, respectively. In Group 3 (with instructions), the number of people choosing Exit 1 and Exit 2 accounted for 40.6% and 59.4% of the total population, respectively. The results of these three sets of experiments show that the evacuation instructions provided by the I2B system effectively reduce the evacuation pressure on individual exits by balancing the number of personnel using each exit.
The total evacuation time for Group 1 without instructions is 140 seconds, while the evacuation times for Group 2 and Group 3 are 125 seconds and 136 seconds, respectively, indicating that providing evacuation instructions reduces the total evacuation time. Comparing the experimental results of Group 2 and Group 3, it can be seen that the total evacuation times of the two experiments and the number of evacuations at each exit are similar and that the total evacuation times are shorter than evacuation without instructions. This shows that the effect of the personnel evacuation APP written in Touch is quite similar to the effect of the evacuation APP written in C.
8.1.4. Discussion
To evaluate the effectiveness of Touch, we now discuss its features with respect to the requirements of the language.(i)Applicability. From the above analysis results, it can be seen that the I2B personnel evacuation APP developed using Touch language can effectively balance the number of evacuees at different exits, avoid congestion, reduce the evacuation time, and ensure the effective evacuation of personnel in emergencies. This proves that Touch can be effectively applied to I2B APP development.(ii)Portability. Generally, people develop applications for a specific network topology in a building. When a new building is given, the application needs to be programmed from scratch. Touch unbinds the application from the network topology through language elements such as DO statements and special operators, making the program portable. We can abstract a general solution through Touch, which is applicable to any given building topology. If the number of CPNs in the personnel evacuation function network changes, the application in Figure 14 can still be applied without changing the code.(iii)Maintainability. Touch enhances abstraction by introducing domain-specific concepts (e.g., basic units, neighborhoods, and domains) in the source code. This helps users to program in the same way as the case description and facilitates the writing, understanding, and maintenance of the applications, whereas using a general-purpose programming language such as C language is more difficult.
8.2. Experiment of Efficiency
The purpose of introducing Touch in I2B APP development is to reduce programming difficulty and improve development efficiency. This means that users can develop I2B APPs faster with Touch and the understandability and learnability of Touch are better.
8.2.1. Experiment Planning and Design
In this section, we discuss the planning and design of experiments, including experimental subjects, experimental variables, experimental instruments, and experimental design.
(1) Subjects. The subjects in this experiment include 15 graduate students in computer science. All subjects have basic experience in application development using C and Visual Studio IDE. They have designed and developed software in an academic environment for at least one year. Most of them have a basic knowledge of I2B and building control. The subjects are explicitly informed that they are free to choose whether to participate in the experiment and that their choice does not affect their course performance.
(2) Variables. We select the dependent and independent variables as follows. The dependent variable is the analyzed variable. In our experiments, the application development time, the number of lines of program code, and the development difficulty are the dependent variables. The development time and the number of lines of program code can be directly measured during the experiment while the development difficulty cannot be directly measured. The subjects can score the development difficulty of different development methods according to indicators such as ease of use, ease of learning, and so on. The independent variables are variables that we can control and change. In this experiment, we choose C language, the INR programming model [29], and Touch language as independent variables.
(3) Instrumentation. To support the experiments, we used the following materials:(i)Hardware Platform and Software Platform. The experiments are performed in a laboratory (controlled environment). The computers in the laboratory have the same configuration and are uniformly installed with Visual Studio (version 15.0), Touch’s supporting tool IBADT, and INR’s supporting tool. The computer desktop also includes a teaching platform that supports homework submission, completion time recording, and filling in scorecards.(ii)Log Sheet. We design two log sheets to collect experimental data. The first log sheet is used to record the application development time and the number of lines of code for each subject during the experiment. The second log sheet is designed as a scorecard, which covers a series of indicators that can reflect the difficulty of development, such as the understandability of the language, the friendliness of the development environment, and so on, as shown in Table 6. The subjects are asked to score the development method according to these concrete criteria.
(4) Experimental Design. Table 7 shows the design of our experiment. According to the principles of randomization, blocking, and balancing, the subjects are divided into three groups labeled as Group 1, Group 2, and Group 3, with 5 subjects in each group. During the preparation phase of the experiment, all participants are uniformly trained to understand the three application development methods. The experimental process is divided into two phases. In the first phase, the subjects use different development methods to complete the tasks. In the second phase, the subjects are asked to mark the development methods they used after completing tasks and submitting source code.
8.2.2. Experiment Operation
The operation procedure of the experiment is introduced in this section, including experiment execution, data collection, and data verification.
(1) Experiment Execution. Before the start of the experiment, we use three hours to conduct unified training for the subjects, including the following content: (i) the basic concepts of I2B and its application development requirements (Section 3) are explained in detail; (ii) C language and its supporting tool Visual Studio are briefly reviewed; (iii) the INR programming model and its supporting tool are specifically introduced; and (iv) the Touch language and its supporting tool (Sections 5, 6, and 7) are specifically introduced.
The subjects are then divided into three groups, each group containing five subjects. The actual experiment is divided into two phases. In the first phase, subjects in Group 1 use C and Visual Studio to design and develop the personnel evacuation applications (Section 3.2) while subjects in Group 2 and Group 3 use INR and Touch to complete the same task. All subjects are required to complete the task independently, and they also need to complete the task quickly while ensuring correctness. During the execution of the experiment, the subjects can ask the experiment administrator (the second author of this paper) questions about language tutorials or task descriptions, but the administrator does not answer questions related to task implementation. After completing the task, the subjects submit their applications using the teaching platform, which records the development time and number of lines of code for each application. In the second phase, the subjects are asked to score the programming language and programming environment based on their experience and related indicators. Table 8 lists the data generated at each phase of the experiment.
(2) Data Verification. Here, we perform a Shapiro–Wilk W test [53] on each dependent variable (i.e., development time, number of lines of code, and evaluation scores) to check whether the data conformed to a normal distribution. We test with a significance level of . The results show that the dependent variables followed a normal distribution. We then use box plots to examine the outliers of the dependent variables, as shown in Figure 15. Since all data samples are located between the lower and upper ends of the box plot, our dataset does not contain outliers.
(a)
(b)
(c)
8.2.3. Experiment Results and Discussion
(1) Data Analysis. Based on the scoring and measurement in Section 8.2.2, the comparison results of Touch with C language and INR are generated, as shown in Figures 16 and 17. Figure 16 shows the average development time, average lines of code, and the average score for developing applications using different methods. The results indicate that the average time to develop applications using C language is the longest, reaching 239.40 minutes. The main reason is that the low level of language abstraction causes the subjects to implement complex low-level details. Although INR introduces some high-level abstractions in the I2B field to allow developers to complete tasks in an average time of 152.80, Touch performs better. The subjects using Touch complete application development in just 64.00 minutes. In terms of lines of code, the number of lines of code for applications corresponding to the C language reaches 370.80 lines. Compared to this, the number of lines of code corresponding to INR is 133.00 and the number of lines of code corresponding to Touch is only 52.60. When the subjects use C language to program, they need to design a specific algorithm for the problem, resulting in massive amounts of code. INR encapsulates some complex operations into language elements such as operators to reduce the code size to a certain extent. Touch greatly simplifies communication between nodes and further improves the level of abstraction, making the effect more significant. In terms of average scores, C language scored 64.00 and INR scored 72.60, while Touch scored 87.40, which shows that it is easier to develop I2B APPs with Touch.
Combining the evaluation indicators listed in Table 6, the detailed comparison results of the three development methods are obtained, as shown in Figure 17. The value of Q1 reflects that the subjects understand all three programming languages. In terms of understandability (Q2), Touch gets 21.00 points higher than C language and INR, indicating that Touch is easier to understand and learn. This is mainly because Touch has fewer keywords and terminators and is simpler. Especially in the term of Q3 (ease of use), the C language scores 15.20 and INR scores 18.60. In contrast, Touch got a more satisfactory score of 22.20, which is because Touch adds many domain-specific language elements such as operators, time offsets, and so on, making the semantic expression stronger. In terms of the friendliness of the programming environment (Q4), the Touch support tool also achieves high scores. The support tool of Touch has a list recommendation function that can automatically display the parameters in SIM for users to choose, which reduces the rate of grammatical errors and the workload of defining variables. For the overall evaluation of programming efficiency (Q5), the advantage of Touch is even more significant, with the highest score of 22.40, while C language only scores 13.8 and INR scores 17.40. In a word, compared with C language and INR, Touch reduces the difficulty of developing I2B APP and improves development efficiency.
(2) Experimental Results and Discussion. In this section, we discussed the efficiency of Touch. Efficiency depends on the development time and the number of lines of code when using different development methods. When using Touch language to develop applications, compared to C language and INR, the development time is shortened by 73.23% and 58.12%, and the number of lines of code of applications is reduced by 85.8% and 60.45% compared to C and INR, respectively. At the same time, the scores of the subjects on different development methods reflect that Touch and its supporting tool are easy to understand and easy to use. It can be seen that Touch has obvious advantages in improving the efficiency of I2B APP development.
Touch greatly reduces the complexity of grasping the concept of I2B and effectively promotes the development process of I2B APP. Since Touch incorporates domain concepts into programming language elements, it provides different levels of abstraction (i.e., basic units, neighborhoods, and domains) and better expressions of complex tasks (e.g., communication between nodes and traversing neighborhood nodes). The Touch support tool provides a friendly development interface, which effectively shortens the development time. Moreover, Touch’s syntax is simple and easy to learn and use. Therefore, the Touch language greatly improves development efficiency and reduces the user’s development burden.
The issue of DSL evaluation has received increasing attention [54]. We compare the controlled experiment of the Touch language with the controlled experiment of DSL applied to different domains [55–60]. Most of these DSL controlled experiments adopt the method of “implementing the same problem in a DSL and a GPL and comparing the efficiency and accuracy of each approach” [55]. And the design and analysis of our experiments are similar to these DSL studies. On the one hand, the experimental results of these studies show that compared with using GPL, when subjects use DSL, the time to complete the task is significantly reduced [9, 55, 57], the number of lines of code of the program is less [18, 59], and the correctness of the task is higher [55, 57]; at the same time, the subjects’ evaluation of the DSL (e.g., ease of use [56, 58], comprehensibility [9, 58], and maintainability of the solution [56, 59]) is also higher. This is similar to the experimental results in this paper: compared with the C language, using Touch language can shorten the development time of I2B APP, reduce the number of lines of code, and improve the satisfaction of the subjects. However, this article does not use the correctness indicator [55] to compare the effectiveness of Touch and C language. In the next step, the correctness will be supplemented as an evaluation indicator in the experimental evaluation stage to enhance scientificity and persuasiveness. Furthermore, the Touch language is not only compared with GPL in this paper but also compared with INR [29] (a DSL) used to I2B APP development in terms of efficiency [60]. The experimental results show that the efficiency of the Touch language is better than INR.
On the other hand, these experiments concluded that using DSL is better than GPL with respect to effectiveness and efficiency [55–59]. This is also similar to the conclusion of this paper: compared with C language and INR, Touch language can effectively develop I2B APP and improve efficiency. However, this paper proves the effectiveness of the Touch language by verifying that the Touch program can be successfully converted to the target code and executed normally on the CPN. Therefore, this paper does not compare the effectiveness of Touch with C language, which is different from some DSL studies [55, 57] that use correctness indicators to evaluate the effectiveness of DSL.
(3) Threats to Validity. In this paragraph, the threat to the validity of this experiment is discussed. Construct validity: the measures of development time and the number of lines of code in this experiment are standard measures. The concept of development efficiency used in this article is broad, and it is easy to produce construct validity. To reduce this threat, we carefully designed a scorecard on development efficiency, including language understandability, ease of use, and friendliness of development tools. We refined the user experience in the development process into specific projects to reflect the development efficiency of different methods. Internal validity: in the experiment, we divided the subjects into three groups according to the principle of randomness and balance, and the ability of the subjects in each group was similar. Subjects have never used these methods before. We gave them enough time to question this task to ensure that they understood it. We carefully monitored and avoided plagiarism. No subjects gave up this task. External validity: external validity represents the universality of the conclusions of this paper. We took the personnel evacuation case as an experimental object, and this task is a typical scenario of I2B applications. The experimental results have universal significance for this type of application. However, the background of the subjects in this paper is limited. In the experiment, we selected a group of experienced graduate students as the experimental object, but Touch is not only designed for students but also designed for I2B engineers. In the future, we plan to conduct more experiments to study the effectiveness and efficiency of Touch and let more I2B engineers participate.
9. Conclusion
I2B is a novel intelligent building platform with excellent flexibility and scalability. To facilitate the development of I2B APPs and reduce the programming difficulty, the textual programming language Touch is proposed. We establish a conceptual programming architecture for I2B APPs containing three key programming concepts: basic units, neighborhoods, and domains. These improve the intuitiveness of application development. Then, the special language elements are created, including special data types, domain-specific variables, time offsets, etc., to effectively support the parallel computing model and portability aspects of the I2B platform. The formal definitions for the concrete syntax of Touch are also provided. Moreover, we implement a support tool for I2B APP development that provides user-friendly GUI support for editing, storing, and managing Touch programs.
In addition, the effectiveness and efficiency of Touch are evaluated using a personnel evacuation APP example. The results show that Touch can effectively support I2B APP development. Furthermore, compared with the traditional C language and INR programming model, Touch can significantly reduce development time and the number of code lines and has better understandability and ease of use. This advantage occurs because Touch incorporates I2B domain-specific concepts into Touch language elements and provides direct support for I2B APP development. Therefore, Touch greatly simplifies the I2B APP development process and improves user accessibility to applications. Overall, this paper is also a good example that can provide a reference for other research into domain-specific application development.
Our planned future work is twofold. First, we plan to combine the Touch approach with formal methods by analyzing the domain-specific model using a formal method and transforming the artifacts into a formal system. This formal system can then be used to verify practical applications and improve reliability. Second, we plan to investigate the applicability of I2B application development methods in cyber-physical systems.
Data Availability
The data used to support the findings of this study are available from the corresponding author upon request.
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this paper.
Acknowledgments
Special thanks goes to Academician Jiang Yi of Tsinghua University for his guidance and discussion. This research was funded by the National Key Research and Development Project of China (New Generation Intelligent Building Platform Techniques) (2017YFC0704100).