Preface

This internship took 6 months and commenced on the first of April 2023 within the dynamic
and research-rich environment of IRIT at ENSEEIHT Toulouse-INP. It was specially hosted
by the appreciated research teams of ACADIE and MINDS, offering a unique opportunity
to engage with advanced research in their respective domains. Notably, the internship was
financially supported by the prestigious IBCO project (CIMI 2021-2023), underscoring its
significance in furthering the research objectives of the institute and providing a valuable
platform for professional growth and academic exploration.
 To my parents,
No dedication can express my deep affection, gratitude, and respect for you.
It’s with your love and your sacrifice that I could realize your wishes. Be always my light
and my source of happiness.

To my brothers,
for their love and support, I dedicate it. I wish you a long life with lots of happiness and
success.

To all my friends,
without their caring support, it would not have been made possible.
And to those who believed in me when I couldn’t,
A special thank you, I am forever grateful...

Alaeddine DAOUD
 Acknowledgements

First and foremost, I would like to thank God Almighty for giving me the strength, knowl-
edge, ability, and opportunity to undertake this internship and complete it. Without his
blessing, this achievement would not have been possible.

I would like to express my deepest gratitude and appreciation to all those who have
made this internship a rewarding and enjoyable experience.

I am particularly thankful to my supervisor in the Toulouse Computer Science Research

Institute (IRIT) laboratory Mrs. Meriem OUEDERNI, PhD in the ENSEEIHT, for her assis-
tance and valuable information and guidance throughout the project. Her contribution in
stimulating suggestions helped me to accomplish this humble work especially while writing
this report. I also would like to express my respect and my gratitude to her.

I would like to express my deep appreciation to my academic supervisor in the Higher

Institute of Computer Science and Multimedia of Sfax (ISIMS), Mr. Bassem BOUAZIZ for
his availability, encouragement, and motivation he has provided, which have pushed me to
achieve more than I ever thought possible. I am sincerely thankful for his support.

I am equally indebted to the entire Laboratory of IRIT in ENSEEIHT for the experience
and knowledge I gathered and for their warm welcome and the friendly environment pro-
vided.

Naturally, I express my sincere appreciation to the jury members: Mrs. Salma JAM-
MOUSSI and Mr. Mohamed TMAR for accepting to evaluate my work.

Finally, a special word of thanks is also expressed to my friends and family who of-
fered encouragement when needed. With their help in countless ways, I could complete this
project.
Contents

Introduction 1
Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Our main contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1 Background 8
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Model-Based Systems Engineering (MBSE) . . . . . . . . . . . . . . . . . . . . 9
1.2.1 Structural Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.2 Meta-models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.3 Level of Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.4 Domain Specific Language (DSL) . . . . . . . . . . . . . . . . . . . . . . 13
1.2.5 Models transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.6 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2.7 Abstract and concrete Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 Behavioral Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3.1 Labelled Transition System (LTS) . . . . . . . . . . . . . . . . . . . . . 18
1.3.2 LTS Interests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4 Signal synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.1 Physical Clock Synchronization . . . . . . . . . . . . . . . . . . . . . . . 21
1.4.2 Logical clocks synchronization . . . . . . . . . . . . . . . . . . . . . . . 23
1.4.3 Consistency in distributed applications . . . . . . . . . . . . . . . . . . 24
1.4.4 Synchronization in concurrent system approach . . . . . . . . . . . . . 24
1.4.5 Clock Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.4.6 Software as a service for signal synchronization . . . . . . . . . . . . . 26
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2 Model Driven Engineering (MDE) 28

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2 Model Driven Engineering for Internet of Things (MDE4IoT) . . . . . . . . . . 29
2.2.1 MDE techniques for IoT concepts . . . . . . . . . . . . . . . . . . . . . . 29
2.2.2 MDE for self-adaptive IoT systems . . . . . . . . . . . . . . . . . . . . . 30
2.2.3 Testing SCADA Systems Using the EMF and Modelica . . . . . . . . . 32
2.2.4 Service Oriented Architecture (SOA) approach . . . . . . . . . . . . . . 34
2.2.5 IoT modelling tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.3 Model Driving Engineering for Artificial Intelligence (MDE4AI) . . . . . . . . 41
2.3.1 Proposed approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.3.2 MDE for monitoring ML Models . . . . . . . . . . . . . . . . . . . . . . 48
2.4 Artificial Intelligence for Model Driven Engineering (AI4MDE) . . . . . . . . 51
2.4.1 Domain modeling with ML . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.4.2 Model-based systems engineering and Knowledge Representation . . 55
2.4.3 Crossover for Model-Driven Optimization . . . . . . . . . . . . . . . . 57
 2.4.4 Supporting Delay-Sensitive IoT Applications: A Machine Learning
Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3 Synchronization & Formal Verification 65

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.2 Formal Verification of IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.2.1 Formal Verification in reactive systems . . . . . . . . . . . . . . . . . . 66
3.2.2 Formal instantiation of MDE. . . . . . . . . . . . . . . . . . . . . . . . . 79
3.2.3 A Scalable Distributed Architecture Towards Unifying IoT Applications 84
3.3 Signal synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.3.1 Clock Synchronization Protocols . . . . . . . . . . . . . . . . . . . . . . 86
3.3.2 Globally Asynchronous Locally Synchronous GALS systems . . . . . . 90
3.3.3 Synchronous Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

4 Contributions 97
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.2 Case study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.3 General architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.4 Meta-model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.5 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.6 Model to Text (M2T) Transformation . . . . . . . . . . . . . . . . . . . . . . . . 105
4.6.1 Idsl2Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.6.2 Idsl2Lotos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4.7 Prototype Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.7.1 Idsl2Python Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.7.2 Idsl2LotosNT Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.7.3 Similation-Based framework . . . . . . . . . . . . . . . . . . . . . . . . 116
4.8 Integration of AI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.8.1 AI for MDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.8.2 MDE for AI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
4.9 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.10 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.11 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Conclusion 121
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Achievements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
List of Figures

1.1 Bridging the requirements gap . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2 Evolution of software development [11] . . . . . . . . . . . . . . . . . . . . . . 11
1.3 Meta-modeling a real-world objects . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Meta model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5 MOF modeling levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.6 Transformation steps in Model-Driven Architecture . . . . . . . . . . . . . . . 14
1.7 Abstract syntax tree example [160] . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.8 Clock skew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.9 Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.10 Clock drift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.11 Stratums levels [161] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.12 Clock Synchronization: Cristian’s Algorithm . . . . . . . . . . . . . . . . . . . 22
1.13 Clock Synchronization: Berkeley Algorithm . . . . . . . . . . . . . . . . . . . . 23
1.14 Mutexes and locks [162] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.1 Map of MDE techniques with IoT concepts [75] . . . . . . . . . . . . . . . . . . 30

2.2 IoT systems as Self-Adaptive Systems [33] . . . . . . . . . . . . . . . . . . . . . 30
2.3 MDE4IoT framework [33] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4 Portion of the Smart Street Lights Model [33] . . . . . . . . . . . . . . . . . . . 32
2.5 SCADA Testing Framework using EMF [78] . . . . . . . . . . . . . . . . . . . . 33
2.6 MDE based methodology to IoT applications deployment [28] . . . . . . . . . 34
2.7 M2M transformation rules [28] . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.8 OSGI Reactive Microservices for IoT [82] . . . . . . . . . . . . . . . . . . . . . 36
2.9 Reactive Microservices Infrastructure [82] . . . . . . . . . . . . . . . . . . . . . 37
2.10 Smart Water Scenario [82] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.11 ECore Model of the Proposed Tool [24] . . . . . . . . . . . . . . . . . . . . . . . 39
2.12 Comparisson between EMF tool and IoT Modeling Tool [24] . . . . . . . . . . 39
2.13 DSL-4-IoT GUI [84] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.14 The state machine Viewpoint [88] . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.15 Workflow of ML-Quadrate [89] . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.16 State machine modeling the behavior of a Smart Air Conditioner based on the
room temperature [90] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.17 Domain Meta-Model [94] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.18 Generated Artifacts [94] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.19 Relations between a meta-model, model, and object graphs [96] . . . . . . . . 52
2.20 Meta–meta-model [96] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.21 Schematic representation of a microlearning unit [96] . . . . . . . . . . . . . . 53
2.22 Workflow, resources, and actors for the implementation of the approach [97] . 57
2.23 Meta-model for the CRA case [103] . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.24 Two solution models E and F of the CRA case and their offspring O1 and O2
generated by applying crossover [103] . . . . . . . . . . . . . . . . . . . . . . . 58
2.25 Cumulative approximation sets of selected algorithm variants for model D [103] 59
2.26 Proposed priority queueing model [104] . . . . . . . . . . . . . . . . . . . . . . 60
2.27 Incorrect grouping of models in clusters [106] . . . . . . . . . . . . . . . . . . . 61
2.28 Algorithm execution starting with a fault tree model [106] . . . . . . . . . . . 62

3.1 Execution schema of a reactive system . . . . . . . . . . . . . . . . . . . . . . . 67

3.2 Real-Time reactive system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.3 Synchronous languages for reactive systems . . . . . . . . . . . . . . . . . . . 68
3.4 Sitemap of the Proposed Web-based Visualization Tool [116] . . . . . . . . . . 70
3.5 Multi-threaded TeleoR architecture [119] . . . . . . . . . . . . . . . . . . . . . . 72
3.6 Details of the hardware and software of the TR node [119] . . . . . . . . . . . 73
3.7 TR program editor implemented using Eclipse, Xtext and Xtend [117] . . . . . 74
3.8 ECG Waves and Their Relation to Heart Nodes [124] . . . . . . . . . . . . . . . 75
3.9 ECG Signal Specifications [124] . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.10 ECG Waves Behaviors [124] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.11 Architectural Framework for Thing as a Service [127] . . . . . . . . . . . . . . 79
3.12 EMFtoCSP architecture [128] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.13 Meta-model for Entity-Relationship diagrams and OCL invariants constrain-
ing the choice of identifier names [128] . . . . . . . . . . . . . . . . . . . . . . . 81
3.14 Comparing all meta-models experiments results [132] . . . . . . . . . . . . . . 83
3.15 A layered architecture for the Internet of Things [138] . . . . . . . . . . . . . . 84
3.16 Functionalities and work-flow of an observer [138] . . . . . . . . . . . . . . . . 85
3.17 A diagram of circular mapping in NTP hierarchy. The GNTP server can be
installed anywhere according to the demand [144] . . . . . . . . . . . . . . . . 87
3.18 Comparison of drift characteristics of different Arduino devices (left) and
the same Arduino device under different ambient temperatures (middle) and
comparison of Allan deviation plots of Arduino devices 1 and 3 and Pi3 (right)
[144] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.19 Architecture of the GRL model of an autonomous car [109] . . . . . . . . . . . 92
3.20 Overview of the derivation of synchronous test scenarios by projection and
exploration of an asynchronous complete test graph CTG [109] . . . . . . . . . 93

4.1 General Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

4.2 IoTFramework Meta-model: Association with Interfacers . . . . . . . . . . . 100
4.3 IoTFramework Meta-model: Integrity of data through various components . 101
4.4 Word suggestions for iDSL language . . . . . . . . . . . . . . . . . . . . . . . . 102
4.5 Model conform to meta-model using ".idsl" xText syntax . . . . . . . . . . . . 103
4.6 XMI model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.7 Meta-model constraints OCL file . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.8 Model to Languages with Acceleo . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.9 Synchronizer Interfacer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
4.10 Synchronization of the EEG signals and ECG signals . . . . . . . . . . . . . . . 109
4.11 CADP Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.12 Extracting behavior from Python code . . . . . . . . . . . . . . . . . . . . . . . 114
4.13 Expected EEG process behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.14 Generation of LTS within a single LNT file . . . . . . . . . . . . . . . . . . . . 115
4.15 Generation of LTS of smart thing Buffer . . . . . . . . . . . . . . . . . . . . . . 115
4.16 Non-interpretable LTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.17 AI4MDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
4.18 MDE4AI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.19 GitHub project Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
List of Tables

2.1 Comparative Analysis of Proposed Tool with existing state-of-the-art tools

and testbeds [82] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.2 Compared ML-Quadrat with other works [89] . . . . . . . . . . . . . . . . . . 42
2.3 The scores of the 4 evaluators [89] . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.4 Comparison of established deep learning frameworks and languages, ✓: yes,
P: partially, -: no, : depending on chosen backend, *: provided by extensions.
[93] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.5 MontiAnna vs. ML-Quadrat [92] . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.6 Loading time and profiling time in seconds [96] . . . . . . . . . . . . . . . . . 55
2.7 Mean normalized hypervolume of selected algorithm variants [103] . . . . . . 59
2.8 Simulating delay requirements of the proposed IoT applications [104] . . . . . 60
2.9 GMFL evaluation results [106] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.10 Results of cross-validation and neural network accuracy [106] . . . . . . . . . 63

3.1 Comparison of dT-Calculus with other algebras by the IoT characteristics [115] 69
3.2 Comparision of the different approaches for model generation [132] . . . . . . 83
3.3 Comparison among Architectural Proposals [138] . . . . . . . . . . . . . . . . 86
3.4 Comparison between different existing protocols with GNTP protocol [144] . 86
3.5 Comparison of synchronization RMSE (ms) values at different noise levels [144] 90
3.6 Comparison of offset error statistics under high noise level [144] . . . . . . . . 90
3.7 Sizes and run-time performance for the tests generated for the test purposes
[109] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.8 LOTOS NT definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

4.1 Summary of Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

4.2 Iterations of the generated LNT code . . . . . . . . . . . . . . . . . . . . . . . . 116
4.3 Comparison of Our Approach with Other Works . . . . . . . . . . . . . . . . . 118
4.4 Summary of literature and our approach . . . . . . . . . . . . . . . . . . . . . . 119
ACP Algebra of Communicating Processes
AI Artificial Intelligence
AI4MDE Artificial Intelligence for Model Driven Engineering
ANN Artificial Neural Network
API Application Programming Interface
ARU Area Reference Unit
AST Abstract Syntax Tree
BPMN Business Process Model and Notation
CADP Construction and Analysis of Distributed Processes
CCS Calculus of Communicating Systems
CIM Computation Independent Model
CPS Cyber-Physical System
CRA Class Responsibility Assignment
CSP Communicating Sequential Processes
CSS Cascading Style Sheets
DA Data Analytics
DAML Data Analytics and Machine Learning
DSL Domain Specific Language
DSL4IOT Domain Specific Language for Internet of Things
DSML Domain Specific Modeling Language
EC Emergent Configuration
ECA Event Condition Action
ECG Electro Cardio Gram
EEG Electro Encephalo Gram
EGL Epsilon Generation Language
EHR Electronic Health Record
EMF Eclipse Modeling Framework
EMG Execution Model Generator
ENSEEIHT École Nationale Supérieure d’Électrotechnique d’Électronique d’Informatique
d’Hydraulique et des Ttélécommunications
ESB Enterprise Service Bus
FIFO First In First Out
FSM Finite State Machines
GALS Globally Asynchronous Locally Synchronous
GMF Graphical Modeling Framework
GMFL Greedy Methodology for Fast Labelling
GPL General Purpose Language
GUI Graphical User Interface
IDE Integrated Development Environment
IDL Interface Definition Language
IoT Internet of Things
IRIT Institut de Recherche en Informatique de Toulouse
ISIMS Institut Supérieur d’Informatique et de Multimédia de Sfax
ISO International Organization for Standardization
JSON JavaScript Object Notation
LNT Lotos New Technology
LOTOS Language Of Temporal Ordering Specification
LSL Lab Streaming Layer
LTS Labelled Transition System
M2M Model to Model
M2T Model to Text
MARTE Modeling and Analysis of Real-Time and Embedded Systems
MBSE Model-Based Software Engineering
MDA Model Driven Achitecture
MDD Model Driven Development
MDE Model Driven Engineering
MDE4AI Model Driven Engineering for Artificial Intelligence
MDE4IOT Model Driven Engineering for Internet of Things
MDO Model-Driven Optimization
MDSE Model Driven Software Engineering
MIF Model Interchange Formats
ML Machine Learning
MNIST Modified National Institute of Standards and Technology database
MOF Meta Object Facility
MQTT Message Queuing Telemetry Transport
NTP Network Time Protocol
OCL Object Constraint Language
OMG Object Management Group
OML Ontological Modeling Language
OSGi Open Service Gateway iniative
OSI Open Systems Interconnection
OWL Web Ontology Language
PDL Process Description Language
PIM Platform Independent Model
PSM Platform Specific Model
PTP Precision Time Protocol
RMS Root Mean Square
SCADA Supervisory Control And Data Acquisition
SE Software Engineering
SOA Service Oriented Architecture
SQL Structured Query Language
SUT System Under Test
SysML System Modeling Language
T2M Text to Model
TA Task Automation
UML Unified Modeling Language
VSB eVolution Service Bus
VDSL Visual Domain Specific Language
WRSA Westinghouse Rail Systems Australia
WSN Wireless Sensory Network
XMI XML Metadata Interchange
Introduction

Contents
Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Our main contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1
Context
In the rapidly evolving aspects of technologies, the Internet of Things (IoT) has become a pow-
erful tool that reshapes the way we interact with our surroundings, due to its ability to merge
physical devices, software, and data networks into a unified system. Moreover, the devices in
IoT systems lead to a new generation of efficiency and automation especially with the inter-
vention of Artificial Intelligence (AI) as it makes sense of the vast amount of data generated by
these devices and enables them to make intelligent decisions and take actions autonomously.

The marriage of AI and IoT creates a synergy that drives innovation across numerous domains
such as smart homes, smart cities, healthcare, and industrial automation. Within these fields,
we place particular emphasis on the healthcare domain, which necessitates a robust real-time
system due to the critical nature of patient well-being where timely responses can mean the
difference between life and death. Electronic health records (EHRs), telemedicine systems,
and surgical robots also demand strict real-time performance to maintain patient safety and
provide effective healthcare services. Additionally, in these systems, maximum precision is
required in the data collection phase, which leads to more valuable results and enhances pa-
tients’ diagnoses.

Even though these systems are very strict and vigilant against errors that could lead to catas-
trophes, healthcare systems have been revolutionized due to the suitable infrastructure and
the advancement of distributed systems, resulting nowadays a multitude of applications. A
significant application in these systems is remote patient monitoring, where smart devices like
wearable fitness trackers, blood pressure monitors, and glucose monitors continuously track
patients’ data in their homes. This data is transmitted to healthcare providers, facilitating early
intervention and improving the management of chronic conditions such as diabetes, heart dis-
ease, and asthma. Moreover, these data can be combined with artificial intelligence algorithms,
empowering healthcare systems with predictive analysis, and offering insights into disease
trends and patient outcomes for informed decision-making and future healthcare planning.
Despite the significant advancements in healthcare technologies, certain aspects still lag, and
traditional methods persist in certain areas. One notable example is how doctors interpret
electroencephalogram (EEG) and electrocardiogram (ECG) signals independently where de-
vices operate independently, and generate huge volumes of data leading to overload devices’
capabilities and inefficient resource utilization, such as energy, bandwidth, and computational
power which may make the professionals waste time in their interpretation, rather than utiliz-
ing more integrated approaches. Also, handling events and triggers in an asynchronous envi-
ronment can increase complexity and can affect automation and decision-making processes.
Consequently, the absence of synchronization between these devices in a healthcare system
can indeed be a significant problem. The misalignment of the data streams can make it chal-
lenging for professionals to correlate events or anomalies in both signals accurately.
Medical researchers often rely on the simultaneous analysis of the data of smart devices to
make informed decisions. For example, in the presented case above, knowing the exact timing
of EEG signals with ECG signals can influence whether medication or other interventions are
necessary.

Asynchronous data can lead to missed correlations between brain activity and heart rhythms,
potentially resulting in an inaccurate diagnosis and limiting the development of effective treat-
ment strategies which can prevent the creation of comprehensive patient profiles. Without
proper synchronization, this data can become inconsistent, making it difficult to analyze and
derive meaningful insights. Also, asynchronous data arriving out of synchronization might be
more susceptible to unauthorized access.

2
However, to address these issues, some attempts were implemented to have synchronization
mechanisms like timestamps, communication protocols, and data synchronization services to
ensure that data from various devices are synchronized. Yet, in healthcare systems, it is im-
portant to validate the reliability of synchronization since the data is sent from devices concur-
rently. That’s why we need to analyze the system’s behavior, typically using formal verifica-
tion, to check whether synchronization is handled correctly or not.

In particular, the integration of software engineering into IoT systems in the last few years
has proven to be a revolutionary development. This event results in the creation of software
such as desktop applications and software as a service over the internet to prototype and de-
sign IoT systems. They ensure the avoidance of the traditional IoT systems development that
requires a significant amount of time during the implementation phase.

Within this context, software engineering has evolved to employ alternative methods to en-
capsulate the vast domain of IoT. One such approach is Model-Driven Engineering (MDE),
which holds the potential to greatly assist developers in tackling complex IT challenges.
One of the key components in MDE is Domain-Specific Languages (DSLs) which are designed
to express domain-specific concepts and ensure that developers capture domain-specific knowl-
edge and requirements in a more intuitive and precise manner, facilitating a smoother transi-
tion from high-level abstractions to concrete code and system configurations. This contributes
to the effectiveness of MDE as a methodology for IoT software development by offering a
means to represent and manipulate domain-specific information effectively. Also, MDE has
proven to be a solid method for tackling various AI tasks where some developed tools are
using this approach, to facilitate the process of creating AI models. Furthermore, The usage
of Graphical User Interface (GUI) including shortcuts, charts, and graphs has significantly
enhanced the accessibility and usability of these platforms. This combination of MDE princi-
ples with user-friendly interfaces not only accelerates the AI model creation process but also
ensures a deeper understanding of the theoretical foundations leading to more robust and ef-
fective AI solutions. Unlike traditional AI implementation, which can be challenging, MDE
offers the potential for consistently achieving pure functional AI models. This advantage is
particularly beneficial in IoT systems, as it simplifies the complexities of AI integration.

In the context of using MDE for the IoT (MDE4IoT), we have identified an exciting oppor-
tunity to explore two other research domains. The first one, known as MDE for AI (MDE4AI),
introduces the capability to construct AI models and algorithms directly from the generated
code using models that are compliant with their respective meta-models. This approach holds
that MDE facilitates the integration of AI techniques into software development and allows
the automation and enhancement of various tasks in AI fields.

The second is AI for MDE (AI4MDE) which focuses on the challenging yet crucial domain
of using AI within the MDE framework. It requires a strong knowledge of algorithms and
expertise to ensure that AI can generate models that align with meta-models and possess self-
improving, self-adaptive, and context-awareness capabilities when needed. In contemporary
research, we discovered that integration of AI within MDE enhances the adaptability and in-
telligence of software that is built using MDE. Also, these research fields have found appli-
cations in various domains, and we are currently exploring their implementation in a generic
healthcare system as part of our project. Given the specific requirements and complexities of
healthcare systems, we see that these research domains have the ability to automate, optimize,
and enhance healthcare system functionalities and consequently, have a significant impact on
patient care and the healthcare field as a whole.

3
Particular problems are considered in IoT systems such as the heterogeneity of devices in terms
of different capabilities, power requirements, the diverse range of operating systems, and pro-
gramming languages that are used to develop the desired distributed applications. To over-
come these problems, DSLs can be designed to facilitate such interoperability by providing
high-level language and allowing domain experts to quickly model and test ideas without get-
ting bogged down in the complexity of general-purpose languages (GPLs).
Furthermore, in the healthcare domain, DSLs can offer numerous advantages such as enhanc-
ing patient safety by performing specific rules and constraints at the language level, enhancing
compliance, and minimizing the chances of programming errors. Additionally, they establish
standardized data formats and communication methods, ensuring effortless interoperability
with EHRs.

Besides that, DSLs can bridge the gap and enable collaboration between technical develop-
ers and healthcare professionals, making it easier for healthcare staff to define clinical proto-
cols and simplify system maintenance by expressing high-level specifications or models using
the abstraction of low-level technical details of the system. This streamlining of development
processes allows for faster response to evolving healthcare needs and ensures domain experts
work with concepts closer to their area of expertise even if they lack extensive knowledge
in development firstly thanks to the code generation techniques that automatically transform
DSLs’ specifications into reliable, error-resistant code or artifacts and secondly thanks to DSLs
explore not only textual but also graphical or visual interfaces (VDSL) options.

Building upon this foundation, the primary goal of the internship is to develop a healthcare
framework using the MDE approach and propose a robust DSL, which we believe will make a
substantial contribution to this field. Our approach includes practical implementation in real-
world case studies, with a particular emphasis on two specific medical sensors, namely, EEG
and ECG. Additionally, we aim to synchronize the data streams from these medical sensors
and validate the correctness and reliability of the framework’s behavior. As we see the great
enhancement in other research on the usage of DSLs in various contexts and domains of IoT
systems, DSL might be also, the right choice for healthcare systems regarding the specific re-
quirements that are not easily met by general-purpose languages.
For instance, in this work, we create a high-level abstract model (meta-model) of the system.
This model should capture essential aspects of the system’s functionality and interactions. We
try to enforce this model with constraints and check specifics in the healthcare domain. Also,
we try to use the DSL features such as creating specialized tooling, editors, and code generators
that make development more efficient and ensure a lower learning curve for domain experts
who may not be proficient in general-purpose programming. Our work contains the genera-
tion of Python code which is designed for medical devices, integrating data synchronization
capabilities. In addition, we create a formal verification language called LOTOS NT and uti-
lize the CADP toolbox, which can produce Labeled Transition Systems (LTS) from LOTOS NT
code, to verify the system’s behavior. This verification process ensures the correctness of the
system, including synchronization, and checks for the absence of any deadlocks.

We hold a strong sense of optimism regarding this opportunity, particularly due to the promis-
ing synergies of AI and MDE, and AI and healthcare systems. This first combination presents a
brilliant concept with the potential to address numerous challenges during software develop-
ment where the targeted systems have models that are not only based on existing knowledge
but also capable of learning and adapting to new data, improving their predictive capabilities,
updating and refining based on the incoming data and user behavior. On the other hand, the
second combination offers substantial benefits in a domain that demands AI algorithm inte-
gration, such as classification and prediction for patient services.

4
Our main contributions
In this project, we address the inherent complexities of IoT systems characterized by diverse
criteria such as technologies, programming languages, and device configurations. Our sig-
nificant contribution to this project centers around the creation of a DSL targeted specifically
for IoT systems. This language is designed to meet the unique needs of domain profession-
als, offering a more intuitive and targeted approach compared to general-purpose languages
that often deviate from specific requirements. The primary goal is to extract essential IoT sys-
tem requirements, bridging the gap between various technologies, languages, and traditional
development by using model-driven engineering principles such as meta-modeling, model
transformation, and operating at a higher level of abstraction.

Our project integrates various domains into a generic framework represented in a particular
healthcare application featuring EEG and ECG medical sensors. In the development of IoT
systems, we investigated that (MDE4IoT) can address the substantial knowledge, time, and
technology specifications these systems demand. Recognizing the extensive knowledge, time,
and technology specifications required for these systems, we have observed that abstraction
within MDE proves beneficial in simplifying the creation of complex systems. This is partic-
ularly evident in the development of graphical user interfaces (GUI), where abstraction and
the visual interface enhance the efficiency and smooth the creation of these systems. Besides
that, this approach allows for a comprehensive understanding of complex interactions and
improves overall IoT systems. Unlike previous studies, our work explores the fusion of AI
and MDE, creating a good synergy relationship that empowers users to deploy AI algorithms
seamlessly. The integration of AI into MDE (MDE4AI) facilitates user-friendly customization
of AI model settings without requiring an in-depth understanding of AI model development.
Alternately, when MDE is integrated into AI (AI4MDE), machine learning algorithms ensure
the automated generation of models that conform to their meta-models, addressing user pref-
erences effectively. Addressing the widespread challenge of synchronization within IoT sys-
tems, we identified two key synchronization aspects: data synchronization from medical de-
vices and system behavior synchronization. In the context of data synchronization, various
algorithms and protocols are typically employed. However, in our framework during the pro-
totype phase, we adopted the GALS (Globally Asynchronous Locally Synchronous) system
concept. In this approach, medical devices generate data asynchronously and independently
send it to the monitor without a common clock. Subsequently, we synchronize the data locally
on the monitor using timestamps, FIFO queues, and buffers. As for the system behavior, we
employ formal verification methods, using mathematical instructions to identify potential is-
sues such as deadlocks and avoid the wrong system behavior. To ensure reliability in systems
developed by users who lack expertise in programming, we employ the LOTOS NT formal
verification language to confirm that the created model aligns with the intended functionality,
making a way for the future evolution of the project.

In this work, we develop a meta-model in Eclipse Modeling Framework (EMF) that serves as
a foundation for instantiating models adhering to its specifications. Utilizing a meta-model
proves particularly advantageous in domains like IoT, where smart devices come with diverse
specifications such as varying technologies, legacy device compatibility issues, and program-
ming language disparities. Meta-modeling serves as an important solution, allowing us to
treat all devices as a commun entity, thereby simplifying the overall workflow. To enhance the
robustness of this meta-model, we employ the Object Constraint Language (OCL). By incor-
porating OCL, we introduce invariants and constraints that render the created models more
aligned with the specific requirements, further optimizing their suitability for the intended
purposes. Using the established meta-model, the DSL was introduced by Xtext to create the

5
concrete syntax of the language. This approach simplifies the experience for end-users, en-
abling them to seamlessly instantiate medical devices with specific parameters. Users can
easily control data flows, define system behavior, and select necessary interfacers, such as
synchronizer interfacer for data synchronization and preprocessor interfacer for data cleaning.
This streamlined DSL empowers users to efficiently configure and manage the intricate aspects
of the system, enhancing overall usability and customization.

Additionally, we undertake MDE transformation using Acceleo to convert models to text

(M2T). Models that have been verified and aligned with the established meta-model are trans-
formed into both Python and LOTOS code. We have defined two distinct projects: iDSL2Python,
where a template is created to generate targeted code for devices, and iDSL2Lotos, aimed at
generating LOTOS code and verifying the LTS graph using the CADP toolbox to verify the
correctness of system behavior and ensure the absence of deadlocks. We conduct testing on
the generated code through several iterations. The Python code performs well and will be en-
hanced in future development, including the integration of AI algorithms. Also, data synchro-
nization for medical devices presents a good outcome. However, with the generated LOTOS
NT code, we face challenges in the implementation. Simulating system graphs with Petri nets
and extracting system behavior necessitates an in-depth understanding of LOTOS syntax and
process algebra. Currently, our focus is on streamlining the process by reducing the number of
transitions to enhance the interpretation of the generated graph.

Outline
The structure of this report is organized into four distinct chapters, each serving a specific pur-
pose in presenting our research findings and insights.

The first chapter, titled "Background" delves into the essential groundwork required to un-
derstand the core concepts of the research. In this section, we present an in-depth exploration
of MDE and signal synchronization, including its significance and relevance in the context of
the internship. Additionally, we discuss the structural and behavioral models that form the
foundation of the research, providing readers with the necessary theoretical aspects to com-
prehend the subsequent chapters.

The second chapter focuses specifically on "Model-Driven Engineering (MDE)", providing

a detailed examination of its principles, practices, and application in various domains like
MDE4IoT, MDE4AI, and AI4MDE. It explores the impact of MDE on software development
and system design, serving as a bridge between theoretical concepts and practical implemen-
tation.

The third chapter, titled "Synchronization and Formal Verification," delves into synchroniza-
tion techniques and formal verification methods. It explores the significance of synchroniza-
tion and formal verification in distributed systems, offering insights into current trends and
methodologies in these areas.

The fourth chapter, titled "Contribution" is the core of this thesis, where we present the origi-
nal research and contributions we have made during the internship. This chapter delves into
the innovative solutions, methodologies, and insights that have emerged from our work, high-
lighting the development of the prototype, the used meta-model, and the application of the
model to text transformation techniques. Also, we present the implementation of the formal
verification language LOTOS NT and the interpretation of the system behavior from the gen-
erated LTS and finally, we illustrate the results we found in this internship.

6
Finally, we will wrap up the thesis by summarizing the key findings, achievements, contri-
butions, and their implications. Also, we will provide insights into potential future research
directions, emphasizing the significance of the internship and its potential impact on the field.

7
Chapter 1

Background

Contents
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Model-Based Systems Engineering (MBSE) . . . . . . . . . . . . . . . . . . . . 9
1.2.1 Structural Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.2 Meta-models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.3 Level of Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.4 Domain Specific Language (DSL) . . . . . . . . . . . . . . . . . . . . . 13
1.2.5 Models transformations . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.6 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2.7 Abstract and concrete Syntax . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 Behavioral Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3.1 Labelled Transition System (LTS) . . . . . . . . . . . . . . . . . . . . . 18
1.3.2 LTS Interests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4 Signal synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.1 Physical Clock Synchronization . . . . . . . . . . . . . . . . . . . . . . 21
1.4.2 Logical clocks synchronization . . . . . . . . . . . . . . . . . . . . . . 23
1.4.3 Consistency in distributed applications . . . . . . . . . . . . . . . . . 24
1.4.4 Synchronization in concurrent system approach . . . . . . . . . . . . 24
1.4.5 Clock Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.4.6 Software as a service for signal synchronization . . . . . . . . . . . . 26
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

8
1.1 Introduction
In this chapter, we lay the foundational groundwork essential for a comprehensive under-
standing of the subject matter addressed in this master thesis. We will delve into the essential
background knowledge required to navigate the complexities of our research. This includes
an exploration of structural models using meta-models within the MDE approach, an exami-
nation of behavioral models, and a rigorous analysis of signal synchronization.

1.2 Model-Based Systems Engineering (MBSE)

1.2.1 Structural Model
Structural Model [1, 2] focuses on representing the static aspects of the system and describes
the composition, organization, and relationships between the various components and entities
within the system. These models are used to understand and document the system’s structure
and do not typically capture dynamic aspects like behavior or functionality.
One of the most famous modeling languages is Unified Modeling Language (UML) [3, 4]
which has become an essential tool for software architects, designers, and developers. It pro-
vides a standardized way to represent the architecture and design of software systems and
ensures various types of diagrams to capture different aspects of a system such as class dia-
grams, object diagrams, and component diagrams, enabling software professionals to create
visual representations of a system’s structure and relationships among its components. These
diagrams serve as a common ground for communication among team members and stake-
holders, making it easier to understand and document the complexities of the system.
In recent years, the field of software engineering has faced numerous challenges. The integra-
tion of diverse technologies, rapidly changing user requirements, the evolution of distributed
and cloud-based architectures, and the increasing demands for scalability and performance
have made system design more complex than ever before. UML has evolved to address these
challenges. The UML standard has been updated and extended with new versions and profiles
to accommodate the changing landscape of software development. UML 2.0 [5, 6], released
in 2005, introduced several improvements and refinements to the language, making it more
adaptable to modern software engineering practices. Subsequent versions and profiles, such
as UML 2.5 [7], have further enhanced UML’s capabilities to address the needs of contempo-
rary software development.
Despite the advancements and progress in software development, a notable challenge that
often arises during the implementation phase is the need to implement software using a low-
level programming language that mismatches the real specific requirements needed. To ad-
dress this issue, it would be beneficial to have a way to express the solution, and even the
requirements themselves, using a model that directly relates to the concepts within the prob-
lem domain. This is where MDE [8, 9] comes into play. It facilitates the creation of intermediate
languages or models that enable the use of problem-domain concepts to specify a model. By
bridging the gap between the problem domain and the implementation [10], MDE allows for
a clearer and more direct representation of the software solution, enhancing the verification
of requirements and improving the overall software development process. Figure 1.1 presents
how MDE helps to bridge the requirements gap :

9
 Requirements Requirements Requirements

Manully Manully Manully

Impement Impement Impement

High level
specification
Functional and
nonfunctional

Source in DSL Source in DSL

Domain Specific Domain Specific
Language Language

Compile Compile

may may
Source in GPLs
Generate Code Generate Code
(java, C++)
(java, C++) (java, C++)

Compile Compile Compile

Implementation Implementation Implementation

Figure 1.1: Bridging the requirements gap

Softwares Development. Traditional software development methods that rely on manual cod-
ing in 3rd generation languages like C++ and Java come with many drawbacks. One signifi-
cant disadvantage is the manual coding overhead, where developers have to write code line by
line, leading to potential errors and inefficiencies and slowing down the development process,
especially for large-scale projects. Learning and mastering programming languages and tools
can be time-consuming.
Moreover, the low abstraction level of manual coding makes it harder to understand the over-
all system requirements and may tie the software to a specific platform, making it challeng-
ing to migrate or adapt to new technologies. Also, maintaining and updating code manually
becomes increasingly challenging as the software grows in complexity, leading to increased
maintenance effort.
Furthermore, manual coding can result in bugs and security vulnerabilities and limited auto-
mated verification and validation tools can lead to potential issues not being detected early in
the development process. From another perspective, non-technical stakeholders might find it
harder to actively participate in the development process due to the technical complexity of
software development.
The evolution of software development [11, 12] has seen a transition from 3rd generation pro-
gramming languages, which were closer to machine code and hardware, to Structured Pro-
gramming, which introduced the concept of modular and organized code through constructs
like loops and functions. This further evolved into Component-Based Software Engineering,
emphasizing the reuse of pre-built components to enhance development efficiency and main-
tainability. MDE leveraged abstraction and independence by allowing developers to create
high-level models of software systems, which could then be automatically transformed into
executable code. This shift (c.f. Figure 1.2) emphasizes the separation of concerns, enabling
developers to focus on system design and logic while the tools handle the technical details,
ultimately streamlining software development and reducing complexity.

10
 Independence
Abstraction Model-Driven
Engineering

