<table><caption>**Table 7.3:** Results from the studied approaches</caption><thead><tr><th>Approach</th><th>System modeling</th><th>Failure behavior modeling</th><th>Perform automatic FT generation</th><th>Perform qualitative FT analysis</th><th>Perform quantitative FT analysis</th></tr></thead><tbody><tr><td>ISOGRAPH [169]</td><td>Yes</td><td>Yes</td><td>No</td><td>Yes</td><td>Yes</td></tr><tr><td>Haider et al. [3]</td><td>Yes</td><td>Yes</td><td>Yes</td><td>No</td><td>No</td></tr><tr><td>JARVIS [170]</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>No</td></tr><tr><td>Mehnni et al. [171]</td><td>Yes</td><td>Yes</td><td>Yes</td><td>No</td><td>No</td></tr><tr><td>Alshboul et al. [4]</td><td>Yes</td><td>Yes</td><td>Yes</td><td>No</td><td>No</td></tr><tr><td>Yakymets et al. [172]</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr><tr><td>Hamed et al. [174]</td><td>Yes</td><td>No</td><td>No</td><td>Yes</td><td>Yes</td></tr><tr><td>Silva et al. [180]</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr><tr><td>Chen et al. [181]</td><td>No</td><td>Yes</td><td>No</td><td>Yes</td><td>No</td></tr><tr><td>Xing et al. [182]</td><td>Yes</td><td>No</td><td>No</td><td>Yes</td><td>Yes</td></tr><tr><td>MetaFPA [178]</td><td>No</td><td>Yes</td><td>No</td><td>No</td><td>No</td></tr><tr><td>Clegg et al. [175]</td><td>No</td><td>Yes</td><td>Yes</td><td>No</td><td>No</td></tr><tr><td>smartIflow [233]</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>No</td></tr><tr><td>Xiang et al. [177]</td><td>Yes</td><td>Yes</td><td>Yes</td><td>No</td><td>No</td></tr><tr><td>CHESSIoT</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr></tbody></table>

(ISOGRAPH [169]) does not support this; this could be due to the scale at which FTs can be used, not only in safety analysis but also in other domains like reliability analysis, risk analysis, and so forth. However, as technology advances, we strongly believe that this should change in order to remain relevant in the market. Our approach provides a solid FT generation mechanism that can support large and complex models with advanced features including but not limited to event tracking, component sub-tree generation, analysis, and undeveloped branch identification.

* *Perform automated qualitative FT analysis:* This feature determines whether or not the proposed approach supports any means for performing qualitative analysis on the generated FT, including detecting minimal cut-sets, FT path reduction, FT event redundancies, and so on. According to the findings of our study, 57% of the approaches support this. Since FTs can be large, depending on the system size and its complexity as well as the individual component failure behavior, it is vital for an FTA platform to make it easier for the user to navigate through the system's main failure paths in order to better help in defining how they might be easily mitigated. This can be accomplished either graphically, through actions such as path reduction, as well as textually through deriving minimal sets of events required for a system to fail (minimal cut-sets). Aside from that, alternative approaches may be completely platform-specific and dependent on the failure behavior modeling approach and FT generation mechanisms.

* *Perform automated quantitative FT analysis:* This feature determines whether the proposed approach allows quantitative analysis, mainly the top failure event probability estimation. Offering such support could potentially aid in quantifying the risk and determining how to manage it. However, this is regarded as optional in the FTA mechanism due to the lack of a standard means of determining individual component failure rates, since basic event failure rates encompass not just hardware failures but also software, human, and environmental factors. Only 35.7% of the approaches evaluated support such a feature, namely [169, 172, 174, 180]. Our proposed approach not only computes the intermediate and top event probabilities from the basic events, but it also recognizes underdeveloped branches and injected failures. It is also worth noting that, during the FT generation process, a file containing the probability information is generated, which allows you to still update the component failure rates and re-run the analysis,
in which the new values are picked up by the tool without having to re-generate the FT again.

<figure><img src="image_46.png" /><figcaption>Figure 7.9: Feature support performances</figcaption></figure>

As it can be seen from the table, our approach supports all five features; among the others, only [172] and [180] support all of them. However, as previously discussed, these differ significantly from our proposed approach in terms of capacity and efficiency. In summary, the proposed approach is completely unique in terms of advancing the state-of-the-art through various novel mechanisms such as support for system design modeling, failure behavior modeling, automated FT generation, automated qualitative FT analysis, and automated quantitative FT analysis.

7.4.2 PMS system modeling (RQ2)

RQ2: Does the system-level modeling infrastructure address all the aspects of modeling a multi-
layered IoT system suitable for safety analysis?

Patient monitoring system design

In order to better answer this question, we showcase the capability of our proposed modeling environment employing the case study presented in Section 7.3.2. As can be seen in Figure 7.8, the Patient Monitoring System (PMS), uses a set of sensors to collect sick patient data and send them to a remote server. The system can display the data on the monitor as well as send an alarming signal when something gets wrong. Figure 7.10 represents the internal physical architecture of the proposed system. For the sake of simplicity and to facilitate the analysis process able to produce presentable results, we have considered the following changes to the architecture presented in 7.8. Firstly, we designed a PMS that only monitors a single patient. Secondly, we introduced a remote server component that acts as a bridge by hosting the service that saves the received data and exposes them to other third parties services that might need them. Thirdly, we replaced the doctor's phone sub-system with an alarming system component that receives data from the PMS software on the monitor side. Finally, we added a "Human" component to reflect the role of a doctor in the overall system functionality.

As shown in Figure 7.10, a "SensingUnit" composite component consisting of five sensors namely ECG, EEG, SPO2, pressure, and temperature sensors. All the sensors are placed on a patient's body to collect the patient's health parameters. They are directly sent to the controller, which aggregates all of that information and sends it to a gateway (in this case a transceiver). The gateway processes the data and forwards them wirelessly to a remote server. The server hosts the software services that save the data as well as exposes them to other authenticated parties in need. On the other hand, the monitoring
software deployed on the computer accesses such information and sends them to a displaying screen. When something goes wrong, for instance, in terms of sensor reading values that exceed or are below a certain threshold, the monitoring software can decide to raise an alarm in order to alert the doctor about the unusual condition of the patient. In this case, a doctor checks on the displayed data and decides to act accordingly by either shutting off the alarm, changing the configuration in the systems, or fixing some issues that might be related to the sensors.

<figure><img src="image_47.png" /><figcaption>Figure 7.10: Patient monitoring system</figcaption></figure>

### PMS model includes failure behavior data

To facilitate the modeling of the system failure behavior data needed for the safety analysis data, the infrastructure allows annotating the failure behavior rules as well as the failure rates on each of the low-level simple components and this information is fully part of the model itself. As we all know, external influences can cause a system to fail. Through two system-level input ports, the presented architecture allows for simulation effects in which an external failure introduced in the system would affect the overall system functionality. For instance, the *sys_power_in* port, used to model the power source outlet, was been injected with an "omission" failure which basically models the event in case there is a power outage. On the other hand, the *sys_hum_in* port is used for modeling the external influence of the doctor. In our case, a "late" failure was used to simulate an event in which a doctor reacted late due to some external factors. Finally, the system contains two output ports, namely *system_monitor_out* for modeling the output port from the monitor, and the *system_alarm_out* to model the output of the alarm system. According to the direction of the ports at the system level as well as the type of failures that are able to propagate to them, different FTs are generated accordingly.

### 7.4.3 System failure behavior (RQ3)

*RQ3: How well do the proposed FLA rules efficiently reflect the system failure behavior leading to the system top failure events?*

As was previously anticipated, the above system is subjected to different kinds of failures either being internally generated from the system or coming from the surrounding environment. As we described in the previous section, it is possible to model the individual component's failure behavior
that later gets assessed in determining the failure behavior of a sub-system or an entire system. Note that we are not focusing on software-level functional behavior but on physical failure behavior which can be even understood by non-professional users. In order to understand the need for the conducted analysis, let's first discuss different top failure scenarios that we have taken into account in defining individual component rules.

* **The alarm sub-system malfunctions by sending out a false signal:** In normal settings, this can occur when the alarm component receives a wrong alarm notification. This is usually caused by the monitor software making a decision based on incorrect data from one of its input ports. The alarming system, on the other hand, can send false signals due to its internal failure for a variety of reasons such as poor internal configuration or simply aging.

* **The alarm subsystem has completely stopped working:** It is possible that the alarm system no longer works completely. This can be caused by several reasons; for example, the alarm system being physically disconnected, or internal failure which causes a total black-out.

* **The monitor is displaying incorrect data:** As it is obvious, the main cause of this could be due to incorrect data being sent to the monitor. However, other factors, such as a faulty monitor, losing connection to the internet make it display the last received data, and so on. It should be noted that these are only generalized assumptions; the extensive individual study, as well as their corresponding failure rules, is shown in Table 7.4.

* **The monitor completely fails to display data on the screen:** This can occur due to internal and/or external monitor issues such as the monitor not being physically connected to the system power source, being unable to connect to the server, internal monitor malfunction due to aging, and so on. On the other hand, this could be caused by the monitor is properly connected but the server not receiving any data from the sensing unit.

The next step is to derive internal failure rules as well as the propagation rules for the basic components. For instance, for each sensor, two rules were defined to model two different scenarios in which a sensor can fail. A sensor can fail internally leading to a complete omission in providing the data to the output port, thus an "omission" failure will be propagated to the output port of the sensor. On another hand, a sensor can start to fail but not completely due to age. This may result in providing incorrect data to the output; this can also be caused by sensor components that are not properly placed in the patient's body. In this case, we consider that the value sent to the output port is of "valueCoarse" type. Hence the two different types of failure can be propagated to the same output port in a different scenario, and they will be represented as indicated in Expression 8.1 and 8.2 respectively. We considered only the two failure conditions to apply for all of the sensors. As it can be seen from Table 7.4, a detailed set of failure behavior rules and their description are represented.

$$FLA : (*) \rightarrow ecgsens\_out.omission \qquad (7.6)$$

$$FLA : (*) \rightarrow ecgsens\_out.valueCoarse \qquad (7.7)$$

In CHESSIoT, to facilitate the quantitative analysis, the failure rates of the component internal failure events as well as the injected failures events have to be set separately. As we did not have the exact failure rates of the basic components, we considered the arbitrary failure rates of any component to be practically small in a range of $10^{-8}$ to the $10^{-7}$. Figure 7.11 depicts the interfaces in which the internal failure and their description are set. Having the event description is practically good in order to facilitate the readability of the FT, but it is not mandatory to have it for performing qualitative analysis. When no data is provided to any of the rows, the default values are used. For instance, an unset basic event probability is assigned with a value of zero in the FT, while the unset basic event description will still follow the conventional naming of "<failure type> at <port name> in <component name>".
<table><caption>Table 7.4: PMS failure behavior table</caption><thead><tr><th>Component</th><th>Rules</th><th>Description</th></tr></thead><tbody><tr><td rowspan="2">ECG, EEG, Temp, SPO2 and Pressure sensor</td><td>① FLA:(*) → ecg_sens_out.omission;</td><td>Sensor fails internally which make it unable to read and push any at output port</td></tr><tr><td>② FLA:(*) → ecg_sens_out.valueCoarse;</td><td>Sensors begin to fail as they age and provide incorrect data to the output; this can also be caused by sensor components that are not properly mounted to the patient body.</td></tr><tr><td colspan="2">Rules ① and ② apply to other sensors</td><td>Same as other sensors</td></tr><tr><td rowspan="12">Controller</td><td>③ FLA:ecg_cont_in.noFailure,ecg_cont_in.noFailure → cont_trans_out.omission;</td><td>Controller fails completely omitting to send the data</td></tr><tr><td>④ FLA:mon_power_in.omission, trans_cont_in.omission → cont_trans_out.omission;</td><td>The controller fails to function due to a power outage at its input power port, no backup solution is available (trans_cont_in port)</td></tr><tr><td>⑤ FLA:ecg_cont_in.omission, eeg_cont_in.omission, press_cont_in.omission, spo_cont_in.omission, temp_cont_in.omission → cont_trans_out.omission;</td><td>All of the sensors simultaneously stop sending data, preventing the controller from sending any data to the server</td></tr><tr><td>⑥ FLA:ecg_cont_in.valueCoarse → cont_trans_out.valueCoarse;</td><td>The controller receives inaccurate data from the ECG sensor and sends it to its output port</td></tr><tr><td>⑦ FLA:ecg_cont_in.valueCoarse → cont_trans_out.valueCoarse;</td><td>Controller receives inaccurate data from the EEG sensor and sends it to its output port</td></tr><tr><td>⑧ FLA:press_cont_in.valueCoarse → cont_trans_out.valueCoarse;</td><td>Controller receives inaccurate data from the blood pressure sensor and sends it to its output port</td></tr><tr><td>⑨ FLA:spo_cont_in.valueCoarse → cont_trans_out.valueCoarse;</td><td>Controller receives inaccurate data from the SPO2 sensor and sends it to its output port</td></tr><tr><td>⑩ FLA:temp_cont_in.valueCoarse → cont_trans_out.valueCoarse;</td><td>Controller receives inaccurate data from the temperature sensor and sends it to its output port</td></tr><tr><td>⑪ FLA:trans_cont_in.valueSubtle → cont_trans_out.valueCoarse;</td><td>The controller receives an undetected error at its from-system port, which impede sensor data transmission.</td></tr><tr><td>⑫ FLA:trans_cont_in.valueSubtle → cont_trans_out.omission;</td><td>The controller receives an undetected error at its from-system port halting the data transmission process.</td></tr><tr><td rowspan="4">Transceiver</td><td>⑬ FLA:trans_in_fr_unit.valueCoarse → trans_out.valueCoarse;</td><td>The transceiver received wrong data and transmit to its output port</td></tr><tr><td>⑭ FLA:trans_in_fr_unit.noFailure,trans_in_f serv.noFailure → trans_out.omission;</td><td>The transceiver fails internally causing the halt of data transmission process</td></tr><tr><td>⑮ FLA:trans_in_fr_unit.omission → trans_out.omission;</td><td>The transceiver receive no data and fails to transmit any data to its output port</td></tr><tr><td>⑯ FLA:trans_in_f serv.valueSubtle → trans_o_2_unit.valueSubtle;</td><td>The transceiver receive an undetected errors at its server port and forwards it back to the sensing unit</td></tr><tr><td rowspan="4">Server</td><td>⑰ FLA:server_in.noFailure → server_out.omission;</td><td>The server fails, bringing the transmission process to a halt</td></tr><tr><td>⑱ FLA:server_in.valueCoarse → server_out.valueCoarse;</td><td>The server routes the incorrect data received at the input port to the output port</td></tr><tr><td>⑲ FLA:server_in.omission → server_out.omission;</td><td>The server receives no data from its input port, and this error is forwarded to its output port</td></tr><tr><td>⑳ FLA:serv_in_f mon.valueSubtle → serv_2_trans_out.valueSubtle;</td><td>The server sends an undetected error from the monitor back to the transceiver's port</td></tr><tr><td rowspan="5">Monitor</td><td>㉑ FLA:monitor_in.noFailure → monitor_out.omission,monsignalout.omission;</td><td>The monitor fails internally omitting to display the data on the screen as well as not communicating to the alarm component</td></tr><tr><td>㉒ FLA:monitor_in.omission → monitor_out.omission,monalarmout.omission;</td><td>The monitor receiving no data from the server omitting to display the data as well as not sending any communicating signal to the alarm component</td></tr><tr><td>㉓ FLA:monitor_in.valueCoarse → monitor_out.valueCoarse,monalarmout.commission;</td><td>The monitor receives inaccurate data and displays it on the screen, potentially sending an unexpected notification to the alarm component (Commission)</td></tr><tr><td>㉔ FLA:hum_mon_in.valueSubtle → mon_2 serv_o.valueSubtle,monalarmout.commission, monitor_out.noFailure;</td><td>The monitor receive an unpredicted error from the human nurse component, the failure propagates in the system in various ways with no direct effect on the data displayed on the screen before (Refer to Rules 30 and 31 for possible causes)</td></tr><tr><td>㉕ FLA:hum_mon_in.omission → mon_2 serv_o.valueSubtle;</td><td>The monitor receives no engagement from the nurse intended to resolve the issue in the system, the cause of which we do not know. As a result, such a failure will go unnoticed by the system. (Refer to Rules 11 and 12 for possible effects)</td></tr><tr><td rowspan="4">Alarm</td><td>㉖ FLA:mon_alm_in.commission → alarm_out.commission;</td><td>The alarm component received an inaccurate notification and immediately rings because it lacks any type of logical reasoning on the signal receiving other than ringing.</td></tr><tr><td>㉗ FLA:mon_alm_in.noFailure → alarm_out.commission;</td><td>The alarm starts failing due to internal failure which can make it malfunction by giving false alerts</td></tr><tr><td>㉘ FLA:mon_alm_in.noFailure → alarm_out.omission;</td><td>The alarm component fails completely which makes it unable to make any alert</td></tr><tr><td>㉙ FLA:mon_alm_in.omission → alarm_out.noFailure;</td><td>The alarm receive no data but that won't affect the internal functionality of the alarm component</td></tr><tr><td rowspan="2">Human nurse</td><td>㉚ FLA:human_in.late → human_out.valueSubtle;</td><td>The human nurse reacts very slowly in the event of a system failure, which may or may not affect the system in some way, which is why a "valueSubtle" is considered.</td></tr><tr><td>㉛ FLA:human_in.noFailure → human_out.omission;</td><td>The absence of the doctor results in an omission at the output port</td></tr></tbody></table>

As proved in the preceding discussion, our proposed approach is capable of satisfying all potential failure behaviors prescribed by the safety expert. As shown in Figure 7.10, our approach is capable of modeling the backward failure propagation pattern. For instance, a server failure will affect the monitor's behavior, preventing data from being displayed on the screen. On the other hand, an erroneous command sent by the doctor's absence (for example, to fix an unmounted sensor) may eventually propagate back to the sensing unit, causing a wrong value error to be transmitted at the controller output port (valueCoarse failure) or possibly suspending the data transmission process (omission failure). Well, it is also worth noting that the ability to integrate all of their component failure rules as well as their failure rates in the same model has the potential to boost model consistency as well as transparency in the modeling process.
<figure><img src="image_48.png" /><figcaption>Figure 7.11: PMS components failures rates set</figcaption></figure>

### 7.4.4 PMS Fault tree analysis (RQ4)

RQ4: Does the proposed FT qualitative and quantitative analysis improve the existing FT analysis techniques?

The FT analysis begins after the CHESS-FLA transformation, as described in Section 2. The FT generation process is performed prior to running the FT analysis, in which each of the top events described in Section 4 results in its own FT. For instance, FT leading to an "omission" failure at the system monitor out port is generated to show the entire failure contribution leading to that top event. Other FT representing the remaining 3 top events are generated as well. At this stage, the generated FTs are very large as they contain every detail related to failure propagation and transformation from component to component, making it tricky to read. Therefore, FT analysis can then be launched to automatically perform both qualitative and quantitative analysis on the model.

Figure 7.12 shows the analyzed FT of the event "the monitor fails to display data completely on the screen". The presented FT showcases only the important events and logical gate combinations. It can be clearly anticipated that the analyzed FT makes it easier to identify and trace any failure source events in their contribution to the top failure event. For instance, we can easily grasp that the monitor would display no data on the screen completely when any of the following events occur:

* Internal failure in the monitor ($10^{-8}$ probability)

* Server is down ($2 \times 10^{-8}$ probability)

* The transceiver (gateway) fails completely to transmit the data ($3 \times 10^{-8}$ probability)

* A combination of events (low-left AND gate) in which there is a problem with the sensing unit power source and there is no person to fix that at the moment. ($5 \times 10^{-15}$ probability)

* The controller of the sensing unit fails completely which halts the transmission process ($1.2 \times 10^{-8}$ probability)

* An event in which all the sensor does not send the data at all (This is more unlikely but possible, that's why we have a lower-middle and gate combination with $2.088 \times 10^{-38}$ probability).

* An unknown human error occurred from the monitor side ($2 \times 10^{-7}$ probability)

When the event of the monitor not displaying any data occurs, medical personnel can rely on such a narrow series of events to determine the cause of the event. Furthermore, medical personnel can use the probability associated with each basic event in the list to quickly locate the source of failure, moving from the most probable basic event (highest probability) to the least probable event (lowest probability).
<figure><img src="image_49.png" /><figcaption>Figure 7.12: PMS monitor screen shown no data</figcaption></figure>

probability). The overall probability of this system-level failure event occurring is calculated to be $2.72 \times 10^{-7}$, which is practically small, however, this value is calculated automatically and is solely dependent on the arbitrary basic event failure rates as well as their logical combination analysis, as shown in the FT.

Other analyzed FT on the event in which "monitor displaying incorrect data" and "PMS alarm sub-system alert false signal" is shown in figure 7.13 and 7.14 respectively. As it can be seen from figure 7.13, the event in which the monitor will display incorrect data can be caused by any of the sensors (OR gate), as well as an unforeseen human error that transforms throughout the system and hinders the data that are being transmitted. The overall probability in which such an event can occur is calculated to be about $3.39 \times 10^{-7}$ which is higher than the event in which the monitor can stop working a all.
<figure><img src="image_50.png" /><figcaption>**Figure 7.13:** The monitor fails to display data completely on the screen</figcaption></figure>

On the other hand, as shown in Figure 7.14, the same events that cause the monitor to display incorrect information can also cause the monitor to send a false signal via a failure transformation, resulting in a false alarm event in the alarm system. It is also worth noting that an event like the alarm sub-system failing with a probability of $4 \times 10^{-8}$ would also contribute to that cause. The overall probability of such an event to occur is projected to be around $5.79 \times 10^{-7}$ which is much higher than the previous two top events. Furthermore, while the "Human error" basic event appears twice in the tree, such failure passes through different channels and eventually transforms into other types throughout the system. This is practically important to understand which component of a system's error would change its nature, potentially causing a lot more damage than expected. Finally, It is worth noting that this FT does not include the top event in which the alarm sub-system stopped working completely. An FT reflecting such an event was generated and analyzed separately.

Typically, safety engineers will collaborate with system engineers to keep the safety model up to date during the development process. Maintaining coherence between system architecture and the safety model can be difficult as the model gets larger and more complicated. Having a framework that can integrate modeling and analysis processes from a single place would potentially improve consistency, and transparency, and minimize analysis time. Overall, the proposed analysis approach is capable of achieving that by the means of automated qualitative and quantitative calculus.
<figure><img src="image_51.png" /><figcaption>Figure 7.14: Alarm sub-system alert false signal</figcaption></figure>

## 7.5 Conclusion and future work

