## 4 Experiments
### Experimental Results
To depict better the situation, graphs are displayed with the number of files recorded during the experiment execution for each parameter's configuration where a disruption in the files recording is initiated. Figures 9-14 depict this situation for 12, 8, 6, 4, 2 and 1 smart meter, respectively. Figure 8: Success ratio in terms of smart meters’ readings received by the data concentrator as a function of the two analysed parameters. Figure 10: Number of files actually received as a function of time–8 smart meters. Figure 9: Number of files actually received as a function of time–12 smart meters. The graphs follow no linear pattern because there are gaps in recording. For example, the system records for one hour, then there is a gap of 20 min, then recording starts again. Connectivity problems may explain this issue. When connectivity is lost, no recording is made. The experiments show that when the system is placed under different stress conditions (for different combinations of parameters' levels) its overall performance can be affected, meaning that the desired amount of information is not obtained. Real situations could be different from the  
Figure 11: Number of files actually received as a function of time–6 smart meters. Figure 14: Number of files actually received as a function of time–1 smart meter. Figure 12: Number of files actually received as a function of time–4 smart meters. Figure 13: Number of files actually received as a function of time–2 smart meters. experimental setting tested in the SGILab, but the stress tests give an idea of the possible limitations that may occur in the performance of a system when operational conditions change. The graphs given in Figures 15 and 16 can be seen as visual representations of Tables 4 and 5. The figures show the two output variables (number of readings received, and number of files received) as a function of the two parameters' values. The green area corresponds to the case in which the success rate in terms of file/readings received is 100%, whereas the red area identifies the critical region of the parameters' space where the success ratio is very low. For example, 100% of success rate is obtained for \"number of files received\" when less than 8 smart meters are connected to the data concentrator and, at the same time, the sampling rate is above 4 min. The non-straight and non-monotonic 3D surface emphasises the intrinsic non-linearities, which are due to uncontrollable factors affecting the system under test. With the increase in the number of smart meters used it is anticipated that the surface area (orange and red in Figures 15 and 16) that represents low success ratios will increase too. The real value of the information provided in Graphs 15 and 16 depends on the considered use case (UC). For use cases that are real-time relevant this would lead to a non-interoperable system. For most of the use cases that are not real-time relevant even low success ratios would be enough for the realisation of the use case with guaranteed interoperability. The user decides which value of  
and BAIOP(s) need to be specified, and the test(s) should be executed. The next step is the design of experiments, which indicates how certain system's parameters can be changed to verify whether the system's interoperability holds under different operational conditions. The tests are repeated for all the selected values of the system's parameters, and it is decided whether or not the system performance remains the same and interoperability is maintained. The methodology shows which combination of parameters' values corresponds to a successful test, and to what extent. As a consequence, it can reveal important information about whether or not a system can remain interoperable or not under certain stress conditions. It should be noted here that it depends on the desired application to determine if the performance of a system is acceptable or not.