# Low-Code Engineering for the Internet of Things

Felicien Ihirwe

► To cite this version:

Felicien Ihirwe. Low-Code Engineering for the Internet of Things. Computer Science [cs]. University of L'Aquila, 2023. English. NNT: tel-04197421

HAL Id: tel-04197421

https://hal.science/tel-04197421

Submitted on 6 Sep 2023

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
<figure><img src="image_2.png" /></figure>

UNIVERSITÀ DEGLI STUDI DELL'AQUILA

Department of Information Engineering, Computer Science
and Mathematics

Ph.D. Program in Information and Communication Technology

**Curriculum:** Emerging computing models, software architectures, and intelligent systems

XXXV cycle

THIS DISSERTATION IS SUBMITTED FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY

Low-Code Engineering for the Internet of Things

SSD INF/01

Supervisor
**Prof. Davide Di Ruscio**

Co-Supervisors
**Prof. Alfonso Pierantonio**
**Dott. Simone Gianfranceschi**

Doctoral Program Supervisor
**Prof. Vittorio Cortellessa**

Doctoral Dissertation of:
**Jean Felicien Ihirwe**
ACKNOWLEDGMENT

First and foremost, I would like to express my heartfelt gratitude to my supervisor, Prof. Davide Di Ruscio, for his unwavering support from the beginning to the finish of my doctorate studies. Your insights and expertise have been invaluable in shaping my ideas and strengthening my technical, research, and writing skills. I want also to express my most sincere appreciation to my co-supervisors Prof. Alfonso Pierantonio and Simone Gianfranceschi for your effort and the trust you have invested in helping me reach this milestone.

I'd like to express my gratitude to Prof. Andrea Polini and Prof. Gerson Sunyé for carefully reading the preliminary version of this thesis and providing helpful comments and recommendations. I also thank the entire Lowcomote supervisory board for their feedback and constructive criticism, which has helped me to reshape my thoughts. I recognize and appreciate the whole Intecs Solution community for providing me with a friendly and supportive atmosphere, especially Silvia Mazzini for his continuous support even after she retired. I would also want to thank Prof. Eric Umuhoza for his guidance and encouragement even before the beginning of this adventure till the end, all of my colleagues and friends from the Lowcomote community, the DISIM department colleagues at the University of L'Aquila, and my friends.

I'd like to extend my sincere tribute to my mother for her continuous encouragement and counsel toward my greater success. Finally, my special thanks goes to my girlfriend, entire family, especially my siblings, who have believed in me and always encouraged me to go for it.

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
Less expectation, more exploration
and trust.
Abstract

The Internet of Things (IoT) technologies are often seen as the main drivers of the current tech-
nological revolution, which devotes the most priority to improving the well-being of humanity. IoT is
typically regarded as a powerful network of systems that integrates several heterogeneous and inde-
pendently networked devices working together to achieve a shared purpose. Engineering such systems
requires efficient tools to deal with the intrinsic complexities while offering means to increase system
reliability by limiting future repair costs. Low-Code Development Platforms (LCDPs) unravel the
opportunities to advance the simplicity of how new applications are developed in different business
application domains. However, in the IoT domain, systems are complex, multi-layered, and highly
heterogeneous in all aspects, not to mention the large amount of data being collected and processed
concurrently. Even though there is a convenient push toward coping with such complexities, there
still needs to be a massive gap regarding the actual development techniques that support early sys-
tem analysis, deployment, and run-time management. Low-Code Engineering (LCE), on the other
hand, aims to tackle such issues by extending the development knowledge present in LCDPs to a more
sophisticated era of "Low-Code Engineering Platforms (LCEPs)" by injecting into it the theoretical
and technical concepts present in Model-Driven Engineering (MDE), Cloud Computing, and Machine
Learning. These platforms target more sophisticated domains such as IoT, industrial automation, data
science, recommender systems, etc. This dissertation addresses such challenges by first presenting
the current state of the art of Low-Code Engineering Platforms (LCEPs), which gives a better un-
derstanding of what LCEPs are and their differences with respect to existing LCDPs, particularly in
the IoT domain. We also highlight how MDE plays a significant role in the LCE's evolution. Then,
we examine the current limitations, open challenges, and opportunities of existing IoT Engineering
platforms in realizing such an initiative. While evaluating the quality of such complex platforms could
be challenging, we propose the software product quality model for evaluating the static and dynamic
quality properties of such engineering platforms.

The complexity behind the automated realization of IoT systems can be extremely daunting. One
efficient approach is to adopt Domain-Specific Languages (DSLs). DSLs are tailored to the specific
domain to pave the way for the domain experts to define the system's behavior based on their exper-
tise. This dissertation presents CHESSIoT, a platform that integrates high-level visual DSLs, software
development, safety analysis, and deployment mechanisms for engineering multi-layered IoT systems.
With CHESSIoT, users may conduct various engineering tasks on system and software models to en-
able earlier decision-making. This is achieved in a unique environment that combines multi-staged
designs, most notably the system-level, functional, and deployment architectures. The physical archi-
tecture specifically contains the high-level system building blocks and their interconnections suitable
to perform both early qualitative and quantitative safety analysis by employing logical Fault-Trees
(FTs). On the other hand, the software model is equipped with the system's functional behavior
suitable for generating platform-specific code ready to be deployed on low-level IoT device nodes.
Additionally, the framework supports modeling of the system's deployment, which would ultimately
be used to generate deployment artifacts. To facilitate run-time management of deployed services, the
tool offers means for defining run-time service provisioning modules through which deployment rules
are defined and configured. To demonstrate the effectiveness of our proposed approach, throughout
this dissertation, different comparative assessment was conducted to highlight the potential contribu-
tion of our approach in relation to existing approaches. Finally, we used the implications from the
conducted research studies as well as experiments from running examples to tackle potential research
questions as well as demonstrate the capabilities of our supporting tool.

**Keywords:** Low-Code Developments Platform, Low-Code Engineering Platform, Model-Driven Engineering, Internet of Things, System modeling, Safety analysis, Code generation, System Deployment.
<figure><img src="image_3.png" /></figure>
# Contents

<table><tr><td>Abstract</td><td>iii</td></tr><tr><td>List of Figures</td><td>viii</td></tr><tr><td>List of Tables</td><td>x</td></tr><tr><td>List of Listings</td><td>xi</td></tr><tr><td>1 Introduction</td><td>1</td></tr><tr><td>1.1 Challenges and motivation</td><td>2</td></tr><tr><td>1.2 Main achieved research and technological results</td><td>4</td></tr><tr><td>1.3 Structure of the dissertation</td><td>6</td></tr><tr><td>2 Background</td><td>7</td></tr><tr><td>2.1 The Internet of Things</td><td>7</td></tr><tr><td>2.1.1 IoT system architecture</td><td>7</td></tr><tr><td>2.1.2 Safety Critical Systems</td><td>9</td></tr><tr><td>2.2 Model-Driven Engineering</td><td>10</td></tr><tr><td>2.2.1 Domain Specific Languages in IoT</td><td>11</td></tr><tr><td>2.2.2 MDE for IoT reference model</td><td>12</td></tr><tr><td>2.2.3 Model-Based Safety Analysis</td><td>13</td></tr><tr><td>2.3 Low-Code Engineering</td><td>14</td></tr><tr><td>2.3.1 Low-Code Development Platforms</td><td>15</td></tr><tr><td>2.3.2 Low-Code Engineering Platforms</td><td>16</td></tr><tr><td>2.4 CHESS environment</td><td>18</td></tr><tr><td>2.4.1 CHESS in nutshell</td><td>19</td></tr><tr><td>2.4.2 Supported Model-based Analysis</td><td>24</td></tr><tr><td>2.4.3 Related tools</td><td>30</td></tr><tr><td>2.4.4 Conclusions</td><td>31</td></tr><tr><td>3 IoT Engineering Platforms: a state of the art</td><td>32</td></tr><tr><td>3.1 Low-Code Development Platforms for IoT</td><td>32</td></tr><tr><td>3.1.1 General-purpose LCDPs for supporting IoT applications development</td><td>32</td></tr><tr><td>3.1.2 IoT specific LCDPs for system modeling and development</td><td>34</td></tr><tr><td>3.1.3 IoT specific LCDPs for service-oriented applications development</td><td>35</td></tr><tr><td>3.2 Model-driven design and development of IoT systems</td><td>36</td></tr><tr><td>3.3 MDE for deployment of IoT systems</td><td>39</td></tr><tr><td>3.4 MDE for safety analysis of IoT systems</td><td>41</td></tr><tr><td>3.5 Software product quality model for IoT LCEPs</td><td>43</td></tr></table>
4 Limitations and open challenges of existing IoT Engineering Platforms 45

<table><tr><td>4.1</td><td>Engineering IoT platforms</td><td>46</td></tr><tr><td>4.1.1</td><td>Engineering IoT platforms features</td><td>46</td></tr><tr><td>4.1.2</td><td>Findings</td><td>48</td></tr><tr><td>4.1.3</td><td>Limitations</td><td>48</td></tr><tr><td>4.1.4</td><td>Conclusion</td><td>49</td></tr><tr><td>4.2</td><td>Cloud-based modeling in IoT domain</td><td>50</td></tr><tr><td>4.2.1</td><td>Related cloud-based modeling studies</td><td>50</td></tr><tr><td>4.2.2</td><td>Study design</td><td>51</td></tr><tr><td>4.2.3</td><td>Findings</td><td>53</td></tr><tr><td>4.2.4</td><td>Open challenges</td><td>55</td></tr><tr><td>4.2.5</td><td>Opportunities</td><td>56</td></tr><tr><td>4.2.6</td><td>Conclusion</td><td>58</td></tr></table>

5 Assessing the quality of IoT Engineering Platforms 59

<table><tr><td>5.1</td><td>Introduction</td><td>59</td></tr><tr><td>5.2</td><td>Overview on Software Quality Models</td><td>60</td></tr><tr><td>5.3</td><td>The product quality model</td><td>61</td></tr><tr><td>5.3.1</td><td>Functional suitability</td><td>61</td></tr><tr><td>5.3.2</td><td>Performance efficiency</td><td>62</td></tr><tr><td>5.3.3</td><td>Compatibility</td><td>62</td></tr><tr><td>5.3.4</td><td>Reliability</td><td>63</td></tr><tr><td>5.3.5</td><td>Usability</td><td>63</td></tr><tr><td>5.3.6</td><td>Security</td><td>63</td></tr><tr><td>5.3.7</td><td>Maintainability</td><td>64</td></tr><tr><td>5.3.8</td><td>Portability</td><td>64</td></tr><tr><td>5.4</td><td>Quality assessment of IoT engineering platforms</td><td>64</td></tr><tr><td>5.4.1</td><td>Selection of the evaluated IoT engineering platforms</td><td>64</td></tr><tr><td>5.4.2</td><td>Research questions</td><td>65</td></tr><tr><td>5.4.3</td><td>Assessment process</td><td>65</td></tr><tr><td>5.5</td><td>Assessment results</td><td>66</td></tr><tr><td>5.6</td><td>Discussion</td><td>69</td></tr><tr><td>5.6.1</td><td>Model suitability</td><td>69</td></tr><tr><td>5.6.2</td><td>Model limitations</td><td>70</td></tr><tr><td>5.7</td><td>Conclusion and Future work</td><td>71</td></tr></table>

6 CHESSIoT: An approach for engineering multi-layered IoT systems 72

<table><tr><td>6.1</td><td>Introduction</td><td>73</td></tr><tr><td>6.2</td><td>The CHESSIoT engineering methodology</td><td>74</td></tr><tr><td>6.3</td><td>Motivating comparative analysis</td><td>75</td></tr><tr><td>6.3.1</td><td>Selected platforms</td><td>75</td></tr><tr><td>6.3.2</td><td>IoT modeling support</td><td>76</td></tr><tr><td>6.3.3</td><td>IoT engineering capabilities</td><td>78</td></tr><tr><td>6.4</td><td>The CHESSIoT domain specific language</td><td>81</td></tr><tr><td>6.4.1</td><td>System-level DSL</td><td>81</td></tr><tr><td>6.4.2</td><td>Software DSL</td><td>82</td></tr><tr><td>6.4.3</td><td>Deployment metamodel</td><td>84</td></tr><tr><td>6.5</td><td>Discussion</td><td>86</td></tr><tr><td>6.6</td><td>Conclusion</td><td>87</td></tr></table>
<table>
  <tbody>
    <tr>
      <td>7</td>
      <td>CHESSIoT safety analysis support for safety-critical IoT systems</td>
      <td>88</td>
    </tr>
    <tr>
      <td>7.1</td>
      <td>Introduction</td>
      <td>89</td>
    </tr>
    <tr>
      <td>7.2</td>
      <td>Proposed safety analysis approach</td>
      <td>90</td>
    </tr>
    <tr>
      <td>7.2.1</td>
      <td>Model-based safety analysis process</td>
      <td>90</td>
    </tr>
    <tr>
      <td>7.2.2</td>
      <td>FPTC Calculus</td>
      <td>91</td>
    </tr>
    <tr>
      <td>7.2.3</td>
      <td>CHESS2FLA transformation</td>
      <td>92</td>
    </tr>
    <tr>
      <td>7.2.4</td>
      <td>Fault-Tree generation</td>
      <td>93</td>
    </tr>
    <tr>
      <td>7.2.5</td>
      <td>Fault-Tree Analysis</td>
      <td>97</td>
    </tr>
    <tr>
      <td>7.3</td>
      <td>Evaluation process</td>
      <td>101</td>
    </tr>
    <tr>
      <td>7.3.1</td>
      <td>Evaluation process</td>
      <td>101</td>
    </tr>
    <tr>
      <td>7.3.2</td>
      <td>Motivating example: Patient Monitoring System (PMS)</td>
      <td>101</td>
    </tr>
    <tr>
      <td>7.3.3</td>
      <td>Research questions</td>
      <td>102</td>
    </tr>
    <tr>
      <td>7.4</td>
      <td>Experimental results</td>
      <td>103</td>
    </tr>
    <tr>
      <td>7.4.1</td>
      <td>Short literature review (RQ1)</td>
      <td>103</td>
    </tr>
    <tr>
      <td>7.4.2</td>
      <td>PMS system modeling (RQ2)</td>
      <td>106</td>
    </tr>
    <tr>
      <td>7.4.3</td>
      <td>System failure behavior (RQ3)</td>
      <td>107</td>
    </tr>
    <tr>
      <td>7.4.4</td>
      <td>PMS Fault tree analysis (RQ4)</td>
      <td>110</td>
    </tr>
    <tr>
      <td>7.5</td>
      <td>Conclusion and future work</td>
      <td>113</td>
    </tr>
    <tr>
      <td>8</td>
      <td>Supporting for development and deployment of IoT systems with CHESSIoT</td>
      <td>115</td>
    </tr>
    <tr>
      <td>8.1</td>
      <td>Introduction</td>
      <td>116</td>
    </tr>
    <tr>
      <td>8.2</td>
      <td>Software modeling and development approach</td>
      <td>117</td>
    </tr>
    <tr>
      <td>8.2.1</td>
      <td>Specification of CHESSIoT software models</td>
      <td>118</td>
    </tr>
    <tr>
      <td>8.2.2</td>
      <td>The CHESSIoT to ThingML transformation</td>
      <td>119</td>
    </tr>
    <tr>
      <td>8.3</td>
      <td>Model-based deployment plan and run-time services provisioning</td>
      <td>122</td>
    </tr>
    <tr>
      <td>8.3.1</td>
      <td>Deployment plan design</td>
      <td>122</td>
    </tr>
    <tr>
      <td>8.3.2</td>
      <td>Service provisioning design</td>
      <td>124</td>
    </tr>
    <tr>
      <td>8.3.3</td>
      <td>Deployment artifacts generation</td>
      <td>126</td>
    </tr>
    <tr>
      <td>8.4</td>
      <td>Case study: Home Automation System (HAS)</td>
      <td>128</td>
    </tr>
    <tr>
      <td>8.4.1</td>
      <td>HAS modeling and Fault-Tree analysis</td>
      <td>128</td>
    </tr>
    <tr>
      <td>8.4.2</td>
      <td>Software design and development</td>
      <td>133</td>
    </tr>
    <tr>
      <td>8.4.3</td>
      <td>Deployment and service provisioning</td>
      <td>138</td>
    </tr>
    <tr>
      <td>8.5</td>
      <td>Conclusion</td>
      <td>140</td>
    </tr>
    <tr>
      <td>9</td>
      <td>Conclusion and future work</td>
      <td>141</td>
    </tr>
    <tr>
      <td>9.1</td>
      <td>General contributions</td>
      <td>141</td>
    </tr>
    <tr>
      <td>9.2</td>
      <td>Publications</td>
      <td>143</td>
    </tr>
    <tr>
      <td>9.2.1</td>
      <td>Journal papers</td>
      <td>143</td>
    </tr>
    <tr>
      <td>9.2.2</td>
      <td>Conference papers</td>
      <td>143</td>
    </tr>
    <tr>
      <td>9.2.3</td>
      <td>Workshop papers</td>
      <td>143</td>
    </tr>
    <tr>
      <td>9.2.4</td>
      <td>Technical Reports</td>
      <td>144</td>
    </tr>
    <tr>
      <td>9.3</td>
      <td>Developed tools</td>
      <td>144</td>
    </tr>
    <tr>
      <td>9.4</td>
      <td>Future Directions</td>
      <td>145</td>
    </tr>
    <tr>
      <td colspan="2">Appendices</td>
      <td>147</td>
    </tr>
    <tr>
      <td>A</td>
      <td>Software product quality evaluation questionnaire for IoT LCDP and MDE</td>
      <td>147</td>
    </tr>
    <tr>
      <td>B</td>
      <td>Fault-Tree generation</td>
      <td>150</td>
    </tr>
    <tr>
      <td>B.1</td>
      <td>FLA2FT transformation rules</td>
      <td>150</td>
    </tr>
    <tr>
      <td>B.2</td>
      <td>FT2FT transformation: Qualitative and quantitative analysis</td>
      <td>153</td>
    </tr>
    <tr>
      <td>C</td>
      <td>Installing CHESSIoT extension on top of CHESS</td>
      <td>159</td>
    </tr>
  </tbody>
</table>
List of Figures