Automated safety analysis is critical for increasing transparency and reducing the time required for manual analysis. However, when the system becomes too large and complex, it is very difficult to maintain the coherence between the safety analysis model with the corresponding system architecture. In addition, the architecture usually has to be reworked so many times, which can hinder the consistency of the process. This chapter presented CHESSIoT, a novel approach for developing and performing safety analysis on safety-critical IoT systems. The proposed method combines rigorous automated analysis procedures with annotated failure behavior on components and associated failure
rates to generate fault trees. The supporting tool can perform both qualitative and quantitative analysis on generated FTs. We presented an evaluation mechanism compared to existing techniques to showcase its novelty, and the results were very promising. The approach improves model composability and reuses while reducing the time required to perform the analysis. In the future, we want to integrate time-based failure logic analysis into our analysis approach if a given failure would only affect the system for a short period. Furthermore, we plan to investigate the feasibility of combining with Markov chain analysis land/or dynamic fault tree analysis using Monte Carlo simulation when performing the quantitative FT analysis.
# Chapter 8

## Supporting for development and deployment of IoT systems with CHESSIoT

Engineering tools that can handle this complexity while also reducing the development time will undoubtedly have a massive impact on the market. As a contribution toward answering the fifth research problem (RP5), this chapter present the CHESSIoT development and deployment approach as a part of the whole CHESSIoT-supported engineering process. In addition to the already presented safety analysis support in Chapter 7, CHESSIoT integrates high-level visual design languages, software development, and deployment mechanisms. Additionally, the tool offers means to define run-time service provisioning modules through deployment agents, which are then used to configure remotely deployed services. To showcase the effectiveness of our proposed approach, as well as the capability of the supporting tool, a Home Automation System (HAS) example was developed, covering the modeling, development, safety analysis, and deployment views.

**This chapter is organized as follows:** Section 8.1 presents a brief introduction to the topic. Section 8.2 presents CHESSIoT software development methodology and code generation process. Section 8.3 present the deployment methodology as well as the run-time service provisioning modeling approach. Section 8.4 presents a Home Automation System running example showcasing the capabilities of the proposed supporting tool. Finally, Section 8.5 concludes the chapter.
8.1 Introduction

Model-driven development and deployment of IoT systems is a challenging task that requires
comprehensive and flexible support. With the increasing complexity of IoT systems, model-driven
approaches have become a popular solution to enable efficient development and deployment [235].
These approaches use models to represent the structure and behavior of IoT systems and automate
the development and deployment process. During the modeling phase, developers create models that
capture the requirements, architecture, and behavior of the IoT system. These models are then used
to perform analysis, such as simulation and verification, to ensure that the system meets the desired
specifications [68]. Furthermore, developers use the models to generate code that implements the
system’s functionality. The code is then tested to ensure that it works as intended, and the system is
finally deployed to the target environment.

However, MDE in IoT systems poses unique challenges, such as heterogeneity of devices and com-
munication protocols, dynamic and unpredictable environments, and the need for real-time response
[86]. To address these challenges, there is a growing need for tools and frameworks that support
MDE for IoT systems. One promising approach is to use domain-specific languages (DSLs) that are
tailored to the specific requirements of IoT systems [71]. DSLs provide a higher level of abstraction
than general-purpose modeling languages, enabling developers to create models that are closer to the
problem domain. Moreover, DSLs can be used to generate platform-specific code, making it easier to
integrate with IoT platforms and devices [37].

In addition to that, efficient and scalable deployment of IoT systems is also critical for the success
of IoT applications. Deployment of IoT systems involves a wide range of tasks, including configura-
tion, provisioning, monitoring, and maintenance of devices and services [17]. To support efficient and
scalable deployment, there is a need for tools and frameworks that automate these tasks, and enable
seamless integration with IoT platforms and infrastructure. In particular, the deployment of IoT sys-
tems involves several challenges, such as managing the heterogeneity of devices and communication
protocols, dealing with resource constraints, and ensuring the reliability and security of the system
[166].

To address these challenges, there is a need for tools and platforms that support the model-driven
deployment of IoT systems. These tools should provide a high-level abstraction of the system by en-
abling developers to focus on the system’s deployment requirements. They should also support the
automatic generation of deployment artifacts, such as configuration files, scripts, and Docker contain-
ers, based on the models of the system [223].

As introduced in Chapter 6, CHESSIoT integrates the modeling, software development, analysis, and deployment for engineering multi-layered IoT systems. In this chapter, we demonstrate in great detail CHESSIoT’s development and deployment approach in addressing some of the potential challenges presented above. Concerning software development, CHESSIoT provides the user with means to define a functional model which contains the system’s key software components, subfunctions, and interrelationships. Furthermore, a behavior model is entitled to each of the system’s main sub-function in form of a state machine in which aspects such as events, actions, and guards are associated with states and their transitions to realize the desired behavioral goal. When the model is complete, a CHESSIoT2ThingML model transformation is launched to generate a series of fully functional ThingML source models which is then used to generate platform-specific code ready to be deployed on low-level IoT devices.

In addition to that, The CHESSIoT includes a deployment environment that aims at supporting the
users with decomposing the IoT system deployment plan as well as managing deployed node services
across all layers. As a matter of fact, IoT services are no different from other domains their deployment
should also follow a multi-tenant approach in which a single service instance should be running on the
host servers, and that single instance serves each subscribing customer or cloud tenant [236]. Runtime
service provisioning refers to the process of allocating and configuring resources, such as computing
power, storage, and network connectivity, at the time a program or application is run [237].

In runtime service provisioning, resources are dynamically allocated based on the needs of the
program or application at any given time. Mastering a variety of deployment languages can be tough
and not to mention the tight coupling between the script being used and the environment they are
intended to apply to. But always the question remains "Should really the deployment plan change
every time the target environment changes?"

To potentially address such a problem, CHESSIoT offers a model-driven runtime service provi-
sioning environment that allows the automatic configuration of software services based on a prede-
fined model. The CHESSIoT provisioning abstraction is defined using deployment scripts referred to
as agents. These agents are annotated to the deployment nodes in the model, to provide run-time mon-
itoring of the deployed services. A textual language for defining deployment rules is used to describe
the agents' behavior. These rules will eventually be transformed into Ansible deployment playbook
scripts [224] that can be run manually on a remote machine. To evaluate the proposed approach as well
as showcase the capability of the tool, we have demonstrated a Home Automation System (HAS) use
case in which we used the tool for modeling, developing, conducting safety analysis, and supporting
its deployment.

8.2 Software modeling and development approach

Software design and development is the process of creating and implementing software systems and applications. The software design phase involves creating high-level conceptual models of the system, identifying key components and interfaces, and defining the overall software architecture. CHESSIoT follows a multi-view design paradigm, the software design is done under the "Component View" to enable users to design functional and behavioral aspects of the software's edge layer.

In CHESSIoT, the user benefits from a dedicated IoT-specific graphical modeling environment consisting of specific diagrams and palettes that are hidden or shown based on the current design step via the "IoT sub-view". Having such a sub-view enables CHESSIoT to be a completely decoupled environment from CHESS, which is relevant throughout the whole design process. Figure 8.1 shows the support of the complete design and development phase.

<figure><img src="image_52.png" /><figcaption>Figure 8.1: Software development process</figcaption></figure>

The software development process initiates with the user creating functional and behavioral mod-
els that conform to the software metamodel shown in Fig. 6.3. Once the model reaches its final form,
a transformation called CHESSIoT2ThingML is executed to generate ThingML model files. These files can then be utilized within the ThingML environment to generate platform-specific code that is ready for deployment on devices. Alternatively, the functional model can be expanded to incorporate real-time properties, enabling real-time analysis to be conducted. This section does not delve into the runtime analysis, as it has already been covered in the work presented in [42]. However, it does provide specific details regarding the design strategy and code generation approach supported by the CHESSIoT tool.

## 8.2.1 Specification of CHESSIoT software models

In CHESSIoT, the modeling of software components is closely intertwined with the definition of their behaviors, ultimately resulting in the generation of platform-specific code. The software design approach encompasses both the functional design and behavioral design aspects of the system. The functional design entails a systematic definition of the primary software components, their sub-components, and their interconnections. This process employs *component structure diagrams* that adhere to a component-to-connector design methodology [37]. During this stage, communication between components is exclusively facilitated through dedicated ports utilizing payload entities. For designing systems that involve wireless communication, such as MQTT-based systems, a special port with an MQTT stereotype is utilized. This MQTT port captures all MQTT-related information, including the broker URL, client type, and topic.

When modeling the internal behavior of a component, internal class diagrams are used, where only specific palette elements are displayed to the user at this stage. Each main sub-function of the system is assigned its own state machine, which encompasses events, actions, and guards associated with states and transitions to achieve the desired behavioral objective. Figures 8.2 and 8.3 presents the high-level mechanisms that are followed during the definition of the component's state machine as well as the event, action semantics definition process. For instance, according to Figure 8.2, an event can be categorized as either an *Internal event* or a *Conditional event*. The event references the payload values found at the corresponding port for verification. When an event is triggered, it initiates an action, which can be either a *SetAction* or a *GenericAction*, depending on the context.

A *SetAction* always sends a *Payload* through a given port, while a generic action would mostly be customarily implemented. A guard which enables a state transition based on the *OnExit* action status or can be customarily implemented. Such a condition is added to the code unchanged during the code generation. A combination of such events and actions is referenced throughout different states and transitions accordingly. Figure 8.2 depicts the basic activities that need to be fulfilled from one state to the other.

<figure><img src="image_53.png" /><figcaption>Figure 8.2: Behavior event & action relationship</figcaption></figure>

Figure 8.3 depicts the general idea behind the basic state-based behavior process supported by our approach. The diagram illustrates an example of two states, i.e., *S1* and *S2*, and the requirements and
activities that must be met to perform the transitions among them. Moreover, when leaving a state,
zero or more *OnExit* actions might be fulfilled. This is defined within a state and will be checked using
the guard expression.

<figure><img src="image_54.png" /><figcaption>**Figure 8.3: State and state transition**</figcaption></figure>

Conditional events must be attached to state transitions when moving from one state to another. Furthermore, zero or more *onEntry* actions may be performed when entering a state. An internal event is used within a state to trigger actions of interest. It is important to note that at this point, a conditional event always inspects the payload state at the ports to initiate a state change.

8.2.2 The CHESSIoT to ThingML transformation

The CHESSIoT2ThingML transformation process is done through model text transformations written in Accelleo<fnref n="1" />. Acceleo is an open template-based source code generation technology developed in the context of the Eclipse Foundation. In this section, we will delve into the details of ThingML and the steps involved in generating ThingML models from CHESSIoT models.

**What is ThingML?** ThingML is a model-driven development and code generation framework which combines a textual modeling language and a set of compilers targeting a range of different platforms (from micro-controllers to servers) to generate ready-to-use platform-specific code. ThingML code generators support the generation of three main languages (C/C++, Java, and JavaScript) and several libraries and open platforms (Arduino, Raspberry Pi, Intel Edison, Linux, and so on) [235].

The ThingML approach targets distributed reactive systems and is especially beneficial for applica-
tions that include heterogeneous platforms and heterogeneous communication channels. In ThingML,
a Thing is an implementation unit, also referred to as a component or process. It can define properties,
functions, messages, ports, and a set of state machines [37]. All the properties are local variables and
can be accessed globally from within a thing through a function or a state machine. Same as prop-
erties, the functions are also local to a thing, and they can be used from anywhere in a thing. Same
as CHESSIoT, things can be interfaced with other things through the ports employing sending and
receiving a set of messages.

The ThingML language relies on two key structures: *Thing*, which represents software compo-
nents, and *Configurations*, which describe their interconnection [37]. During the CHESSIoT2ThingML
transformation, the generation of those two main sets of code is done separately, as described in the
next sections. Over the years, the ThingML approach has continuously evolved and applied to cases
in different domains, including commercial e-health applications such as fall detection systems called
Safe@Home [235], Micro-aerial vehicle platform as well as the Arduino Yùn IoT-based projects [37].

CHESSIoT to ThingML generator: The CHESSIoT component’s semantics differ from the ThingML,
which is why mapping the elements is needed to solicit an efficient transformation. In the following,
we discuss how the different CHESSIoT modeling constructs contribute to generating target ThingML
elements. As shown in Figure 8.4, the transformation process starts from the top-level generation of
main software components such as *VirtualElement*, *VirtualBoard*, *VirtualEntity*, *Sensor* and *Actuator*
as the main building blocks elements. Each of those components is mapped to a ThingML thing.
Each of these types undergoes a dedicated transformation route based on relevant semantics found in

<footnote n="1">¹https://www.eclipse.org/acceleo/</footnote>
the model and its typical properties to satisfy its existence in the entire ecosystem. When the transformation finishes, the tool generates CHESSIoT code licenses, the ThingML dependencies such as ThingML *DataTypes*, and *Times*. In general, Table 8.1 depict the CHESSIoT2ThingML transformation mappings implemented by the developed CHESSIoT to ThingML code generator.

<figure><img src="image_55.png" /><figcaption>**Figure 8.4:** High-level transformation steps</figcaption></figure>

<table><caption>**Table 8.1:** CHESSIoT2ThingML transformation mapping</caption><thead><tr><td>CHESSIoT element</td><td>ThingML element</td></tr></thead><tbody><tr><td>VirtualElement, Virtual-Board, VirtualEntity, Sensor, Actuator</td><td>Thing</td></tr><tr><td>IoTPort</td><td>Provided/required port</td></tr><tr><td>Component's property</td><td>Thing's property</td></tr><tr><td>Component's operation</td><td>Thing's function</td></tr><tr><td>Payload</td><td>Message</td></tr><tr><td>Set of Payloads</td><td>Fragment</td></tr><tr><td>IoTState/Transition</td><td>State/Transition</td></tr><tr><td>IoTGuard</td><td>Guard</td></tr><tr><td>IoTEvent/Action</td><td>Event/Action</td></tr></tbody></table>

IoTPorts are used to support the communication between two or more components by exposing or requiring the interfaces from other components. During the transformation, IoTPorts of the components are transformed to the required/provided port of a ThingML's thing. Deciding on whether a given port is a required port or provided port depends on the desired direction of communication, and this can be specified in the language itself. Same as in ThingML, properties are used to retain the variable functional value of a Thing, in which during the transformation, the component's property is
transformed to thing's property.

Payload elements are mapped to Message ones in the ThingML model. For each component, all the payloads that it defines are collected into one ThingML element called a Fragment. The payload can have zero or many primitive or derived properties to be defined in a message. For instance, suppose a component message to be communicated among components contains a string value, an integer, or even an instance of another payload. In this case, a payload will include three different attributes, represented as message arguments in ThingML. Figure 8.5 depicts a fragment of the Payload fragment generator.

<figure><img src="image_56.png" /><figcaption>Figure 8.5: Payload generation process</figcaption></figure>

<figure><img src="image_57.png" /><figcaption>Figure 8.6: State machine generation process snippet</figcaption></figure>

IoTState elements are mapped to instances of *ThingML state*, same goes for *State transition* that will also be mapped to their corresponding transition provided by ThingML. As shown in Figure 8.6, the state-chart transformation process as a core is one of the complex generation processes in the
whole transformation process, and it involves two main steps. First, the generation of the internal state behaviors such as *OnEntry* action, internal events, and the *OnExit* actions. The Second step of the generation process involves generating the state transitions. This stage involves the generation of conditional events to be attached to the state transitions. In certain cases, the guards associated with these transitions are also checked for potential effects and transformed accordingly. Once the generation of Things is completed, the final task is to generate the configuration files, which encompass the instances of Things and their connections. This process aligns with a component-to-connector methodology, following the internal structure of the nodes. The above-mentioned transformation process only occurs when the corresponding behaviors have been specified and are present in the CHESSIoT model. For instance, not every system will necessarily have all three internal state behaviors present at all times.

## 8.3 Model-based deployment plan and run-time services provisioning

The deployment plan refers to the steps involved in planning and implementing the deployment of a software system or application. This can include identifying and specifying hardware and software requirements, determining the most appropriate deployment architecture, and creating a detailed deployment plan that outlines the specific steps and resources needed to deploy the system successfully. Docker<fnref n="2" /> and Kubernetes<fnref n="3" /> are two popular technologies used in modern software development and deployment. While Docker provides containerization capabilities, Kubernetes is an orchestrator for managing containerized applications.

Ideally, the software components of a typical IoT system can be deployed in the Cloud, at the Fog layer, and the Edge of the network. Designing the deployment plan of such a complex and heterogeneous system has to consider several aspects and be aware of different satisfactory requirements [223]. In fact, as in other domains, IoT software services need to follow a multi-tenant approach in which a single service instance should be running on the host servers, and that single instance serves each subscribing customer or cloud tenant [236].

IoT systems interact with humans and are always at the intersection between human survival, for instance, in the healthcare and transportation domains. As such, monitoring, reviewing and managing deployed services is necessary to avoid any operational mistake in the IoT cloud-based infrastructure. The CHESSIoT deployment environment aims to support the users in decomposing the IoT system deployment plan and managing deployed node services at all layers. The overall deployment design is depicted in Figure 8.7. Alongside the design of the deployment model, the environment also offers support for specifying deployment rules using textual grammar. This enables the expression of mechanisms to monitor the life cycle of deployed services through deployment agents.

This section comprises three parts. First, in Sec. 8.3.1, we present the approach for designing the deployment plan. Second, in Sec. 8.3.2, we delve into the design approach for service provisioning. Finally, in Sec. 8.3.3, we describe the approach for generating deployment artifacts.

### 8.3.1 Deployment plan design

In CHESSIoT, the deployment design showcases the physical hardware architecture for running IoT software services. It links the software architecture design to the real system architecture, outlining the nodes where the software program will be executed. The *Deployment view* allows users to break down the inter-dependency between different nodes, which may include a machine with one or multiple services running on it. The goal of this process is to generate ready to be deployed Docker compose files for each of the machines at a certain node.

The design process, illustrated in Figure 8.7, commences with the user defining the system's deployment model. This model, which aligns with the metamodel discussed in Sec. 6.4.3, primarily focuses on the interconnections between computing nodes, machines, and the IoT services they host.

<footnote n="2">²https://www.docker.com/</footnote>

<footnote n="3">³https://kubernetes.io/</footnote>
<figure><img src="image_58.png" /><figcaption>**Figure 8.7: Deployment design process**</figcaption></figure>

Nodes play a crucial role in the entire design process, as they not only encompass the computing machines but also bear the responsibility of hosting deployment agent annotations. The inclusion of machines in the process serves to enhance the decoupling of how and where IoT services are deployed.

The definition of the deployment concrete syntax model is achieved by using the Papyrus modeling editors. A deployment context model was developed and used to create an IoT-specific deployment editor, which it easy to define element properties, inter-connection, and their intra-compositions using a rich editor. CHESSIoT context model in 8.8 primarily defines tabs, views related to the selected element, and a section as part of a view related to a given tab. The section includes the element's direct representation as a widget and a layout. Depending on the layer at which a node is, services deployed at the same layer or not could communicate between themselves. For instance, an MQTT client running on the device layer need to know the address to which a fog MQTT server is running to better communicates and vice versa.

The communication relationship between nodes can be explicitly indicated at the node level as well as down to the service itself. As previously mentioned, services could have a dependency relationship between themselves. This relationship is critical when determining the startup and shutdown dependencies between services. For instance, when running Apache Kafka in a distributed mode (i.e., with multiple brokers forming a cluster), ZooKeeper <fnref n="4" /> is typically required to provide highly reliable coordination and synchronization for such distributed systems. In this case, Apache Kafka will have a dependency relationship to ZooKeeper in the deployment plan model. Hence, during the docker-compose file generation process a *depends_on* value is used and it is set to the corresponding service following the service-to-service dependency relationship it applies to (in our previous case "ZooKeeper"). Finally, the *service priority* property is used when determining the order in which individual service configurations are generated as well as their run-time prioritization later in the event of a machine memory shortage.

<footnote n="4">⁴https://zookeeper.apache.org/</footnote>
<figure><img src="image_59.png" /><figcaption>Figure 8.8: CHESSIoT context model</figcaption></figure>

8.3.2 Service provisioning design

There are different ways to achieve runtime service provisioning, one of them is by using con-
tainerization technology. Docker and Kubernetes technologies enable users to package an application
along with its dependencies into a container. This containerization approach facilitates the manage-
ment of deployment, scalability, and runtime monitoring of these applications. However, in the present
software deployment landscape, many runtime service provisioning approaches still rely on workflow-
driven methods that utilize scripts and follow well-defined deployment steps. Mastering multiple de-
ployment languages can be challenging, and there is a notable issue of tight coupling between the
scripts and the specific deployment environments they are intended for. But always the question re-
mains "should the deployment plan change every time the target environment changes?"

To address this challenge, the CHESSIoT approach utilizes a model-driven strategy for handling
runtime service provisioning. This involves the automatic configuration and deployment of software
services based on a pre-defined model. The runtime provisioning notations model integrates all the
essential information about a specific type of action required at runtime, including its dependencies,
requirements, and configuration settings. This information is presented in the deployment model,
which includes nodes, machines, and deployed services. Depending on the client's needs, the model
can be translated into any target configuration language for the desired environment. The abstract
syntax for the service provisioning language is illustrated in Figure 8.9.
<figure><img src="image_60.png" /><figcaption>Figure 8.9: Service provisioning metamodel</figcaption></figure>

<table><caption>Table 8.2: CHESSIoT2Ansible transformation mapping</caption><thead><tr><th>CHESSIoT element</th><th>Ansible element</th></tr></thead><tbody><tr><td>DepPlan<br/>- Name</td><td>PlayBook<br/>- PlayBook filename</td></tr><tr><td>AbstractAgent<br/>- Description</td><td>Play<br/>- Name</td></tr><tr><td>Rule<br/>- Name<br/>- Arguments<br/>- MachineName</td><td>Module<br/>- Name<br/>- Arguments (depends on rule)<br/>- HostName<br/>- HostAddress (from the inventory)</td></tr><tr><td>Set of rules</td><td>Task</td></tr></tbody></table>

To support the easy deployment and run-time service provisioning of the deployed services, CHESSIoT provides a textual grammar to express the means for monitoring the life-cycle of the deployed containers. At each node, a deployment plan is annotated, consisting of a collection of expressions. These expressions take the form of deployment agents, where each agent specifies a series of one-time actions to be executed on a remote machine’s configuration. These activities are aimed at facilitating the deployment and provisioning of services.

As the Agents are attached to the nodes, their expressions are meant to be directly dependent on the number of machines running at such nodes, their names as well as their addresses. In practice, a deployment agent could extend another one to better avoid rewriting rules over and over in case the same or even with some additional run-time actions are applied from one machine to the other.
In addition to that, the rules which are meant to express the runtime actions that are meant to be
performed on the machine are the only target "services" they are intended to support. Please note that
the following rules are intended to support the services that have been already defined in the previous
deployment model as well as other dependencies or supporting services that could be of interest to the
efficient deployment and runtime service provisioning of a given system.

