Modes of Communication or Transmission in Run-Time Coupling Because the main feature distinguishing a distributed simulation from a standalone simulation (or from Because the main feature distinguishing a distributed simulation from a standalone simulation (or from

The gSOAP compiler tools that provide SOAP/XML to C/C++ bindings were installed on both Unix and Windows. By compiling an XML schema, a number of files were generated, including the XML documents, a C++ stub, and skeleton codes, to map between the native C++ data representation and the XML format. The generated C++ stub and skeleton codes were compiled and linked with the client code integrated into ESP-r, which was in turn compiled and linked with ESP-r and with the server code integrated into Matlab/Simulink, which was in turn compiled and linked with the matespexge toolbox.

Figure 6.23 shows the response times for data exchange in XML format between ESP-r and Matlab/

Simulink by run-time coupling when they are running in the same and in different environments.

XML document with UTF-8 encoding

Figure 6.23. Response times for data exchange in XML between ESP-r and Matlab/Simulink The main objective of this experimental study was to determine whether exchanging data in XML format between ESP-r and Matlab/Simulink by run-time coupling impacts the communication latency and overall performance of control systems. The results presented in Figure 6.23 regarding the response times required for exchanging data in XML format with plain uncompressed string content between Matlab/Simulink and ESP-r by run-time coupling in the same environment and in different environments indicate that when Matlab/Simulink and ESP-r exchange 1 KB of data in XML format by run-time coupling, 5.1 ms is required to send and receive data in the same environment and about 7.6 ms in heterogeneous environments. The results were obtained without considering the processing time of ESP-r and Matlab.

Based on the aforementioned analysis on the effects of time delays in NCSs, it can be concluded that the time required to exchange data in XML format between ESP-r and Matlab/Simulink by run-time coupling while representing BACnet and LonWorks protocols in a simulation is within a reasonable limit. The experimental results were obtained by exchanging XML documents with string content that requires UTF-8 encoding⁸¹ because although there exist other ways of encoding⁸² XML documents, UTF-8 encoding is most widely used as the default encoding for XML. However, it should be noted that the use of character encodings other than UTF-8 may significantly reduce the time required to exchange data in an XML format.

6.4.3. Modes of Communication or Transmission in Run-Time Coupling Because the main feature distinguishing a distributed simulation from a standalone simulation (or from 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,⁸³ a partially synchronous, or an asynchronous mode.

In a standalone simulation, the simulation clocks (i.e. the number of simulation time-steps or iterations) can only be synchronized and advanced by a fixed interval (or step), but in a distributed simulation, the

81UTF-8 (Unicode Transformation Format -8bit) is an efficient means of encoding Unicode documents such as ASCII characters.

82 Other ways of XML encodings are e.g. base64 content and Direct Internet Message Encapsulation (DIME) attachments.

83 The synchronous mode is set as the default communication mode in run-rime coupling between Matlab/Simulink and ESP-r.

simulation clocks can be synchronized, partially synchronized, or totally asynchronized. These simulation clocks are synchronized when a distributed simulation between Matlab/Simulink and ESP-r requires strict causality,⁸⁴ partially synchronized when a distributed simulation requires running as in a real-time application, and asynchronized when a distributed simulation requires running in a chaotic manner (i.e. when neither Matlab/Simulink nor ESP-r waits for incoming data from the other).

Synchronous Mode

Synchronous mode is used when Matlab/Simulink and ESP-r 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. Therefore, Matlab/Simulink is in charge of the same number of simulation time-steps defined for ESP-r. Synchronous mode is a typical and simple way of run-time coupling between ESP-r and Matlab/Simulink because they must wait and exchange data at several predetermined time steps for the completion of their computations, as shown in Figure 6.24.

process

Figure 6.24. Run-time coupling between ESP-r and Matlab/Simulink in synchronous mode Because ESP-r and Matlab/Simulink are executed sequentially, communication in synchronous mode blocks the entire simulation at each predetermined time-step until the data transmission has been completed, which may cause delays in scheduled transitions. Therefore, when ESP-r and Matlab/

Simulink 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

Asynchronous mode is used in run-time coupling when ESP-r and Matlab/Simulink are processing independently 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 advantageous in some cases because both Matlab/Simulink and ESP-r can be run-time coupled with different numbers of simulation time-steps, although in other cases the efficiency or even the accuracy of the obtained results cannot be ensured. Figure 6.14 shows a case in which the time-step of either ESP-r or Matlab/

Simulink differs from that of the other.

process

Figure 6.25. Run-time coupling between ESP-r and Matlab/Simulink in asynchronous mode

84 Causality is a principle of cause and effect, i.e. neither ESP-r nor Matlab/Simulink can proceed without waiting for the other.

The asynchronous mode is difficult to program because it requires that Matlab/Simulink and ESP-r be run-time coupled in a chaotic manner; that is, 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 accomplished. When run-time coupling between Matlab/Simulink and ESP-r is implemented with 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. In addition to these functions, several signals, such as “operation would block!”, are returned immediately when the operations reading data from the sockets are invoked by ESP-r or Matlab/Simulink to indicate that there are no data to be received (see e.g. Stevens, 1998).

The asynchronous mode was implemented in run-time coupling between ESP-r and Matlab/Simulink so that Matlab/Simulink began computing once it received the first data exchange 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 the 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. Fumagalli et al., 1999). As it imposes no constraints on the performance of control systems, the asynchronous mode can be used in circumstances where communication-induced time delays are unpredictable. When synchronous mode is used in these circumstances, 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.

Consequently, asynchronous computation can be useful for the simulation of large building control applications, such as those supported by BACS technology, although it is much more difficult to parallelize 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 Matlab/Simulink and ESP-r are run-time coupled in partially synchronized (or partially asynchronized) mode, which imposes time restrictions on the synchronization of their events. However, the data exchange 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. Figure 6.26 illustrates these two possibilities.

Figure 6.26. Run-time coupling between ESP-r and Matlab/Simulink in partially synchronized mode:

ESP-r asynchronized and Matlab/Simulink synchronized (left) versus ESP-r synchronized and Matlab/Simulink asynchronized (right)

This partially synchronized mode represents the most realistic communication characteristic of BACS technology, mainly when ESP-r is running in asynchronous mode and Matlab/Simulink in synchronous

85 Sockets are created in blocking mode by default.

mode. Although communication delays in BACS architecture are difficult to predict, a communication delay usually has an upper bond, especially when data communications are performed by a network.

For this reason, use of the partially synchronous mode leads to less uncertainty than does the totally asynchronous mode, but is very difficult to program due to the timing differences between Matlab/

Simulink and ESP-r (see e.g. Shamsi et al., 2005). The partially synchronous mode was implemented in run-time coupling between ESP-r and Matlab/Simulink in such a way that ESP-r could run in either synchronous or in asynchronous mode while Matlab/Simulink ran in asynchronous or in synchronous mode.

When running a distributed simulation between a building model and its remote control system in partially synchronous mode, the results depend on the timing assumptions. The partially synchronous mode can play an important role in control systems, especially when building components are subject to delays or objects located in the building change their actions over the timeframe.

Experimental Results with a Building Control Application

To demonstrate the development and implementation of run-time coupling between Matlab/Simulink and ESP-r, a simple building control application in the form of an on–off control and an existing exemplar in ESP-r was analyzed to fulfil the following objectives:

 compare the results of a standalone simulation obtained using only ESP-r and of distributed simulations using run-time coupling between Matlab/Simulink and ESP-r;

 compare the results of internal and external (i.e. remote) control systems set to regulate the temperature at 22º C between 07:00 and 18:00 o’clock for different numbers of simulation time-steps per hour. The on–off control system was used simply to regulate the air temperature inside the building by supplying either maximum heating flux capacity (3000 W) or minimum heating flux capacity (0 W). The internal control system refers to the on–off control system implemented and available in ESP-r, while the external (or remote control) system refers to the on–off control system implemented in Matlab;

 compare the results of distributed simulations between this building model and its external on–

off control system running in synchronous, asynchronous, and partially synchronous modes; and

 determine the importance of using run-time coupling between Matlab/Simulink and ESP-r for the simulation of building control applications.

Standalone Simulation

Figure 6.27 illustrates a building model with its on–off control implemented in ESP-r. The heating system was set to operate when the indoor air temperature went below 22^o C and to stop when the indoor air temperature reached 22^o C, while the cooling system was set to operate when the indoor air temperature rose above 26^o C and to stop when the indoor air temperature reached 24^o C. As the simulation was performed during the winter, it was assumed that the indoor air temperature would not rise above 26^o C, and therefore the simulation only concerned the heating process.

Figure 6.27. A simple building model with an internal on-off control implemented in ESP-r

Figure 6.28. Simulation results obtained from a standalone simulation using only ESP-r

Distributed Simulations

Figure 6.27 illustrates a building model built on ESP-r with an on–off control implemented in Matlab.

The simulations were performed by run-time coupling between Matlab/Simulink and ESP-r in synchronous, asynchronous, and partially synchronous modes, and the data were exchanged between a building model and its external (or remote) control system during the simulation by a network.

Figure 6.29. A simple building model with an external on-off control implemented in Matlab

Figure 6.30. Simulation results obtained by run-time coupling between ESP-r and Matlab/Simulink in synchronous mode

It is important to note that the maximum number of simulation time-steps allowed by ESP-r to display simulation results is 60 times per hour for building zones and 100 times per hour for building plant components, but the maximum number of simulation time-steps allowed by ESP-r to run simulations is actually 999 times per hour for both. As in distributed simulations, the results are transferred from ESP-r to Matlab/Simulink every time step, these results can be saved and displayed in the Matlab side.

Modifying the maximum number of simulation time-steps in the source code to run simulations with very small time-steps would require much more effort than it does to run them with the maximum number of simulation time-steps. Therefore, the use of run-time coupling between ESP-r and Matlab/

Simulink can be an advantage in obtaining the results from distributed simulations between a building model built on ESP-r and its external control systems modelled on Matlab/Simulink with small simulation time-steps, which in fact are not possible with standalone simulations.

Figure 6.31 Simulation results obtained by run-time coupling between ESP-r and Matlab/Simulink in asynchronous mode

Figure 6.32. Simulation results obtained by run-time coupling between ESP-r and Matlab/Simulink in partially synchronous mode (ESP-r synchronized and Matlab/Simulink asynchronized)

Figure 6.33. Simulation results obtained by run-time coupling between ESP-r and Matlab/Simulink in partially synchronous mode (ESP-r asynchronized and Matlab/Simulink synchronized) Performance Analysis

The following conclusions can be made regarding the simulation results presented in Figures 6.28, 6.30, 6.31, 6.32, and 6.33:

1) With distributed simulation between ESP-r and Matlab/Simulink, it is as widely as possible to simulate applications in different manners (such as synchronous, partially synchronous and asynchronous), which are actually not feasible and not possible with standalone simulation.

2) The simulation results obtained with different time-steps (30 min,⁸⁶ 10 min, 5 min, 2 min, and 1 min) presented in Figure 6.28 and those presented in Figure 6.30 are identical despite being obtained by standalone simulation using ESP-r and distributed simulation between Matlab/

