Determination of Requirements

This section describes the requirements and specifications necessary for the rational design of a distributed dynamic simulation mechanism for BACS. This also elaborates the reasoning behind the hypothesis that marrying both CME and BPS software tools by run-time coupling would potentially enable integrated performance assessment by predicting the overall effects of innovative control strategies in building environments. In consequence, the major objective of this work is to develop and implement run-time coupling between BPS and CME as an enabling product for BACS architecture.

5.2.1. Concept of Operations

As it is envisaged that both CME and BPS tools may run simultaneously on a heterogeneous network (e.g. Unix and Windows), and that potentially run-time coupling could be conducted with a test-rig as a control system (hardware testing in the loop), or even with a building emulator, the IPC mechanism must be platform independent. In consideration of these possibilities, the main objective, in this work, was to develop and implement a distributed simulation mechanism for BACS. In order to achieve this objective, the developed IPC must contain the following characteristics:

52 IPC, also referred to as inter-thread communication and inter-application communication, is a set of programming interfaces that allows the coordination of activities among cooperating processes.

 flexibility so that run-time coupling can support any building model and any external (or remote) control system;

 reliability so that run-time coupling can support the exchange of data between CME and BPS at important frequencies;

 resource sharing so that run-time coupling can share data over a network (e.g. BACnet);

 extensibility –so that run-time coupling can incorporate new applications over time without disruption or duplication of existing applications;

 concurrency –so that run-time coupling can process multiple applications at the same time;

 scalability so that run-time coupling need not change when the scale of a particular application increases;

 fault tolerance so that run-time coupling can appropriately address errors that occur during simulations; and

 transparency so that run-time coupling between CME and one or multiple BPS can be perceived as one application rather than as a collection of independent applications.

As outlined in the requirements described in Section 1.9, it is also important that the IPC mechanism have a large transmission capacity to enable communication among the multivariable control systems required to run when a building control application regulates a number of physical quantities at the same time. Such a situation requires that all sensed and actuated building, plant, and mass-flow control actions that ESP-r provides for simulation are exchanged with Matlab/Simulink. All existing possibilities regarding these three control actions are described in Table 5.1.

Table 5.1. Different control possibilities in run-time coupling

Control functions Sensed variables Actuated variables

Building control

actions Dry bulb temperature 1^st phase mass flow rate

5.2.2. System Requirements

In order to represent run-time coupling between CME and one or more BPSs in a manner analogous to BACS architecture (or technology), data representing physical quantities as they are handled in BACS architecture must be readily available and exchanged between CME and BPS on both sides of run-time coupling. To meet this requirement, this work enhanced the common data-exchange method that is widely used and available on most platforms because it allows for the exchange of data through run-time coupling with reference to the OSI model, as shown in Figure 5.1.

Figure 5.1. Exchange of data between CME and BPS within an OSI model

Conceptually, BPS is mainly written in Fortran codes and CME is largely written in C/C++ codes. As both BPS and CME are legacy tools, integrating them in a distributed simulation requires developing their bindings to the implemented IPC mechanism with low overhead by such means as exchanging data directly and avoiding the use of several programming languages. In the case of this research study, run-time coupling should support asynchronous events that occur when the time-step of one process differs from that of another process and during the synchronous events that occur when the two processes are synchronizing with the same defined time-step in execution. The exchange can be either unidirectional, as when data are sent one way, or bidirectional, as when data altered during the first process are sent to the second process, which in turn sends the data back to the first. The data are transferred in the form of data types using a common format so that the processes running on two different OSs can translate them as well as the underlying communication protocols.

Another important requirement of run-time coupling is having the ability to avoid communication-induced time delays that degrade the performance of building control applications, as shown in Figure 4.5. when a large amount of data, including those pertaining to outside conditions, the sensed and actuated variables of the three different control actions, and other necessary variables for simulation setup, are exchanged between ESP-r and Matlab/Simulink. Table 5.2 lists the number of variables pertaining to each ESP-r control action for which data must be exchanged with Matlab/Simulink.

Table 5.2. Number of all variables that ESP-r exchanges with Matlab/Simulink

Control actions Number of sensed variables Number of actuated variables Other variables

Building 3 + 7 (auxiliary) 2 1 + 3 (optional)

Plant 9 + 6 (auxiliary) 4 1 + 4 (optional)

Mass flow 8 + 9 + 6 (auxiliary) 2 1

In total, data regarding 66 variables must be exchanged between ESP-r and Matlab/Simulink (i.e. 16 regarding building control actions, 24 regarding plant control actions, and 26 regarding flow mass-control actions), not including those related to the establishment of communication options, e.g. mode of exchange. As most exchanged variables between BPS and CME must be declared as float precision, exchanging them correctly requires choosing the appropriate IPC.