An example of run-tine service provisioning definition is depicted in listing 8.1. The Create rule takes into account the service name and the machine name; it is meant to create and install a containerized service at a given machine server. Start/Stop/Re-start rules are meant to start, stop, and re-start an already created or existing service, respectively. The Log rule is intended to capture either the machine logs at which the target service is deployed or the deployed service logs itself depending on the developer’s needs. If needed, the location of the log file for the root directory as well as the filename can be defined. The Re-deploy rule is intended to recreate and restart a service on a given machine. The Re-runAgent is meant to re-run all the rules that are encapsulated in a given agent.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

DepPlan:Setup{
    setup:true
}

DepPlan:Name1
{
    re-use-plan:Setup
    agent: newAgent1{
        Description: "This is a first agent"
        RULE: create=> "Service_name" on: "Machine_name"
        RULE:start=> "Service_name" on: "Machine_name"
        RULE: log=> "Service_name" log_type: machine
        filename: "Filename" location: "Filename"
        on: "Machine_name"
    }
}

DepPlan:Name2{
    agent: newAgent2 {
        Description: "This is a second agent"
        RULE:stop=>"Service_name"on:"Machine_name"
        RULE:re-deploy=>"Service_name"
        log_type: machine
    }
    agent: newAgent3 extends newAgent2{
        Description: "This is a third agent"
        RULE:log=>"Service_name" log_type:service
        filename: "Filename" location: "Location"
        on: "Machine_name"
    }
}

DepPlan:Name3{
    re-use-plan:Name1
    agent: newAgent4 {
        Description: "This is a fourth agent"
        RULE:re-runAgent=> newAgent1
    }
}

<caption>Listing 8.1: Run-tine Service provisioning definition example</caption>

8.3.3 Deployment artifacts generation

When the whole deployment plan design, as well as its service provision annotations, are finished,
the user can perform the deployment artifacts generation through a series of model-to-text transforma-
tions. The two main types of transformations take generate different configuration files for two main
tasks. First, by following the deployment metamodel presented in Sec. 6.4.3 and the concepts in Sec.
8.3.1, each node is transformed into a series of docker-compose files targeting each of the machines.
A Docker-Compose file<fnref n="5" />, usually named `docker-compose.yml`, is used to configure the application's services, networks, and volumes. During the transformation process, each machine is allocated its `docker-compose` file which contains the `docker` set-up information of each service hosted by such machine. Depending on the nature of the service, another dependency file could be generated and placed in the same folder to fully satisfy the run-time requirements (e.g., security and storage).

<figure><img src="image_61.png" /><figcaption>**Figure 8.10:** Deployment artifact generation (Acceleo)</figcaption></figure>

Figure 8.10 depicts a fragment of CHESSIoT to .yaml translation code written in the Acceleo M2T transformation language. During the transformation, each service type goes through a separate transformation path before being added back to the parent configuration file. For example, if a service is of the type "Broker" and the anonymous access mode is set to false, different security-related files such as passwords are generated according to the user definitions. When the `docker-compose` configuration files generation is finished, the next step is to generate the Ansible script based on the service provision agents specified.

Ansible<fnref n="6" /> is a powerful, flexible, and user-friendly tool designed for automating various infrastructure tasks, executing ad hoc commands, and deploying multitier applications across multiple machines [224]. Its simplicity lies in the usage of human-readable YAML templates, known as playbooks. With Ansible, users can easily program repetitive tasks to be executed automatically, without the need for advanced programming knowledge.

In the right-hand side of Figure 8.7, the generation of Ansible scripts involves three main components: set-up scripts, inventory, and playbook scripts. The set-up scripts are responsible for tasks such as installing and configuring Docker (if it is not already installed), updating the Ubuntu system, and performing other necessary setup actions. These scripts are typically used on cloud nodes. On the fog layer, the set-up process varies depending on the operating system running on the machines. Different mechanisms for basic setup and upgrades are employed based on the specific operating system requirements. The next files to be generated are inventory files which define the managed nodes

<footnote n="5">⁵https://www.docker.com/</footnote>

<footnote n="6">⁶https://www.ansible.com/</footnote>
to be automated. The host data from the deployment model are drafted to create the inventory file. The inventory file is created with groups of different machines and addresses so that the user can run automation tasks on multiple hosts at the same time. The creation of the inventory groups will be based on each deployment agent attached to the node. The Ansible playbooks are generated next.

*Ansible Playbooks* are sets of automated operations that need to be executed by the hosts on a remote server. They use several "*plays*" to manage multi-machine deployments on one or more hosts. Ansible Playbooks are frequently used to automate IT infrastructures, including networks, security systems, operating systems, and Kubernetes platforms. One or more *Ansible tasks* might be combined to make a *play*. A *Modules* have a specific activity to complete within a task. Each module contains metadata that identifies the user, the location, and the time and place at which a task is completed. During the transformation, the mapping in Table 8.2 is duly followed.

## 8.4 Case study: Home Automation System (HAS)

To demonstrate the capabilities of our tool, we conducted a case study on a Home Automation System (HAS), utilizing both the tool itself and the methodology described in this paper. In Section 8.4.1, we present the safety analysis of the system. Section 8.4.2 focuses on the system development, specifically addressing the modeling and code generation aspects. Lastly, in Section 8.4.3, we discuss the system deployment and the runtime service provisioning aspects.

The Internet of Things (IoT) has experienced significant market growth in sectors like industrial automation, healthcare, and transportation. As technological advancements continue to permeate various aspects of our lives, home automation is gaining increasing attention. A Home Automation System (HAS) is a technological solution that enables users to remotely control different aspects of their homes, including lighting, heating, appliances, and security, using smartphones or other devices. These systems typically combine software and hardware components, such as sensors, to automate various tasks and functions within the home. While home automation systems primarily serve energy-saving purposes, some also cater to the needs of elderly or disabled individuals, facilitating their interaction with home appliances. Figure 8.11 provides an overview of the high-level structure of the system implemented in this study.

With the scenario in mind, we could potentially explain our motivating example:

> John is a software engineer and homeowner who works at a bank 40 minutes away from his home. John has installed a home automation system to control his house remotely while he is away for work. His house has many rooms, but we just consider two for simplicity. The major components he seeks to automate in a room are an air conditioning unit (AC), a light bulb, and double-hung windows. This will primarily be dependent on temperature sensor readings installed in each room, and based on that, the AC should switch on and off automatically, as will the window open and close down. Depending on his preferences, he can remotely turn on and off the light bulb as well as other appliances using his smartphone, regardless of sensor readings. The system board installed in the room is wirelessly connected to a RaspberryPi gateway, which interfaces the room system appliances with his Android phone's application. Finally, he can use his own PC at work to remote interface with his home system.

### 8.4.1 HAS modeling and Fault-Tree analysis

In the Home Automation System (HAS) example mentioned earlier, a temperature sensor is utilized to collect temperature values within the home. Based on these readings, the system can automatically perform certain actions, such as controlling the AC or adjusting the windows. Additionally, the system allows users to remotely control the light bulbs and windows regardless of the sensor data. Figure 8.12 illustrates the internal physical architecture of the system. For simplicity, we have depicted only two rooms and have assumed that the window actuation is directly connected to the window and represented by the servo motor. We have not accounted for alternative designs that incorporate electrical and mechanical configurations that could impact the physical functionality, such as appliances
<figure><img src="image_62.png" /><figcaption>**Figure 8.11: Home Automation System**</figcaption></figure>

requiring high power (e.g., window motors). Such considerations are beyond the scope of this study.

Figure 8.12 illustrates the power supply configuration of the system, where a single battery source supplies power to the two rooms independently. The two room components communicate individually with a central gateway. The server hosts the necessary software services for data storage, processing, and accessibility by authenticated parties. Users can access these services remotely through active devices such as mobile phones or PCs, which display the relevant information on their screens. In the event of abnormal sensor readings that exceed or fall below certain thresholds, the system may automatically trigger actions such as turning on/off the AC or opening/closing the windows. Moreover, the system should be capable of sending notifications to the user regarding any unusual room conditions. For example, John can view the displayed data on his phone or PC and choose to manually override the system's decisions by forcibly opening the windows or turning on the AC, disregarding the sensor readings.

As stated, the above system is vulnerable to several types of failures, usually generated by the system or caused by the surrounding environment. It is essential to model the failure behavior of individual components, which could be used to establish the failure behavior of all subsystems or a whole system. It is crucial to note that we do not focus on software-level functional behavior, but rather on hardware failure behavior that users could understand. To grasp the requirement for the
<figure><img src="image_63.png" /><figcaption>Figure 8.12: Home Automation System internal diagram</figcaption></figure>

conducted analysis, let us first review the several top failure scenarios that we believe could occur at the system's output port, such as the phone or the PC.

1. Phone/PC displaying wrong data: This can happen at any time the data received from the server is wrong with regards to the actual data to be represented.

2. Phone/PC is off completely and does not display any data: This can happen either when the phone or PC does not receive any data or those entities are faulty.

Figure 8.12 depicts the system's two input ports: inHuman2Phone and inHuman2PC, corresponding to the mobile phone and PC, respectively. These ports enable us to simulate the effects of external failures on the overall system functionality. For example, the inHuman2Phone port can simulate a scenario where the user mistakenly turns an appliance "ON/OFF" when it is not required. This situation represents a "commission" failure injected externally into the system. Similarly, for the PC, we simulate a scenario where the user responds to a "LATE" system condition, indicating a "late" failure externally injected into the system. It is important to note that the consequences of both scenarios propagate throughout the system and elicit different responses based on the actual failure behavior of each component they encounter. The routes of failure propagation are highlighted in pink in Figure 8.12.

The next step involves deriving the system components' internal failure and propagation rules. To determine the failure behavior of each component, it is necessary to understand their functional behavior. Let's consider the example of a sensor. A sensor can fail in two different ways. First, it may completely cease providing data (resulting in an "omission" at the output port). Alternatively, the sensor may experience internal failures, such as inaccuracies in the readings or data values outside the expected range (leading to a "valueCoarse" at the output port). We can establish distinct failure rules for these scenarios, as depicted in Equation 8.1 and 8.2, respectively. It is important to note that the asterisk notation denotes an unknown source of failure in cases where a component does not possess any input ports. Additionally, other components like the power battery, gateway, server, ACUnit, etc., can fail by ceasing to provide power (omission at the outputs). A comprehensive list of failures and detailed descriptions can be found in the table set provided in [238].

$$FLA : (*) \rightarrow outSensor2Board.omission \qquad (8.1)$$
$$FLA : (*) \rightarrow outSensor2Board.valueCoarse \qquad (8.2)$$

Once the failure behavior specifications of the components are finalized, the safety expert can assign basic failure probabilities to aid in quantitative analysis. Determining the failure probability of a component can be a challenging task. It is recommended to consult the device manufacturer's documentation, and industry standards, or seek advice from device experts. In safety engineering, the device failure probability is often considered to be extremely low and often expressed as failures per million ($10^{-6}$), particularly for individual components [231]. To maintain simplicity, we have set a default probability value of $4 \cdot 10^{-5}$ for all basic failure events. It is important to note that the Fault Tree Analysis (FTA) can also be applied at the sub-composite component level, such as the ROOM level. This allows for investigating the potential impact of failures originating from internal sub-components, as well as the effects of externally injected failures on the behavior of internal components.

<figure><img src="image_64.png" /><figcaption>Figure 8.13: Analysis results</figcaption></figure>

Upon completing the analysis, fault-tree models are generated based on the failures that have propagated to the system's output port. The analysis results are represented for both the "ROOM-level" and the "System-level" in Figure 8.13. In particular, the "omission" and "valueCoarse" failures have propagated to the system's outSystemFmPC and outSystemFmPhone output ports. Furthermore, at the ROOM-level, the "commission" and "omission" failures have propagated to the output ports of components such as ACUnit, LightBulb, and Window, whereas the "commission" and "valueCoarse" failures have propagated to the outRoomData port which sends data to the gateway.

An FT is generated and analyzed accordingly for each analysis result described above. The two system-level propagated failures match the two big top failure scenarios described earlier. Fig. 8.14, Fig. 8.15, and Fig. 8.16, present generated and analyzed FTs for both at the Room level as well as at the system level.

Figure 8.14 shows an analyzed fault tree in the situation where the window stops working totally. As can be observed, at the low lever, there are three basic events: "a completely broken board", "a completely broken sensor", and "an external failure related to the battery, for example, a drained
<figure><img src="image_65.png" /><figcaption>**Figure 8.14:** Room-level FT diagram: *Window not working (omission at the window output port)*</figcaption></figure>

*battery*". Based on the shown fault tree in Fig. 8.14, the three basic events are fed into an "OR" gate, which means that if any of them occurs, it will flow directly through the gate. As the simulation evolves, the resulting intermediate event is OR'ed with the "*window servo broken completely*" internal failure resulting in the undesired top failure. Eventually, one of the four basic failures will directly propagate to the output port.

Overall, the top-level undesired event probability for such a scenario is estimated to be $1.2 \cdot 10^{-4}$.
Because the scope of the room is substantially smaller than that of the system, the external event, in this case resulted from the injected failure from the battery port and was assigned a probability of zero. This may appear irrational, however, to obtain the probability values of such an event, the entire system's probability must first be computed and then assign the corresponding probability value to such an event. We plan to tackle this issue in the future.

In Figure 8.15, we present another example of a room-level Fault Tree (FT) that illustrates an event where the ACUnit unexpectedly switches on and off, resulting in a "commission" failure at the ACUnit's output port. The diagram includes two external events: one located at the bottom right, representing an external "valueSubtle" failure injected from the outside due to a late reaction from the PC, and another event in the middle-left depicting the user pressing the commanding button when it is not needed. Both scenarios elicit different responses from the system. It is important to note again that the two external events labeled as injected failure events are beyond the scope of the current analysis context, and thus no probability can be assigned to them at this stage.

Finally, at the system level, we discuss the fault tree depicted in Fig. 8.16. It shows the fault tree in which the "Mobile phone displays erroneous data," inferring a "valueCoarse" failure propagating at the output port. In this situation, the two rooms will have equal control over whether the data on the display is totally incorrect. Two rooms in the tree have the same sub-tree since they are from the same instance, and their failure outcomes are joined by a "AND" gate. According to the above tree,
<figure><img src="image_66.png" /><figcaption>**Figure 8.15:** Room-level FT diagram: ACUnit turn on and off when not expected</figcaption></figure>

erroneous sensor data in an event with a late reaction from the user PC will permit erroneous data to propagate up the tree. The event in which the "Board is failing and sent inaccurate data" will also play a role in the loop.

Maintaining coherence between the system and the safety model can be challenging when the model grows in size and complexity. Having a framework that can automate the safety analysis process by allowing the safety expert and the IoT engineer to work on the same problem from the same unique environment can potentially improve transparency while significantly reducing the time required to perform such rigorous analysis tasks. Based on the previous findings, we discuss the feasibility of establishing a collaborative analysis mechanism in which both parties collaborate to keep the system and safety model up to date, thereby improving consistency throughout the process.

## 8.4.2 Software design and development

The software development approach supported by CHESSIoT encompasses the functional and behavioral design aspects of the system, along with code generation, with a specific emphasis on the edge layer. These aspects are described in detail in Section 8.2. In this section, we will primarily focus on the Room level, providing models for the functional and behavioral aspects of its sub-components: the *Temperature sensor*, *ACUnit*, *Bulb*, and *WindowServo*.

To maintain continuity with our previous system-level model, which is presented in Figure 8.12, we refer to it as a point of reference.

### Behavior modeling

The internal component model representation of the room is depicted in Figure 8.17. This model illustrates the structure and interactions of the sub-components within the room, offering insights into their functionalities and behaviors. As shown in the figure, communication between components is accomplished by sending and receiving payload messages over provided and required ports. A set of payloads initiated by each component is created internally, and a pin number is specified for each port of the actuating or sensing component to be connected to the board. For instance, two payloads
<figure><img src="image_67.png" /><figcaption>**Figure 8.16:** System-level FT diagram: *Mobile phone displays inaccurate data scenario*</figcaption></figure>

(i.e., ON/OFF or OPEN/CLOSE) are defined for each actuating component, namely ACUnit, Light-Bulb, and WindowServo, to be used when communicating with the board. Furthermore, the generic actions that are fired were defined internally to set the associated pins HIGH or LOW accordingly. Furthermore, internal events are initiated for each component to determine whether there is a received actuating payload from the board via the dedicated port.

Each component is associated with its respective state machine. The working principle of actuating components is to react on a source of electric energy received to move or change the physical state of something. From that, each actuating component state machine has been assigned a single state.
<figure><img src="image_68.png" /><figcaption>Figure 8.17: Room internal composite structure</figcaption></figure>

In this case, it waits for the board's command and reacts accordingly using the previously defined actions. A sensor, on the other hand, has a state called "Sensing" in which it constantly monitors the "readSensor" communication payload from the board to sense the temperature and send a new payload "sensorData" the board through the same port (Figure 8.17).

The board serves as a central computing component in the process, coordinating all connected elements by reusing previously defined actions, payload, and guards. Figure 8.18 shows a partial caption of the inner events and guard defined within the board. As we can see, only the necessary internal events, such as checking if the sensor data has arrived to send the ON/OFF commands to the appliance (i.e *HighSensorDataReceived* and *LowerSensorDataReceived*), as well as conditional events i.e: *High_to_low* and *Low_to_high*) and transition guards *ValueLow* and *ValueHigh*) to be fulfilled accordingly when transiting from one state to the other.

<figure><img src="image_69.png" /><figcaption>Figure 8.18: Portion of the Board event, action, guard specification</figcaption></figure>

As we can see from the board state machine figure 8.19, three main states are defined, namely "IDLE", "AC_OFFBulbOFFWindowClose" as well as the "AC_ONBulbONWindowOpen" states are
<figure><img src="image_70.png" /><figcaption>**Figure 8.19: Board state machine**</figcaption></figure>

defined to control the basic behavior of the board. In each of the two main states, the internal event internal events such as *HighSensorDataReceived* and *LowerSensorDataReceived* are used to send trigger the ON/OFF actions accordingly refer to Figure 8.18. Coming from the "IDLE" state, the transition from the *"AC_OFFBulbOFFWindowClose"* state to the following *"AC_ONBulbONWindowOpen"* state happens when the conditional event check is confirmed (i.e: we are still getting the payload being sent at the sensor port) as well as the guard condition is fulfilled (in our case we choose to go for a temperature of 30 degree Celsius as a threshold).

## Code generation

When the functional and behavior modeling is done, the CHESSIoT2ThingML transformation is launched to generate the ThingML model files ready to be compiled in the ThingML environment for generating platform-specific code. The transformation process follows the mapping presented in 8.1. Figure 8.20 depicts the structure of the generated ThingML models infrastructure. During the transformation process, each of the Room's sub-component is transformed into its unique ThingML model. Furthermore, the utility files such as license files as well as the global data types and timing messages are generated separately.

Figure 8.21 depicts the generated ThingML model of the board mapped back to the state machine diagram presented in Figure 8.19. As we can see from Figure 8.20, the ThingML model associated with the board model is generated in the parent folder of the *Room* and it imports all of its connected siblings. This gives the board the possibility to have access to the message of all the other components. For instance, at this level, the board can use its port to send and receive payloads from other components through its *required ports*. Each of the states indicated in the state machine diagram is converted into a ThingML thing's state with all its internal actions and events transformed accordingly.

Upon executing the transformation process, the code generator generates the configuration code, adhering to a component-to-connector architecture [37] that aligns with the Room's internal structure. As depicted in the bottom-left section of Figure 8.21, the configuration code instantiates all components as ThingML objects. From there, internal connections are established by linking the corresponding ports of these objects. Additionally, the properties of each Thing object are set to their original values as specified in their respective Things.

The current CHESSIoT generator supports the ThingML code generation compiled into Arduino
<figure><img src="image_71.png" /><figcaption>Figure 8.20: Generated ThingML models</figcaption></figure>

<figure><img src="image_72.png" /><figcaption>Figure 8.21: Generated Board's ThingML model mapped to the state machine diagram</figcaption></figure>

code and from the generated models we could successfully generate Arduino code ready to be deployed on IoT devices. To validate the generated code, we have successfully deployed the generated
code without any single change in the same project designed in the Proteus Simulation software <fnref n="7" /> and
the code worked perfectly as expected. The full example with all the materials is online available at
https://github.com/fihirwe/HomeAutomationSystem.git

8.4.3 Deployment and service provisioning

In this section, we cover the "Home Automation System" deployment designs as well as the de-
ployment artifact generation aspects.

HAS Deployment plan design

As we described above, the HAS system involves the code running at all layers, namely the edge device, i.e., Arduino, and the mobile phone, at the Fog, i.e., a RasberryPi running the MQTT broker, as well as the on the cloud i.e-, a web server running a Node-RED dashboard instance. Figure 8.22 shows the deployment model of the system. As can be seen, all three main node layers are present, namely "DeviceNode", "FogNode", and "CloudNode" reflecting the level of computation involved other than the device layer.

<figure><img src="image_73.png" /><figcaption>Figure 8.22: HAS system deployment plan</figcaption></figure>

At the edge layer, two machines are defined namely to reflect the generated Arduino code running
at the Arduino micro-controller as well as the Mobile-Phone as a machine running the Android app.
The deployment at this layer is done manually and for now, no automation is provided. This is mainly

<footnote n="7">7 https://www.labcenter.com/</footnote>
due to the computing limitation presented by such chosen deployment platform for this example. At the FogNode, one machine running a Raspbian operating system was chosen to host the MQTT broker, which receives the communication from the edge layer (i.e., the Android app as well as the system code running on the Arduino code which publishes/subscribes messages to it).

As shown in Fig. 8.22, the Broker allows anonymous connections, so no username and password are needed to be created for such a server. Furthermore, the service priority property at this stage doesn't matter because we have only one service running on such a machine. This is typically used as a priority reference during the run-time management of services as a given machine. The persistence is set to true in which, during the transformation, the default Eclipse-Mosquitto broker persistence directories are chosen by default. Finally, at the cloud layer, one Ubuntu-based machine is used to host both the Node-RED dashboard instance.

During the transformation process, a docker-compose file is generated for each machine at any layer. These docker-compose files contain the necessary information for hosting the services on each machine. However, due to missing information and service incompatibility at the Device layer, the generated docker-compose file in this case is incomplete and cannot be used. For illustration purposes, the generated docker-compose file at the Fog layer is presented in Figure 8.23.

<figure><img src="image_74.png" /><figcaption>Figure 8.23: Generated deployment configuration Fog</figcaption></figure>

## HAS runtime service provisioning

As shown in the deployment plan model in Figure 8.22, the FogNode and the CloudNode elements are annotated with their corresponding FogDepAgent and CloudDepAgent, respectively. These annotations enable the definition of runtime deployment rules associated with the runtime management of the services deployed at each of the machines running at the node.