Simulink and ESP-r, respectively. In addition, it can be observed that in Figure 6.30, the simulation results can also be obtained with small-time steps (36 s, 6 s and 4 s), which is not the case in Figure 6.28. Therefore, it is more advantageous to use distributed simulation between Matlab/Simulink and ESP-r than use standalone simulation using just ESP-r.

3) The simulation results in Figures 6.28 and 6.30 at the time time-steps of 5 min, 2 min and 1 min show the same oscillations in control response around the setpoint during the occupied period.

These oscillations are due to control system capability, in which control actions are either fully on or completely off every time a deviation from the setpoint occurs. The control actions respond quickly but are sensitive to outside temperature changes, which cause chattering (or rapid switching of the controller) at short intervals. In Figure 6.30, it can also be observed that the results obtained with small time-steps of 6 s and 4 s are better than those obtained with large time-steps. Therefore, the use of small time-steps is sometimes necessary in simulations to reduce or overcome oscillations and to obtain results that are more accurate.

4) By comparing the simulation results presented in Figure 6.31 with those in Figure 6.30 (i.e.

those with the same number of time-steps), it can be observed that the simulation results obtained by run-time coupling between ESP-r and Matlab/Simulink in asynchronous mode differ little from those obtained by run-time coupling between ESP-r and Matlab/Simulink in synchronous mode. Specifically, the simulation results obtained with the time-steps of 30 min and 10 min are similar. However, the results obtained with the time-steps of 5 min, 2 min, and 1 min are slightly different because the results obtained with run-time coupling between ESP-r and Matlab/Simulink in asynchronous mode are influenced by several issues related mainly to