<table><tr><td>2.1</td><td>IoT system building blocks</td><td>8</td></tr><tr><td>2.2</td><td>IoT conceptual metamodel [1]</td><td>12</td></tr><tr><td>2.3</td><td>An FT example</td><td>14</td></tr><tr><td>2.4</td><td>CHESS editor overview</td><td>19</td></tr><tr><td>2.5</td><td>CHESS views architecture [2]</td><td>21</td></tr><tr><td>2.6</td><td>Wheel Braking System requirement example</td><td>21</td></tr><tr><td>2.7</td><td>Wheel Braking System internal block diagram</td><td>22</td></tr><tr><td>2.8</td><td>Producer-consumer: components implementation modeling</td><td>22</td></tr><tr><td>2.9</td><td>Producer-consumer: extra-functional properties modeling</td><td>23</td></tr><tr><td>2.10</td><td>Producer-consumer: software-to-hardware allocation</td><td>23</td></tr><tr><td>2.11</td><td>Producer-consumer: Schedulability analysis results</td><td>25</td></tr><tr><td>2.12</td><td>Producer-consumer: End-2-end response time analysis results</td><td>25</td></tr><tr><td>2.13</td><td>Example of a FormalProperty formalizing a requirement</td><td>26</td></tr><tr><td>2.14</td><td>Example of a component contract</td><td>26</td></tr><tr><td>2.15</td><td>State machine modeling faulty behavior</td><td>27</td></tr><tr><td>2.16</td><td>Process of Security breach</td><td>28</td></tr><tr><td>2.17</td><td>Erroneous state transition due to security threat event and vulnerability</td><td>28</td></tr><tr><td>2.18</td><td>Example of parameterized architecture</td><td>29</td></tr><tr><td>2.19</td><td>Trade-off Analysis results sample</td><td>29</td></tr><tr><td>2.20</td><td>Generated report sample</td><td>30</td></tr><tr><td>4.1</td><td>Feature diagram representing the top-level variation areas</td><td>47</td></tr><tr><td>4.2</td><td>Search and selection process</td><td>51</td></tr><tr><td>4.3</td><td>Selected approach distribution</td><td>53</td></tr><tr><td>4.4</td><td>Accessibility vs Open</td><td>54</td></tr><tr><td>5.1</td><td>Software Product Quality Model</td><td>62</td></tr><tr><td>5.2</td><td>Primary studies selection process</td><td>65</td></tr><tr><td>5.3</td><td>Overview of the selected basic studies</td><td>66</td></tr><tr><td>5.4</td><td>Quality characteristics support</td><td>68</td></tr><tr><td>5.5</td><td>Quality sub-characteristics performances</td><td>69</td></tr><tr><td>5.6</td><td>Average quality sub-characteristics performances</td><td>70</td></tr><tr><td>6.1</td><td>High-level approach</td><td>74</td></tr><tr><td>6.2</td><td>CHESSIoT System-level metamodel</td><td>81</td></tr><tr><td>6.3</td><td>CHESSIoT Software Metamodel</td><td>83</td></tr><tr><td>6.4</td><td>CHESSIoT Deployment Metamodel</td><td>85</td></tr><tr><td>6.5</td><td>Overall comparative supporting results</td><td>86</td></tr><tr><td>7.1</td><td>Safety analysis process</td><td>91</td></tr><tr><td>7.2</td><td>CHESS-FLA meta-model [3]</td><td>93</td></tr><tr><td>7.3</td><td>FT meta-model [4]</td><td>94</td></tr><tr><td>7.4</td><td>Event types</td><td>95</td></tr></table>
<table>
  <tbody>
    <tr>
      <td>7.5 Expression 7.5 corresponding tree</td>
      <td>97</td>
    </tr>
    <tr>
      <td>7.6 Qualitative transformation example (a) before, (b) after</td>
      <td>100</td>
    </tr>
    <tr>
      <td>7.7 Probability calculation formula</td>
      <td>100</td>
    </tr>
    <tr>
      <td>7.8 Basic architecture of Patient Monitoring System [5]</td>
      <td>102</td>
    </tr>
    <tr>
      <td>7.9 Feature support performances</td>
      <td>106</td>
    </tr>
    <tr>
      <td>7.10 Patient monitoring system</td>
      <td>107</td>
    </tr>
    <tr>
      <td>7.11 PMS components failures rates set</td>
      <td>110</td>
    </tr>
    <tr>
      <td>7.12 PMS monitor screen shown no data</td>
      <td>111</td>
    </tr>
    <tr>
      <td>7.13 The monitor fails to display data completely on the screen</td>
      <td>112</td>
    </tr>
    <tr>
      <td>7.14 Alarm sub-system alert false signal</td>
      <td>113</td>
    </tr>
    <tr>
      <td>8.1 Software development process</td>
      <td>117</td>
    </tr>
    <tr>
      <td>8.2 Behavior event &amp; action relationship</td>
      <td>118</td>
    </tr>
    <tr>
      <td>8.3 State and state transition</td>
      <td>119</td>
    </tr>
    <tr>
      <td>8.4 High-level transformation steps</td>
      <td>120</td>
    </tr>
    <tr>
      <td>8.5 Payload generation process</td>
      <td>121</td>
    </tr>
    <tr>
      <td>8.6 State machine generation process snippet</td>
      <td>121</td>
    </tr>
    <tr>
      <td>8.7 Deployment design process</td>
      <td>123</td>
    </tr>
    <tr>
      <td>8.8 CHESSIoT context model</td>
      <td>124</td>
    </tr>
    <tr>
      <td>8.9 Service provisioning metamodel</td>
      <td>125</td>
    </tr>
    <tr>
      <td>8.10 Deployment artifact generation (Acceleo)</td>
      <td>127</td>
    </tr>
    <tr>
      <td>8.11 Home Automation System</td>
      <td>129</td>
    </tr>
    <tr>
      <td>8.12 Home Automation System internal diagram</td>
      <td>130</td>
    </tr>
    <tr>
      <td>8.13 Analysis results</td>
      <td>131</td>
    </tr>
    <tr>
      <td>8.14 Room-level FT diagram: Window not working (omission at the window output port)</td>
      <td>132</td>
    </tr>
    <tr>
      <td>8.15 Room-level FT diagram: ACUnit turn on and off when not expected</td>
      <td>133</td>
    </tr>
    <tr>
      <td>8.16 System-level FT diagram: Mobile phone displays inaccurate data scenario</td>
      <td>134</td>
    </tr>
    <tr>
      <td>8.17 Room internal composite structure</td>
      <td>135</td>
    </tr>
    <tr>
      <td>8.18 Portion of the Board event, action, guard specification</td>
      <td>135</td>
    </tr>
    <tr>
      <td>8.19 Board state machine</td>
      <td>136</td>
    </tr>
    <tr>
      <td>8.20 Generated ThingML models</td>
      <td>137</td>
    </tr>
    <tr>
      <td>8.21 Generated Board's ThingML model mapped to the state machine diagram</td>
      <td>137</td>
    </tr>
    <tr>
      <td>8.22 HAS system deployment plan</td>
      <td>138</td>
    </tr>
    <tr>
      <td>8.23 Generated deployment configuration Fog</td>
      <td>139</td>
    </tr>
    <tr>
      <td>8.24 FogDepAgent rules</td>
      <td>140</td>
    </tr>
  </tbody>
</table>
# List of Tables

<table><tr><td>4.1 Taxonomy table</td><td>48</td></tr><tr><td>4.2 Results table</td><td>52</td></tr><tr><td>4.3 Analyzed approaches</td><td>54</td></tr><tr><td>4.4 Recommended technologies</td><td>57</td></tr><tr><td>5.1 Assessment overview</td><td>67</td></tr><tr><td>6.1 Selected approaches for the comparative analysis</td><td>76</td></tr><tr><td>6.2 Comparative table on supporting different IoT modeling features</td><td>77</td></tr><tr><td>6.3 Comparative table on supporting different IoT engineering capabilities</td><td>79</td></tr><tr><td>7.1 Failure types</td><td>92</td></tr><tr><td>7.2 Selected approaches</td><td>104</td></tr><tr><td>7.3 Results from the studied approaches</td><td>105</td></tr><tr><td>7.4 PMS failure behavior table</td><td>109</td></tr><tr><td>8.1 CHESSIoT2ThingML transformation mapping</td><td>120</td></tr><tr><td>8.2 CHESSIoT2Ansible transformation mapping</td><td>125</td></tr></table>
# List of Listings

<table><tr><td>7.1</td><td>Extended FLA syntax expression</td><td>92</td></tr><tr><td>8.1</td><td>Run-time Service provisioning definition example</td><td>126</td></tr><tr><td>B.1</td><td>FLA2FT ETL transformation rules</td><td>150</td></tr><tr><td>B.2</td><td>FT2FT ETL transformation rules</td><td>153</td></tr></table>
# Chapter 1

## Introduction

The current advancement in software engineering is transforming how we live our daily lives by providing a smoother living experience by automating essential lifestyle tasks. IoT technologies are one of the critical drivers of such a technological revolution which devotes the most priority to enhancing the well-being of humanity. However, because of the competitive challenges imposed by digitalization, [6], businesses are always looking for innovative approaches that can tackle complex problems and reduce time to market, as well as the costs associated with development while maintaining the optimum software quality.

A typical IoT system is regarded as a powerful multi-layered network of systems that integrates many heterogeneous, independently networked systems working together to achieve a shared purpose. In general, a typical IoT system consists of multiple layers. For instance, at a low level, we have the edge layer, which is made up of devices and sensors that collect data from the physical world and communicate it to the next layer. The fog layer serves as an intermediate layer between the edge devices and the cloud, enabling local data processing and decision-making. It can perform various tasks, including data filtering, aggregation, analytics, and even running certain applications locally. Finally, the cloud layer is a centralized repository where data from all devices is stored and analyzed. This layer can also include services such as data storage, analysis, and management. Such systems demand various development skills, from handling tiny microcontrollers to more extensive and complex cloud-based systems. Each layer is crucial to enable the system to operate efficiently and offer users valuable insights and automation capabilities [7].

Engineering such systems is challenging and complex primarily due to the ever-increasing heterogeneity in every aspect that needs to be combined to fully produce a well-sensed and functional system [8]. Model-Driven Engineering (MDE) seeks to support the automation of the software development process by employing models as the primary artifact in the development of complex systems. Through high-level abstractions, MDE can provide a unique means for representing many aspects of heterogeneous systems all in one place thanks to modeling languages, specifically Domain-Specific Modeling Languages (DSMLs). Tackling such heterogeneity is essential to look at every system sub-component as a black box, where both the physical characteristics and the software that manages them are highly linked [9]. These sub-systems can be designed, developed, tested, and analyzed independently, and later they can be integrated to form a fully functioning system.

Cloud-based modeling is one of the relevant topics in the MDE community due to the induced possibilities of designing, developing, analyzing, and deploying applications seemingly with reduced efforts. This has also been recently favored by the increasing adoption of Low-Code Development Platforms (LCDPs). LCDPs aim to tackle the shortage of highly skilled professional software developers by enabling end-users with no or limited programming background (referred to as citizen developers in LCDP terminology) to contribute to software development processes without sacrificing the productivity of professional developers [10]. LCDPs have been especially successful in developing domain-specific applications in four market segments: database applications, mobile applications,
process applications, and request-handling applications [11]. IoT is expected to be the fifth one. Low-
comote project [11] aims to push advancement in LCDP to a more technical and sophisticated era of
"Low-Code Engineering (LCE)" by employing the concrete basic engineering principles in the mod-
eling world. The merge of MDE, Cloud computing, and Machine Learning techniques will do this.
Ideally, domain-specific LCDPs have to run on cloud infrastructures, even though in some industrial
settings such as IoT, domain-specific modeling environment tends to be local-based [12].

This dissertation presents the current state of research on MDE approaches for IoT by taking a particular account of LCDPs. We present the results from a taxonomy and the findings that have been done by analyzing sixteen IoT development platforms. In addition, we looked at what has been done so far in the IoT domain to support IoT systems' development through cloud-based settings. In particular, we conducted a thorough investigation to see where the IoT community stands concerning the current trend of moving traditional modeling infrastructures to the cloud. After examining 611 articles, we identified 22 different cloud-based IoT system development tools and platforms. Furthermore, we perform an analysis of the various issues that the IoT community is encountering while implementing cloud-based modeling tools. As a result, we take a deeper look at a few options and discuss the research and development opportunities enabled by adopting LCE approaches in the IoT domain [13].

Deciding whether such engineering platforms meet the minimum required software quality stan-
dards is complex. Software quality can be defined as the degree to which a software system achieves its
intended goal. Various software quality standards have been established to aid in the software quality
assessment process; however, due to the nature of engineering IoT platforms, such models may only
partially suit the IoT domain. This dissertation presents a model for assessing the software quality of
Low-Code and MDE platforms for engineering IoT platforms. The proposed software quality model
is based on and extends the ISO/IEC 25010:2011 [14] software product quality model standard. It is
intended to assist IoT practitioners in assessing and establishing quality requirements for engineering
IoT platforms. We have also presented the methodology used to choose such platforms and perform
the quality assessment while subsequently presenting and discussing the results.

MDE tools have proven potential to provide significant benefits in the development of complex
systems [15, 16]. However, as the complexity of the systems grows, MDE tools will need to handle
large-scale models, which can be computationally expensive and may lead to scalability issues. Con-
sidering the heterogeneity in all aspects of IoT systems, MDE tools need to provide a way to integrate
these diverse components and ensure interoperability [8]. Additionally, the dynamic nature of IoT
systems, where devices can join or leave the network at any time, poses another challenge for MDE
tools. The models need to be adaptive to changes and allow for the efficient reconfiguration of the
system [9]. Furthermore, deploying IoT systems can be challenging, as they often operate in highly
distributed and complex environments. Therefore, MDE tools must provide mechanisms for deploy-
ing and managing the system components in a scalable and efficient way [17]. This includes automatic
deployment of software updates, efficient management of resources, and monitoring of the system's
performance.

1.1 Challenges and motivation

While engineering IoT systems has been subject of intense research, several challenges are still present in the IoT domain. In this section, we highlight different research problems (RP) that is being tackled in this thesis.

1. RPI: Low-Code Engineering Platforms and their usage in engineering IoT systems

While the complexity of implementing IoT systems is enormous in all aspects, the current tech-
nical demand provides significant obstacles to better software development techniques that re-
duce developer issues. The recent Low-code practices for developing software remain a highly
debated topic regarding the degree to which such approaches can be used and the level at which
they can satisfy user expectations in developing complex software in fields such as IoT. With the
rapid increase of intelligence on how traditional code-centric software development is done in
domains such as IoT, enabling Low-code approaches applied in such domains could contribute
toward better software production yield. Understanding what Low-Code Engineering Platforms
are and their difference with respect to existing Low-Code Development Platforms remains a
work in progress within the software engineering industry. Taking LCDPs from a systems en-
gineering standpoint and industrial automation provides a good picture of what LCEP could be
and achieve if made a reality.

2. **RP2: Evaluating the software quality of Low-Code Engineering Platforms**

Over the last few years, industry and academia have proposed different LCDPs to ease the
development process of IoT systems. However, deciding whether those platforms meet the
crucial software quality standards is a complex process as it involves considering and exploring
various aspects. In general, in domains such as System engineering, Space, and Automation,
practitioners typically rely on well-established standards and practices to improve confidence
in whether a system or a product fulfils the required quality requirements. For example, in the
past, the ISO/IEC 25010:2011 standard has been adopted to assess not only the product quality
of IoT systems [18–20] but also in domains such as Big data [21], Machine Learning [22],
Software Product Lines (SPL) [23], Customer Relationship Management (CRM) systems [24]
and mobile apps [25], to mention a few. However, when it comes to IoT in general, taking
Low-code and MDE tools in particular, there still needs to be a massive gap in what to consider
when evaluating their software product quality attributes.

3. **RP3: Supporting modeling of multi-layered IoT systems**

There are several challenges in modeling multi-layered IoT systems. One of the main challenges is the system's complexity, which can involve many interconnected components, each with its own set of characteristics and behaviors [26]. This can make it challenging to develop a comprehensive model that captures all of the relevant factors that influence the functional and behavioral aspects of the system. In addition, the dynamic nature of the IoT system, with devices and applications constantly changing and evolving, further complicates the process. Another ongoing challenge is the need to integrate diverse technologies and standards across different system layers [27]. For example, the device layer may use different communication protocols than the fog layer; on the cloud, the application layer may require more data formats than the computing layer. Modeling these different technologies and standards seamlessly and efficiently can be difficult and may require specialized knowledge and expertise in various areas, including networking, software development, and data analytics. Few of the existing model-driven approaches have tackled such issues however, being able to achieve such a modeling task and at the same time offering means to perform other crucial engineering tasks on the model is still an open issue.

4. **RP4: Providing means for performing safety analysis of IoT systems**

A significant challenge to be recognized in IoT ecosystems is how to provide a reliable infras-
tructure for the billions of expected devices and how to deliver their intended services without
failing in unexpected and catastrophic ways [28]. Aside from the inherent difficulties in realiz-
ing multi-layered IoT applications systems, software developers often make the false assump-
tions that devices will always succeed [29]. Indeed, IoT systems might fail for a wide range
of reasons: device age, data sources, communication protocols, deployment environments, and
human errors. In the past, safety engineers relied on different informal design artifacts and
documents to measure the safety compliance of the system with less or no involvement of sys-
tem engineers. Later, several approaches, such as [4, 30–33] (to mention a few), have emerged
in the field by providing a tool that adds a degree of automation during the analysis process,
bridging the gap between the system and safety engineers. However, these approaches were
designed and developed to fit mostly the legacy domains such as aerospace, automotive, and
industrial manufacturing systems. Therefore, such methods might partially reflect IoT. Thus, providing foundational concepts and approaches to support the IoT safety process to cope with the complex nature present in IoT ecosystems can potentially contribute to tackling such gap [34].

5. **RP5: Supporting the development and deployment of IoT systems across multiple layers**

The development and deployment of IoT systems require a multi-disciplinary approach that considers the system's hardware, software, and communication aspects. By carefully considering each layer and selecting the appropriate technologies and tools, developers can build robust, scalable, and secure IoT systems that meet the needs of today's businesses and consumers. MDE has shown capabilities to tame some of the complex problems found in software engineering through abstraction. To increase productivity and reduce time to market, models are defined with concepts that are much less bound to their underlying implementation technology and much closer to the problem domain of interest [35]. However, due to the inherent complexity and heterogeneity present in the IoT domain, engineering platforms such as MDE4IoT [36], ThingML [37], IoTML/BRAIN-IoT [38, 39], SimulateIoT [40] and Montithings [17] (to name a few), have demonstrated the potential to be realistic alternatives for developing scalable IoT systems leveraging MDE approaches. While that is the case, finding a platform capable of fully engineering such systems by integrating modeling, software development, system analysis, and deployment becomes challenging.

To tackle the challenges mentioned above, we present the CHESSIoT framework, an environment for engineering IoT systems. CHESSIoT brings a unique possibility to the user to perform the modeling, development, safety analysis, and deployment of multi-layered IoT systems, all from a unique environment. This is achieved through multi-view models, most notably the physical, functional, and deployment architectures. The physical system-level model is annotated with Failure Logic behaviors in which the analysis results are used to perform both qualitative and quantitative safety analysis by employing logical Fault-Trees models (FTs) [41] On the other hand, the software model is equipped with the system's functional and behavioral aspects, and it is employed to generate platform-specific code that can be deployed on low-level IoT device nodes. Furthermore, the framework supports modeling of the system's deployment plan, which is ultimately transformed into deployment configuration artifacts ready to be deployed on remote servers. To facilitate deployment, the tool offers means to design run-time service provisioning modules through deployment agents, which are then used to configure and remotely manage the run-time life-cycle of deployed services.

Throughout this doctoral thesis, we exploit various assessment techniques, such as, but not limited to, addressing potential research questions relative to the specific topic of interest. In addition, we rely on implications from comparative analyses to evaluate the effectiveness of our proposed approach and our contribution relative to the existing approaches. To demonstrate the supporting tool's capabilities in satisfying specific developer requirements, different running demonstrations were implemented.