In Figure 8.24, we present an example of agent rules defined at the edge node. The provided agent includes four distinct deployment plans. The first plan, known as the setup plan, is responsible for installing all the necessary dependencies on the target machine. This setup plan is highly dependent on the specific target host, and the actual setup tasks will be defined accordingly.

Furthermore, the "installServiceOnFogMachine" plan will create and install the MQTT broker instance at the target fog machine. In addition to that, on the next plan, a "StartMQTTBroker" plan is defined to start and save the broker logs in the file with the name specified. By default, such a file will
<figure><img src="image_75.png" /><figcaption>Figure 8.24: FogDepAgent rules</figcaption></figure>

be located in the root folder of the machine server. The log type in this case is set to service to limit
the logging to the Service log, not the machine host in which the broker is running. Note that during
the transformation process, each of the "DepPlan" is translated into the corresponding playbook with
its corresponding name. At this stage, the playbook can be used and launched separately depending
on the user's need (see Fig. 8.23).

**8.5 Conclusion**

This chapter presented CHESSIoT, a model-driven environment for developing and deploying multi-layered IoT systems. In the chapter, we illustrated the CHESSIoT approach for software modeling IoT systems across all three primary layers. A deployment modeling approach, together with a run-time service provisioning approach was presented. Through the use of a home automation case study, we demonstrated the fully CHESSIoT tool capability for conducting both qualitative and quantitative safety analyses, model software aspect of the system and generate a set of fully functional ThingML source models, which are then used to generate platform-specific code ready for deployment on low-level IoT devices. Finally, a full deployment model was designed and generated deployment artifacts ready to be executed on a remote docker environment. In the future, we intend to provide testing support for generated code, with the outputs potentially assisting in the recommendation of any potentially missing safety rules. Finally, we plan to enhance the qualitative safety analysis mechanism by enabling the generation of minimal cut-set FTs.
# Chapter 9

# Conclusion and future work

## 9.1 General contributions

We summarize the key contributions of this thesis as follows:

1. Low-code engineering and its current adoption in IoT software development domain

In this dissertation, we have covered the current state of the art of LCE, particularly in the IoT domain, and how the model-driven approach is playing a huge role in its realization. We have mapped its similarities and differences with respect to existing trends in LCDPS as to where MDE fits in the loop. We have presented the analysis that has been performed by conceiving a taxonomy, which has been formalized as a feature diagram presenting all the features of a typical modeling platform supporting the engineering of IoT systems. We have conducted and presented the current state of the art regarding which IoT domain developers adopt cloud-based modeling technology revolutions. The considered approaches have been analyzed to assess their strengths and weaknesses concerning many characteristics, including their modeling focus, accessibility, openness, and artifact generation. We have also presented the challenges that are being faced in order to migrate the legacy platforms into cloud-based low-code ones. For instance, issues such as the extensibility of the legacy platforms, and IoT system complexity, in general, make the learning curve route even more hard and scalability concerns. We also conceived some opportunities that this initiative could bring to the community such as attracting more citizen developers, collaborative modeling, low cost of maintenance, and so on.

2. Software product quality evaluation of Low-Code/MDE engineering platforms

Evaluating the quality of engineering platforms, especially in IoT, is still an open issue due to the technological revolution that the IoT domain experience to enhance our everyday livelihood. This thesis presented a model for evaluating the quality of IoT Low-code/MDE engineering platforms targeting the software product quality features. The presented model is based on and extends the ISO/IEC 25010:2011 software product quality model [14] standard targeting to help IoT practitioners in assessing and establishing the software quality requirements for engineering IoT platforms. Among others, security and maintainability features were found to be less addressed, whereas functional appropriateness, portability, and usability were found to be the most addressed. The model has been used to evaluate the software quality of 17 IoT platforms in which it was discovered that the overall quality performance of considered IoT engineering platforms (MDEs and LCDPs combined), regardless of characteristics and sub-characteristics, was about 45.5%, in which MDE accounts for 39.6%, whereas LCDPs have 51.1%. In general, the proposed model could be used mostly to evaluate the software platforms' static and dynamic properties rather than the quality of the outcome of interaction when a product is used in a specific context.
3. Supporting model-based safety analysis of IoT systems

As the current technological revolution evolves around the improved quality of life of human be-
ings, the safety of that system needs to be well studied and certified beforehand. The IoT domain
is one of the emerging domains; fewer approaches have been developed to assess the safety of
the system under development at its earliest stages. In this dissertation, we presented the CHES-
SIoT safety analysis approach for IoT systems based on the Fault-Tree Analysis technique. The
presented approach relies on and extends CHESS Failure Logic Analysis (CHESS-FLA) [44], a
methodology that enables the user to model the system's failure behavior, run the Failure Logic
Analysis, and propagate the analysis results back onto the original model [45]. In addition to its
ability to generate the system's complete FTs, the new FTA approach automatically performs
qualitative analyses by eliminating unnecessary paths and redundancies in the FTs' events. Fi-
nally, the proposed approach also calculates the failure probabilities of an entire system from
its constituent parts' failure event probabilities. In addition to a short comparative analysis con-
ducted based on related works, a safety critical example was used to showcase the capability
of the tool. The proposed approach can hugely help in predicting the impact of a component
change or architectural change on a system in a very cheap way [81]. For instance, in case
of an essential failure behavior occurring at the model system level, it will be easy to discover
the source of the fault immediately and identify where the fault tolerance measures should be
directed in the architecture to mitigate them.

4. Supporting model-based development and deployment of IoT systems

In addition to the safety analysis contribution, the CHESSIoT engineering environment pre-
sented in this thesis gives the user the opportunity to perform the modeling, development as
well as deployment tasks of IoT systems. The new approach employs a range of DSL for each
task to better enhance the separation of concerns as well as the model's correctness. CHESSIoT
brings a unique possibility for the user to design, develop, analyze, and deploy engineering
IoT systems all from the same environment. Through CHESSIoT, a user can benefit from a
multi-view development environment in which each of the supported views has its own under-
lined constraints that enforce its specific privileges on model entities and properties that can be
manipulated. The software model containing the system's functional and behavioral aspects is
transformed to ThingML [37] models, which eventually can later be transformed into platform-
specific code. A deployment modeling approach together that supports the users in decomposing
of IoT system deployment plan as well as managing deployed node services at all layers, namely
Edge, Fog, and Cloud was presented. Finally, CHESSIoT offers a model-driven runtime service
provisioning environment that allows the automatic definition of software services' life cycle
based on predefined rules referred to as agents. To evaluate or approach, we have presented
results from two different comparative analyses, and discussions were developed, taking into
consideration modeling support as well as other supporting activities, revealing an averaged gap
of 54.34%, which CHESSIoT potentially addresses.
## 9.2 Publications

The following contains a list of all research publications that I was involved in during the course of my PhD research.

### 9.2.1 Journal papers

1. **Under review: Felicien Ihirwe**, Katia Di Blasio, Davide Di Ruscio, Simone Gianfranceschi, and Alfonso Pierantonio. "Supporting the model-based safety analysis for safety-critical IoT systems" Submitted to Journal of Computer Languages (May 2022) **This paper was presented in Chapter 7**

2. **Under supervisor review: Felicien Ihirwe**, Davide Di Ruscio, Simone Gianfranceschi, and Alfonso Pierantonio. "A model-driven environment for engineering multi-layered IoT systems" Submitted to Journal of Computer Languages (May 2023) **This paper was presented in Chapter 6 and 8**

3. Murorunkwere Belle Fille, **Felicien Ihirwe**, Idrissa Kayijuka, Joseph Nzabanita, and Dominique Haughton. "Comparison of Tree-Based Machine Learning Algorithms to Predict Reporting Behavior of Electronic Billing Machines" Information Volume:14, Issue no. 3: 140. February 2023. https://doi.org/10.3390/info14030140 **Not presented in this thesis**

### 9.2.2 Conference papers

4. **Felicien Ihirwe**, Davide Di Ruscio, Simone Gianfranceschi, and Alfonso Pierantonio. "Assessing the Quality of Low-Code and Model Driven Engineering Platforms for Engineering IoT Systems". In Proceedings of the 22nd IEEE International Conference on Software Quality, Reliability, and Security (QRS22). 12 Pages. November 2022. Available at SSRN: http://dx.doi.org/10.2139/ssrn.4267269. **This paper was presented in Chapter 5**

5. Alberto Debiasi, **Felicien Ihirwe**, Pierluigi Pierini, Silvia Mazzini, and Stefano Tonetta. "Model-based Analysis Support for Dependable Complex Systems in CHESS". In Proceedings of the 9th International Conference on Model-Driven Engineering and Software Development - MODEL-SWARD'21. ISBN 978-989-758-487-9; ISSN 2184-4348, pages 262-269. DOI: http://doi.org/10.5220/0010269702620269. February 2021 **This paper was presented in Chapter 2**