Component-Based
Software Engineering

Structured programming

3rd generation languages

Figure 1.2: Evolution of software development [11]

1.2.2 Meta-models
Meta-modeling in MDE (c.f. Figure 1.3), revolutionized the way software systems are designed
and developed. At its core, meta-models [13, 14] serve as the backbone of MDE and define the
structure, relationships, constraints, and semantics of models within a specific domain. They
provide a formal foundation for creating domain-specific modeling languages (DSMLs) [15]
and facilitating the construction of well-formed and consistent models. Meta-models capture
the essential concepts, entities, attributes, relationships, and constraints relevant to the specific
domain, providing a structured vocabulary that models can adhere to. They define the build-
ing blocks and rules that guide the construction of valid models, ensuring that they accurately
represent the desired system and conform to predefined standards.
Meta-models are used to create DSLs targeted to specific application domains [16], enabling
domain experts to express their ideas in a way that is closer to their problem domain. Meta-
models are used as the basis for developing model transformation rules and tools that can
automatically generate code, documentation, or other artifacts from models, facilitating the
automation of development processes. Also, they provide the criteria for validating the cor-
rectness and consistency of models to ensure they conform to the intended domain-specific
semantics [17], ensuring model quality and reliability and they can evolve to accommodate
changes in domain requirements, supporting the adaptability and maintenance of existing
models.
Meta-models ensure a valuable technique used to design novel modeling languages and ex-
pand the capabilities of existing modeling languages by defining the abstract and concrete
syntax and semantics of models (c.f. Figure 1.4). Just as models are simplified representations
of real-world entities, meta-models can be seen as simplified representations of models. They
define the structure, constraints, and semantics of lower-level models used in the software de-
velopment process [18, 19]. As mentioned in [20, 21], expanding the abstraction further leads
to the concept of meta-meta-models, which are models that encapsulate descriptions about
meta-models, including statements about their properties.

11
 Meta-metamodel <<instanceOf>>

<<instanceOf>> <<instanceOf>>

Metamodel

<<instanceOf>> <<instanceOf>>

Model


<<instanceOf>>

Real world objects

Figure 1.3: Meta-modeling a real-world objects

Metamodel

Sementics Abstract Syntax Concrete Syntax

Figure 1.4: Meta model

1.2.3 Level of Abstraction

Abstraction is a fundamental concept in computer science that enables developers and re-
searchers to express their programs in terms of high-level designs rather than getting bogged
down in the complexities of underlying computer technologies and making development more
manageable and scalable.
While most software projects are currently written in GPLs (Java, C++), these languages may
not align perfectly with the specific problem domain, making development less efficient. MDE
follows the same approach by elevating the level of abstraction [18]. It allows developers to
work with models that represent the problem domain more closely. The traditional meta-
model architecture was defined by the Object Management Group (OMG) [22, 23], which de-
fines Meta Object Facility (MOF) standard that introduces four levels of abstraction (c.f. Fig-
ure 1.5 ). At the base M0, which represents the real-world entities. M1 represents the models
of the M0 entities. M2 contains meta-models, which provide the abstract definitions and a de-
scription of M1 entities, and finally, M3 represents the meta meta-model which describes the
M2. Notably, the M3 meta-meta-model is capable of self-description.

12
 conformsTo ▸
◂describe
Metametamodel M3 MOF
▲
describe conformsTo
▼ UML UML ...
Metamodel M2 2.0 2.0
▲
describe conformsTo
▼
UML UML ...
Model M1 model model
▲
representedBy

System M0

Figure 1.5: MOF modeling levels

1.2.4 Domain Specific Language (DSL)

Meta-modeling enables the creation of DSLs [18] which are programming languages specifi-
cally designed to solve problems within a particular domain or application area. Unlike GPLs,
DSLs are created to address specific tasks, optimizing efficiency and expressiveness within
their targeted domains.
DSLs make it easy for domain experts or non-programmers to write code that addresses the
particular challenges in their field. These languages typically provide abstractions, syntax, and
semantics that align closely with the problem domain, allowing users to express their inten-
tions more concisely and directly. As in previous works [24], authors present that IoT modeling
tools with DSL scored better than using EMF with UML.
The advantage of DSLs lies in their ability to provide a language that is closely aligned with
the problem domain, allowing developers to work more efficiently and effectively. In the study
conducted by Visser et al. [25], they highlight the role of SQL as a domain-specific language
(DSL) for managing database queries. SQL offers users the advantage of working with a well-
defined grammar and a structured notation for database interactions, simplifying the learning
and management of the database. DSLs can make code more maintainable by encapsulating
domain-specific knowledge and making it explicit. Changes to the domain can be reflected in
the DSL, simplifying updates and modifications. A good example is Cascading Style Sheets
(CSS) for web design, which is a DSL for specifying the style of web content.
Additionally, DSLs can enforce domain-specific constraints [26], ensuring that only valid con-
structs are used. This can help prevent errors and guide developers in the right direction.
DSLs can enable parallel development efforts, where experts in different domains can work
independently, as long as they adhere to the DSL’s specification. This can lead to faster de-
velopment cycles. For example, BPMN (Business Process Model and Notation) [27] is a DSL
used for modeling business processes, allowing different stakeholders to contribute to process
design.

1.2.5 Models transformations

In MDE, software development is approached through various levels of abstraction to facilitate
the design and implementation process [28, 29]. Relating to this approach are three types
of models (c.f. Figure 1.6): Computation Independent Model (CIM), Platform Independent
Model (PIM), and Platform Specific Model (PSM). These models, defined within the Model-

13
Driven Architecture (MDA) framework by OMG, serve distinct purposes.
Computation Independent Model (CIM). CIMs are high-level models that provide a concep-
tual view of the system, focusing on the requirements and environment without considering
system structure or processing details. These models are typically used for understanding the
business context, domain entities, and high-level interactions. CIMs help to ensure that the
software being developed aligns with the business goals and requirements.
Platform Independent Model (PIM). PIMs are models that specify the functionality and be-
havior of a system while remaining abstracted from any specific technology or platform. This
allows developers to capture the "what" of a system without yet defining the "how." A PIM
can later be transformed into one or more PSMs, which provide the platform-specific details
needed for actual implementation. This level of abstraction enables better reusability of the
model across different technology stacks.
Platform Specific Model (PSM). PSMs are models that combine the specifications in the PIM
with the details necessary for implementation on a specific platform. This includes platform-
specific data types, libraries, and other technology-specific constructs. The PSM is typically
what gets transformed into actual source code. It’s more closely tied to the underlying tech-
nology, making it less portable than a PIM but more straightforward to implement.

Functional Technical Operational

Requirements Requirements Documentation

Non Functional System

Requirements System Documentation
Requirements
Business Support
Rules Documentation
Constraints User
User Story
Documentation

CIM Skilled
Transformation PIM Automated
Transformation PSM CODE

Use case Class Diagram Component

Diagram Object Diagram Diagram

Activity Timing Diagram Package

Diagram Diagram
Interaction Diagram
Sequence Deployment
Diagram Communication Diagram Diagram

UML DIAGRAMS
Conceptualization Specification Realization

Figure 1.6: Transformation steps in Model-Driven Architecture

Transformation Process
The MDE approach typically involves transforming a CIM into a PIM where business require-
ments are turned into an independent technology model that specifies what the system should
do and then another transformation of PIM into a PSM where PSM incorporates all the tech-
nological specifics necessary for implementation. Finally, the PSM is usually used to generate
source code [29]. By examining these transformations, we can describe various aspects of
model transformations [30] below:

• Model-to-Model (M2M) transformation: This method allows the generation of new mod-

14
 els from existing ones. It consists of a set of rules that define how to map elements from
one model to another, allowing the transformation of models from one level of abstrac-
tion to another

• Model-to-Text (M2T) transformation: This method allows to generate executable code

from models. It consists of a set of rules that define how to transform a model into a spe-
cific programming language. This method is used in the last phase of the methodology
to generate the final code of the application.

• Text-to-Model (T2M) transformation: This method allows to generate models from tex-
tual specifications. It consists of a set of rules that define how to parse a text file and
transform it into a model.

Code generation. Code generation using DSLs [31, 32] is a common technique that trans-
lates a DSL model into actual code (GPLs, customized file extensions). By defining high-level,
domain-specific abstractions, DSLs allow developers to express their purpose more clearly
with high-level DSLs specifications which are transformed into low-level code that can be ex-
ecuted on a target platform. This technique can significantly improve productivity, reduce
errors, and ensure consistency in complex projects and tasks like software modeling and con-
figuration making DSLs a valuable tool for domain experts.
According to [33], MDE4IoT currently employs translational execution, where source models
are translated into GPLs. These translated models are then executed on the target device.

1.2.6 Semantics
Semantics in MDE [34, 35] ensure the correctness and meaning of models and their transforma-
tions, which are essential for the development of complex software systems. Semantics in MDE
refers to the formal description of the meaning and behavior of modeling languages, models,
and transformations. It provides a foundation for precise reasoning, verification, and valida-
tion of MDE artifacts, helping to bridge the gap between abstract models and their concrete
implementations. The choice of semantics for a modeling language or transformation language
greatly influences the reliability and predictability of MDE processes. Several approaches and
formalisms such as Meta-model-Based Semantics, have been proposed and applied in MDE
to establish a clear understanding of how models and transformations should behave. These
semantic foundations are essential for the success of MDE and have been the focus of extensive
research in the field.
Static semantics. Meta-models are a powerful means for defining semantics in MDE, but it’s
important to clarify that they are distinct from abstract syntax [36]. While abstract syntax de-
fines the structure of a modeling language, specifying the elements and their relationships, it
does not inherently carry the meaning of these elements. This is where static semantics comes
in and acts as an intermediary between syntax and the full semantics of a language [37, 38].
Static semantics ensures that a model or program is not only syntactically well-formed but
also semantically meaningful within the context of its language. In other words, it ensures
that a program, model, or transformation conforms not only to the syntactical rules but also to
the meaningful constraints and rules of the modeling language, making it semantically valid
within the language context before execution. This verification process helps prevent unin-
tended errors and inconsistencies in MDE artifacts. Below, we present some key insights on
the role of static semantics in MDE:

• Syntax: While syntax checks if the arrangement of symbols is correct, static semantics
checks if the arrangement makes sense. For instance, in many programming languages,
it’s syntactically correct to write int x = 5 .

15
 However, writing int 5 = x is syntactically correct but violates static semantics, as vari-
able names shouldn’t be numeric literals.

• Type Checking: A type checker ensures that operations and functions are applied to the
right kinds of values. For instance, it would prevent us from trying to divide a string by
a number.

• Scope and Binding: Another domain of static semantics is ensuring that identifiers (like
variable names) are used in the correct scope and are properly bound to their correspond-
ing values or functions.

• Relationship Rules: How different elements relate to each other, what kinds of relation-
ships are allowed, and so on. For instance, the meta-model may dictate that a "Teacher"
element can be related to multiple "Student" elements, forming a "teaches" relationship.

• Aids in Tooling: Static semantics help in creating better development tools. Integrated
Development Environments (IDEs) often use static semantic checks to provide real-time
feedback, auto-completion, and error highlighting to developers as they write code.

In the context of MDE, the Object Constraint Language (OCL) [39, 40] specifies constraints and
expressions on models. It provides a way to describe the invariants of models, pre-conditions,
and post-conditions for operations, as well as guard conditions. While a modeling language
primarily describes the syntax and fundamental semantics of a system, OCL enables the defi-
nition of supplementary rules and constraints that may not be visually represented within the
model itself. This functionality enhances the precision and comprehensiveness of the modeling
process by allowing the explicit description of complex constraints and logic that are essential
for the accurate representation and validation of model-based systems.

1.2.7 Abstract and concrete Syntax

When designing or understanding a language, especially in meta-modeling, it is crucial to
distinguish between the abstract syntax, which defines what things mean, and the concrete
syntax, which determines how they are visually represented. The abstract syntax serves as the
foundation for reasoning about the semantics and behavior of language constructs, supporting
various tools and transformations such as compilers or model transformations. On the other
hand, concrete syntax is responsible for the representation, ensuring human readability and
interaction. It is crucial in the implementation of parsers and compilers and often serves as the
primary interface for users who write code or create models in a DSL.

Abstract Syntax. Abstract syntax [18, 41] set the foundational structure of a language, pri-
marily focusing on its core components and semantics without being bound by any specific
representation. It primarily deals with the logical entities and their relationships. For instance,
as mentioned in [42] when considering a programming language, the abstract syntax is con-
cerned with constructs such as variables, functions, loops, and conditionals. A way to visualize
the abstract syntax is through the Abstract Syntax Tree (AST). The AST represents the hierar-
chical structure of a program, where each node corresponds to a language construct.
An expression like 4 + 2 × 10 + 3 × (5 + 1) would be broken down into an AST (c.f. Figure 1.7)
where multiplication has higher precedence, resulting in a tree with the + at the root and the
∗ operation as one of its children.

16
 Figure 1.7: Abstract syntax tree example [160]

Concrete Syntax. Concrete syntax [18, 43] is all about representation. It provides the tangible
form or the "look" of the language constructs, be it in textual or graphical shape. In the con-
text of a programming language, [42] mentions that concrete syntax determines the specific
keywords, symbols, and notations. Using the earlier mathematical expression as an example,
the concrete syntax dictates the specific symbols such as ×, +, and the order in which they are
written to make the expression understandable and ensure the ability to be analyzable.
For a loop in a programming language, while the abstract syntax represents the idea of itera-
tion, the concrete syntax will decide whether it looks like:

• for(i=0; i<10; i++)

• for i from 0 to 10

In this context, there are several frameworks available for defining the grammar of domain-
specific languages (DSLs). One such framework is xText [44, 45], which is commonly used to
define and generate concrete syntax for DSLs. In xText, we define the language’s grammar
using a formal notation. This grammar specification comprises syntax rules that outline the
structure of the language. These rules detail how various language elements, such as key-
words, identifiers, expressions, and statements, should be composed within the language.

1.3 Behavioral Model

Behavioral modeling is an essential step in the system design process, allowing designers to
understand and define the system’s expected behavior, which can then be used to guide im-
plementation and testing phases. Traditional models such as finite-state machines (FSM) [46],
Petri nets [47], and Labeled Transition Systems (LTS) [48] have historically been employed to
describe system behavior comprehensively. LTS provides a clear visual representation and
mathematical framework to analyze and reason about system behaviors, especially in scenar-
ios where parallel and concurrent processes or interactions are involved.

Deterministic and non-deterministic behavior. Deterministic behavior model [49] in which

the outcome of a particular action or event is predictable, given a specific initial state and input.
In deterministic systems, there is a unique and well-defined path of progression, with no un-
certainty or ambiguity in the transitions between states. This predictability is a key advantage
in fields like computer science, where deterministic algorithms ensure that the same inputs
always lead to the same outputs. On the other hand, non-deterministic behavior character-
izes systems where multiple outcomes are possible for a given input and state. Such systems
exhibit uncertainty or choice in their transitions, making it challenging to precisely anticipate
their behavior. Non-determinism is often used to represent aspects of randomness, choice, or

17
parallelism in real-world systems and is particularly relevant in fields like probabilistic mod-
eling, and concurrent programming, where it allows for a more flexible and expressive repre-
sentation of complex behaviors.

Synchronization, Concurrency, and parallelism in behavioral models. When dealing with

complex systems, understanding how concurrency, parallelism, and synchronization are rep-
resented within behavioral models becomes crucial [50]. Concurrency refers to multiple ac-
tivities occurring simultaneously, while parallelism involves executing tasks in parallel to im-
prove efficiency. Behavioral models must effectively capture these simultaneous activities and
their interactions, allowing for an accurate representation of how different components or pro-
cesses coordinate their actions. Synchronization mechanisms, such as semaphores, message
passing, or shared memory, manage concurrency and parallelism. Mastering the integration
of concurrency and synchronization in behavioral models is essential, as it ensures that the
system’s behavior is accurately presented, enabling the analysis and verification of concurrent
and parallel systems, which are ubiquitous in modern computing and engineering.

1.3.1 Labelled Transition System (LTS)

An LTS [48] is comprised of a collection of states and a set of transitions connecting those
states. Each transition is associated with a label, typically representing an action, and among
these states, one is marked as the initial state. Formally, in an LTS:

Definition 1. LTS definition :

• Let’s denote S as the set of states.

• Let’s denote A as the set of action labels.

• Let’s denote →⊆ S × A × S as the transition relation, where s → a s′ means there is a transition

from state s to state s′ labeled with action a.

• s0 ∈ S is the initial state

LTS typically characterizes the discrete behavior of a system or protocol. In any given state
of the system, various actions are possible, each resulting in a transition to a new state. The
initial state represents the system’s state before any actions are taken.

1.3.2 LTS Interests

• Reachability: a state s g is said to be reachable if there exists a sequence of transitions
that starts from an initial state s0 and leads to s g . Reachability analysis is often used
to determine which states can be reached from a given initial state. The sequence of
transitions that leads from s0 to s g it can be denoted as:

s0 → a1 s1 → a2 s2 → a3 ... → an s g

• Deadlock: A deadlock is a state in an LTS where the system cannot make any further
progress, typically because all possible transitions are blocked. A state s ∈ S is said to be
in deadlock if:
There is no a ∈ A and s′ ∈ S such that s → a s′ , there are no outgoing transitions from
state s. Detecting and avoiding deadlocks is an important concern in system design and
verification especially for reactive systems.

18
 • Safety and Liveness : An important observation is that any property can be decomposed
into a safety and a liveness part. That is:

P = Psafe ∧ Plive

Safety: Safety properties ensure that "nothing bad will happen." A property P is a safety
property if, for every finite execution sequence σ that does not satisfy P, there is a finite
prefix σ′ such that no extensions of σ′ satisfy P.
Liveness: Liveness properties guarantee that "something good will eventually happen."
A property P is a liveness property if for every finite execution sequence σ, there exists a
finite extension σ′ of σ such that σ′ satisfies P.

• Model Checking: Formal verification technique that aims to verify finite-state concurrent
systems where the behavior of a system is exhaustively explored to check whether it
satisfies specified properties.

1.4 Signal synchronization

Signal synchronization in IoT networks is a critical process that ensures efficient and reliable
communication between various devices. It involves coordinating the timing and frequency
of data transmission and reception to minimize errors, latency, and energy consumption. To
achieve effective signal synchronization, IoT systems typically employ various techniques such
as synchronization protocols and algorithms, which help devices maintain a shared sense of
time. This shared time awareness is essential for decreasing issues [51] such as clock skew
(c.f. Figure 1.8), which refers to the difference in the arrival time of the clock signal at various
components of a system, jitter (c.f. Figure 1.9), refers to the variability in the timing of the ticks
of a clock signal, and clock drift (c.f. Figure 1.10), which refers to the deviation of a clock from
its intended frequency or timing rate. We give below a brief presentation of these issues:

Clock Skew. As an example, for a given two registers A and B in a digital circuit , Let :

• TA be the arrival time of the clock signal at register A.

• TB be the arrival time of the clock signal at register B.

The skew (∆T) between registers A and B can be defined as:

∆T = TB − TA (1.1)
Where:

• If ∆T > 0, the clock signal reaches B after it reaches A.

• If ∆T = 0, there’s no skew, and the clock signal reaches both registers simultaneously.

• If ∆T < 0, the clock signal reaches B before it reaches A.

19
 Skew
0 5 10 15 20

A CLK

B CLK

Figure 1.8: Clock skew

Jitter. Jitter, Tj , is often defined as the deviation in the period of the clock from its ideal or
intended value. If Ti is the actual time interval between successive clock edges and T is the
ideal clock period, the jitter can be defined as:

Tj = Ti − T (1.2)
The measurement of jitter is often quantified using the Root Mean Square (RMS) value which
gives an effective measure of the deviation. For n clock cycles, if ji represents the jitter in each
cycle, the RMS Jitter is given as:
s
1 n 2
n i∑
RMS Jitter = ji (1.3)
=1

Jitter

Reference
edge Ideal
event
timing

Unit interval

Figure 1.9: Jitter

Clock Drift. When we talk about multiple clocks, each clock can have its drift rate due to fac-
tors such as temperature changes, and components aging. As an example, let:
t: Represents the real-time, or "true" time. It will be considered the reference or standard
against the measurements of other clocks.
C (t): Represents the reading of a clock. If the clock was ideal (perfectly synchronized with
real-time), then C (t)=t
dC (t)
dt : Represents the ticking rate of the clock (p). It’s essentially the rate at which clock (p) is
running relative to real-time.

dC (t)
• If dt = 1, the clock is ticking at the ideal rate: for every unit increase in real-time t,
clock (p) also advances by one unit.
dC (t)
• If dt > 1, the clock (p) is running faster than in real-time.
dC (t)
• If dt < 1, the clock (p) is running slower than in real-time.

20
 𝐝𝐝𝑪𝑪
>1
𝐝𝐝𝑡𝑡

𝐝𝐝𝑪𝑪
=1
𝐝𝐝𝑡𝑡

𝐝𝐝𝑪𝑪

C
<1
𝐝𝐝𝑡𝑡

Figure 1.10: Clock drift

1.4.1 Physical Clock Synchronization

Network Time Protocol NTP. Various approaches have been explored in this field to ensure ef-
fective synchronization. One such method involves establishing protocols like Network Time
Protocol (NTP) [51–53] to ensure all devices operate on a similar clock. NTP servers can syn-
chronize in three distinct modes, each with different use cases and levels of accuracy which
are: multicast mode [54, 55] used for LAN networks where servers broadcast time periodically
to workstations and then workstations adjust their clocks, Procedure-call mode [55] where
workstations request time from the server and performing greater accuracy than multicast
mode, and symmetric mode [55, 56] employed by high-level servers using a pair of servers ex-
changing messages containing timing information to synchronize their clocks accurately and
ensuring the most accurate among the three. Generally, This approach ensures the clients send
a request packet to a server, which responds with a response packet containing timestamps to
calculate round-trip (RT) delay and offset between the server and client clocks. Finally, based
on these calculations, the client adjusts its local clock. Also, the client can synchronize with
multiple servers and uses a selection algorithm to choose the best one based on factors like RT
delay, the level of stratum(c.f. Figure 1.11), and offset.

Figure 1.11: Stratums levels [161]

21
Stratum 1: Primary server (PS) synchronized directly with UTC sources.
Stratum 2: Secondary servers (SS) synchronized directly to PS.
Stratum 3: Lowest servers (LS) execute in user sites synchronized with SS.
Accuracy: the number of levers (strata).

Cristian’s and Berkeley algorithms. The core concept behind Cristian’s algorithm is that a
client initiates a time request to a server, which subsequently responds with the current times-
tamp, denoted as T. The client, in turn, receives the server’s response at time T ′ . As presented
in 1.12, the process begins with the client sending a request packet timestamped with its local
clock T1 and the server recording the reception time as T2 on its local clock. The server then
responds with a packet marked with timestamps T2 and T3 on its local clocks, and the client
registers the receipt of the server’s response as T4 on its local clock. The main goal is for the
client to adjust its clock to T3 + δresp , where δ signifies the round-trip time.

• Round Trip Delay (δ):

δ = ( T4 − T1) − ( T3 − T2)

• Offset (θ):
( T2 − T1) + ( T3 − T4)
θ=
2
As we assume that δreq = δresp , the client can synchronize its clock to T3 + 12 δ.

Client Server

T1
Ꟙreq
T2

T3
Ꟙresp
T4

Time

Figure 1.12: Clock Synchronization: Cristian’s Algorithm

The Berkeley algorithm (c.f. Figure 1.13) is designed for clock synchronization in distributed
systems, while its primary objective is to synchronize the time across diverse machines within
a network. It is based on a master amongst all participating machines, including the time
server, to orchestrate the synchronization process. The Berkeley Algorithm initiates the syn-
chronization process by requesting all participating machines in the network to send their
local clock times to the coordinator. Once the local times are received from all the machines,
the coordinator calculates the average time based on the collected data and determines the
deviation between this average time and the local time of each machine, including its own.
Subsequently, the coordinator distributes the calculated time differences to all machines in the

22
network. Each machine, upon receiving its respective time difference, adjusts its local clock by
incorporating this time difference, thereby contributing to the overall synchronization of the
network’s clocks.
The Berkeley Algorithm’s strength lies in its resilience through the use of average time, allow-
ing gradual clock correction, which is ideal for scenarios prioritizing relative time coherence
over precise time. However, it assumes negligible message delay between machines, which
can result in synchronization inaccuracies in real-world situations.

Time daemon
3:00 3:00 3:05 +5
0
3:00

-10 +25 +15 -20

3:00 3:00

Network

2:50 3:25 2:50 3:25 3:05 3:05

Figure 1.13: Clock Synchronization: Berkeley Algorithm

1.4.2 Logical clocks synchronization

Lamport’s algorithm and vector logical clock. Lamport’s algorithm approach defines the log-
ical clocks due to the absence of a global clock in distributed operating systems. This approach
was proposed by Leslie Lamport [57], and serves to order events in a distributed system. The
causal ordering in this algorithm represented as : a → b : Event a “causally” affects event b.
Lamport’s algorithm defines the "happened before" relation that if an event a precedes event b
in process p, it is denoted as a → p → b and it implies a → b. Additionally, if events a, b, and
c are in question, a → b and b → c implies a → c signifying causally ordered events.
Concurrent events are represented as a ∥ e which holds true if there is no causal relationship
between a ∥ e : if a ̸→ e and e ̸→ a.

The Lamport Timestamps algorithm assigns a unique timestamp to every event in a distributed
system. This algorithm guarantees that if event e causally precedes event e′ , then the times-
tamp L(e) is less than the timestamp L(e′ ). However, the converse does not hold true; if
L(e) < L(e′ ), it does not necessarily imply that e causally precedes e′ . Thus, Lamport Times-
tamps could potentially lead to inaccurate conclusions regarding the causal order of events. To
overcome these limitations, the Vector Clock Algorithm was introduced, specifically to distin-
guish between concurrent events. Each process in a system of N processes maintains an array
of N integers, representing the vector clock. The vector clocks are updated as follows:

• VC1: Initially, every entry in the vector, Vi [ j], is set to 0 for i, j = 1, 2, . . . , N.

• VC2: Just before process pi timestamps an event, it increments its corresponding entry:
Vi [i ] := Vi [i ] + 1.

• VC3: Process pi includes its entire vector Vi in every message it sends.

23
 • VC4: Upon receiving a message with timestamp vector t, process pi updates its vector
clock by taking the componentwise maximum: Vi [ j] := max(Vi [ j], t[ j]), for 1, 2, . . . , N.

In comparison to Lamport Timestamps, Vector Clocks can deduce more accurate causal rela-
tionships between events in a distributed system. While Lamport Timestamps can only infer a
partial ordering of events, Vector Clocks can infer a more detailed partial ordering, reflecting
the actual causal dependencies between events. This makes Vector Clocks preferable when
precise information about the causal order of events.

1.4.3 Consistency in distributed applications

Distributed snapshot. The global state of a distributed system is frequently advantageous
to detect the termination of a distributed computation and deadlocks. It captures the local
states of all processes and the states of all the communication channels in a distributed sys-
tem to represent a consistent global state. One method of recording the global state is the
distributed snapshot defined by K. Mani Chandy and Leslie Lamport [58]. This algorithm ad-
dresses the challenge of recording a consistent, synchronized view of the entire system’s state
at a specific moment in time, despite the distributed nature of its components. It operates by
introducing special "snapshot markers" and employs the "happened before" relationship to en-
sure the consistency of recorded snapshots. When a process in a distributed system receives
a snapshot marker, it records its local state, including variables and messages sent but not yet
delivered. By propagating these markers and using the "happened-before" relationship to de-
termine causality, the Chandy-Lamport Algorithm enables the creation of globally consistent
snapshots, making it a valuable tool for debugging, monitoring, and maintaining data consis-
tency in distributed applications.

1.4.4 Synchronization in concurrent system approach

Signal synchronization refers to the techniques and mechanisms used to coordinate and com-
municate between concurrent processes or threads to ensure that they work together correctly
and produce the desired results.
Mutexes (Mutual Exclusion). Mutexes mechanism ensures that only one thread or process can
access a critical section of code at a time [59, 60]. When a thread acquires a mutex, it gains ex-
clusive access to the protected resource or code. Other threads attempting to acquire the same
mutex will be blocked (c.f. Figure 1.14) until the owning thread releases it. Mutexes are es-
sential for preventing data races and ensuring data consistency in multithreaded applications.
This mechanism avoids potential issues like deadlock which occurs when two or more threads
are waiting for each other to release the mutex. There are different types of mutexes, including
binary mutexes (which can be locked by only one thread at a time), recursive mutexes (which
allow the same thread to lock the mutex multiple times), and other forms like reader-writer
locks and condition variables.

24
 Figure 1.14: Mutexes and locks [162]

Semaphores. Semaphores are introduced by computer scientist Edsger Dijkstra. [61] They
are widely used in concurrent programming to control access to shared resources and co-
ordinate the execution of multiple processes or threads. Semaphores provide a simple way
to manage the order in which processes can proceed by using "wait" (decrement) and "sig-
nal" (increment) operations[62, 63]. When a process encounters a WAIT operation with a
semaphore value of zero, it is blocked until the semaphore becomes available. On the other
hand, when a process executes a SIGNAL operation, it either wakes up a waiting process or
increments the semaphore value if no processes are waiting. The key advantage of semaphores
lies in their ability to enable efficient and non-busy-waiting synchronization, as blocked pro-
cesses are placed on a waiting list rather than continuously consuming CPU time. This makes
semaphores a foundational tool for managing concurrency and ensuring orderly access to
shared resources in multi-threaded or multi-process systems.
Monitors. monitors ensure controlled access to shared resources and automatic process syn-
chronization. This approach was introduced by Hansen [64] and further refined by Hoare
[65]. Initially, monitors enforce mutual exclusion, ensuring that only one thread or process
can actively access the monitor at a given time. This exclusivity prevents multiple entities
from concurrently modifying the shared resource, preventing data corruption and race con-
ditions. Also, they often incorporate condition variables, allowing threads to wait for specific
conditions to be met before continuing their execution. These condition variables are used for
signaling and notification, enabling threads to pause, release the monitor, and notify others
when a particular condition becomes true. Additionally, monitors maintain an entry queue,
which serves as a waiting area for threads or processes attempting to enter the locked monitor.
Threads in the queue patiently wait their turn, ensuring orderly access to the shared resource.
Together, these features make monitors a valuable tool for effective synchronization in concur-
rent programming [63]. Monitors are commonly used in languages and libraries that provide
high-level concurrency support.
Rendezvous. Rendezvous [63] ensures a controlled interaction and coordination between mul-
tiple threads or processes. In rendezvous synchronization, two or more entities agree to meet
at a predefined point in their execution, and they synchronize by exchanging data, signals, or
control flow. This mechanism ensures that tasks or threads stop at their rendezvous points
until all participating entities have arrived, and only then can they proceed. Rendezvous syn-
chronization is particularly useful for scenarios where precise coordination between concur-
rent entities is required, such as in real-time systems, inter-process communication, and con-
current algorithms. It helps avoid issues like race conditions and ensures that actions occur in
a specific order, providing a structured and orderly approach to concurrency control.

25
1.4.5 Clock Synchronization
Globally Asynchronous Locally Synchronous system. Clock synchronization primarily fo-
cuses on setting the time, while data synchronization focuses on data consistency. However,
in some cases, precise clock synchronization may be important to ensure data is processed
or recorded with the correct timestamps. Signal synchronization does not automatically syn-
chronize the clock, but, from another perspective clock synchronization is necessary to ensure
the accuracy of data timestamps. That’s why, another approach that we are considering is the
Globally Asynchronous Locally Synchronous (GALS) system [66]. GALS is a design paradigm
used in the field of electronics and integrated circuits, where modules operate synchronously
internally, with each module having its local clock, but asynchronously interacting with each
other, without a global clock. Each locally synchronous module in a GALS system operates
under its clock domain, driven by a local clock, while asynchronous interfaces are essential
for communication between different clock domains, and they handle the synchronization of
signals crossing between domains that are not synchronized to each other. While the global
clock is absent in the system design, GALS uses asynchronous FIFO (First-In-First-Out) buffers
[67] along with handshaking protocols to synchronize data transfer between different clock
domains, ensuring correct data sampling. The independence of clock domains in the GALS
concept can significantly help in problems related to clock skew, as it limits the skew-related
issues within individual domains, enabling easier management and control.
FIFO Buffers. FIFO buffers [68] are important for signal synchronization in various appli-
cations, such as digital communication and real-time systems. These buffers ensure that in-
coming data or signals are processed in the order they are received, regardless of variations
in arrival times or data rates. They bridge clock domain inconsistency, align signal timing,
and facilitate flow control, making them essential in managing the orderly flow of data and
maintaining synchronization. Additionally, FIFO buffers prevent data loss and help manage
data flow efficiently by allowing senders to operate independently of receivers, ensuring op-
timal synchronization between various system components. The adaptability and versatility
of FIFO buffers make them a fundamental building block in signal processing and synchro-
nization, contributing to the reliability and stability of numerous modern technologies and
systems.

1.4.6 Software as a service for signal synchronization

Other techniques considered for signal synchronization are middlewares like "Lab Stream-
ing Layer" (LSL) [163] which was used for real-time EEG synchronization, LSL solution is
open source and based on clock offset measurements to manage event information and tim-
ing. Moreover, we found the usage of the LSL package in several ecosystems like (Medusa)
[164] which is for brain-computer interface and cognitive neuroscience research. This plat-
form consists of two components, Medusa kernel and Medusa platform. In this topic, we con-
centrate on the Medusa Platform which provides high-level functionalities for managing and
synchronizing signals in real-time via LSL libraries. Also (OpenSync) [69] is another open-
source platform designed to synchronize a variety of physiological, and behavioral signals,
user input responses, and task-related information in neuroscience experiments. It facilitates
simultaneous synchronization and recording of data from multiple devices, leveraging the Lab
Streaming Layer (LSL) as its fundamental method for data streaming and synchronization.

1.5 Conclusion
In this chapter, we have laid a solid foundation by presenting the essential background knowl-
edge required for our master thesis. We’ve delved into crucial concepts such as structural
models utilizing meta-models in the context of Model Driven Engineering (MDE), behavioral

26
models, and signal synchronization. These building blocks are fundamental to the core of our
research. As we move forward, the next chapter will transition into the state of the art in
our research domain, where we will explore the current landscape and existing knowledge to
further contextualize our work.

27
Chapter 2

Model Driven Engineering (MDE)

Contents
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2 Model Driven Engineering for Internet of Things (MDE4IoT) . . . . . . . . . 29
2.2.1 MDE techniques for IoT concepts . . . . . . . . . . . . . . . . . . . . . 29
2.2.2 MDE for self-adaptive IoT systems . . . . . . . . . . . . . . . . . . . . 30
2.2.3 Testing SCADA Systems Using the EMF and Modelica . . . . . . . . 32
2.2.4 Service Oriented Architecture (SOA) approach . . . . . . . . . . . . . 34
2.2.5 IoT modelling tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.3 Model Driving Engineering for Artificial Intelligence (MDE4AI) . . . . . . . 41
2.3.1 Proposed approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.3.2 MDE for monitoring ML Models . . . . . . . . . . . . . . . . . . . . . 48
2.4 Artificial Intelligence for Model Driven Engineering (AI4MDE) . . . . . . . . 51
2.4.1 Domain modeling with ML . . . . . . . . . . . . . . . . . . . . . . . . 51
2.4.2 Model-based systems engineering and Knowledge Representation . 55
2.4.3 Crossover for Model-Driven Optimization . . . . . . . . . . . . . . . 57
2.4.4 Supporting Delay-Sensitive IoT Applications: A Machine Learning
Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

28
2.1 Introduction
The intersection of MDE, IoT, and AI has become a focal point in the field of technology inno-
vation. MDE, as a methodology for software development, emphasizes the use of models as
primary artifacts throughout the entire development process. This approach offers numerous
benefits, including abstraction, automation, and increased productivity. As IoT and AI tech-
nologies continue to evolve, the integration of MDE has become important in addressing the
complexity and challenges inherent in these domains.
This chapter provides an overview of the state of the art in MDE and its implications in the
context of IoT and AI. We delve into the emerging trends, challenges, and opportunities in this
interdisciplinary field, focusing on the advancements in MDE techniques tailored for AI and
IoT applications, namely MDE4AI, AI4MDE, and MDE4IoT.

2.2 Model Driven Engineering for Internet of Things (MDE4IoT)

The Internet of Things refers to the network of interconnected physical devices, sensors, ac-
tuators, and software applications that communicate and interact with each other to enable
various services and applications [70]. By working at a higher level of abstraction, heterogene-
ity, adaptability, reusability, and interoperability are a few non-functional aspects requiring
consideration during both the initial design phase and runtime operation [71–73].
However, developing IoT systems can be challenging due to the diverse range of devices, pro-
tocols, and technologies involved, as well as the need to handle large-scale deployments [74].
MDE4IoT proposes the use of models to abstract and capture the essential aspects of an IoT
system, including its structure, behavior, and deployment [33] where these models serve as a
common representation that can be used to reason about and automate various aspects of the
system’s development and operation by combining the principles of MDE with the domain of
IoT. It aims to address the complexity and heterogeneity of IoT systems by leveraging models
as central artifacts in the development process.
In this approach, developers create models using specialized modeling languages that cap-
ture the concepts and relationships relevant to the IoT domain. These models can describe
the physical devices, their capabilities, the communication protocols, the interactions between
devices, and the overall system architecture.

2.2.1 MDE techniques for IoT concepts