**1.2 Main achieved research and technological results**

*Employing Low-Code Engineering for engineering IoT systems*

Low-Code Engineering (LCE), as a relatively new concept in the MDE industry, has sparked much controversy and misunderstanding about what it is and how it differs from the previous Low-code development methodologies. Furthermore, there is still discussion about what both novel approaches add or change compared to existing MDE techniques. Although in this dissertation we concentrate on the IoT domain, we would therefore discuss their similarities, interdependence, and differences in the procedure for software engineering. As an answer to the first research problem (RP1), this dissertation we highlights the current state of the art regarding how IoT developers are incorporating low-code methodologies into their development process. For instance, as presented in Chapter 4, in [8], we examined 16 different platforms to gain a better understanding of the current state of supporting the
development of IoT systems, with a focus on languages and tools available in the MDE field and emerging LCDPs. In [13], we examined 22 low-code environments by assessing their strengths and weaknesses regarding cloud-based modeling capacity, accessibility, openness, and artifact generation. This work was published both in [13] and [8].

## Software product model for evaluating the software product quality of LCEPs in IoT domain

As the IoT LCE tools go to market, their quality to satisfy the user requirements is always questionable since there are not yet established mechanisms for assessing their software product qualities. To answer the second research problem (RP2), this dissertation goes a step further by proposing a software product quality model intended to help people interested in developing or purchasing low-code software products and systems specify and evaluate their quality requirements. In doing so, it presents a quality model based on the ISO/IEC 25010:2011 standard [14] with the enhanced definition of a product quality assessment model that is more suitable for the IoT domain. In the end, the evaluation mechanism of the proposed quality was done by employing it to assess the software product quality of 17 IoT low-code and MDE platforms selected from our previous studies [8, 13]. Finally, we present the methodology we used to choose such platforms, perform the quality assessment, and subsequently present and discuss the obtained results. This work was published in [27].

## Multi-view modeling environment for IoT systems

In this dissertation, we introduce the CHESSIoT modeling environment and languages for multi-layered IoT systems as an answer to the third research problem (RP3). To tackle the scalability and complexity of modeling IoT systems, in CHESSIoT different aspects of the system are modeled independently from their respective views and later interlinked to satisfy specific engineering tasks being performed on the model. To achieve that, the designer relies on a series of CHESSIoT DSLs in which the meta-modeling syntax has been specified as an extension to both UML/SysML modeling languages. CHESSIoT DSLs are made up of three primary DSLs (abstract syntaxes), namely *SystemDSL* for IoT system-level modeling, *SoftwareDSL* for functional and behavioral modeling, and the *DeploymentDSL* for deployment-related aspect modeling and runtime service provisioning. To guarantee a fully decoupled extension, CHESSIoT introduced the *"IoT sub-view"* constraint and once applied in all design stages, the user will benefit from a dedicated IoT-specific modeling infrastructure consisting of specific diagrams and palettes. This also enforces correctness and error avoidance during the design phase, as palette elements can be hidden or shown based on the current state of the modeling process (e.g., diagram type or view type).

## Model-based safety analysis of safety critical IoT systems

As an answer to the fourth research problem (RP4), this dissertation introduce the CHESSIoT model-driven safety analysis approach targeting IoT systems based on the Fault-Tree Analysis (FTA) approach. The approach runs on top of CHESSIoT, a model-driven development environment for the modeling and the analysis of industrial IoT systems [42, 43]. The presented approach relies on CHESS Failure Logic Analysis (CHESS-FLA) [44], a methodology that enables the user to: i) model system's failure behavior of the system through the decoration of the system model components with safety-related information, ii) run the Failure Logic Analysis (FLA), iii) and propagate the analysis results back onto the original model [45]. The new approach allows the specification of systems failure modes and generates the system's complete Fault-tree based on the failure logic analysis results. In addition, the new approach automatically performs qualitative analyses, which analyze the generated fault trees and eliminates unnecessary paths and redundancies in the FTs' events. Finally, in addition to the qualitative analysis, the proposed approach also calculates the failure probabilities of an entire system from its constituent parts' failure event probabilities. This calculation is automatically performed following the well-known logic Fault-tree probabilities calculations mechanism [46–48].

## Model-based development and deployment support for IoT systems
As an answer to the fifth research problem (RP5), this dissertation also present the CHESSIoT software design approach that combines both the functional and behavioral modeling aspects targeting the IoT device layer. The functional design involves the systematic definition of the main software components, their sub-components, and their interconnection. Each system's main sub-function is entitled to its state machine, in which aspects such as message payloads, events, actions, and guards are associated with states and their transitions to realize the desired behavioral goal. When the model is complete, the CHESSIoT model is transformed into ThingML models [37], which eventually is used to generate platform-specific code. ThingML is a well-proven software modeling tool aligned with UML (state charts and components) and an imperative platform-independent action language to construct the intended IoT applications [8]. Although the ThingML model can compile and generate code in different languages such as Arduino, C/C++, Java, JavaScript, and Go, the implemented code generator that is supported by our tool only satisfies the CHESSIoT models targeting Arduino-based computing devices. In addition, CHESSIoT provides a deployment environment that aims to support the users in decomposing IoT system deployment plans and managing deployed node services at all layers. The deployment model connects the software to the actual system nodes in which the software program will be executed. Finally, CHESSIoT deployment offers a model-driven approach for runtime service provisioning that allows the definition of runtime software services provisioning and life-cycle management. The provisioning model is defined in the form of deployment rules referred to as agents.

## 1.3 Structure of the dissertation

The rest of the dissertation is organized as follows: **Chapter 2** provides the general background of the fundamental concepts and principles such as IoT as a multi-layered ecosystem, MDE and low-code around which this dissertation is based on. **Chapter 3** summarizes state of the art on IoT engineering platforms related to several topics discussed in this dissertation. **Chapter 4** presents the limitations and open challenges of existing IoT Engineering platforms by relying on experimental studies on focusing their general features and what such platforms should be supporting. **Chapter 5** presents a model for assessing the software product quality of Low-Code and MDE engineering platforms for IoT development platforms. **Chapter 6** introduces the CHESSIoT engineering approach and a motivating comparative analysis as an evaluation mechanism. The chapter also presents CHESSIoT DSL in great detail and compares its contribution with respect to the existing DSLs. **Chapter 7** presents CHESSIoT's two-fold safety analysis approach for IoT systems based on Fault Trees models. **Chapter 8** presents the supported development and deployment approach by showcasing the supported feature using a running example. Finally, **Chapter 9** concludes the dissertation and highlights the future outlooks.
# Chapter 2

## Background

This chapter provides a general overview of the essential concepts and principles around which this dissertation is founded. By partially targeting to answer the first research problem (RP1), this chapter discusses the notions of IoT systems in the context of multi-layered architecture, Model-Driven Engineering (MDE) concepts, and how they relate in handling IoT domain complexity. The chapter also covers Low-Code Engineering (LCE) concepts in general, as well as where Low-code and MDE approaches fit in such a context. Finally, it provides an overview of the CHESS environment, on which the proposed engineering platform is based.

**The chapter is organized as follows:** Section 2.1 provides a high-level overview of the IoT as a multi-layered ecosystem. Section 2.2 provides a broad introduction to MDE, Domain Specific Languages, and IoT reference architectures. Section 2.3 introduces Low-Code Engineering Platforms (LCEPs) in general and how they differ from Low-Code Development Platforms (LCDPs). Finally, Section 2.4 introduces CHESS platforms by emphasizing the supported model-based engineering aspects as well as different supported analysis techniques.

### 2.1 The Internet of Things

IoT is a term used to refer to the interconnection of devices over the internet. This interconnection enables the collection and exchange of information, as well as the management and automation of devices via a network. IoT offers a wide range of applications, including home automation and security, as well as healthcare, transportation, and agriculture [8]. IoT can enable smart devices such as refrigerators, lights, and appliances to be controlled remotely from a smartphone or other device in the household. IoT in healthcare can enable remote monitoring of patients and provide crucial data to physicians and caregivers [5]. IoT in transportation can improve safety by giving real-time traffic data and enabling autonomous driving systems [36].

#### 2.1.1 IoT system architecture

In the past, IoT was referred to as the emergence of barcodes and Radio Frequency Identification (RFID), which served to automate inventory, tracking, and basic identifying needs. However, nowadays IoT is a keen interest in interconnecting sensors, objects, devices, data, and applications [49]. A fully IoT system is often complex, with numerous players with varying levels of skill and multiple stakeholders with varying roles. According to Costa et al [50], IoT is defined as a collection of automated procedures and data that are integrated with heterogeneous entities (hardware, software, and humans) that interact with one other and with their environment to accomplish a common goal. Advances in technology, such as cloud computing, machine learning, and artificial intelligence, have accelerated the emergence of IoT. The potential for IoT to revolutionize businesses and enhance our
lifestyles grows as even more items become interconnected. Yet, there are worries regarding IoT's
security and privacy risks. There is a danger of information being hijacked or exploited because of all
the devices monitoring and transmitting information [49].

<figure><img src="image_4.png" /><figcaption>**Figure 2.1: IoT system building blocks**</figcaption></figure>

Figure 2.1 shows a high-level architecture of a typical IoT system. A thing is a combination of on-board devices including sensors, tags, actuators, and physical entities like cars, watches, etc. Data is generated from a sensor or a tag attached to the physical entity the user is interested in. A programmable device (such as an Arduino, a Pycom, a Raspberry Pi, etc.) collects data and sends them to the nearby gateway using some well-known protocols such as Z-Wave, MQTT, HTTP, Bluetooth, Wi-Fi, Zigbee, etc. The Gateway component acts as a bridge between the physical and digital worlds. Note that in some cases devices and gateways can make some simple computation logic and respond to some events without the need for further processing. The platform server is a combination of processing and storage resources on the cloud. At this stage, data can be streamed, analyzed, or manipulated for meaningful information to be communicated back to actuators, users, or third parties services.

Aside from the inherent difficulties in developing multi-device IoT applications for diverse plat-
forms, software developers often make false assumptions. One of these assumptions is that devices
will never fail [29]. Indeed, IoT systems might fail because of a wide range of reasons: device age,
data sources, communication protocols, deployment environment, as well as external environment
constraints, such as human error. In IoT ecosystems different types of error can occur: local errors,
which can be also detected from the device itself, like a failing sensor; or more complex errors that
affect multiple devices at the same time, for example, a network failure or a missing communication
pattern as a result of a device failure that causes the entire system to fail [17].

An important challenge to be recognized in the IoT ecosystem is how to provide a reliable in-
frastructure for the billions of expected devices and how to deliver their intended services without
failing in unexpected and catastrophic ways [28]. In nature, a system is considered to be fail-safe if
it has none or harmless failures, whereas a safety-critical system can have catastrophic failures that
can sometimes result in human life loss. In the healthcare domain, for instance, the monitoring of
hospitalized patients must be done with extreme caution as a simple failure, such as a false sensor data
reading, can have catastrophic consequences, including the patient's death. Because these systems are at the intersection of information technology and biomedical sciences, it is necessary to have a thorough understanding of how the connected components work as well as the ability to take perfect decisions either manually or through automated software. These systems are among the riskiest in terms of engineering because they interact directly with sick patients.

IoT things, being reactive systems, constantly interact with their surroundings, changing their states. Such entity behavior causes the IoT application extremely dynamic and thus susceptible to unanticipated behavior. Identifying unexpected behavior while also ensuring that essential functionality is in place can be difficult, especially in a dynamic system [51]. This can potentially be achieved by promoting advanced automated software engineering approaches and tools by which can software development could be done in a faster and more secure manner. Tools able to develop, deploy, and analyze the system's reliability to avoid future repair costs could be of huge impact. There are several successful platforms offered by some of the bigger industrial partners to tackle such challenges but looking at the complexity in terms of usability makes it even more challenging.

## 2.1.2 Safety Critical Systems

The term “safety-critical system” was created in response to growing concern and awareness about the use of computers in situations where human lives could be jeopardized if an error occurs [52]. Safety-critical systems are those systems whose failure could result in loss of life, significant property damage, or damage to the environment [53]. A safety-critical system should be ideally designed to lose no more than one life per billion hours of operation [54]. We can see many examples of such systems in the following domains: aviation, railway, medicine, nuclear engineering, and military. Developing such systems is difficult and must be done with extreme caution, as even the smallest error in the process can have disastrous consequences. More and more modern safety-critical systems are incorporating new technologies, such as machine learning techniques, to reduce the possibility of failure through intelligent responses provided by artificially trained robots [55].

A significant challenge recognized in the IoT ecosystem is how to provide a reliable infrastructure for the billions of expected devices and how to deliver their intended services without failing in unexpected and catastrophic ways [28]. In the IoT context, safety is often considered as the ability to detect and prevent any unintended failure behavior in IoT systems [34]. In the past, IoT systems were considered fail-safe because of their size, as their failures mostly had no or harmless consequences. However, due to the system's rise in size and complexity and the increased demand for IoT systems in the industry, errors and failures for such systems are unavoidable. For instance, IoT systems, such as Intelligent traffic lights, smart homes, smart manufacturing systems as well as patient monitoring systems, can suffer from potential failures generated internally in the system due to several issues such as age or poorly connected or failures caused by external influences such as weather or human error.

As research in this area continues, their developers deem existing proposed concepts and architectures safe. Still, they are frequently found to be impractical for real-life applications because safety-critical systems involve unpredictable behavior of lives, properties, or the environment [56]. In addition, as the technologies evolve in some domains, such as IoT, new failure modes, such as denial-of-service attacks against networked information systems, are emerging. Failures occur through physical effects and service disruption or data loss. The lack of a systematic, disciplined, and quantifiable software engineering methodology, as well as a comprehensive abstraction mechanism for dealing with the increasing complexity of safety-critical systems, results in a wide variety of similar, but not congruent, isolated solutions that cannot be easily reused and combined [34].

The number of computer systems that we consider safety-critical is expected to grow significantly in the future. In addition, the declining cost of hardware, improvements in hardware quality, and other technological advancements ensure that new applications will be sought in a wide range of domains [53]. However, for the analysis of the safety-critical systems, there is no universally accepted rigorous dependability analysis process, which helps in choosing the metrics, techniques, and methodologies for the dependability evaluation of such critical systems [57]. In any case, analysis of software devel-
opment approaches, as well as safety-critical software, is required to determine the most appropriate techniques for use in the production of future software for high-integrity systems [52].

## 2.2 Model-Driven Engineering

Model-driven engineering (MDE) is a software development methodology that aims at supporting software development and analysis by promoting the adoption of models as first-class citizens [10]. To advance the software development paradigm to a new level, MDE promotes software development through abstraction which significantly reduces the system complexity as well as the development time. To increase productivity and reduce time to market, models are defined with concepts that are much less bound to their underlying implementation technology and which are much closer to the problem domain of interest [35]. In MDE, models are used to specify, test, simulate, verify, modernize, maintain, understand, and generate code for the system, among many other activities [58].

Models in the context of MDE are not sketches or drawings that serve purpose only in design, but they prevail until the end of the development cycle of these systems as machine-readable and processable abstractions [59]. MDE favors the collaboration of engineers and stakeholders, as both work together toward the completion of the conceived products and foster integration of different engineering processes [60]. MDE can also aid to improve the quality of software systems, which is another advantage. Software engineers can reason about the system and make sure it complies with requirements more simply by using models to represent the system. Models are frequently easier to grasp and maintain since they are typically written in a higher-level language than general-purpose programming languages.

In the IoT domain, MDE can well be looked at as the methodology in which the development process focuses only on defining the system's IoT device's behaviors and the data they process, rather than on the platform that runs them. Generally, MDE enforces (i) the system model specification, in which the heterogeneous elements are precisely identified; (ii) promotes the reuse of system elements across teams and other applications (iii) tackles the application's complexity; and (iv) facilitates the communication between the system stakeholders [61]. Different complex engineering activities such as verification and validation as well as different analysis activities can be done on the model to quantify the robustness of the system under development as well as identify and correct any potential future failures that might arise.

The MDE process involves multiple stages, such as model development, model transformation, and code generation. A model of the system being developed is established by the software engineer during the model development step. The software engineer develops a set of rules for transforming the model into another model or into code during the model transformation process. The model transformation engine applies the transformation rules on the model to create a new model or code snippet, automating this step in most circumstances. During the code generation stage, the software engineer generates executable code using the model. This code can be in a traditional programming language, such as Java or C++, or it can be in a specialized language [37].

MDE has had tremendous success stories in many ways in academia as well as in industrial settings. This can be observed in areas such as model-based systems engineering (MBSE), low-code software development, and informal software modeling [62]. Furthermore, the quantitative results from the conceptual analysis of such systems can provide theoretical support for optimizing system architectures and parameters earlier enough [63]. However, this success has led to an even higher demand for better tools, theories, and general awareness about modeling, its scope, and application [64]. This can be looked at from the domain in which such tools are going to be used, technical implementation requirements, and social as well as evolving technologies.

Recently, MDE itself has faced challenges that have shifted the focus of the development of such complex and heterogeneous systems from local environments to the cloud [65]. Modeling-as-a-Service is gaining momentum as the MDE research community is migrating modeling tools and services to the cloud. This migration is encouraged by several out-of-box benefits in cloud computing,
such as easy discovery and reuse of services and artifacts [10]. It has enabled efficient self-healing mechanisms to detect, diagnose, and countermeasure threats and foster collaboration among stakeholders and engineers [66]. Furthermore, migrating modeling artifacts and services on the cloud can facilitate end-users' easy accessibility, hence supporting sustainable management and disaster recovery of model artifacts and tools [67].

Finally, the model can be used to perform even more advanced engineering tasks such as performing different analyses depending on the problem at hand [16]. For instance, it could be better to evaluate the model performance in a real-time state in order to get a sense of how the actual system generated from the model could behave in the long run [42]. Furthermore, models are often injected with external constraints to be able to verify and validate their behavior robustness for instance when code generation is involved [68]. In the IoT domain, there still presents a significant gap in the validation, verification, and analysis of such systems under development [42]. The main challenge is the scope of the analysis; because the number of IoT devices and applications is already large and is only likely to grow in the future, physical replication and testing of IoT systems are complex (due to scale) [69]. This potentially contributes to the long-standing lack of standardized realistic reference models that can perfectly capture the interactions between sensors, apps, and actuators.

### 2.2.1 Domain Specific Languages in IoT

Domain-specific languages (DSLs) are languages tailored to a specific application domain to define the domain models. These DSLs are used in MDE to pave the way for domain experts to be able to define the system's behavior based on their expertise [70]. A DSL is suited to the specific domain of the software system being developed; it is often used to express models. The DSL provides a way to represent the system at a higher level of abstraction than traditional programming languages and defines the syntax and semantics of the model. Although DSL-based development is hard and requires both domain knowledge and language development expertise, they offer tremendous benefits such as improved productivity for the developers as well as effective communication with the domain experts [71]. Finally, the models defined by these languages are intended to be far more human-oriented than common code artifacts, which are inherently machine-oriented [36].