86 Note that in Figures 6.28, 6.30, 6.31, 6.32, and 6.33, m refers to minute(s).

computational speed and simulation time. The fact that the final series of simulation results presented in Figure 6.31, for which the number of time-steps in ESP-r is 1 min and a small delay is introduced in Matlab/Simulink, are similar to those obtained with the number of time-steps of 1 min indicates that both computational speed and simulation time advances play an important role in the simulation results when ESP-r and Matlab/Simulink are run-time coupled in asynchronous mode. In addition, the simulation results obtained by run-time coupling between Matlab/Simulink and ESP-r in asynchronous mode with the time-steps of 5 min, 2 min, and 1 min indicate that the control responses are sensitive to both computational speed and simulation time advances, which cause chattering (or small oscillations) at short intervals.

5) As observed by comparing the simulation results presented in Figure 6.32 with those of Figure 6.30 (i.e. those with the same number of time-steps), it can be observed that the simulation results are similar and consistent with each other, even though the results of Figure 6.32 were obtained by run-time coupling between Matlab/Simulink and ESP-r in partially synchronous mode while ESP-r was synchronized and Matlab/Simulink was asynchronized. This seems to be correct, as ESP-r waits for input from Matlab/Simulink, and Matlab/Simulink writes practically the same output. Every time Matlab/Simulink tries to read data from sockets and when no data are available to be received, Matlab/Simulink computes using the last received input, and provides the same output to ESP-r. Therefore, it is important to note that when a building model is synchronized (i.e. waiting to receive data from its control system), its control response is not sensitive, at all, to issues such as computational speed and simulation time advances.

