Description of BACS architecture
ABs are a class of buildings that are automatically supervised and controlled by or from a central computer-based monitoring and control system such as distributed control system (DCS) architecture, or more specifically BACS architecture. Therefore, BACS is an example of a DCS because it uses a computer-based control system to replace so-called hardwired controls with control strategies implemented in software. The basic function of BACS is to automatically monitor and control a wide range of building performance applications including HVAC equipment, lighting components and other tasks such as access control, energy management, and fault diagnoses in a building or a group of buildings over a network. While this technology has several advantages, it also brings inevitable problems due to the network. Fig. 1 shows a complete BACS architecture that can be described at four main levels[2, 10, 11]:
1) The management level consists of a central computer used for managing and analyzing data, communicating with external systems, and operating building equipment and components.
2) The network level consists of an open protocol connected to the network through routers used for data exchange between the central computer and substations (or terminals).
3) The automation level consists of one or more substations used for interfacing building HVAC equipment and lighting components to the network.
4) The field level represents the low level where building HVAC equipment and lighting components (i.e., sensors and actuators) and final users are located.
Because BACS uses a network for data exchange between a central computer and substations, this can degrade both the performance and the stability of HVAC equipment and lighting components in buildings. The most common and straightforward way to evaluate such problems without a full-scale implementation of BACS architecture is by a modelling and simulation approach. Therefore, successful development and application of BACS require a scalable simulation platform that supports evaluation and verification of different control and network algorithms. As a consequence, a distributed simulation environment was developed and implemented mainly for BACS to simultaneously simulate building control applications and communication network dynamics.
Development and design of run-time coupling
The design of run-time coupling between Matlab/Simulink and one or more ESP-r(s) begins with the definition requirements, and proceeds eventually to conceptual design of the run-time coupling by means of trade-off analysis, and then to detailed design of every part of the run-time coupling being developed. Therefore, a set of requirements were first identified and set forth as the basis for the development and design of the run-time coupling. However, these requirements must then be taken into consideration at the early-stage of development. Among the most important of these requirements are[4, 12]:
1) The ability for run-time coupling between Matlab/Simulink and one or more ESP-r(s) to run on a heterogeneous network as on Windows and Unix operating systems (OS).
2) The ability for run-time coupling between Matlab/Simulink and one or more ESP-r(s) to support data exchange over a network in either unidirectional or bidirectional way.
3) The ability for run-time coupling between Matlab/Simulink and one or more ESP-r(s) to support different data exchange formats including ASCII, binary and extensible markup language (XML).
4) The ability for run-time coupling between Matlab/Simulink and one or more ESP-r(s) to support different communication modes including synchronous, asynchronous, partially synchronous (or asynchronous).
5) The possibility for run-time coupling between Matlab/Simulink and ESP-r to enable simulations with either a real building (e.g., building emulator) or a control test-rig (e.g., hardware in the loop testing), in which the inter-process communication (IPC) must then be platform independent.
After evaluating and selecting the most suitable solution among a number of possible options, using network (or internet) sockets has been chosen and approved by [2, 13, 14] as the best means of implementing run-time coupling between Matlab/Simulink and one or more ESP-r(s) since they meet all the requirements of the run-time coupling, including those described above, and they can also be used to represent in simulations real-time building control implementations over a network, as shown in Fig. 1.
Network sockets are an IPC mechanism that is used for run-time coupling between ESP-r and Matlab/Simulink to support modelling of a building model and its external control systems separately. Both the building model and its control systems can be located on either the same machine or different separate machines running different OS such as Unix and MS-Windows connected to a network. They also work together by exchanging data in a common format including ASCII, binary and extensible markup language (XML) over a network, and by supporting communication modes such as synchronous, asynchronous, and partially synchronous. Fig. 2 illustrates the proposed approach to run-time coupling between Matlab/Simulink and ESP-r.
Run-time coupling between Matlab/Simulink and ESP-r
Run-time coupling is implemented in such a way to facilitate data exchange between Matlab/Simulink and ESP-r when they are concurrently operating either on the same machine or to increase the speed of simulations, on separate machines connected by a network. In addition, when Matlab/Simulink and ESP-r are located on different machines running over different OSs and/or using different data formats by initiating network protocols, such as LonWorks and Bacnet, run-time coupling can be run to support portability and distributed dynamic simulations over a heterogeneous network (i.e., on different machines with different OSs and/or different data format protocols). For this reason, in this work different methods for marshalling and demarshalling (or unmarshalling) data over a network were implemented within run-time coupling to convert data (i.e., sensed or actuated variables) into a form of external network representation and then back to their native format before being accessed by a building model and its control systems, respectively.
Detailed design of run-time coupling
In order to implement run-time coupling between ESP-r and Matlab/Simulink with network sockets, the C/C++ programming language was used of which socket libraries were originally implemented. As neither Matlab/Simulink nor ESP-r has simple interfaces with socket application programming interfaces (APIs), a detailed design of the run-time coupling is proposed and implemented with the objective of interfacing socket APIs to both ESP-r and Matlab/Simulink, as shown in Fig. 3.
Detailed design of run-time coupling between ESP-r and Matlab/Simulink
As the detailed design shown in Fig. 3 is based on the idea that run-time coupling should be delivered in such a way with no or minor user interferences, the details of the parallel and distributed computations are then hidden to users, while necessary information, such as the port number and IP address of the Matlab/Simulink location, is provided through user interfaces in order to create sockets that allow one or more ESP-r(s) to exchange data with Matlab/Simulink. As both datagram and stream sockets are supported, the same sockets type should be selected on both sides of the run-time coupling mechanism. By such means, this mechanism can serve as a virtual interface that supports portability between heterogeneous platforms, enables distributed dynamic simulation of BACS, and achieves a higher level of interoperability by using a common middleware platform rather than a non-distributed communication system. Besides this middleware platform, two data encoding methods are integrated to improve interoperability when Matlab/Simulink and ESP-r are running in heterogeneous environments and to increase the speed of data exchange between a building model and its control systems when both ESP-r and Matlab/Simulink are running on distant machines connected to a network. The first method of data encoding consists of implementing two modes (ASCII strings and binary codes) to meaningfully and accurately exchange data between a building model and its control systems over a network. The second method consists of using a set of web-based interoperability specifications, such as web-services based on XML in order to enable building models and their control systems to exchange data with a high level of interoperability between ESP-r and Matlab/Simulink while representing different network technologies, such as BACnet and LonWorks protocols, in a simulation.
The right side of Fig. 3 shows how ESP-r and its integrated subsystems (zone, plant, and flow modules) are bound to socket APIs, while the left side of Fig. 3 details how the “matespexge” toolbox is implemented to bind socket APIs to Matlab/Simulink. On the ESP-r side, several subroutines, such as IBCLAW25, IPCLAW12, and IFCLAW4, are added and implemented in a building simulator (BPS) to allow direct data transmission between the subroutines and their parallel programs, which are implemented in the matespexge toolbox during simulation. Other subroutines, such as that for a test function, are implemented in a project manager (PRJ) to determine whether any of the building simulator (BPS) integrated modules invokes external control system that should be remotely processed from Matlab/Simulink. If one of these integrated modules occurs, a graphical user interface containing data regarding the port number, server IP address, current process number, communication mode, protocol type, and mode of data exchange appears so that the user can modify and choose specific settings. Initially, these settings are set to default values and correspond exactly to those specified in the matespexge toolbox. Changing these settings is possible, although Matlab/Simulink and ESP-r must use the same entries to ensure their connection. On the Matlab side, the matespexge toolbox is designed with graphical interfaces in order to allow users to differentiate between sensed and actuated variables that should be exchanged with ESP-r. Executing the matespexge toolbox at the Matlab prompt results in a graphical user interface appearing and displaying the machine IP address of the Matlab/Simulink location, which should match the ESP-r IP address. As Matlab is the server of ESP-r client(s), executing first the matespexge toolbox is essential before initiating simulation in ESP-r.
As shown in Fig. 3, run-time coupling between ESP-r and Matlab/Simulink is designed in a layered model, where the upper open systems interconnection (OSI) layers resolve different aspects of the communication process. As ESP-r consists of legacy Fortran codes, the programs that operate building simulation and those that initiate and terminate it are positioned and executed in different steps (i.e., the first programs are executed every time-step during the simulation period, while the second programs are executed only when initiating and terminating the simulation). Placing functions that open and close sockets in the first programs would certainly incur significant delays while exchanging data with Matlab/Simulink during simulation, and opening and closing sockets at every time step could lead to computer failures.
The main advantages of this developed run-time coupling are that it permits any simulation of a building model and its control systems to be built separately using ESP-r and Matlab/Simulink, respectively, and that it provides the preferred means to handle interoperability tasks, especially cross interdisciplinary data integration and exchange between ESP-r and Matlab/Simulink with no or minor user interferences. Therefore, it requires only modelling a building model on ESP-r and its control systems on Matlab/Simulink, and then indicating their interfaces by specifying the port-numbers, modes of exchange, or variables that they will use to import or export data to or from each other.
Interfacing client socket to ESP-r
Because ESP-r, e.g., , is almost completely written in Fortran programming language and socket application programming interface (APIs) can only be implemented in programming languages such as C/C++, mixed-language programming using Fortran and C++ must be used to interface between Fortran and C/C++ programs. Therefore, mixed-language programming is used to develop and implement an approach combining a Fortran common block with global C/C++ extern data structures (or extern structs) of the same name in order to enable the addition of new variables that need to be exchanged with Matlab/Simulink without making large modifications in the existing programming codes.
ESP-r was modified and extended to enable users to obtain data on sensed and actuated variables in the external control systems of building zones, plant components, and/or mass-flow networks, and to choose settings (including server IP address, port number, current process number, network protocol, communication mode, and data-exchange format) for run-time coupling. The added Fortran subroutines that exchange data with Matlab/Simulink and functions indicate when initiating and ending simulations are combined together with socket APIs of the C/C++ client code separately. The C/C++ client code was developed in a hierarchical way in order to support all possible combinations of exchanged variables and settings that a user could choose in run-time coupling with Matlab/Simulink. Compiling the modified and extended ESP-r code together with the socket APIs of the C/C++ client code generates executable ESP-r, respectively, and allows ESP-r to run as a client process.
Interfacing server socket to Matlab/Simulink
In , there is a built-in utility called Matlab EXcutable (MEX) that is often used to convert C or C++ programs to a MEX format. The original sense of the Matlab/Simulink word represents two different environments, which are a high-level technical programming language and a graphical block-diagram interface. Depending on which environment is interfaced, two main approaches can be used to link external programs written in C/C++ code:
1) For Matlab, MEX-files are used with dynamically linked programs that, when compiled, can be called from within Matlab in the same way as M-files or built-in functions. In case we need to deal with Simulink, the links can be established between each other by just using “sim” functions.
2) Practically the same procedure is adopted by Simulink, although MEX S-functions are used with dynamically linked programs that, when compiled, can be called from within a Simulink block diagram. However, when there is a need to deal with Matlab, the link should be done via M-file S-functions that are more complicated than using a straightforward “sim” function.
The first approach is preferable not only because it is less complex than the second approach but also because it offers more advantages, such as: 1) the ability to manage a high number of exchanging variables simultaneously, 2) the versatility needed to meet the requirements of run-time coupling, and 3) the ability to implement functionalities that are not accessible by M-file S-functions.
Although the MEX-files were originally designed to allow the inclusion of external routines written mainly in C/C++, they are also capable of integrating external shared libraries, such as socket APIs, into Matlab. For these reasons, a MEX-file was used for the development and implementation of the “matespexge” toolbox.
By combining MEX-file functions and socket APIs, access from ESP-r to Matlab and Simulink functionalities, especially to the application toolboxes for advanced control systems, is realized by just invoking the name “matespexge” from the Matlab prompt. Once the matespexge toolbox has been executed, a graphical user interface including icons and menus will display and provide the dialogue for users to create M-files to remotely control a building zone, plant, and/or flow model as built on ESP-r accordingly. Further access from these M-files to Simulink can be obtained by using “sim” functions, although access from Simulink to Stateflow should be obtained by incorporating a Stateflow block in the Simulink block diagram. Moreover, these M-files include Matlab functions that contain the left- and right-hand arguments with which the MEX-file is invoked. Therefore, the matespexge toolbox was designed with the use of MEX-files that include facilities for enabling run-time coupling between Matlab/Simulink and one or multiple ESP-r(s). After compiling the matespexge toolbox, a dynamic executable file is generated with an extension corresponding to the OS over which Matlab/Simulink is running. Within the implementation of the matespexge toolbox, the external routines that specifically exchange data with subroutines for building zone, plant, and flow network modules of ESP-r are encapsulated into a single MEX-file. A global identifier is also integrated to determine which building zone, plant, and/or flow network model will exchange data with the created control file. Due to this fact, the user must provide valid information (i.e., as stated in ESP-r) on the input interface. In addition, as Matlab is an interactive tool, the handling callbacks from ESP-r are ensured by default in order to access Matlab/Simulink as a computational engine. For these reasons, the matespexge toolbox is designed in such a way to let Matlab/Simulink operate as a server process when its created control files are invoked by one of the three ESP-r modules. Because stateflow can be used together with Simulink for the simulation of MASs, the use of the matespexge toolbox becomes essential for enabling the integration of advanced control systems, such as hybrid systems and MASs in building performance simulation. It enables a user to interactively build, test, and simulate distributed applications between ESP-r and Matlab/Simulink, even when both software tools are running on separate and different OSs. Therefore, it is a key solution in enabling the analysis of multi-variable control systems of building performance applications (or operations) that had previously not been feasible.
A practical approach to representing BACS architecture in simulation
Although representing BACS technology in simulation, as shown in Fig. 1, is difficult if not impossible, this design of run-time coupling between multiple ESP-r(s) and Matlab/Simulink can allow identifying practical solutions for the integration of advanced control systems into building performance simulation, and improving distributed control applications such as planning and coordination of control actions, in ABs for better control and operation. As one of constrained BACS architecture has network-induced time delays, distributed simulations are required to analyze and simulate both the performance and stability of building HVAC equipment and lighting components in ABs. Hence, the need for distributed simulations originates from the fact that BACS requires the study of both control theory and communication networks in design architecture.
By assuming that Matlab/Simulink represents a central computer and ESP-r, a terminal in a similar way to BACS architecture, the IPC meshcanism used for run-time coupling Matlab/Simulink and ESP-r is thus designed to support cooperative applications through an interoperable middleware that is involved in facilitating the interface of any building model built in ESP-r with its external control system modelled in Matlab/Simulink, as shown in Fig. 3. This has for an objective to simplify data management and distribution over a network, provide for the independence and transparency of data exchange between building models and their control systems, and allow web-services to be highly portable in distributed simulations, in a similar way as the real-time control applications are represented in BACS architecture. Therefore, this work has enhanced the traditional approach to run-time coupling between ESP-r and Matlab/Simulink as shown in Fig. 2, with the addition of involving more ESP-r(s) to represent BACS architecture in simulation. Fig. 4 illustrates a more practical approach to distributed control and building performance simulation by run-time coupling multiple ESP-r(s) and Matlab/Simulink over a network.
A practical approach to run-time coupling Matlab/Simulink with multiple ESP-r(s)
As shown in Fig. 4, the framework that is implemented to support distributed and parallel simulations by run-time coupling one or more ESP-r(s) with Matlab/Simulink over a network occurs practically the same as BACS architecture. This framework was developed using multi-threads to optimally handle and connect multiple ESP-r(s) to Matlab/Simulink, for which an application similar to the one used in BACS architecture can at once run across several machines distributed over a network. In a similar way to BACS architecture, each ESP-r in the framework must be used to simply model building zone(s), plant system(s) and/or flow network(s), while Matlab/Simulink must be used to model all their remote control systems.
Run-time coupling two or more ESP-r(s) with Matlab/Simulink
Of the many possible ways to run-time couple more than one ESP-r with Matlab/Simulink at the same time, the portable operating system interface (POSIX) standard for threads has been the most widely adopted. The use of POSIX threads is very advantageous because of its standardization, flexibility, and portability, as well as fact that POSIX threads provide a standardized programming interface for the dynamic creation and destruction of threads (i.e., sub-threads). It also enables using the same port and a single shared address space to make Matlab/Simulink accessible to all ESP-r(s) connections that are handled on the network. By using a single address space abstraction, it is however possible to avoid the overhead inherent to data exchange and provide better support for concurrency, parallelism, and consistency of data exchange in run-time coupling of Matlab/Simulink and multiple ESP-r(s) with substantial ease. To nearly represent BACS architecture in simulation, the previous approach, shown in Fig. 2, was therefore extended with a capability to run-time couple one or more ESP-r(s) with Matlab/Simulink. This capability was developed with multi-threads in conjunction with C++ codes to support parallel and distributed control and building performance applications between multiple ESP-r(s) and Matlab/Simulink in the same simulation environment. Within this capability, all ESP-r(s) should share the same connection as Matlab/Simulink and be able to run either on the same machine as Matlab/Simulink or on separate machines connected to a network. Each time a new ESP-r is connected to Matlab/Simulink, its specific thread is thus created by the matespexge toolbox so as to avoid conflicts and data inconsistencies with other concurrent ESP-r(s) participating in the same simulation environment. As all participating (or connected) ESP-r(s) exchange data with the same Matlab/Simulink, any ESP-r can access all the global variables exchanged by Matlab/Simulink via its specific sub-thread. Fig. 5 illustrates how run-time coupling is implemented between Matlab/Simulink (i.e., matespexge toolbox) and multiple ESP-r(s) using POSIX threads.
Conceptual view of multi-threading Matlab/Simulink with multiple ESP-r(s)
As illustrated in Fig. 5, the matespexge toolbox is implemented in such a way that one or more ESP-r(s) can connect and interact with Matlab/Simulink concurrently. The number of ESP-r(s) to run-time couple to Matlab/Simulink depends on the application, varying from one (1) to nine (9) ESP-r(s) simultaneously. This implementation is fairly complex as it requires that the main thread of the matespexge toolbox accept incoming connections and create one ESP-r sub-thread for each ESP-r connection that is handled. These ESP-r sub-threads are a part of the matespexge toolbox used by shared data structures to communicate with their all parallel connected ESP-r(s). Because the matespexge toolbox can run-time couple with multiple ESP-r(s),
1) each data exchange to/from ESP-r is handled by the corresponding ESP-r sub-thread on the matespexge toolbox side;
2) each ESP-r sub-thread can send data to other connected ESP-r(s) by accessing the shared data structure that contains their references;
3) the sockets connecting the matespexge toolbox to each ESP-r can be retrieved through this shared data structure.
Consequently, all interactions between ESP-r(s) and Matlab/Simulink occur via the matespexge toolbox, where every ESP-r is handled by a particular sub-thread. Also this toolbox is implemented with call-back methods to allow remote control systems (i.e., control systems modelled on Matlab/Simulink) to be invoked as they receive data from their corresponding building models built on one or more ESP-r(s). Because building models built on multiple ESP-r(s) can interact with each other via the matespexge toolbox, their corresponding remote control systems can also interact with each other on the Matlab/Simulink side. The main objective of using this approach is to represent the BACS architecture in simulation and enable unrelated remote control systems, particularly advanced control systems such as MASs, to communicate with each other when their corresponding building models are built on seperate ESP-r(s). In effect, permitting control systems – particularly MASs – to communicate with each other while remotely regulating building zone, plant, and mass-flow models built on diverse ESP-r(s) connected to a network results in the design and development of advanced building control applications that had previously not been feasible, such as:
1) the use of coordinated and interconnected control systems, especially MASs, to better operate and regulate building HVAC equipment and lighting components in ABs;
2) the use of self-adapting control systems to react to climate changes, the addition or removal of equipment in a building, or building plant variations;
3) the use of self-upgrading control systems to meet occupant needs when damping effects or changes are critical factors in the functioning of the systems.
Communication modes in run-time coupling
Because the main feature distinguishing a distributed simulation from a standalone simulation (or a sequential simulation) is the method of advancing simulation time-steps, run-rime coupling between Matlab/Simulink and ESP-r was implemented with all the options accessible from the user interface to specify the number of simulation time-steps per hour and to determine whether the simulation should run in a synchronous, an asynchronous, or a partially synchronous mode.
Synchronous mode is used when ESP-r and Matlab/Simulink are run-time coupled and synchronized with the same number of simulation time-steps in execution. When either ESP-r or Matlab/Simulink must wait for incoming data from the other, the number of simulation time-steps is defined by ESP-r, which is the client for Matlab/Simulink, the server. Fig. 6 shows how ESP-r and Matlab/Simulink must wait for each other and exchange data by run-time coupling at several predetermined time steps for the completion of their computations.
Run-time coupling between ESP-r and Matlab/Simulink in synchronous mode
Because both ESP-r and Matlab/Simulink are executed sequentially, the exchange of data in this mode blocks the entire simulation at each predetermined time-step until the data exchange has been totally completed. Therefore, when Matlab/Simulink and ESP-r are run-time coupled in synchronous mode, the time constraints of scheduled transitions must be satisfied by such means as adjusting the timing of a control loop for several applications.
Asynchronous mode is used when ESP-r and Matlab/Simulink are run-time coupled and processing separately from each other, and not synchronized totally. As such, neither ESP-r nor Matlab/Simulink must wait for incoming data from the other and can continue their computations with the existing data, although the data might be outdated, until the updated data become available for computation. Running distributed simulations in asynchronous mode can be positive in some cases because ESP-r and Matlab/Simulink can be computed with different numbers of simulation time-steps, although in other cases the accuracy of obtained simulation results cannot be ensured. Fig. 7 shows a case where the time-step of either Matlab/Simulink or ESP-r differs from that of the other.
Run-time coupling between ESP-r and Matlab/Simulink in asynchronous mode
The asynchronous mode is difficult to program because it requires that Matlab/Simulink and ESP-r be run-time coupled in a chaotic manner; i.e., in such a way that neither Matlab/Simulink nor ESP-r must wait for incoming data from the other but instead proceed with its computation until the common task is fulfilled. As run-time coupling between Matlab/Simulink and ESP-r is implemented with network sockets, the asynchronous communication is characterized by the fact that the client and server programs integrated in ESP-r and Matlab/Simulink, respectively, contain functions that change sockets to non-blocking mode. Moreover, such changing signal is returned immediately when the operations reading data from the sockets are invoked by another to indicate that there are no data to be received, see e.g., .
The asynchronous mode was developed in such a way that Matlab/Simulink began computing once it received the first data from ESP-r. After data were received, ESP-r and Matlab/Simulink computed independently from each other, and when no data were available to be received, both continued computing using the most recently received data. Using asynchronous mode allows run-time coupling between Matlab/Simulink and ESP-r to handle existing data in a manner that may significantly reduce the execution time, see e.g., . As it imposes no constraints on the control performance, this mode can be used in situations where network-induced time delays are unpredictable. When synchronous mode is used in these situations, Matlab/Simulink and ESP-r may have to wait for incoming data for an extended time, which could result in very low or even impractical computation efficiency. Therefore, computation in asynchronous mode can be useful for the simulation of large building control applications, such as supported by BACS technology, although it is much more difficult to parallelize and distribute efficiently due to various independencies in run-time coupling between Matlab/Simulink and multiple ESP-r(s).
Partially synchronous mode
The partially synchronous mode is used when ESP-r and Matlab/Simulink are run-time coupled in partially synchronized (or partially asynchronized) mode, which partly imposes time restrictions on the synchronization of their events. However, the exchange of data between Matlab/Simulink and ESP-r by run-time coupling does not occur in lock-time-step, as it does in synchronous mode. When using the partially synchronized mode, it is assumed that the computation time-step and data delivery time of either Matlab/Simulink or ESP-r is between the upper and lower bounds. Therefore, as a partially synchronous mode lies between the synchronous and asynchronous modes, two possibilities are available for run-time coupling Matlab/Simulink and ESP-r in partially synchronized mode: 1) when ESP-r is running in synchronous mode and Matlab/Simulink in asynchronous mode, and 2) when ESP-r is running in asynchronous mode and Matlab/Simulink in synchronous mode. Fig. 8 shows both cases of the partially synchronous mode.
Run-time coupling between ESP-r and Matlab/Simulink in partially synchronized mode
The partially synchronized mode, when ESP-r is running in asynchronous mode and Matlab/Simulink is in synchronous mode, represents the most realistic communication characteristics of BACS technology (i.e., such the real-time control applications are performed in BACS). Although time delays associated with network (i.e., with communication) are difficult to predict in BACS architecture, these delays usually have an upper bond, mainly when data are exchanged over a network. Hence, use of the partially synchronous mode leads to less uncertainty than does the fully asynchronous mode, but is very difficult to program due to the timing differences between Matlab/Simulink and ESP-r, see e.g., .