In the IoT context, DSLs can be particularly useful for simplifying the process of developing software applications for IoT devices. As the core of IoT processes relies on IoT devices that are typically used for specific purposes, such as monitoring environmental conditions or controlling home automation systems. Each of these applications requires a unique set of functions and data structures, and developing software for each of these applications can be time-consuming and complex. DSLs can help to simplify this process by providing a specialized language that is tailored to the specific needs of the IoT application. This can make it easier for developers to write code that is optimized for the particular requirements of the device or application.

Engineering platforms such as MonitorIoT [26], MDE4IoT [36], IoTML [39] and MontiThings [17] (to name a few), have presented potential DSLs able to realistically tackle the high degree of heterogeneity in their hardware devices, data sources, protocols, deployment levels for developing scalable IoT systems. However, developing IoT code generators that are perfectly capable of handling large models and generates full-functional code is still an open issue. Approaches such as ThingML [37] is one of the top code generators in IoT that targets many popular programming languages such as C/C++, Java, and Javascript, and about ten different target platforms (ranging from tiny 8bit microcontrollers to servers) and ten different communication protocols.

Several research and industrial approaches have shown interest in applying ThingML as their modeling or code generation framework. To mention a few, in [72], ThingML has been used to generate code for CAPS, an architecture-driven modeling framework for the development of IoT Systems. In [73] ThingML has been used to specify the behavior of distributed software components, and later it has been extended with mechanisms to monitor and debug the execution flow of a ThingML program. Finally, CyprIoT tool [74] has relied on and extended the ThingML modeling language to model and control network-based IoT applications. Their tool relies on Rule-Based Policy Language, to control
and supervise the behavior of the modeled network and a code Generator that interpret the model and generates deployable network artifacts.

### 2.2.2 MDE for IoT reference model

IoT reference architectures provide a useful starting point for designing and implementing IoT systems. They offer a standardized approach to IoT system design and help to ensure interoperability and compatibility between different IoT systems. To support the development of complex IoT systems, several standards and tools have been proposed over the last years [61]. Standards like ISO/IEC/IEEE 15288¹ have been in use to evaluate the quality, efficiency, and life-cycle of different approaches. In [75] an IoT reference model (ITU-TY.2060) [76] is proposed by an International Telecommunication Union (ITU) and presented with respect to other four reference architectures developed in the context of the IoT-A [49], WSO2 [77], Korean RA [76] and Chinese [66] projects.

<figure><img src="image_5.png" /><figcaption>**Figure 2.2:** IoT conceptual metamodel [1]</figcaption></figure>

Figure 2.2 shows a conceptual representation of the elements shown in Figure 2.1. The physical properties of the associated *Physical entities* are captured through *Sensors*, whereas the modification of physical properties of associated *Physical Entity* is performed through the use of *Actuators*. *Physical Entity* can be represented in the digital world by a *Digital Entity* which is in turn a *Digital Proxy*. *Digital Proxy* has one and only one *ID* that identifies the represented object. The association between the *Digital Proxy* and the *Physical Entity* must be established automatically. A *Smart Object* has the extension of a *Physical Entity* with its associated *Digital Proxy* which then talks to the user by providing or requesting resources. The external services are invoked by the user which can be human or third-party software.

Overall, IoT reference architectures provide a useful starting point for designing and implementing IoT systems. They offer a standardized approach to IoT system design and help to ensure interoperability and compatibility between different IoT systems. However, it has been shown that no single reference model was able to tackle all the aspects that involves in engineering IoT systems [75]. For instance, one of the most used reference architectures in [49] doesn't cover the run-time dynamicity

<footnote n="1">¹https://www.iso.org/standard/63711.html</footnote>
of IoT systems as well as context-awareness concepts. They also lack other aspects such as quantified system reliability, security, and privacy protection. According to different challenges in IoT environments and the existence of some weaknesses in IoT architectures, we believe that more research on IoT reference architectures need to be done.

### 2.2.3 Model-Based Safety Analysis

Failures that could risk human life, and injuries to the environment, or properties are considered safety hazards. Safety analysis should run concurrently with system design, including interactions between the two, and it should be kept up to date throughout the system life cycle. Risks of this sort are usually managed with the methods and tools of safety engineering. Conducted initially by safety engineers, the safety analysis is one of the dependability analysis techniques that aim to study system response in case of an unwanted failure behavior that can hinder system safety compliance. In safety-critical systems, it is often required to maintain a high level of safety to prevent potentially catastrophic consequences [44]. FTA, as well as FMEA, are already mandatory analysis approaches for performing safety analysis in domains like automotive and aerospace [78, 79], and more domains are going to be subjected to follow that suit [32].

Failure logic approaches map the reliability concepts (produced by reliability engineers) to reflect the underlying fault-to-failure and failure-to-fault propagation within the systems [80]. CHESS Failure Logic Analysis (CHESS-FLA) [44] introduces the possibility of unifying and automatizing existing traditional dependability analysis approaches through the use of the Failure Propagation Transformation Calculus (FPTC) rules [81]. CHESS-FLA enables users (system architects and safety engineers) to decorate component-based architectural models (specified in the CHESS modeling language - CHESSML) with dependability information, perform Failure Logic Analysis (FLA), and have the results back-propagated onto the original model [82]. In practice, a component can act as a source of failure (for example, by causing a failure in output due to the activation of internal faults) or as a sink (a component can avoid failure propagation by detecting and correcting the failure in input). Furthermore, failures in a component can be propagated (i.e., a failure can be passed from input to output) or transformed (by changing the nature of the failure from one type to another from input to output) [3].

The Fault-Tree Analysis (FTA) [41] technique is currently one of the most widely used methodologies when performing safety analysis. The purpose of an FTA is to graphically represent and trace down influence from a system-level hazard to individual failures of distinct system components and sub-components. The graphical representation of the scenarios can aid in explaining these causal chains that can lead to a hazard, followed by an analysis to determine the combination of events that trigger such hazards or compute the chance that such a hazard could occur. During the analysis, the safety engineer starts from the actual hazard, referred to as a "top event," and traces down different event combinations that might contribute to such hazard until the actual cause is reached. This is referred to as a "basic event" in this case. Figure 2.3, shows a typical FT example.

The FT event combination logic relies on logic gates to determine the output of a situation. For example, if two or more events are needed to represent a certain component failure, an "AND" gate is used; while, if one event is enough to trigger the failure, an "OR" gate is used. Other known logic gates can also be used based on the desired system failure behavior.

Failure Mode and Effects Analysis (FMEA) [83] is among the earliest known failure analysis techniques, and it is frequently used as the first stage in a system reliability analysis. Reliability engineers originally developed it to investigate problems that could come from military system failures. It is used to examine as many components, assemblies, and subsystems as feasible to determine failure modes and their causes and effects. The failure modes of each component, as well as their consequences on the rest of the system, are recorded in a separate FMEA worksheet [84]. Unlike the FTA, which follows a top-down deductive approach from the top event to specify its possible causes, the FMEA follows an inductive reasoning approach. Using a forward logic approach, FMEA separates a system into small components, analyses failures that each component may cause, and assesses the effects of
<figure><img src="image_6.png" /><figcaption>**Figure 2.3:** An FT example</figcaption></figure>

those failures on the system. As a result, the FMEA performer must properly understand the system safety context and software requirements or design specifics to assure the comprehensiveness of the system decomposition and the validity of each component’s usability.

## 2.3 Low-Code Engineering

The significant advancements in computing power, data storage, and processing are revolutionizing the development and research of complex systems in several domains, including that of the IoT [85]. IoT systems enable the integration of intelligent features into daily human activities through the automation of services. In particular, such systems allow the automation of low-level services that used to be error-prone if done by humans. Moreover, they increase efficacy in current engineering solutions and connect a range of many devices that render our environment smart. Recent reports predict that more than 100 billion devices will be connected by 2025 and 11 trillion dollars of global market capital will be reached [86]. However, to unleash the full potential of these systems, it is necessary that also citizen developers can take part in the development of custom IoT applications [12].

The development and consumption of IoT systems are becoming way more complex, and involving end-users is more challenging due to the heterogeneity of the hardware and required expertise [12]. This complexity originates from various sources. IoT applications are complex systems that use heterogeneous devices and data sources. Besides, IoT systems require enormous efforts and investments both in their implementation and maintenance. Moreover, the systems are implemented using code-centric approaches that make it challenging to foster the inclusion of IoT domain experts and other stakeholders with less IoT programming skills [12].

As a result of the competitive pressures imposed by digitalization [6], more and more industries
across all domains are being pushed to establish software development teams to continue developing and maintaining new products based on customer needs. This allows the organization to keep up to date with customer digital demands while also remaining relevant to market needs. Managing and paying such teams comes at a high budget, which can appear to be a burden to businesses, especially when such teams fail to deliver on time. Reduced time to market as well as the top quality of the developed software are always the main concerns when developing software. Most of the time, software teams reuse existing code to increase the speed at which new features are developed. Although this can always be a better walk around, they are most likely to suffer from code inconsistency, high maintenance as well as incompatibility in case of a very complex software problem. On another hand, businesses are looking for new ways of developing software that can decrease the time to market as well as cut the development cost while maintaining the quality of developed software.

### 2.3.1 Low-Code Development Platforms

With the increasing interest in advancing the software development process, more and more engineering industries are looking for a way to take advantage of what advanced technologies such as cloud computing and machine learning have to offer. Low-Code Development Platforms (LCDPs) aim at easing the development of fully functional applications by facilitating people with less or no experience in software engineering (eg, business managers) to develop business applications using simple graphical or textual user interface [8]. These platforms drastically reduce the time it takes to build an application, reducing it all from months to days or even hours. Technically, most of such applications are developed through declarative and high-level abstractions languages and take advantage of cloud infrastructures, and automatic code generation to develop entirely functioning applications [87]. LCDPs have shown their strengths in the development of software systems in four main market segments such as database applications, mobile applications, process applications, and request-handling applications. According to Tisi et al. [11], IoT is expected to be the next market segment.

The main goal of MDE is to increase productivity and reduce time to market by enabling the development of systems using models defined with concepts that are much less tied to the underlying implementation technology, and much closer to the problem domain [35]. Same as MDE, low-code software development processes also aim to improve software development processes by raising abstraction and hiding implementation-level details. Both approaches employ model-driven development (MDD) in their development stack; the important distinction seems to be how they enforce factors such as cloud-based deployment, target users, setup, and so on [58]. In addition to that, not all MDE approaches seek to reduce the amount of code required to develop software solutions, and not all low-code approaches are model-driven [58]. Although this is true, their difference in practice is still widely debated on how much work done in MDE is directly transferable to LCDPs [88].

Nowadays, we witness a growing number of successful generic LCDPs on the market (e.g., Google App Maker and Microsoft Power Platform). Despite their success, LCDPs' development capabilities are still limited regarding how complex, intelligent, and sophisticated they may be [11]. Such application often suffers from several issues as follows. On one hand, most of the LCDPs suffer from vendor lock-in problems in which the developed application only being able to be deployed on their own dedicated infrastructure [58]. In addition to that, their scalability in terms of how big and sophisticated such developed applications can be is still questionable. On another hand, domains supported by such platforms are still limited too. For instance, so far LCDPs have been especially successful in the development of domain-specific applications in four market segments such as database applications, mobile applications, process applications, and request-handling applications [11].

Despite their success, LCDPs' development capabilities are still limited regarding how complex, intelligent, and sophisticated they may be [11]. In the IoT domain, only a few LCDPs are available, and they provide limited functionalities given the inherent complexity and heterogeneity of typical IoT systems. Among others, IoT-specific platforms such as Node-RED [89] and Atmosphere IoT [90] have demonstrated a significant push toward the development of fully-fledged multi-layer IoT platforms. However, their capacity to generate code and interact with low-level IoT devices is still
limited. Unlike LCDPs, MDE presents a more significant number of platforms that can still generate low-level platform-specific code. Still, they often suffer from integration and interoperability issues because most of them are deployed and operated locally [8]. Full list of existing LCDPs is presented in Section 3.1

### 2.3.2 Low-Code Engineering Platforms

With the rapidly rising machine intelligence and how traditional code-centric software development stack has achieved in domains such as IoT, data science, and cloud computing, Low-Code Engineering Platforms (LCEPs) focus on extending the development knowledge present LCDP by injecting it with the theoretical and technical framework defined by recent research in MDE, Cloud Computing, and Machine Learning techniques [11]. These platforms' target span more advanced and complex domains such as IoT, industrial automation, data science, recommender systems, and so on. They aim at overcoming the current limitations present in LCDPs such as those related to scalability (i.e., supporting the development of large-scale applications, and using artifacts coming from a large number of users), open (i.e., based on inter-operable and exchangeable programming models and standards), and heterogeneous (i.e., able to integrate with models coming from different engineering disciplines) [8].

A simple example of differentiating LCEP and LCDPs can be the difference between *Software engineering* and *Software development*. Software engineering is a systematic approach to designing, developing, and maintaining software. It emphasizes on offering software systems of high quality, dependability, and maintainability that satisfy stakeholders. The priority of software engineering is on the use of well-established engineering methods and principles, such as requirement analysis, design, testing, and maintenance [91]. It also takes into account the software's lifecycle, including the phases of development, deployment, and maintenance. Software development, on the other hand, is the process of developing software products through programming, testing, and documentation. It is a component of software engineering that is concerned with developing software solutions that comply with particular business needs. Software development often takes a more realistic and practical approach than software engineering, when implementing software solutions into reality to address particular business or user demands [91]. Even though the ideal LCE target appears to be in its early stages, the current and continuous development under this umbrella shows promising signs of success in the near future.

Although we clearly agree with Di Ruscio et al [58] on the fact that "not all MDE approaches seek to reduce the amount of code required to develop software solutions, and not all low-code approaches are model-driven"; we believe that "*LCEPs should one way or another enforce model-driven principles*". This is due to the fact that LCEPs combine the MDE, cloud computing and machine learning technologies to tackle most challenging tasks in complex domains. For instance, looking at the system engineering domain, having legacy model-driven services exposed through APIs could potentially boost their usability. The fact that most of the LCDPs are cloud-based and do not require installation significantly lowers the entry barrier for new users [58]. Having such LCDPs consume live services could potentially contribute to their extensibility as well as targeting more complex domains. In the following section, we will go through some of the popular and ongoing potential LCEPs that target complex domains such as Data mining and recommender systems.

#### LCEP in Data science

* RapidMiner [92] is a data science platform that provides an integrated environment for data preparation, machine learning, deep learning, predictive modeling, and other data analytics tasks. It offers a drag-and-drop interface that allows users to easily build, test, and deploy predictive models without the need for programming. RapidMiner supports a wide range of data sources and formats, including databases, spreadsheets, text files, and cloud-based data storage services. It also offers advanced data preparation and cleansing tools to ensure that
data is accurate and ready for analysis. One of the key features of RapidMiner is its machine
learning capabilities, which allow users to build predictive models using a variety of algorithms,
such as decision trees, random forests, and neural networks [93]. The platform also provides
tools for model validation and optimization, allowing users to fine-tune their models for max-
imum accuracy. RapidMiner offers both a free, open-source version (RapidMiner Studio) as
well as a commercial version with additional features (RapidMiner Server). It is used by busi-
nesses and organizations in a wide range of industries, including finance, healthcare, retail, and
manufacturing.

* The Konstanz Information Miner (KNIME) [94] is a modular environment, which enables easy visual assembly and interactive execution of a data pipeline. This platform is designed as a teaching, research and collaboration platform, which enables data manipulation or visualization methods in the form of new modules or nodes. KNIME also provides a large selection of pre-built components and tools that can be easily integrated into workflows, as well as the ability to extend its functionality. For instance, KINME integrates with popular data science platforms as R and Python, making it easier for data scientists to incorporate their code into custom applications built on the platform. Finally, the platform is used in a wide range of industries, such as life sciences, finance, and marketing, for tasks such as predictive modeling, text mining, and customer segmentation.

* Kourouklidis et al. [95] developed a low-code technique for identifying and responding to events that can affect the performance of a machine learning model based on MDE concepts. The proposed solution is a cloud-based engine that enables machine learning specialists to design the execution of drift detecting algorithms on a computing cluster and receive email notifications of the results without the need for considerable software engineering knowledge. Their solution is based on DSL, which offers a standardized communication layer between domain experts who declaratively describe the behavior of the ML monitoring system and software engineers who are in charge of developing a concrete implementation that complies to the defined behavior.

LCEP in recommender systems

* Droid [96] is a open source framework for automating the configuration, evaluation, and synthesis of recommender systems for modeling languages. Droid tooling automates all steps of recommender system development, including data preprocessing, system configuration for the modeling language, evaluation and selection of the optimum recommendation algorithm, and deployment of the recommender system into a modeling tool. The Droid tool has been validated on multiple usecases, including recommending UML model attributes in domains such as Literature and Education [97]. Many recommender systems were trained in this approach using a number of collaborative, content-based, and hybrid recommendation methods such as item popularity, item-based collaborative filtering, user-based collaborative filtering, and so on. The recommendation systems are mostly based on the static features of elements and their occurrence in the dataset. When the requested recommendations become more complicated, the tool's performance can worsen. So far, the data's morphological natural language processing feature is regarded as a potential solution for improving recommendation systems. Droid can be accessed at https://droid-dsl.github.io/

* LEV4REC [98] is a low-code environment to foster a recommender systems’s design, configuration, and deployment from scratch using such a cutting-edge paradigm. LEV4REC is flexible and extensible as it relies on three core techniques, i.e., feature model, metamodel, and Acceleo templates. Starting from a feature model, RS designers can specify the system’s features and then progressively enrich a configuration model automatically generated out of the selected features. With LEV4REC, developers have the flexibility to explore a wide range of algorithms and methodologies for recommendation. They can experiment with different approaches, such as
collaborative filtering, content-based filtering, or hybrid methods, to identify the most effective solution for their specific use case. By fine-tuning the experimental settings, such as adjusting hyperparameters or incorporating additional features, developers can optimize the recommender system's performance and accuracy. Moreover, LEV4REC allows for the selection and evaluation of appropriate metrics to assess the recommender system's performance. Developers can analyze metrics like precision, recall, F1-score, or customized domain-specific metrics to gain insights into the system's effectiveness. This iterative process of experimentation and evaluation enables developers to continuously refine the recommender system until desired performance levels are achieved.

## 2.4 CHESS environment

The ever-increasing complexity and dependability issues of systems in various domains, such as transportation, space, energy, health, and industrial production, require effective design and development methods. The complexity and heterogeneity of components can be addressed with modeling approaches that span different technical disciplines and prove effective in the end-to-end engineering of the products. This implies taking into account various requirements such as quality, performance, cost, safety, security, and reliability. Model-based design technologies enable the user to perform beforehand different assurance-related activities such as physical architecture exploration, system behavioral analysis, early verification, and validation.

The CHESS toolset [99] offers cross-domain modeling and analysis of high-integrity systems providing an integrated framework that helps the modeler (user) to automate different development phases: from the requirements definition to the architectural modeling of the system's software and hardware, up to its deployment to a hardware platform [99]. CHESS follows a component-based approach where the user decouples different functional parts of the system as components that can be modeled, analyzed, verified, stored, reused individually, and integrated to meet the system's common goals. CHESS supports, among others, schedulability and dependability analysis across the entire project life cycle. The results of the analysis are back-propagated to the model itself so that the modeler can review and fine-tune the model to satisfy real-time and dependability requirements.