6. **Felicien Ihirwe**, Giovanni Iovino, and Davide Di Ruscio. "Towards an MQTT5 geo-location extension for location-aware applications". In the 44th IEEE International Conference on Telecommunications and Signal Processing (TSP'21). July 2021. DOI: http://doi.org/10.1109/TSP52935.2021.9522590. **Not presented in this thesis**

7. **Felicien Ihirwe**, Davide Di Ruscio, Silvia Mazzini, and Alfonso Pierantonio. "A domain-specific modeling and analysis environment for complex IoT applications". In the 7th Italian Conference on ICT for Smart Cities And Communities (I-CiTies'21). September 2021. https://arxiv.org/abs/2109.09244 **This is an extended abstract that introduces the approach presented in Chapter 2**

### 9.2.3 Workshop papers

8. **Felicien Ihirwe**, Davide Di Ruscio, Silvia Mazzini, Pierluigi Pierini, and Alfonso Pierantonio. "Low-code engineering for internet of things: a state of research". In Proceedings of the 23rd ACM/IEEE International Conference on Model Driven Engineering Languages and Systems: Companion Proceedings (MODELS '20). Association for Computing Machinery, New York, NY, USA, Article 74, 1-8. November 2020 https://doi.org/10.1145/3417990.3420208 **This paper was presented in Chapter 4**
9. Felicien Ihirwe, Davide Di Ruscio, Silvia Mazzini, and Alfonso Pierantonio. "Towards a modeling and analysis environment for industrial IoT systems". In the International Workshop on MDE for Smart IoT Systems co-located with Software Technologies: Applications and Foundations (MESS@STAF21) conferences. June 2021. Bergen, Norway. Available https://ceur-ws.org/Vol-2999/messpaper1.pdf This paper presents the preliminary results of the approach presented in Chapter 2

10. Felicien Ihirwe, Arsene Indamutsa, Davide Di Ruscio, Silvia Mazzini, and Alfonso Pierantonio, "Cloud-based modeling in IoT domain: a survey, open challenges, and opportunities". In 2021 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C 2021), Fukuoka, Japan, 2021, pp. 73-82, doi:http://doi.org/10.1109/MODELS-C53483.2021.00018. This paper was presented in Chapter 4

### 9.2.4 Technical Reports

11. Léa Brunschwig, Felicien Ihirwe, Panagiotis Kourouklides, Joost Noppen "D3.2. Lowcomotive Integrations - Interim Version". Technical report in the context of Training the Next Generation of Experts in Scalable Low-Code Engineering Platforms (Lowcomote). November 30th, 2020. The report available at: https://cordis.europa.eu/project/id/813884/results

## 9.3 Developed tools

The full code and the instruction on how to use CHESSIoT can be found in detail in the appendix C
## 9.4 Future Directions

1. **Low-Code Engineering platforms capabilities on tackling complex IoT system:** While MDE is often referred to as an essential building block of low-code but with certain differences [58], however, there is still a question of which if the current generation of domain-agnostic LCDPs will keep up with the growing complexity of IoT stems. In the future, we will keep exploring quantitatively as well as qualitatively to which extent IoT low-code approaches are keeping up with the rise. We will keep exploring the limitations which such platforms are facing in terms of providing more engineering support, such as early analyses and verification, deployment, and continuous maintenance of developed software. In addition to that, we plan to explore the extent to which the generated solutions are to tackles complex tasks in comparison to the existing code-centric approaches.

2. **Quality in use product model for IoT engineering platforms:** The proposed software quality model was based on ISO/IEC 25010:2011 quality standard [14]. While the standard is composed of two main sets of quality models, namely “quality in use model”, and “product quality model”, the presented model only extends the software product model. In order to enhance the proposed quality evaluation process, we plan to also examine the possibility of evaluating “quality in the use” aspects for the IoT engineering platform. We plan on extending the quality in use model of the as well as accommodate other quality aspects beyond the software product quality model. This “quality in the use” model includes five characteristics, namely effectiveness, efficiency, satisfaction, risk freedom, and context coverage where some of them are further subdivided into nine sub-characteristics, however in “real-world” also other quality aspects matter. For example, how about the viability of the community (e.g., support and answer rate) or other aspects not covered by the model?

3. **Enhanced Fault-tree qualitative safety analysis:** The goal of the presented Fault-tree qualitative analysis approach is to provide a new representation of the existing FT that only includes the essential event representations. Although the current implementation does not fully reflect the final shape of the calculation of the minimal cut-set event sets [230], it does provide a much shorter and more correct, shorter, and readable FT that still helps and reflects the goal for the analysis. Due to the time constraint and the complexity that lies behind solving the logic function of the fault-tree model function, we did not manage to implement the probability logic solver infrastructure. In the future, we plan to implement the infrastructure for deriving minimal tree representation based on minimum cut-set events. In addition to that, we plan to integrate time-based failure logic analysis as well as the severity aspects into our approach. This is mainly to reflect the effect of which a component failure may cause on the entire system taking into account short or longer periods as well as how severe it could be. Finally, we intend to improve our system failure mode abstraction method by making it easily customizable from one domain to another as well as providing testing support to potentially assist in the recommendation of any potentially missing safety rules.

4. **Improved code generator for supporting other platforms:** The presented software development approach provides means for modeling the functional and behavioral model of the systems, and later it is transformed into a ThingML model ready to be compiled into platform-specific code. Although ThingML supports many different platform-specific languages, the provided transformation infrastructure currently supports the ThingML models, which can be compiled into Arduino platforms. In the future, we want to expand such infrastructure e.g., by including other platforms running on Java and C++.

5. **CHESSIoT services on the cloud:** With the growing interest in cloud-based engineering tools, traditional local-based solutions appear to be increasingly driven towards becoming cloud-based. Although CHESSIoT is not a cloud-based tool, it provides significant support for more
complex and critical IoT system engineering tasks. Despite this, the lack of cloud-based sup-
port causes challenges with installability, dependencies, and, in some cases, usability. To sup-
port future accessibility as well as supporting our proposed LCEP concepts presented in 2.3.2,
we intend to detach all supported engineering features and deploy them separately, allowing
such facilities to be consumed via dedicated API. This will also allow re-engineering of the
modeling infrastructure to the cloud.

6. **Extensive empirical validation:** As CHESSIoT was developed as a tool to support the engineering of IoT systems which involves capabilities that needs to abide with certain standards and approvals from the external experts, in the future we plan to conduct an extensive empirical evaluation of the approach to check the acceptance of the proposed method by various external stakeholders in the industry. For instance, for what regards the safety analysis infrastructure, conducting this can in turns give us possible recommendation on what to follow when proposing potential fundamental principles on dealing with safety analysis for IoT systems an an evolving domain.
# Appendix A

## Software product quality evaluation questionnaire for IoT LCDP and MDE
<table><thead><tr><th>Characteristic</th><th>Sub-characteristic</th><th>Questions</th></tr></thead><tbody><tr><td rowspan="4">Functional suitability</td><td>Functional Completeness</td><td>"Does the platform support any form of modeling of the Edge layer?<br>Does the platform support any form of modeling of the Fog layer?<br>Does the platform support any form of modeling of the Cloud layer?<br>Does the supporting paper mention any support for dealing with different communication protocols?"</td></tr><tr><td>Functional Correctness</td><td>"Does the platform employs at least one of correctness methodologies during the development?<br>For instance: - Component based development<br>- Correct by construction<br>- Model-checking<br>- Model validation<br>- Rule-based development<br>- Model verification"</td></tr><tr><td>Functional Appropriate-ness</td><td>Does correctness approaches impact in the platform code generation process?</td></tr><tr><td>Performance efficiency</td><td>Time-behavior</td><td>"Does the platform respond well while in usage?<br>If it is not lively accessible, does the supporting paper mention any means for execution time efficiency?"</td></tr><tr><td rowspan="3">Compatibility</td><td>Resource Utilization</td><td>"Does the platform require zero or very minimal set-up in usage?<br>If not accessible live, does the supporting paper mention any means for dealing with resources needed?"</td></tr><tr><td>Capacity</td><td>"Can the platform be used to develop apps from various IoT sub-domains?<br>Can the platform develop a scalable IoT platform with hundreds of connected devices?"</td></tr><tr><td>Co-existence</td><td>"Can the platform be deployed and used in a shared server environment?<br>If the platform is not lively accessible, does the supporting paper mention any mean for that?"</td></tr><tr><td rowspan="4">Reliability</td><td>Interoperability</td><td>"Does the platform support any means for exchanging data from third parties services?<br>Does the developed application support external data exchanges?"</td></tr><tr><td>Maturity</td><td>"Does the platform support both the design and code generation of engineering IoT systems?<br>Does the platform support any kind of deployment of engineering IoT systems?<br>Does the platform support any kind of analysis?"</td></tr><tr><td>Availability</td><td>"Does the platform operational when needed?<br>In case of a local based platform, is it downloadable and directly be used when needed?"</td></tr><tr><td>Fault tolerance</td><td>"Does the platform provide any mean for fault tolerance such as self-adaptation or self-healing operation mechanisms?<br>Does the supporting paper mention any mean for such support?"</td></tr><tr><td rowspan="6">Usability</td><td>Recoverability</td><td>"Does the platform provide any mean for fault tolerance such as self-recovery or self-redeployment operation mechanisms?<br>Does the supporting paper mention any mean for such support?"</td></tr><tr><td>Appropriateness</td><td>"Does the name of the platform reveals easily any IoT related concepts?<br>Is the platform solery designed for IoT systems development?<br>Does the platform's concepts, elements and constructs used in development IoT specific?"</td></tr><tr><td>Learnability</td><td>Does the platform provides any kind of the following supports: context-based modeling, on-the-fly suggestions, and so on</td></tr><tr><td>Operability</td><td>Does the platform provide any kind of the following supports: as auto-completion for textual languages, guide-through mechanisms, multi-view modeling, palette show/hide, and palette element search?</td></tr><tr><td>User error protection</td><td>Does the platform provide any means for error protection such as static analysis or on-the-fly error handling</td></tr><tr><td>User interface</td><td>Does the platform provides pleasant and satisfying user interfaces?</td></tr><tr><td></td><td>Accessibility</td><td>"Does the platform easily reachable in case of needs, either being locally or online?<br>Does the supporting paper mention any mean for such support (open accessed repo for local based platforms)?"</td></tr></tbody></table>
<table><tbody><tr><td rowspan="5">Security</td><td>Confidentiality</td><td>"Does the platform provides any means for granting access only to authorized parties?<br>Does the supporting paper mention any mean for such support?"</td></tr><tr><td>Integrity</td><td>"Does the platform provide any means to prohibit unwanted access, modification of the platform, or data?<br>Does the supporting paper mention any mean for such support?"</td></tr><tr><td>Non-repudiation</td><td>"Does the platform enforce the logging of all hortorical activities performed during the developemnt process?<br>Can such activities be retrieved later?"</td></tr><tr><td>Accountability</td><td>"Does the platform provide any kind of software under development versioning?<br>Does the supporting paper mention any mean for such support?"</td></tr><tr><td>Authenticity</td><td>"Does the platform support any kind of authentication mechanisms while accessing platform resources?<br>Does the supporting paper mention any mean for such support?"</td></tr><tr><td rowspan="5">Maintainability</td><td>Modularity</td><td>Does the platform be decoupled into different sub-parts for instance, micro-services?</td></tr><tr><td>Reusability</td><td>"Does the platform sub-parts be reused independently?<br>Does the supporting paper mention any mean for such support?"</td></tr><tr><td>Analyzability</td><td>"Does the platform sub-parts be analysed independently?<br>Does the supporting paper mention any mean for such support?"</td></tr><tr><td>Modifiability</td><td>"Does the platform sub-parts be modified independently without introducing any flaws or deteriorating the quality of existing products?<br>Does the supporting paper mention any mean for such support?"</td></tr><tr><td>Testability</td><td>"Does the platform sub-parts be tested independently?<br>Does the supporting paper mention any mean for such support?"</td></tr><tr><td rowspan="3">Portability</td><td>Adaptability</td><td>Can the platform be deployed effectively and efficiently adapts to different environments</td></tr><tr><td>Installability</td><td>Can the platform be successfully installed and/or uninstalled in a given environment?</td></tr><tr><td>Replaceability</td><td>Can the platform be updated, replaced, and redeployed in the same environment and still performs as expected.</td></tr></tbody></table>
# Appendix B

## Fault-Tree generation

### B.1 FLA2FT transformation rules

```csharp
1
2 * Copyright (c) 2022, Intecs Solutions SpA
3
4 * All rights reserved. This program and the accompanying materials
5 * are made available under the terms of the Eclipse Public License v2.0
6 * which accompanies this distribution, and is available at
7 * https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.html
8 *
9 * SPDX-License-Identifier: EPL-2.0
10
11 * Contributors:
12 * Felicien Ihirwe
13 * Initial API and implementation and/or initial documentation
14*********************************************************************/
15pre{
16 "Running transformation---------------------------".println();
17 var mapping : Sequence ;
18 var ftas : Sequence ;
19 var parents : Sequence;
20 var events : Sequence;
21 var portNames : Sequence;
22 var count : Integer;
23 count=0;
24 mapping = flamm!Port.allInstances();
25 "Started the transformation---------------------------".println();
26 for(port in mapping) {
27 if(port.ownerparent.isUndefined()and port.owneroutputPorts.contains(port)) {
28 for(f in port.failures) {
29 if(f.id.contains("noFailure")) = false) {
30 var fta = new emfta!FTAModel;
31 fta.name = "Fault Tree of "+ port.name+""+f.id+" 
----------------
\n TOP FAILURE
<"+f.id+"> at "+port.name+" port in "+port.owner.name;
32
33 ftas.add.fta;
34 }
35 }
36 }
37 }
38 }
39
40 rule outputOfComposite2FTA
41 transform c : flamm!CompositeComponent
42 to ev : emfta!FTAModel {
43 guard : c.parent.isUndefined()
44 for(p in mapping) {
45 if(p.ownerparent.isUndefined()and p.owneroutputPorts.contains(p)) {
46 for(f in p.failures) {
47 for(ft in ftas) {
48 if(ft.name = "Fault Tree of "+p.name+""+f.id+" 
----------------
\n TOP FAILURE
<"+f.id+"> at "+p.name+" port in "+p.owner.name") {
49 var e = new emfta!Event;
50 e.name = p.name+""+f.id+" 
----------------
\n TOP FAILURE <"+f.id+"> at
51 "+p.name+" port in "+p.owner.name;
52
```
```ksharp
e.type = emfta!EventType#Intermediate;
var gate: new emfta!Gate;
e.gate = gate;
e.gate.type = emfta!GateType#OR;
e description="" + ftasurget + "" + f.id;
e.gate description="" + e description;
ft.events.add(e);
for (con in p connectedPorts) {
    parents.clear();
    con recurseFaultTree(f, con, ft, e);
}
}
//take care of undeveloped events to avoid concurrent modification error
var k1 = 0;
while (k1 < ft.events.size()) {
    var event = ft.events.at(k1);
    if (event.type.name = "Intermediate") {
        if (event.gate.events.size() < 1) {
            var eventSp: new emfta!Event;
            eventSp.name = "UNDEVELOPED FAILURE";
            eventSp.type = emfta!EventType#Undeveloped;
            eventSp description="unknown_undeveloped";
            ft.events.add (eventSp);
            event.gate.events.add (eventSp);
            parents.add (eventSp);
        }
        //take care of internal propagation and transformation gate differences
        if (event.gate.events.size() = 1) {
            for (v1 in event.gate.events) {
                if (event description.split("_").get(1) = v1. description.split("_").get(1)) {
                    event.gate.type = emfta!GateType#OR;
                }
            }
        }
        }k1 = k1 + 1;
    }
}
// remove the undeveloped tree
var k = 0;
while (k < ftas.size()) {
    var ft = ftas.at(k);
    if (ft.events.size() = 1) {
        ftas.remove(ft);
        k = k + 1;
    }
}
"Ended the transformation --------------------------".println();
operation flamm!Portrecursion FaultTree(f: flamm!Failure, con: flamm!Port,
ft: emfta!FTAModel, e: emfta!Event): Sequence{
    if(con.ownerparent.isDefined()) {
        if(con.owner.type.name = "SimpleComponent") {
            for (rul in con.owner_rules) {
                for (outexp in rul outputExpression) {
                    if (outexp.port = con) {
                        for (f1 in outexp.failures) {
                            if (f1.id = f.id) {
                                var eventSp: new emfta!Event;
                                eventSp.name = outexp.port.name + "" + f1.id + " 
\n--------------------
LOCAL FAILURE <" + f1.id + "> at " + outexp.port.name + "
                                port in " + outexp.port.owner.name;
                                eventSp.type = emfta!EventType#Intermediate;
                                var gate: new emfta!Gate;
                                eventSp.gate = gate;
                                eventSp.gate.type = emfta!GateType#AND;
                                eventSp. description="" + ftasurget + "" + f1.id;
                                eventSp.gate. description="" + eventSp. description;
                                ft.events.add (eventSp);
                                e.gate.events.add (eventSp);
                                parents.add (eventSp);
                                for (inpexp in rul.inputExpression) {
```
```javascript
for (ftTarget in ftas) {
  if (firstelement = true) {
    for (evSource in ftSource.events) {
      if (ftTarget.name = "Fault Tree of " + evSource.name) {
        var nevEv = new emfta!Event;
        nevEv.name = evSource.name;
        if (evSource.gate.events.size() > 1) {
          nevEv = AssignNewType (evSource, nevEv);
          nevEv.gate = getGate (evSource. description);
          nevEv(probability = evSource. probability;
        ftTarget.events. add (nevEv);
        firstelement = false;
        generateFollowings (evSource, nevEv, ftTarget);
      }
      else if (evSource.gate.events. size() = 1) {
        getTheNextEvenWithOneEvent (evSource, nevEv, ftTarget, firstelement);
      }
    }
  }
}

//Cleaning fault tree;
cleanTree (ftTarget);
//Calculating probabilities
for (event in ftTarget.events) {
  if ("Fault Tree of " + event.name = ftTarget.name) {
    if (event. probability = 0) {
      var eventProb = 1;
      //get the gate attached to it (in case it is a OR gate)
      if (event.gate. type. name = "OR") {
        //check all following events and check if they are among the system's events
        for (ev in event.gate.events) {
          //sometimes these attached event includes the original events, they are
          excluded
          if (not (ev. name = event.name) and ftTarget.events. contains (ev)) {
            if (ev. type. name = "Intermediate") {
              var p = getProbability (ev, event.gate, ftTarget). asDouble ();
              eventProb = eventProb * (1 - p);
            }
            else {
              eventProb = eventProb * (1 - ev. probability);
            }
          }
        }
        event. probability = (1 - eventProb). asDouble ();
      }
      else if (event.gate. type. name = "AND") {
        for (ev in event.gate events) {
          if (not (ev. name = event.name) and ftTarget.events. contains (ev)) {
            if (ev. type. name = "Intermediate") {
              var p = getProbability (ev, event.gate, ftTarget). asDouble ();
              eventProb = eventProb * p;
            }
            else {
              eventProb = eventProb * (ev. probability);
            }
          }
        }
        event. probability = (eventProb). asDouble ();
      }
    }
  }
}

cleanGates (ftTarget);
}

operation getTheNextEvenWithOneEvent (evSource: emftanew!Event, nevEv: emfta!Event,
                                      ftTarget: emfta!FTAModel, firstelement: Boolean): Sequence {
  for (event in evSource.gate.events) {
    if (event. type. name = "Basic") {
      if (firstelement = true) {
        nevEv = AssignNewType (evSource, nevEv);
        nevEv.gate = getGate (evSource. description);
        nevEv. description = evSource. description;
        nevEv. probability = evSource. probability;
```
```javascript
111 ftTarget.events.add(nevEv);
112 firstelement=false;
113 var localEv= new emfta!Event;
114 localEv.name(event.name;
115 localEv.type= emfta!Type#Basic;
116 localEv description event description;
117 localEv(probability= event/probability;
118 nevEv.gate.events.add(localEv);
119 ftTarget.events.add(localEv);
120 parents.add(nevEv);
121 }
122 else {
123 firstelement=false;
124 nevEv.name(event.name;
125 nevEv.type= emfta!Type#Basic;
126 nevEv description event description;
127 nevEv(probability= event/probability;
128 ftTarget.events.add(nevEv);
129 parents.add(nevEv);
130 }
131 }
132 else if (event.type.name="External") {
133 if (firstelement=true) {
134 nevEv= AssignNewType(evSource, nevEv);
135 nevEv.gate = getGate(evSource. description);
136 nevEv. description evSource. description;
137 nevEv. probability= evSource. probability;
138 ftTarget.events.add(nevEv);
139 firstelement=false;
140 var localEv= new emfta!Event;
141 localEv.name(event.name;
142 localEv.type= emfta!EventType#External;
143 localEv. description event. description;
144 localEv. probability= event. probability;
145 nevEv.gate.events.add(localEv);
146 ftTarget.events.add(localEv);
147 parents.add(nevEv);
148 }
149 else {
150 firstelement=false;
151 nevEv.name(event.name;
152 nevEv.type= emfta!EventType#External;
153 nevEv. description event. description;
154 nevEv. probability= event. probability;
155 ftTarget.events.add(nevEv);
156 parents.add(nevEv);
157 }
158 }
159 else if (event.type.name="Intermediate") {
160 if (event. description. split("_"). get(1)= evSource. description. split("_"). get(1)) {
161 if (event.gate.events. size() >1) {
162 if (firstelement=false) {
163 nevEv.name= evSource.name;
164 }
165 nevEv= AssignNewType(event, nevEv);
166 nevEv.gate = getGate(event. description);
167 nevEv. description= event. description;
168 nevEv. probability= event. probability;
169 ftTarget.events. add(nevEv);
170 firstelement=false;
171 generateFollowings (event, nevEv, ftTarget);
172 }
173 else if (event.gate events. size()=1) {
174/TheNextEvenWithOneEvent (event, nevEv, ftTarget, firstelement);
175 }
176 }
177 }
178 else {
179 //in case the two single events are not the same
180 //implement the source and check the next event properties
181 nevEv= AssignNewType(evSource, nevEv);
182 nevEv.gate = getGate(evSource. description);
183 nevEv. description= evSource. description;
184 nevEv. probability= evSource. probability;
```
```pascal
ftTarget.events.add(nevEv);
firstelement=false;
if(event.gate.events.size() > 1) {
  // if greater than one and different form source.. implement that
  var localEv = new emfta!Event;
  localEv.name = event.name;
  localEv = AssignNewType(event, localEv);
  localEv.gate = getGate(event description);
  localEv description = event description;
  localEv(probability = event(probability;
  nevEv.gate.events.add(localEv);
  ftTarget.events.add(localEv);
  generateFollowings(event, localEv, ftTarget);
}
else if (event.gate.events.size() = 1) {
  // else implement half and look the next different of many child event
  var localEv = new emfta!Event;
  localEv.name = event.name;
  nevEv.gate.events.add(localEv);
  getTheNextEvenWithOneEvent(event, localEv, ftTarget, firstelement);
}
}
}
else if (event.type.name = "Undeveloped") {
  if (firstelement = true) {
    nevEv = AssignNewType(evSource, nevEv);
    nevEv.gate = getGate(evSource. description);
    nevEv. description = evSource. description;
    nevEv. probability = evSource. probability;
    ftTarget.events. add (nevEv);
    firstelement = false;
    var localEv = new emfta!Event;
    localEv.name = event.name;
    localEv. type = emfta!EventType # Undeveloped;
    localEv. description = event. description;
    localEv. probability = event. probability;
    nevEv.gate.events. add (localEv);
    ftTarget.events. add (localEv);
    parents. add (nevEv);
  }
  else {
    firstelement = false;
    nevEv.name = event.name;
    nevEv. type = emfta!EventType # Undeveloped;
    nevEv. description = event. description;
    nevEv. probability = event. probability;
    ftTarget.events. add (nevEv);
    parents. add (nevEv);
  }
}
}
}
}
operation generateFollowings (lookEv: emftanew!Event, grobalEv : emfta!Event,
                                 ft: emfta!FTAModel) : Sequence {
  for (event in lookEv.gate.events) {
    if (event.gate.events.size() > 1) {
      var localEv = new emfta!Event;
      localEv.name = event.name;
      localEv = AssignNewType(event, localEv);
      localEv.gate = getGate(event. description);
      localEv. description = event. description;
      localEv. probability = event. probability;
      grobalEv.gate events. add (localEv);
      ft.events. add (localEv);
      generateFollowings (event, localEv, ft);
    }
    else if (event.gate events. size() = 1) {
      var localEv = new emfta!Event;
      localEv.name = event.name;
      grobalEv.gate events. add (localEv);
      getTheNextEvenWithOneEvent (event, localEv, ft, false);
    }
  }
}
```
```pascal
 operation getGate(st : String): emfta!Gate{
 259 }
 260
 261 var g=new emfta!Gate;
 262 for (gate in emftanew!Gate.allInstances()){
 263 if (gate description = st) {
 264 if (gate.type.name="OR") {
 265   g.type=emfta!GateType#OR;
 266 }
 267 else {
 268   g.type=emfta!GateType#AND;
 269 }
 270 g description=gate description;
 271 for (oldEv in gate.events) {
 272   var evTemp=new emfta!Event;
 273   evTemp.name=oldEv.name;
 274   evTemp=AssignNewType (oldEv, evTemp);
 275   evTemp description=oldEv description;
 276   g.events.add (evTemp);
 277 }
 278 g nbOccurrences=gate nbOccurrences;
 279 return g;
 280 }
 281 }
 282 }
 283
 operation AssignNewType (oldEv: emftanew!Event, evTemp: emfta!Event): emfta!Event{
 284 if (oldEv.type.name="External") {
 285   evTemp.type=emfta!EventType#External;
 286 }
 287 else if (oldEv.type.name="Basic") {
 288   evTemp.type=emfta!EventType#Basic;
 289 }
 290 else {
 291   evTemp.type=emfta!EventType#Intermediate;
 292 }
 293 return evTemp;
 294 }
 295 }
 operation getProbability(lookEv: emfta!Event, gate : emfta!Gate,
 296                      ftTarget:emfta!FTAModel) : Any{
 297 var eProb=1;
 298 //Same process but here we need to return the lookEV probability
 300 if (lookEv.gate.type.name="OR") {
 301   for (ev in lookEv.gate.events) {
 302     if (not (ev.name = lookEv.name) and ftTarget.events contains (ev)) {
 303       if (ev.type.name="Intermediate") {
 304         var p=getProbability(ev,lookEv.gate,ftTarget).asDouble();
 305         eProb=eProb*(1-p);
 306       }
 307     else {
 308       eProb=eProb*(1-ev(probability);
 309     }
 310   }
 311 }
 312 lookEv(probability=(1-eProb).asDouble();
 313 return lookEv(probability;
 315 }
 316 else if (lookEv.gate.type.name="AND") {
 317   for (ev in lookEv.gate events) {
 318     if (not (ev.name = lookEv.name) and ftTarget.events contains (ev)) {
 319       if (ev.type.name="Intermediate") {
 320         var p=getProbability(ev,lookEv.gate,ftTarget).asDouble();
 321         eProb=eProb*p;
 322       }
 323     else {
 324       eProb=eProb*(ev(probability);
 325     }
 326   }
 327 }
 328 lookEv(probability=(eProb).asDouble();
 329 return lookEv(probability;
 330 }
 331 }
 332 return lookEv(probability;
```
```pascal
333 }
334 operation cleanTree(ftTarget : emfta!FTAModel) : Any{
335     var k=0;
336     var gates= emfta!Gate.allInstances();
337     var toRemove : emfta!Event;
338     while (k<gates.size()) {
339         var gate= gates.at(k);
340         var i=0;
341         var eventsLocal=gate.events;
342         while (i<eventsLocal.size()) {
343             if (not (eventsLocal.at(i).type.name="Intermediate")) {
344                 var name=eventsLocal.at(i).name;
345                 if (i+1<eventsLocal.size()) {
346                     if (name= eventsLocal.at(i+1).name) {
347                         //remove duplicated paths
348                         toRemove= eventsLocal.at(i);
349                         ftTarget.events.remove(toRemove);
350                         eventsLocal.remove/eventsLocal.at(i));
351                         emfta!Event.allInstances().remove/eventsLocal.at(i));
352                         parents.remove/eventsLocal.at(i));
353                     }
354                 }
355             }i=i+1;
356         }k=k+1;
357     }
358 }
359 operation cleanGates(ftTarget : emfta!FTAModel) : Any{
360     var k=0;
361     var gates= emfta!Gate.allInstances();
362     var toRemove : emfta!Event;
363     while (k<gates.size()) {
364         var gate= gates.at(k);
365         if (gate.events.size()<4) {
366             gate.type=emfta!GateType#INTERMEDIATE;
367             gate description="propagations and/or \n transformations";
368         }k=k+1;
369     }
370 }
```

<caption>Listing B.2: FT2FT ETL transformation rules</caption>
# Appendix C

## Installing CHESSIoT extension on top of CHESS

The infrastructure that was implemented to test and validate our approach was implemented on top of CHESS1.0.0. Although a newer version of CHESS (1.1.0) was been recently released, we haven't yet tested with our implementations. Therefore the following steps only apply to the CHESS1.0.0 version. In this section We show you the steps to follow in order to successfully install the extension:

1. Prerequisite:

* Jdk/Java 8 (Mandatory not 11 or above)

* Git client (optional)

* Window OS

2. Download CHESS1.0.0 for Window OS from CHESS1.0.0 main page and extract it

3. Clone the repository contains CHESSIoTFeatures
   "git clone https://github.com/fihirwe/CHESSIoT-features.git"

4. The CHESSIoT source code can be accessed through this CHESSIoTplugins git repo.

5. Launch CHESS.exe to start CHESS.

6. To install the CHESSIoT features proceed to Help-> Install New Software-> Add-> Local ->
   Browse your computer then pick the folder with all of the extracted content and hit Finish.

7. When loading is finished make sure to uncheck the "Group items by category" option and select "CHESSIoT extension supported FTA, ThingML model generation and IoT deployment support" features and Click next to continue

8. Click next for CHESSIoT updates on already existing installation

9. Accepts the license

10. This will take a few seconds or minutes to load and download all the dependencies.

11. After few moment remeber to "Agree to install unsigned contents"

12. When the process is finished, you will need to restart your CHESS tool.

13. Voila! Now you are ready to explore CHESSIoT!!
Bibliography

[1] Alexandru Serbanati, Carlo Maria Medaglia, and Ugo Biader Ceipidor. Building blocks of the internet of things: State of the art and beyond. *Deploying RFID-Challenges, Solutions, and Open Issues*, pages 351–366, 2011.

[2] Team CHESS, 2020. URL https://www.eclipse.org/chess/publis/CHESSToolsetGuide.pdf.

[3] Zulqarnain Haider, Barbara Gallina, and Enrique Zornoza Moreno. FLA2FT: Automatic generation of fault tree from ConcertoFLA results. In *2018 3rd International Conference on System Reliability and Safety (ICSRS)*, pages 176–181, 2018. doi: 10.1109/ICSRS.2018.8688825.

[4] Bashar Alshboul, Dorina C. Petriu, Bashar Alshboul, and Dorina C. Petriu. Automatic derivation of fault tree models from SysML models for safety analysis. *Journal of Software Engineering and Applications*, 11:204–222, 5 2018. ISSN 1945-3116. URL https://doi.org/10.4236/jsea.2018.115013.

[5] Rajesh Kannan Megalingam, Divya M. Kaimal, and Maneesha V. Ramesh. Efficient patient monitoring for multiple patients using wsn. In *2012 International Conference on Advances in Mobile Network, Communication and Its Applications*, pages 87–90, 2012. doi: 10.1109/MNCA Apps.2012.23.

[6] Petri Kettunen and Maarit Laanti. Future software organizations – agile goals and roles. *European Journal of Futures Research*, 5(1):16, 2017. ISSN 2195-2248. doi: 10.1007/s40309-017-0123-7. URL https://doi.org/10.1007/s40309-017-0123-7.

[7] Martin Bauer, Mathieu Boussard, Nicola Bui, Jourik De Loof, Carsten Magerkurth, Stefan Meissner, Andreas Nettsträter, Julinda Stefa, Matthias Thoma, and Joachim W. Walewski. IoT Reference Architecture, pages 163–211. Springer Berlin Heidelberg, Berlin, Heidelberg, 2013. ISBN 978-3-642-40403-0. doi: 10.1007/978-3-642-40403-0_8. URL https://doi.org/10.1007/978-3-642-40403-0_8.

[8] Felicien Ihirwe, Davide Di Ruscio, Silvia Mazzini, Pierluigi Pierini, and Alfonso Pierantonio. Low-Code engineering for internet of things: A state of research. In *In the 23rd ACM/IEEE MODELS'20: Companion Proceedings*, MODELS '20, New York, NY, USA, 2020. Association for Computing Machinery. ISBN 9781450381352. doi: 10.1145/3417990.3420208. URL https://doi.org/10.1145/3417990.3420208.

[9] Abel Gómez, Markel Iglesias-Urkia, Lorea Belategi, Xabier Mendialdua, and Jordi Cabot. Model-driven development of asynchronous message-driven architectures with AsyncAPI. *Software and Systems Modeling*, pages 1–29, 2021. URL https://doi.org/10.1007/s10270-021-00945-3.

[10] Arsene Indamutsa, Davide Di Ruscio, and Alfonso Pierantonio. A Low-Code Development Environment to Orchestrate Model Management Services. *Advances in Production Management Systems*, 2021.
[11] Massimo Tisi, Jean-Marie Mottu, Dimitrios S. Kolovos, Juan De Lara, Esther M Guerra, Davide Di Ruscio, Alfonso Pierantonio, and Manuel Wimmer. Lowcomote: Training the next generation of experts in scalable low-code engineering platforms. *1st Junior Researcher Community Event*, page 67–76, July 2019. URL https://hal.archives-ouvertes.fr/hal-02363416.

[12] Aymen J Salman, Mohammed Al-Jawad, and Wisam Al Tameemi. Domain-Specific Languages for IoT: Challenges and Opportunities. *IOP Conference Series: Materials Science and Engineering*, 1067(1):012133, 2021. ISSN 1757-8981. doi: 10.1088/1757-899x/1067/1/012133.

[13] F. Ihirwe, A. Indamutsa, D. Ruscio, S. Mazzini, and A. Pierantonio. Cloud-based modeling in IoT domain: a survey, open challenges and opportunities. In *2021 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C)*, pages 73–82, Los Alamitos, CA, USA, oct 2021. IEEE Computer Society. doi: 10.1109/MODELS-C53483.2021.00018.

[14] ISO ISO. ISO/IEC 25010:2011, Systems and software engineering - Systems and Software Quality Requirements and Evaluation (SQuaRE) - System and software quality models. *ISO*, 34:2910, 2011. URL https://www.iso.org/standard/35733.html. Last accessed March 2022.

[15] John Hutchinson, Jon Whittle, and Mark Rouncefield. Model-driven engineering practices in industry: Social, organizational and managerial factors that lead to success or failure. *Science of Computer Programming*, 89:144–161, 2014. ISSN 0167-6423. doi: https://doi.org/10.1016/j.scico.2013.03.017. URL http://www.sciencedirect.com/science/article/pii/S0167642313000786. Special issue on Success Stories in Model Driven Engineering.

[16] Alberto Debiasi, Felicien Ihirwe, Pierluigi Pierini, Silvia Mazzini, and Stefano Tonetta. Model-based analysis support for dependable complex systems in CHESS. In *Proceedings of the 9th International Conference on Model-Driven Engineering and Software Development - Volume 1: MODELSWARD*, pages 262–269. INSTICC, SciTePress, 2021. ISBN 978-989-758-487-9. doi: 10.5220/0010269702620269. URL https://doi.org/10.5220/0010269702620269.

[17] Jörg Christian Kirchhof, Bernhard Rumpe, David Schmalzing, and Andreas Wortmann. MoniThings: Model-driven development and deployment of reliable IoT applications. *Journal of Systems and Software*, 183:111087, 2022. ISSN 0164-1212. doi: https://doi.org/10.1016/j.jss.2021.111087. URL https://doi.org/10.1016/j.jss.2021.111087.

[18] Azham Hussain and Emmanuel Mkpojiogu. An application of the ISO/IEC 25010 standard in the quality-in-use assessment of an online health awareness system. *Jurnal Teknologi*, 77:9–13, 11 2015. doi: 10.11113/jt.v77.6107. URL https://doi.org/10.11113/jt.v77.6107.

[19] Eddas Bertrand-Martinez, Phelipe Dias Feio, Vagner de Brito Nascimento, Fabio Kon, and Antônio Abelém. Classification and evaluation of IoT brokers: A methodology. *International Journal of Network Management*, 31(3), may 2021. ISSN 1099-1190. doi: 10.1002/nem.2115. URL https://doi.org/10.1002/nem.2115.

[20] Johan J.C. Tambotoh, Sani M. Isa, Ford Lumban Gaol, Benfano Soewito, and Harco Leslie Hendric Spits Warnars. Software quality model for internet of things governance. In *2016 International Conference on Data and Software Engineering (ICODSE)*, pages 1–6, 2016. doi: 10.1109/ICODSE.2016.7936138. URL https://doi.org/10.1109/ICODSE.2016.7936138.

[21] Md. Saifur Rahman and Hassan Reza. Systematic mapping study of non-functional requirements in big data system. In *2020 IEEE International Conference on Electro Information Technology (EIT)*, pages 025–031, 2020. doi: 10.1109/EIT48999.2020.9208288. URL http://dx.doi.org/10.1109/EIT48999.2020.9208288.
[22] Julien Siebert, Lisa Jöckel, Jens Heidrich, Koji Nakamichi, Kyoko Ohashi, Isao Namba, Rieko Yamamoto, and Mikio Aoyama. Towards guidelines for assessing qualities of machine learning systems. In *13th International Conference on Quality of Information and Communications Technology - , QUATIC 2020, Faro, Portugal, September 9-11, 2020*, volume 1266, pages 17–31, 2020. doi: 10.1007/978-3-030-58793-2\_2. URL https://doi.org/10.1007/978-3-030-58793-2_2.

[23] Almeida Martins Luana, Afonso Júnior Paulo, Pimenta Freire André, and Costa Heitor. *IET Software*, 14:572–581(9), December 2020. ISSN 1751-8806. URL https://doi.org/10.1049/iet-sen.2020.0037.

[24] Jhonatan Bernardes Boarim and Ana Regina Cavalcanti da Rocha. CRM systems quality evaluation. In *XX Brazilian Symposium on Software Quality, SBQS '21, New York, NY, USA, 2021. Association for Computing Machinery*. ISBN 9781450395533. doi: 10.1145/3493244.3493273. URL https://doi.org/10.1145/3493244.3493273.

[25] Janine Koepp, Miriam Viviane Baron, Paulo Ricardo Hernandes Martins, Cristine Brandenburg, and et al. The quality of mobile apps used for the identification of pressure ulcers in adults: Systematic survey and review of apps in app stores. *JMIR Mhealth Uhealth*, 8(6):e14266, Jun 2020. ISSN 2291-5222. doi: 10.2196/14266. URL https://doi.org/10.2196/14266.

[26] Lenin Erazo-Garzón, Priscila Cedillo, Gustavo Rossi, and José Moyano. A domain-specific language for modeling IoT system architectures that support monitoring. *IEEE Access*, 10: 61639–61665, 2022. doi: 10.1109/ACCESS.2022.3181166.

[27] Felicien Ihirwe, Davide Di Ruscio, Simone Gianfranceschi, and Alfonso Pierantonio. Assessing the quality of Low-Code and MDE platforms for engineering IoT systems. *22nd IEEE International Conference on Software Quality, Reliability, and Security (QRS22)*, 2022. doi: http://dx.doi.org/10.2139/ssrn.4267269.

[28] Alexander Power and Gerald Kotonya. Providing fault tolerance via complex event processing and machine learning for IoT systems. In *Proceedings of the 9th International Conference on the Internet of Things*, IoT 2019, New York, NY, USA, 2019. Association for Computing Machinery. ISBN 9781450372077. doi: 10.1145/3365871.3365872. URL https://doi.org/10.1145/3365871.3365872.

[29] Antero Taivalsaari and Tommi Mikkonen. A roadmap to the programmable world: Software challenges in the IoT era. *IEEE Software*, 34(1):72–80, 2017. doi: 10.1109/MS.2017.26. URL https://doi.org/10.1109/MS.2017.26.

[30] Akram Amin Abdellatif and Florian Holzapfel. Model based safety analysis (MBSA) tool for avionics systems evaluation. In *2020 AIAA/IEEE 39th Digital Avionics Systems Conference (DASC)*, pages 1–5, 2020. URL https://doi.org/10.1109/DASC50938.2020.9256578.

[31] A. Joshi, S.P. Miller, M. Whalen, and M.P.E. Heimdahl. A proposal for model-based safety analysis. In *24th Digital Avionics Systems Conference, volume 2*, pages 13 pp. Vol. 2–, 2005. URL https://doi.org/10.1109/DASC.2005.1563469.

[32] Gaëlle Girard, Ivan Baeriswyl, Jonathan James Hendriks, Roland Scherwey, Christian Müller, Philipp Hönig, and Rüdiger Lunde. Model based safety analysis using sysml with automatic generation of FTA and FMEA artifacts. In *Proceedings of the 30th European Safety and Reliability Conference and the 15th Probabilistic Safety Assessment and Management Conference (Esrel 2020 PSAM 15)*, 1-5 November 2020, Venice, Italy, number CONFERENCE. 1-5 November 2020, 2020.
[33] Richard F Paige, Louis M Rose, Xiaocheng Ge, Dimitrios S Kolovos, and Phillip J Brooke. FPTC: Automated Safety Analysis for Domain-Specific Languages. In Michel R V Chaudron, editor, *Models in Software Engineering*, pages 229–242, Berlin, Heidelberg, 2009. Springer Berlin Heidelberg. ISBN 978-3-642-01648-6.

[34] Federico Ciccozzi, Ivica Crnkovic, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, and Romina Spalazzese. Model-driven engineering for mission-critical IoT systems. *IEEE Software*, 34(1):46–53, 2017. doi: 10.1109/MS.2017.1. URL https://doi.org/10.1109/MS.2017.1.

[35] Davide Di Ruscio, Romina Eramo, Alfonso Pierantonio, Marco Bernardo, Vittorio Cortellessa, and Alfonso Pierantonio. *Model Transformations*, pages 91–136. Springer Berlin Heidelberg, Berlin, Heidelberg, 2012. ISBN 978-3-642-30982-3_4. URL https://doi.org/10.1007/978-3-642-30982-3_4.

[36] Federico Ciccozzi and Romina Spalazzese. MDE4IoT: Supporting the internet of things with model-driven engineering. In Costin Badica, Amal El Fallah Seghrouchni, Aurélie Beynier, David Camacho, Cédric Herpson, Koen Hindriks, and Paulo Novais, editors, *Intelligent Distributed Computing X*, pages 67–76, Cham, 2017. Springer International Publishing. ISBN 978-3-319-48829-5. doi: 10.1007/978-3-319-48829-5_7. URL http://dx.doi.org/10.1007/978-3-319-48829-5_7.

[37] Nicolas Harrand, Franck Fleurey, Brice Morin, and Knut Eilif Husa. ThingML: A language and code generation framework for heterogeneous targets. In *Proceedings of the ACM/IEEE 19th International Conference on Model Driven Engineering Languages and Systems*, MOD-ELS '16, page 125–135, New York, NY, USA, 2016. Association for Computing Machinery. ISBN 9781450343213. doi: 10.1145/2976767.2976812. URL https://doi.org/10.1145/2976767.2976812.

[38] Richard Nicholson, Timothy Ward, Derek Baum, Xu Tao, Davide Conzon, and Enrico Ferrera. Dynamic fog computing platform for event-driven deployment and orchestration of distributed internet of things applications. In *2019 Third World Conference on Smart Trends in Systems Security and Sustainability (WorldS4)*, pages 239–246, 2019. doi: 10.1109/WorldS4.2019.8903975.

[39] Davide Conzon, Mohammad Rifat Ahmmad Rashid, Xu Tao, Angel Soriano, Richard Nicholson, and Enrico Ferrera. BRAIN-IoT: Model-based framework for dependable sensing and actuation in intelligent decentralized IoT systems. In *2019 4th International Conference on Computing, Communications and Security (ICCCS)*, pages 1–8, 2019. doi: 10.1109/CCCS.2019.8888136. URL http://dx.doi.org/10.1109/CCCS.2019.8888136.

[40] José A. Barriga, Pedro J. Clemente, Encarna Sosa-Sanchez, and Alvaro E. Prieto. SimulateIoT: Domain specific language to design, code generation and execute IoT simulation environments. *IEEE Access*, 9:92531–92552, 2021. doi: 10.1109/ACCESS.2021.3092528. URL http://dx.doi.org/10.1109/ACCESS.2021.3092528.

[41] Liudong Xing and Suprasad V. Amari. *Fault Tree Analysis*, pages 595–620. Springer London, London, 2008. ISBN 978-1-84800-131-2. doi: 10.1007/978-1-84800-131-2_38. URL https://doi.org/10.1007/978-1-84800-131-2_38.

[42] Felicien Ihirwe, Davide Di Ruscio, Silvia Mazzini, and Alfonso Pierantonio. Towards a modeling and analysis environment for industrial IoT systems. *STAF Workshops*, abs/2105.14136: 90–104, 2021. URL https://ceur-ws.org/Vol-2999/messpaper1.pdf.
[43] Felicien Ihirwe, Davide Di Ruscio, Silvia Mazzini, and Alfonso Pierantonio. A domain-specific modeling and analysis environment for complex IoT applications. CoRR, abs/2109.09244, 2021. URL https://arxiv.org/abs/2109.09244.

[44] Barbara Gallina, Muhammad Atif Javed, Faiz Ul Muram, and Sasikumar Punnekkat. A model-driven dependability analysis method for component-based architectures. In 2012 38th Euromicro Conference on Software Engineering and Advanced Applications, pages 233–240, 2012. doi: 10.1109/SEAA.2012.35.

[45] Barbara Gallina, Edin Sefer, and Atle Refsdal. Towards safety risk assessment of socio-technical systems via failure logic analysis. In ISSRE Workshops, pages 287–292, 2014.

[46] A.S. Cheliyan and S.K. Bhattacharyya. Fuzzy fault tree analysis of oil and gas leakage in subsea production systems. Journal of Ocean Engineering and Science, 3(1):38–48, 2018. ISSN 2468-0133. doi: https://doi.org/10.1016/j.joes.2017.11.005. URL https://doi.org/10.1016/j.joes.2017.11.005.

[47] Stefan Markulik, Marek Šolc, Jozef Petrík, Michaela Balážiková, Peter Blaško, Juraj Kliment, and Martin Bezák. Application of FTA analysis for calculation of the probability of the failure of the pressure leaching process. Applied Sciences, 11(15), 2021. ISSN 2076-3417. doi: 10.3390/app11156731. URL https://www.mdpi.com/2076-3417/11/15/6731.

[48] Refaul Ferdous, Faisal Khan, Brian Veitch, and Paul R. Amyotte. Methodology for computer aided fuzzy fault tree analysis. Process Safety and Environmental Protection, 87(4):217–226, 2009. ISSN 0957-5820. doi: https://doi.org/10.1016/j.psep.2009.04.004. URL https://www.sciencedirect.com/science/article/pii/S0957582009000421.

[49] A. Bassi, M. Bauer, M. Fiedler, T. Kramp, R. van Kranenburg, S. Lange, S. Meissner, and Eds. Enabling things to talk: Designing IoT solutions with the IoT Architectural Reference Model. Springer Berlin Heidelberg, 2013. ISBN 978-3-642-40402-3. doi: 10.1007/978-3-642-40403-0.

[50] Bruno Costa, Paulo F. Pires, and Flávia C. Delicato. Modeling IoT applications with SysML4IoT. In 2016 42th Euromicro Conference on Software Engineering and Advanced Applications (SEAA), pages 157–164, 2016. doi: 10.1109/SEAA.2016.19.

[51] Ajay Krishna Muroor Nadumane. Models and Verification for Composition and Reconfiguration of Web of Things Applications. Theses, Université Grenoble Alpes [2020-....], December 2020. URL https://theses.hal.science/tel-03188299.

[52] Jonathan Ostroff, Susan Gerhart, Dan Craigen, Ted Ralston, Nancy G. Leveson, Jonathan Bowen, and Victoria Stavridou. Real-Time and Safety-Critical Systems, pages 359–528. Springer London, London, 1999. ISBN 978-1-4471-3431-2. doi: 10.1007/978-1-4471-3431-2_6. URL https://doi.org/10.1007/978-1-4471-3431-2_6.

[53] John C. Knight. Safety critical systems: Challenges and directions. In Proceedings of the 24th International Conference on Software Engineering, ICSE '02, pages 547–550, New York, NY, USA, 2002. Association for Computing Machinery. ISBN 158113472X. doi: 10.1145/581339. 581406. URL https://doi.org/10.1145/581339.581406.

[54] Jonathan Bowen. The ethics of safety-critical systems. Commun. ACM, 43(4):91–97, apr 2000. ISSN 0001-0782. doi: 10.1145/332051.332078. URL https://doi.org/10.1145/332051.332078.

[55] Jaehyung An, Alexey Mikhaylov, and Keunwoo Kim. Machine learning approach in heterogeneous group of algorithms for transport safety-critical system. Applied Sciences, 10(8), 2020.
ISSN 2076-3417. doi: 10.3390/app10082670. URL https://www.mdpi.com/2076-3417/10/8/2670.

[56] W.R. Dunn. Designing safety-critical computer systems. *Computer*, 36(11):40–46, 2003. doi: 10.1109/MC.2003.1244533.

[57] Raj kamal Kaur, Babita Pandey, and Lalit Kumar Singh. Dependability analysis of safety critical systems: Issues and challenges. *Annals of Nuclear Energy*, 120:127–154, 2018. ISSN 0306-4549. doi: https://doi.org/10.1016/j.anucene.2018.05.027. URL https://www.sciencedirect.com/science/article/pii/S030645491730213X.

[58] Davide Di Ruscio, Dimitris Kolovos, Juan de Lara, Alfonso Pierantonio, Massimo Tisi, and Manuel Wimmer. Low-Code development and model-driven engineering: Two sides of the same coin? *Software and Systems Modeling*, 21:437–446, 2022. ISSN 1619-1374. doi: 10.1007/s10270-021-00970-2. URL https://doi.org/10.1007/s10270-021-00970-2.

[59] Luca Berardinelli, Alexandra Mazak, Oliver Alt, and Manuel Wimmer. *Model-Driven Systems Engineering: Principles and Application in the CPPS Domain*, pages 261–299. 05 2017. ISBN 978-3-319-56344-2.

[60] Marco Brambilla, Jordi Cabot, and Manuel Wimmer. *Model-Driven Software Engineering in Practice*. 2012. ISBN 9781608458820. doi: 10.2200/s00441ed1v01y201208swe001.

[61] Paulo F. Pires, Bruno Costa, Flávia C. Delicato, Wei Li, and Albert Y. Zomaya. Design and analysis of IoT applications: A model driven approach. *2016 IEEE 14th Intl Conf on Dependable, Autonomic and Secure Computing*, pages 392–399, 2016. doi: 10.1109/DASC-PICom-DataCom-CyberSciTec.2016.81. URL http://dx.doi.org/10.1109/DASC-PICom-DataCom-CyberSciTec.2016.81.

[62] A. Bucchiarone, F. Ciccozzi, L. Lambers, A. Pierantonio, M. Tichy, M. Tisi, A. Wortmann, and V. Zaytsev. What is the future of modeling? *IEEE Software*, 38(02):119–127, mar 2021. ISSN 1937-4194. doi: 10.1109/MS.2020.3041522.

[63] Jiwei Huang, Songyuan Li, Ying Chen, and Junliang Chen. Performance modeling and analysis for iot services. *International Journal of Web and Grid Services*, 14:146, 01 2018. doi: 10.1504/IJWGS.2018.090742.

[64] Antonio Bucchiarone, Jordi Cabot, Richard F. Paige, and Alfonso Pierantonio. Grand challenges in model-driven engineering: An analysis of the state of the research. *Softw. Syst. Model.*, 19(1):5–13, jan 2020. ISSN 1619-1366. doi: 10.1007/s10270-019-00773-6.

[65] Davide Di Ruscio, Mirco Franzago, Ivano Malavolta, and Henry Muccini. Envisioning the future of collaborative model-driven software engineering. *Proceedings - 2017 IEEE/ACM 39th International Conference on Software Engineering Companion, ICSE-C 2017*, (May):219–221, 2017. doi: 10.1109/ICSE-C.2017.143.

[66] S. Chen, H. Xu, D. Liu, B. Hu, and H. Wang. A vision of iot: Applications, challenges, and opportunities with china perspective. *IEEE Internet of Things Journal*, 1(4):349–359, 2014.

[67] Ábel Hegedüs, Gábor Bergmann, Csaba Debreceni, Ákos Horváth, Péter Lunk, Ákos Menyhért, István Papp, Dániel Varró, Tomas Vileiniskis, and István Ráth. Inquery server for teamwork cloud: Scalable query evaluation over collaborative model repositories. *21st ACM/IEEE International Conference on Model Driven Engineering Languages and Systems: Companion Proceedings, MODELS-Companion 2018*, pages 27–31, 2018. doi: 10.1145/3270112.3270125.
[68] A. Cimatti, E. M. Clarke, E. Giunchiglia, F. Giunchiglia, M. Pistore, M. Roveri, R. Sebastiani, and A. Tacchella. NuSMV 2: An opensource tool for symbolic model checking. Technical report, University of Trento, Berlin, Heidelberg, 2002.

[69] Dang Tu Nguyen, Chengyu Song, Zhiyun Qian, Srikanth V. Krishnamurthy, Edward J. M. Colbert, and Patrick McDaniel. IotSan: Fortifying the safety of IoT systems. In *Proceedings of the 14th International Conference on Emerging Networking EXperiments and Technologies*, CoNEXT '18, pages 191–203, New York, NY, USA, 2018. Association for Computing Machinery. ISBN 9781450360807. doi: 10.1145/3281411.3281440. URL https://doi.org/10.1145/3281411.3281440.

[70] Marjan Mernik, Jan Heering, and Anthony M. Sloane. When and how to develop domain-specific languages. *ACM Comput. Surv.*, 37(4):316–344, dec 2005. ISSN 0360-0300. doi: 10.1145/1118890.1118892. URL https://doi.org/10.1145/1118890.1118892.

[71] Martin Fowler. *Domain Specific Languages*. Addison-Wesley Professional, 1st edition, 2010. ISBN 0321712943. URL https://dl.acm.org/doi/10.5555/1809745.

[72] Henry Muccini and Mohammad Sharaf. CAPS: Architecture description of situational aware cyber physical systems. In *2017 IEEE International Conference on Software Architecture (ICSA)*, pages 211–220, 2017. doi: 10.1109/ICSA.2017.21.

[73] Nicolas Ferry and et al. Development and operation of trustworthy smart iot systems: The ENACT framework. In *Software Engineering Aspects of Continuous Development and New Paradigms of Software Production and Deployment*, pages 121–138, 2020. ISBN 978-3-030-39306-9.

[74] Imad Berrouyne, Mehdi Adda, Jean-Marie Mottu, Jean-Claude Royer, and Massimo Tisi. CyprIoT: framework for modeling and controlling network-based IoT applications. In *In 34th ACM/SIGAPP Symposium on Applied Computing*, pages 832–841, 2019.

[75] Atefeh Torkaman and M.A.Seyyedi. Analyzing IoT referencearchitecture models. *International Journal of Computer Science and Software Engineering (IJCSSE)*, 5, 2016. ISSN 2409-4285.

[76] ISO & ICE. Study report on IoT reference architectures/frameworks, "August 2014". URL http://docplayer.net/16351625-Study-report-on-iot-reference-architectures-frameworks.html. July 2020.

[77] Paul Fremantle. A reference architecture for the internet of things, 10 2015. URL https://wso2.com/wso2_resources/wso2_whiteapproach_a-reference-architecture-for-the-internet-of-things.pdf.

[78] ESA Requirements and Standards Division. *Space Product Assurance - Fault Tree Analysis - Adoption Notice ECSS/IEC 61025*. ESA Publ. Division, 2008. URL https://ecss.nl/standards/active-standards/.

[79] ESA Requirements and Standards Division. *Failure modes, effects (and criticality) analysis (FMEA/FMECA)*. ESA Publ. Division, 2009. URL https://ecss.nl/standards/active-standards/.

[80] Jacopo Parri, Samuele Sampietro, and Enrico Vicario. FaultFlow: a tool supporting an mde approach for timed failure logic analysis. In *2021 17th European Dependable Computing Conference (EDCC)*, pages 25–32, 2021. doi: 10.1109/EDCC53658.2021.00011.
[81] Malcolm Wallace. Modular architectural representation and analysis of fault propagation and transformation. *Electronic Notes in Theoretical Computer Science*, 141(3):53-71, 2005. ISSN 1571-0661. doi: https://doi.org/10.1016/j.entcs.2005.02.051. URL http://www.sciencedirect.com/science/article/pii/S1571066105051650. FESCA 2005.

[82] Leonardo Montecchi and Barbara Gallina. SafeConcert: A metamodel for a concerted safety modeling of socio-technical systems. In Marco Bozzano and Yiannis Papadopoulos, editors, *Model-Based Safety and Assessment*, pages 129-144, Cham, 2017. Springer International Publishing. ISBN 978-3-319-64119-5.

[83] Diomidis H Stamatis. *Failure mode and effect analysis: FMEA from theory to execution*. Quality Press, 2003.

[84] Xiangyu Han and Jun Zhang. A combined analysis method of FMEA and FTA for improving the safety analysis quality of safety-critical software. In *2013 IEEE International Conference on Granular Computing (GrC)*, pages 353-356, 2013. URL https://doi.org/10.1109/GrC.2013.6740435.

[85] Mohsen Marjani, Fariza Nasaruddin, Abdullah Gani, Ahmad Karim, Ibrahim Abaker Targio Hashem, Aisha Siddiqa, and Ibrar Yaqoob. Big IoT Data Analytics: Architecture, Opportunities, and Open Research Challenges. *IEEE Access*, 5:5247-5261, 2017. ISSN 21693536. doi: 10.1109/ACCESS.2017.2689040.

[86] Laith Farhan, Sinan T. Shukur, Ali E. Alissa, Mohmad Alrweg, Umar Raza, and Rupak Kharel. A survey on the challenges and opportunities of the Internet of Things (IoT). *Proceedings of the International Conference on Sensing Technology, ICST*, 2017-Decem(December):1-5, 2017. ISSN 21568073. doi: 10.1109/ICSensT.2017.8304465.

[87] Apurvanand Sahay, Arsene Indamutsa, Davide Di Ruscio, and Alfonso Pierantonio. Supporting the understanding and comparison of low-code development platforms. In *2020 46th Euromicro Conference on Software Engineering and Advanced Applications (SEAA)*, pages 171-178, 2020. doi: 10.1109/SEAA51224.2020.00036. URL https://doi.org/10.1109/SEAA51224.2020.00036.

[88] Jordi Cabot. Positioning of the low-code movement within the field of model-driven engineering. In *Proceedings of the 23rd ACM/IEEE International Conference on Model Driven Engineering Languages and Systems: Companion Proceedings*, MODELS '20, New York, NY, USA, 2020. Association for Computing Machinery. ISBN 9781450381352. doi: 10.1145/3417990.3420210. URL https://doi.org/10.1145/3417990.3420210.

[89] Node-RED. Node-RED: Low-code programming for event-driven applications. https://nodered.org/, 2020. URL https://nodered.org/. Last accessed May 2020.

[90] AtmosphereIoT. Fast time to first data. https://atmosphereiot.com/, 2020. URL https://atmosphereiot.com/. Last accessed May 2020.

[91] Darnell Kenebrew. The difference between a software developer and a software engineer, Jan 2023. URL https://www.computerscience.org/resources/software-developer-vs-software-engineer/.

[92] RapidMiner Team. Amplify the impact of your people, expertise data, Oct 2022. URL https://rapidminer.com/.

[93] Shalin Hai-Jew. Running a 'deep learning' artificial neural network in rapidminer studio. *C2C Digital Magazine*, 1(10):17, 2019.
[94] Michael R. Berthold, Nicolas Cebron, Fabian Dill, Thomas R. Gabriel, Tobias Kötter, Thorsten Meinl, Peter Ohl, Kilian Thiel, and Bernd Wiswedel. Knime - the konstanz information miner: Version 2.0 and beyond. *SIGKDD Explor. Newsl.*, 11(1):26–31, nov 2009. ISSN 1931-0145. doi: 10.1145/1656274.1656280. URL https://doi.org/10.1145/1656274.1656280.

[95] Panagiotis Kourouklidis, Dimitris Kolovos, Joost Noppen, and Nicholas Matragkas. A model-driven engineering approach for monitoring machine learning models. In *2021 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C)*, pages 160–164, 2021. doi: 10.1109/MODELS-C53483.2021.00028.