Sabine Wolny et al. in [75] conducted an initial mapping study on MDE4IoT, which aimed to
identify the extent to which MDE techniques are currently being applied in the field of IoT
(c.f. Figure 2.1), and which challenges are being addressed. In this paper, the research revealed
that numerous papers employ meta-models and semantic modeling techniques for IoT-related
tasks like service composition, discovery, and device description. Furthermore, the study also
identified the widespread usage of specific solutions and DSLs/DSMLs techniques for various
IoT concepts, including middleware, cloud, fog, edge computing, and deployment.

29
 Figure 2.1: Map of MDE techniques with IoT concepts [75]

2.2.2 MDE for self-adaptive IoT systems

Many research papers address self-adaptive IoT systems realized through dynamic reconfig-
uration, allowing the topology of components and models to be modified at run-time [33, 76,
77]. Additionally, the system adapts to changes in the hardware environment by tracking the
availability of IoT devices and recalculating deployments accordingly. One such paper was
proposed by Ciccozzi et al.[33], which discussed the use of high-level models for envisioning
this requirement(c.f. Figure 2.2). In this paper, for generating and executing models in a smart
street lights use case, the Authors discussed three main methods that are typically considered
which are interpretive, translational, and compilative execution. While Interpretive execution
involves running source models through a virtual machine, which may be less suitable for
resource-constrained embedded devices and translational execution translates models into a
third-generation programming language, utilizing a validated code generator, The authors fol-
low the third choice which is compilative execution that directly compiles source models into
machine language, leveraging the power of modern compilers. Also, they mention that The
choice between these methods depends on factors like resource constraints, domain hetero-
geneity, and performance requirements.

Figure 2.2: IoT systems as Self-Adaptive Systems [33]

30
Three different viewpoints (VP1, VP2, and VP3) are highlighted for developing logic related
to warnings, motion sensors, and actuators, respectively (c.f. Figure 2.3), allowing concur-
rent exploration by domain experts and synchronization through model transformations. The
utilization of multiple viewpoints is a fundamental aspect of the system’s design to address
different aspects of the problem domain and is concurrently exploited by various domain ex-
perts. VP1 signifies a horizontal viewpoint associated with a particular software application
domain, while VP2 represents a horizontal viewpoint for physical devices. VP3 serves as a
vertical viewpoint, encompassing both software and hardware aspects of a specific application
domain. Different viewpoints are designed to be concurrently leveraged by domain experts,
with underlying mechanisms defined in terms of model transformations ensuring consistency
among these diverse perspectives.
To support the design phase, MDE4IoT offers mechanisms for addressing evolutionary sce-
narios within the IoT through self-adaptation. When an Emergent Configuration (EC) goes
through changes and the managing system contemplates potential adaptations with two pos-
sible outcomes: The affected executable artifacts can be directly re-deployed or The system
must first re-allocate the functionality at the modeling level and subsequently execute the arti-
facts on alternative physical devices.

Figure 2.3: MDE4IoT framework [33]

@design-time. In smart street lights mode (c.f. Figure 2.4), the physical devices are categorized
into three hardware components: WarningSystemSensors, LampPostHardware, and Naviga-
tionSystemHardware. These hardware components are attributed to Modeling and Analysis
of Real-Time and Embedded Systems (MARTE) stereotypes to provide essential information
about the devices.
MARTE stereotypes allow the specification of critical details about the various devices, such
as the architecture of the computation unit and the number of cores it possesses. Software
functionalities are allocated to these hardware components through MARTE allocations, rep-
resented by UML abstractions stereotyped as «Allocate». The allocation of software function-
alities to hardware components is a crucial step in the system’s design process. It involves the
transformation of software functionalities into executable artifacts through model transforma-
tion chains. These transformations, driven by the allocations defined in the model, help infer
platform-specific details to enable software functionalities to run on specific devices effectively.

31
 Figure 2.4: Portion of the Smart Street Lights Model [33]

@run-time. In the runtime scenario, consider a situation where Car A is approaching a street
segment, and the red lights of four subsequent lampposts malfunction. Simultaneously, Car B
is approaching the same segment while traveling over the speed limit. The system indicates
a malfunction within part of the LampPostHardware. To address this issue, the managing
system, known as the ARU (Area Reference Unit) initiates a repair procedure by sending a
message to the maintenance service, providing details about the malfunctioning devices and
their locations. Additionally, the ARU continuously monitors the IoT and ECs. It detects the
availability of Car A and Car B, as well as their navigation systems, which can serve as alter-
native resources to replace the malfunctioning red lights.
MDE4IoT run-time adaptations. It checks that NavigationSystemHardware provides the nec-
essary features to host the functionalities previously deployed on LampPostHardware, which
require re-allocation. For example, an actuator for showing warnings (to replace the broken
red light, LPR) and routines to manage such an actuator (to replace part of the intelligence
provided by mR) are re-allocated from LampPostHardware to NavigationSystemHardware.
These reallocations are performed automatically by model transformations. Once completed,
MDE4IoT generates executable artifacts for the newly allocated devices.

2.2.3 Testing SCADA Systems Using the EMF and Modelica

Supervisory control and data acquisition (SCADA) is a system of software and hardware el-
ements that allow industrial organizations to control industrial processes locally or at remote
locations. SCADA systems are used to monitor and control a wide range of equipment and
processes in industries. These systems contain heterogeneous and legacy devices which makes
it crucial to test the entire system. Also, testing real-time SCADA systems is challenging due to
the complex interactions and the need to simulate the supervised and controlled environment
despite its distribution and its complex computation. To outcome these issues, [78] suggest

32
the usage of the EMF and Modelica to integrate testing models with environmental simulation
models (c.f. Figure 2.5), which can further enhance the effectiveness of model-driven testing
for SCADA systems.
Also, It discusses the System Modeling Language (SysML) as a standard for unifying diverse
approaches in system engineering and software domains. SysML, while allowing models to
describe system behavior without complex transformations. In comparison, Modelica, de-
signed to extend object-oriented mathematical modeling languages, is better at detailing com-
ponent behavior and functionality in a declarative manner. Modelica allows the graphical
composition of models through connection diagrams but recognizes that designing complex
systems goes beyond component assembly, requiring tasks such as gathering requirements,
specifying components, defining a structure, outlining design alternatives, describing overall
behavior, and conducting validation and verification, where Modelica’s capabilities surpass
those of SysML.

Figure 2.5: SCADA Testing Framework using EMF [78]

The paper [78] introduces a design-time model that captures an Interface Definition Language
(IDL) and product composition. Additionally, it incorporates a run-time model that captures
system configuration along with ports linked to sensors and actuators. Furthermore, a test
model is presented, which encapsulates test steps and establishes simulator bindings.
The paper discusses the application of Modelica for modeling and simulating the complex
external environment of SCADA systems. While internal system models are comparatively
simple, SCADA systems interact with intricate external worlds. Modelica, combining object
orientation with equations, is introduced as a tool for this purpose. A Modelica model is com-
posed of objects representing physical, mechanical, control, electrical, or electronic systems. It
can be compiled into an executable that simulates the development of system properties over
time. In addition to self-contained simulation, Modelica allows the definition of connectors
for external interactions. Sensors and actuators in SCADA systems are linked to connectors
on the outermost simulation model. A testing scenario is created by connecting test scripts to
the simulated environment through writes and assertions. This scenario resembles a G-clamp,
placing the SCADA system in a controlled testing environment. During testing, a Modelica
tool translates the model into C source code, compiling it into an optimized binary for the tar-
get platform to meet near-real-time requirements. Each test step is mapped into invocations
on the system using a test framework, with information drawn from the runtime model. The
approach can be extended by specifying the expected behavior of a component within the sim-
ulator, allowing predictions and prototyping. In the last tests, the actual behavior of the live
system can be compared to its simulation within the Modelica simulator.

33
2.2.4 Service Oriented Architecture (SOA) approach
SOA is an approach to software development that employs software components known as
services to construct business applications [79]. Each service delivers a specific business ca-
pability, and these services can communicate seamlessly with one another, regardless of plat-
forms and language differences. As mentioned in [24, 28] SOA is useful for developing IoT
systems while it treats a complex system as a set of subsystems and implementation using this
approach software and hardware components can be efficiently reused and updated.
Service Oriented Architecture handle transformation. The methodology used by Sosa-Reyna
et al. [28] is supported by model transformation (c.f. Figure 2.6) which can be vertical where
it refines abstract models in more specific models, or horizontal form defining mappings be-
tween models of the same level of abstraction.
The proposed methodology uses conceptual models at various levels of abstraction and gran-
ularity to develop software solutions for IoT applications. The output of each phase in this
methodology consists of models created by applying MDE principles. These models even-
tually lead to the generation of software implementation artifacts, such as the code for IoT
applications or software systems.

Analysis of business requirements Business

Requirements requirements
Requirements capture model
Definition of system use cases
Definition of activity diagram
Business Business
requirements solution
model Definition of business logic model
Model Model
Definition of BPMN diagram
Repo Repo
(Input/ Business IT (Output/
source) solution Design of the integrated services architecture target)
model solution model
Generation of SOA Composite

IT Technological
architecture Generation of the technological solution
model solution model
Generation of IOT app

Software
implementation
artifacts

Figure 2.6: MDE based methodology to IoT applications deployment [28]

To address the complexity of the software development process, the works of [28, 80, 81] lever-
age the UML, resulting in a business requirements model that serves as an abstract represen-
tation, independent of specific technologies, and sets the foundation for a PIM. In the second
phase, the focus was on the design of business processes, which constitute the core function-
ality of the system. Then, employ the Business Process Model and Notation (BPMN) to define
the complexities of business process logic. This enhances the existing business requirements
model, leading to the creation of a PIM that offers a global perspective on the behavior and
interactions of these processes. An IT architecture model is implemented rises above platform-
specific details, effectively segregating the business logic from technical implementation con-
cerns. The final phase involves the transformation of the architectural design into executable
code, customized for a specific implementation platform, this step is in two stages the first one
is the specification of the chosen technology or platform, and the second one is the transforma-

34
tion of the PSM into a textual representation, effectively performing the executable instructions
for the application.
These model transformations (c.f. Figure 2.7) consist of sets of rules that map input models
to one or more output models or executable code. The proposed MDE methods include four
transformations. These transformations take place at different stages of the methodology and
are facilitated by using tools like the Eclipse Atlas Transformation Language (ATL).

Figure 2.7: M2M transformation rules [28]

Why SOA? In SOA, interoperability is ensured through autonomous services, each equipped
with descriptive documents outlining its functionality and associated conditions where users
interact with these services and treat them as black boxes, obtaining necessary information
through service descriptive documents [165, 166]. This allows any client system to execute
a service regardless of the implicit platform or programming language. Service coupling is
designed to be loose to minimize external dependencies such as data models. Additionally,
service granularity is important, aiming to group individual business functions into sepa-
rate services, enabling developers to create composite services for complex operations. Also,
the flexibility and adaptability of SOA compositions allow for incremental changes and rapid
adaptation to evolving IoT requirements. Additionally, they facilitate development practices
and dynamic service discovery and composition, enabling real-time adjustments.

Reactive Microservices for IoT. IoT applications can be specific to certain industries or more
general. However, challenges like deployment, scalability, and interoperability persist. Mi-
croservices have been effective in cloud computing, but their application in IoT faces unre-
solved issues. To address these challenges, the paper [82] introduces a combination of mi-
croservices and reactive systems as a solution for developing IoT applications, with a focus
on fog computing (c.f. Figure 2.8). The authors discuss the adoption of service-oriented ar-
chitecture (SOA) is considered insufficient for achieving interoperability and scalability due to
the limitations of SOA applications in IoT, including deployment difficulties, scalability issues
caused by strong service coupling, performance bottlenecks, centralized management leading
to system unavailability, and limitations in addressing physical heterogeneity due to reliance
on a single technology platform and development standards. They highlight that while SOA
has been applied to IoT projects, IoT presents unique challenges that require a different ap-
proach compared to traditional SOA. They mention that other researchers have explored SOA
solutions in IoT to achieve scalability, portability, and reusability. However, the authors sug-
gest that IoT’s specific requirements demand a different development approach. They mention
a more recent approach was proposed focusing on a service-oriented middleware and an eVo-
lution Service Bus (VSB) to interconnect IoT devices with different interaction protocols. Yet,
they point out that even the Enterprise Service Bus (ESB) approach can have faults that affect
the operation of an entire application due to strong service coupling.

35
 Figure 2.8: OSGI Reactive Microservices for IoT [82]

Microservices, as defined by Fowler and Lewis in [167], involve implementing an applica-

tion as a set of small, independently running services, often using lightweight communica-
tion mechanisms like HTTP. This approach offers several advantages for IoT applications, in-
cluding technology heterogeneity, resilience, scalability, ease of deployment, organizational
alignment, composability, and optimizing for replaceability, which is crucial for large-scale
IoT applications. Recent studies, including one by Di Francesco et al. in [83], have shown that
microservices have been applied in domains such as IoT and mobile. Given the vast amount
of data produced by billions of IoT devices.
The proposed approach for modeling reactive microservices in IoT encompasses two main
modules: data and application. In the data module, each microservice provides an interface
for maintaining data in the database, supporting polyglot persistence for various data storage
requirements. In the application module, the design includes core and utility perspectives.
The core perspective provides components for asynchronous message exchange (Event Bus
and MQTT Broker), fault control (Circuit Breaker), and service discovery. The utility perspec-
tive offers components for displaying devices via a RESTful API and handling data streaming.
The Event Bus enables weakly coupled communication among different parts of an applica-
tion or service, with messages sent to addresses and consumers registering at those addresses.
The Circuit Breaker supports resilience by managing states, including Closed, Open, and Half-
Open, based on fault conditions. The Timeout component uses a specified timeout to run a
Microservice in a degraded mode. A separator isolates Microservices from the exchange of
asynchronous messages. The Health check component reports the current state of a Microser-
vice as UP or DOWN. The MQTT Broker component handles connections, communication,
and message exchange with remote MQTT clients. The service discovery component enables
the discovery and composition of services, promoting location transparency and elasticity. The
RESTful component exposes services through a RESTful API for IoT device access, while the
streaming component processes and analyzes data streams from various IoT devices in real-
time. The security component provides authorization and authentication functionalities for
users.

36
The implementation of the microservices based on the model (c.f. Figure 2.9) uses the tools
provided by Vert.x [168] and Apache ServiceMix [169]. Vert.x is chosen for its advantages in
designing reactive applications in multiple languages and its superior performance compared
to other frameworks. ServiceMix allows the deployment of run-time applications with elastic-
ity characteristics suitable for reactive systems. Karaf container, a core component of Apache
ServiceMix, serves as the foundation for deploying Bundles that support reactive Microser-
vices.

Figure 2.9: Reactive Microservices Infrastructure [82]

Fish farm case study in Fog Computing. The implementation and application of the reactive
microservices IoT platform were in the context Fish Farm case study (c.f. Figure 2.10). The
platform is deployed on limited processing and memory capacities devices like Raspberry Pi
and Intel Galileo Gen2, utilizing components such as an Apache OSGi-based service-oriented
middleware (Karaf), a Vertx MQTT broker, and various APIs for service discovery, resiliency,
security, and elasticity support.
This architecture allows for the exchange of asynchronous messages between microservices,
with features like mobility support, authentication, and cascading failure prevention. In the
Fish Farm scenario, the platform is applied to monitor parameters like temperature, pH, and
others aiming to detect anomalies or environmental events, such as pH levels between 6 and
8. The platform is designed to provide scalability, low latency, resiliency, and elasticity in
managing complex aquatic environments.

37
 Figure 2.10: Smart Water Scenario [82]

The authors analyze the results of their experiments to compare their architecture proposal
with a traditional Fog-based platform for IoT applications (c.f. Table 2.1). The analysis is based
on the factors and levels defined in their experimental design.
Real
Cloud Open- General- Tool Shared Data
S.No Name Major Domain Programming Language Maintanance Status Simulation in
Support Source Purpose Type Resources Insight
IoT Environment
Real-time task scheduling
1 STRESS No No C Language Not maintained No Yes Desktop No No
algorithms analysis
Real-time task scheduling
2 GHOST No No C Language Not maintained No Yes Desktop No No
algorithms analysis
3 MAST No Yes Scheduling Visualization Ada Not maintained No Yes Desktop Yes No
4 STORM No Yes Visualization and Simulation Java Not maintained No Yes Desktop Yes No
Maintained for
5 SimSo No Yes Simulation and Visualization Python No Yes Desktop No No
bugs only
Supply-demand matching Multiple Languages
6 SDMSim No No Unknown No No Web-based No No
simulation and analysis Support
Data intensive analysis
7 ScSF No Yes Python Actively Maintained No No Desktop Yes Partial
tool on HPC
Scheduling Algorithms
8 TaskInsight Yes No C/C++ Unknown Yes Yes Desktop Yes Yes
Memory insight
Maintained for
9 MCRTsim No Yes Visualization and Simulation Java No Yes Desktop No No
bugs only
Energy Consumption
10 Score No No Multiple Languages Unknown Yes No Web-based Yes Partial
Analysis tool
Resource-Constrained
11 iMOPSE No Java Actively Maintained No
Scheduling
12 ABEMAT No No Energy Management tool Python, C++ Unknown No No Desktop No No
Maintained for
13 Location Tracker Yes Yes IoT Context Tracker Android N/A No Mobile Application No Yes
bugs only
Fiware and
14 Yes Yes IoT API Provider JavaScript Actively Maintained Yes No Headless Backend N/A Yes
DIY testbeds
15 Proposed Tool Yes Yes IoT Scheduling Simulator Python Actively Maintained Yes Yes Web-based Yes Yes

Table 2.1: Comparative Analysis of Proposed Tool with existing state-of-the-art tools and
testbeds [82]

The results show that the use of the proposed architecture improves both the throughput pub-
lished and the throughput received in scenarios with 6 and 12 sensors. In addition, in scenarios
where data analysis at the edge of the network is performed, the approach proves to be more
efficient in terms of designing IoT applications compared to the traditional approach resulting
in lower latency and improved data throughput, making it a favorable choice for IoT applica-
tions.

38
2.2.5 IoT modelling tools
A challenge is raised in research and development in this context of IoT systems with a perva-
sive network including managing diverse applications, development environments, devices,
and communication technologies. Real-time models for reliable interworking and the identi-
fication and monitoring of critical system elements are required to overcome challenges and
advance the IoT paradigm [170].
A proposed modeling tool for IoT systems is built on the Eclipse Modeling Framework (EMF)
[24] using meta-model and Graphical Modeling Framework (GMF) to create the Model-Driven
Development (MDD) editor for the DSL. The tool’s development process begins with defining
the ECore model (c.f. Figure 2.11), which acts as the tool’s meta-model and encompasses pri-
mary and sub-containers for various components like Data Provider, Pre-Processing, Virtual
Object, and Application Interface. These containers can host multiple implementations of ab-
stract classes, serving as evaluation examples against user requirements and extensible for
future IoT technologies.

Figure 2.11: ECore Model of the Proposed Tool [24]

The EMF Generator Model is used to generate essential plugin projects, while GMF helps in
creating a diagram editor where serialization is supported in the XMI format. The tool’s base
classes are implemented as Eclipse plugins, providing flexibility for future component integra-
tion. The code generator uses Xpand to create Java code and essential artifacts based on cus-
tomizable templates. This generated code is organized into a Java project that includes chosen
connections (e.g., Plugwise and Arduino). In terms of workflow, users create a project, define
a domain model, design it with virtual objects, associate processing modules, data providers,
and application interfaces, and then generate a Java project that can be accessed via chosen ap-
plication interfaces. The authors agree that the proposed work outperformed (c.f. Figure 2.12)
another work including EMF Tool with UML diagrams in terms of user satisfaction.

Figure 2.12: Comparisson between EMF tool and IoT Modeling Tool [24]

39
Files generation and Integration with other systems. Integrating an IoT modeling tool with
other tools is a beneficial approach to enhance its versatility and optimize performance. Sal-
ihbegovic et al. [84] explore various tools and languages used in IoT system development,
including DiaSuite, Node-RED, PervML, and OpenHAB.
DiaSuite [85] is a tool suite designed for Sense, Compute, and Control applications, featuring
a domain-specific design language and a Java programming framework.
Node-RED [171], an open-source IBM software, is a visual tool for configuring IoT applications
by connecting hardware devices, APIs, and online services using a browser-based flow editor.
PervML [86] is a Domain Specific Language (DSL) for describing pervasive IoT systems in a
technology-independent manner. OpenHAB [172], on the other hand, is a general-purpose
framework for smart home gateways based on Eclipse SmartHome, facilitating the develop-
ment of IoT solutions in the smart home domain. It employs Java OSGi bundles to define OSGi
services, serving as middleware in wireless sensor networks.
A comprehensive gap analysis of IoT platforms [87] identified 39 distinct platforms. Despite
this diversity, several significant challenges were noted. Generally, there was a lack of support
for heterogeneous devices, leading to inefficiencies in managing various formats and models
of device data streams. Additionally, concerns were raised regarding the seamless handling of
different data formats and models associated with device data streams.
The paper [84] discusses the design of a Visual Editor named DSL-4-IoT (c.f. Figure 2.13 ).
It is a VDSL that aims to abstract many of the specific aspects of IoT applications into build-
ing blocks and library modules. To handle the heterogeneity of IoT devices, the OpenHAB
runtime engine is used for interfacing with hardware and software components and execut-
ing DSL-4-IoT configuration files including items, rules, and sitemaps. These files define the
IoT system’s topology and its associated items. Also, The DSL-4-IoT exports data into a JSON
array, which contains information about the position of items within the configuration, rela-
tionships between items and groups, and data types and can be used to restore the system’s
state for further editing. Seamlessly, The author mentions that the configuration files generated
by DSL-4-IoT are not limited to OpenHAB, but also they can be adapted for other IoT integra-
tion platforms by replacing the corresponding JavaScript files used for code generation.

Figure 2.13: DSL-4-IoT GUI [84]

Simulation-Based Approach. In this paper [88], the authors introduce the usage of MDE tech-
niques, specifically ThingML, Eclipse Modeling Project, Sirius, and Xtext, for Simulation-Based
Arduino applications. This approach is organized into four steps, the initial step was designing
and modeling IoT Applications using the ThingML language. Next, they employ the ThingML

40
code generation framework to generate code for the Arduino hardware platform, resulting in
source code known as "sketches". After generating sketches, the code is compiled into object
code (with a ".hex" file extension) that can be executed on the Arduino. This compilation is per-
formed using the Arduino IDE. The simulation is carried out using Proteus software where we
can define the parameters (Program file) of the Arduino micro-controller and launch the simu-
lation. The paper highlights the various notations available as concrete syntaxes for Domain-
Specific Languages (DSL). These notations can be textual, graphical, tabular, form-based, or a
combination of these, each offering unique advantages. Also, the authors describe the devel-
opment of three viewpoints: viewing and editing Things, state machines (c.f. Figure 2.14), and
configurations.

Figure 2.14: The state machine Viewpoint [88]

2.3 Model Driving Engineering for Artificial Intelligence (MDE4AI)

There has been a growing interest in integrating MDE with AI, particularly machine learning
(ML), to address the challenges of developing AI-based systems. This integration can provide
a higher level of abstraction and automation to the development of these systems, thus im-
proving their efficiency, quality, and maintainability.
One notable advantage is the provision of a higher level of abstraction. MDE allows devel-
opers to work with models that capture system functionality and behavior at a more abstract
level than traditional code. This abstraction simplifies the complexity of AI system develop-
ment, making it more accessible and manageable.
Moreover, the automation capabilities of MDE contribute significantly to the development pro-
cess. Developers can automatically generate code from high-level models, streamlining the
implementation of AI techniques. This automation is particularly valuable in the context of

41
machine learning, where the development often involves iterative experimentation with vari-
ous algorithms and parameters.
A noteworthy aspect is that individuals without in-depth coding expertise in AI can still lever-
age these techniques effectively. MDE enables the generation of AI models with the incorpo-
ration of parameters and theoretical tools, reducing the reliance on manual coding.

2.3.1 Proposed approaches

ML-Quadrat. In a Model-Driven approach to Machine Learning and software modeling for the
IoT, a group led by Armin Moin et al. reported in [89], that the CPSs, become smarter through
incorporating AI. The team observed an increasing need for integration and liaison between
the Software and Systems Engineering community on the one side and the AI, including the
data analytics (DA) and ML community. Otherwise, they compared their proposed approach,
called "ML-Quadrat" as presented in table 2.2 with existing approaches in the field of MDE4IoT.

Description Work Full DAML IoT/CPS Model type

code support domain
gen.
ML libraries
TensorFlow, Keras,
and No Yes No DAML models
Scitkit learn,etc
frameworks
DAML KNIME, RapidMiner, No Yes No DAML models
workflow etc
designers
Model In- PMML, PFA, ONNX No Yes No DAML models
terchange
Formats
(MIF)
Model Infer.Net Yes Yes No ML (PGM) & SE
based (ML) models
MDE4 IOT ThingML and HEADS Yes No Yes SE models
Models @ µ-Kevoree Yes No Limited SE models
Runtime
Models @ GreyCat Yes Yes Limited SE & DAML
Runtime + models
ML
MDE4 IOT ML-Quadrat Yes Yes Yes SE & DAML
+ ML models

Table 2.2: Compared ML-Quadrat with other works [89]

This paper mentions how tools and libraries in DAML, such as TensorFlow [173], Keras [174],
KNIME [175], and RapidMiner [176], provide different levels of abstraction for data analytics
and machine learning tasks. In the context of MDSE, a systematic approach where models
carry comprehensive information about the entire application was suggested where model-to-
code transformations are mentioned as a way to generate software implementations from these
models. Additionally, it discusses model-interchange Formats like PMML, PFA, and ONNX,
which provide standards for exchanging machine learning models between different platforms
and frameworks. Those articles [89, 90] discuss ThingML as a foundational project, given its
integration with the EMF and the Xtext framework. The authors adapted this project to their
needs and incorporated a DA component that enables access to DAML libraries and frame-

42
works, such as Scikit-Learn [177] and Keras, at the design time and this confirms that their
ML-Quadrate method is the unique approach capable of supporting DAML, the IoT/CPS do-
main, and code generation. Furthermore, they have expanded the capabilities of the Java code
generator in ThingML to include the generation of Python code which is responsible for im-
plementing DAML functionalities by using the APIs provided by Scikit-Learn and Keras for
this purpose.
The approach’s workflow (c.f. Figure 2.15) offers numerous parameters and choices, one no-
table parameter is the switches between enabling or disabling data analytics modules, setting
the Automated ML feature to ON, trying to automatically select the best option of the desired
ML method. That would greatly benefit software developers who might be a novice in the
field of DAML.

Model the Model the

software software
structure behavior

«Platform Model the DAML required

expert» DAML
Support components
target
platform(s)

Desired ML method
not there

Desired ML method
pre-defined
Augment software
model with
Choose an ML references to
model the pre-trained
architecture ML model &
library (black-
box ML)

«End
user»
Interact
Run the model-to-code No DAML needed with /
transformations use the
generated
IOT
Run the service
generated
No Yes build script
Software
model valid
& complete?
Deploy &
run the IOT
service

Figure 2.15: Workflow of ML-Quadrate [89]

Smart energy systems case study. The authors describe a case study focused on IoT/CPS in the
context of smart energy systems within smart homes, using publicly available data from a UK
residential building available through the REFIT datasets [178]. The data covers 21 months,
capturing the power consumption of various electrical appliances and the total household
load. This study explores scenarios where ML is used to predict the state of specific appli-
ances, such as a washer and dryer, when data is missing. It considers four different scenarios:
classification, clustering, regression, and black-box machine learning. The system architecture
involves smart meters, a database server, and a DAML server to predict missing values.

• Supervised (MLP): In this experiment, precision, recall, and F1-Measure metrics were
exceptionally high at 99.9%, 100%, and 99.9%, respectively, and took 3,552 seconds for

43
 training.

• Unsupervised (Clustering): Training the clustering model is notably faster, taking only
13 seconds compared to the supervised model in the previous scenario. The clustering
model achieved an accuracy of 92% on unseen test data.

• Supervised (Regression): For measuring the performance of regression, the typical error
measures, Mean Absolute Error (MAE), as well as the Mean Squared Error (MSE). the
achieved MAE was 10.1, and the MSE was 29,962.1.

• Black-box ML: same as Unsupervised ML including the performance

ML-Quadrat evaluation. This paper mentions that the evaluation (c.f. Table 2.3) was by eval-
uators who are familiar with Java and Python programming and ML, and they have study
documentation that provides guidance and instructions for using ML-Quadrate and creating
smart IoT services using the prior work ThingML. The project includes a basic example in-
volving two things connected to the IoT: a "ping client" and a "pong server." In this scenario,
the ping client sends ping messages to the pong server, and the server responds with pong
messages. In a real-world scenario with a large number of clients, the authors suggest using
machine learning (ML) to prevent Distributed Denial of Service (DDoS) attacks. They pro-
pose the introduction of a new component responsible for DAML and designed to predict if a
client is likely to be an attacker or not. When the server receives a ping message, it consults
the DAML component to determine whether to respond with a pong message or ignore the
request. It may also involve putting the client on a blacklist for a certain period if necessary.

Task-Mode Eval. 1 Eval. 2 Eval. 3 Eval. 4 Total

Score
Manual software 1 1 2 2 6
ANN MLP
development(no
classifier
MDSE)
Using the prior 0.5 5.5 3.25 10.25 19.5
work (ThingML)
Using the pro- 2.25 2 5 12 21.25
posed DSML
Manual software 0 1 2.25 1 4.25
K-Means
development(no
clustering
MDSE)
Using the prior 2.25 1.25 4 2 9.5
work (ThingML)
Using the pro- 2.25 1.25 5 5 13.5
posed DSML
Table 2.3: The scores of the 4 evaluators [89]

The evaluators have noted improved scores in comparison to both previous efforts and manual
software development in the results. The proposed approach demonstrated a significant pro-
ductivity improvement of around 25% compared to prior work (ThingML) and a substantial
236% improvement compared to manual software development. Additionally, the authors be-
lieve that the value of their approach could be even greater when dealing with heterogeneous
IoT cloud and edge platforms.

44
In another paper, A.Moin et al. [90] propose an alternative approach to model the behavior of
components, known as "things" in ThingML. This innovative perspective empowers users of
the tool to delegate the task of defining a thing’s behavior to AI algorithms, specifically ML
algorithms. These algorithms are capable of making inferences based on observed data. In
general, for complex behaviors that prove challenging to comprehend and specify using tradi-
tional state machines, ML algorithms can autonomously learn these behaviors efficiently and
effectively.
Hybrid systems. The physical world often involves continuous dynamics represented by vari-
ables changing continuously over time, and this is well captured by mathematical tools such
as differential equations and integration theory. On the other hand, digital components in
CPS are typically discrete and can be represented by finite states. This is where discrete event
systems, state machines, and Petri Nets become valuable tools for modeling. Discrete event
systems focus on events that occur at distinct points in time, and state machines provide a
way to model the behavior of a system based on its discrete states and transitions between
them. Petri Nets, a mathematical modeling language, are also commonly used to represent
and analyze the flow of events and states in systems. The challenge lies in integrating these
two distinct modeling paradigms. Hybrid systems [91], which combine both continuous and
discrete dynamics, are one approach to bridge the gap between the physical and digital aspects
of CPS. These systems may involve continuous physical processes that are influenced by dis-
crete digital control systems. To address these challenges, researchers in this paper introduce
an extension to the existing approach for specifying behaviors using state machines (c.f. Fig-
ure 2.16). This extension enables the utilization of advanced DA algorithms and methods for
event detection, the triggering of state transitions, and modifying the system’s behavior using
the data received from the sensors.

Figure 2.16: State machine modeling the behavior of a Smart Air Conditioner based on the
room temperature [90]

Comparison of MontiAnna & ML-Quadrat. Kirchhof et al. in [92] lists its contributions, which
include a case study that demonstrates the use of MontiAnna and ML-Quadrat for modeling
ML-enabled software, a functional comparison of these two model-driven tools, and an explo-
ration of how MDE can support different aspects of ML-driven software development. The
paper mentions that it uses the MNIST [179] calculator model as a common ground.
MontiAnna [93] (c.f. Table 2.4) is a textual modeling framework and build system that ensures
the creation of deep ANNs with a specific emphasis on IoT applications. It operates within
the EmbeddedMontiArc modeling language, adopting a component-based approach that en-
capsulates software functionality within well-defined components connected via input and
output ports. Each ANN is considered a component within the software architecture, with
ports directly mapped to the neural network’s input and output layers. MontiAnna stream-
lines the management of trained model weights through its build system. It automatically
detects ANNs within the software architecture and resolves model weights during the build
process. If no pre-trained weights are available or if there are changes to the network model
or training data, the build system autonomously retrains the network. This automation mini-
mizes the need for manual involvement in the machine learning life cycle.

45
 Dynamic/Imperative
component interface

Layer independence
Low-level operators

Mobile deployment
Layer composition

Parameterization
C & C integration

General purpose
Static/Symbolic
Directed acyclic

Layer stacking
Deep learning

computation

computation
framework

framework
Interfaces
Type-safe

graphs
MontiAnna ✓ ✓ ✓ - ✓ ✓ ✓ ✓ MontiAnna * * - *
Theano - - ✓ ✓ ✓ ✓ ✓ ✓ Python ✓ - ✓ -
Torch - - ✓ ✓ ✓ ✓ - ✓ Lua, C - ✓ ✓ -
PyTorch - - ✓ ✓ ✓ ✓ - ✓ Python - ✓ ✓ -
Command Line,
Caffe P - ✓ - - - ✓ - C++, Matlab, ✓ - - -
Python
Caffe2 - - ✓ ✓ ✓ ✓ - ✓ Python, C++ ✓ - ✓ ✓
TensorFlow - - ✓ ✓ ✓ ✓ ✓ ✓ Python, C++ ✓ -** ✓ ✓
Python, C++,
R, Julia
MXNet P - ✓ ✓ ✓ ✓ ✓ ✓ Matlab, Go, ✓ ✓ ✓ ✓
Scala, Perl,
JavaScript
Keras - - ✓ - ✓ ✓ ✓ ✓ Python ✓ * - *
Matlab NNT ✓ - ✓ - P P ✓ ✓ Matlab ✓ - - -

Table 2.4: Comparison of established deep learning frameworks and languages, ✓: yes, P:
partially, -: no, : depending on chosen backend, *: provided by extensions. [93]

Machine learning models in MontiAnna are structured with a neural network architecture
component and a separate configuration model. These components define the desired training
scheme and encompass hyper-parameter settings. Tag models enable the association of ver-
sionable training data and weights with the ANNs.
MontiAnna also offers a library of pre-built training pipelines, including supervised learn-
ing, reinforcement learning, generative adversarial networks (GANs), and variational autoen-
coders (VAEs). Moreover, it provides the flexibility to create custom pipelines and compo-
nents using Python code, promoting modularity and adaptability. Configuration parameters
for different pipelines are managed using a modular schema system, allowing for parameter
inheritance and combination. MontiAnna’s versatility extends to IoT applications through in-
tegration with MontiThings, a DSL-based framework. This allows for the specification of IoT
component behavior, even in cases where edge devices have limited computational resources.
As an example, MontiAnna can be used to train simplified speech recognition models for IoT
devices to detect specific phrases and trigger actions. Additionally, this paper provides a com-
parison of various critical elements between MontiAnna and ML-Quadrat. The comparison
(c.f. Table 2.5) encompasses the problem domain and integration, modeling methodology, ML
methods, target ML libraries and frameworks, ML pipelines, modularity, compatibility, Au-
toML, and the management of generated artifacts.

46
 Propreties MontiAnna ML-Quadrat
1 Problem domain ML self-contained (or to- ML-enabled IoT services
gether with MontiThings for
the IoT)
2 Integration Component encapsulation in Encapsulation in ThingML
EmbeddedMontiArc / Mon-
tiThings
3 Modeling methodology Multiple DSLs Single DSL
4 ML methods Various ANNs with super- Various supervised, unsuper-
vised, unsupervised, and re- vised, and semi-supervised
inforcement learning ML approaches
Target ML libraries
5 MXNet Gluon, TensorFlow, Scikit-Learn and Keras (with
& frameworks
PyTorch, Caffe2 the TensorFlow backend)
Target languages
6 Python (training and run- Python (for ML), Java, C,
for code generation
time), C++ (runtime) JavaScript, and Go
7 ML pipelines Modeled via the DSL; func- Out-of-the-box
tionality out of the box or im-
plemented by user
Modularity
8 Pre-trained networks can be Any pre-trained ML model in
and Compatibility
loaded as network layers and Sckit-Learn or Keras may be
ONNX imported/ plugged in
9 AutoML Neural Architecture Search Rule-based and through
with AdaNet, hyper- Bayesian Optimization
parameter optimization and (Hyperopt)
component-based AutoML
planned
10 Re-training Re-training only if data or Event-based automated re-
model have changed, event- training, for example, when
based automated re-training new data arrive, or timer-
based
11 Generated artifacts Full source code contain- ML models, full source code
ing ANNs (from CNNArch- (including the Python scripts
Lang models) and ML model for pre-processing, training,
training scripts (from Con- and prediction), build and
fLang), complete source code run scripts.
and dataflows or only inter-
faces (from Pipeline Model
created with EmbeddedMon-
tiArc and ConfLang)
12 Artifact management Maven-based artifact re-use Apache Maven projects gen-
(source code, trained models, erated for Java
datasets are packaged inde-
pendently)

Table 2.5: MontiAnna vs. ML-Quadrat [92]

The initial aspect under comparison concerns the problem domain and integration capabilities
of the two modeling tools. MontiAnna offers the flexibility to create standalone ML applica-
tions and ensure integration into the IoT domain through MontiThings. On the other side,