CHESS tool is a full-fledged open-source project, hosted by The Eclipse Foundation (https://www.eclipse.org/chess/). The code has been developed by various contributors following an open-source approach with public projects for issue tracking, code repository branches, and continuous integration. CHESS was developed, used, and extended in many research projects, by both industrial and academic partners. To list a few, CHESS was involved in international projects such as the homonymous CHESS project<fnref n="2" />, CONCERTO<fnref n="3" />, and SESAMO<fnref n="4" />, under the ARTEMIS Joint Undertaking initiative, AMASS<fnref n="5" />, AQUAS<fnref n="6" />, and MegaM@Rt<fnref n="7" />, under the ECSEL Joint Undertaking initiative. CHESS has been applied in different domains such as Avionics [100], Automotive [101], Space [102], Telecommunication [103], and Petroleum [104] [105].

Because CHESS is the foundation for our CHESSIoT extension, we go over the basics of CHESS in this section. We discuss its supporting engineering methodologies, such as multi-view modeling, component-based, and correct-by-construction approaches. Through the contract-based design analysis and model checking, we provide a quick introduction to the support verification and validation processes. In addition, we summarizes the existing analysis support, such as dependability, timing, safety, and quantitative reliability analyses. Lastly, we look at a number of successful stories and the impact CHESS has had on system engineering both in industry and academic settings.

<footnote n="2">²http://www.chess-project.org/</footnote>

<footnote n="3">³http://www.concerto-project.org/</footnote>

<footnote n="4">⁴http://sesamo-project.eu/</footnote>

<footnote n="5">⁵https://www.amass-ecsel.eu/</footnote>

<footnote n="6">⁶https://aquas-project.eu/</footnote>

<footnote n="7">⁷https://megamart2-ecsel.eu/</footnote>
### 2.4.1 CHESS in nutshell

The CHESS modeling tool was released under the Eclipse PolarSys project<fnref n="8" /> and recently it was moved from the incubation status to the first major release. The CHESSML is an integrated modeling language profiled from OMG standard languages: UML, SysML, and MARTE under the Papyrus modeling environment <fnref n="9" />. Not all the features from all three languages were profiled to CHESS but only specific subsets that suit CHESS’s perspective. In particular, sub-profiles supporting contract-based and dependability concerns have been defined, while MARTE has been adopted (with minor deviations) for what concern the timing perspective. There are different tools, plugins, and languages that were integrated into CHESS to support model validation, model checking, real-time, and dependability analysis. In this section, we are going to briefly describe the core aspects of CHESS methodology.

#### CHESS editor tooling

With reference to Figure 2.4, CHESS editor is an extension of the Papyrus UML editor and is activated when a CHESS model is created or opened. It provides additional functionality and constraints specific to the CHESS modeling approach. A CHESS model is essentially a UML model with the CHESS profile applied to it. To create a CHESS model, you can use a dedicated wizard that guides you through the process of applying the CHESS profile to your UML model.

When working with the CHESS editor, you can use the *CHESS design views*. Each design view imposes specific constraints on the UML diagrams and entities that can be created, viewed, or edited within that view. These constraints help enforce the rules and guidelines of the CHESS modeling methodology.

<figure><img src="image_7.png" /><figcaption>**Figure 2.4: CHESS editor overview**</figcaption></figure>

The CHESS editor allows you to *switch between different views* based on your modeling needs. As you switch between views, the editor keeps track of the current view's status. It ensures that you do not violate the constraints defined for the specific diagram-view pair you are working with. This

<footnote n="8">⁸https://projects.eclipse.org/projects/polarsys.chess</footnote>

<footnote n="9">⁹https://www.eclipse.org/papyrus/</footnote>
prevents you from unintentionally creating or modifying UML elements that are not allowed in the
current view.

In order to support the constraints of the current diagram view, the native *Papyrus palettes* have been customized. The customized palettes only display the entities that are allowed to be created within the current diagram view. This customization helps streamline the modeling process by presenting you with the appropriate set of options for the specific view you are working in.

Overall, the CHESS editor enhances the Papyrus UML editor by providing specialized features, design views, and constraints that align with the CHESS modeling approach. It facilitates adherence to the methodology and helps maintain consistency and correctness throughout the modeling activity.

Component-based methodology

Component-based design is an approach where software systems are decomposed into modular,
reusable, and independent components. These components encapsulate specific functionality and can
be composed and connected to build larger systems. The goal is to promote modularity, reusability,
and maintainability of the software. The CHESSML language supports a component-based develop-
ment methodology enabling property-preserving component assembly for real-time and dependable
embedded systems. Emphasis is given to separation of concerns between the functional and the non-
functional dimensions, such as safety, security, reliability, performance, and robustness [106].

The tool provides mechanisms to compose components and establish connections between them. You can define relationships such as aggregation, composition, and association to represent how components interact and collaborate. At the design level, components encompass functional concerns only (i.e., they are devoid of any constructs pertaining to tasking and specific computational models). Components interact with each other through well-defined interfaces. The CHESS tool enables you to define interfaces and specify the operations and properties that components expose to other components. The specification of non-functional attributes is then used for the automated generation of the container, enforcing the realization of the non-functional attributes declared for the component to be wrapped.

The CHESS methodology follows the “Correctness by Construction” practice which enforces (1) the use of formal and precise tools and notations for the development and the verification of all product items; (2) say things only once to avoid contradictions and repetitions; (3) the design of software components that are easy to verify, by e.g., using safer language subsets, and to implement, by using appropriate coding styles and design patterns [107]. The CHESS tool supports the deployment of components onto target platforms or execution environments. You can model the deployment architecture and specify the mapping of components to hardware or software resources. Finally, CHESS tool provides analysis capabilities to validate and verify component-based designs. You can perform checks and simulations to ensure that the components and their interactions adhere to design constraints and requirements.

Multi-view modeling approach

The CHESS tool provides a set of design views to uphold the "separation of concern", the "correctness by construction" and the other methodological principles introduced before. Six main views (requirement, component, system, deployment, analysis, and instance views) are defined to support The CHESS modeling approach. Throughout the development process, each view has its own underlined constraints that enforce its specific privileges on model entities and properties that can be manipulated. Depending on the current stage of the design process, CHESS sub-views are adopted to enhance certain design properties or stages of the process. Figure 2.5 shows the high-level architecture of CHESS views and their inter-relations.

* Requirement view: Originally adopted from the SysML requirement diagram, the requirement view is used to define system requirements and track their verification. In CHESS, requirements
<figure><img src="image_8.png" /><figcaption>Figure 2.5: CHESS views architecture [2]</figcaption></figure>

are part of the model and play a central role in the system development life cycle. The system elements are associated with the technical requirements they satisfy, which are, in turn, traced to higher-level requirements, up to system-level requirements [106]. This association technique enhances traceability while evaluating the correctness and consistency of the modeled system. In this way, the change's impact can be better evaluated and faithful model verification evidence can be provided according to the requirements. An example of a requirement created on a WheelBrakingSystem (WBS) example is shown in Figure 2.6

<figure><img src="image_9.png" /><figcaption>Figure 2.6: Wheel Braking System requirement example</figcaption></figure>

* **System view:** It provides a suitable frame for system-level design activities. In the System view, the system entities are initially designed into blocks and then hierarchically decomposed (see CHESS editor section from Figure 2.4). CHESSML inherits from SysML the specification of the block hierarchies and their internal decomposition, i.e. a block definition diagram can describe
a system structure by means of a set of blocks and each block may have its own dedicated internal block diagram describing its sub-blocks decomposition and interfaces. An example of the internal block decomposition architecture of the WBS system example is shown in Figure 2.7. Furthermore, in addition to system-level design, in system view it possible to perform contract-based design as well as several functional and dependability analyses from system models.

<figure><img src="image_10.png" /><figcaption>**Figure 2.7:** Wheel Braking System internal block diagram</figcaption></figure>

*   **Component view:** This view is used for software design work and logic of the intended model. The component view is composed of two sub-views, *Functional View* which is enabled by default, and the *Extra-Functional View* which is enabled manually in the tool. The *Functional View* is used to model system functional specifications using diagrams such as class, composite structure, state machine, activity, and sequence diagrams. Under the component view, the system's software construct can be designed through the modeling of component interfaces, component types as well as their components implementation. Figure 2.8 shows an example modeling of component implementations for a producer-consumer components implementation example.

<figure><img src="image_11.png" /><figcaption>**Figure 2.8:** Producer-consumer: components implementation modeling</figcaption></figure>

In addition to that, it is possible to model the system functional behavior using state machines which can be used for code generation purposes. On the other hand, when switched to it (see Figure 2.9), the *Extra-Functional View* can be used to compose the system's extra-functional specifications such as the real-time and dependability attributes. Recall that all views have a
dedicated palette depending on their requirements, for instance, the extra-functional view has no access to the activity diagram and has a palette with entries exclusively related to extra-functional concerns (See Figure 2.9).

<figure><img src="image_12.png" /><figcaption>Figure 2.9: Producer-consumer: extra-functional properties modeling</figcaption></figure>

* **Deployment view:** This view is used to model the hardware structure of the system and permits the allocation of their corresponding software component instances modeled from the before (from component-view). Through the use of class and composite structure diagrams, the user can model the type of deployment on either a single or multiple-core processor. In this view, each hardware resource is allocated to a specific memory partition and can only access and change its own memory space. Regarding the software-to-hardware resource allocation, all software components are allocated to cores. Figure 2.10 shows producer-consumer: software-to-hardware allocation modeling example in which the producer and consumer software component instances are allocated to cores on *CPU_inst* hardware instances.

<figure><img src="image_13.png" /><figcaption>Figure 2.10: Producer-consumer: software-to-hardware allocation</figcaption></figure>

* **Analysis view:** This is used to capture all the activities and diagrams related to analysis in CHESS. It consists of the two sub-views as *Dependability Analysis view* and *Real-Time Analysis view*.
ysis view. The analyses performed in CHESS are real-time analysis, quantitative dependability analysis, failure propagation analysis, and so on. We will discuss further analysis in Section 2.4.2.

* **Instance view:** CHESS offers a dedicated view to visualize and model the PSM. This model comprises a combination of hardware and software instances derived from the deployment and component views, respectively. Composite structure diagrams serve as the foundation for this representation, allowing for a detailed depiction of the system's structure and its dynamic behavior during runtime. One of the key strengths of CHESS is its ability to facilitate runtime analysis between model instances. By representing the PSM as a combination of hardware and software instances, it becomes easier to understand how the system components interact and how their behavior is affected by the underlying hardware. This comprehensive view enables analysts and developers to identify potential performance issues, resource constraints, and architectural issues that may impact the system's runtime behavior.

The generation of model instances is automatic by invoking the "BuildInstance" command, the tool automatically creates the necessary hardware and software instances based on the deployment and component views. This automation saves time and effort for system designers and allows them to focus on the analysis and validation of the runtime behavior rather than manual instance creation. In the generated instance model, each component's properties and connectors are mapped onto dedicated *InstanceSpecifications*. This mapping provides a detailed representation of the characteristics and connections of the system's components within the PSM. By associating properties and connectors with specific instances, CHESS enables a deeper understanding of the runtime behavior and facilitates analysis of component interactions. More on this is presented our published work in [42].

### 2.4.2 Supported Model-based Analysis

In this section, we present different major model-based system analyses supported by CHESS.

#### Model-based system analysis and verification

CHESS provides the capability to perform several kinds of analysis depending on the specific requirements (functional, timing, dependability).

**Timing Analysis** is built on top of the MAST<fnref n="10" /> analysis tool. It is invoked to perform analyses such as schedulability and end-to-end response time analysis. Schedulability analysis is performed by taking input from the annotated PSM model and the computed partition schedule on each available processing unit. Then, the response-time analysis calculates the worst-case response time of each task [100] assessing the schedulable tasks complying with the given timing constraints. Sample schedulability analysis results for the producer-consumer example is shown in Figure 2.11. The end-to-end response time analysis, on another hand, is done by utilizing the component sequence diagram. Applying MARTE timing stereotypes, the tool evaluates the hardware component's responsiveness. This analysis facilitates “early end-to-end response time verification”, giving a sense of any possible refinement of the model before deployment [106] (See Figure 2.12).

**Dependability analysis** include Failure Logic Analysis and State-Based Quantitative Dependability Analysis. CHESSML dependability profile which normally supports different techniques for safety and dependability analysis has been extended to model fault injection and threats. Other new features include contract validations, parameter-based architectures, and document generation. Failure Logic Analysis [44] builds on top of Failure Propagation and Transformation Calculus [81] and enables deductive as well as inductive hazards analysis towards a semi-automatic generation of artifacts, necessary for arguing about HARA (Hazards Analysis and Risk Assessment). Supported by the DEEM tool [108], State-Based Quantitative Dependability Analysis [109] supports safety engineers in the

<footnote n="10">¹⁰https://mast.unican.es/</footnote>
<figure><img src="image_14.png" /><figcaption>Figure 2.11: Producer-consumer: Schedulability analysis results</figcaption></figure>

<figure><img src="image_15.png" /><figcaption>Figure 2.12: Producer-consumer: End-2-end response time analysis results</figcaption></figure>

management of Reliability, Availability, Maintainability, and Safety (RAMS) properties, and in the assessment of hazard rate threshold associated with safety integrity levels. Properties modeled using the CHESSML dependability profile are analyzed to obtain the probability of occurrence of specific failure modes and other quantitative metrics involving reliability, availability, and safety. More on this is presented in Chapter 7.

**Functional Verification** by means of model checking is supported by the integrated *nuXmv* model checker [110]. System and component properties, derived from requirements, can be formalized into linear temporal logic properties, then they can be verified on top of the system's or component's behavioral models developed using state machines.

**Model validation** enforces several types of model constraints, depending on the specific analysis to be exploited, and the related application domain and criticality. For example, we can mention: (1) Model core constraints validation is performed to enforce the CHESS model constraints including specific preconditions as required by the schedulability analysis (2) Validate model for criticality specification and (3) Validate model for Automotive 26262 compliance (only specific for automotive domain) checks the system correctness of Automotive Safety Integrity Level(ASIL) inheritance and decomposition according to the ISO 26262 standard.
Contract-based design analysis and model checking

CHESS supports the specification of component contracts specified in the OCRA contract lan-
guage. Requirements are formalized into Formal Properties, which contain OCRA assertions, i.e.,
textual specifications of temporal logic formulas (see Figure 2.14 for a contract while Figure 2.13
shows formal property specifications example).

<figure><img src="image_16.png" /><figcaption>**Figure 2.13:** Example of a FormalProperty formalizing a requirement</figcaption></figure>

<figure><img src="image_17.png" /><figcaption>Figure 2.14: Example of a component contract</figcaption></figure>

In the contract-based paradigm, these properties are restricted to the related component interface.
A contract is a pair of properties representing an assumption and a guarantee of the component. In
addition, the CHESS tool supports the contract refinement analysis for composite components. The
contract of a composite component is defined by the assumption of the composite component itself
and the guarantee ensured by the contracts of its sub-components, considering their interconnection
as described by the architecture and that the assumption of each sub-component is ensured by the
contracts of the other sibling sub-components.

CHESS supports the improved contract-based analysis aspects by integrating CHESS with verifi-
cation and validation (V&V) tools such as OCRA [111], nuXmv [68], and xSAP [112]. In this regard,
the contract-based analysis includes:

(1) *Model checking*, i.e. the behavioral models, that describe how the internal state of a component and the output ports are updated, can be verified against some formal properties in different temporal logics. The formal properties can represent some requirements (e.g., functional or safety-related requirements) or some validation queries such as the reachability of states.

(2) *Contract-based compositional verification of state machines* is performed on composite components. The local state machine of each sub-component is verified separately against its local contract. The correctness of the composite component is implicitly derived from the correctness of the contract refinement and the successful verification of local state machines.

(3) *Contract-based safety analysis*, i.e. identify the component failures as the failure of its im-
plementation in satisfying the contract. When the component is composite, its failures can be caused
by a failure of one or more sub-components and/or a failure of the environment in satisfying the as-
umption. As result, the analysis produces a fault tree in which each intermediate event represents
the failure of a component or its environment, linked to a Boolean combination of other nodes. The
top-level event is the failure of the system component. The basic events are the failures of the leaf
sub-components, in addition to the failure of the environment (see [113] for more details).
<figure><img src="image_18.png" /><figcaption>**Figure 2.15:** State machine modeling faulty behavior</figcaption></figure>

## Fault Injection and Safety Analysis

CHESS supports safety analysis based on fault injection thanks to the integration of xSAP [114]. The behavioral models of components are extended with faults and the tool automatically generates Fault Trees, showing the combinations of events leading to a failure or an undesired state, and Fault Mode Effect Analysis (FMEA) tables, listing all potential failure modes and their effects on the system [115].

More specifically, once the system model is defined in CHESS, through components definition and their nominal behavioral model, the faulty behavior is expressed through a specific state machine called "Error Model". The Error Model extends the nominal state machine with information about the effect upon a property of the component, and consequently on its nominal behavior. Figure 2.15 represents an example of an error model that, in case of an internal fault, moves the related component in an error state where the property "energy" is stuck at 0 value. The optional probability assigned to that transition is $5 \cdot 10^{-2}$.

Once the error model is defined, the Fault Tree Analysis (FTA) or FMEA can be done by invoking xSAP through the CHESS environment. The xSAP approach is based on the library-based fault injection (i.e., an extension of a behavioral model with the definition of faults taken from a library of faults) and the use of model-based routines to generate safety artifacts. The result of the FTA is the fault tree that is automatically shown in a dedicated panel in the front end. If fault probabilities have been specified during the configuration of the error model, the fault tree will report their combination. The fault tree shows all minimal cut sets, identifying the basic fault conditions which can lead to top-level failure. This is complementary to other existing analysis techniques supported in CHESS such as Failure Logic Analysis and State-Based Quantitative Dependability Analysis, which do not consider the nominal behaviors and fault injection, but explicitly model the faulty behavior and fault propagation.

## Quantitative Reliability Analysis

The CHESS profile for dependability is used to enrich functional models of the system with information regarding the behavior with respect to faults and failures, thus allowing properties like reliability, availability, and safety to be documented and analyzed.

CHESS supports the modeling of security concerns which helps in threat identification at the early stages of the development and facilitates the exploiting of the Mobius capabilities for analysis of reliability. Möbius<fnref n="11" /> is a software tool for modeling the behavior of complex systems, by allowing the study of the reliability, availability, security, and performance for large-scale discrete-event systems [116]. Many reliability analysis results can be obtained with probabilistic models built with Mobius

<footnote n="11">¹¹https://www.mobius.illinois.edu/</footnote>
using the stochastic activity networks (SAN) formalism, solved via Monte-Carlo simulation<fnref n="12" />. Specific extensions of the dependability profile are related to the modeling of Cyber-Attacks aspects and model transformations from CHESS to the Mobius tool to run the analysis of SANs.

As result, the implemented methodology allows the modeling of a system security threat and data corruption which may result in service misfortune. An example of a system security threat can be a cyber-security attack, i.e. unauthorized access to the system, halting services. Figure 2.16 depicts the

<figure><img src="image_19.png" /><figcaption>**Figure 2.16: Process of Security breach**</figcaption></figure>

process of a security breach that leads to the violation of security-related properties. A *threat* event, initiated by a threat source agent, able to exploit a *vulnerability* of an asset (e.g. a component/system) may result in a loss to the confidentiality, integrity, and/or availability of the asset. Vulnerabilities could be represented as a pre-defined enumeration collected through different sources (e.g. personal competence, standards, results of previous threat analysis, etc.). Finally, the consequences could be modeled using pre-defined effects, which refers to the loss of Confidentiality, Integrity, and Availability (CIA).

<figure><img src="image_20.png" /><figcaption>**Figure 2.17: Erroneous state transition due to security threat event and vulnerability**</figcaption></figure>

An «*ErrorModel*»-tagged state machine is used when modeling the security breach. The failure, internal fault, and effect are extended to include security threats, vulnerability, and consequences respectively. Figure 2.17 illustrates an example of an error model, where a cyber-security attack initiates a data corruption threat. The vulnerability was modeled by exploiting the value check function which is set to false. In this case, the system transits to an erroneous state leading to component failure. Note that a component could have multiple instances of «*ErrorModel*»-tagged state machines, attached to it. Each instance would provide the elaboration of input/output failure behavior addressing a specific concern.

The generation of the Mobius SAN model process is done by performing an automatic model-to-model transformation from a model instance to the SAN model recognized by Mobius for reliability analysis. The reliability analysis is additional to the existing State Based Quantitative Dependability Analysis. It exploits Mobius's powerful and well-supported analysis capabilities as an engine for

<footnote n="12">¹²https://www.investopedia.com/terms/m/montecarlosimulation.asp</footnote>
safety and security co-engineering, according to the scenario addressed in [117]. Editing Mobius models can be nontrivial, CHESS modeling language fully supports the modeling of system architectures taking into consideration safety and security co-engineering for reliability analysis with MOBIUS.

The generation of the Mobius SAN model process is done by performing an automatic model-to-model transformation from a CHESS model instance. The transformation engine was implemented using eclipse-based tools such as **QVTo** [118] and **Acceleo** [119]. The traceability information about the CHESS entities and the generated Ecore SAN model are saved in the SAN folder as **.qvtoTrace** file. The file comes with a dedicated editor to be used when checking the mappings. This extension has been developed in the context of the AQUAS project, as a result of a collaborative effort among Intecs and the City University of London. This approach was applied and evaluated across different use cases namely the Automated Teller Machine (ATM) and Industrial Drive. This approach provides a smooth integration, guarantees consistency among SysML and SAN models, and largely reduces the effort required to construct an appropriate SAN analysis model.

### Support for parameterized architecture and trade-off analysis

In a parameterized architecture the number of components, the number of ports, the connections, and the static attributes of components depend on a set of parameters. Parameters are defined along the architectural hierarchy and, thus, the number of parameters themselves can depend on other parameters. CHESS supports the modeling of the parameterized architecture as well as its instantiation. In particular, the user can set the values of the parameters, defining the configuration of the architecture, and the tool automatically generates a concrete architecture corresponding to that configuration. Figure 2.18 shows an example of parameterized architecture.

<figure><img src="image_21.png" /><figcaption>**Figure 2.18:** Example of parameterized architecture</figcaption></figure>

The parameterized architecture is also exploited for trade-off analysis, by performing various analyses on the different instantiations and comparing the results. This makes it easy to visually get an idea of how the intended model instances perform with respect to the selected configurations. Figure 2.19 shows the sample result of a trade-off analysis made on two instances by looking at different concerns specified by the assumption/guarantee formal properties of each contract.

<figure><img src="image_22.png" /><figcaption>**Figure 2.19:** Trade-off Analysis results sample</figcaption></figure>
Automatic generation of diagrams and documentation

The traditional way of editing a model is by adding an element to a diagram but changes made
in the model are not reflected in the diagrams. CHESS offers the possibility of generating a diagram
from the model which reflects the data in the model on the fly. The supported diagrams are Block
Definition Diagram (BDD) and Internal Block Diagram (IBD). The generated diagram elements will
be automatically aligned but the user can rearrange by moving elements manually or by invoking
"*layout selection command*".

CHESS also supports the generation of the model architecture and the report on various analyses executed on the model in an HTML document or a LaTeX source code. The report is divided into two sections. The first describes the structure of the model which includes diagrams and the associated components while the second includes the report lists of the results of the validation and verification (V&V) analyses results. An example of generated model architecture report is shown in Figure 2.20.

<figure><img src="image_23.png" /><figcaption>Figure 2.20: Generated report sample</figcaption></figure>

**2.4.3 Related tools**

Several commercial tools provide similar functionalities to CHESS. One of the most popular is **Matlab/Simulink**<fnref n="13" />. Although Simulink facilitates the modeling and analysis of complex systems, its simulation efficiency might be an important disadvantage. Being based on a single Model of Computation and Communication (MoCC) is another limitation. **CoFluent**<fnref n="14" /> is another commercial tool

<footnote n="13">¹³https://www.mathworks.com/products/simulink.html</footnote>

<footnote n="14">¹⁴https://www.intel.com/content/www/us/en/cofluent/overview.html</footnote>
extended to model IoT systems. Although supporting more interaction models than Matlab/Simulink, it is also limited in the way components may interact among them.

Another tendency is to overcome the UML lack of semantic content, required in some application domains, towards a proliferation of DSLs [60]. Among the available DSLs, UML/MARTE is the standard language for real-time and embedded systems design, while SysML is the standard language for system modeling. Several modeling environments like **Papyrus**<fnref n="15" /> support UML/MARTE. Nevertheless, its flexibility and semantic richness require the definition of efficient modeling methodologies.

**Capella**<fnref n="16" /> is an open-source comprehensive and extensible Eclipse system modeling tool. It is inspired by the SysML principles and it supports the **ARCADIA** methodology that is successfully deployed in a wide variety of industrial contexts [120]. ARCADIA provides architectural descriptions for functional analysis, structural analysis, interfaces, and behavior modeling, structured in five perspectives according to major system engineering activities and concerns.

**COMPASS** [121] supports model checking, model-based safety, reliability, and performance analysis and shares with CHESS some of the tools used as a backend for such analyses. Different from CHESS, it targets a variant of AADL and does not support traceability and code generation.

**MapleSim**<fnref n="17" /> is a modeling tool for multi-domain engineering systems built on top of **Modelica** modeling language [122]. MapleSim features an integrated environment in which the system equations can be automatically generated and analyzed [123].

Although we see some approaches able to tackle modeling challenges, no tool or approach has been able to fit into our methodology with such analysis and verification functionalities. This makes CHESS a novel approach for implementing component-based modeling methodology for real-time and dependable systems by taking care of non-functional properties and enforcing correctness at all the stages of the development process.

### 2.4.4 Conclusions

Dependable complex system design and development present several challenges; the well-known canonical approach is to divide complex systems into smaller chunks (or subsystems), build them separately, and later integrate them. In this section, we presented the current state of the CHESS tool to tackle the design and verification of real-time dependable complex systems. First, we briefly presented the CHESS tool engineering methodologies, such as component-based and multi-view modeling environments. Next, we have summarized the existing analysis support, such as dependability, timing, safety, and quantitative reliability analyses.

<footnote n="15">¹⁵https://www.eclipse.org/papyrus/</footnote>

<footnote n="16">¹⁶https://www.eclipse.org/capella/</footnote>

<footnote n="17">¹⁷https://www.maplesoft.com/products/maplesim/</footnote>
Chapter 3

IoT Engineering Platforms: a state of the
art

This chapter presents the state of the art by summarizing all of the existing approaches related to sev-
eral topics presented in this dissertation. This chapter covers related approaches and tools available in
different area of interest in which this thesis covers. For instance, we covers related works in domains
such as Low-code development tools, model-driven development, deployment, safety analysis and the
software quality models of LCEPs in the IoT domain.

**This chapter is organized as follows:** Section 3.1 reviews the current low-code-based methodologies for engineering IoT systems, highlighting general-purpose approaches as well as IoT-specific approaches that focus on general design and development as well as service-oriented development approaches. Section 3.2 presents the MDE approach for modeling and developing IoT systems. Then, in section 3.3, we present the MDE approaches that focus on deploying IoT systems. In Section 3.4, the related system analysis approach is described with an emphasis on safety-related approaches. Lastly, in Section 3.5, we present the existing conceptual methods for evaluating the quality of IoT engineering systems.

**3.1 Low-Code Development Platforms for IoT**

In this section, we make an overview of existing LCDPs for IoT that take into account MDE concepts in their core implementations.

**3.1.1 General-purpose LCDPs for supporting IoT applications development**

Mendix [124] is one of the popular LCDPs that offer significant enterprise characteristics espe-
cially attractive to large businesses [125]. Its platform is equipped for multi-cloud and hybrid com-
puting, due to its support for on-premises, virtual private multi-cloud, and multi-tenant public cloud
deployment options. With Mendix, you can easily connect to different devices and sensors, and use
data from these devices to create applications that can automate processes, provide insights, and en-
able real-time monitoring and control. In addition, Mendix provides a range of pre-built connectors
and integrations for popular IoT platforms and protocols such as MQTT, AWS IoT, and Azure IoT.
These integrations make it easy to connect your Mendix application to your existing IoT infrastructure
and start collecting and analyzing data right away.

Salesforce [126] is a popular CRM LCDP that has been adopted through many different new tech-
nologies like AI, Machine Learning, and Cloud computing. Salesforce supports the rapid prototyping
of IoT applications through the connection with the underlying Salesforce IoT cloud engines [126].
This platform provides data visualization and event management through a visual set of rules and trig-
gers on different data source components. Furthermore, Salesforce IoT Cloud allows businesses to
create rules that trigger automated actions based on IoT data, such as sending alerts, updating records, or creating new cases in Salesforce. Additionally, it provides real-time insights into IoT data, helping businesses to optimize their operations and make data-driven decisions.

ThingWorx [127] offers a set of tools and services that assist companies to develop, implement, and manage IoT solutions. ThingWorx is designed to make the process of developing and deploying IoT applications easier by allowing developers to focus on designing their applications instead of infrastructure and platform difficulties. It includes a visual drag-and-drop interface that enables developers to design complicated IoT apps without writing much code. ThingWorx also includes an array of pre-built connectors and templates for fast integrating IoT devices and data channels. Finally includes a powerful analytics engine that allows developers to analyze and visualize data from IoT devices in real time as well as ensure data protection from unauthorized access.

Microsoft Power Platform [128] offered by Microsoft, is an LCDP for business software development. While it's not specifically designed for developing IoT applications, it can certainly be used to develop IoT applications with some additional tools and services. PowerApps, which is part of the platform, provides a visual interface for building custom mobile and web applications that can interact with IoT devices. Power Apps include connectors that can be used to communicate with IoT devices, such as Azure IoT Hub or IoT Central. Power Automate, another tool in the platform, can be used to create automated workflows that connect IoT devices to other systems and services such as Azure Event Grid or Azure Stream Analytics. Finally, Microsoft offers a variety of other services that can be used to develop IoT applications, such as Azure IoT Edge and Azure IoT Hub. By using these services in conjunction with the Power Platform, developers can quickly and easily create custom IoT applications with minimal coding.

AWSIoTCore [129] is a fully-managed service provided by Amazon Web Services (AWS) that allows developers to connect, manage, and securely communicate with IoT devices and applications. It provides a platform for developing IoT applications by facilitating device connectivity, message routing, and data management. It includes an LCDP called AWS IoT Things Graph, which allows developers to visually model the structure and behavior of their IoT systems. It offers different development features such as device management which register and manage devices; Rules Engine which allows you to define rules to filter, transform, and route data between devices and AWS services. Finally, it integrates the developed application with other AWS services, including Amazon Kinesis, Amazon DynamoDB, and AWS Lambda.

IBM Watson IoT Platform [130] provided by IBM, provides a set of tools and services to help developers build IoT applications. It offers a range of capabilities such as device connectivity, data management, analytics, and cognitive computing, all of which can be used to develop and deploy IoT applications. The platform is designed to handle large volumes of data generated by IoT devices and sensors and provides secure and scalable communication between devices and applications. It supports a variety of protocols such as MQTT, HTTP, and CoAP, making it easy to connect different types of devices and sensors to the platform. One of the key features of the IBM Watson IoT Platform is its ability to apply analytics and machine learning to the data generated by IoT devices. The platform includes a range of built-in analytics tools, such as dashboards and predictive analytics, that can be used to gain insights into the data and make data-driven decisions.

Simplifier [131] integrates business and IoT applications that enable users to create, manage, deploy, and maintain enterprise-grade SAPUI5¹ apps for web, mobile, and wearables. Simplifier uses a pre-built interface for bidirectional integration of existing SAP and non-SAP systems and leverages shop-floor integration with native IoT interfaces (OPC-UA, MQTT) [131]. It is provided as a web-based environment available on-premise or in the cloud. Simplifier permits to the deployment of applications on the SAP Cloud Platform, SAP NetWeaver, as stand-alone, or on a dedicated Simplifier cloud.

GoogleCloudIoT [132] offered by Google, offers end-to-end solutions for device connectivity, data ingestion, processing, storage, and visualization. The platform also supports a wide range of

<footnote n="1">¹https://www.guru99.com/sapui5-tutorial.html</footnote>
IoT devices and protocols, including MQTT, HTTP, and CoAP. It also integrates with popular IoT development platforms such as Arduino and Raspberry Pi. With Google Cloud IoT, developers can easily create and manage device registries, configure device settings, and monitor device health and status. The platform also provides secure and reliable data transport and storage, using encryption and authentication protocols to ensure data privacy and integrity. In addition, Google Cloud IoT offers a range of analytics and machine learning tools, such as BigQuery and Cloud ML Engine, to help developers gain insights from IoT data and build intelligent applications.

3.1.2 IoT specific LCDPs for system modeling and development

Modeling IoT systems need to take into account heterogeneous parts of the system which run at
different levels. There are several LCDPs available for IoT structural modeling and development. In
this section, we analyze approaches that propose the modeling of the entire structural aspects of the
system.

Node-RED [89] is a programming tool specifically conceived in the IoT context, with the aim of wiring and connecting together hardware devices, APIs, and online services [89]. It provides a cloud-based editor that makes it easy to connect together flows using the wide range of nodes in the palette that can be deployed to its runtime easily. Node-RED provides a rich text editor built on top of Node.js taking full advantage of its event-driven, non-blocking model. Node-RED can be run locally or on the cloud. Node-RED is platform agnostic and compatible with several devices such as Raspberry Pi, BeagleBone Black, Arduino, Android-based devices. Node-RED also supports its integration with cloud-based resources such as IBM Cloud, SenseTecnic FRED, Amazon Web Services, and Microsoft Azure. Finally, in Node-RED, the user can also create and deploy real-time dashboards.

AtmosphereIoT [90] provides IoT solution builders with languages and tools to build, connect, and manage embedded-to-cloud systems. Atmosphere IoT Studio offers a free drag-and-drop online IDE, to build all device firmware, mobile apps, and cloud dashboards. AtmosphereIoT connects devices from a range of wireless options including Wi-Fi, Bluetooth and BLE, Sigfox, LoRa, ZigBee, NFC, satellite, and cellular. This platform is entirely cloud-based but it offers downloadable artifacts. Finally, AtmosphereIoT offers a range of analytics and visualization tools that allow developers to monitor and analyze data from their IoT devices in real time. This helps developers to identify issues, optimize performance, and improve the overall functionality of their applications.

DSL-4-IoT [133] is a cloud-based modeling tool for the IoT domain, which comprises a JavaScript-
based graphical frontend programming language and a runtime “OpenHAB” execution engine. DSL-
4-IoT provides a multistage model-driven approach for the design of IoT applications that supports
all stages of the life cycle of these systems. Automatic model transformations are provided to refine
abstract model elements into concrete ones. Those transformation results formatted as JSON-Arrays
are passed to the OpenHAB runtime engine for execution. In addition to that, it can help to improve
the reliability and performance of the system, DSL-4-IoT can make it easier to test and debug the
system, since the rules and automation logic can be evaluated independently of the underlying device
hardware and software.

BIoTA [134] offers a cloud-based modeling approach for IoT architectures. The specification and implementation of the BIoTA language involve a grammar and a compiler, responsible for syntax and semantic analysis, as well as code generation. A graphical DSL and supporting tools allow users to perform syntax and semantic analysis. BIoTA renders it possible to computationally formalize a software architecture suggested by a user according to formal automata techniques. The component & connectors are created following specific rules to meet IoT-specific scenarios while exporting the resulting software architecture to a software distribution package pattern based on containers (Docker Compose) for future deployment.

Kiljander et al [135] proposed a cloud-based textual language and tool for Event-based Config-
uration of Smart Environments (ECSE) had been proposed. The tool enables the end-user, expert or
not, to configure a smart environment by employing an ontology-based model. In their approach, the
authors used the Resource Description Frameworks (RDF) to define the event-action rules.
Bezerra et al. [136] propose a cloud-based approach for creating responsive and configurable Web of Things user interfaces. Models@Runtime are used to produce runtime interfaces based on a formal model named Thing Description (TD). TD's goal is to expose Web Things (WT) attributes, actions, and events to the outside ecosystem. The modeling language has been developed in JavaScript, using the VueJS framework, and it is publicly available<fnref n="2" />.

FloWare Core [137] is a model-driven open-source toolchain for building and managing IoT systems. FloWare supports the Software Product Line and Flow-Based Programming paradigms to manage the complexity in the numerous stages of the IoT application development process. The system configures the IoT application following the IoT system model supplied by the IoT developer. A Node-RED engine [89] is integrated into FloWare.

Vitruvius [138] is an MDD platform that allows users with no programming experience to create and deploy complex IoT web applications based on real-time data from connected vehicles and sensors. Users can design their ViWApplications straight from the web using a custom Vitruvius XML domain-specific language. Furthermore, Vitruvius provides a variety of recommendation and auto-completion features that aid in creating applications by reducing the amount of XML code to be written.

### 3.1.3 IoT specific LCDPs for service-oriented applications development

This category includes approaches providing users with cloud-based modeling environments targeting service-oriented architectures. Thus, different services are connected to build the final IoT systems.

MIDGAR [139] is an IoT platform specifically developed to address the service generation of applications that interconnect heterogeneous objects. This is achieved by using a graphical DSL in which the user can interconnect and specify the execution flow of different things. Once the desired model is ready, it gets processed through the service generation layer, generating a tree-based representation model. The model is then used to generate a Java application that can be compiled and run on the server.

IADev [140] is a model-driven development framework that orchestrates IoT services and generates software implementation artifacts for heterogeneous IoT systems while supporting multi-level modeling and transformation. This is accomplished by converting requirements into a solution architecture using attribute-driven design. In addition, the components of the produced application communicate using RESTful APIs.

LogicIoT [141] offer a textual web-based DSL to ease data access and processing semantics in IoT and Smart Cities settings. LogicIoT is implemented as a set of custom Jakarta Server Pages (JSP)<fnref n="3" /> in which different custom JSP tags have been implemented to define the modeling semantics. The language consists of seven constructs: relations, triggers, endpoints, timers, facts, rules, and modules. Using the custom tags, the user can define the application's operations required to enable the communication between process instances and sensors without being concerned with low-level programming details.

glue.things [142] offers a cloud-based mashup platform for wiring data of Web-enabled IoT devices and Web services. glue.things take care of both the delivery and maintenance of device data streams, apps, and their integration. In this regard, glue.things rely on well-established real-time communication networks to facilitate device integration and data stream management. The glue.things modeling tool combines device and real-time communication, allowing users to describe elements' triggers and actions and deploy them in a distributed manner.

Taherkordi et al. [143] proposed a cloud-based framework for scalable and real-time modeling of cloud-based IoT services in large-scale applications, such as smart cities. IoT services are modeled and organized in a hierarchical manner by relying on references to services and their real-time data. In

<footnote n="2">²https://github.com/smar2t/td_interfaceBuilder</footnote>

<footnote n="3">³https://en.wikipedia.org/wiki/Jakarta_Server_Pages</footnote>
order to guarantee real-time and fresh service delivery to interested parties, the service tree supports
notification-based access to service data and changes.

Valsamakis et al. [144] presented a portable web-based graphical end-user programming environment for personal apps is proposed. This tool allows users to discover smart things in their environment and create personalized applications that represent their own needs. Each of the defined smart objects can provide various features that can be published via a well-defined API. The graphical representation of the system is then generated from the constructed JavaScript objects in which the user can interact with the system on the fly.

E-SODA [145] is a cloud-based DSL under the Cloud-Edge-Beneath (CEB) architecture ecosystem. In E-SODA, a cloud sensor comprises a set of Event/Condition/Action (ECA) rules that define the sensor service life-cycle. It allows the user to be abstract and simulate sensor behavior in an events-based fashion. This is achieved by having the ECA rules listen for the occurrence of a predetermined "event" and respond by performing the "action" if the rule's "condition" is met. Finally, the generated cloud sensor application can be used in any cloud-based application which needs sensor data.

Mayer et al. [146] introduced an integrated graphical programming tool based on a goal-driven approach, in which end users are only required to specify their purpose in a machine-understandable manner, rather than designing a service architecture that fulfills their goal. This allows a smart environment's ultimate purpose to be graphically represented, but the complexities of the underlying semantics are hidden. A reasoning component uses the provided goal statement and analyses whether the goal can be achieved given the set of available services and infers whatever user actions (i.e., requests involving REST resources) are required to achieve it.

InteroEvery [147] is a cloud-based development tool that promotes a micro-service-based architecture to deal with interoperability issues of the IoT domain. First, an IoT system is configured through a web-based graphical interface showing each micro-service functionalities. A universal broker connects a dedicated interoperability micro-service with various adaption micro-services depending on employed choreography patterns.

## 3.2 Model-driven design and development of IoT systems

In this section, we present the related work with more emphasis on software modeling and development that may further generate code ready for deployment on IoT devices.

Ciccozzi, F. et al. [36] presented MDE4IoT, an MDE platform that combines different UML DSLs as profiles used through different viewpoints to enforce the separation of concerns. Its main goal is to combine the support for the design, development, and runtime management of IoT systems. This is achieved by providing means for supporting the modeling and self-adaptation of Emergent Configurations (ECs) of connected systems. MDE4IoT performs a series of model-to-model as well as model-to-text transformations to satisfy the generated platform-specific code from state machines. The run-time monitoring and self-adaptations are supported through the re-allocations as well as re-generation mechanisms according to the system's runtime feedback.

Costa B. et al. [50] presented SysML4IoT a Model-Based Systems Engineering tool for IoT application development, focusing on the design phase. SysML4IoT is strongly based on IoT-A domain reference model [49] established by European research body as well as ISO/IEC/IEEE 15288 standard <fnref n="4" />, aiming to enhance system models with Systems Engineering concepts [49]. To address different stakeholders involved in the process, the tool adopts a multi-disciplined IoT application design by using views and viewpoints. In [148], SysML4IoT was been extended to assist IoT application engineers in precisely modeling IoT applications and verifying their quality of service (QoS) properties. Through a model-to-text translator that converts the model and QoS properties specified on it to be executed by NuSMV [68], a mature model checker that allows entering a system model comprising a number of communicating Finite State Machines (FSM) and automatically checks its properties specified as Computational Tree Logic (CTL) or Linear Temporal Logic (LTL) formulas. The tool has been

<footnote n="4">⁴https://standards.ieee.org/ieee/15288/5673/</footnote>
adopted in [149] for developing IoT self-adaptive systems endorsing the public/subscribe paradigm to model communication with other systems.

Thramboulidis K. et al. [150] introduced UML4IoT, an MDE platform for industrial automation systems. It was designed to support the full automation of the generation process of the IoT-compliant layer required for the cyber-physical component to be effectively integrated into the modern IoT manufacturing environment. A model-to-model transformation has been implemented to automatically transform the mechatronic components into Industrial Automation Things (IAT). The tool adopted the Open Mobile Alliance (OMA) LWM2M application protocol running on top of the CoAP communication protocol as the mean for exposing the IoT interface as simple smart objects [151]. The approach also enables the usage of high-level languages such as Java to specify the system's behavior in case a higher-level design specification such as the UML one is not available.

Harrand N. et al. [37] presented ThingML, an engineering IoT platform that combines well-proven textual software-modeling constructs aligned with UML (statecharts and components) and an imperative platform-independent action language for developing IoT applications. In ThingML, a thing can be defined by a set of properties, functions, messages, ports, as well as state machines. These behaviors are local to a thing and can be accessed only through interfaces inside the state machines or functions. The interaction between things is enabled through required or provided ports by means of message exchanges. The tools include an advanced multi-platform code generation framework that supports multiple target programming languages such as C/C++, Java, Arduino, JavaScript, Python, and Go. In [152], ThingML was extended to assist IoT/cyber-physical modeling with machine learning needs. The new approach targets the issue of IoT communications and behavioral modeling which was normally done using state machines.

Nicholson R. et al. [39] presented IoTML, a tool developed in the context of the BRAIN-IoT project [39] as an integrated modeling tool to ease rapid prototyping of intelligent cooperative IoT systems based on shared models. The BRAIN-IoT modeling environment i.e IoTML is implemented as a Papyrus profile. The BRAIN-IoT architecture mainly consists of three macro-blocks: the BRAIN-IoT Modeling Framework, the Marketplace, and the Federation of BRAIN-IoT Fabrics. The constructed models are transformed into XML format before being uploaded to the BRAIN-IoT marketplace for run-time system deployment and dynamic remote edge/cloud reconfiguration.

M. de Farias et al. [153] presented a Cloud and Model-based IDE for the IoT tool (COMFIT) to target wireless sensor networks (WSN) applications for IoT. The COMFIT modeling environment is built on top of Papyrus, and it presents a simple multi-view environment to model the system's requirement, structural and behavioral aspects. The wireless nodes of the system and their communication links are created in the structural view, while the model activities and behaviors are modeled as functional units, which later get linked according to the desired execution sequence. Finally, the tool provides the model-checking infrastructure respecting the OCL rules specified in the meta-model.

Muccini H. et al. [72] introduced CAPS an architecture-driven modeling framework for the development of Situational Aware Cyber-Physical Systems. CAPS is based on a multi-view architectural approach that combines the design for the IoT system's software components and their interactions, the hardware specification of situational awareness, as well as the physical environment where hardware equipment is deployed. To link together the modeled views, the authors introduced two auxiliary languages, denoted Mapping Modeling Language (MAPML) and Deployment Modeling Language (DEPML). The authors used the Atlas Model Weaver (AMW)<fnref n="5" /> to define relations among models and to create semantic links among model elements. In [154], CAPSml extension to CAPS was introduced to support the platform-specific code generation through the usage of the ThingML [37].

Dhouib S. et al. [155] introduced Papyrus4IoT, a modeling tool developed under the Smart, Safe, and Security Software Development and Execution Platform (S3P) project. Papyrus4IoT environment that enables the design and deployment of complex IoT systems following an IoT-A reference architecture [7]. the designer can define process specification definition, functional, and operational platform, and the deployment which is done by allocating the system's functional blocks to the device

<footnote n="5">⁵https://projects.eclipse.org/projects/modeling.gmt.amw</footnote>
processing units. The authors proposed the use of development-time models to supervise a running
IoT system to reflect the Models@Runtime monitoring approach. This typically helps in detecting
overall system critical states and helps make decisions on the adaptation of the running system. Au-
thors suggest the extension of Papyrus Moka [156] to perform model simulations. Concerning the
deployment of the modeled systems, authors make use of Prismtech's Vortex as a dynamic platform
to discover and deploy microservices, and MicroEJ as the target operating system.

Salihbegovic A. et al. [133] presented DSL-4-IoT, a tool based on a high-level visual programming language established to tackle the complexity and heterogeneity of IoT systems. The Editor enables the application designer to configure the system structure and select devices, sensors, and actuators either from built-in library modules available. When the design is finished, the user can export the data into one JSON array configuration file. This file keeps the information about the position of all the items within the configuration, relationships between items and groups, the value of all configured fields associated with items, and of data types. After all configuration files are generated, they can be transferred to the respective OpenHAB runtime directory manually or automatically downloaded, using a simple web service for execution.

Erazo-Garzón L. et al. [26] presented Monitor-IoT, a graphical designer (high-level visual language) built in the Obeo Designer Community and Eclipse Sirius tools to support developers in modeling IoT multi-layer monitoring architectures with a high level of abstraction, expressiveness, and flexibility. Monitor-IoT supports the definition of computing nodes and their resources that support the monitoring processes (data collection, transport, processing, and storage) at the edge, fog, and cloud layers. It is also possible to specify the properties to be monitored for each entity as well as the definition of dataflows between digital entities, based on synchronous or asynchronous communication. Although Monitor-IoT supports a variety of different interesting concepts, it does no support the generation of any kind of code, monitoring scripts, or data flows which can be executed on an actual IoT system.

Pramudianto F. et al. [157] presented IoTLink, a development toolkit based on a model-driven approach to allow inexperienced developers to compose mashup applications through a graphical domain-specific language. Modeled applications can be easily configured and wired together to create an IoT application. Through visual components, IoT Link encapsulates the complexity of communicating with devices and services on the internet and abstracts them as virtual objects that are accessible through different communication technologies. To support interoperability with other services, authors implemented custom components like ArduinoSerial for Arduino connectivity, SOAPInupt, RESTInput, MQTTInput, etc. The tool is able to generate a complete Java project including an extendable Java code. At runtime, the tool generates connections by using the Drools<fnref n="6" /> engine to poll the rules from a database repository, which allows developers to deploy and change deployment rules at runtime. In a controlled experiment, IoT Link was 42% faster than using a Java library and able to outperform the Java library’s user satisfaction.

Corradini et al. [158] presented X-IoT, a model-driven approach supporting the development of cross-platform IoT applications. X-IoT is based on a DSML and its related notation, whose development has been guided by a deep analysis of IoT application characteristics. The proposal covers the modeling, development, and deployment phases, supporting different actors in the development process and the derivation of specific artifacts, resulting in a model-to-code transformation approach. X-IoT tackles the IoT platform portability issue by promoting “a single development/multiple deployments” strategy. Tool support is provided through the ADOxx platform <fnref n="7" />, which allows using the DSML to model platform-independent IoT applications. The resulting application can be successively refined by introducing platform-specific information and then deployed on the selected IoT platform.

Thang Nguyen et al. [159] presented a FRAmework for Sensor Application Development (FRASAD), a model-driven framework to develop IoT applications. The tool was developed with aim of tackling the reusability, flexibility, and maintainability of sensor software. FRASAD relies on a node-centric

<footnote n="6">6. https://www.drools.org/</footnote>

<footnote n="7">⁷https://www.adoxx.org</footnote>
software architecture model in which a rule-based programming model is enabled by a DSL that un-
couples the programming language and the execution model used by the underlying operating system.
FRASAD has been developed on top of Eclipse EMF/GMF and consists of a graphical modeling lan-
guage, a code generator, and other supporting tools to help developers design, implement, optimize,
and test the developed IoT applications. Two case studies are provided to show the usability and
portability of our framework. The evaluation results demonstrate that our framework FRASAD can
be considered a promising solution to reduce the complexity of IoT software development.

Nepomuceno et al. [160] presented AutoIoT, a framework that allows users to model their IoT
systems using a simple JSON file. The process starts by modeling the system using the graphical
interface generated from GMF. When the modeling phase is completed, AutoIoT loads the content
of the model as a JSON file to be validated and transformed into Python objects using the Pydantic<fnref n="8" />
library. After that, the framework finally delivers these objects to an appropriate *Builder* that performs
model-to-text transformations to generate a ready-to-use IoT server-side application. The Prototype
Builder generates a Flask application written in Python, HTML, CSS, and Javascript. The generated
server-side application communicates with IoT devices and third-party systems through MQTT, Rest
API, and WebSockets.

Soukaras et al. [161] presented IoTSuite, a suite of tools for IoT applications development, for reducing development effort. The tool consists of the following components: i) an *editor* to support the application design phase by allowing stakeholders to specify high-level descriptions of the system under development; ii) an ANTLR<fnref n="9" /> based *compiler* that parses the high-level specification and supports the application development phase by producing programming framework that reduces development effort in specifying the details of components of an IoT application; iii) a *deployment module*, which is supported by the mapper and linker modules; iv) a *runtime system*, which leverages existing middleware platforms and it is responsible for the distributed execution of the modeled IoT application. The current implementation of IoTSuite targets both Android and JavaSE-enabled devices and makes use of an MQTT-based middleware.