[96] Lissette Almonte, Esther Guerra, Iván Cantador, and Juan De Lara. *Building Recommenders for Modelling Languages with Droid*. Association for Computing Machinery, New York, NY, USA, 2023. ISBN 9781450394758. URL https://doi.org/10.1145/3551349.3559521.

[97] Lissette Almonte, Sara Pérez-Soler, Esther Guerra, Iván Cantador, and Juan de Lara. Automating the synthesis of recommender systems for modelling languages. In *Proceedings of the 14th ACM SIGPLAN International Conference on Software Language Engineering, SLE 2021, page 22–35, New York, NY, USA, 2021*. Association for Computing Machinery. ISBN 9781450391115. doi: 10.1145/3486608.3486905. URL https://doi.org/10.1145/3486608.3486905.

[98] Claudio Di Sipio, Juri Rocco, Davide Di Ruscio, and Phuong Nguyen. Lev4rec: A low-code environment to support the development of recommender systems, 04 2022.

[99] Antonio Cicchetti, Federico Ciccozzi, Silvia Mazzini, Stefano Puri, Marco Panunzio, Alessandro Zovi, and Tullio Vardanega. CHESS: a model-driven engineering tool environment for aiding the development of complex industrial systems. In *2012 Proceedings of the 27th IEEE/ACM International Conference on Automated Software Engineering*, pages 362–365, 2012. doi: 10.1145/2351676.2351748.