47
ML-Quadrat offers an integrated modeling language that encompasses both IoT and machine
learning, serving as a comprehensive solution for heterogeneous and distributed IoT services.
Also, The two tools differ in their modeling methodologies and the ML methods they sup-
port. Both are research prototypes in active development, We can predict that these open and
collaborative approaches will contribute to synergies and network effects within the SE and
ML communities and this will lead to the rapid adoption and extension of MDE tools for ML,
benefiting both academic research and industry applications soon.

2.3.2 MDE for monitoring ML Models

Commercial ML models need to adapt to changing environments to maintain performance
where algorithms for detecting and adapting to environmental changes are essential [94]. The
goal of this paper is to create a for expressing ML monitoring methodologies, separating the
technical implementation from the system’s intended behavior.
The approach allows engineers to define the intended behavior of monitoring systems without
specifying technical details. The paper mentions various methods to adapt to non-stationary
environments, including using causal models and online learning. Online learning continu-
ously adapts for each labeled sample received but requires a constant flow of labeled data. A
hybrid approach combines initial training with continuous adaptation whenever new labeled
samples become available.
To apply ML techniques in a commercial setting, they must be part of a larger system that
meets various stakeholder requirements. These requirements may include considerations for
latency, cost of resources, compatibility with existing software, and infrastructure. The as-
sumptions for the deployed ML models in a non-stationary environment were outlined such
as models continuously receiving unlabelled samples must make predictions instantly actual
labels become available for some previously unlabelled samples over time and periodic de-
cisions are made based on the latest data received, using both labelled and unlabelled data.
Different actions can be taken in response to various types of drift, defined by domain experts.
The meta-model (c.f. Figure 2.17) for ML monitoring consists of several essential components:

48
 Figure 2.17: Domain Meta-Model [94]

• Deployment: Describes all aspects of an ML monitoring method, containing a model and

drift detectors.

• Model: Represents the ML model to be monitored and includes general information

about it, such as the model’s name, URL for model serialization, and the framework
used to create it.

• IO: Represents inputs and outputs of the model, including the data type.

• DriftDetector: Represents the periodic execution of an algorithm to detect drift and de-
cide on corrective actions.

The domain experts can define the drift detector’s name, execution frequency, and the algo-
rithm to be executed. Two types of drift detectors are distinguished such as DataDriftDetector
which Requires unlabelled samples received over time and labeled training samples and Con-
ceptDriftDetector which Requires predicted labels and actual labels of unlabelled samples.
The provided meta-model outlines the behavior of the ML monitoring system but does not
delve into specific technical implementation details. It’s important to note that multiple valid
implementations are feasible. An example of such an implementation is based on Kubernetes

49
(c.f. Figure 2.18). Using Epsilon Generation Language (EGL) model-to-text extension in EMF,
the authors employed the transformation to generate a Kubernetes manifest. This manifest is
then used for deployment via Kubernetes’ CLI tool, facilitating the creation of ML monitoring
systems aligned with domain expert specifications. The resulting system effectively translates
the behavioral specifications provided by a domain expert within the MDE model.

Figure 2.18: Generated Artifacts [94]

• Inference Service: Provides a model server for responding to inference requests. Contains
a logger that produces events about the server’s requests and responses developed by the
Kubeflow project.

• Message Queue: Receives events from the logger and routes them to the database writer
service. Implemented using Broker and Trigger custom resources, developed by the Kna-
tive project.

• Database Writer: Initializes a database based on domain expert specifications. Stores

monitoring data, including information from the model server’s requests and responses.

50
 Collects feedback about the ML model’s performance, such as ground truth labels for
inference requests. Implemented using a Service custom resource by the Knative project.

• Database: A standard MySQL database for persisting data. Implemented using Deploy-
ment, Service, and PersistentVolumeClaim resources from Kubernetes.

• Drift Detection Execution: Periodically executes the drift detection algorithm specified
by the domain expert. Implemented as a CronJob resource from Kubernetes. Uses a
containerized application that retrieves test set data from the database and training set
data from cloud storage. Passes the data to a function implementing the drift detection
algorithm. Also, sends email alerts if drift is detected.

• Configuration: Allows containerized applications to adapt their behavior to match the

domain expert’s specification. Achieved using configuration files (ConfigMaps) that are
mounted to a container’s file system.

• Proxy: Handles incoming HTTP requests and checks the request’s path. Forwards the
request to either the inference service or the database writer based on the path. Im-
plemented using a VirtualService custom resource by the Istio project. This system is
designed to implement the behavior specified by a domain expert in the MDE model
without specifying the technical implementation details.

By offering these features, the web application simplifies the deployment of ML monitoring
systems, making the process more accessible for domain experts with varying technical back-
grounds. It streamlines the definition and deployment of these systems based on MDE models,
enhancing user-friendliness and flexibility without necessitating deep technical expertise.
The authors outline various areas of improvement and development for this approach to ML
monitoring in their future work. These include enhancing scheduling capabilities to accom-
modate more complex scenarios, creating a comprehensive abstraction for drift detection al-
gorithms, expanding response actions to drift, and enabling incremental updates for deployed
ML monitoring systems. Additionally, the authors plan to conduct a comprehensive evalua-
tion, focusing on the solution’s general applicability and empirical effectiveness, to validate
the practical advantages of their approach in real-world applications.

2.4 Artificial Intelligence for Model Driven Engineering (AI4MDE)

Software systems must become more intelligent to address evolving requirements in cyber-
physical and IoT applications regarding the huge use of smart objects that autonomously re-
spond to various situations and reduce the need for human intervention. In this context, AI
techniques can enhance various aspects of MDE, such as improving modeling, code genera-
tion, analysis, and optimization.

2.4.1 Domain modeling with ML

An evolving paradigm, known as [email protected] was introduced in [95], as an extension
in MDE by advocating the use of models at both the design and runtime stages to facilitate
reasoning processes. In another paper [96] the relationships (c.f. Figure 2.19) between meta-
model, model, and object graphs ([email protected]) were presented as sequential processes
by transformation or generation steps.

51
 Figure 2.19: Relations between a meta-model, model, and object graphs [96]

In [96] Hartmann et al. introduced a new meta–meta-model (c.f. Figure 2.20) that is based on
MOF/EMOF and includes additional concepts for directly representing ML within the domain
modeling language. These meta-classes, in turn, can have a variable number of properties that
encompass attributes, relationships, and what authors refer to as "specified properties."

Figure 2.20: Meta–meta-model [96]

Specified properties are further categorized into learned and derived properties where learned
properties refer to attributes or relationships that will be acquired through a specific ML algo-
rithm. A particular learning algorithm can be designated using the "specification" labeled as
"using," and any required algorithm parameters can be defined using the "parameter" speci-
fication and the "feature" specification permits access to properties from other metaclasses or
enums.

52
Coarse-grained vs fine-grained learning. The same paper discusses coarse-grained learning
involves extracting common patterns and behaviors from extensive datasets to address un-
known behaviors that typically focus on capturing trends and behaviors across large datasets.
On the other side, fine-grained learning requires applying learning algorithms to specific el-
ements or subsets of a dataset rather than seeking commonalities across the entire dataset.
Deciding which portions of the dataset should be considered for each learning algorithm often
requires domain knowledge, which can be structured as domain models.
Moreover, learning algorithms can deduce behavioral models based on past instances, rep-
resenting the common behaviors learned from the data. However, when datasets consist of
independent and diverse entities with significantly different behaviors, searching for a single
coarse-grained common behavior may not be effective or suitable, especially in complex do-
mains like CPSs. Coarse-grained learning can give inaccurate results for systems composed
of heterogeneous entities with distinct behaviors. Furthermore, in cases of data changes, the
entire learning process must be recomputed, which can be time-consuming.
On the other side, fine-grained learning was introduced as a contribution in this context,
regarding that it can significantly enhance efficiency such as segmenting the problem into
smaller, more manageable units, insisting that micro-learning is a good solution for addressing
the diversity of unknown behavioral models in systems composed of heterogeneous elements
with distinct behaviors believing that combining small learning units will prove effective in
constructing probabilistic prediction models.

Smart grid case study. In this approach around using micro-learning units, finely-grained
learning components are designed to break down complex learning tasks into reusable, chain-
able, and independently computable elements. For example (Figure 2.21) provides an exam-
ple featuring a SmartMeter metaclass, defining attributes and introducing both derived and
learned properties.

Figure 2.21: Schematic representation of a microlearning unit [96]

When specifying a learned property like "powerProbabilities" the approach automatically gen-
erates code to weave machine learning algorithms into meta-model instances, creating mi-
crolearning units. These units are associated with both object instances and states.
The authors introduce the modeling language, which is designed to enable the definition of
domain data and its structure and facilitates the integration of machine learning (via learned
properties) with domain modeling. It allows for defining relationships between learned prop-
erties, domain properties, and other learned properties, ensuring composition, reusability, and
independent computation. Additionally, microlearning units can be computed in a distributed
manner, with each unit processed on separate machines thanks to a shared model state en-
hancing efficiency through a bulk-synchronous parallel approach. The modeling language is
inspired by established meta-modeling languages such as UML, SysML, and EMF Ecore. It
extends the semantics of UML class diagrams with the concept of microlearning units.

53
Integrating machine learning into models. The authors describe patterns for integrating ML
into models, similar to design patterns that have emerged from modeling methodologies to ad-
dress common issues. They explore how the language can be applied in a concrete smart grid
use case with various combinations of ML and domain modeling. An example of SmartMeter,
which includes two attributes, activeEnergy, and reactiveEnergy, along with a relationship to
a customer was presented. These attributes are the typical domain properties of a SmartMeter
class and another attribute named anomaly to automatically detect abnormal behavior based
on the profiling of active and reactive energy using the Gaussian anomaly detection algorithm
as the learning method.

c l a s s SmartMeter {
a t t a c t i v e E n e r g y : Double
a t t r e a c t i v e E n e r g y : Double
r e l customer : Customer
l e a r n e d a t t anomaly : Boolean {
from " a c t i v e E n e r g y "
from " r e a c t i v e E n e r g y "
using " GaussianAnomalyDetection "
}
}
The generated API provides suitable methods such as train and inference for working with
the anomaly attribute. While it can be used similarly to "normal" attributes, these methods
allow for training and inference based on the ML model. Also, The template of the Gaussian
mixture model algorithm is implemented in GreyCat and used by the code generator to cre-
ate ML functionality in the domain class. This approach is realized using IntelliJ Integrated
Development Environment (IDE). The development workflow in the framework aligns with
standard MDE practices, commencing with the definition of a meta-model. The framework
includes a code generator based on Apache Velocity. This code generator is capable of produc-
ing APIs for object-oriented languages like Java and TS. The generated classes are conceptually
similar to those created by frameworks like EMF, but they extend their capabilities with ML
features. The framework offers flexibility in terms of the ML algorithms that can be integrated
such as regression, classification, clustering, and Profiling (Gaussian Mixture Models (Simple
and Multinomial)). The authors conduct an evaluation of the approach aiming to determine
whether micro-learning can offer greater accuracy compared to coarse-grained learning. All
evaluations were on an Intel Core i7 2620M CPU with 16 GB of RAM and Java version 1.8.
The accuracy of micro-learning profiling was found to be approximately 85%, whereas coarse-
grained learning achieved an accuracy of 72% while a Gaussian mixture model was used as
the profiling algorithm in both cases. The average prediction error in microlearning was 3,770
Wh, while coarse-grained learning resulted in an average error of 6,854 Wh. Microlearning
appears to be more accurate, reducing the error between prediction and actual measurement
by half, and sufficiently fast to support real-time (c.f. Figure 2.6), live learning applications by
evaluating the time required to load data and perform live profiling for different numbers of
users and power records.

54
 Number of users Number of records Loading data time in s Profiling time in s
10 283,115 4.28 1.36
50 1,763,332 21.94 7.20
100 3,652,549 44.80 14.44
500 17,637,808 213.80 67.12
1000 33,367,665 414.82 128.53
5000 149,505,358 1927.21 564.61
Scalability test over 5000 users and 150 million power records

Table 2.6: Loading time and profiling time in seconds [96]

The results showed that loading the data was a time-consuming task, taking around 32 minutes
to load and parse the dataset from disk when dealing with 5,000 users and 150 million power
records. On the other hand, the time spent on profiling using micro-learning was significantly
less, taking less than 10 minutes. Both the loading and training times showed a linear relation-
ship with the number of records loaded (O(n) complexity), indicating that performance could
be improved by distributing and parallelizing the computation. The results demonstrated that
the framework could handle more than 60,000 values per second on a single computer, com-
parable to data processing frameworks like Hadoop.
General applicability of the presented approach and modeling language. The general appli-
cability of the approach is demonstrated through examples from different domains, showcas-
ing how ML can be seamlessly integrated into domain modeling. Two examples are provided,
one from the domain of recommender systems and another from the domain of transportation
systems
The recommender systems aim to provide recommendations based on users’ prior actions.
Three common types of recommender systems are user-user, item-item, and user-item recom-
menders. The proposed modeling language allows the integration of all three types within the
same model, providing flexibility for system designers. Fine-grained profiling and recommen-
dation can be achieved by attaching profiles to users and products. Profiles can be updated
in real-time after every purchase. User clustering for user-user recommenders, product clus-
tering for item-item recommenders, and fast matching between user and product profiles for
user-item recommenders can be implemented.
The transportation systems aim to optimize public transportation by suggesting different trans-
portation alternatives to users. Fine-grained profilers can be created for various aspects, such
as taxi fare pricing, road traffic, and parking availability. These profiles are independent, fine-
grained, and reusable learning units in the modeling language. A recommender system can
use the information from these learning units to calculate recommendations.

2.4.2 Model-based systems engineering and Knowledge Representation

The article [97] addresses the challenge of bridging the gap between Model-Based Systems En-
gineering (MBSE) and Knowledge Representation, offering a promising solution to improve
the design, knowledge sharing, and reasoning capabilities in the field of complex system en-
gineering. The authors contribute to the development of an ontology for Unmanned Aerial
Vehicles (UAVs) and their integration into the MBSE tooling environment. This integration al-
lows for the systematic use of formalized knowledge, with benefits such as knowledge reuse,
advanced reasoning, and tool-agnostic system representations. The article discusses the rele-
vant literature and related research in the fields of ontologies, UML, and MBSE with a focus on
Autonomous Systems. The central reference is the Core Ontology for Robotics and Automa-
tion (CORA) [98], an IEEE standard that uses Web Ontology Language (OWL) [99] to formalize

55
ontological categories relevant to robotics. Several surveys and works related to knowledge
representation in autonomous systems and UAVs are highlighted, such as KnowRob [100] for
knowledge processing, Perception and Manipulation Knowledge (PMK) for enhancing robotic
capabilities, and the "dronetology" ontology for UAVs. The authors note differences between
UML’s Closed World Assumption (CWA) and ontologies’ Open World Assumption (OWA)
and the need for addressing semantic heterogeneity in distributed systems.
The proposed solution involves integrating standardized ontologies into MBSE tools like Pa-
pyrus [180], the approach aims to enable expert knowledge reuse, enhance knowledge ac-
quisition, and refine system models. It emphasizes the potential for ontologies to provide a
consistent and computer-interpretable foundation for system design, improving the accuracy
and precision of system implementations in complex domains. The article highlights the use
of two key ontologies: the Core Ontology for CORA and the Drone Components ontology
(ODrone), developed for specific drone-related concerns. ODrone is integrated into CORA
to provide a standardized vocabulary for describing drones and their components, making
it more accessible and useful for system designers and introduces specific device types, in-
cluding ActuatorDevice, SensorDevice, CommunicationsDevice, ComputingDevice, and En-
ergySourceDevice. Each inherites properties from CORA, to facilitate a common language for
describing drone components. It also defines the roles that devices can perform within a drone
system, adding precision to the relationships.
Furthermore, the paper outlines the modeling of interactions between drone system parts us-
ing the isConnectedTo relation and its specializations (suppliesTo, bus, attachedTo). These
relations help describe how devices interact, sharing data, or physical connections within an
ArtificialSystem. The formalization of these concepts in OWL ensures a high degree of se-
mantic clarity and consistency within the ontological framework that was used to represent,
exchange, and analyze information. OML simplifies the complexities of OWL, making it more
user-friendly.
The workflow (c.f. Figure 2.22) begins with UML specification files (.uml), which contain re-
sources for modeling systems. Then, An adapter is used to convert UML specifications into
an OML vocabulary. Then, The DSL, specific to the domain of interest (UAVs), is represented
in OML format. Concepts from ODrone are mapped to UML constructs, and specific seman-
tics are defined by a knowledge engineer. After that, Using the DSL in OML format, a UML
profile is automatically generated. This profile extends the UML language and includes an-
notations from the ODrone ontology. At that point, The generated UML profile is imported
into the Papyrus UI, where system designers use it to model a system. The final step involves
transforming the annotated UML model back into OWL format using a custom UML2OWL
adapter specific to the ODrone ontology. Constraints expressed as queries, rules, or complex
concept definitions can be evaluated on the annotated UML model.

56
 Figure 2.22: Workflow, resources, and actors for the implementation of the approach [97]

To ensure that the semantics of ontology concepts are preserved throughout the transformation
into UML and back to OWL, a mapping has been implemented between ODrone and UML,
targeting class diagrams and composite structure diagrams. The mapping allows for the ex-
tension of the current ontology by defining new classes in UML. These extended classes and
their definitions become part of the ontology, offering the potential for reuse in new designs
or external tools and services compatible with ODrone and CORA. Once the ODrone UML
profile is available, it can be used to stereotype UML elements in a system design.
The authors present some examples that even when certain information is not explicitly pro-
vided in the UML model, the reasoner can infer it, based on the mappings and ontology seman-
tics. In a second example, when UML instances are created and interconnected, the reasoner
evaluates whether an instance has all the necessary and sufficient parts of the required types
and whether these parts are interconnected as intended. This example highlights how inverse
roles, class inheritance, and relations inheritance are used to draw inferences about complex
concept definitions while preserving ontology semantics. As an example focuses on reusing
knowledge from the CORA standard shows how knowledge formalized in logic axioms can be
reused to draw inferences about the UML model and demonstrates how SPARQL [101] queries
and SWRL [102] rules are used to enforce compliance with the standard.

2.4.3 Crossover for Model-Driven Optimization

Evolutionary algorithms inspired by biological evolution which are used to explore a search
space for solutions to a problem were introduced in [103]. Techniques such as mutation and
crossover are two fundamental operators used to generate new solutions. These operators
play a crucial role in the exploration and exploitation of the search space to find optimal or
near-optimal solutions to a problem. In this paper, S. John et al. introduce a new mechanism
for generating new models from existing ones using a crossover technique and a selection
mechanism typically based on the concept of survival of the fittest drives evolution. These
mechanisms are designed to be relevant to the field of MDE and applied to the Class Respon-
sibility Assignment (CRA) case (c.f. Figure 2.23), which is a structural optimization problem
in the field of software engineering.

57
 Figure 2.23: Meta-model for the CRA case [103]

The CRA case is important in the context of Model-Driven Optimization (MDO). which is re-
lated to creating high-level designs for object-oriented systems. In this context, the author’s
goal is to perform a crossover technique to create offspring solutions. This case study helps
demonstrate the practical application of MDO principles and tools in the software engineering
domain. This paper provides an example of a crossover between two solutions, E and F (c.f.
Figure 2.24), for the same problem instance. The crossover combines the best aspects of both
solutions to create offspring solutions O1 and O2. This example demonstrates how crossover
can lead to the creation of new solutions by recombining parts of existing ones.

Figure 2.24: Two solution models E and F of the CRA case and their offspring O1 and O2
generated by applying crossover [103]

This paper mentioned that crossover can lead to infeasible solutions, meaning they may vio-
late constraints or have low fitness. In such cases, infeasible offspring can either be repaired
after crossover or discarded. It outlines a specific splitting algorithm that serves as a funda-
mental component of the crossover operator. The algorithm’s primary objective is to divide
problem-rooted EMF models into two sub-models, E1 and E2 while ensuring that they remain
rooted EMF models and valid solutions for a given problem instance. The authors provide a
detailed algorithm for this recombination, focusing on the determination of a crossover point
(CP) that serves as a common sub-model for the split points of the parent models. This CP
includes the problem model and extends it, ensuring that the offspring models remain rooted
in EMF models with valid containment hierarchies. The strength point of this algorithm is its
configurability, allowing for domain-specific adaptations to deal with the specific needs and

58
constraints of diverse optimization tasks.
For the evaluation of the proposed algorithm (c.f. Table 2.7 and Figure 2.25 ), the authors aimed
to answer whether an evolutionary search of models could be more effective by incorporating
both mutation and crossover instead of relying only on mutation. The experiments used a
framework called MDEOptimiser [181] and the NSGA-II evolutionary algorithm [182] to opti-
mize problem instances related to CRA case, ranging from small to large models. The authors
applied Henshin transformation rules [183] as mutation operators and introduced a crossover
operator.

Algorithm Metric A B C D E
M100-C0 Mean HV 0.924 0.841 0.738 0.574 0.596
M100-C100 Mean HV 0.846 0.332 0 0 0
M100-C10 Mean HV 0.915 0.838 0.743 0.538 0.455
M100-C10-R Mean HV 0.929 0.871 0.759 0.584 0.609
M100-C20-R Mean HV 0.934 0.883 0.77 0.576 0.595
M100-C30-R Mean HV 0.933 0.879 0.779 0.583 0.579
M90-C10-R Mean HV 0.89 0.603 0.506 0.601 0.594
M80-C10-R Mean HV 0.774 0.586 0.538 0.483 0.618

Table 2.7: Mean normalized hypervolume of selected algorithm variants [103]

Figure 2.25: Cumulative approximation sets of selected algorithm variants for model D [103]

The results demonstrated that adding crossover (along with the repair step) to the evolution-
ary search process can be more effective and enable a broader exploration of the search space
compared to using mutation alone. Notably, the evaluation revealed that lower mutation rates
can be more effective for larger models, as higher crossover rates could lead to constraint vio-
lations.

59
2.4.4 Supporting Delay-Sensitive IoT Applications: A Machine Learning Approach
The paper [104] addresses the challenge by proposing a hierarchical network architecture, such
as heterogeneous cloud radio access networks (H-CRANs) [105] and cooperative cloud-edge
computing. These architectures leverage network function virtualization and software-defined
networking to enhance network-wide management. authors mention that cloud computing is
central in processing tasks, but the increased computing demands call for strategies like task
offloading to relieve cloud servers. In parallel, edge computing processes tasks at the network
edge, ensuring low latency for delay-sensitive applications in areas like e-health, manufactur-
ing, and connected vehicles. To minimize delay, the authors propose an approach by classi-
fying the incoming tasks into delay-sensitive (e.g. biomedical sensors) and delay-insensitive
(e.g. climate monitoring) categories. In this approach supervised machine learning, particu-
larly decision trees, is employed to classify tasks efficiently. The model is trained and tested
using simulated datasets, considering the nature and category of IoT applications (c.f. Ta-
ble 2.8). Four distinct IoT types and categories are considered, and delay-sensitive tasks are
labeled as 1, while delay-insensitive tasks are labeled as 0.

Category Manufacturing Connected

Home Enterprise
IoT Type facility vehicles
Lighting actuator 0 1 1 1
Temperature sensor 0 0 0 0
Motion sensor 0 0 or 1 0 or 1 1
Biomedical sensors 1 1 1 1

Table 2.8: Simulating delay requirements of the proposed IoT applications [104]

The authors introduce a priority-based edge computing model to manage the increasing vol-
ume of IoT tasks arriving at edge devices(c.f. Figure 2.26). To prevent overloading and perfor-
mance degradation, this model incorporates the concept of an M/M/k queuing system. The
usage factor (ρ) of the M/M/k queuing system is defined as ρ = λ/(kµ), where λ represents
the task arrival rate, k is the number of servers, and µ is the service rate and is essential for ρ
to remain below 1 for system stability.

Figure 2.26: Proposed priority queueing model [104]

The authors mention that the user delays in a priority queuing system are attributed to three
distinct waiting periods, namely, remaining service time for users being served, users with
equal or higher priority already in the queue, and users with higher priority arriving later.
The evaluation of the model involves calculating key metrics, including accuracy, precision,
and recall, using a confusion matrix. The simulation leveraged a machine learning model
trained with Python’s libraries and a dataset created using MATLAB’s random functions. The

60
dataset contained 1000 samples, with 700 allocated for training and 300 for testing, wherein IoT
tasks were characterized by their ’IoT Type’ and ’Category.’ The model employed a decision
tree with four levels to categorize tasks based on specific conditions, resulting high accuracy
of 0.96, a precision of 0.93, and a recall of 1.
Furthermore, the study explored the advantages of prioritizing delay-sensitive tasks, reveal-
ing a substantial reduction in queuing delays for such tasks compared to delay-insensitive
ones. These findings underscore the effectiveness of machine learning in IoT task classification
and provide valuable insights for enhancing the performance of mobile computing networks
through task prioritization at the edge device.

A Labeled Dataset for Advancing ML in MDE. In [106] López et al. cite that the previous
ML applications in MDE have included using ANNs for classifying meta-models into applica-
tion domains, clustering techniques for organizing collections of models, and graph kernels for
characterizing similar models, But, one significant challenge in applying ML to MDE is the lack
of high-quality datasets for training rich ML models since the existing datasets are often small
in size or not well-organized, making them less suitable for training ML models effectively.
Even dataset labeling often involves manual intervention, which can be a time-consuming pro-
cess. It involves investigating the specifics of a model, exploring similar models, and searching
for external sources of information to assign an appropriate label. Also labeling Ecore meta-
models necessitates familiarity with EMF and its ecosystem, while annotating UML diagrams
requires an understanding of the different UML diagram types.
Traditional methods for addressing this issue involve clustering techniques, such as K-means
or hierarchical clustering, which can be used to group models that have limitations (c.f. Fig-
ure 2.27), such as the need to predefine the number of clusters, which is often unknown in
advance.

Figure 2.27: Incorrect grouping of models in clusters [106]

To overcome these issues, a proposed methodology to speed up the labeling process for soft-
ware models was mentioned. This methodology is supported by an Eclipse plug-in that allows
for interactive, semi-automatic labeling by grouping similar models using a search engine. The
presented methodology, referred to as Greedy Methodology for Fast Labelling (GMFL) was de-
signed to facilitate dynamic and user-driven clustering of models. This algorithm allows the
user to label models while considering their similarities, thereby minimizing the cognitive load
and streamlining the labeling process.
The strategy for determining the order in which unlabelled models are presented to the user in
the GMFL labeling methodology is by prioritizing the models with a higher likelihood of the
selected model. Therefore, this approach boosts user confidence and feel more productive. The
exploration order is by converting models into text documents. This conversion is achieved by
considering the values of string attributes, typically the names of model elements within each
model. A Term Frequency-Inverse Document Frequency (TF-IDF) [184] approach is applied

61
to transform each document (model) into a vector. This vectorization technique is commonly
used in natural language processing and information retrieval to represent documents based
on the importance of terms within them. For each document, its density is calculated. This
density is determined as the average similarity with its k nearest neighbors to measure the
similarity between models. Models with a higher density, indicating more similarity with
other models in the dataset, are selected first for exploration.
The proposed approach involves using off-the-shelf search engines (using Whoosh [185]) to
determine model similarity. Initially, a model (model a) is chosen to start a new streak. A
ranked list of unlabelled models is obtained based on their similarity to the chosen model (c.f.
Figure 2.28). Models in this list are labeled with the same category as the starting model, effec-
tively initiating a streak.

Figure 2.28: Algorithm execution starting with a fault tree model [106]

The evaluation of the GMFL algorithm (c.f. Table 2.9) was in emulating the user’s actions.
This process introduces two metrics: streak size (the number of models labeled in a row with
the same category) and repetition size (the number of times a streak with the same label reap-
pears). Additionally, three clustering approaches are compared: K-means, hierarchical cluster-
ing (HC), and DBSCAN. The number of clusters is estimated based on the number of identified
categories.

ECORE UML
Savg Smax Rcat Savg Smax Rcat
Random 1.03 5 19.53 1.06 4 29.95
K-Means 3.51 93 5.74 3.76 373 8.41
HC 3.98 165 5.06 2.57 209 12.30
DBSCAN 1.46 53 13.76 1.26 84 24.99
GMFL 4.45 183 4.52 4.58 277 6.90

Table 2.9: GMFL evaluation results [106]

The results indicate that the random method and DBSCAN perform poorly. The K-means and
HC approaches did better, assuming the number of categories is known in advance. However,

62
in situations where categories are discovered during dataset exploration, GMFL outperforms
the clustering approaches, as it enables users to label more models in a row and reduces the
cognitive load. GMFL exhibits larger average streak sizes (Savg) and smaller repetition ratios
(Rcat) compared to other methods and proves effective for labeling software models, especially
when the number of categories is not predetermined.
The paper introduces ModelSet [186], a dataset containing 5,466 Ecore meta-models and 5,120
UML models with associated labels. This dataset aims to address the lack of large, well-
organized datasets for software models in MDE. The models are collected from well-known
model repositories such as GitHub and GenMyModel and then validated and organized. This
dataset was labeled by two authors with over a decade of modeling experience. While they
performed the process individually, they established milestones to discuss labeling criteria and
unify their approach, they performed ML algorithms such as detecting dummy models and re-
moving them from the dataset. Also, the approach used to infer tags for models based on their
content. By training the model on a dataset with tags provided, it learns to associate tags with
specific features or characteristics of the models. This process is particularly useful for models
that do not have tags explicitly assigned and allows for the automatic generation of descriptive
tags to facilitate search and categorization.
To infer tags for models, a neural model is used . It is a simple neural network that learns the
weights of two layers. The Models are represented as TF-IDF vectors, which serve as input
features for the neural model. The model consists of two layers with weights and biases: W1,
b1, W2, and b2. The activation functions used are Rectified Linear Unit(ReLU) and sigmoid.
The output dimension of the neural model corresponds to the number of tags. Each output
coordinate represents the probability of a model belonging to a specific tag. The neural model
is trained using binary cross-entropy as the loss function and the Adam optimizer.
The authors discuss the results of a machine learning classification task for classifying models
based on categories. The models were evaluated using different machine-learning algorithms(
KNN (k-Nearest Neighbors), SVM (Support Vector Machine), and NN neural network mod-
els) and datasets (Ecore-555, ModelSet-Ecore, and ModelSet-UML). Cross-validation was per-
formed to select the best hyperparameters for each model. The models were trained on the
entire training set, and their performance was evaluated (c.f. Table 2.10) on the test set.

MODEL BEST ACCURACY

PARAMETER CV TEST
k-NN 5 0.9278 0.9401
Ecore-555 SVM 1 0.9512 0.9520
NN 50 0.9563 0.9401
k-NN 3 0.8639 0.8873
MODELSET-Ecore SVM 10 0.9236 0.9393
NN 100 0.9148 0.9369
k-NN 1 0.9127 0.9168
MODELSET-UML SVM 10 0.9343 0.9442
NN 150 0.9355 0.9434

Table 2.10: Results of cross-validation and neural network accuracy [106]

The results indicate that in Ecore-555, there were no significant differences between SVM and
the NN, while KNN performed slightly worse. In ModelSet-Ecore, SVM and the NN out-
performed KNN, with SVM being slightly better. For ModelSet-UML, SVM and the NN also
outperformed KNN. The Ecore-555 dataset had better accuracy results than ModelSet-Ecore,
likely because the classification problem in Ecore-555 was less complex (9 categories compared
to 80 in ModelSet-Ecore). The classifier was able to predict the category of an Ecore model

63
based on its content, such as recognizing concepts like StateMachine, Region, and so on. These
findings suggest that the classification problem of categorizing models can be effectively ad-
dressed using ML techniques. The choice of dataset, encoding technique, and ML algorithm
can influence the model’s performance, but overall, the task seems to be manageable, even
with a large number of categories.

2.5 Conclusion
In this chapter, we have explored the state of the art in MDE and its implications in the domains
of IoT and AI. We have observed the evolving landscape of technology, where abstraction, au-
tomation, and scalability are key drivers in addressing the complexity of modern software
systems. In the context of IoT, AI4MDE explores ways to enhance MDE with AI capabilities,
enabling intelligent decision-making and automation within the model-driven development
process. Also, MDE4AI offers promising avenues for the development of intelligent and con-
nected systems. By combining the strengths of MDE, IoT, and AI, MDE4AI enables the devel-
opment of intelligent systems using model-driven techniques, enhancing automation, scala-
bility, and reusability.
In closing, the integration of these domains holds immense promise for shaping the future of
technology, paving the way for the development of intelligent, interconnected systems that can
revolutionize various domains.

64
Chapter 3

Synchronization & Formal Verification

Contents
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.2 Formal Verification of IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.2.1 Formal Verification in reactive systems . . . . . . . . . . . . . . . . . 66
3.2.2 Formal instantiation of MDE. . . . . . . . . . . . . . . . . . . . . . . . 79
3.2.3 A Scalable Distributed Architecture Towards Unifying IoT Applications 84
3.3 Signal synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.3.1 Clock Synchronization Protocols . . . . . . . . . . . . . . . . . . . . . 86
3.3.2 Globally Asynchronous Locally Synchronous GALS systems . . . . . 90
3.3.3 Synchronous Languages . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

65
3.1 Introduction
In the development of complex software systems, synchronization mechanisms are fundamen-
tal to the development of concurrent and distributed systems, where multiple processes or
threads interact to achieve a common goal. These mechanisms ensure that concurrent opera-
tions occur in a coordinated manner, preventing issues such as data races and deadlocks. Over
the years, various synchronization techniques have been developed, ranging from low-level
primitives like locks and semaphores to higher-level constructs such as monitors and trans-
actions. Understanding and effectively utilizing these mechanisms are essential for building
robust and efficient concurrent software systems. Also, formal verification is a rigorous tech-
nique used to prove the correctness of a system concerning a formal specification. Unlike
testing, which only checks for correctness on a limited set of inputs, formal verification offers
mathematical certainty by exhaustively analyzing all possible behaviors of a system. This tech-
nique involves mathematical modeling of the system and its properties, followed by rigorous
verification using formal methods such as model checking, theorem proving, and abstract in-
terpretation.
This chapter aims to provide a comprehensive overview of the state of the art in synchroniza-
tion mechanisms and formal verification techniques. We will explore the underlying princi-
ples, recent advancements, and practical applications of these techniques in software engi-
neering. By understanding the current landscape and emerging trends in synchronization and
formal verification, we can gain insights into how these techniques can be effectively applied
to ensure the correctness and reliability of modern software systems.

3.2 Formal Verification of IoT

Formal verification is a critical process in IoT and CPSs, due to their complexity and the poten-
tially strict consequences of failures. Formal verification employs mathematical techniques to
exhaustively analyze system models, checking for errors, vulnerabilities, and deviations from
specifications. This approach helps identify and correct issues early in the development pro-
cess, reducing the risk of costly and potentially dangerous failures. The importance of formal
verification in these domains lies in its ability to rigorously and systematically verify the cor-
rectness and reliability of these systems, ensuring they operate as intended and are resilient
against unexpected events. In safety-critical applications such as healthcare systems, any mal-
function or vulnerability can lead to horrible consequences since these systems are entrusted
with safeguarding human lives.

3.2.1 Formal Verification in reactive systems

As mentioned in [107–109], reactive systems represent a crucial paradigm for controlling and
interacting with the environment effectively. These systems (c.f. Figure 3.1) observe their
surroundings through input sensors and respond by adjusting their behavior using output
commands to achieve desired outcomes. A notable example is the automatic flight control
system in modern airplanes.

66
 Request

React to events
Continuely look for
next event

Response

Figure 3.1: Execution schema of a reactive system

A notable subdomain in reactive systems is a real-time reactive system that has time constraints
(c.f. Figure 3.2). It is designed to respond to input or events within a specific time frame, often
in a matter of milliseconds or microseconds. These real-time systems can be classified into two
main categories [187], namely, hard real-time and soft real-time systems.

• Hard real-time systems (c.f. Figure 3.2) have strict timing constraints, and if a deadline is
missed, it can result in system failure or even catastrophe (e.g. medical devices, aviation
systems, and nuclear power plants).

• Soft real-time systems have less strict timing constraints, and missing a deadline does
not usually result in system failure (e.g. multimedia applications, online gaming, and
traffic control systems).

Figure 3.2: Real-Time reactive system

Synchronous programming of reactive systems. Synchronous programming languages rep-

resent a distinctive paradigm designed to effectively address the complexities of program-
ming reactive systems [110]. The primary objective of synchronous programming languages
is to provide a high-level abstraction that mirrors the synchronous behavior found in digital
circuits, streamlining the development of these systems. At the core of this paradigm is the
concept of logical ticks, which allows programs to react in a sequence of well-defined steps,
corresponding to the behavior of synchronous circuits. This simplification enables develop-
ers to reason about time-related aspects more easily, eliminating the non-determinism that can
arise from the concurrent behavior of the system processes.
Synchronous programming languages ensure deterministic semantics, verifying that the order
of operations remains consistent and predictable. This property is pivotal for formal analy-
sis, verification, and certified code generation, making these languages extremely useful for
applications demanding high reliability, such as embedded systems and real-time control sys-
tems. On the other hand, asynchronous models of computation, where interleaving-based

67
non-determinism can lead to complex race conditions. These languages offer a specialized ap-
proach to developing reactive systems with strict timing demands.
We found a diversity of synchronous languages including Argos [111], which streamlines
real-time system development with accurate timing and synchronization. Atom, a DSL in
Haskell, expert in building dependable embedded systems. Averest[111] stands out for its
strong real-time support and verification capabilities, simplifying the complexities of reactive
system design. Esterel[110, 112, 113] excels in aerospace and automation applications. Lus-
tre[83] employs a dataflow-oriented approach and supports formal verification. SIGNAL[113]
specializes in multi-clock specifications, SOL[114] combines synchronous and asynchronous
concepts, and many other languages that collectively illustrate the diversity and impact of
synchronous programming paradigms across various domains.
We discovered that within these formal languages, some are more oriented toward managing
system behavior, with a lesser emphasis on data flows, and others exhibit the opposite focus
(c.f. Figure 3.3).