Xuan Thang et al. [162] presented a DSL designed for specifying all aspects of a sensor node application, especially for data processing tasks such as sampling, aggregation, and forwarding. The proposed DSL offers a set of declarative sentences to express the behavior of sensor nodes application such as *sampling*, *aggregating*, and *forwarding* which is necessary for developing data-centric Wireless Sensor Networks (WSN) applications. The tool is based on Eclipse GMF for specifying PIMs. The transformation from the PIM to nesC<fnref n="10" /> PSM models has been implemented by using the ATL transformation language<fnref n="11" />. Acceleo-based model-to-text transformations have been developed to generate the final nesC source code of the modeled system.

## 3.3 MDE for deployment of IoT systems

In the context of IoT, MDE can help to simplify the deployment process by automating many of
the tasks involved, such as configuring devices, setting up communication protocols, and managing
data flows. By creating models that capture the key aspects of an IoT system, such as the devices,
sensors, and data streams involved, MDE can provide a high-level view of the system and make it
easier to manage and maintain. In this section, we go over the MDE approach that focuses mainly on
the deployment modeling and automation of IoT systems.

Kirchhof et al. [17] introduced MontiThings a C&C language offering automatic error handling
capabilities and a clear separation between business logic and implementation details. Built on top of
MontiArc [163], MontiThing is an integrated modeling language for architectures of IoT applications,
their deployment, and error handling that lifts the level of abstraction in the IoT system engineering