[100] W. Godard and Geoffrey Nelissen. Model-based design and schedulability analysis for avionic applications on multicore platforms. *Ada User Journal*, 37(3):157–163, 09 2016. ISSN 1381-6551.

[101] L. Bressan, A. L. de Oliveira, L. Montecchi, and B. Gallina. A systematic process for applying the CHESS methodology in the creation of certifiable evidence. In *EDCC*, pages 49–56, 2018.

[102] Lorenzo Pace, Mauro Pasquinelli, Diego Gerbaz, Joachim Fuchs, Valter Basso, S. Mazzini, Laura Baracchi, Stefano Puri, Marco Lassalle, and Juhani Viitaniemi. Model-based approach for the verification enhancement across the lifecycle of a space system. In *INCOSE CIISE2014*, 10 2014.

[103] Silvia Mazzini. The CONCERTO project: An open source methodology for designing, deploying, and operating reliable and safe cps systems. *Ada User Journal*, 36:264–267, December 2015.

[104] B. Gallina, E. Sefer, and A. Refsdal. Towards safety risk assessment of socio-technical systems via failure logic analysis. In *ISSRE Workshops*, pages 287–292, 2014.

[105] Mahmood Shafiee, Evenye Enjema, and Athanasios Kolios. An integrated FTA-FMEA model for risk analysis of engineering systems: A case study of subsea blowout preventers. *Applied Sciences*, 9(6):1192, Mar 2019. ISSN 2076-3417. doi: 10.3390/app9061192. URL http://dx.doi.org/10.3390/app9061192.

[106] Laura Baracchi Silvia Mazzini, John Favaro. A model-based approach across the IoT lifecycle for scalable and distributed smart applications. pages 149–154, 2015. doi: 10.1109/ITSC.2015.33.
[107] Marco Panunzio and Tullio Vardanega. A component-based process with separation of concerns for the development of embedded real-time software systems. *Journal of Systems and Software*, 96:105-121, 2014. ISSN 0164-1212. doi: https://doi.org/10.1016/j.jss.2014.05.076. URL http://www.sciencedirect.com/science/article/pii/S0164121214001381.

[108] A. Bondavalli, I. Mura, S. Chiaradonna, R. Filippini, S. Poli, and F. Sandrini. DEEM: a tool for the dependability modeling and evaluation of multiple phased systems. In *DSN 2000*, pages 231-236, 2000. doi: 10.1109/ICDSN.2000.857541.

[109] Leonardo Montecchi, Paolo Lollini, and Andrea Bondavalli. A reusable modular toolchain for automated dependability evaluation. In *VALUETOOLS*, pages 298-303. ICST, 2013. ISBN 9781936968480. doi: 10.4108/icst.valuetools.2013.254395. URL https://doi.org/10.4108/icst.valuetools.2013.254395.

[110] Roberto Cavada, Alessandro Cimatti, Michele Dorigatti, Alberto Griggio, Alessandro Mariotti, Andrea Micheli, Sergio Mover, Marco Roveri, and Stefano Tonetta. The nuXmv Symbolic Model Checker. In Armin Biere and Roderick Bloem, editors, *CAV*, pages 334-342, Cham, 2014. Springer. ISBN 978-3-319-08867-9. doi: 10.1007/978-3-319-08867-9_22. URL https://doi.org/10.1007/978-3-319-08867-9_22.

[111] Alessandro Cimatti, Michele Dorigatti, and Stefano Tonetta. OCRA: A tool for checking the refinement of temporal contracts. In *2013 28th IEEE/ACM International Conference on Automated Software Engineering (ASE)*, pages 702-705, 2013. doi: 10.1109/ASE.2013.6693137.

[112] Marco Bozzano, Alessandro Cimatti, Marco Gario, David Jones, and Cristian Mattarei. Model-based safety assessment of a triple modular generator with xsap. *Formal Aspects of Computing*, 33, 04 2021. doi: 10.1007/s00165-021-00532-9.

[113] Marco Bozzano, Alessandro Cimatti, Cristian Mattarei, and Stefano Tonetta. Formal safety assessment via contract-based design. In *ATVA*, pages 81-97. Springer, 2014.

[114] Benjamin Bittner, Marco Bozzano, Roberto Cavada, Alessandro Cimatti, Marco Gario, Alberto Griggio, Cristian Mattarei, Andrea Micheli, and Gianni Zampedri. The xSAP Safety Analysis Platform. In Marsha Chechik and Jean-François Raskin, editors, *TACAS*, pages 533-539, Berlin, Heidelberg, 2016. Springer. ISBN 978-3-662-49674-9. doi: 10.1007/978-3-662-49674-9_31. URL https://doi.org/10.1007/978-3-662-49674-9_31.

[115] M. Bozzano and A. Villafiorita. Safety critical systems. In *Encyclopedia of Software Engineering*. CRC Press (Taylor & Francis Group), USA, 1st edition, 2013. ISBN 1439803315. doi: https://doi.org/10.5555/1951720.

[116] T. Courtney, S. Gaonkar, K. Keefe, E. W. D. Rozier, and W. H. Sanders. Möbius 2.3: An extensible tool for dependability, security, and performance evaluation of large and complex system models. In *DSN*, pages 353-358, 2009. doi: 10.1109/DSN.2009.5270318.

[117] P. Popov. Models of reliability of fault-tolerant software under cyber-attacks. In *ISSRE*, pages 228-239, 2017.

[118] Eclipse Foundation. Qvto, . URL https://wiki.eclipse.org/QVTo.

[119] Eclipse Foundation. Generate anything from any emf model, . URL https://www.eclipse.org/acceleo/.

[120] Stéphane Bonnet, Jean-Luc Voirin, Véronique Normand, and Daniel Exertier. Implementing the MBSE cultural change: Organization, coaching and lessons learned. *INCOSE International Symposium*, 25(1):508-523, 2015. doi: 10.1002/j.2334-5837.2015.00078.x.
[121] Marco Bozzano, Harold Bruintjes, Alessandro Cimatti, Joost-Pieter Katoen, Thomas Noll, and Stefano Tonetta. COMPASS 3.0. In TACAS, pages 379-385. Springer, 2019. doi: 10.1007/978-3-030-17462-0\_25. URL https://doi.org/10.1007/978-3-030-17462-0_25.

[122] Peter Fritzson. *Principles of Object-Oriented Modeling and Simulation with Modelica 3.3: A Cyber-Physical Approach*. Wiley-IEEE Press, 2 edition, April 2015. ISBN 978-1-118-85912-4.

[123] Jia Ming Cao and Tao Wu. Multi-domain modeling simulation and application based on MapleSim. In *Mechatronics and Intelligent Materials III*, volume 706, pages 1894-1897. Trans Tech Publications Ltd, 7 2013. doi: 10.4028/www.scientific.net/AMR.706-708.1894.

[124] Mendix. Mendix: IoT application development with a low-code platform. https://www.mendix.com/building-iot-applications/, 2020. Last accessed May 2020.

[125] Paul Vincent, Kimihiko Iijima, Mark Driver, Jason Wong, and Yefim Natis. Magic quadrant for enterprise Low-Code application platforms. https://www.gartner.com/, 2019. Last accessed June 2020.

[126] Salesforce. Salesforce news, features and certifications. Online, 2023. URL https://www.salesforceben.com. Accessed February 2023.

[127] ThingWorx. ThingWorx. ThingWorx: Industrial IoT software: IIot platform, Feb 2023. URL https://www.ptc.com/en/products/thingworx.

[128] Microsoft Corporation. Business application platform | microsoft power platform, Feb 2023. URL https://powerplatform.microsoft.com/en-us/.

[129] Amazon. Aws IoT core: Easily and securely connect devices to the cloud, Feb 2023. URL https://aws.amazon.com/iot-core/.

[130] IBM Watson IoT platform, Sep 2015. URL https://internetofthings.ibmcloud.com/.

[131] Simplifier. Simplifier: Enterprise apps made simple. https://www.simplifier.io/en/, 2020. Last accessed May 2020.

[132] Google Cloud. Cloud IoT core | google cloud. URL https://cloud.google.com/iot-core.

[133] A. Salihbegovic, T. Eterovic, E. Kaljic, and S. Ribic. Design of a domain specific language and ide for internet of things applications. In *2015 38th International Convention on Information and Communication Technology, Electronics and Microelectronics (MIPRO)*, pages 996-1001, 2015. doi: 10.1109/MIPRO.2015.7160420.

[134] Fabrizio F. Borelli, Gabriela O. Biondi, and Carlos A. Kamienski. BIoTA: A buildout IoT application language. *IEEE Access*, 8:126443-126459, 2020. doi: 10.1109/ACCESS.2020. 3003694.

[135] Jussi Kiljander, Janne Takalo-Mattila, Matti Etelapera, Juha-Pekka Soininen, and Kari Keinänen. Enabling end-users to configure smart environments. In *2011 IEEE/IPSJ International Symposium on Applications and the Internet*, pages 303-308, 2011. doi: 10.1109/SAINT.2011. 58.

[136] Jagni Dasa Horta Bezerra and Cidcley Teixeira de Souza. A model-based approach to generate reactive and customizable user interfaces for the web of things. In *Proceedings of the 25th Brazilian Symposium on Multimedia and the Web*, WebMedia '19, page 57-60, New York, NY, USA, 2019. Association for Computing Machinery. ISBN 9781450367639. doi: 10.1145/3323503.3360631.
[137] Flavio Corradini, Arianna Fedeli, Fabrizio Fornari, Andrea Polini, and Barbara Re. FloWare: An Approach for IoT Support and Application Development. In Adriano Augusto, Asif Gill, Selmin Nurcan, Iris Reinhartz-Berger, Rainer Schmidt, and Jelena Zdravkovic, editors, *Enterprise, Business-Process and Information Systems Modeling*, pages 350–365, Cham, 2021. Springer International Publishing. ISBN 978-3-030-79186-5.

[138] Guillermo Cueva-Fernandez, Jordán Pascual Espada, Vicente García-Díaz, Cristian González García, and Nestor Garcia-Fernandez. Vitruvius: An expert system for vehicle sensor tracking and managing application generation. *Journal of Network and Computer Applications*, 42:178–188, 2014. ISSN 1084-8045. doi: https://doi.org/10.1016/j.jnca.2014.02.013. URL https://doi.org/10.1016/j.jnca.2014.02.013.

[139] Cristian González García, B. Cristina Pelayo G-Bustelo, Jordán Pascual Espada, and Guillermo Cueva-Fernandez. MIDGAR: Generation of heterogeneous objects interconnecting applications. a domain specific language proposal for internet of things scenarios. *Computer Networks*, 64:143–158, may 2014. ISSN 1389-1286. doi: https://doi.org/10.1016/j.comnet.2014.02.010. URL https://doi.org/10.1016/j.comnet.2014.02.010.

[140] Wajid Rafique, Xuan Zhao, Shui Yu, Ibrar Yaqoob, Muhammad Imran, and Wanchun Dou. An application development framework for internet-of-things service orchestration. *IEEE Internet of Things Journal*, 7(5):4543–4556, 2020. doi: 10.1109/JIOT.2020.2971013. URL http://dx.doi.org/10.1109/JIOT.2020.2971013.

[141] Manfred Sneps-Sneppe and Dmitry Namiot. On web-based domain-specific language for internet of things. In *2015 7th International Congress on Ultra Modern Telecommunications and Control Systems and Workshops (ICUMT)*, pages 287–292, 2015. doi: 10.1109/ICUMT.2015.7382444.

[142] Robert Kleinfeld, Stephan Steglich, Lukasz Radziwonowicz, and Charalampos Doukas. Glue.Things: A mashup platform for wiring the internet of things with the internet of services. In *Proceedings of the 5th International Workshop on Web of Things*, WoT ’14, page 16–21, New York, NY, USA, 2014. Association for Computing Machinery. ISBN 9781450330664. doi: 10.1145/2684432.2684436.

[143] Amir Taherkordi and Frank Eliassen. Scalable modeling of cloud-based IoT services for smart cities. In *2016 IEEE International Conference on Pervasive Computing and Communication Workshops (PerCom Workshops)*, pages 1–6, 2016. doi: 10.1109/PERCOMW.2016.7457098.

[144] Yannis Valsamakis and Anthony Savidis. Personal Applications in the Internet of Things Through Visual End-User Programming. In Claudia Linnhoff-Popien, Ralf Schneider, and Michael Zaddach, editors, *Digital Marketplaces Unleashed*, pages 809–821, Berlin, Heidelberg, 2018. Springer Berlin Heidelberg. ISBN 978-3-662-49275-8. doi: 10.1007/978-3-662-49275-8_71. URL https://doi.org/10.1007/978-3-662-49275-8_71.

[145] Yi Xu and Abdelsalam Helal. Scalable cloud-sensor architecture for the internet of things. *IEEE Internet of Things Journal*, 3(3):285–298, 2016. doi: 10.1109/JIOT.2015.2455555.

[146] Simon Mayer, Ruben Verborgh, Matthias Kovatsch, and Friedemann Mattern. Smart configuration of smart environments. *IEEE Transactions on Automation Science and Engineering*, 13 (3):1247–1255, 2016. doi: 10.1109/TASE.2016.2533321.

[147] Badr El Khalyly, Mouad Banane, Allae Erraissi, and Abdessamad Belangour. InteroEvery: Microservice based interoperable system. In *2020 International Conference on Decision Aid Sciences and Application (DASA)*, pages 320–325, 2020. doi: 10.1109/DASA51403.2020.9317159. URL http://dx.doi.org/10.1109/DASA51403.2020.9317159.
[148] M. Hussein, S. Li, and A. Radermacher. Model-driven development of adaptive IoT systems. In *2017 MODELS Satellite Event*, volume 2019, pages 17–23, Austin, United States, September 2017. CEUR-WS. doi: 10.1109/DASC-PICom-DataCom-CyberSciTec.2016.81. URL https://hal-cea.archives-ouvertes.fr/cea-01843007.

[149] Mahmoud Hussein, Shuai Li, and Ansgar Radermacher. Model-driven development of adaptive IoT systems. *4th International Workshop on Interplay of Model-Driven Engineering and Component-Based Software EngineeringAt: Austin, Texas, USA, 2017*. URL https://www.researchgate.net/publication/319328820.

[150] Kleanthis Thramboulidis and Foivos Christoulakis. UML4IoT-A UML-based approach to exploit IoT in cyber-physical manufacturing systems. *Comput. Ind.*, 82(C):259–272, oct 2016. ISSN 0166-3615. doi: 10.1016/j.compind.2016.05.010. URL https://doi.org/10.1016/j.compind.2016.05.010.

[151] Open Mobile Alliance. Lightweight machine to machine technical specification. *Technical Specification OMA-TS-LightweightM2M-V1*, 2013.

[152] Armin Moin, Stephan Rössler, and Stephan Günnemann. ThingML+: Augmenting model-driven software engineering for the internet of things with machine learning. *MDE4IoT - MODELS 2018*, 2018.

[153] Claudio M. de Farias and Italo C. Brito et al. COMFIT: A development environment for the internet of things. *Future Generation Computer Systems*, 75:128–144, 2017. ISSN 0167-739X. doi: https://doi.org/10.1016/j.future.2016.06.031.

[154] Mohammad Sharaf, Mai Abusair, Rami Eleiwi, Yara Shana'a, Ithar Saleh, and Henry Mucini. Modeling and code generation framework for IoT. In Pau Fonseca i Casas, Maria-Ribera Sancho, and Edel Sherratt, editors, *System Analysis and Modeling. Languages, Methods, and Tools for Industry 4.0*, pages 99–115, Cham, 2019. Springer International Publishing. ISBN 978-3-030-30690-8. doi: https://doi.org/10.1007/978-3-030-30690-8_6.

[155] S. Dhouib, A. Cuccuru, F. Le Fèvre, S. Li, B. Maggi, I. Paez, A. Rademarcher, N. Rapin, J. Tatibouet, P. Tessier, S. Tucci, and S. Gerard. Papyrus for IoT – a modeling solution for IoT. , 2016.

[156] Papyrus Moka team. Papyrus moka, 2019. URL https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution.

[157] Ferry Pramudianto, Carlos Alberto Kamienski, Eduardo Souto, Fabrizio Borelli, Lucas L. Gomes, Djamel Sadok, and Matthias Jarke. IoT Link: An internet of things prototyping toolkit. In *2014 IEEE 11th Intl Conf on Ubiquitous Intelligence and Computing and 2014 IEEE 11th Intl Conf on Autonomic and Trusted Computing and 2014 IEEE 14th Intl Conf on Scalable Computing and Communications and Its Associated Workshops*, pages 1–9, 2014. doi: 10.1109/UIC-ATC-ScalCom.2014.95. URL http://dx.doi.org/10.1109/UIC-ATC-ScalCom.2014.95.

[158] Flavio Corradini, Arianna Fedeli, Fabrizio Fornari, Andrea Polini, Barbara Re, and Luca Ruschioni. X-IoT: a model-driven approach to support IoT application portability across IoT platforms. *Computing*, 01 2023. doi: 10.1007/s00607-023-01155-z.