signals signals

Control

Data
sensors values

Esterel Lustre
Statecharts SCADE
Argos SIGNAL
EsterelStudio

Figure 3.3: Synchronous languages for reactive systems

Formal Method to Specify Distributed Mobile Real-Time IoT Systems. In the context of
distributed mobile real-time IoT systems, which involve the movement of physical objects in
geographical spaces and real-time communication with deadlines, the use of formal methods
during system design is essential. Process algebra is a well-suited formalism for modeling
these systems, as it can represent objects as processes and capture their movements and timed
communications. The paper [115] presents dT-Calculus, an extension of d-Calculus, as a pro-
cess algebra for specifying distributed mobile real-time IoT systems. dT-Calculus addresses
limitations in existing formal methods by providing capabilities to specify time properties,
such as ready time, timeout, execution time, and deadline, as well as priority and repetition.
dT-Calculus offers an innovative approach to modeling IoT systems, making it a valuable op-
tion for systems with complex real-time requirements. The choice of formal method should
depend on the specific needs of the IoT application being considered.
The paper discusses the use of process algebras like Timed pi-calculus, Timed Mobile Ambient,
and d-Calculus for specifying the characteristics of distributed mobile real-time IoT systems
during the design phase. However, it points out that these process algebras have limitations in
fully capturing the complexities of mobility and temporal properties in such systems. While
these formal methods offer valuable tools for modeling certain aspects of IoT systems, they
may not adequately represent the complexities of movement and precise timing requirements
often found in real-world IoT applications. Researchers and engineers in the field may need
to explore more expressive formal methods or a combination of formalisms to create more
comprehensive models for these systems. To overcome these limitations, the paper introduces
dT-Calculus which provides an advanced framework for capturing temporal properties re-

68
lated to actions and processes in IoT systems.
dT-Calculus is a process algebra designed for specifying and analyzing the movements of IoT
devices in a geographical space with temporal restrictions. It extends the capabilities of d-
Calculus by introducing five temporal properties such as ready time, timeout, execution Time,
deadline, and period. These properties help define the timing and scheduling aspects of spo-
radic and periodic actions in IoT systems. Additionally, graphical representations are provided
in the form of system and process views to aid in understanding system and process relation-
ships, making dT-Calculus a powerful tool for specifying and analyzing temporal properties in
IoT systems. In the comparison between dT-Calculus and other process algebras(c.f. Table 3.1),
dT-Calculus outperforms in expressing various forms of direct movements, both autonomous
and heteronomous, which are crucial for modeling IoT device mobility. On the other hand,
Timed pi-calculus relies only on value passing for mobility, limiting its capability to express di-
verse movement patterns. Timed Mobile Ambient provides three types of movement actions,
but it lacks support for passive or heteronomous movements. d-Calculus and dT-Calculus al-
low the specification of both autonomous and heteronomous movements.

Process Algebra IoT Characteristic

Types of movement Types of temporal
Interactions
properties properties
Timed pi-Calculus Indirect movements Deadline Communication
Timed Mobile Communication
in, out, open Deadline
Ambient Movements
Execution time Communication
d-Calculus in, out, get, put
Deadline Movements
Ready time
Time out Communication
dT-Calculus in, out, get, put
Execution time Movements
deadline period

Table 3.1: Comparison of dT-Calculus with other algebras by the IoT characteristics [115]

The paper introduces a tool called SAVE (Specification, Analysis, Verification, and Evaluation)
developed on the ADOxx meta-modeling platform. SAVE comprises four basic components,
namely, the Modeler which allows users to specify system and process views, the Execution
Model Generator (EMG) which generates an execution model for the specified views and en-
ables the selection of simulation paths, Simulator which generates a model for the selected
simulation, and Analyzer which conducts security analysis and verification by using model-
checking. SAVE offers two specification models, ITL (In-The-Large) and ITS (In-The-Small),
to support detailed specifications. From these specifications, the tool automatically generates
execution models, which show all possible execution paths and determine if each path is nor-
mal or leads to a deadlock. After generating an execution model, SAVE creates simulation
models for each execution path, representing the execution and movements. Based on these
simulation models, it becomes possible to analyze and verify the temporal requirements of IoT
systems.

Design of a Formal Verification and Evaluation Tool of RT Tasks Scheduling of IoT . RT IoT
applications are becoming increasingly important, posing challenges in terms of task schedul-
ing and communication delays. The study in [116] points out the importance of reliable com-
munication with minimal delays particularly for applications in healthcare and smart homes,
enabled by technologies like 5G. and reviews the history of simulation tools for real-time sys-
tems, highlighting their limitations and the need for web-based tools adapted to IoT contexts.

69
The authors in [116] propose a web-based tool for feasibility analysis and task scheduling in
real-time IoT systems. It leverages web technologies for remote access and tracking of real-time
tasks. The paper highlights the novelty of a web-based approach for real-time task visualiza-
tion, simulation, and tracking, with potential applications in IoT and smart cities aiming to
bridge the gap by proposing a novel tool for simulation, monitoring, and tracking in RT-IoT
applications, filling a crucial void in the field.
The proposed system architecture focuses on the development of a cloud-centric web-based
tool for simulating, visualizing, and tracking IoT tasks. This architecture aims to address the
limitations of existing tools, such as platform dependency and failure to keep up with modern
technology trends. The key modules of the architecture illustrated in 3.4 include Input, Pro-
cess, and Output.

Figure 3.4: Sitemap of the Proposed Web-based Visualization Tool [116]

• Input Module deals with task generation and configuration. Users can add, edit, upload
tasks, or delete them. The tasks can be of two types: periodic or event-driven. Common
task attributes include start time, execution time, period, deadline, urgency, and slack.
The input module allows users to create and configure tasks for analysis.

• Process Module applies scheduling algorithms to the input tasks. The proof of con-
cept considers two existing algorithms: Earliest Deadline First (EDF) for event-driven
tasks and Rate Monotonic (RM) for periodic tasks. The process module is responsible for
scheduling tasks based on these algorithms.

• Output Module presents the results of the scheduling algorithms in an effective user
interface. It provides various interfaces for different scheduling algorithms, focusing on
improving the user experience. The output includes performance measures like CPU
utilization, missed tasks, completed tasks, and timelines of task instances.

The interaction model involves the sequence of interactions among the task input module,
input buffer, algorithm controller, and visualization using the Model-View-Controller (MVC)

70
architecture. Users can initiate random task generation, which creates tasks based on their in-
put parameters and stores them in a CSV file. which is loaded into the input buffer, and virtual
instances of tasks are created for scheduling using the algorithm unit. Users can interact with
the visualization module to understand the response of input tasks using the specified algo-
rithms. The results are presented in HTML format through the MVC view and rendered to the
application user. The system can simulate and analyze the behavior of input task sets, evaluate
the feasibility of scheduling algorithms, and visualize results. The architecture is designed to
be cloud-centric, making it accessible remotely and leveraging modern web technologies for
improved user experience. It aims to be platform-independent and compatible with the latest
technology trends, enhancing the efficiency of real-time systems’ feasibility analysis and for-
mal proof. The system can be used in an IoT environment to schedule and monitor physical
tasks while ensuring they meet their deadlines. The system was implemented using a combi-
nation of technologies and tools for both the cloud-centric web application and the Raspberry
Pi-based IoT server. Here are the key implementation details:

• Cloud-Centric Web Application Environment:

Operating System: Linux-based AWS EC2 Compute Node.
CPU: Intel Core i5-4570 CPU @ 3.20 GHz.
Memory: 12 GB RAM.
Integrated Development Environment (IDE): PyCharm, Sublime Text 3.
Framework: Flask MVC (Model-View-Controller).
Core Programming Language: Python 3.
Libraries: Jinja 2, CSV Parser, Bootstrap 3, HTML 5/CSS3.
Persistence: CSV (for data storage).

• Raspberry Pi-based IoT Server Environment:

Hardware: Raspberry Pi 3 Model B. Operating System: Raspbian (Linux-based OS for
Raspberry Pi).
Memory: 1 GB RAM.
Server: Flask Web Server (for serving HTTP requests).
Connected Resources: LED, Fan, Temperature Sensor, Humidity Sensor, Breadboard, Ex-
pansion Board, Connecting wires, e-Health Sensor Platform.
Libraries: GPIO (General Purpose Input/Output control for Raspberry Pi), CSV Reader,
Jinja Template, Bootstrap 3, HTML 5/CSS3.
Integrated Development Environment (IDE): Vim, PyCharm.
Programming Language: Python 3.

The cloud-based web application communicates with the Raspberry Pi-based IoT server using
the HTTP protocol. The IoT server listens to incoming requests, processes them, and controls
various physical resources connected to it, such as LEDs, fans, sensors, etc.
The authors perform an experimental test bed for the proposed approach where the system
classifies tasks into two main types: critical tasks with a priority of 1 and non-critical tasks
with a priority of 0. For non-critical tasks, the system uses three physical IoT resources: a tem-
perature sensor, an LED actuator, and a fan actuator. On the other hand, critical tasks involve
the use of an e-Health sensor platform with two sensors, which are used to monitor the ECG
and pulse of elderly individuals under observation. The tasks are periodically simulated to
assess their response time and whether they are executed within specified deadlines. Input
parameters are provided via the web interface. The tasks associated with physical resources
communicate with a Raspberry Pi at predetermined times specified by the main algorithm.
This communication is achieved using general-purpose I/O (GPIO). The status of the algo-
rithms and tasks is displayed in real-time on the bash terminal of the Raspberry Pi and con-

71
nected devices, particularly for actuating devices like a fan. When both critical and non-critical
tasks are present in the system at the same time, the system gives priority to critical tasks. This
is indicated by unique color codes in the system (Rate-Monotonic (RM) is a priority-based
scheduling algorithm commonly used in real-time systems).
A Teleo-Reactive Node for implementing IoT Systems. A research paper [117] focuses on
addressing challenges in IoT system development by proposing the adoption of the Teleo-
Reactive (TR) approach. It highlights the importance of accommodating non-technical users
and achieving higher levels of abstraction in IoT development. TR approach was initially in-
troduced by Nilsson in [118] for autonomous agents operating in dynamic environments. The
TR approach focuses on achieving goals while constantly sensing and reacting to changes in
the environment. TR programs are structured as sets of rules, where each rule consists of a
condition based on perceptual inputs and environmental models and an associated action that
affects the environment. Rules are prioritized, with most rules taking precedence. TR pro-
grams allow for the hierarchical decomposition of goals, enabling both discrete and durative
actions, which can be started, stopped, and modified by the execution of other rules.
The extension of the original TR language, TeleoR, is introduced [119], which features a multi-
task agent architecture (c.f. Figure 3.5) with four main elements: the BeliefStore (BS) for agent
knowledge, the Percept Handler for converting sensor data into environmental information,
the Message Handler for storing inferred beliefs, and the TeleoR Evaluator for evaluating rules
based on the BS to trigger associated actions.

Figure 3.5: Multi-threaded TeleoR architecture [119]

TeleoR extensions optimize the semantics model and enhance action specification. These ex-
tensions include actions that modify the BeliefStore, send messages for concurrent executions
with other agent actions, sequence time-limited durative actions (including procedure calls),
repeated actions within specified time intervals resulting in the firing of other rules, and ac-
tions that receive messages from other agents and update the BeliefStore. Since the authors aim
to provide a more user-friendly and abstract approach to IoT system development, making it
accessible to a broader range of users, they review approaches to IoT system development
and the result is using general-purpose programming languages, which demand substantial

72
developer expertise and MDE[120] which aim to automate model-to-code transformations. In
this context, authors found several MDE-based approaches like IoTSuite [121] which separates
concerns in IoT development and simplifies application logic using high-level languages but it
still requires general-purpose programming languages for implementing application logic, Di-
aSuite [122] pervasive systems related to IoT, simplifying the design phase with architectural
descriptions. It necessitates Java for implementing application logic, which can be burden-
some and PervML [123] that enables pervasive system development with UML-based models
but specifying services using UML diagrams may be complex and require additional effort.
The authors emphasize that these approaches often rely on UML or GPLs for behavior specifi-
cation, which can be challenging for engineers.
The authors introduce the TR Node (c.f. Figure 3.6) that comprises various hardware compo-
nents, including RF antennas for communication, power supply systems, sensors, actuators,
data conversion modules, clocks, status LEDs, and memory. These components enable the
node to sense the environment and perform actions based on its TR program. The TR Node’s
software consists of the TR code, TR interpreter, and an operating system layer with libraries.
The TR code defines the node’s behavior, while the TR interpreter translates this code into
executable instructions for the CPU. The software layer communicates with the hardware, re-
ceiving sensor data and sending commands to actuators.

Figure 3.6: Details of the hardware and software of the TR node [119]

The TR Node can be configured to operate in three different functional modes: Local Node
(LN), Local Coordination Node (LCN), and Coordination Node (CN). These modes determine
the node’s roles and hierarchical positions within the IoT network. LN nodes primarily sense
and react to the environment, LCN nodes coordinate lower-level nodes and interact with exter-
nal services, while CN nodes focus on high-level coordination and internet connectivity. The
TR Interpreter module is a critical component that translates TeleoR program rules into Erlang
code for IoT nodes. It follows a systematic process: first, it structures the TR program’s goals
in Erlang, using pattern matching to execute the first satisfied condition. Then, it evaluates
conditions based on percepts, beliefs, variables, and comparisons with values, and triggers
actions accordingly. Beliefs and variables in the BeliefStore module are updated through Er-
lang functions, and the interpreter handles remembering and forgetting beliefs. Additionally,
it manages message communication and proposes using MQTT, specifically EMQ, for inter-
node communication in IoT architectures. This approach enables customizable behavior and
communication in IoT systems.

73
Additionally, the authors have developed a tool for editing TeleoR programs, which is im-
plemented using Eclipse Xtext and Xtend (c.f. Figure 3.7). This tool offers a domain-specific
language for editing TeleoR programs, syntax validation, and automatic code generation for
Raspberry Pi devices. A configuration file is used to specify the correspondences between
device inputs/outputs and the TR agent’s percepts and actions. The combination of these
modules and the development tool provides a comprehensive framework for developing and
deploying TeleoR-based IoT systems with Erlang on Raspberry Pi devices.

Figure 3.7: TR program editor implemented using Eclipse, Xtext and Xtend [117]

Bottle collecting robot case study. The authors deployed a simulation of a bottle-collecting
robot using a Raspberry Pi as the hardware platform, Linux-based operating system support,
and an Erlang virtual machine. The hardware setup included LEDs and switches to emulate
the robot’s environment. The experiment involved running the robot simulation with differ-
ent states and events to compare the computational performance of the Erlang implementation
with a Python implementation. They measured CPU load and memory usage during the tests.
The Erlang implementation exhibited higher CPU usage due to its concurrent nature, as it has
multiple processes running concurrently. The Python implementation, being sequential, had
lower CPU usage. Memory usage was similar in both implementations, with around 550 MB
of free memory and 700 MB of available memory. The power consumption for both imple-
mentations was comparable. The Erlang implementation showed higher CPU usage, which
is expected given its concurrency features. However, memory usage and power consump-
tion were similar for both implementations. The authors concluded that developers should
consider the novel approach (Erlang) due to the facilities it provides for implementing and
evolving IoT systems and discuss the use of the TR approach for IoT nodes and its feasibility
for simplifying the specification of complex IoT systems.

Formalizing ECG signal behavior. Al-Hamadi et al. in [124] discussed some of the challenges
and issues related to the development of information and communication technology health-
care systems, with a specific focus on ECG and formal verification methods. Authors highlight
that guidelines for interpreting ECG signals may have ambiguities and inconsistencies due to
the complexity of this sensor and their informal presentation. Formal methods, which involve

74
systematic mathematical reasoning, can be used to enhance trust in healthcare systems. The
paper discusses the use of Event-B [125], a formal language for modeling and verifying reac-
tive and distributed or concurrent systems which allows for rigorous abstraction and steps of
refinement to obtain concrete specifications and verify them based on predefined invariants.
Event-B comprises two main constructs: The machine that defines the dynamic behavior of the
model, contains the system variables, events, and invariants and the context that defines the
static behavior of the model, contains carrier sets, constants, axioms, and theorems.
The authors provide detailed specifications of the ECG and how it represents the electrical ac-
tivity of the heart. It describes the fundamental components of the ECG signal and how they
are generated. The generation of the ECG signal occurs in three phases (c.f. Figure 3.8). The
first phase involves the activation of the atria, which generates the P wave. The second phase,
the activation of the ventricles, produces the QRS wave. The third phase is the recovery phase
which generates the T wave as the heart muscles recover.

Figure 3.8: ECG Waves and Their Relation to Heart Nodes [124]

There are also flat segments representing no activity between these waves during certain pe-
riods. The frequency, duration, and presence or absence of these waves and segments bring
important information about the heart’s condition, such as whether it’s functioning normally,
abnormally, quickly, or slowly. The ECG signal can be divided into active waves consisting
(c.f. Figure 3.9) of P, QRS, and T waves, each exhibiting different behaviors and durations and
idle segments include PQ-segment, ST-segment, and TP-segment, with similar behavior but
different durations.

75
 Figure 3.9: ECG Signal Specifications [124]

To distinguish different ECG signals representing heart activity. These signals are divided into
segments and waves, and their sequences (c.f. Figure 3.10) are defined through a series of
labeled activities. When the heart initiates its activity from the idle segment labeled as number
1, the heart’s nodes’ functionality can result in four distinct cases:

Figure 3.10: ECG Waves Behaviors [124]

1. Neither the sinoatrial (SA) node nor the atrioventricular (AV) node is functioning, result-
ing in a lack of pulse(Block 1).

2. Only the SA node is functional, leading to the generation of P wave signals, possibly
alternating with idle segments, This represents an abnormal behavior of the heart system
(Repeating block 2 or alternating between blocks 2 and 3).

3. Only the AV node is functional, producing QRS wave signals with the possibility of T
waves and idle segments. The first one occurs for fatigued ventricles activation, where
QRS is continuously repeated (repeating Block 5). The second situation occurs for a less
fatigued ventricles activation, where there is a segment between each successive QRS

76
 waves (repeating blocks 5 and 6). The third situation occurs when the heart system has
the opportunity to recover from the activation of the ventricles, where the QRS wave
and the T wave are generated with idle segments in between(repetition of the sequence
of blocks 5, 7, 8, and 9).

4. Normal heart behavior, where both the SA and AV nodes are functional, leading to the
sequential generation of P, QRS, and T waves with idle segments (repetition of the se-
quence of blocks 2, 4, 5, 7, 8, and 10).

The ECG signal can transition between these cases depending on the functionality of the
heart’s nodes. Any interruption in the functioning of the SA or AV node or the ventricles’
activation recovery can change the ECG signal’s state.

Formalizing ECG in EVENT-B. The Event-B model encompasses several essential compo-
nents, including the context, machine, events, axioms, and invariants. The context primarily
serves to model the static aspects of the system through axioms. Meanwhile, the machine is
responsible for addressing the dynamic facets through a series of events. The desired system
properties are described using invariants, and design constraints and constants are represented
through axioms. Events feature guards, and they can only be executed when these guards are
evaluated to be true.
First, the Authors employ an Event-B context to define the fundamental parameters of the
ECG signal using sets and constants. Additionally, several axioms are used to represent facts
regarding the ECG signal within the heart system. Two main sets are defined: ECG State
and WavType. The ECGState set comprises four distinct states: Idle, Pwave, QRSwave, and
Twave. It is defined using an axiom. The WavType set is used to categorize various types of
waves within the ECG, including P, QRS, and T waves, defined in another axiom.
Moreover, various constants related to the duration of the ECG cycle, such as P duration
(PDura), QRS duration (QRSDura), and T duration (TDura), are introduced. These constants
are defined as natural numbers through different axioms. Furthermore, additional properties
about wave durations, such as QRS having the shortest duration among all waves, are speci-
fied through axioms. The formalization of the ECG context in Event-B is presented below:
CONTEXT C ECG
SETS
ECG S t a t e WavType
CONSTANTS
I d l e Pwav QRSwav Twav
PDura QRSDura TDura
P QRS T
AXIOMS
axm1 : p a r t i t i o n ( ECGState , { I d l e } , { Pwav } , {QRSwav } , { Twav } )
axm2 : p a r t i t i o n ( WavType , { P } , {QRS } , { T } )
axm3 : PDura ∈ N ∧ QRSDura ∈ N
axm4 : TDura ∈ N
axm5 : QRSDura < PDura ∧ QRSDura < TDura
END
The dynamic aspect of the system consists of several events with non-deterministic behavior.
These events can occur only when their guard conditions are met. In the Event-B model, two
record variables, ECG rec, and Wav rec, are introduced. ECG rec is responsible for recording
the history of the ECG indicates the type of the ECG signal at any given point in time and is
defined as a function from natural numbers to the set ECG State. Wav rec is responsible for
recording the history of ECG waves only and is defined as a function from natural numbers to
the set Wav Type. These two variables are used because some ECG specifications are related
to the occurrence of active waves only, while others involve the occurrence of active waves
and/or idle segments. To validate the ECG signal, the authors derived several properties from
its specifications and modeled these properties using Event-B invariants. One such property
as an example, defines that the model should have a state at any point in time. In other words,

77
ensures that for each point in time (x), there exists a corresponding state (y) in the ECG State
that is represented in the ECG record.
inv : ∀ x · ∃ y · x ∈ dom(ECG r e c ) ∧ y ∈ ECG S t a t e ⇒ ECG r e c ( x ) = y
The advantages of embedding ECG signal behavior in Event-B include the ability to verify
properties related to specifications, which are often overlooked by existing methods focused
on diagnosis. This approach ensures consistency and helps identify issues in incomplete or
incorrect interpretations of ECG behavior.

Formal language specifying the behavior of IoT devices. In [126] End-User Development
(EUD) was introduced as a solution that allows non-professional users to create, modify, or
extend software systems. The focus of this paper is on the development of the EUDroid sys-
tem for the management of pills in a therapy context, primarily aimed at older people and
caregivers. The system comprises three main components: a smartphone app, an IoT de-
vice for pill reminders, and a web server for therapy scheduling.P. Buono et al. present a
formal language (EUDroid) to define the behavior of IoT device components, including LEDs,
buzzers, and actuators. The language is divided into electronic components and another for
Event-Condition-Action (ECA) rules. Electronic components have properties like delay and
duration, which determine when and how long a component is active. Actuators are classified
as sensors or actuators and include red, blue, green, and yellow LEDs, along with a buzzer.
The buzzer operates with an inverse logic compared to LEDs. A message component allows
users to customize messages to be displayed in the mobile app. The actuator set (AT) can be
extended to accommodate additional devices.
EUDroid allows users to define custom events based on specific criteria and associate actions
with them. These elementary events can be combined to create composite events that are often
linked to the calendar, specifying start dates and execution times. Users can control the be-
havior of IoT devices by defining triggers and corresponding actions. The Arduino controller
reads and interprets commands sent from the web server, specifying pin positions and states
of elementary components. The EUDroid formal language offers a robust tool for controlling
the behavior of IoT devices and enables users to change the behavior of their systems to meet
specific needs in various contexts. The presented case study of the pill reminder IoT device
demonstrates how the EUDroid formal language is implemented in a real-world application,
emphasizing its flexibility and practicality in controlling IoT devices and improving user ex-
periences.
The user interface follows the ECA paradigm, where users define conditions, and the system
reacts by activating actions. Users can create rules step by step, and these rules are sent to the
web server and converted into commands following the formal language. The communication
between the app and the server is two-way, allowing users to check for stored events on the
server, associate multiple actions with a single specific event, such as taking multiple pills si-
multaneously, and choose which LED should be turned on for each pill. The web server acts
as a middleware, storing user-created rules in its database, checking their compliance with the
formal language in the app, and scheduling rules. The interaction between the pill reminder
box and the app is mediated by the web server, which constantly controls and schedules all
rules. When an event occurs, the server sends a command to the pill reminder box, which
activates the required actuators. If the user presses the button, the server’s rules for checking
if the pill has been taken correctly are interrupted. In case of no interaction between the user
and the pill reminder, a reminder procedure is initiated, which includes activating the buzzer
and sending a message to the user’s smartphone.

Things as a Service: Service model for IoT. The paper [127] highlights that while there’s ex-
tensive research on IoT services for various applications, there’s a lack of standardized mecha-
nisms for modeling IoT-based systems. The concept of Things as a Service (TaaS) is introduced

78
in figure 3.11, aiming to deliver IoT data as a service to end-users. However, it notes that
many IoT services lack data context, limiting interoperability and analytical capabilities. The
authors propose a formal IoT service model that includes physical properties of "things" and
context association. It suggests using the Semantic Sensor Network (SSN) ontology for context
representation. The IoT service model should also support exposing "things" physical proper-
ties and event-based interactions. The proposed approach extends a generic IoT architecture,
where "things" use gateways to communicate with enterprise back-end servers. It introduces
a cloud-based system for IoT services that includes features like discovery, selection, contract
negotiation, and composition.
This approach starts by defining devices in IoT, which can be sensors or actuators, and their
attributes. These devices are then used to model services. In the context of IoT, these devices
are named "things" which define the TaaS that allows interface-based access to the capabilities
of "things" over the internet which are defined by its unique interface address.

Figure 3.11: Architectural Framework for Thing as a Service [127]

Weather monitoring system. The authors describe an implementation of a weather moni-

toring service to demonstrate the benefits of the proposed model, emphasizing its capacity
to provide context-aware service discovery and composition. The system uses a DHT22 sen-
sor module installed on a Raspberry Pi 3B+ board to monitor temperature and humidity. A
Node.js REST service is employed to provide access to device profiles, temperature, and hu-
midity data in JSON format. The device profile includes essential parameters like Things ID,
deployment platform, supported protocol, service type, endurance, up-time, and device infor-
mation. Subsequently, the service data is mapped to the SSN ontology, producing context-rich
RDF data. This demonstrates the model’s capability to expose device profiles to users, facil-
itating context-aware IoT service discovery and composition. Furthermore, the model’s in-
corporation of relevant context with the "things" data enhances its utility in various analytics
scenarios.

3.2.2 Formal instantiation of MDE.

Carlos A. Gonzalez et al. in [128] highlight a significant lack of tools specifically designed for
the verification of EMF models within the Eclipse environment. Existing tools mainly focus

79
on the verification of UML/OCL class diagrams, which often involve transforming diagrams
into formalisms for efficient solvers or theorem provers. They discuss the need for mecha-
nisms to ensure the quality and absence of errors in MDE artifacts which ensure the quality
and correctness of models to maintain the reliability of the MDE-based development process.
Also, they note that formal methods have been used successfully in the verification of software
and hardware systems. These methods provide a way to rigorously verify the correctness of
systems. However, using formal methods for MDE can be challenging due to the complexity
of the problem which can make the adoption of formal methods less practical. They intro-
duce EMFtoCSP, a tool for verifying EMF models with OCL constraints. EMFtoCSP translates
models into Constraint Satisfaction Problems (CSPs) [129] for verification and supports vari-
ous correctness properties. The tool is flexible and can be used for a wide range of models,
including DSML.
EMFtoCSP (c.f. Figure 3.12) is introduced as a tool for fully automatic, decidable, and ex-
pressive verification of EMF models extended with OCL constraints. The approach follows a
bounded verification strategy, which ensures termination by limiting the search space based on
instance and attribute domain restrictions. In constraint programming, problems are framed
as CSPs, defined by a set of variables, domains for those variables, and constraints that express
relationships between variables where the goal is to find a solution that satisfies all constraints.
The primary technique for solving CSPs is backtracking, combined with constraint propaga-
tion methods. Backtracking involves attempting to assign values to variables, backtracking
when constraints are violated, and continuing until a solution is found or all possible assign-
ments are exhausted. Termination is ensured by constraining variable domains to be finite.
EMFtoCSP uses the ECLiPSe Constraint Programming System [130], which handles various
constraint types expressed as predicates in a Prolog-based language, stored in ".ecl" files, and
loaded into the solver for analysis. The verification process is divided into two subproblems
for efficiency: firstly, determine a valid population size for the model. This involves deciding
the number of instances of each class and associations that constitute a valid solution and sec-
ondly assigning legal values to all attributes of objects and association ends and checking if
the assignment constitutes a valid solution.
EMFtoCSP offers a user-friendly GUI that leads users through several steps, including speci-
fying OCL constraints, setting search space limits, choosing verification properties, and select-
ing output locations. Also, It provides feedback on whether the input model satisfies selected
properties and, if so, generates a valid model instance demonstrating the property.

80
 Figure 3.12: EMFtoCSP architecture [128]

The tool’s architecture consists of the "ECL Generator" subsystem, which handles user inputs,
and a connection to the ECLiPSe. The "ECL Generator" subsystem includes three components
responsible for translating the model, constraints, and properties into ECL code for the solver
using Eclipse’s EMF and OCL parsers. The generated ECL code is sent to ECLiPSe for prop-
erty verification. ECLiPSe’s feedback is interpreted, and results are displayed to the user. If the
model satisfies the properties, EMFtoCSP uses GraphViz to visually represent the valid model
instance.
The scalability of the tool is influenced by the complexity of the model’s constraints (c.f. Fig-
ure 3.13) and the generated CSP. Two main factors are considered: The extent to which con-
straint propagation can be used to solve the CSP (minimizing backtracking), and whether the
CSP is non-trivially unsatisfiable.

Figure 3.13: Meta-model for Entity-Relationship diagrams and OCL invariants constraining
the choice of identifier names [128]

81
For satisfiable cases with reasonable ranges, EMFtoCSP efficiently finds valid instances of ER
models with several hundred objects, using linear constraint propagation for determining link
set sizes and attribute assignments. The tool’s scalability is maintained even when changing
upper multiplicity bounds. On the other hand, unsatisfiable cases, where constraints cannot
be met due to a lack of required attributes, result in worse scalability. It struggles in these cases
as it attempts all symmetrical link set assignments before reporting unsatisfiability. That’s
why the authors note that in future work, they will address this scalability challenge by us-
ing symmetry-breaking approaches during the search process. Also, they briefly compare
EMFtoCSP to other tools, such as UML2Alloy [131] and use validation tools, which employ
the satisfiability of a boolean-based solvers (SAT). These tools have limitations related to the
encoding of numbers as boolean variables and bit-level operations. EMFtoCSP is presented as
an integrated tool with more straightforward arithmetic expression encoding.

A CSP Approach for Meta-model Instantiation. This paper [132] introduces a comprehensive
approach to generating models that conform to specific meta-models using CSP. The goal is to
efficiently produce a diverse dataset of relevant models for testing model transformations and
designing new meta-models. The approach includes original constraint modeling techniques,
ensuring that the generated models adhere to meta-models and additional OCL constraints.
The paper highlights previous approaches to model generation, which had limitations.
Models represent systems using a modeling language like UML, while meta-models define the
concepts available for creating models. Models should conform to meta-models, which them-
selves conform to a meta-meta-model (Ecore). Meta-meta-models are typically unique and can
define themselves and often come with constraints, expressed as well-formed rules using the
OCL, ensuring that models adhere to the meta-model.
The authors introduce essential concepts related to models and meta-models, their confor-
mance relationships, and constraints using the case study of Petri nets presenting concepts
like places, transitions, and arcs, along with their properties. They outline the key properties
expected from a model generation mechanism: Several essential properties are expected from a
model generation mechanism such as Scalability. The mechanism should handle large models
and meta-models, crucial for testing model transformations on extensive datasets. Generated
models must adhere to their meta-model and meet OCL constraints. The model generation
process should be easily configurable for various purposes, such as testing model transforma-
tions or adapting meta-models. Generated models should be representative of the meta-model,
covering its structure while providing a wide range of model variations. The authors discuss
some related work in the field of model generation, primarily within the context of MDE such
as Random Graph Generation [133] which utilizes random tree generation to create models
but only produces skeleton models, ignores OCL constraints, and lacks flexibility, Grammar
Graph-Based Approach [134, 135] which employs elementary grammar rules for meta-model
encoding but struggles with OCL constraints and external constraints. Alloy Language Trans-
lation [136, 137] where the user needs to translate meta-models and OCL constraints into the
Alloy language and use the Alloy solver but scalability and quick solution retrieval are issues.

This paper cites Cabot et al. [128] work which proposes a model generation approach based
on CSP where they encode the meta-model and OCL constraints into CSP, using the ECLiPSe
solver but scalability issues are noted and the lack of optimization in there works. A com-
parison (c.f. table 3.2) of the presented paradigms is provided based on scalability, validity,
flexibility, and diversity criteria where none of the approaches fully satisfy all these criteria.

82
 Approach Scalability Validity Diversity Flexibility
Random graphs ? No No No
Grammar graphs Yes No Yes No
Alloy No Yes No Medium
CSP No Yes Possible Yes

Table 3.2: Comparision of the different approaches for model generation [132]

Regardless of the result of this comparison, the authors suggest that CSP-based approaches
can address scalability, diversity, and flexibility challenges through improved modeling tech-
niques. In this context, a CSP model for meta-models and OCL constraints is presented. The
key points include the following classes in the meta-model are represented by instance vari-
ables and feature variables. The domains of these variables are determined based on the min-
imum and maximum instance constraints for each class. The value 0 indicates non-allocated
instances. A Global Cardinality Constraint is imposed to ensure that values assigned to in-
stances of different classes are unique. References between classes are treated as pointers from
instances of the source class to instances of the target class, reducing the number of required
variables. Constraints involving reference navigation are handled by checking the equality be-
tween reference and instance variables. Constraints related to collections are transformed into
the global constraint Alldiff for efficiency.
The authors performed a comparison to the previous CSP Model [128] and addressed limita-
tions. They employ instance variables, use global constraints, reduce disjunctive constraints,
optimize reference modeling, and provide an accurate representation of OCL constraints based
on their specific characteristics. The experiments (c.f. Figure 3.14) involved transforming
meta-models into CSP problems and writing CSP instances in the XCSP format. Several meta-
models were employed for the evaluation such as Petri-Nets, Entities and Relationships, B
language specification, and Sad software architecture meta-models.

Figure 3.14: Comparing all meta-models experiments results [132]

The authors compare their solution with Cabot et al.’s EMFtoCSP tool, demonstrating the ef-
ficiency of their CSP model, with a particular focus on the Entities and Relationships meta-
model. Results indicated that their solution was eight times faster in terms of resolution time.
The authors aimed to expertise their solution’s performance scalability concerning different
meta-model sizes. The outperforming of their solution was attributed to various factors, such

83
as the use of variable sets instead of lists, the incorporation of global constraints, the repre-
sentation of class references as pointers, and the detailed modeling of OCL constraints. While
their approach remained efficient for large meta-models with numerous classes, its efficiency
was slightly reduced when generating a large number of instances for meta-models with fewer
classes due to the rapid increase in variable modeling references. This approach shows great
promise, enabling the generation of models that adhere to OCL constraints, even for large
instances, within a reasonable timeframe compared to previous methods.

3.2.3 A Scalable Distributed Architecture Towards Unifying IoT Applications

This paper [138] cites that existing works for IoT architectures often target specific application
domains and lie in the absence of a unified architecture suitable for a global IoT infrastruc-
ture. For instance, Castellani et al. [139] designed an architecture for a smart office application,
primarily concentrating on connecting wireless sensor networks and actuator networks to the
internet as web services. Similarly, the EPC global IoT architecture in [140] addresses RFID
networks and smart logistics systems. These architectures are targeted to meet the needs of
particular application areas. This gap highlights the need for a more comprehensive and ver-
satile IoT architecture that can seamlessly integrate diverse application areas. To address these
challenges, the article proposes a distributed, interoperable architecture for IoT. It provides dif-
ferent levels of abstraction to make IoT systems work together seamlessly. It emphasizes the
need for seamless integration of diverse devices and introduces the concept of a layered ar-
chitecture called the Distributed Internet-like Architecture for Things (DIAT) to address IoT’s
technical challenges. IoT’s evolution includes connecting non-communicable objects for futur-
istic services. The desired characteristics of IoT include automation, intelligence, dynamicity,
and zero-configuration support such as plug-and-play devices in the system [141]. The au-
thors mention that some researchers have proposed layered architectures and suggested SOA
as a potential approach [142, 143] but these approaches may not address IoT challenges such
as interoperability and scalability. The initial proposed Architecture in this paper is presented
in 3.15

Figure 3.15: A layered architecture for the Internet of Things [138]

This architecture consists of three main layers: Virtual Object Layer (VOL) which virtualizes
physical objects, provides semantic descriptions, and bridges the gap between the physical and
cyber worlds. Composite Virtual Object Layer (CVOL) which coordinates multiple physical
objects to achieve tasks. It creates Composite Virtual Objects (CVOs) by combining individual
Virtual Objects. It optimizes operations and handles the discovery of suitable VOs and CVOs,
and Service Layer (SL) which manages service creation and execution. It handles service re-
quests, decomposes them into subtasks, and determines how to assemble these subtasks to
achieve the final goal.

84
One of the primary tasks of the SL is Observer (c.f. Figure 3.16) which is responsible for
automating the creation of services and facilitating intelligent machine-to-machine (M2M)
communication. It continuously monitors various objects, assessing their situations based on
contextual information and knowledge. The Observer’s functionalities and workflow extend
across CVOL and the SL.

Figure 3.16: Functionalities and work-flow of an observer [138]