<footnote n="8">⁸https://pydantic-docs.helpmanual.io/</footnote>

<footnote n="9">⁹https://www antlr org/</footnote>

<footnote n="10">¹⁰http://nescc.sourceforge.net/</footnote>

<footnote n="11">¹¹https://www.eclipse.org/atl/</footnote>
process. The error-handling approach makes C&C-based IoT applications more reliable without clut-
tering the business logic with error-handling code that is time-consuming to develop and makes the
models hard to understand, especially for non-experts. Targeting mainly the edge layer, Montithings
provides a model-driven toolchain for the automated synthesis of executable IoT containers, and auto-
mated deployment planning, featuring deployment suggestions, for the generated containers. Finally,
the tool monitors the generated container and in case of need, the tool is able to suggest the deployment
goals changes based on deployment planning feedback.

Duran et al. [164] proposed a new technique for supporting the reconfiguration of running IoT applications, represented as a set of coordinated rules acting on devices. These techniques compare two versions of an application (before and after reconfiguration) to check if several functional and quantitative properties are satisfied. This information can be used by the user to decide whether the actual deployment of the new application should be triggered or not. The approach uses advanced Event-Condition-Action (ECA) rules by providing means for the composition of rules, such as the sequential execution of rules, the choice between several rules, the concurrent execution of several rules, or the repetition of rules. Finally, the property property-based verification was implemented to analyze whether the proposed reconfiguration preserves the consistency of the application.

Ivan A. et al. [165] proposed a model-based approach for the specification and execution of self-adaptive multi-layered IoT systems. A domain-specific language (DSL) for the specification of such architectures, and a runtime framework to support the system behavior and its self-adaptation at runtime were presented. The proposed DSL covers modeling primitives covering the four layers of an IoT system that includes IoT devices (sensors or actuators), edge, fog, and cloud nodes. The modeling of the deployment and grouping of container-based applications on that node. In addition to that, the tool supports a specific language to express adaptation rules to guarantee QoS at runtime. A proof of concept of a generator for deploying and executing the runtime state of modeled IoT system on a K3S-based infrastructure (Kubernetes distribution built for IoT and edge computing) is also provided.

Negash et al. [166] introduced DoS-IL, a textual domain scripting language for resource-constrained IoT devices. It allows a flexible and scalable approach that enhances modifiability and programmability through client-server-server-client architecture. DoS-IL allows changing the system’s behavior after deployment through a lightweight script written with the DoS-IL language and stored in a gateway at the fog layer. This mainly is to support easy maintenance and modification after deployment, without the need to physically access the end node. The gateway hosts an interpreter to execute DoS-IL scripts accessible by devices in the perception layer. The interpreter splits the script into tokens first, identifies the function of each token, and structures it in a convenient way for execution. On the target node, the Device Object Model (DOM) exposes the available resources for the DoS-IL script to manipulate.

Fei Li et al. [167] proposed Topology and Orchestration Specification for Cloud Applications (TOSCA), a structured (XML-based) language that defines different components of an application and relations between them using an application topology while capturing all management tasks in management plans. TOSCA aims at automating the deployment and management of composite applications by providing a generic way to describe the application topology of composite cloud applications and leverages portable workflow languages to ensure the portability of deployment and management plans. Moreover, it aims at improving the reusability of service management processes and automating IoT application deployment in heterogeneous environments. In TOSCA, common IoT components such as gateways and drivers can be modeled. In addition, the gateway-specific artifacts necessary for application deployment can also be specified to ease the deployment tasks.

Ferry et al. [168] proposed GENESIS, a textual cloud-based domain-specific modeling language that supports continuous orchestration and deployment of Smart IoT systems on edge, and cloud infrastructures. GENESIS (Generation and Deployment of Smart IoT Systems) uses component-based approaches to facilitate the separation of concerns and reusability; therefore, deployment models can be regarded as an assembly of components. The GENESIS execution engines support three types of deployable artifacts, namely ThingML model [37], Node-RED container [89], and any black-box deployable artifact (e.g., an executable jar). The created deployment model is subsequently passed to
the GENESIS deployment execution engine, which is in charge of deploying the software components,
ensuring communication between them, supplying the required cloud resources, and monitoring the
deployment's status.