[159] Xuan Thang Nguyen, Huu Tam Tran, Harun Baraki, and Kurt Geihs. FRASAD: A framework for model-driven IoT application development. In *2015 IEEE 2nd World Forum on Internet of Things (WF-IoT)*, pages 387–392, 2015. doi: 10.1109/WF-IoT.2015.7389085.
[160] Thiago Nepomuceno, Tiago Carneiro, Paulo Henrique Maia, Muhammad Adnan, Thalyson Nepomuceno, and Alexander Martin. AutoIoT: a framework based on user-driven MDE for generating IoT applications. *The 35th ACM/SIGAPP Symposium on Applied Computing (SAC '20)*, page 719-728, 2020. doi: https://doi.org/10.1145/3341105.3373873. URL https://doi.org/10.1145/3341105.3373873.

[161] Dimitris Soukaras, Pankesh Pately, Hui Songz, and Sanjay Chaudhary. IoTSuite: A toolsuite for prototyping internet of things applications. *The 4th Workshop on on Computing and Networking for Internet of Things (ComNet-IoT 2015)*, 2020. doi: https://doi.org/10.1145/3341105.3373873.

[162] Nguyen Xuan Thang, Michael Zapf, and Kurt Geihs. Model driven development for data-centric sensor network applications. In *Proceedings of the 9th International Conference on Advances in Mobile Computing and Multimedia*, MoMM '11, page 194-197, New York, NY, USA, 2011. Association for Computing Machinery. ISBN 9781450307857. doi: 10.1145/2095697.2095733. URL https://doi.org/10.1145/2095697.2095733.

[163] Arvid Butting, Arne Haber, Lars Hermerschmidt, Oliver Kautz, Bernhard Rumpe, and Andreas Wortmann. Systematic language extension mechanisms for the montiarc architecture description language. In *Anthony Anjorin and Huáscar Espinoza, editors, Modelling Foundations and Applications*, pages 53-70, Cham, 2017. Springer International Publishing. ISBN 978-3-319-61482-3. doi: https://doi.org/10.1007/978-3-319-61482-3_4.

[164] Francisco Durán, Ajay Krishna, Michel Le Pallec, Radu Mateescu, and Gwen Salaün. Models and analysis for user-driven reconfiguration of rule-based IoT applications. *Internet of Things*, 19:100515, 2022. ISSN 2542-6605. doi: https://doi.org/10.1016/j.iot.2022.100515.

[165] Ivan Alfonso, Kelly Garcés, Harold Castro, and Jordi Cabot. A model-based infrastructure for the specification and runtime execution of self-adaptive IoT architectures. *Computing*, pages 1-24, 02 2023. doi: 10.1007/s00607-022-01145-7.

[166] Behailu Negash, Tomi Westerlund, Amir M Rahmani, Pasi Liljeberg, and Hannu Tenhunen. DoS-IL: A Domain Specific Internet of Things Language for Resource Constrained Devices. *Procedia Computer Science*, 109:416-423, 2017. ISSN 1877-0509. doi: https://doi.org/10.1016/j.procs.2017.05.411.

[167] Fei Li, Michael Vögler, Markus Claeßens, and Schahram Dustdar. Towards automated IoT application deployment by a cloud-based approach. In *2013 IEEE 6th International Conference on Service-Oriented Computing and Applications*, pages 61-68, 2013. doi: 10.1109/SOCA.2013.12.

[168] Nicolas Ferry, Phu Nguyen, Hui Song, Pierre-Emmanuel Novac, Stéphane Lavirotte, Jean-Yves Tigli, and Arnor Solberg. GeneSIS: Continuous orchestration and deployment of smart IoT systems. In *2019 IEEE 43rd Annual Computer Software and Applications Conference (COMPSAC)*, volume 1, pages 870-875, 2019. doi: 10.1109/COMPSAC.2019.00127.

[169] ISOGRAPH. Fault tree analysis in reliability workbench, 2022. URL https://www.isograph.com/. Last accessed May 2022.

[170] Jacopo Parri, Fulvio Patara, Samuele Sampietro, and Enrico Vicario. A framework for model-driven engineering of resilient software-controlled systems. *Computing*, 103, 04 2021. doi: 10.1007/s00607-020-00841-6.

[171] Faida Mhenni, Nga Nguyen, and Jean-Yves Choley. Automatic fault tree generation from SysML system models. In *2014 IEEE/ASME International Conference on Advanced Intelligent Mechatronics*, pages 715-720, 2014. doi: 10.1109/AIM.2014.6878163.
[172] Nataliya Yakymets, Hadi Jaber, and Agnes Lanusse. Model-based system engineering for fault tree generation and analysis. In *Proceedings of the 1st International Conference on Model-Driven Engineering and Software Development - Volume 1: MODELSWARD*, pages 210–214. INSTICC, SciTePress, 2013. ISBN 978-989-8565-42-6. doi: 10.5220/0004346902100214.

[173] Tatiana Prosvirnova. *AltaRica 3.0: a Model-Based approach for Safety Analyses*. Theses, Ecole Polytechnique, November 2014. URL https://pastel.archives-ouvertes.fr/tel-01119730.

[174] Hamed Fazlollahtabar and Seyed Niaki. Fault tree analysis for reliability evaluation of an advanced complex manufacturing system. *Journal of Advanced Manufacturing Systems*, 17: 107–118, 03 2018. doi: 10.1142/S0219686718500075.

[175] Kester Clegg, Mole Li, David Stamp, Alan Grigg, and John McDermid. Integrating existing safety analyses into SysML. In Yiannis Papadopoulos, Koorosh Aslansefat, Panagiotis Katsaros, and Marco Bozzano, editors, *Model-Based Safety and Assessment*, pages 63–77, Cham, 2019. Springer International Publishing. ISBN 978-3-030-32872-6.

[176] Kester Clegg, Mole Li, David Stamp, Alan Grigg, and John McDermid. A SysML profile for fault trees—linking safety models to system design. In Alexander Romanovsky, Elena Troubitsyna, and Friedemann Bitsch, editors, *Computer Safety, Reliability, and Security*, pages 85–93, Cham, 2019. Springer International Publishing. ISBN 978-3-030-26601-1.

[177] Jianwen Xiang and Kazuo Yanoo. Automatic static fault tree analysis from system models. In *2010 IEEE 16th Pacific Rim International Symposium on Dependable Computing*, pages 241–242, 2010. doi: 10.1109/PRDC.2010.35.

[178] Moomen Chaari, Wolfgang Ecker, Thomas Kruse, Cristiano Novello, and Bogdan-Andrei Tabacaru. Transformation of failure propagation models into fault trees for safety evaluation purposes. In *2016 46th Annual IEEE/IFIP International Conference on Dependable Systems and Networks Workshop (DSN-W)*, pages 226–229, 2016. doi: 10.1109/DSN-W.2016.18.

[179] Stefanos Katsavounis, Nikolaos Patsianis, E. Konstantinidis, and Pantelis Botsaris. Reliability analysis on crucial subsystems of a wind turbine through FTA approach. 09 2014. doi: 10.13140/2.1.2524.3849.

[180] Ivanovitch Silva, Rafael Leandro, Daniel Macedo, and Luiz Affonso Guedes. A dependability evaluation tool for the internet of things. *Computers & Electrical Engineering*, 39(7):2005–2018, 2013. ISSN 0045-7906. doi: https://doi.org/10.1016/j.compeleceng.2013.04.021. URL https://www.sciencedirect.com/science/article/pii/S0045790613001171.

[181] Yingyi Chen, Zhumi Zhen, Huihui Yu, and Jing Xu. Application of fault tree analysis and fuzzy neural networks to fault diagnosis in the internet of things (IoT) for aquaculture. *Sensors*, 17(1), 2017. ISSN 1424-8220. doi: 10.3390/s17010153. URL https://www.mdpi.com/1424-8220/17/1/153.

[182] Liudong Xing, Massarrah Tannous, Vinod M. Vokkarane, Honggang Wang, and Jun Guo. Reliability modeling of mesh storage area networks for internet of things. *IEEE Internet of Things Journal*, 4(6):2047–2057, 2017. doi: 10.1109/JIOT.2017.2749375.

[183] Ovidiu-Andrei Schipor, Radu-Daniel Vatavu, and Jean Vanderdonckt. Euphoria: A scalable, event-driven architecture for designing interactions across heterogeneous devices in smart environments. *Information and Software Technology*, 109:43–59, 2019. ISSN 0950-5849. URL https://doi.org/10.1016/j.infsof.2019.01.006.
[184] Gökhan Kahraman and Semih Bilgen. A framework for qualitative assessment of domain-specific languages. *Softw. Syst. Model.*, 14(4):1505–1526, oct 2015. ISSN 1619-1366. doi: 10.1007/s10270-013-0387-8. URL https://doi.org/10.1007/s10270-013-0387-8.

[185] Christian Moreira, Juan Cobos-Q, Wilson Valdez Solis, Cristina Sánchez-Zhunio, and Irene Priscila Cedillo Orellana. Evaluating the usability in domain-specific languages. In *Information Systems Development: Crossing Boundaries between Development and Operations (DevOps) in Information Systems (ISD2021 Proceedings)*, Valencia, Spain, September 8-10, 2021, 2021. URL https://aisel.aisnet.org/isd2014/proceedings2021/hci/3.

[186] Mohamed Darwish and Essam Shehab. Framework for engineering design systems architectures evaluation and selection: Case study. *Procedia CIRP*, 60:128–132, 2017. ISSN 2212-8271. URL https://doi.org/10.1016/j.procir.2017.01.058. Complex Systems Engineering and Development Proceedings of the 27th CIRP Design Conference Cranfield University, UK 10th – 12th May 2017.

[187] Miguel Goulão, Vasco Amaral, and Marjan Mernik. Quality in model-driven engineering: A tertiary study. 24(3):601–633, sep 2016. ISSN 0963-9314. doi: 10.1007/s11219-016-9324-8. URL https://doi.org/10.1007/s11219-016-9324-8.

[188] Diego X. Jara Juárez and Priscila Cedillo. Security of mobile cloud computing: A systematic mapping study. In *2017 IEEE Second Ecuador Technical Chapters Meeting (ETCM)*, pages 1–6, 2017. doi: 10.1109/ETCM.2017.8247486. URL https://doi.org/10.1109/ETCM.2017.8247486.

[189] John Estdale and Elli Georgiadou. Applying the ISO/IEC 25010 quality models to software product. In Xabier Larrucea, Izaskun Santamaria, Rory V. O’Connor, and Richard Messnarz, editors, *Systems, Software and Services Process Improvement*, pages 492–503, Cham, 2018. Springer International Publishing. ISBN 978-3-319-97925-0. URL https://doi.org/10.1007/978-3-319-97925-0_42.

[190] Jose Luis González, Roberto García, Josep Maria Brunetti, Rosa Gil, and Juan Manuel Gimeno. SWET-QUM: A quality in use extension model for semantic web exploration tools. In *Proceedings of the 13th International Conference on Interacción Persona-Ordenador*, INTERACCION ’12, New York, NY, USA, 2012. Association for Computing Machinery. ISBN 9781450313148. doi: 10.1145/2379636.2379651. URL https://doi.org/10.1145/2379636.2379651.

[191] Siamak Farshidi, Slinger Jansen, and Sven Fortuin. Model-driven development platform selection: Four industry case studies. *Softw. Syst. Model.*, 20(5):1525–1551, oct 2021. ISSN 1619-1366. doi: 10.1007/s10270-020-00855-w. URL https://doi.org/10.1007/s10270-020-00855-w.

[192] CONNECT Advisory Forum (CAF). Internet of things – the next revolution “a strategic reflection about an european approach to internet of things. Technical report, European Commission, 2014.

[193] Satya Nand. Environmental energy harvesting techniques to power standalone iot-equipped sensor and its application in 5g communication. *Emerging Science Journal*, 4:116–126, 11 2021. doi: 10.28991/esj-2021-SP1-08.

[194] Amir H. Moin. Domain specific modeling (DSM) as a service for the internet of things & services. In *Internet of Things. User-Centric IoT*. Springer, Cham, 2015. doi: 10.1007/978-3-319-19656-5_47.

[195] Francesco Basciani, Juri Rocco, Davide Di Ruscio, Amleto Di Salle, Ludovico Iovino, and Alfonso Pierantonio. MDEForge: An extensible web-based modeling platform. volume 1242, 09 2014.
[196] Léa Brunschwig, Esther Guerra, and Juan de Lara. Towards access control for collaborative modelling apps. In *Proceedings of the 23rd ACM/IEEE International Conference on Model Driven Engineering Languages and Systems: Companion Proceedings*, MODELS '20, New York, NY, USA, 2020. Association for Computing Machinery. ISBN 9781450381352. doi: 10.1145/3417990.3420201.

[197] Adriana Caione, Alessandro Fiore, Luca Mainetti, Luigi Manco, and Roberto Vergallo. Chapter 13 - WoX: Model-Driven Development of Web of Things Applications. In Quan Z Sheng, Yongrui Qin, Lina Yao, and Boualem Benatallah, editors, *Managing the Web of Things*, pages 357-387. Morgan Kaufmann, Boston, 2017. ISBN 978-0-12-809764-9. doi: https://doi.org/10.1016/B978-0-12-809764-9.00017-2.

[198] Darko Androcec and Neven Vrcek. Thing as a service interoperability: Review and framework proposal. In *2016 IEEE 4th International Conference on Future Internet of Things and Cloud (FiCloud)*, pages 309-316, 2016. doi: 10.1109/FiCloud.2016.51.

[199] Giancarlo Fortino, Claudio Savaglio, Giandomenico Spezzano, and MengChu Zhou. Internet of things as system of systems: A review of methodologies, frameworks, platforms, and tools. *IEEE Transactions on Systems, Man, and Cybernetics: Systems*, 51(1):223-236, 2021. doi: 10.1109/TSMC.2020.3042898.

[200] Andreas Wortmann, Benoit Combemale, and Olivier Barais. A systematic mapping study on modeling for industry 4.0. In *Proceedings of the ACM/IEEE 20th International Conference on Model Driven Engineering Languages and Systems*, MODELS '17, page 281-291. IEEE Press, 2017. ISBN 9781538634929. doi: 10.1109/MODELS.2017.14.

[201] Sergio Teixeira, Bruno Alves Agrizzi, José Gonçalves Pereira Filho, Silvana Rossetto, and Roquemar de Lima Baldam. Modeling and automatic code generation for wireless sensor network applications using model-driven or business process approaches: A systematic mapping study. *Journal of Systems and Software*, 132:50-71, 2017. ISSN 0164-1212. doi: https://doi.org/10.1016/j.jss.2017.06.024.

[202] Partha Pratim Ray. A Survey on Visual Programming Languages in Internet of Things. *Scientific Programming*, 2017:1231430, 2017. ISSN 1058-9244. doi: 10.1155/2017/1231430.

[203] Christian Prehofer and Ilias Gerostathopoulos. Chapter 3 - Modeling RESTful Web of Things Services: Concepts and Tools. In Quan Z Sheng, Yongrui Qin, Lina Yao, and Boualem Benatallah, editors, *Managing the Web of Things*, pages 73-104. Morgan Kaufmann, Boston, 2017. ISBN 978-0-12-809764-9. doi: https://doi.org/10.1016/B978-0-12-809764-9.00004-4.

[204] Jorge Biolchini, Paula Gomes Mian, Ana Candida Cruz Natali, and Guilherme Horta Travassos. Systematic review in software engineering. *System Engineering and Computer Science Department COPPE/UFRJ, Technical Report ES*, 679(05):45, 2005.

[205] Marco Brambilla, Eric Umuhoza, and Roberto Acerbis. Model-driven development of user interfaces for IoT systems via domain-specific components and patterns. *Journal of Internet Services and Applications*, 8(1):14, 2017. ISSN 1869-0238. doi: 10.1186/s13174-017-0064-1.

[206] Mahda Noura, Mohammed Atiquzzaman, and Martin Gaedke. Interoperability in Internet of Things: Taxonomies and Open Challenges. *Mobile Networks and Applications*, 24(3):796-809, 2019. ISSN 15728153. doi: 10.1007/s11036-018-1089-9.

[207] Mauro Conti, Ali Dehghantanha, Katrin Franke, and Steve Watson. Internet of Things security and forensics: Challenges and opportunities. *Future Generation Computer Systems*, 78:544-546, 2018. ISSN 0167739X. doi: 10.1016/j.future.2017.07.060. URL http://dx.doi.org/10.1016/j.future.2017.07.060.
[208] Eclipse Foundation. 2020 annual eclipse foundation community report, 2020. URL https://www.eclipse.org/org/foundation/reports/annual_report.php. Last accessed July 2021.

[209] Melanie Bats and Stephane Begaudeau. Sirius web: 100 URL https://www.eclipsecon.org/2020/sessions/sirius-web-100-open-source-cloud-modeling-platform. Last accessed July 2021.

[210] André Restivo, Hugo Sereno Ferreira, João Pedro Dias, and Margarida Silva. Visually-defined real-time orchestration of IoT systems. 2020.

[211] Nam Ky Giang, Michael Blackstock, Rodger Lea, and Victor C.M. Leung. Developing IoT applications in the fog: A distributed dataflow approach. In *2015 5th International Conference on the Internet of Things (IOT)*, pages 155–162, 2015. doi: 10.1109/IOT.2015.7356560.

[212] João Pedro Dias, André Restivo, and Hugo Sereno Ferreira. Empowering visual internet-of-things mashups with self-healing capabilities. *arXiv preprint arXiv:2103.07395*, 2021.

[213] Yun Mi Antorini and Albert M Muñiz. The Benefits and Challenges of Collaborating with User Communities. *Research-Technology Management*, 56(3):21–28, 2013. doi: 10.5437/08956308X5603931. URL https://doi.org/10.5437/08956308X5603931.

[214] Olaf David, Wes Lloyd, Ken Rojas, Mazdak Arabi, Frank Geter, James Ascough, Tim Green, G. Leavesley, and Jack Carlson. Model-as-a-service (MaaS) using the Cloud Services Innovation Platform (CSIP). *Proceedings - 7th International Congress on Environmental Modelling and Software: Bold Visions for Environmental Modeling*, iEMSs 2014, 1:243–250, 2014.

[215] Faezeh Khorram, Jean-Marie Mottu, and Gerson Sunyé. Challenges & opportunities in Low-Code testing. In *Proceedings of the 23rd ACM/IEEE International Conference on Model Driven Engineering Languages and Systems: Companion Proceedings*, MODELS ’20, New York, NY, USA, 2020. Association for Computing Machinery. ISBN 9781450381352. doi: 10.1145/3417990.3420204. URL https://doi.org/10.1145/3417990.3420204.

[216] Stephen H. Kan. *Metrics and Models in Software Quality Engineering*. Addison-Wesley Longman Publishing Co., Inc., USA, 2nd edition, 2002. ISBN 0201729156. doi: 10.5555/559784. URL https://dl.acm.org/doi/10.5555/559784.

[217] Maryoly Ortega and et al. Construction of a systemic quality model for evaluating a software product. *Softw. Qual. J.*, 11(3), 2003. URL https://doi.org/10.1023/A:1025166710988.

[218] Oleksandr Gordieiev, Vyacheslav Kharchenko, Nataliia Fominykh, and Vladimir Sklyar. Evolution of software quality models in context of the standard ISO 25010. In *Proceedings of the Ninth International Conference on Dependability and Complex Systems DepCoS-RELCOMEX. June 30 – July 4, 2014, Brunów, Poland*, pages 223–232, Cham, 2014. ISBN 978-3-319-07013-1. doi: 10.1007/978-3-319-07013-1_21. URL https://doi.org/10.1007/978-3-319-07013-1_21.

[219] Marc-Alexis Côté, Witold Suryn, and Elli Georgiadou. In search for a widely applicable and accepted software quality model for software quality engineering. *Software Quality Journal*, 15(4):401–416, dec 2007. ISSN 0963-9314. doi: 10.1007/s11219-007-9029-0. URL https://doi.org/10.1007/s11219-007-9029-0.

[220] Felicien Ihirwe, Davide Di Ruscio, Simone Gianfranceschi, and Alfonso Pierantonio. Software product quality evaluation questionnaire for IoT LCDP&MDE, June 2022. URL https://doi.org/10.5281/zenodo.6631200.
[221] Bruno A. Mozzaquatro, Ricardo Jardim-Goncalves, and Carlos Agostinho. Towards a reference ontology for security in the internet of things. In *2015 IEEE International Workshop on Measurements & Networking (M&N)*, pages 1–6, 2015. doi: 10.1109/IWMN.2015.7322984. URL https://doi.org/10.1109/IWMN.2015.7322984.

[222] Eric Bouwers, Jose Pedro Correia, Arie van Deursen, and Joost Visser. Quantifying the analyzability of software architectures. In *2011 Ninth Working IEEE/IFIP Conference on Software Architecture*, pages 83–92, 2011. doi: 10.1109/WICSA.2011.20. URL https://doi.org/10.1109/WICSA.2011.20.

[223] Fahed Alkhabbas, Romina Spalazzese, Maura Cerioli, Maurizio Leotta, and Gianna Reggio. On the deployment of IoT systems: An industrial survey. In *2020 IEEE International Conference on Software Architecture Companion (ICSA-C)*, pages 17–24, 2020. doi: 10.1109/ICSA-C50368.2020.00012.

[224] Gourav Shah. *Ansible Playbook Essentials*. Packt Publishing Ltd, 2015.

[225] M. Hussein, S. Li, and A. Radermacher. Model-driven development of adaptive IoT systems. In *2017 MODELS Satellite Event*, volume 2019, pages 17–23, Austin, United States, September 2017. CEUR-WS. URL https://hal-cea.archives-ouvertes.fr/cea-01843007.

[226] Banks Andrew and Gupta Rahul. Mqtt version 3.1.1 plus errata 01 [online], December 2015. URL http://docs.oasis-open.org/mqtt/mQTv3.1.1/mQTv3.1.1.html. Last Accessed: September 2020.

[227] Commission Electrotechnique Internationale. *IEC 61025:2006 - Fault tree analysis (FTA)*. IEC Standards Online, 2006. URL https://webstore.iec.ch/publication/4311.

[228] Barbara Gallina and Sasikumar Punnekkat. FI4FA: A formalism for incompletion, inconsistency, interference and impermanence failures' analysis. In *2011 37th EUROMICRO Conference on Software Engineering and Advanced Applications*, pages 493–500, 2011. doi: 10.1109/SEAA.2011.80.

[229] Dimitrios S. Kolovos, Richard F. Paige, and Fiona A. C. Polack. The epsilon transformation language. In Antonio Vallecillo, Jeff Gray, and Alfonso Pierantonio, editors, *Theory and Practice of Model Transformations*, pages 46–60, Berlin, Heidelberg, 2008. Springer Berlin Heidelberg. ISBN 978-3-540-69927-9. doi: https://doi.org/10.1007/978-3-540-69927-9_4.

[230] He Ren, Xi Chen, and Yong Chen. Chapter 6 - fault tree analysis for composite structural damage. In He Ren, Xi Chen, and Yong Chen, editors, *Reliability Based Aircraft Maintenance Optimization and Applications*, Aerospace Engineering, pages 115–131. Academic Press, 2017. ISBN 978-0-12-812668-4. doi: https://doi.org/10.1016/B978-0-12-812668-4.00006-X. URL https://www.sciencedirect.com/science/article/pii/B978012812668400006X.

[231] Fatemeh Afsharnia. Failure rate analysis. In Aidy Ali, editor, *Failure Analysis and Prevention*, chapter 7. IntechOpen, Rijeka, 2017. doi: 10.5772/intechopen.71849. URL https://doi.org/10.5772/intechopen.71849.

[232] P. Varady, Z. Benyo, and B. Benyo. An open architecture patient monitoring system using standard technologies. *IEEE Transactions on Information Technology in Biomedicine*, 6(1): 95–98, 2002. doi: 10.1109/4233.992168.

[233] Philipp Hönig, Rüdiger Lunde, and Florian Holzapfel. Model based safety analysis with smartiflow. *Information*, 8(1), 2017. ISSN 2078-2489. doi: 10.3390/info8010007. URL https://www.mdpi.com/2078-2489/8/1/7.
[234] Arthur Henrique de Andrade Melani and Gilberto Francisco Martha de Souza. Obtaining fault trees through SysML diagrams: A MBSE approach for reliability analysis. In *2020 Annual Reliability and Maintainability Symposium (RAMS)*, pages 1–5, 2020. doi: 10.1109/RAMS48030.2020.9153658.

[235] Brice Morin, Nicolas Harrand, and Franck Fleurey. Model-based software engineering to tame the IoT jungle. *IEEE Software*, 34(1):30–36, 2017. doi: 10.1109/MS.2017.11.

[236] Gözde Karataş, Ferit Can, Gamze Doğan, Cemile Konca, and Akhan Akbulut. Multi-tenant architectures in the cloud: A systematic mapping study. In *2017 International Artificial Intelligence and Data Processing Symposium (IDAP)*, pages 1–4, 2017. doi: 10.1109/IDAP.2017.8090268.

[237] Katharina Görlach and Frank Leymann. Dynamic service provisioning for the cloud. In *2012 IEEE Ninth International Conference on Services Computing*, pages 555–561, 2012. doi: 10.1109/SCC.2012.30.

[238] Felicien Ihirwe. Home automation system failure logic behavior rules, January 2023.
Funding

"This project has received funding from the European Union's Horizon 2020 research and innovation programme under the Marie Skłodowska-Curie grant agreement No 813884"

Jean Felicien Ihirwe, Pisa, March 2023
<figure><img src="image_76.png" /></figure>