To enable automated services, the Observer relies on context awareness, a fundamental aspect
of the IoT. It evaluates the situations of both human and non-human objects and maintains
contextual information within associated vectors.
For human objects, the contextual information includes the current Location which provides
high-level information about a person’s current location, derived from low-level data. It can
indicate locations like atHome, atOffice, and more. An expected location sub-field helps iden-
tify deviations from scheduled locations, triggering relevant service requests, and operating
state that indicates a person’s current activity, such as inMeeting or watchingTV to initiate ser-
vice requests. An expected operating state sub-field helps detect inconsistencies and generate
service requests accordingly and the Next Job Queue outlines upcoming tasks derived from to-
do lists or calendar events, including notification time and complementary service sub-fields.
For non-human objects, the contextual information includes Attention Flags which indicate
anomalies or issues with non-human objects, with urgency levels dictating response times,
and Working Neighbor Group which creates groups of similar objects within specific areas
where objects within these groups can communicate, coordinate, and optimize performance.
The Observer can detect anomalies in one object by consulting with other group members and
setting the appropriate attention flag.
The three layers were presented as IoT Daemon (c.f. Figure 3.15), this IoT Daemon is present
in every device, running all three layers. It ensures interoperability, supports automatic ser-
vice creation, smart execution, and dynamic adjustments, and minimizes the need for human
intervention in end-to-end communication. This daemon aids in achieving scalability without
manual configuration, adhering to the zero-configuration requirement. It effectively addresses
device heterogeneity by creating digital representations of physical objects in the VOL through
APIs and interconnections across the three architectural layers. The Authors also provide a
comparison of DIAT with other IoT architectural efforts (c. Table 3.3), suggesting that DIAT
offers promise in addressing technical challenges and providing key IoT characteristics using
a multi-application use case.

85
 IoT Characteristics DIAT Butler Compose IoT-A
Heterogeneity yes partially yes yes
Scalability yes no no -
Interoperability yes no partially yes
Automation yes yes partially yes
Zero-configuration yes no no partially
Distributiveness yes partially no -
Layered design yes no yes no

Table 3.3: Comparison among Architectural Proposals [138]

The use case encompasses various IoT applications, including smart home, smart transporta-
tion, and smart healthcare where each object is equipped with an IoT Daemon that runs the
architecture’s layers regardless of its application domain. This use case presents how IoT Dae-
mons can collaborate across various application domains to perform a complex, unified task.

3.3 Signal synchronization

In parallel computing and distributed systems, where multiple streams of information operate
simultaneously, signal synchronization becomes essential to maintain order, consistency, and
coherence. This process involves aligning and coordinating signals or events across different
streams to avoid conflicts, race conditions, and data inconsistencies. Efficient signal synchro-
nization ensures that concurrent processes can communicate effectively, exchange information
reliably, and operate in a synchronized manner. The goal of signal synchronization is to or-
chestrate the flow of data and activities, enabling parallelism without sacrificing data integrity
or system stability.

3.3.1 Clock Synchronization Protocols

GPS-based approach. The paper [144] discusses the challenges of clock synchronization in
distributed systems and introduces a decentralized GPS-based approach integrated with the
NTP to enhance accuracy. Clock synchronization protocols are categorized based on properties
such as logical and physical time synchronization. The authors compare the existing solutions
(c.f. Table 3.4) and highlight the precision levels of protocols like NTP, PTP, and DTP. The
proposed system uses GPS-enabled NTP nodes (GNTP) to synchronize clocks, selecting nodes
based on stratum number, data center locations, and accuracy over cost factors, resulting in a
synchronization algorithm, and experimental analysis shows improved accuracy compared to
traditional NTP.
Protocol Precision Scalability Hardware requirements
NTP us Good None
PTP sub-us Good PTP-enabled devices
GPS ns Bad Timing signal receivers, appropriate cables
DTS ns Good DTD-enabled devices
GNTP sub-us Good Timing signal receivers, cables

Table 3.4: Comparison between different existing protocols with GNTP protocol [144]

The authors distinguish between logical time, which suffices in some cases, and the need for ac-
curate synchronization with physical time in most scenarios. The challenges of achieving high
precision in clock synchronization in complex network scenarios are addressed, with examples

86
of control algorithms designed by Li et al. [145] and synchronization methods in wireless mesh
networks by Reichman et al.[146]. Different approaches, such as the PALS [147] and the use
of physical clock signals, are introduced to enhance synchronization accuracy. In this paper,
the focus was on the effectiveness of GPS timing signals which concludes the limitations of
existing clock synchronization protocols like NTP and PTP.
The proposed approach focuses on enhancing clock synchronization by synchronizing nearby
clocks with GNTP servers (c.f. Figure 3.17). These GNTP servers, designed for high accuracy
comparable to atomic clocks, are particularly targeted for nodes requiring more precise time-
keeping than traditional NTP synchronization offers. To accomplish this synchronization, the
coordination between GNTP servers and client nodes is crucial. Synchronization is conducted
over a wide area network, such as the internet, using the well-known and effective routing
and transportation mechanism of the NTP. The regular NTP protocol is employed, with a key
modification involving fetching timing information from the highly available GPS receivers
associated with GNTP servers. Rules for proper redirection and NTP server selection are en-
forced on each NTP client. These clients maintain information about available GNTP servers
and their respective distances. This information selects the most suitable GNTP server for syn-
chronization.

Figure 3.17: A diagram of circular mapping in NTP hierarchy. The GNTP server can be in-
stalled anywhere according to the demand [144]

GNTP enhancement. The experimental results reveal significant insights into the proposed
GNTP model. The analysis of offset and drift demonstrates the non-deterministic nature of
synchronization errors with higher RTT, where increased RTT correlates with higher offset and
potential errors. The average between RTT and drift graph indicates consistent improvements
in synchronization accuracy, except for a peak caused by connection instability. Furthermore,
the comparison between the RTT of the implemented GNTP server and a traditional NTP
server shows the GNTP server’s superiority, exhibiting lower RTT and improved synchroniza-
tion accuracy. Additionally, the reduced drift in the GNTP server, compared to the NTP server,
underscores the positive impact of server proximity on minimizing synchronization errors and
enhancing precision.

Drift characteristics and Stability of clock hardware. The authors in [51] investigate the
drift characteristics of clock hardware (c.f. Figure 3.18), using Arduino devices. The ex-
periment was conducted in three different locations, each with varying ambient tempera-
tures(14°C,21°C,27.5°C). The experiments involved collecting pairs of timestamps every sec-
ond. The researchers observed that different instances of the same Arduino platform exhibited
distinct drift characteristics and drift rates, resulting in varying clock offsets over the experi-

87
ment’s duration. Furthermore, even the same hardware instance demonstrated different clock
drift rates depending on the ambient temperature. The results illustrated that the impact of
temperature variations on clock drift was noticeable even over short durations, such as 10
minutes. This variability and sensitivity to temperature fluctuations in IoT hardware have im-
plications for clock synchronization in IoT applications.
To evaluate the stability of the clock hardware, the researchers used a typical measure known
as the Allan variance [148]. This metric helps evaluate the clock’s stability. The Allan vari-
ance is calculated based on a series of consecutive offset measurements of a clock, which are
obtained at specific measurement intervals denoted as τ. Researchers often plot the square
root of the Allan variance, known as the Allan deviation. The Allan interception is an essential
statistic that influences the design of rate synchronization and polling behavior in numerous
time synchronization protocols, such as NTP and RADClock. These protocols anticipate that
the Allan intercept will typically fall within the range of τ = 1000 seconds.
The authors conducted a comparative analysis of the clock hardware stability between Ar-
duino devices and the Raspberry Pi3. Their objective was to evaluate the stability of clock
hardware on Arduino devices and compare it with the stability of Raspberry Pi3. Their goal
was to determine if the assumptions used in designing various wired and wireless time syn-
chronization protocols are widely applicable in the context of IoT devices. The observations
made regarding the variations in clock drift characteristics among inexpensive clock hardware
used in typical IoT devices are significant. While differences in manufacturing, environmental
conditions, and crystal aging are well-documented factors contributing to such variations, the
researchers noted that the differences in this case are notably large. In the worst-case scenario,
clock drift reached approximately 600 milliseconds in 10 minutes. This level of variability is
considerably higher compared to traditional PC clock hardware.

Figure 3.18: Comparison of drift characteristics of different Arduino devices (left) and the
same Arduino device under different ambient temperatures (middle) and comparison of Allan
deviation plots of Arduino devices 1 and 3 and Pi3 (right) [144]

Applicability of SPoT for IoT Deployments. These findings highlight the need for new syn-
chronization mechanisms capable of accommodating these challenges. This paper proposes a
synchronization method named Scalable Protocols for Tight Clock Synchronization on IoT De-
vices (SPoT). The SPoT is designed for diverse IoT devices with varying computational capa-
bilities, clock stability, energy constraints, and accuracy needs. It aims to provide lightweight
synchronization algorithms, minimal packet exchange, and adaptability. this method includes
two client types (thick clients and thin clients). Thick clients run synchronization algorithms
locally, while thin clients with limited computational capabilities rely on the server for syn-
chronization. Also, SPoT addresses energy constraints in IoT devices by allowing different
polling regimes and setting Error Margins accordingly. The operation of the architecture in-
volves IoT devices registering with the SPoT server, with thin clients responding to server-
initiated timestamp exchanges, and thick clients executing synchronization algorithms locally
and communicating with the server.
SPoT achieves offset synchronization by addressing forward and reverse path asymmetry er-

88
rors. It identifies the asymmetry direction by comparing computed and expected offsets. The
magnitude of the asymmetry is estimated as the difference in RTT. SPoT then corrects for these
errors using a specific algorithm, adjusting offsets when significant deviations are detected.
This approach ensures accurate offset synchronization in IoT devices. SPoT’s rate synchro-
nization algorithm is essential for estimating and updating clock skew, particularly for devices
with lower-quality clock hardware. Clock skew is needed for accurate clock offset calculations
and to correct clock drift between synchronization points. The algorithm considers the sta-
bility of the clock hardware and determines suitable polling intervals based on it. For stable
hardware, longer polling intervals are chosen, while less stable hardware requires more fre-
quent polling. The algorithm calculates the mean absolute error for a specified observation
time or after a set number of observations and adjusts the polling interval accordingly. Users
can choose between Additive Increase and Multiplicative Decrease (AIMD) or Multiplicative
Increase and Multiplicative Decrease (MIMD) polling styles, depending on their accuracy and
energy requirements. MIMD is more aggressive in increasing the polling interval for lower
energy consumption but slightly reduced accuracy, and users can also adjust the Error Margin
(EM) to trade-off accuracy for lower synchronization costs. SPoT’s implementation consists of
several components to support both thick and thin clients. It includes a core library for syn-
chronization algorithms, a reference server implementation, a reference implementation for
thin clients, and a client emulator for scalability testing. The core library is lightweight and
suitable for resource-constrained IoT platforms, maintaining only a small number of variables.
The reference server can support thick and thin clients and uses asynchronous networking. It
handles device registration, timestamp exchanges, and polling intervals for thin clients. The
client emulator can run multiple thin clients and respond to the server’s timestamp probes,
making it useful for scalability experiments.
the authors evaluate SPoT’s clock synchronization accuracy by comparing it with other syn-
chronization protocols, such as SNTP, MQTT, and MNTP’s filtering methods. The experimen-
tal setup for investigating time synchronization challenges in the IoT ecosystem includes AWS
IoT cloud used for wide-area tests with a co-located message broker, four Arduino MKR1000
devices, and one Raspberry Pi3:

• Arduino MKR1000 uses a low-power ARM MCU, a 2.4 GHz WiFi chip, and a 32.768 kHz
crystal oscillator.

• Raspberry Pi3 features a quad-core ARM CPU, 1GB LPDDR2-900 SDRAM, Ethernet,
WiFi, and Bluetooth.

The authors conducted experiments using an IoT testbed and added observational noise to
collect clock offsets (c.f. Table 3.6). The noise was generated from a normal distribution with
different standard deviations to simulate varying levels of noise. The authors compared SPoT
with other protocols under three noise levels: low, medium, and high. They measured the
RMSE, minimum, maximum, and standard deviation of offset errors for each protocol and
reported the results averaged over 100 runs (c.f. Table 3.5). They also compared SPoT with the
Consensus method and MinRTT, highlighting that thick and thin client implementations offer
the same accuracy.

89
 Protocol Low noise Medium noise High noise
SPoT 10.0(35.6) 9.3(102.1) 8.9(173.4)
SNTP 36.2(36.2) 105.5(105.5) 161.7(161.7)
MQTT 162.5(162.5) 196.6(196.6) 225.7(225.7)
Consensus 9.1(34.5) 27.0(109.8) 42.5(175.7)
MinRTT 8.7(34.8) 21.8(107.0) 41.9(177.5)

Table 3.5: Comparison of synchronization RMSE (ms) values at different noise levels [144]

Protocol Minimum (ms) Maximum (ms) Standard Deviation (ms)

SPoT 0.0(0.0) 47.5(771.36) 7.8(162.4)
SNTP 0.0(0.0) 709.0(709.0) 133.8(133.8)
MQTT 150.0(150.0) 781.7(781.7) 107.6(107.6)
Consensus 0.0(0.0) 253.1(896.6) 32.3(144.9)
MinRTT 0.0(0.0) 417.7(855.1) 40.2(147.6)

Table 3.6: Comparison of offset error statistics under high noise level [144]

Perfect alignment remains unreachable. As mentioned in [149], CPSs integrate computational

algorithms with physical processes, often constituting distributed devices and controllers com-
municating over a network. In these systems, computations are initiated by periodic timers
aligned with local system clocks. Despite efforts to synchronize clocks, perfect alignment re-
mains unreachable, and only relative skew can be bounded. Drawing inspiration from the
hardware community, the GALS design philosophy is commonly employed by embedded sys-
tem designers to model computations in CPS. This approach ensures that computations within
a device occur synchronously with the local clock, while intentionally maintaining asynchro-
nization between nodes. Each device operates independently, executing tasks synchronously
based on its local clock, contributing to the overall efficiency of the system. Additionally, the
periodic nature of computations, coupled with the inherent challenges of clock synchroniza-
tion, underscores the complexity and careful consideration required in the design and imple-
mentation of these networked real-time systems.

3.3.2 Globally Asynchronous Locally Synchronous GALS systems

GALS [67, 109, 150] can be used as a method to synchronize concurrent devices with different
components operating with independent clocks. GALS allows for local synchronization within
individual components or modules, while the global system operates without a single, com-
mon clock. This approach is particularly beneficial in situations where components, such as
processes or devices, need to communicate concurrently but may have different clock frequen-
cies or may be subject to varying delays. GALS architectures provide a way to handle these
differences and enable effective synchronization between concurrent devices. By employing
asynchronous communication links between modules and incorporating local synchronization
within each module.

GALS systems verification. In a real-time IoT The inherent complexity and interactions be-
tween asynchronous and synchronous domains present unique challenges in ensuring the cor-
rectness and reliability of GALS designs. To address these challenges, formal languages, ver-
ification, and validation techniques become indispensable tools in the design, analysis, and
testing of GALS systems [109]. By leveraging these formal methods, designers can rigorously
verify the behavior, interactions, and adherence to specified properties of GALS systems, pro-
viding the necessary confidence in their functionality and performance. By formalizing the
system’s design and properties using mathematical models, verification tools can explore all

90
possible scenarios, detecting potential bugs, race conditions, and deadlocks that might other-
wise remain unnoticed during traditional simulation-based testing. In safety-critical applica-
tions such as aerospace, automotive, or medical devices, the need for correctness and reliabil-
ity is important. Any unexpected failure or miscommunication in GALS systems could lead to
catastrophic consequences.

GALS language for System Level Design. The paper [150] introduces SystemJ, a system-level
programming language designed to model and synthesize multi-clock systems allowing the
increasing prevalence of multi-clock systems in hardware and software due to IP-based design
and distributed architectures, the paper cites the limitations of existing system-level languages.
SystemJ aims to fill this gap by offering a general-purpose language with the capability to
model both synchronous reactive and GALS models of computation. It specifically examines
CRP [151] for its reliance on Esterel [152] and inefficient rendezvous implementation, MC-
Esterel for its low-level design abstraction and hardware knowledge requirements, and SHIM
[153] for limitations in modeling reactivity and the need for early manual hardware-software
partitioning. The paper positions SystemJ as a more versatile solution, capable of overcoming
these limitations by offering high-level abstractions, support for data-driven operations, and
seamless integration with the Java programming language. The objectives of this language
include portability, efficient compilation into Java code, integration of control and data-driven
operations, automated formal verification, and a user-friendly syntax resembling mainstream
languages.

Physically asynchronous logically synchronous. In this paper [154], PALS was also discussed
in detail. It mentions this concept refers to the systems where components operate indepen-
dently in terms of physical timing, but they are synchronized logically to achieve a common
goal. While PALS systems may not be synchronized at the physical level, they often require
some form of logical synchronization to ensure proper functionality. Signal synchronization
mechanisms may be employed within PALS systems to coordinate the timing of signals at a
logical level, even if the components operate with different physical clocks or independently
in terms of physical timing. PALS systems have components that operate independently in
terms of timing (physically asynchronous) but exhibit synchronized behavior at a higher, log-
ical level. In this context, even though the components may not share a common clock or
operate in perfect synchronization at the physical level, they are designed to coordinate and
communicate effectively in a logically synchronous manner. This can involve the use of proto-
cols and mechanisms to ensure that data is exchanged in a coordinated way, even if the phys-
ical timing of the components is not perfectly aligned. In other words, while signal synchro-
nization focuses on aligning signals for reliable communication, PALS systems aim to achieve
coordinated behavior among components despite their independent physical timing.

Asynchronous Testing of Synchronous Components in GALS Systems

The paper [109] discusses the challenges posed by modern complex systems which are dif-
ferent from the traditional synchronous approach used in safety-critical systems like avionics
and nuclear plants. To address the complexity of such modern systems, the paper proposes
a testing methodology for autonomous cars, which contains synchronous and asynchronous
components. The methodology involves synchronous and asynchronous models, functional
unit testing, and behavioral conformance testing, employing formal methods and associated
tools. Notably, it automates the generation of conformance tests for asynchronous components,
making the testing process more efficient and reliable. This approach is demonstrated using
a simple example inspired by autonomous cars and aims to enhance the development and
testing of GALS systems, ensuring their functional correctness and reliability in complex ap-
plications. It uses GALS Representation Language (GRL) and CADP for asynchronous system

91
modeling and validation, TESTOR for conformance test generation, and synchronous testing
with Lutin and Lustre.
The paper describes the GRL model of an autonomous car(c.f. Figure 3.19), which serves as an
illustration of their proposed approach. The model considers the behavior of the autonomous
car interacting with moving obstacles within its environment. The autonomous car comprises
four synchronous components: GPS, radar, decision controller, and action controller, each with
specific roles in the system. These components communicate through various channels.

Figure 3.19: Architecture of the GRL model of an autonomous car [109]

GRL is used to model this GALS system, with synchronous components represented as blocks
and communication channels as media. The interactions between these blocks follow specific
constraints defined in GRL. The map is represented as a directed graph with streets and cross-
roads, and functions are defined to explore this map and compute itineraries. The GRL model
is parameterized by global constants defining the map, initial positions, destinations, obstacles,
and their movements. Each GRL block defines the code executed by the synchronous compo-
nent during each activation (clock instant). For instance, the radar block updates the percep-
tion grid based on input positions and sends it to the action controller through the medium.
GRL media facilitate asynchronous interactions between synchronous blocks and enable pre-
cise modeling of behaviors, such as message buffering and loss. Each medium is connected to
two channels, receive and send, with associated conditions. Its environments provide inputs
to blocks and receive their outputs, controlling the activation of synchronous blocks and their
relative clock speeds. The environment can also contain nondeterministic choices. This GRL
model provides a formal representation of the autonomous car’s behavior, which can be used
for analysis, testing, and validation within the proposed GALS testing methodology. The au-
thors in this paper use the GRL2LNT translator to convert the GRL model into the LNT formal
modeling language, which is compatible with the CADP verification toolbox. This translation
process resulted in a large Labeled Transition System representing the GRL model of the au-
tonomous car. The LTS had millions of states and transitions, which were significantly reduced
after strong bisimulation minimization. They then conducted model checking to verify several
safety and liveness properties that characterize the correct behavior of the autonomous car.
These properties were expressed in MCL, a temporal logic used in the CADP model checker.
One of the properties, for example, ensures that the car’s position is correctly updated after
any movement of the car. The MCL code provided in the paper illustrates this property, using
necessity modality and conditions on the actions and variables involved.
The paper discusses testing techniques for synchronous components in reactive systems, par-
ticularly the use of the testing tool Lurette. Functional testing of a reactive system involves
providing a sequence of inputs and observing the corresponding sequence of outputs. It is
essential to consider previous outputs when determining the next input, as the system may
adapt its behavior based on its environment. Lurette is a testing tool for synchronous pro-
grams. It automates the generation of appropriate inputs for the System Under Test (SUT) and

92
the decision-making process to determine the test result. Also provides an example of using
Lurette to test an implementation of radar in the C language, which is part of the GALS au-
tonomous car system. The radar component processes inputs related to the position of the car
and obstacles and produces a perception grid. Testing the radar component involves generat-
ing a sequence of inputs and observing the corresponding outputs. To define relevant input
constraints for the radar, a scenario is described in Lutin. The scenario considers the posi-
tion of the car and the movement of obstacles while adhering to the constraints of the map.
The scenario specifies how the car and obstacles evolve within the system. However, writ-
ing complex scenarios manually can be error-prone and boring, especially when representing
street names using numerical values. The oracle, implemented in Lustre, defines the expected
output (perception grid) for each input vector (positions of the car and obstacles). The oracle
verifies whether the observed outputs match the expected ones and computes coverage vari-
ables, such as "pass" and "blocked," to measure test coverage.
The paper discusses the concept of test projection and exploration 3.20, which aims to improve
the unit testing of synchronous components within this GALS system.

Figure 3.20: Overview of the derivation of synchronous test scenarios by projection and explo-
ration of an asynchronous complete test graph CTG [109]

The process involves three main steps: Initially, a conformance complete test graph (CTG) is
generated for the entire GALS system. This CTG reflects the interactions and behavior of the
system as a whole. The CTG is then projected onto the specific synchronous component de-
noted as "C" that is being tested. This projection reduces the scope of the test to focus on the
interactions and inputs relevant to the component being tested. After projection, the test graph
for component C is translated and renamed to be compatible with the synchronous testing tool
being used. In this case, Lurette is the tool employed for synchronous testing. The translation
ensures that the test graph aligns with the tool’s requirements and format. In the final step, the
test graph for component C is explored using scripts (such as XTL scripts) to generate input
constraints and the oracle for separate testing. This exploration process defines how the com-
ponent responds to various inputs and defines expected behavior through the oracle.
The benefits of this approach include providing realistic and relevant inputs to the synchronous
component, and ensuring that the generated tests cover all possible inputs leading to the goals
of test purposes. It leverages the interactions and constraints within the GALS system to create
more meaningful and comprehensive tests for the individual synchronous component.

TP CTG CTGRADAR constraints oracle time mem.

states trans. states trans. states trans. (Lutin) (Lustre) (s) (MB)
T1 5 4 15.466 29.665 89 281 286 295 29 200
T2 4 3 102.985 211.455 584 3617 3622 1916 1237 231
T3 5 4 15.444 29.957 83 258 263 282 26 200
T4 5 4 2.278 4.959 218 1119 1124 557 86 193
T5 5 5 21.930 42.788 105 356 361 344 36 201

Table 3.7: Sizes and run-time performance for the tests generated for the test purposes [109]

93
In this approach, testing synchronous components within GALS systems is distinct from other
methods that focus on different aspects and employ diverse techniques. While some method-
ologies derive test purposes for sub-systems by projecting symbolic executions of the over-
all system, this approach specifically handles GALS systems, necessitating the integration of
various formal methods and tools. One notable difference is the ability to directly handle
GRL semantics, addressing synchronous properties. Another difference exists between test-
ing synchronous and asynchronous systems in terms of abstraction levels, mutation scores,
non-determinism, and applicability to real-time systems. This approach combines an asyn-
chronous automaton with a dedicated synchronous automaton, leveraging the synchronous
components’ properties to improve overall testing. Also, it reverses the direction by specify-
ing the global aspects of a GALS system in an asynchronous language. This allows the usage
of existing asynchronous tools to enhance synchronous component testing.
Lastly, this approach is tailored to testing synchronous components in a broader range of GALS
systems and doesn’t rely on highly precise models of communication signals, making it suit-
able for more generic GALS systems beyond hardware circuits.

3.3.3 Synchronous Languages

Some synchronous programming languages were designed for developing reactive, real-time
systems [155, 156]. The languages are based on mathematical formalism and provide a clear
and concise way to specify the behavior of concurrent systems in a deterministic and syn-
chronous manner. This paper [155] introduces three languages, ESTEREL [157] widely used
in the design of embedded systems, robotics, multimedia systems, telecommunications, and
automotive applications. Esterel’s ability to model parallelism, synchronization, and dynamic
scheduling makes it suitable for systems with concurrency requirements. LUSTRE [158] is
used for specifying and verifying the behavior of reactive systems with critical timing require-
ments. LUSTRE is often employed in formal verification techniques like model checking and
static analysis to ensure the correct properties of the system, and SIGNAL[159] used in dig-
ital system design, covering various levels of abstraction, from high-level specifications to
low-level hardware descriptions. It is employed in the design and simulation of digital cir-
cuits, including microprocessors, ASICs (Application-Specific Integrated Circuits), and FPGAs
(Field-Programmable Gate Arrays). SIGNAL allows the specification of timing constraints,
functional behavior, and hierarchical composition of digital system components. it can de-
scribe multi-clocked systems without the necessity of a global clock. So This feature permits
the description of globally asynchronous locally synchronous systems. These languages have
evolved to include industrial environments and are currently being applied in extensive indus-
trial applications. Also, The article [91] discusses the formal verification process in the context
of embedded control systems, emphasizing the use of hybrid systems that integrate discrete
state-machine models with continuous differential-equation models. Designers aim to create
a mathematically precise model of the system to ensure correctness to specified requirements.
The article briefly reviews existing approaches to formal verification of hybrid systems and
highlights the need for future research in this field. It underscores the significance of model-
based design in early-stage error detection and correction for system design. In this approach,
designers create a mathematically precise model of the system under design and conduct ex-
tensive analyses to meet correctness requirements before generating the implementation. The
preferred mathematical model for designing embedded control systems is hybrid systems,
merging traditional discrete behavior models with classical models based on differential and
algebraic equations for dynamical systems. The article highlights the common use of tools like
Stateflow/Simulink in the automotive and avionics industry for modeling. The imperative for
high assurance in safety-critical applications deploying embedded software has driven formal
verification of hybrid systems to be a confusing research area for the past two decades.
The ESTEREL language. Esterel [152, 157] is a synchronous programming language and for-

94
mal method that excels in designing and specifying reactive systems. Developed by Gerard
Berry, it operates on the principle of synchronized, deterministic execution, making it partic-
ularly well-suited for systems with strict timing requirements, including safety-critical and
real-time applications. Esterel enables concurrent execution of tasks, modeling systems as fi-
nite state machines, and offers automatic code generation for electronic circuits, streamlining
the implementation of complex systems while reducing the risk of errors. This language is
widely used in aerospace, automotive, medical devices, and industrial automation for its abil-
ity to ensure reliability, safety, and system behavior predictability, often integrated with other
languages like C and Ada for broader capabilities.
LOTOS NT. Process algebras, also known as process calculi, are mathematical frameworks
that provide techniques for modeling and analyzing the behavior of concurrent systems (c.f.
Table 3.8).
Definition Symboles Description

process P [ Event1: Channel1, Event2: Channel2,. . . ] is

Processes The fundamental entities that are mod-
// Process Behavior
eled. A process can represent anything
end process
from a simple computation to a complex
system.
par
behavior1
Parallel Composition || Allows multiple processes to execute con-
behavior2 currently.
end par
statement1;
Sequential Composition statement2; Specifies that one process follows an-
... other.
behavior1
Choice [] Indicates that one of several processes
behavior2 should be selected for execution.
par event in
behavior1; event
Synchronization || Ensures that certain actions in different
behavior2; event processes occur in a coordinated manner.
end par
channel1 ! variable offering interaction
Communication Describes how processes can exchange
channel1 ? variable accepting interaction
information.
process P1 [Event1 : any] is
Recursion Event1; process P1 [Event1 : any] Enables the definition of processes that
end process can call themselves.
hide event2 in
Hiding Process1 [event1, event2, event3] Allows certain actions within a process to
end hide be hidden from its environment, making
them unobservable.

Table 3.8: LOTOS NT definitions

Among the most popular process algebras are the Calculus of Communicating Systems (CCS),
Communicating Sequential Processes (CSP), and Algebra of Communicating Processes (ACP).
Each of these has its specific syntax and semantics, but they all provide tools for the behavior
model of concurrent systems. In this context, it’s important to mention that Language Of Tem-
poral Ordering Specification (LOTOS), also, conforms to the principles of process algebra. LNT
(LOTOS New Technology), which represents the advanced version of LOTOS and E-LOTOS is
a formal language that has been under development since the mid-1980s and contains a wide
range of formal methods, including model-checking and simulation. It offers a rich set of op-
erators for both data and behavior, all presented in a user-friendly notation to streamline the
process of writing and expanding models.
Why LOTOS NT? In the center of many formal languages, one might wonder why LNT stands
out as a choice. A primary advantage of LNT lies in its adeptness at illustrating both non-

95
deterministic and deterministic behaviors within system specifications. On a different note,
LNT has advanced data-handling capabilities, facilitating the design and manipulation of so-
phisticated data structures and operations. Also, a common issue of traditional LOTOS and
some other formal languages was their challenging syntax. In contrast, LNT offers a more
user-friendly experience, especially for those new to the field. Furthermore, LNT’s flexibility
is evident in its applicability across diverse areas, ranging from networking protocols to dis-
tributed systems.
Complementing its features, LNT is paired with the Construction and Analysis of Distributed
Processes (CADP) toolbox. It is a comprehensive software suite developed by the National
Institute for Research in Digital Science and Technology (INRIA) and the VASY team for for-
mal verification and analysis of concurrent and distributed systems. allows the construction of
formal models that represent the behavior and interactions of concurrent and distributed pro-
cesses. These models can be used to reason about system properties such as correctness, safety,
liveness, deadlock-freedom, and fairness. By supporting various modeling languages like LO-
TOS, Promela, and Estelle, it allows users to describe their systems accurately and provides
user-friendly interfaces for easy system design and debugging. Its capabilities help engineers
and researchers detect potential issues and errors, assisting in the generation of labeled tran-
sition systems and verification such as deadlocks in system designs and protocols, finding
execution sequences, and enhancing system performance and safety. CADP consists of several
software tools that work together to provide a complete environment for system analysis. One
notable tool is BCG (Binary Coded Graph) which is an LTS compact graph representation of
system behaviors.

3.4 Conclusion
In this chapter, we explored the critical fields of formal verification and signal synchroniza-
tion in the context of IoT systems. Our investigation revealed the importance of ensuring the
correctness and reliability of IoT applications, especially in environments where numerous in-
terconnected devices interact with each other and the physical world. We talked about formal
verification, which provides a systematic approach to ensuring the correctness of IoT systems.
We discussed its application in reactive systems, emphasizing its significance in guaranteeing
the desired properties and behavior of these systems. We explored the critical issue of signal
synchronization. Clock synchronization protocols were examined, highlighting their role in
achieving precise temporal alignment among distributed devices. Furthermore, we explored
the concept of GALS systems, offering insights into achieving global coordination while al-
lowing local autonomy. Synchronous languages emerged as powerful tools for expressing
temporal constraints and facilitating verification in synchronous systems.
In conclusion, this chapter underscores the necessity of rigorous approaches to ensure the reli-
ability, safety, and efficiency of IoT applications. By leveraging formal verification techniques,
we can guarantee the correct behavior of these systems, thus enhancing their trustworthiness.
Moreover, signal synchronization is important for enabling seamless communication and co-
ordination among IoT devices, laying the foundation for dependable and scalable IoT ecosys-
tems.

96
Chapter 4

Contributions

Contents
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.2 Case study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.3 General architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.4 Meta-model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.5 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.6 Model to Text (M2T) Transformation . . . . . . . . . . . . . . . . . . . . . . . 105
4.6.1 Idsl2Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.6.2 Idsl2Lotos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4.7 Prototype Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.7.1 Idsl2Python Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.7.2 Idsl2LotosNT Generator . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.7.3 Similation-Based framework . . . . . . . . . . . . . . . . . . . . . . . 116
4.8 Integration of AI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.8.1 AI for MDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.8.2 MDE for AI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
4.9 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.10 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.11 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

97
4.1 Introduction
In this chapter, we will present a comprehensive exploration of the contributions made to our
project and delve into the core aspects. Furthermore, we will spot the lights on the challenges
we encountered, the notable achievements that we have attained, and the work that still lies
ahead. Additionally, we will provide insights into the tools and frameworks that have been
instrumental in our pursuit, offering a comprehensive overview of the technology landscape
that supports our work.

4.2 Case study

The case study is the creation of a generic framework for IoT using MDE techniques. We
present this framework as an application for a particular healthcare system. The existing sys-
tems are tailored to specific subjects and have limitations such as scalability for connecting
numerous devices and resource consumption. MDE has been proven their enhancement in the
latest research, with the creation of a DSL that helps to instantiate models conform to the meta-
model. Also, regarding the evolution of software development, abstraction is key to avoiding
the specificity of the targeted system. Additionally, IoT systems nowadays perform AI algo-
rithms to make sense of the generated data from the sensor nodes which makes the system
perform smart decisions. In the literature, we found that AI can enhance the desired system
especially when using deep learning algorithms that help the user to describe the system com-
ponents and behavior and automatically generate the model and the implementation that will
be executed in the devices of the system, on the other side we found that MDE can generate
machine and deep learning models using hyper-parameters that are chosen from the user or
automatically the system choose the best parameters for AI models.
In addition to the challenges posed by traditional interpretation methods in healthcare, such
as manual analysis of EEG and ECG data by doctors, an essential feature of the proposed sys-
tem is the synchronization of processed data from biomedical devices. This synchronization
is particularly crucial for connected devices, especially when dealing with two fundamental
biomedical devices such as EEG and ECG. The synchronization process becomes complicated
due to variations in the sampling rates and clocks of EEG and ECG devices where EEG de-
vices typically sample at a higher rate than ECG devices and have differences in time offsets.
To address this challenge, we employed the GALS concept. With this approach, smart de-
vices generate data and send data asynchronously in an interleaving manner and independent
clock domains, then the data is synchronized in a common clock domain using FIFO queues
and buffers. Subsequently, this approach ensures the seamless integration and concurrent pro-
cessing of data from these medical devices, thereby enhancing the interpretation and usability
of the overall healthcare system.
From another perspective, the imperative nature of healthcare systems demands an obligation
represented in safety-critical requirements, regarding their direct impact on human health.
Consequently, ensuring the reliability and adherence of the created model to specified require-
ments becomes very important. To achieve this, a robust methodology such as formal verifi-
cation can be employed. Formal verification serves as a systematic and rigorous process for
evaluating the correctness of a model by mathematically analyzing its behavior. This needs
checking the model to confirm its conformity to predefined specifications and verifying the
absence of critical issues such as deadlocks or missing behaviors. This ensures that the model
comprehensively addresses all anticipated scenarios and functionalities, leaving no chance for
oversight or unexpected behavior in its operation. By adopting formal verification methodolo-
gies, the healthcare system can undertake a robust evaluation that produces confidence in its
reliability, safety, and adherence to the specified requirements.

98
4.3 General architecture
Within this framework, numerous subdomains collaborate to form the overarching project.
At the outset, in the IoTFramework project (c.f figure 4.1), we utilized the Eclipse Modeling
Framework to establish an encore metamodel. This metamodel provides us with the capa-
bility to generate a dynamic XMI instance that adheres to its specifications. Additionally, we
create an OCL file containing constraints to validate the model.
Furthermore, we developed an Xtext project to create a DSL for our framework. This DSL
allows us to define models in a more intuitive and domain-specific manner. The created lan-
guage facilitates the creation of models tailored to our framework’s needs. Additionally, we
utilized a mwe2 file to generate the IDE for our language, providing developers with a seam-
less environment for modeling and development.
Moreover, we created two Acceleo projects to define model-to-language transformations. The
first project is dedicated to generating Python code, while the second one is responsible for
generating LNT code. These generated codes are integral to our approach. Firstly, the Python
code is executable on IoT devices, allowing for the implementation of the generated system.
Secondly, the LNT code is utilized in CADP to generate the LTS graph. This LTS graph is
utilized to interpret the behavioral model of the generated system, aiding in verification and
validation processes.

IoTFramework

EMF

Ecore Project Acceleo Projects .mtl idsl2Python Executable

Create file Python
Ecore Dynamic instance code
Meta-model XMI file .mtl idsl2LNT file

Conform uses
to OCL file
contraints

Xtext Project uses

DSL language
Xtext grammar create with .idsl
file extension
Mwe2 file Provide language IDE

CADP
Interpret behavioral Generate LTS files
model
Generated LTS files

Figure 4.1: General Architecture

4.4 Meta-model
The initial step in this research was to develop a meta-model for the IoT framework which en-
compasses classes for elements such as medical sensors (EEG, ECG), monitors, dataflows, and
various interfacers, along with all the necessary relationships between these classes and the
processes that happen like the inputs and outputs of dataflows in the interfacers. To achieve
this, we initiated an Ecore project which contained an Ecore file. This foundational Ecore file
paved the way to add a new .aird file. This file contains an editor that provides support for
quick editing of the semantic models independently of a Sirius representation. we used the