Erazo-Garzón et al. [26] introduced Monitor-IoT, a graphical designer (high-level visual language) built in the Obeo Designer Community and Eclipse Sirius tools to support developers in modeling IoT multi-layer monitoring architectures with a high level of abstraction, expressiveness, and flexibility. Monitor-IoT supports the definition of computing nodes and their resources that support the monitoring processes (data collection, transport, processing, and storage) at the edge, fog, and cloud layers. It is also possible to specify the properties to be monitored for each entity as well as the definition of dataflows between digital entities, based on synchronous or asynchronous communication. Although Monitor-IoT supports a variety of different interesting concepts, it does no support the generation of any kind of code, monitoring scripts, or data flows which can be executed on an actual IoT system.

3.4 MDE for safety analysis of IoT systems

MDE can help with safety analysis by allowing designers and safety engineers to create models of the system that capture its behavior and interactions with the physical world. These models can then be used to perform various types of safety analysis, such as hazard identification, Fault-Tree, and Failure Mode and Effects Analysis (FMEA) [79]. MDE-based safety analysis can be particularly effective for complex IoT systems, where the interactions between devices, sensors, and data streams can be difficult to understand and analyze manually. By creating models that capture the system's behavior and interactions, MDE can provide a more complete and accurate view of the system and its potential risks.

Fault tree analysis is one of the hugely used and suggested methods when performing different
dependability analysis studies, including safety analysis [34]. We have also mentioned that FTs are
among the mandatory artifacts that should be provided for performing Safety Analysis in different
domains and IoT is yet to follow [32]. However, most of the approaches presented in the literature
still rely on the manual construction of the FTs, which still makes the process time-consuming.

One of the widely used tools in the industry as well as in the academia to perform the FTA is the ISOGRAPH tool [169]. The ISOGRAPH Reliability workbench is a powerful integral visual modeling and analysis environment in which all the aspects of the reliability analysis such as failure rate and maintainability prediction, Failure Mode Effects & Criticality Analysis (FMECA), Reliability Allocation, Reliability Block Diagram as well as Fault Tree, Event Tree, and Markov analysis are combined. Although this tool is seemingly powerful in terms of what can be covered, different from our approach presented in Chapter 7 in which the system FTs are automatically generated from the analysis, the FTs are still manually constructed from the system failure requirements provided by the safety experts.

Haider et al. [3] employs the CHESS Failure Logic Analysis results to build European Cooperation for Space Standardization (ECSS)<fnref n="12" /> compatible FTs. Although their approach is linked with ours, it differs significantly in various points. To name a few, their approach only supports system-level component composition while creating FT, while our approach supports any level of composition. For instance, with our approach, FTs of a single composite component can be generated and analyzed individually. Furthermore, in their approach, only basic events from the system-level input ports can be generated, whereas in our case, any component can initiate a basic failure event. Finally, their approach only supports FT generation, however, unlike our approach, they neither support qualitative nor quantitative FT analysis.

Parri et al. [170] presented JARVIS (Just-in-time Artificial intelligence for the eValuation of Industrial Signals), a model-driven tool that facilitates the development and verification of the integration of physical IoT devices, enterprise-scale software agents, data analytics, and human operators.

<footnote n="12">¹²https://ecss.nl/standards/</footnote>
JARVIS promotes semi-formal specification of structural elements, functional requirements, and be-
havioral characteristics of subsystems from a System of a Systems perspective. JARVIS employs
agents to facilitate the development and integration of intelligent data agents capable of detecting fail-
ure events that occur in accordance with a set of failure modes. Eventually, a *FaultTreeAnalyzer* agent
is used to perform Fault Tree Analysis on detected failure events. Although their approach performs a
qualitative analysis, the quantitative one is not supported. Finally, their FT generation approach relies
on the practical data model constructed by the deployed agent, while our approach relies on FLA for
the FT generation.

Several approaches have been proposed for the automatic generation of FTs from SysML models. For example, Mhenni et al. [171] present an approach for generating FTs from SysML models, relying on a combination of information provided in activity and IBD diagrams as well as information in the FMEA table. Although the current tool generates a single FT picture representing the system failure paths, no FT models are generated. Another critical difference with respect to our proposed approach regards the use of *directed graph traversal* and *block design patterns* to generate FTs which is nothing but using the component-directed edge relationships to determine how the next component has to be represented in an FT. Even though the presented block design patterns are useful to derive the component failure propagation behaviors, they do not cover certain topics such as "internal failure of the components", since this information is probably picked from the FMEA table, as well as they do not provide any support for any kind of automated qualitative or quantitative FT analysis.

Alshboul et al. [4] presented an MDE environment for performing preliminary safety analysis from SysML models. The approaches use UML state machines to model the component functional behavior and annotate them with failure behaviors; later this information is used to generate the system FTs. Although the proposed approach generates the FTs, certain aspects of the safety analysis are not covered such as injected or external failures, as well as the qualitative or quantitative analysis of the generated FTs. On another hand, Yakymets et al. [172] presented a framework that integrates the formal method approach for facilitating the automatic FT generation within an MDE workflow. The approach annotates to the SysML model elements the formal analytical expressions showing how deviations in the block outputs can be caused by internal failures of the block and/or possible deviations in the block inputs. Later this information is transformed into an AltaRica model [173] representation which is used to perform qualitative and quantitative analysis using the XFTA tool provided by the framework. Although this approach seems very interesting, the process of annotating the model with formal analytical expression can be very complex to grasp whereas, in our proposed approach, failure logic behavior rules following FPTC notation are used and we retain they are simpler and straightforward to be used.

In terms of safety-critical systems, Han et al. [84] presented an approach for performing a com-
bination of FMEA and FTA analysis on safety-critical systems starting from the Preliminary Hazard
Analysis (PHA) method, initially conducted by the safety experts. However, no supporting tool is
provided. Same as Hame at al. [174] an approach for manually deriving FT diagrams from the Re-
liability Block Diagram (RBD) was also presented, however, the qualitative and quantitative analysis
are manually performed, differently from our approach where the analysis is performed automatically.
Furthermore, unlike our approach which models the system architecture, annotates the model with
safety-related information, and later generates and analyzes FTs, several approaches, such as [175-
177], propose SysML profiles which are used to create FT models and later translate them into FT
graphs without any support for system modeling itself. On another hand, Chaari et al. [178] proposes
a Meta-modeling-based Failure Propagation Analysis (MetaFPA) framework to support the synthesiz-
ing of the system failure propagation models in order to help the creation of the system FTs. Although
the presented framework presents an alternative to FPTC on how system failure propagation rules can
be modeled, unlike our proposed approach, the framework does not generate the system FTs but relies
on the ISOGRAPH tool [169] to perform the FTA. The same goes with the approaches proposed in
[174, 179] which rely on the ISOGRAPH software to manually construct and analyze the FTs.

In the IoT domain, very few approaches specifically target the execution of safety analysis on
IoT systems. This might be mainly caused by the lack of systematic, disciplined, and quantifiable
software engineering standards, as well as comprehensive abstraction models for dealing with the increasing complexity and safety requirement heterogeneity present in the IoT domain. Silva et al. [180] presented a dependability evaluation tool for IoT applications, when hardware and permanent link faults are considered. The tool supports the modeling of system network architecture and, later, the so-called network failure condition events (nfc) are defined to help in generating the FT. The nfc formalism somehow follows the logical association rules for addition and multiplication in order to reflect the "OR" and the "AND" gates respectively. Finally, the tool supports the qualitative analysis, by generating minimal cut-sets, as well as the quantitative analysis. Although this tool supports the automatic generation and the analysis of the FTs, it differs from our approach presented in Chapter 7 both in terms of system failure behavior formalism and because it does not support any mechanism related to failure transformation, propagation, and injection.

Chen et al. [181] presented an intelligent method for fault diagnosis based on a combination of FTA and fuzzy neural networks in the aquaculture IoT systems. In their approach, the FT is manually constructed for each component of the system and later the “IF-THEN” rules are extracted from the FT to be fed into the fuzzy neural network to train the relationship model between fault symptoms (failures) and faults. Although this method uses the FTA for the safety analysis process, it differs from our approach since the generation of the FT is done manually, while in our case it is performed automatically. Furthermore, our approach conducts a quantitative analysis by calculating the system failure probability, while their approach does not. Finally, Xing et al. [182] presented an FT modeling infrastructure in which different reliability analyses for mesh topology IoT networks are performed taking into account the quantitative analyses. However, same as the ISOGRAPH tool, the aspect of the FT construction is still manually done from the system failure requirements provided by the safety expert.

## 3.5 Software product quality model for IoT LCEPs

Practitioners typically rely on well-established standards and practices to improve confidence in whether a system or a product fits the wanted quality requirements. ISO/IEC 25010:2011 standard is one of the model standards that have been heavily used to assess the quality of complex software and systems. In this section, we present the existing approaches that was been used to evaluate the quality of IoT systems based on ISO/IEC 25010:2011 standard.

To name a few, Azham et al. [18] relied on it to assess the quality of online health awareness systems, Martinez et al. [19] relied on the model for assessing the quality of IoT brokers. Schipore et al. [183] presented Euphoria, a software architecture design and implementation that enables easy prototyping, deployment, and evaluation of adaptable and flexible interactions across heterogeneous devices in smart environments. The tool was designed and developed following the requirement set by the ISO/IEC 25010:2011 standard. Johan et al. [20] relied on the standard to evaluate the quality of IoT implementations. Although this quality model's scope is intended general for software and computer systems, it can also be applied to assess larger systems and services [14]. For instance, Janine et al. [25] adopted the standard to assess the quality of mobile applications, as well as in [21, 22] for Machine learning and Big data systems.

There have been several approaches in the modeling domain for quality measurements. For example, Gökhan et al. [184] introduced a Framework for Qualitative Assessment of DSLs (FQAD) was presented. The FQAD framework is based on ISO/IEC 25010:2011 when determining the evaluation's perspective, the assessment's goal, and selecting relevant quality characteristics to guide the assessment process. In addition to that, in [185] Christian et al. relied on the standard to assess the quality assurance of DSLs. In contrast, Mohamed et al. [186] employed the standard to evaluate the quality of design architectures. In addition, Miguel et al. [187] relied on the standard to evaluate MDE quality studies in attaining maximum quality evaluation level by considering that study that touched more of the quality characteristics as specified by the standards would be ranked as optimal.

Luana et al. [23] used the standard to perform a mapping study on the quality assessment of
software product lines. The standard was used by Jara et al. [188] to assess the security quality of mobile cloud computing-based technologies. Finally, Bernardes et al [24] used it to evaluate the quality aspects of customer relationship management (CRM) systems. A large number of extensions and suggestions on the standard have been proposed. To name a few, Estdale et al. [189] proposed the extension to meet the lifetime service-oriented quality aspect of software systems. Rahman et al [21] conducted a study to assess the product quality of Big Data systems concerning non-functional requirements, while Gonzalez et al. [190] extended the model to Semantic Web exploration tools.

Finally, Farshidi et al. [191] presents a highly comprehensive effort to assist the quality evaluation of MDD platforms, as well as a mapping from the proposed model to the ISO/IEC 25010:2011 standard. In their approach, a multi-criteria decision-making (MCDM) model for MDD platforms is used to help in choosing an optimal quality sufficient platform for their requirements. External decision models can be uploaded to the existing decision support system (DSS) knowledge base to support long-term software-producing organizations make decisions based on their needs and preferences. Nevertheless, the approach as well as the results presented are too generic, whereas our approach focuses primarily on IoT-specific platforms. Furthermore, the approach, in our opinion, focuses mostly on LCDPs, while other conventional MDE platforms, such as those based on the Eclipse Development Environment, are not taken into account at all.
# Chapter 4

## Limitations and open challenges of existing IoT Engineering Platforms

IoT Engineering platforms have to cope with several challenges mainly because of the heterogeneity of the involved sub-systems and components. With the aim of conceiving languages and tools supporting the development of IoT systems, this chapter presents the results of different studies conducted to understand the current state of the art of LCEPs in the IoT domain. By partially targeting to answer the first research problem (RP1), this chapter initially focuses on MDE and Low-Code approaches to satisfy the engineering support of IoT systems. First, we present a general overview of what an IoT Engineering platform should support through a well-conceived taxonomy of features. By doing so, we selected sixteen platforms, and such features were used to evaluate the functionalities and services supported by each analyzed platform. Furthermore, we identified some weaknesses of the analyzed platforms to pave the way toward a Low-Code platform for developing IoT systems. As a last step, we have also identified some limitations of existing approaches and discussed possible ways to improve and address them in the future.

The current evolution of cloud-based computing opens up many possibilities for software development. In the near future, the engineering of complex systems in various domains, such as Space, Automotive, IoT, and Smart Cities, will be done from cloud-based environments, lowering production and maintenance costs. In particular, parts of the IoT domain have to run on Edge, Fog, or Cloud, posing significant difficulties in determining what, where, and when to develop. Therefore, as a contribution toward answering the first research problem (RP1), this chapter also present the results of the state-of-the-art review we conducted to investigate where the IoT domain community stands concerning the current trend of moving traditional modeling infrastructures to the cloud. After examining 611 articles, we focus on 22 different cloud-based IoT system development approaches. The considered approaches have been analyzed to assess their strengths and weaknesses concerning many characteristics, including their modeling focus, accessibility, openness, and artifact generation. Throughout the chapter, we have discussed many challenges IoT developers encounter while adopting such tools. We also discuss various generic technologies and tools which can be adopted in the IoT domain.

**The chapter is organized as follows:** Firstly, Section 4.1 demonstrates the current state of the art of IoT engineering platforms in general, including both Low-code and MDE approaches. In fact, section 4.1.1 highlights the IoT engineering platform features, and 4.1.3 evaluates the outcomes of the study while sub-section 4.1.4 concludes the section. Secondly, Section 4.2 covers the current state of the art in cloud-based modeling methodologies in IoT. Section 4.2.1, for instance, presents related studies on cloud-based modeling in IoT, Section 4.2.2 presents the study design methodology while Section 4.2.3 describes the study's results. Section 4.2.4 presents the topic's challenges, and Section 4.2.5 highlights related opportunities.
## 4.1 Engineering IoT platforms

According to European Union CONNECT Advisory Forum report [192], IoT promises to be one of the most disruptive technological revolutions since the advent of the Internet. It is projected that by the end of 2030, fifty to hundred billion IoT devices will be connected to the Internet using a variety of information technologies [193]. As we experience in daily life, now we see more and more intelligent traffic lights, advanced parking technologies, smart homes, and intelligent cargo movement. This is due to the rising adoption of artificial intelligence (AI), and 5G infrastructure is helping the global IoT market register increased growth.

IoT engineering platform aims to simplify and streamline the process of developing and deploying IoT applications, helping developers to focus on the higher-level functionality of their applications instead of worrying about the underlying infrastructure and connectivity [8]. IoT engineering platforms especially commercial ones may also include a set of pre-built components, such as sensors, actuators, and communication protocols, that can be used to quickly develop IoT applications without having to build everything from scratch [90]. Additionally, these platforms often support various programming languages, making it easier for developers to build applications using the language they are most comfortable with [89].

In this section, we present the current state of research model-based approaches for engineering IoT systems by taking into account LCDPs in particular. We present a general overview of what we think a typical IoT Engineering platform should support through a well-conceived taxonomy of features. We present the results and the findings that have been done by analyzing sixteen IoT development platforms. They are divided into two categories considering their basic implementation mechanisms. In particular, the first category consists of tools based on the Eclipse technologies such as Eclipse Modeling Framework(EMF), Graphical Modeling Framework(GMF), and Papyrus environment. The second category is a collection of tailor-made platforms LCDPs.

### 4.1.1 Engineering IoT platforms features

In this section, we introduce a taxonomy of terms, which can support the description and the comparison of different approaches for the development of IoT systems. By analyzing different languages and tools drafted from Chapter 3, we identified and formalized their corresponding variabilities and commonalities in terms of a feature diagram. These features were selected mainly based on our expertise as well as the studies from different research papers. Figure 4.1 shows the top-level feature diagram, where each sub-node represents a major point of variation.

**Requirement modeling support:** This group of features emphasizes the first stages of any MDE-based development process. This evaluates whether a tool has an inbuilt requirement specification environment. Supporting this feature is very important because it helps keep track of whether the specified requirements are correctly implemented throughout the whole development. This also helps in requirements traceability and verification.

**Domain Modeling support:** It refers to the kind of modeling tools the user is provided with e.g., if it is graphical or not if it gives the possibility to model the static structure of the system's blocks or components. Some of the systems provide modelers with behavior modeling capabilities to specify semantic concepts relating to how the system behaves and interacts with other entities (users or other systems). For instance, OMG-based implementations of UML/SysML inherit all the modeling functionalities which include structural and behavioral diagrams. Additionally, this also includes the tool supports for design through multiple views which in turn is referred to as multi-view modeling support should also be considered.

**Testing and verification support:** It refers to whether a tool has inbuilt mechanisms to evaluate artifacts before deployment which can be done by conducting different verification checks. As IoT applications are present in our daily life, developing systems that will cause no harm to users in case of more and more sophisticated scenarios should be a priority. To be more specific this feature evaluates
<figure><img src="image_24.png" /><figcaption>**Figure 4.1:** Feature diagram representing the top-level variation areas</figcaption></figure>

if the tool support model-based testing, inbuilt model checking, and validation mechanism. This is very important as it ensures the system's correctness and robustness which make the system safe and secure.

**Analysis environment:** Such a group of features is related to the capability of the considered environment to support different analysis checks for the intended system before its deployment. This can be done on different blocks or components of the system by checking on their responsiveness in case of failure, network loss, security breach, and so on. In this regard, we can feature dependability analysis, real-time analysis, and system quality of service in general.

**Reusability:** This category illustrates whether the tool under analysis allows the export of artifacts for future reuse. This can be done on developed models or on generated artifacts. Reusability features are also related to the way artifacts are managed e.g., locally or by means of some cloud infrastructure.

**Deployment support:** It is related to the ways developed systems are deployed and if the generated artifacts are ready for deployment or not. To the best of our knowledge, this should be one of the important features to focus on when implementing an IoT engineering tool. In addition to that, the development tool can be installed locally or on the cloud depending on the client's interest. Finally, factors such as run-time adaptation mechanisms (on modeled or generated artifacts) to respond to the contextual changes are also considered in this category.

**Interoperability:** This feature examines the ability of a tool to exchange information either internally between components, expose or consume functionalities or information from external services e.g., by means of dedicated APIs.

**Extensibility:** The tool should provide the means for refining or extending the provided functionalities. In the case of modeling tools, such a feature is related to the possibility of adding new modeling features and notations.

Additionally to the above features, we have added the "additional characteristics" row to elicit other orthogonal characteristics to the previously discussed elements. In particular, some tools target early phases of development like system design, data acquisition, and system analysis by focusing on the *thing* behavior. Some other tools target the application generation without taking much care of the data acquisition phases which can be done by integrating the developed system with already implemented data source engines, etc. Another peculiar aspect is if the considered approach is available as