6) By comparing the simulation results presented in Figure 6.33 with those of Figure 6.30 (i.e.

those with the same number of time-steps), it can be observed that the simulation results obtained at the time-step of 10 min (and even of 30 min) are similar, but that those obtained at the time-steps of 5 min, 2 min, and 1 min differ slightly. Because the simulation results of Figure 6.33 were obtained by run-time coupling between Matlab/Simulink and ESP-r in partially synchronous mode while Matlab/Simulink was synchronized and ESP-r was asynchronized, Matlab/Simulink waited for the input from ESP-r, but ESP-r did not wait for the output from Matlab/Simulink, and continued computing with the last batch of received data

those with the same number of time-steps), it can be observed that the simulation results obtained at the time-step of 10 min (and even of 30 min) are similar, but that those obtained at the time-steps of 5 min, 2 min, and 1 min differ slightly. Because the simulation results of Figure 6.33 were obtained by run-time coupling between Matlab/Simulink and ESP-r in partially synchronous mode while Matlab/Simulink was synchronized and ESP-r was asynchronized, Matlab/Simulink waited for the input from ESP-r, but ESP-r did not wait for the output from Matlab/Simulink, and continued computing with the last batch of received data

In document A distributed dynamic simulation mechanism for buildings automation and control systems (pagina 178-188)