99
 Sirius extension from EMF to visualize and realize the meta-model of the project.
Model::Main In this model, the dataflows class initiates the process by sending data to the monitor. Subse-
quently, the monitor acts as a central coordinator, forwarding this data to the interfacer classes
(c.f. Figure 4.2). These interfacer classes then carry out their respective processes, including
preprocessing, data processing, and synchronization. Once these operations are completed,
the interfacer classes send back the processed data to the monitor. This cyclical interaction en-
sures a systematic flow, with the data initially originating from the dataflows class and travers-
ing through the monitor to reach the interfacer classes for processing before returning to the
monitor.

Output
0..* +anomynousintputdataflowdescriptors

DataHolder
Thing DataCenter

0..* +anomynousoutputdataflowdescriptors
0..* +outputdataflowdescriptors
+dataflowdescriptor DataFlowDescriptor
0..1 1..* +inputdataflowdescriptors

0..* +dataflowdescriptors

+interfacerdescriptor InterfacerDescriptor
0..* +inputs
DataFlow 0..1

0..* +outputs 0..* +interfacerdescriptors

1..* +dataflows

Interfacer

Synchronizer
SynchronizerDescriptor
0..* +interfacers
DataProcessor
DataProcessorDescriptor

PreProcessor
PreProcessorDescriptor

IotFramework

Figure 4.2: IoTFramework Meta-model: Association with Interfacers

From an alternative perspective, this model encompasses a range of classes (c.f. Figure 4.3)
such as dataflow, dataflow descriptor, stream, stream descriptor, and others. Together, these
classes guarantee data consistency and ensure the creation of well-formed and well-configured
data streams. The model’s design focuses on maintaining the integrity of data as it traverses
through various components. Moreover, it’s worth noting that this model exhibits a certain
level of care in handling data, reflected in the multitude of classes dedicated to its manage-
ment.

100
 Connexion StreamDescriptor
+parameters DomainParameter
-name: EString +parameters -name: EString
0..* -name: EString
-description: EString -samplingRate: EInt
0..*
-port: EInt -type: Type = string
0..* +parameters -description: EString

0..* +connexions
+streamdescriptors 0..* 0..* +streamdescriptors

Stream
-name: EString

DataFlowDescriptor
-name: EString IotFramework
-description: EString 0..* +dataflowdescriptors
-DataFlow_port: EInt +name: EString
0..1 +dataflowdescriptor

1..* +dataflows
Thing DataCenter
DataFlow
-name: EString

Figure 4.3: IoTFramework Meta-model: Integrity of data through various components

The replication of classes, such as Interfacer, InterfacerDescriptor, Dataflow, and DataflowDe-

scriptor, serves a dual purpose in streamlining the system and augmenting the model’s ca-
pabilities. The initial set of classes, namely Interfacer and Dataflow, functions as predefined
configuration classes. These classes provide a foundation for the system’s configuration, of-
fering a structured framework. The introduction of descriptors, such as InterfacerDescriptor
and DataflowDescriptor, maintains simplicity during configuration updates. By separating
configuration details into descriptors, the model ensures that the addition of new configura-
tions doesn’t necessitate extensive modifications to the entire project. This modular approach
enhances flexibility and facility of adaptation, allowing for the seamless integration of new
configurations without disrupting the overall system architecture. After establishing the meta-
model, we integrated the "Gen-Model" to ensure the automated generation of essential com-
ponents, including "Edit," "Editor," and "Test" directories.

Xtext DSL. After establishing the meta-model, our next step involved the creation of a new
Xtext project. In this project, we used the Ecore file from the previous meta-model as a founda-
tion to define the DSL for our framework, named IDSL. This project includes a file dedicated
to defining the grammar for the targeted language. we start to define the concrete syntax of the
project that uses the meta-model components and their attributes. As an example, we define
the syntax of the main class IoTFramework and the Synchronizer as the following patterns :

101
 1 IotFramework r e t u r n s IotFramework :
2 ’ IotFramework ’
3 name= E S t r i n g
4 ’{ ’
5 ( ’ description ’ description=EString )?
6 ( ’ port ’ p o r t = E I n t ) ?
7 ( ’ nb_ workers ’ nb_ workers= E I n t ) ?
8 ( ’ i n t e r f a c e r s ’ ’ { ’ i n t e r f a c e r s += I n t e r f a c e r ( " , "
9 i n t e r f a c e r s += I n t e r f a c e r ) * ’ } ’ ) ?
10 ’ dataflows ’ ’ { ’ d a t a f l o w s +=DataFlow ( " , "
11 d a t a f l o w s +=DataFlow ) * ’ } ’
12 ( ’ d a t a f l o w d e s c r i p t o r s ’ ’ { ’ d a t a f l o w d e s c r i p t o r s +=
13 DataFlowDescriptor ( " , " d a t a f l o w d e s c r i p t o r s +=
14 DataFlowDescriptor ) * ’ } ’ ) ?
15 ( ’ i n t e r f a c e r d e s c r i p t o r s ’ ’ { ’ i n t e r f a c e r d e s c r i p t o r s +=
16 I n t e r f a c e r D e s c r i p t o r ( " , " i n t e r f a c e r d e s c r i p t o r s +=
17 InterfacerDescriptor )* ’} ’ )?
18 ’} ’;
19 Synchronizer returns Synchronizer :
20 { S y n c h r o n i z e r } ’ Synchronizer ’
21 name= E S t r i n g
22 ’{ ’
23 ( ’ description ’ description=EString )?
24 ( ’ inputs ’ ’ ( ’ i n p u t s +=[ DataFlow| E S t r i n g ] ( " , " i n p u t s +=
25 [ DataFlow| E S t r i n g ] ) * ’ ) ’ ) ?
26 ( ’ outputs ’ ’ ( ’ outputs +=[ DataFlow| E S t r i n g ] ( " , " outputs+=
27 [ DataFlow| E S t r i n g ] ) * ’ ) ’ ) ?
28 ( ’ interfacerdescriptor ’ interfacerdescriptor=
29 [ I n t e r f a c e r D e s c r i p t o r|EString ] ) ?
30 ’} ’;

In the exploitation of Xtext for the development of IDSL language, central to this process was the "Gen-
erateIDSL.mwe2" file. This file, a Modeling Workflow Engine 2 (mwe2) artifact, was used as a workflow
description for the Xtext generator. Within this file, we describe the necessary components for the spe-
cific language, enabling the specification of code generation and configuring other essential settings. By
finishing the configuration of the ’GenerateIDSL.mwe2’ file and the deployment of XText project plug-
ins, we successfully generated a specialized editor for our custom language. This editor offers a range
of features to enhance our writing experience and code editing. It helps streamline our writing process
by offering word suggestions (c.f figure 4.4) and incorporates features like syntax highlighting, content
assist, and validation, all specifically adapted to the IDSL language. Its text coloring feature allows us
to highlight important sections, making it easier to identify key points or errors.

Figure 4.4: Word suggestions for iDSL language

102
To work with the created language, we adopted the ".idsl" file extension for files created within our
project using this specialized editor. These ".idsl" files contain code written in the custom language (c.f
figure 4.5), especially adhering to the syntax and structure defined in the Xtext grammar.

Figure 4.5: Model conform to meta-model using ".idsl" xText syntax

4.5 Model
After defining the meta-model, we can create models that conform to it using various tools and meth-
ods, such as constructing models within the DSL we have developed or creating dynamic instances
from the Ecore meta-model as an XML Metadata Interchange (XMI) file. These models should align
with the specified relationships and guidelines set forth by the meta-model. To instantiate the model
we created an XMI file (c.f. Figure 4.6) that adheres to the previously established meta-model.

103
 Figure 4.6: XMI model

However, a persistent issue arose during the validation of this model. It indicated successful valida-
tion, even when illogical meanings and configurations were established between the objects’ instances.
This issue highlighted the limitations in the validation process, presenting the need for more strict and
comprehensive validation criteria.

OCL constraints. In response to the previous limitation, we developed an OCL file, designed to incor-
porate additional constraints that the original meta-model couldn’t provide them. This implementation
of OCL constraints allowed for more accurate and meaningful validations. While the invariants may
seem simple, their implications carry significant weight particularly when considering the sensitivity
of IoT systems. As an example here are some examples of invariants for the interfacer synchronizer:
• add the pattern of the synchronizer’s name :

1 context Synchronizer
2 inv invalidSynchronizerName
3 ( ’ I n v a l i d name f o r : ’ + s e l f . name ) :
4 s e l f . name . matches ( ’ [ A−Za−z _ ] [A−Za−z 0 − 9 _ ] * ’ )
5 and s e l f . name . s i z e ( ) >= 3

• the input and output in synchronizers should not be the same :

1 context Synchronizer
2 inv n o t R e f l e x i v e S y n c h r o n i z e r I O :
3 s e l f . i n p u t s <> s e l f . outputs

• Each interfacer has its descriptor, in the synchronizer interfacer must match a synchronizerDe-
scriptor :

1 context Synchronizer
2 inv i n v a l i d S y n c h r o n i z e r D e s c r i p t o r :
3 s e l f . i n t e r f a c e r d e s c r i p t o r . oclIsKindOf
4 ( SynchronizerDescriptor )

104
To validate models that are newly created conform to the meta-model, we select validate the model
and then select the OCL file (c.f figure 4.7) that contains the meta-model constraints. If any mismatches
occur between the model and the specifications required in the meta-model or the constraints present
in the OCL file, an alert will appear containing errors and warnings. Errors indicate serious issues that
must be corrected before the model can be considered valid, while warnings highlight potential issues
that, while not critical, should be addressed for better model quality.

Figure 4.7: Meta-model constraints OCL file

4.6 Model to Text (M2T) Transformation

After confirming the model’s adherence to the meta-model with the incorporated constraints, we ad-
vanced to the creation of two Acceleo projects. The initial project is designed for Python code gen-
eration, while the second project is dedicated to producing LNT code. Acceleo is an open-source code
generator designed to efficiently implement the Model-Driven Architecture approach and improve soft-
ware development productivity. It’s part of the EMF ecosystem. Also, it is based on OMG’s standard
for model-to-text transformations.
In EMF, Acceleo simplifies the task of transforming EMF models into various textual formats, allowing
developers to streamline code generation, documentation, and report generation from their models.
Mainly, Acceleo’s syntax uses a template-based language to define how models should be transformed
into text, and these templates specify how different parts of the model should be converted into textual
output. Our workflow typically involves two transformations (c.f. Figure 4.8). The initial task involves
transforming the IDSL model into Python code. This Python code will act as the implementation for the
system’s devices. Simultaneously, the second task concentrates on translating the models into LOTOS
NT code. This code is for verifying and validating the system’s behavior.

105
 XMI file MTL file Output files

Model to Python language Executable Python

files
Model

Model to LNT LNT files (for formal

verification)

Figure 4.8: Model to Languages with Acceleo

4.6.1 Idsl2Python
One of the main goals of the project is to generate code automatically for devices in the IoT system
without the need to have a deep knowledge of the user of how the code is implemented as the main
actors in the system are doctors who deal with medical aspects more than IT systems. The generated
Python code should comprehensively address various aspects of the system, including the definition of
monitors, interfacers, dataflows, and smart devices. Additionally, it should encompass the mechanism
through which smart devices connect to monitors, simultaneously and concurrently sending their data.
As data synchronization is the main feature we dealing with in this internship, the implemented code
of this process should follow defined streamlined steps (c.f. Figure 4.9). The synchronizer receives data
from the input dataflows of devices, directing them to the input Buffers. This input buffer concatenates
chunk data until it forms a complete buffer. Once a buffer is ready, it is added to a FIFO queue. When
the queues collectively hold at least one buffer, the synchronizer initiates a synchronization algorithm,
such as indexing, snapshot, interpolation, and rendezvous. During synchronization, the synchronized
data is redirected to an output Buffer. Once these output buffers are filled, they are redirected to output
FIFO queues. When the output FIFO queues accumulate at least one buffer, the synchronized data is
retrieved and returned to the monitor.
In this synchronization architecture, new devices can easily be integrated into the network without af-
fecting existing ones, as each device operates independently on its local clock. This makes it suitable for
dynamic environments where devices may join or leave the network frequently. This approach simpli-
fies the management and scalability of the IoT system, allowing for seamless expansion and adaptation
to changing requirements. Additionally, by abstracting the complexity of code implementation, espe-
cially for users like doctors who focus primarily on medical aspects, the system ensures a user-friendly
experience while maintaining robust functionality.
On the other side, the synchronization mechanism is targeted to be finely grained [96]. This level of
flexibility allows for the adaptation of the synchronization process to evolving requirements or the in-
corporation of additional features without disrupting the existing system. Moreover, it facilitates the
integration of advancements in synchronization algorithms or the introduction of specialized function-
alities tailored to specific use cases, ensuring the IoT system remains adaptable.

106
 Synchronizer (interfacer)

3 Synchronization mechanism
Chunk synchronization
0 Interpolation function 4
Synchronizer Queues
Input Buffers 2
FIFO
Buffer 5
Queue
Output Buffers
1 Output
Queue 6 Buffer

Figure 4.9: Synchronizer Interfacer

Python Code Generation. we started by creating a new Acceleo project containing a new model to lan-
guage (.mtl) file, which served as the Acceleo template. In system development, we recognize that there
are unchanged (static) code segments, which typically encompass elements like classes from which we
instantiate objects. These static components remain constant throughout the development process, pro-
viding the foundational structure and functionality upon which the dynamic aspects of the system are
built. Alongside these static code segments, we also encounter dynamic code segments that present
variability based on the specific context in which they are employed. This dynamism may involve
modifications to variable attributes and the decision to instantiate objects from classes or not, depend-
ing on the evolving requirements and conditions.
Due to this distinction, we have divided the generated code into two categories: static templates, which
remain constant across every code generation cycle, and dynamic code which adapts based on the input
from the new model.
Static code. For instance, here is an example of a Stream object declaration class, which will be auto-
matically generated as a Python file with the ".py" extension:

1 [ f i l e ( ’ Stream ’ + ’ . py ’ , f a l s e ) ]
2 c l a s s Stream :
3 def __ i n i t _ _ ( s e l f , name , type , sample _ r a t e ) :
4 s e l f . name = name
5 s e l f . type = type
6 s e l f . sample _ r a t e = sample _ r a t e
7 [/ f i l e ]

Dynamic code. On the other side, the dynamic code presents a considerable workload. To create a
Python class for each object within the input model, It must extract these objects from the models using
queries. For example, this is how we can get the synchronizer interfacers:

107
 1 [ query p u b l i c g e t S y n c h r o n i z e r
2 ( sync : OrderedSet ( I n t e r f a c e r ) ) :
3 OrderedSet ( S y n c h r o n i z e r ) = sync −>
4 s e l e c t ( e | e . oclIsKindOf ( Synchronizer ) )
5 −> c o l l e c t ( e | e . oclAsType ( S y n c h r o n i z e r ) )
6 −>asOrderedSet ( ) / ]

Subsequently, this query can serve various purposes, including its application in loops and conditional
statements.

1 [ f o r ( sync : S y n c h r o n i z e r | anIotFramework . i n t e r f a c e r s −>

2 getSynchronizer ( ) ) ]
3 \\ implementation Here . . .
4 [/ f o r ]

Using the developed XMI file that accurately conforms with the meta-model and is verified using the
OCL constraints, we have effectively automated the generation of Python code. Upon executing the
generated main file and establishing connections with EEG and ECG devices, we interpreted the sim-
ulation of signals’ dataflows. The result of this process was the successful synchronization of signals
(c.f figure 4.10), evident in the transformation from asynchronized input signals to synchronized output
signals. As observed in the state of the art for this project, it became evident that the algorithms used
for signal synchronization faced significant challenges due to the computation limitations of connected
devices. These devices struggled to handle high connectivity demands for sending and receiving data.
Consequently, we chose to adopt the GALS concept [67].
GALS allows devices to operate on their local clocks without needing to overclock their computational
speed. Instead, they send data to a monitor, which synchronizes the data using buffers and FIFO queues
[67, 109, 150]. This approach effectively alleviates the charge on individual devices, enabling them to
function optimally within their computational limits while ensuring synchronized data transmission
and reception.
Implementing the GALS concept offers several advantages. First, it reduces the effort on individual
devices by allowing them to operate within their computational capabilities [154]. This prevents issues
such as bottlenecking and ensures smoother operation. Additionally, by using local clocks, devices can
perform tasks at their own speed, avoiding the need for them to synchronize their clocks with each
other, which can be challenging in large-scale networks. The use of buffers and FIFO queues by the
monitor facilitates efficient data synchronization. Buffers temporarily store data to accommodate vari-
ations in transmission rates between devices, while FIFO queues ensure that data is processed in the
order it was received, maintaining the integrity of the information. Furthermore, GALS architecture
promotes scalability and flexibility. New devices can easily be integrated into the network without af-
fecting existing ones, as each device operates independently on its local clock. This makes it suitable
for dynamic environments where devices may join or leave the network frequently.

108
 Figure 4.10: Synchronization of the EEG signals and ECG signals

4.6.2 Idsl2Lotos
Synchronization with LOTOS NT. Using the CADP (Construction and Analysis of Distributed Pro-
cesses) toolbox(c.f figure 4.11), various properties of the system described in LNT can be checked. Our
focus in this project is on evaluating the behavior of the EEG and ECG components when they are con-
currently transmitting data. we aim to evaluate the system’s synchronization mechanisms and define
the relationships between the components. This analysis allows us to gain insights into how the system
manages data flow and inter-component coordination, ensuring the robustness and reliability of the
system design. Also, we can evaluate properties related to system behavior, such as detecting dead-
locks and liveness, as well as inspecting the data within the communication components of a process.
Initially, we extracted the processes present in our specification to obtain the primary LNT specification.

109
 Figure 4.11: CADP Graphical User Interface

In our specification, the main process needs to synchronize with the EEG and ECG processes. These
EEG and ECG processes operate in a purely interleaved parallel manner. This interleaved parallelism
ensures that the actions of the EEG and ECG can take place simultaneously, without one process waiting
for the other to complete.

1 par
2 EEG [ c on nec t _EEG , send _ data _EEG ]
3 ||
4 ECG [ c o nne ct _ECG, send _ data _ECG ]
5 end par

However, despite this parallelism, synchronization with the monitor is crucial to ensure the sending
and receiving of data. In other words, the monitor is synchronized with EEG and ECG with send-
DataEEG and sendDataECG gates respectively and ensures the send/receive communication with the
smart devices.

110
 1 par send _ data _EEG , send _ data _ECG i n
2 MONITOR [ i n i t _ Monitor , . . . , send _ data _EEG , send _ data _ECG ]
3 ||
4 par
5 EEG [ c onnec t _EEG , send _ data _EEG ]
6 ||
7 ECG [ c o nn ect _ECG , send _ data _ECG ]
8 end par
9 end par

To ensure the transfer of data through the sendDataEEG and sendDataECG gates, it’s essential to es-
tablish a channel. These gates use the channels to guarantee the passing flow of data between devices.
Additionally, the channel must be configured to handle data types that match the content sent by these
gates. For instance, the sendDataEEG and sendDataECG gates use the dataChannel, which manages the
data exchange between the monitor and smart devices, employing the variable type ’data’ for seamless
communication.

1 channel data _ channel i s

2 ( d : data )
3 end channel

In the creation of the EEG and ECG process, we should introduce the sendData gate with a channel of
type dataChannel, which is linked between these devices and the Monitor. Here’s an example of how
to introduce the ECG process :

1 p r o c e s s ECG [ . . . , send _ data _ECG : data _ channel ] i s

2 var data : data i n
3 data : = any data where data == ( 1 0 o f data ) ;
4 send _ data _ECG ( data )
5 ...
6 end var
7 end p r o c e s s

To ensure the monitor receives data, the work begins with the initialization of the monitor process.
Subsequently, the monitor will await incoming data from the devices (EEG and ECG). In this example,
we illustrate how the monitor manages incoming data. It employs a condition where, if the buffer is not
at full capacity, the monitor accepts the incoming data. Otherwise, when the buffer reaches its capacity,
the monitor pushes the existing chunk and then reinitializes the buffer to accept the new incoming
data.

111
 1 p r o c e s s MONITOR [ i n i t _ monitor : none , . . . ,
2 send _ data _ECG : data _ channel , . . . ] is
3 var data _EEG : data , B1 : B u f f e r , Remaining : Nat , . . . i n
4 Buffer =: { } ;
5 Remaining = : 1 0 0 ;
6 i n i t _ monitor ;
7 // o t h e r behavior here
8 ( * monitor r e c i e v e EEG data * )
9 send _ data _EEG ( ? data _EEG ) ;
10 i f l e n g t h ( Remaining ) > l e n g t h ( data _EEG) then
11 B u f f e r = : i n s e r t ( data _EEG , B u f f e r ) ;
12 Remaining = : Remaining − l e n g t h ( data _EEG ) ;
13 else
14 ...
15 end i f

4.7 Prototype Tools

This work was exceptionally demanding and exhaustive due to the extensive knowledge and diverse
skill set required. we needed to master various disciplines, including software engineering, formal
verification, IoT systems, AI techniques, and signal synchronization. Furthermore, we had to become
proficient in the use of new software tools and languages like LOTOS NT, OCL, and XText among oth-
ers. Understanding the syntax and functioning of these tools was crucial for the successful completion
of this project.
Within this complex chain of tasks, any gaps in knowledge posed a significant threat to the project’s
progress and overall performance. Also, The process of debugging in Python code, in LOTOS and Ac-
celeo, demanded notable time and effort. Overcoming these challenges required patience and persistent
tenacity.
This work was carried out on an ASUS laptop, model X540U, equipped with the following specifica-
tions:

Processor: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz

Video Card: NVIDIA GeForce MX110
Video Card-2: Intel(R) UHD Graphics 620
Operating System: Windows 11
RAM: 8.0 GB
Additionally, a VirtualBox environment was used to run Kali Linux 2023.2 since CADP is not compati-
ble with the Windows operating system.
we constructed the meta-model within Eclipse 09-2022. To implement the Python code, we used the IDE
VScode because of its large range of Python-related extensions and our familiarity with its features. As
for LOTOS NT, we used Vim as the text editor for writing the code as was suggested in the installation
of the CADP toolbox.

4.7.1 Idsl2Python Generator

The MTL file was the base of the code generation process which comprised 955 lines, guiding the cre-
ation of various Python files essential for the project. It covered a wide range of functionalities, includ-
ing the setup of the monitor, dataflows management, and the integration of device-specific code for
EEG and ECG. Additionally, it facilitated the implementation of crucial interfacers such as the synchro-
nizer, preprocessor, and dataprocessor, streamlining the development process.
During the initial stages, the MTL file structure and directives were somewhat unclear, leading to chal-
lenges in generating functional code. Refinement and clarification were necessary to achieve the desired
outcomes. This involved multiple iterations and adjustments to the MTL file, aiming to make the code
generation process more precise and efficient.
One significant issue encountered during code generation was related to the compatibility of Python

112
libraries. As the project progressed, it became evident that certain libraries used in the generated code
were either outdated or incompatible with other components. This necessitated revisiting the MTL file
to ensure that the appropriate libraries were being utilized, and compatibility issues were addressed
effectively. In Python, implementation is crucial for defining code blocks, and any errors in tabulation
can lead to syntax errors or unexpected behavior. The MTL file needed adjustments to ensure consistent
and correct tabulation throughout the generated code.

Experiment Description Results

1 Generate Overall System Files Generated 15 Python files for the overall system.
2 Detect errors in generated code Identify missing code in generated files.
3 MTL File Modification for Correct Generation adjust the connectivity, synchronization mechanism, and
ensure all components are correct.
4 Verify and Validate generated code Successfully generated and validated code with different
models.
5 Improve Generated File Formatting Improve consistency and readability and add comments on
generated code.

Table 4.1: Summary of Experiments

4.7.2 Idsl2LotosNT Generator

The Acceleo project, used for the LOTOS generator, presents greater complexity when compared to the
Python generator. This complexity arises from LOTOS’ sensitive syntax. Before generating the code, a
clear understanding of the desired output is essential. Unfortunately, the documentation for LOTOS is
not comprehensive and lacks clarity. Resources for learning the syntax are rare, consequently, we relied
on examples and code snippets from scientific papers as a temporary form of documentation.
Initially, we attempted to use the older version of LOTOS, but it was very exhaustive and required
numerous lines even for a basic specification. As a result, we switched to LOTOS NT, the newer version
with slightly improved documentation and more user-friendly. However, a persistent issue lies in the
compilation process, where the terminal error messages weren’t helpful.
Regarding the CADP, two versions are available, one commercial and the other academic. we acquired
the academic version through an email and form submission. Furthermore, the installation of this
software proved to be challenging, as it necessitated reading through four separate installation files and
other files for specific operating systems.
To enhance the precision of system behavior analysis, we attempted to derive (see Figures 4.12) the
code transition from the generated Python code, utilizing enumerations. For instance, in defining the
processes for EEG and ECG, we employed the VScode debugger to inspect function transitions and
data changes, explaining their operational mechanisms:
1. This transition signifies the initialization of EEGTHING.
2. EEGTHING establishes a connection to the server.
3. Generates EEG data.
4. Waits for a specified duration (0 seconds, if needed).
5. Increments the start time of EEGTHING.
6. L: Indicates that transitions 6-3, 3-4, 6-5, and 5-6 persist in a continuous loop.

113
 3

Figure 4.12: Extracting behavior from Python code

From these enumerations of the system processes (c.f. Figure 4.13 for the expected EEG process), we
used software developed at LAAS-CNRS, called "nd," to design the LTS for the processes, and This
increased our understanding of the system’s behavior, particularly as we observed the primary chal-
lenge of data synchronization and encountered the complexity of representing concurrency within the
system’s behavior.

114
 Figure 4.13: Expected EEG process behavior

As previously mentioned, the goal of this generated code is to create the behavioral model of the system
in the form of a Labelled Transition System (LTS) graph. Initially, when we started using LOTOS NT, we
attempted to encapsulate all the specifications within a single LNT file. However, this approach resulted
in a huge number of transitions (c.f. Figure 4.14), making the generated graph complex, unclear, and
challenging to interpret.

Figure 4.14: Generation of LTS within a single LNT file

This observation highlighted a significant issue in our prior work and led us to rethink our approach,
and we decided to decompose the specifications into distinct modules, interpreting each model sepa-
rately. After several iterations, we managed to reduce the number of transitions compared to the initial
attempt, such as the LTS of the buffer used for smart things (c.f. Figure 4.15). we realized that changing
the processes into smaller modules could be important to make the graph more comprehensive and
expressive.

Figure 4.15: Generation of LTS of smart thing Buffer

Therefore, instead of consolidating the behavior specifications of the entire system into a single file,
we began to decompose the specification processes into smaller modules. This approach outcomes
in simplified results for each module for the interpretation but the same issue persisted when execut-
ing these modules as the complete system specification. Throughout this work, frequent issues also
persisted in the form of deadlocks. These deadlocks highlighted scenarios within the generated code
where processes or threads were blocked, and unable to proceed, thus adding a layer of complexity to
the development process. This code was a culmination of extensive effort. With LOTOS NT, we iterated
through five versions (c.f. Table 4.2), continually enhancing it with each revision.

115
 Iteration Language N° of files N° of lines N° of transitions Completed
1 LOTOS 1 106 173598 No
2 LOTOS NT 1 411 1868754 Yes
3 LOTOS NT 1 357 278955 Yes
4 LOTOS NT 3 287 +17866 No
5 LOTOS NT 6 326 +3459 No
6 LOTOS NT 7 749 +48390 No

Table 4.2: Iterations of the generated LNT code

Upon reviewing this table, we gather that this approach requires additional time to address its chal-
lenges, particularly in minimizing transitions within the LTS. Additionally, we find that the concurrency
in the system makes it challenging to interpret the generated LTS (c.f. Figure 4.16). For each state, we
observed a significant number of transitions, mainly attributed to the non-determinism of the system,
further complicating the determination of the next transition in the sequence, resulting in an increasing
number of remaining transitions.

Figure 4.16: Non-interpretable LTS

4.7.3 Similation-Based framework

Based on [88] which presented the usage of MDE techniques, specifically Eclipse Modeling Project, Sir-
ius, and Xtext for Arduino applications. This paper highlights the various notations available in DSL.
These notations can be textual, graphical, tabular, form-based, or a combination of these, each offering
unique advantages. Also, The authors in [84] propose the design of a Visual Editor named DSL-4-IoT
which is a VDSL that aims to abstract many of the specific aspects of IoT applications into building
blocks.
Our approach aims to create a Simulation-Based framework. We plan to use Sirius to create an in-
teractive GUI that helps users create models and validate them against a meta-model. The graphical
interface should be user-friendly and easy to learn how to use, ensuring that users can quickly grasp its
functionalities and efficiently create models. It will show alerts if any errors appear.

4.8 Integration of AI
In this state-of-the-art exploration, we delved into the bidirectional integration of AI in MDE4AI and
AI4MDE. In this project, we propose several key points to exploit the capabilities of AI.

4.8.1 AI for MDE

Firstly, leveraging AI for predictive diagnostics can enhance early disease detection, facilitating timely
intervention. Furthermore, AI can streamline administrative tasks, reducing the charge on healthcare
professionals and improving overall efficiency.
As presented in this research paper [103], we can use mutation and crossover algorithms to create mod-
els that conform to a given meta-model. To employ an AI algorithm for generating models conforming

116
to a meta-model with constraints, users can interact with a chatbot designed to understand system com-
ponents and their behaviors. By describing the system through natural language input, users provide
the AI algorithm with the necessary information. The AI algorithm then processes this data, iden-
tifying patterns and relationships, and subsequently generates models that conform to the specified
meta-model and its constraints. This approach (c.f figure ai4mde here) streamlines the model creation
process, offering an intuitive and accessible way for users to articulate their system requirements with-
out requiring explicit knowledge of modeling languages or formal specifications. The integration of a
chatbot facilitates a user-friendly experience, enabling users with diverse backgrounds to effortlessly
contribute to the model generation process.

Describing system Identify patterns and

Identify model
through natural relationships and
errors
language input generate model

Natural Language Generate

Generated model
Processing Python/LNT code

AI
Algorithms

Figure 4.17: AI4MDE

4.8.2 MDE for AI

During the data generation process from EEG and ECG sensors, the system efficiently stores the ac-
quired information in a data warehouse. This dataset serves as the foundation for subsequent model-
ing activities. As in our literature, we found KNIME [175], and RapidMiner [176] leading data analytics
platforms that enable users to perform advanced data processing and machine learning tasks. They
offer a visual workflow design interface for creating data pipelines without coding. With its extensive
library of nodes, KNIME covers everything from data import and preprocessing to analysis and vi-
sualization. They provide the Auto Model feature, which automates the process of building machine
learning models making it accessible to users with varying levels of programming experience. Besides
that, the ML-Quadrat [89] approach demonstrates a significant productivity improvement of around
236% compared to manual AI model development.
In our approach (c.f figure mde4ai here), users are granted the capability to actively participate in the
modeling phase by selecting algorithms targeted to their objectives, be it unsupervised learning for
uncovering inherent patterns or supervised learning with predefined labels. Furthermore, users can
select the modeling parameters, such as the number of epochs and hidden layers, providing a hands-on
approach to model customization. Alternatively, for those seeking a more automated experience, the
system offers the convenience of autonomously determining optimal parameters through sophisticated
optimization techniques.
This dual capability empowers users with varying levels of expertise to navigate the modeling process
efficiently, catering to both those who prefer hands-on control and those who favor a more automated,
data-driven decision-making approach.

117
 Select Hyper-parameters
Select learning M2T Generated AI
Select input data (libraries, epochs,
method Templates Model
optimizer,…)

Optimization suggestions

Figure 4.18: MDE4AI

4.9 Evaluation
Our vision is to create a comprehensive framework that leverages MDE and extends it to accommo-
date AI for AI4MDE, MDE4AI, and MDE4IoT, along with signal synchronization, formal verification
techniques, code generation, and domain-specific language. While some aspects of this framework are
already completed, others are ongoing and will require time to be fully realized in our next phases of
work.
Our framework is currently under development, and it serves as a foundation for comparison with
existing works. In table 4.3, we outline how our approach stacks up against other frameworks in var-
ious domains, ensuring a comprehensive evaluation based on the domains they cover. Our approach
is designed to cater to all these domains, ensuring a holistic solution for Model-Driven Engineering
applications.

FORMAL CODE
MDE4AI AI4MDE MDE4IOT SYNCHRONIZATION DSL/ VDSL
VERFICATION GENERATION
ML-Quadrat YES NO YES NO NO DSL YES
Crossover for Model-
NO YES NO NO YES — NO
Driven Optimization
DSL-4-IoT GUI NO NO YES NO NO VDSL Yes
SCADA Testing
NO NO YES NO YES — NO
Framework using EMF
Our approach YES YES YES YES YES BOTH YES

Table 4.3: Comparison of Our Approach with Other Works

Combining insights from the previous table and our literature review, it’s evident that prior works often
face challenges in specific domains and use cases. Rarely do we find combinations between different
domains, unlike what we see in the following table 4.4, which summarizes the comparison between our
work and others. This summary highlights that our work is original, particularly in signal synchroniza-
tion using MDE techniques. This represents a significant advancement in the field, filling a crucial gap
in the existing research landscape.

118
 Domain Our Approach Other Works
AI4MDE Integration of AI techniques into Varies, often limited to specific
MDE processes AI-MDE integration
MDE4AI Use of MDE to support AI devel- Limited adoption, often lacks a
opment unified framework
MDE4IoT Application of MDE principles Scattered implementations,
in IoT development lacks comprehensive approach
Signal Synchronization Incorporation of signal synchro- Not addressed in other frame-
nization techniques works
Formal Verification Integration of formal verifica- Present in some, but not always
tion techniques as a core component
Code Generation Automated generation of code Common, but varies in sophisti-
from models cation and integration
DSL Development of Domain Spe- Varies, often limited or not em-
cific Languages DSLs phasized

Table 4.4: Summary of literature and our approach

4.10 Deployment
The project is hosted on a GitHub repository, which serves as a central platform for collaboration and
version control. Within this repository, there are three main components. First, there’s a referenced
papers folder containing all the relevant literature and documents. Second, there’s a shared text file
updated weekly, featuring work checkpoints summarizing the week’s progress and tasks completed,
along with a list of missing items to be addressed in the upcoming week. This structured approach
ensures transparency and facilitates effective collaboration among team members by providing clear
insight into the project’s status and upcoming tasks. And finally, the dealt works folder (c.f figure 4.19)
encompasses the project’s code and components such as EMF Meta-model, Acceleo projects, OCL files,
and other resources necessary for its development.

Figure 4.19: GitHub project Repository

119
4.11 Conclusion
In conclusion, this work represents an extensive undertaking, requiring substantial effort to be realized
fully. Throughout our endeavor, we have established the success of our approach, primarily evidenced
by the successful execution of the generated Python code. This demonstrates the efficacy of our frame-
work and validates the direction of our research efforts. However, Our work has highlighted several
areas that require further development and refinement. The complexity of the domains we are ad-
dressing necessitates continued exploration and refinement of our methodologies. Nevertheless, our
framework has laid a solid foundation for future advancements. By demonstrating the effectiveness of
MDE techniques, particularly in signal synchronization, we have opened new avenues for research and
innovation in this field.
Moving forward, our focus will be on addressing the remaining challenges and expanding the capabili-
ties of our framework. This will involve further refinement of our techniques, as well as the integration
of additional functionalities to enhance its applicability in diverse scenarios.

120
Conclusion

Contents
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Achievements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

121
Conclusion
The fusion of SE, AI, and IoT in this internship topic presents a promising avenue for advancing the
field of DSL development, with a focus on the future of IoT framework. This project marks a start ef-
fort in the employment of MDE within an application for a particular healthcare system, specifically
aimed at advancing the synchronization of concurrent biomedical devices data. The overall framework
under development encompasses various details, including behavioral modeling, structural modeling,
semantics, and signal handling. As another feature, this project aims to adapt AI techniques in MBSE
which will improve the system design level and avoid the complexity of implementing AI models
for the users. The clarity of the project was somewhat compromised by its ambiguity concerning the
required effort and proficiency across diverse domains including signal synchronization, formal verifi-
cation, and other relevant fields such as MDE4AI and AI4MDE.

Achievements
In this internship, we acquired extensive knowledge across diverse IT domains. Furthermore, we
delved into the evolution of software development, discovering how elevating the abstraction level
can enhance the reliability of solutions for targeted problems and handle a variety of challenges in IT
fields. Also led us to realize that abstraction opens up a new way of thinking. In this state-of-the-art,
we saw that AI extends its typical use in IoT and defines new synergy with model-based software de-
velopment. This exploration has expanded our perspective and eliminated any limited vision of tools
and their field of applications. At the start of the internship, we gained a deep understanding of Ecore
meta-modeling language. our exploration began by delving into the practical aspects of this concept
through scientific papers, documentation, and exercises provided by our supervisor, such as PetriNet
and SimplePDL (Process Description Language).
we learned the concept of abstract syntax, which involves defining the essential elements of systems
without delving into specific details. This provides a high-level structure for modeling systems. To
enforce rules and constraints within these models, we learned also the OCL and applied it to add con-
straints and invariants to meta-models. Moving on to concrete syntax, we explored DSLs and their
strengths in software development. we used Xtext to implement textual concrete syntax, enabling us
to create new languages with customized grammar and extensions. This expertise allowed us to gen-
erate and execute code efficiently. Additionally, we learned graphical concrete syntax by using the
Sirius extension within EMF. This gave us the ability to design intuitive graphical representations of
meta-models and create GUI editors. Also, we have acquired proficiency in ATL to perform model-to-
model transformations. This skill enhances our knowledge for efficiently translating and transforming
models, contributing to the versatility of our model-driving development capabilities. Besides that, we
expanded our knowledge of model-to-text transformations, such as using the Acceleo extension. This
skill enabled us to automatically generate textual files from models, streamlining the code generation
process.
The synchronization issue remains an ongoing research challenge, drawing the attention of numerous
researchers dedicated to improving various approaches. In this state, we had the opportunity to en-
counter the GALS system. As in the context of our project, where device resources are constrained,
incorporating the GALS aspect emerges as a good solution for synchronization. After reviewing papers
on signal synchronization, the selected approach involved having the bio-medical devices generate in-
terleaving data where these data are transmitted to a monitor node responsible for orchestrating them
and implementing the synchronization mechanism using its interfaces. This approach necessitated
a thorough verification of the system’s behavior, specifically checking for any potential deadlocks or
lack of synchronization. In this context, we had the opportunity to acquire knowledge in synchronous
programming and formal verification languages, we learned the fundamental concepts of formal verifi-
cation and gained the capability to implement the formal specifications of systems using LOTOS code,
as well as the enhanced version of LOTOS NT. This endeavor took much time to learn and utilize effec-
tively, especially when running the implemented code in the CADP toolbox that provides a platform
for model checking, equivalence checking, and other formal verification techniques.
This milestone demonstrates the feasibility of our approach and signifies the first step toward future
work in this domain especially when the generated Python code succeeds in synchronizing the data
stream.

122
Perspectives
At this significant milestone, We are currently concentrating on verifying and validating our system to
meet the specified requirements and behavior as intended. Since the output of the generated LTS is not
interpretable, we will explore alternative strategies to enhance the LTS outcomes. Simultaneously, we
are actively preparing and finalizing the results for submission to an international conference to share
our findings, implementations, and insights with the wider academic community and contribute to the
advancement of knowledge in this field. Additionally, we will test the scalability of the system and
its endurance to handle more numbers of connected devices and interpret the synchronization of data
flows.
In the long-term perspective, we plan to leverage AI models, encompassing both machine and deep
learning models, in our system. This aligns with the latest advancements in research areas such as
MDE4AI and AI4MDE. Using AI algorithms, such as language models, ensures the creation of models
that conform with the meta-model. This empowers users to customize the system’s components and
behavior according to their needs. In addition, users have the flexibility to reform and enhance system
configurations. This enhancement extends to defining new configurations targeted to specific needs.
Furthermore, users can dynamically modify executed algorithms and choose the preferred learning
methods for optimal performance. This customizable approach ensures a personalized and adaptable
user experience, empowering users to adjust the system according to their unique requirements and
preferences. At this point, our focus is on implementing algorithms that transform the complexity of
ML models into a seamless black-box experience where the system chooses the best parameters auto-
matically. The objective is to empower users by automating the selection and determining the most
effective parameters that can have the best evaluation metrics. Besides that, we will try to standardize
this framework in the IoT field which can encompass a diversity of devices such as Electromyography
(EMG) to enable the interpretation of the new correlations between the processed data and make the
task easier and not time-consuming like traditional interpretation.
Furthermore, we aim to enhance this framework by enabling it to possess self-healing capabilities and
the capacity to adapt to its environments. This is crucial to bridge the knowledge gap between the
system and users. This task involves modifying the model dynamically during runtime and redeploy-
ing the executed code. Another enhancement that can be done is to enforce our framework by adding
OCL constraints. This will increase the system’s robustness through rigorous verification of interactions
between system components components.

123
Bibliography

[1] Arthur M Geoffrion. “An introduction to structured modeling”. In: 33.5 (1987), pp. 547–
588.
[2] Jaeho Jeon, InGeol Chun, and WonTae Kim. “Metamodel-based CPS modeling tool”.
In: Springer. 2012, pp. 285–291.
[3] Grady Booch, Ivar Jacobson, James Rumbaugh, et al. “The unified modeling language”.
In: 14.13 (1996), p. 5.
[4] Anthony Clark and Andy Evans. “Foundations of the Unified Modeling Language.” In:
Springer. 1997.
[5] Russ Miles and Kim Hamilton. " O’Reilly Media, Inc.", 2006.
[6] Petri Kukkala et al. “UML 2.0 profile for embedded system design”. In: IEEE. 2005,
pp. 710–715.
[7] Maryam Jamal and Nazir Ahmad Zafar. “Formalizing structural semantics of UML 2.5
activity diagram in Z Notation”. In: IEEE. 2016, pp. 66–71.
[8] Parastoo Mohagheghi et al. “MDE adoption in industry: challenges and success crite-
ria”. In: Springer. 2009, pp. 54–59.
[9] Tahar Gherbi, Djamel Meslati, and Isabelle Borne. “MDE between Promises and Chal-
lenges”. In: IEEE. 2009, pp. 152–155.
[10] Emmanuelle Rouillé et al. “Bridging the Gap between Software Process and Software
Development”. In: 2011.
[11] David Ameller. “Considering non-functional requirements in model-driven engineer-
ing”. MA thesis. Universitat Politècnica de Catalunya, 2009.
[12] Arie Van Deursen, Eelco Visser, and Jos Warmer. “Model-driven software evolution: A
research agenda”. In: Citeseer. 2007, pp. 41–49.
[13] João de Sousa Saraiva and Alberto Rodrigues da Silva. “Evaluation of MDE tools from
a metamodeling perspective”. In: 19.4 (2008), pp. 21–46.
[14] Ludovico Iovino, Alfonso Pierantonio, and Ivano Malavolta. “On the Impact Signifi-
cance of Metamodel Evolution in MDE.” In: 11.3 (2012), pp. 3–1.
[15] Ulrich Frank. “Domain-specific modeling languages: requirements analysis and design
guidelines”. In: (2013), pp. 133–157.
[16] Juan de Lara, Esther Guerra, and Jesús Sánchez Cuadrado. “Model-driven engineering
with domain-specific meta-modelling languages”. In: 14 (2015), pp. 429–459.
[17] Matthew Emerson and Janos Sztipanovits. “Techniques for metamodel composition”.
In: 2006, pp. 123–139.
[18] Tony Clark, Paul Sammut, and James Willans. 2008.
[19] Douglas C Schmidt. “Model-Driven Engineering”. en. In: 39.2 (2006).
[20] Jean Bézivin. “On the unification power of models”. In: 4 (2005), pp. 171–188.

124
[21] Cornelia Caragea and Vasant Honavar. “Machine Learning in Computational Biology”.
en. In: ().
[22] Marcello Mariucci. “Introduction to OMG Modelling”. In: 15 (2000).
[23] Nicolas F Rouquette. “Simplifying OMG MOF-based metamodeling”. In: Springer. 2016,
pp. 97–118.
[24] Ferry Pramudianto, Indra Rusmita, and Mathias Jarke. “Model Driven Development
for Internet of Things Application Prototyping”. en. In: ().
[25] Eelco Visser. “WebDSL: A case study in domain-specific language engineering”. In:
(2008), pp. 291–373.
[26] Florian Heidenreich et al. “Integrating OCL and textual modelling languages”. In: Springer.
2011, pp. 349–363.
[27] Henning Heitkötter. “A Framework for Creating Domain-specific Process Modeling
Languages.” In: 2012, pp. 127–136.
[28] Claudia Maricela Sosa-Reyna et al. “A Methodology Based on Model-Driven Engineer-
ing for IoT Application Development”. en. In: (2018).
[29] Mostapha Melouk, Yassine Rhazali, and Hadi Youssef. “An Approach for Transforming
CIM to PIM up To PSM in MDA”. In: 170 (2020), pp. 869–874.
[30] Manuel Wimmer and Loli Burgueño. “Testing m2t/t2m transformations”. In: Springer.
2013, pp. 203–219.
[31] M Akif Özkan et al. “HipaccVX: wedding of OpenVX and DSL-based code generation”.
In: 18 (2021), pp. 765–777.
[32] Tomas Bures, Michal Malohlava, and Petr Hnetynka. “Using DSL for automatic gener-
ation of software connectors”. In: IEEE. 2008, pp. 138–147.
[33] Federico Ciccozzi and Romina Spalazzese. “MDE4IoT: Supporting the Internet of Things
with Model-Driven Engineering”. en. In: ed. by Costin Badica et al. Vol. 678. Series Ti-
tle: Studies in Computational Intelligence. Cham: Springer International Publishing,
2017, pp. 67–76. ISBN: 978-3-319-48829-5. DOI: 10.1007/978- 3- 319- 48829- 5_7. URL:
http://link.springer.com/10.1007/978-3-319-48829-5_7.
[34] Colin Atkinson and Thomas Kühne. “The essence of multilevel metamodeling”. In:
Springer. 2001, pp. 19–33.
[35] Barrett Bryant et al. “Challenges and Directions in Formalizing the Semantics of Mod-
eling Languages”. In: 8 (May 2011). DOI: 10.2298/CSIS110114012B.
[36] Milan Milanović et al. “Bridging concrete and abstract syntaxes in model-driven engi-
neering: a case of rule languages”. In: 39.16 (2009), pp. 1313–1346.
[37] Angelo Gargantini, Elvinia Riccobene, Patrizia Scandurra, et al. “Metamodelling a for-
mal method: applying mde to abstract state machines”. In: (2006).
[38] Suzana Andova et al. “MDE Basics with a DSL Focus”. In: Springer, 2012, pp. 21–57.
[39] Mark Richters and Martin Gogolla. “OCL: Syntax, semantics, and tools”. In: Springer,
2002, pp. 42–68.
[40] Jordi Cabot and Martin Gogolla. “Object constraint language (OCL): a definitive guide”.
In: Springer, 2012, pp. 58–90.
[41] Angelo Gargantini, Elvinia Riccobene, and Patrizia Scandurra. “Combining formal meth-
ods and MDE techniques for model-driven system design and analysis”. In: 1 (2010).
[42] Tony Clark, Paul Sammut, and James Willans. en. arXiv:1505.00149 [cs]. May 2015. URL:
http://arxiv.org/abs/1505.00149.

125
[43] Athanasios Zolotas et al. “Type Inference Using Concrete Syntax Properties in Flexible
Model-Driven Engineering.” In: 2015, pp. 22–31.
[44] Moritz Eysholdt and Heiko Behrens. “Xtext: implement your language faster than the
quick and dirty way”. In: 2010, pp. 307–309.
[45] Lorenzo Bettini. Packt Publishing Ltd, 2016.
[46] Valdivino Santiago et al. “An environment for automated test case generation from
statechart-based and finite state machine-based behavioral models”. In: IEEE. 2008,
pp. 63–72.
[47] Bartosz Jasiul, Marcin Szpyrka, and Joanna Śliwa. “Malware behavior modeling with
Colored Petri nets”. In: Springer. 2014, pp. 667–679.
[48] Roberto Gorrieri and Roberto Gorrieri. “Labeled transition systems”. In: (2017), pp. 15–
34.
[49] Thomas Stroeder and Maurice Pagnucco. “Realising deterministic behavior from mul-
tiple non-deterministic behaviors”. In: Citeseer. 2009.
[50] Ilaria Castellani. “Bisimulations for concurrency”. In: (1987).
[51] Sathiya Kumaran Mani et al. en. arXiv:1806.02474 [cs]. June 2018. URL: http://arxiv.
org/abs/1806.02474.
[52] D.L. Mills. en. Tech. rep. RFC0958. RFC Editor, 1985, RFC0958. DOI: 10.17487/rfc0958.
URL : https://www.rfc-editor.org/info/rfc0958.

[53] David L. Mills. “A Brief History of NTP Time: Memoirs of an Internet Timekeeper”.
In: 33.2 (2003), pp. 9–21. ISSN: 0146-4833. DOI: 10.1145/956981.956983. URL: https:
//doi.org/10.1145/956981.956983.
[54] Nikhil Tripathi and Neminath Hubballi. “Preventing time synchronization in NTP broad-
cast mode”. In: 102 (2021), p. 102135. ISSN: 0167-4048. DOI: https://doi.org/10.1016/
j.cose.2020.102135. URL: https://www.sciencedirect.com/science/article/pii/
S0167404820304089.
[55] Z Mahesh Kumar and R Manjula. “Performance Comparison of Phys”. In: ().
[56] DL Mills. 1985.
[57] Leslie Lamport. “Time, clocks, and the ordering of events in a distributed system”. en.
In: 21.7 (1978).
[58] K Mani Chandy and Leslie Lamport. “Distributed snapshots: Determining global states
of distributed systems”. In: 3.1 (1985), pp. 63–75.
[59] Michel Raynal and Gadi Taubenfeld. “A visit to mutual exclusion in seven dates”. In:
919 (2022), pp. 47–65.
[60] Lifu Guo. “Synchronization expressions in parallel programming languages”. In: (1995).
[61] Edsger W Dijkstra. “Cooperating sequential processes”. In: Springer, 2002, pp. 65–138.
[62] David P Reed and Rajendra K Kanodia. “Synchronization with eventcounts and se-
quencers”. In: 22.2 (1979), pp. 115–123.
[63] Ralph C Hilzer Jr. “Synchronization of the Producer/Consumer problem using semaphores,
monitors, and the Ada Rendezvous”. In: 26.3 (1992), pp. 31–39.
[64] Per Brinch Hansen. Prentice-Hall, Inc., 1973.
[65] Charles Antony Richard Hoare. “Monitors: An operating system structuring concept”.
In: 17.10 (1974), pp. 549–557.
[66] Daniel Chapiro. “Globally-asynchronous locally-synchronous systems”. In: (Sept. 1984).

126
[67] Paul Teehan, Mark Greenstreet, and Guy Lemieux. “A survey and taxonomy of GALS
design styles”. In: 24.5 (2007), pp. 418–428.
[68] Hyoung-Kook Kim et al. “Testing of synchronizers in asynchronous FIFO”. In: 29 (2013),
pp. 49–72.
[69] Moein Razavi et al. “OpenSync: An open-source platform for synchronizing multiple
measures in neuroscience experiments”. In: 369 (2022), p. 109458.
[70] Somayya Madakam et al. “Internet of Things (IoT): A literature review”. In: 3.05 (2015),
p. 164.
[71] Daniele Miorandi et al. “Internet of things: Vision, applications and research challenges”.
In: 10.7 (2012), pp. 1497–1516. ISSN: 1570-8705. DOI: https: //doi .org/10 .1016/ j.
adhoc.2012.02.016. URL: https://www.sciencedirect.com/science/article/pii/
S1570870512000674.
[72] Jayavardhana Gubbi et al. “Internet of Things (IoT): A vision, architectural elements,
and future directions”. en. In: 29.7 (2013), pp. 1645–1660. ISSN: 0167739X. DOI: 10.1016/
j.future.2013.01.010. URL: https://linkinghub.elsevier.com/retrieve/pii/
S0167739X13000241.
[73] Pankesh Patel and D. Cassou. “Enabling high-level application development for the
internet of things”. In: 103 (Jan. 2015), pp. 62–84. DOI: 10.1016/jjss.2015.01.027.
[74] P.P. Ray. “A survey on Internet of Things architectures”. en. In: 30.3 (July 2018), pp. 291–
319. ISSN: 13191578. DOI: 10.1016/j.jksuci.2016.10.003. URL: https://linkinghub.
elsevier.com/retrieve/pii/S1319157816300799.
[75] Sabine Wolny, Alexandra Mazak, and Bernhard Wally. “An Initial Mapping Study on
MDE4IoT.” In: 2018, pp. 524–529.
[76] Jörg Christian Kirchhof et al. “Model-Driven Self-Adaptive Deployment of Internet of
Things Applications with Automated Modification Proposals”. In: 3.4 (2022). DOI: 10.
1145/3549553. URL: https://doi.org/10.1145/3549553.
[77] Manuela Dalibor et al. “Tagging Model Properties for Flexible Communication.” In:
2019, pp. 39–46.
[78] J S et al. “Towards Integrated Model-Driven Testing of SCADA Systems Using the
Eclipse Modeling Framework and Modelica”. en. In: ISSN: 1530-0803. Perth, Australia:
IEEE, Mar. 2008, pp. 149–159. ISBN: 978-0-7695-3100-7. DOI: 10 . 1109 / ASWEC . 2008 .
4483203. URL: http://ieeexplore.ieee.org/document/4483203/.
[79] Nicolai M Josuttis. " O’Reilly Media, Inc.", 2007.
[80] Jose Manuel Perez, Francisco Ruiz, and Mario Piattini. “MDE for BPM: a systematic
review”. In: Springer. 2008, pp. 127–135.
[81] Niels Schot. “QoS-aware model-driven SOA using SoaML”. MA thesis. University of
Twente, 2012.
[82] Cleber Jorge Lira de Santana, Brenno de Mello Alencar, and Cássio V. Serafim Prazeres.
“Reactive microservices for the internet of things: a case study in fog computing”. en.
In: Limassol Cyprus: ACM, 2019, pp. 1243–1251. ISBN: 978-1-4503-5933-7. DOI: 10.1145/
3297280.3297402. URL: https://dl.acm.org/doi/10.1145/3297280.3297402.
[83] Paolo Francesco, Ivano Malavolta, and Patricia Lago. “Research on Architecting Mi-
croservices: Trends, Focus, and Potential for Industrial Adoption”. In: Apr. 2017, pp. 21–
30. DOI: 10.1109/ICSA.2017.24.

127
[84] A. Salihbegovic et al. “Design of a domain specific language and IDE for Internet of
things applications”. en. In: Opatija, Croatia: IEEE, May 2015, pp. 996–1001. ISBN: 978-
953-233-082-3. DOI: 10.1109/MIPRO.2015.7160420. URL: http://ieeexplore.ieee.
org/document/7160420/.
[85] Benjamin Bertran et al. “DiaSuite: A tool suite to develop Sense/Compute/Control ap-
plications”. In: 79 (2014), pp. 39–51.
[86] Carlos Cetina et al. “Tool support for model driven development of pervasive systems”.
In: IEEE. 2007, pp. 33–44.
[87] Julien Mineraud et al. “A gap analysis of Internet-of-Things platforms”. In: 89 (2016),
pp. 5–16.
[88] Abdelouahab Fortas, Elhillali Kerkouche, and Allaoua Chaoui. “Application of MDE in
the Development of IoT Systems: A Simulation-Based Approach”. en. In: Jijel, Algeria:
IEEE, Nov. 2022, pp. 93–98. ISBN: 978-1-66546-188-7. DOI: 10.1109/I3CIS56626.2022.
10075784. URL: https://ieeexplore.ieee.org/document/10075784/.
[89] Armin Moin et al. “A Model-Driven Approach to Machine Learning and Software Mod-
eling for the IoT”. en. In: 21.3 (June 2022). arXiv:2107.02689 [cs], pp. 987–1014. ISSN:
1619-1366, 1619-1374. DOI: 10.1007/s10270- 021- 00967- x. URL: http://arxiv.org/
abs/2107.02689.
[90] Armin Moin, Stephan Rössler, and Stephan Günnemann. “Augmenting Model-Driven
Software Engineering for the Internet of Things with Machine Learning”. en. In: ().
[91] Rajeev Alur. “Formal verification of hybrid systems”. en. In: Taipei Taiwan: ACM, Oct.
2011, pp. 273–278. ISBN: 978-1-4503-0714-7. DOI: 10 . 1145 / 2038642 . 2038685. URL:
https://dl.acm.org/doi/10.1145/2038642.2038685.
[92] Jörg Christian Kirchhof et al. en. arXiv:2209.07282 [cs]. 2022. DOI: 10.1145/3550356.
3561576. URL: http://arxiv.org/abs/2209.07282.
[93] Evgeny Kusmenko et al. “Modeling and Training of Neural Processing Systems”. en.
In: Munich, Germany: IEEE, 2019, pp. 283–293. ISBN: 978-1-72812-536-7. DOI: 10.1109/
MODELS.2019.00012. URL: https://ieeexplore.ieee.org/document/8906978/.
[94] Panagiotis Kourouklidis et al. “A Model-Driven Engineering Approach for Monitor-
ing Machine Learning Models”. en. In: Fukuoka, Japan: IEEE, Oct. 2021, pp. 160–164.
ISBN: 978-1-66542-484-4. DOI : 10.1109/MODELS- C53483.2021.00028. URL : https://
ieeexplore.ieee.org/document/9643788/.
[95] Stuart Kent. “Model Driven Engineering”. In: ed. by Michael J. Butler, Luigia Petre, and
Kaisa Sere. Vol. 2335. Lecture Notes in Computer Science. Springer, 2002, pp. 286–298.
DOI : 10.1007/3-540-47884-1\_16. URL : https://doi.org/10.1007/3-540-47884-
1%5C_16.
[96] Thomas Hartmann et al. “The next evolution of MDE: a seamless integration of machine
learning into domain modeling”. en. In: 18.2 (2019), pp. 1285–1304. ISSN: 1619-1366,
1619-1374. DOI: 10.1007/s10270-017-0600-2. URL: http://link.springer.com/10.
1007/s10270-017-0600-2.
[97] Luis Palacios Medinacelli, Florian Noyrit, and Chokri Mraidha. “Augmenting model-
based systems engineering with knowledge”. en. In: Montreal Quebec Canada: ACM,
Oct. 2022, pp. 351–358. ISBN: 978-1-4503-9467-3. DOI: 10.1145/3550356.3561548. URL:
https://dl.acm.org/doi/10.1145/3550356.3561548.
[98] Matthias Althoff. “An Introduction to CORA 2015.” In: 34 (2015), pp. 120–151.
[99] Grigoris Antoniou and Frank van Harmelen. “Web ontology language: Owl”. In: (2009),
pp. 91–110.

128
[100] Michael Beetz et al. “Know Rob 2.0 — A 2nd Generation Knowledge Processing Frame-
work for Cognition-Enabled Robotic Agents”. In: 2018, pp. 512–519. DOI: 10 . 1109 /
ICRA.2018.8460964.
[101] Jorge Pérez, Marcelo Arenas, and Claudio Gutierrez. “Semantics and complexity of
SPARQL”. In: 34.3 (2009), pp. 1–45.
[102] Martin O’connor et al. “Writing rules for the semantic web using SWRL and Jess”. In:
(2005).
[103] Stefan John. “Towards a Configurable Crossover Operator for Model-Driven Optimiza-
tion”. en. In: (2022).
[104] Ali Alnoman. “Supporting Delay-Sensitive IoT Applications: A Machine Learning Ap-
proach”. en. In: London, ON, Canada: IEEE, Aug. 2020, pp. 1–4. ISBN: 978-1-72815-442-
8. DOI: 10.1109/CCECE47787.2020.9255800. URL: https://ieeexplore.ieee.org/
document/9255800/.
[105] Yuzhou Li et al. “Green Heterogeneous Cloud Radio Access Networks: Potential Tech-
niques, Performance Tradeoffs, and Challenges”. In: 55 (Nov. 2017), pp. 33–39. DOI:
10.1109/MCOM.2017.1600807.
[106] José Antonio Hernández López, Javier Luis Cánovas Izquierdo, and Jesús Sánchez
Cuadrado. “ModelSet: a dataset for machine learning in model-driven engineering”.
en. In: 21.3 (June 2022), pp. 967–986. ISSN: 1619-1366, 1619-1374. DOI: 10.1007/s10270-
021-00929-3. URL: https://link.springer.com/10.1007/s10270-021-00929-3.
[107] Albert Benveniste and Gérard Berry. “The Synchronous Approach to Reactive and Real-
Time Systems”. In: 79 (Oct. 1991), pp. 1270–1282. DOI: 10.1109/5.97297.
[108] Stuart Bennett. en. 1. print. Prentice Hall International series in systems and control
engineering. New York: Prentice Hall, 1988. ISBN: 978-0-13-762485-0.
[109] Lina Marsso et al. “Asynchronous Testing of Synchronous Components in GALS Sys-
tems”. en. In: ed. by Wolfgang Ahrendt and Silvia Lizeth Tapia Tarifa. Vol. 11918. Se-
ries Title: Lecture Notes in Computer Science. Cham: Springer International Publish-
ing, 2019, pp. 360–378. DOI: 10.1007/978- 3- 030- 34968- 4_20. URL: http://link.
springer.com/10.1007/978-3-030-34968-4_20.
[110] Nicolas Halbwachs. “Synchronous Programming of Reactive Systems”. en. In: ().
[111] Florence Maraninchi. “Modélisation et validation des systèmes réactifs: un langage syn-
chrone à base d’automates”. en. In: (1997).
[112] Albert Benveniste, Michel Borgne, and Paul Guernic. “SIGNAL as a model for real-
time and hybrid systems”. In: ed. by Gerhard Goos, Juris Hartmanis, and Bernd Krieg-
Brückner. Vol. 582. Series Title: Lecture Notes in Computer Science. Berlin, Heidelberg:
Springer Berlin Heidelberg, 1992, pp. 20–38. ISBN: 978-3-540-55253-6. DOI: 10.1007/3-
540-55253-7_2. URL: http://link.springer.com/10.1007/3-540-55253-7_2.
[113] Albert Benveniste et al. “The Synchronous Languages Twelve Years Later”. en. In: ().
[114] Ramesh Bharadwaj. “SOL: A verifiable synchronous language for reactive systems”. In:
65.5 (2002), pp. 140–154.
[115] Sunghyeon Lee, Yeongbok Choe, and Moonkun Lee. “dT-Calculus: A Formal Method
to Specify Distributed Mobile Real-Time IoT Systems”. en. In: ed. by Jaydip Sen. InTech,
Aug. 2018. ISBN: 978-1-78923-548-7. DOI: 10.5772/intechopen.75138. URL: http://
www . intechopen . com / books / internet - of - things - technology - applications -
and- standardization/dt- calculus- a- formal- method- to- specify- distributed-
mobile-real-time-iot-systems.

129
[116] Shabir Ahmad et al. “Towards the Design of a Formal Verification and Evaluation Tool
of Real-Time Tasks Scheduling of IoT Applications”. en. In: 11.1 (Jan. 2019), p. 204. ISSN:
2071-1050. DOI: 10.3390/su11010204. URL: https://www.mdpi.com/2071-1050/11/1/
204.
[117] Pedro Sánchez et al. “A Teleo-Reactive Node for Implementing Internet of Things Sys-
tems”. en. In: 18.4 (2018), p. 1059. ISSN: 1424-8220. DOI: 10 . 3390 / s18041059. URL:
https://www.mdpi.com/1424-8220/18/4/1059.
[118] Nils Nilsson. “Teleo-reactive programs for agent control”. In: 1 (1993), pp. 139–158.
[119] Jose Luis Morales, Pedro Sánchez, and Diego Alonso. “A systematic literature review
of the Teleo-Reactive paradigm”. en. In: 42.4 (Dec. 2014), pp. 945–964. ISSN: 0269-2821,
1573-7462. DOI: 10.1007/s10462-012-9350-2. URL: http://link.springer.com/10.
1007/s10462-012-9350-2.
[120] S Kent. 2002.
[121] Pankesh Patel and Damien Cassou. “Enabling high-level application development for
the Internet of Things”. In: 103 (2015), pp. 62–84.
[122] Damien Cassou et al. “Toward a tool-based development methodology for pervasive
computing applications”. In: 38.6 (2011), pp. 1445–1463.
[123] Estefanía Serral, Pedro Valderas, and Vicente Pelechano. “Towards the model driven
development of context-aware pervasive systems”. In: 6.2 (2010), pp. 254–280.
[124] Hussam Al-Hamadi, Amjad Gawanmeh, and Mahmoud Al-Qutayri. “Formalizing elec-
trocardiogram (ECG) signal behavior in event-B”. en. In: Natal: IEEE, Oct. 2014, pp. 55–
60. ISBN: 978-1-4799-6644-8. DOI: 10 . 1109 / HealthCom . 2014 . 7001813. URL: http : / /
ieeexplore.ieee.org/document/7001813/.
[125] Jean-Raymond Abrial. Cambridge University Press, 2010.
[126] Paolo Buono et al. “EUDroid: a formal language specifying the behaviour of IoT de-
vices”. In: 12.5 (2018), pp. 425–429. DOI: https://doi.org/10.1049/iet- sen.2017.
0347. eprint: https://ietresearch.onlinelibrary.wiley.com/doi/pdf/10.1049/
iet- sen.2017.0347. URL: https://ietresearch.onlinelibrary.wiley.com/doi/
abs/10.1049/iet-sen.2017.0347.
[127] Amit Kr Mandal et al. “Things as a Service: Service model for IoT”. en. In: Helsinki, Fin-
land: IEEE, July 2019, pp. 1364–1369. ISBN: 978-1-72812-927-3. DOI: 10.1109/INDIN41052.
2019.8972241. URL: https://ieeexplore.ieee.org/document/8972241/.
[128] Carlos A. Gonzalez et al. “EMFtoCSP: A tool for the lightweight verification of EMF
models”. en. In: Zurich, Switzerland: IEEE, June 2012, pp. 44–50. ISBN: 978-1-4673-1906-
5. DOI: 10 . 1109 / FormSERA . 2012 . 6229788. URL: http : / / ieeexplore . ieee . org /
document/6229788/.
[129] Vipin Kumar. “Algorithms for constraint-satisfaction problems: A survey”. In: 13.1 (1992),
pp. 32–32.
[130] Mark Wallace, Stefano Novello, and Joachim Schimpf. “ECLiPSe: A platform for con-
straint logic programming”. In: 12.1 (1997), pp. 159–200.
[131] Kyriakos Anastasakis et al. “UML2Alloy: A challenging model transformation”. In:
Springer. 2007, pp. 436–450.
[132] Adel Ferdjoukh et al. “A CSP Approach for Metamodel Instantiation”. en. In: Hern-
don, VA, USA: IEEE, Nov. 2013, pp. 1044–1051. ISBN: 978-1-4799-2972-6. DOI: 10.1109/
ICTAI.2013.156. URL: http://ieeexplore.ieee.org/document/6735367/.
[133] Alix Mougenot et al. “Uniform random generation of huge metamodel instances”. In:
Springer. 2009, pp. 130–145.

130
[134] Karsten Ehrig, Jochen Malte Küster, and Gabriele Taentzer. “Generating instance mod-
els from meta models”. In: 8 (2009), pp. 479–500.
[135] Karsten Ehrig et al. “Generating instance models from meta models”. In: Springer. 2006,
pp. 156–170.
[136] Sagar Sen, Benoit Baudry, and Jean-Marie Mottu. “On combining multi-formalism knowl-
edge to select models for model transformation testing”. In: IEEE. 2008, pp. 328–337.
[137] Sagar Sen, Benoit Baudry, and Jean-Marie Mottu. “Automatic model generation strate-
gies for model transformation testing”. In: Springer. 2009, pp. 148–164.
[138] Chayan Sarkar et al. “A scalable distributed architecture towards unifying IoT appli-
cations”. en. In: Seoul, Korea (South): IEEE, Mar. 2014, pp. 508–513. ISBN: 978-1-4799-
3459-1. DOI: 10.1109/WF- IoT.2014.6803220. URL: http://ieeexplore.ieee.org/
document/6803220/.
[139] Angelo P Castellani et al. “Architecture and protocols for the internet of things: A case
study”. In: IEEE. 2010, pp. 678–683.
[140] Steve Beier et al. “Discovery Services-Enabling RFID Traceability in EPCglobal Net-
works.” In: vol. 6. 1. 2006, pp. 214–217.
[141] Novi Ineke et al. “Address autoconfiguration in wireless ad hoc networks: Protocols
and techniques”. In: 15.1 (2008), pp. 70–80.
[142] Dominique Guinard et al. “Interacting with the soa-based internet of things: Discovery,
query, selection, and on-demand provisioning of web services”. In: 3.3 (2010), pp. 223–
235.
[143] Patrik Spiess et al. “SOA-based integration of the internet of things in enterprise ser-
vices”. In: IEEE. 2009, pp. 968–975.
[144] Md Shohel Khan, Ratul Sikder, and Muhammad Abdullah Adnan. “A Hybrid Ap-
proach for Synchronizing Clocks in Distributed Systems”. en. In: ed. by Dilma Da
Silva, Qingyang Wang, and Liang-Jie Zhang. Vol. 11513. Series Title: Lecture Notes in
Computer Science. Cham: Springer International Publishing, 2019, pp. 271–286. DOI:
10.1007/978-3-030-23502-4_19. URL: http://link.springer.com/10.1007/978-3-
030-23502-4_19.
[145] Li Gun et al. “A novel method of clock synchronization in distributed systems”. In: 41.2
(2017), pp. 263–281.
[146] Arie Reichman, Miri Priesler, and Shahaf Wayer. “Distributed network synchroniza-
tion”. In: IEEE. 2015, pp. 1–5.
[147] Jeman Park and Taeho Kim. “A method of logically time synchronization for safety-
critical distributed system”. In: IEEE. 2016, pp. 356–359.
[148] Patrik Spiess et al. “SOA-based integration of the internet of things in enterprise ser-
vices”. In: IEEE. 2009, pp. 968–975.
[149] Abdullah Al-Nayeem. University of Illinois at Urbana-Champaign, 2013.
[150] Avinash Malik et al. “SystemJ: A GALS language for system level design”. en. In: 36.4
(Dec. 2010), pp. 317–344. ISSN: 14778424. DOI: 10 . 1016 / j . cl . 2010 . 01 . 001. URL:
https://linkinghub.elsevier.com/retrieve/pii/S1477842410000023.
[151] S Ramesh. “Communicating reactive state machines: Design, model and implementa-
tion”. In: 31.32 (1998), pp. 105–110.
[152] Gérard Berry. “The Esterel v5 language primer version 5.21 release 2.0”. In: 36 (1999).
[153] Olivier Tardieu and Stephen A Edwards. “Scheduling-independent threads and excep-
tions in SHIM”. In: 2006, pp. 142–151.

131
[154] Jose Meseguer. “Formalization and Correctness of the PALS Architectural Pattern for
Distributed Real-Time Systems”. en. In: ().
[155] Albert Benveniste. “Synchronous Languages and Reactive System Design”. In: 31.15
(1998). 9th IFAC Symposium on Information Control in Manufacturing 1998 (INCOM
’98), Nancy, France, 24-26 June, pp. 35–46. ISSN: 1474-6670. DOI: https://doi.org/10.
1016 / S1474 - 6670(17 ) 40526 - X. URL: https : / / www . sciencedirect . com / science /
article/pii/S147466701740526X.
[156] Zhibin Yang, Jean-Paul Bodeveix, and Mamoun Filali. “A comparative study of two for-
mal semantics of the SIGNAL language”. en. In: 7.5 (Oct. 2013), pp. 673–693. ISSN: 2095-
2228, 2095-2236. DOI: 10.1007/s11704-013-3908-2. URL: http://link.springer.com/
10.1007/s11704-013-3908-2.
[157] Frédéric Boussinot and Robert De Simone. “The ESTEREL language”. In: ().
[158] Nicholas Halbwachs et al. “The synchronous data flow programming language LUS-
TRE”. In: 79.9 (1991), pp. 1305–1320.
[159] Albert Benveniste, Paul Le Guernic, and Christian Jacquemot. “Synchronous program-
ming with events and relations: the SIGNAL language and its semantics”. In: 16.2
(1991), pp. 103–149. ISSN: 0167-6423. DOI: https://doi.org/10.1016/0167-6423(91)
90001-E. URL: https://www.sciencedirect.com/science/article/pii/016764239190001E.

132
Webography

[160] Vladimir Keleshev. 2022. URL: https://keleshev.com/abstract- syntax- tree- an-

example-in-c.
[161] . 2013. URL: https://iot.samteck.net/enablers/networking/what-is-ntp-sntp-
protocols/.
[162] Ngomba Litombe. 2023. URL: https://medium.com/@litombeg/concurrency- in- c-
mutexes-and-locks-part-1-d0cc06bade11.
[163] . URL: https://labstreaminglayer.org/.
[164] Biomedical Engineering Group. URL: https://www.medusabci.com/home/.
[165] . URL: https://www.redhat.com/en/topics/cloud-native-apps/what-is-service-
oriented-architecture.
[166] . URL: https://aws.amazon.com/fr/what-is/service-oriented-architecture/.
[167] . URL: https://martinfowler.com/tags/microservices.html.
[168] . URL: %5Curl%7Bhttps://vertx.io/%7D.
[169] The Apache ServiceMix Team. URL: https://servicemix.apache.org/.
[170] Christopher Guindon. URL: https://www.eclipse.org/community/eclipse_newsletter/
2016/april/article3.php.
[171] . URL: https://nodered.org/.
[172] . URL: https://www.openhab.org/.
[173] . URL: https://www.tensorflow.org/tensorboard?hl=fr.
[174] URL : https://keras.io/.
[175] . URL: https://www.knime.com/.
[176] . URL: https://rapidminer.com/.
[177] . URL: https://scikit-learn.org/stable/.
[178] . URL: https://pureportal.strath.ac.uk/en/datasets/refit-electrical-load-
measurements-cleaned.
[179] . URL: https://www.kaggle.com/datasets/hojjatk/mnist-dataset.
[180] . URL: https://projects.eclipse.org/projects/modeling.mdt.papyrus.
[181] . URL: https://mde-optimiser.github.io/.
[182] . URL: https://pymoo.org/algorithms/moo/nsga2.html.
[183] . URL: https://wiki.eclipse.org/Henshin/Transformation_Meta-Model.
[184] . [Accessed 13-11-2023]. URL: https://www.geeksforgeeks.org/understanding-tf-
idf-term-frequency-inverse-document-frequency/.
[185] . URL: https://pypi.org/project/Whoosh/.

133
[186] . URL: https://modelset.github.io/.
[187] . URL: https://byjus.com/gate/difference-between-hard-real-time-and-soft-
real-time-system/.

134