[image] [image] Ressource protégée - Inria - Institut national de recherche en sciences et technologies du numérique [Accéder directement au contenu](#)

[image] [image]

* [Documentation](#)

* FR
  Français (FR)

* Anglais (EN)
  Se connecter

* [Portail HAL Inria](#)

* Recherche
  Loading...

## Recherche avancée

Information de documents

Titres

○ Titres

○ Sous-titre

○ Titre de l'ouvrage

○ Titre du volume (Série)

○ Champ de recherche par défaut (multicritères) + texte intégral des PDF

○ Résumé

○ Texte intégral indexé des documents PDF

○ Mots-clés

○ Type de document

○ Sous-type de document

○ Tous les identifiants du document

○ Identifiant HAL du dépôt

○ Langue du document (texte)

○ Pays (Texte)

○ Ville

○ À paraître (true ou false)

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

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
## Auteur

### Auteur (multicritères)

○ Auteur (multicritères)

○ Auteur : Nom complet

○ Auteur : Nom de famille

○ Auteur : Prénom

○ Auteur : Complément de nom, deuxième prénom

○ Auteur : Organisme payeur

○ Auteur : IdHal (chaîne de caractères)

○ Auteur : Fonction

○ Auteur : personID (entier)

○ Auteur : Identifiant de l'organisme payeur

○ Auteur : Identifiant de la structure

○ Directeur de thèse

○ Éditeur

○ Éditeur scientifique

○ Éditeur de la série

## Ajouter

### Structure

#### Structure (multicritères)

○ Structure (multicritères)

○ Structure : Acronyme

○ Structure : Nom

○ Structure : Code

○ Structure : Pays

○ Structure : Type

○ Structure : État dans le référentiel

○ Structure : Identifiant HAL de la structure

○ Structure/équipe de recherche : Pays

○ Structure/regroupement d'équipes : Pays

○ Structure/laboratoire : Pays

○ Structure/regroupement de laboratoires : Pays

○ Structure/institution : Pays

○ Structure/regroupement d'institutions : Pays

## Ajouter
# A Proposal to Trace and Maintain Requirements Constraints of Real-time Embedded Systems

Fabíola Gonçalves C. Ribeiro²[0000-0002-3303-9396], Achim Rettberg²[0000-0002-9181-1110], Carlos E. Pereira³[0000-0003-4315-4256], Charles Steinmetz⁴[0000-0002-1579-1701], and Michel S. Soares⁵[0000-0002-7193-5087]

¹ Federal Institute Goiano, Brazil, fgcr.ufg@gmail.com

² University of Applied Science Hamm/Lippstadt and CvO University Oldenburg, Germany, achim.rettberg@iess.org

Federal University of Rio Grande do Sul, Brazil, cpereira@ece.ufrgs.br

³ University of Applied Science Hamm/Lippstadt, Germany, charlessteinmetzk@gmail.com

⁴ Federal University of Sergipe, Brazil, mics.soares@gmail.com

**Abstract.** The development of Real-Time Embedded Systems (RTES) considering critical and volatile system and software requirements is a difficult and error-prone activity. The capability to describe system components while highlighting and maintaining their correlations at different abstraction levels and refinements has a significant impact on RTES development. Most techniques for designing RTES present many problems and limitations regarding tracing RTES constraints along of architectural design. Moreover, there is a gap in integrated strategies to evaluate the correctness of these constraints from model specification to the system models realization. This article aims to perform a study on Model-Driven Systems Engineering approaches applied in the design and traceability of specific RTES constraints. The main objective of this study is to automatically perform an evaluation of traced non-functional concerns and provide feedback to the developers regarding the validity of the simulated constraints. In order to achieve this objective, this study, initially, develops a formalized manner to specify RTES constraints in architectural viewpoints and a tool to evaluate the real simulated values of these specifications.

**Keywords:** SysML · MARTE · Real-Time Systems · Non-Functional Constraints.

## 1 Introduction

RTES have been increasingly present in human activities and many of them present high level of complexity, smartness and automation. For instance, controlling the diversity of infrastructures - water, energy, transportation and so on - improving citizens access to services, which leads to smart, heterogeneous and complex software controllers [15], [16].
Autres

Champ de recherche par défaut (multicritères)

○ <u>Champ de recherche par défaut (multicritères)</u>

○

○ <u>Revues (multicritères)</u>

○ <u>Revue : Éditeur</u>

○ <u>Revue : Titre abrégé</u>

○ <u>Revue : Titre</u>

○ <u>Revue : Identifiant interne</u>

○ <u>Revue : Date de début de publication</u>

○ <u>Revue : ISSN électronique</u>

○ <u>Revue : ISSN</u>

○ <u>Revue : Éditeur</u>

○ <u>Revue : Couleur dans SHERPA/RoMEO</u>

○ <u>Revue : État dans le référentiel</u>

○

○ <u>Colloque (multicritères)</u>

○ <u>Colloque : Titre</u>

○ <u>Colloque : Organisateur</u>

○ <u>Colloque : date de début (Année)</u>

○ <u>Colloque : date de fin (Année)</u>

○ <u>Conférence invitée (oui/non)</u>

○

○ <u>Projets ANR (multicritères)</u>

○ <u>Projet ANR : Acronyme</u>

○ <u>Projet ANR : Acronyme du programme</u>

○ <u>Projet ANR : Code décision (référence)</u>

○ <u>Projet ANR : Nom</u>

○ <u>Projet ANR : Identifiant interne</u>

○ <u>Projet ANR : État dans le référentiel</u>

○

○ <u>Projets européens (multicritères)</u>

○ <u>Projet européen : Acronyme</u>

○ <u>Projet européen : Identifiant de l'appel à projet</u>

○ <u>Projet européen : Référence</u>

○ <u>Projet européen : Nom</u>

○ <u>Projet européen : Date de fin</u>

○ <u>Projet européen : Financement</u>

○ <u>Projet européen : Date de début</u>
Traceability is an important knowledge for improving the artifacts of software and systems and processes related to them. Even in a single system, various kinds of artifacts exist, and each of them relates to different kinds of artifacts. Traceability over them has thus large diversity. In addition, developers in each process have different types of purposes to improve their artifacts and processesResearch regarding traceability can be categorized and analyzed so that such a developer can choose one of them to achieve his/her purposes.

The most common approach to write requirements specifications for software is through natural language [10]. Natural languages have no mathematical structure, thus they present difficulties to be properly analyzed [3]. As a result, problems such as imprecision, difficulty of understanding, ambiguity and inconsistency are common when natural language is used [20]. However, as the main mean of communication between stakeholders, natural language can not be simply avoided. Structured languages [20] allow the designer to write requirements using a pre-formatted pattern. Their main characteristic is to contain most part of the ease of expression and understanding of natural languages, ensuring that some degree of uniformity is imposed in the specifications. However, structured natural languages are neither formal nor graphical and, in some cases, are inadequate for modern programming languages and paradigms [18].

Managing traces between large, complex real-time systems artefacts has been a concern of many studies in past years [23], [17], [19], [5], [4]. In a study performed by Gills [23], an issue discussed about traceability of requirements is that most companies create their own trace metamodel almost from scratch, which normally leads to huge effort and frustration. In addition, traces are poorly recorded and almost never consulted as a support for other software development activities. According to Gills, using a well-known modeling language, such as the one proposed in this article, can diminish these problems. The SysML language has been successfully applied to model and to trace requirements. The work presented in [17] refers to the application of the SysML Requirements diagram for the specification of system requirements.

In [2], a method to facilitate the development of systems with safety-critical requirements, linking the functional design phase using SysML is proposed. In [22], SysML is used together with *Alloy*, a modelling and design tool, to formally specify the semantics and syntax of SysML Requirements diagrams. In [6], SysML is used for the analysis of requirements of military aircraft. The choice in this article is not to start from scratch, as criticized by Gills, but to start elements provided by the SysML language to deal with the traceability problem in software systems. The choice is based on two facts. First, SysML is derived from UML, a well-known modeling language both in academia and industry. Second, and most important, the SysML metamodel brings a new diagram which is specific to model and to trace requirements. However, the current state of the language is not complete enough to satisfy many of the needs of representation, description, trace, and manipulation of requirements for RTS.

This paper focuses on three important contributions to the RTES development while highlighted traceability strategies to architectural models. (1) Auto-
○ Projet européen : État dans le référentiel

○ Projet européen : Identifiant interne

○

○ Date de production : année

○ Date de mise en ligne : année

○ Date de publication : année

○ Date d'écriture : année

○ Date de modification du dépôt : année

○ Date de dépôt : année

○ Date de publication électronique : année

○

○ Collection HAL (multicritères)

○ Collection HAL : catégorie

○ Collection HAL : Code

○ Collection HAL : Nom

○ Collection HAL : Identifiant interne

○

○ Identifiant interne du contributeur/déposant

○ Nom complet du contributeur/déposant

○

○ Domaines

○ Domaine primaire

○ Domaine racine

○ Sous-domaine niveau 1

○ Sous-domaine niveau 2

○ Sous-domaine niveau 3

○

○ Statut du document

○ Version du document

○ Type de dépôt

○ Type de document

○ ISBN

○ Numéro - référence

○ Identifiant DOI

○

○ Classification

○ Audience

○ Vulgarisation

○ Comité de lecture - texte (oui ou non)

○ Actes de colloque
matic Code Generation from Papyrus to C++ Code, highlighting non-functional
constraints, in order to favorize the implementation of the designed RTES. (2)
Automatic Code Generation, from Papyrus to XML format, in order to extract,
from graphical models, information of constrained model elements. It focuses on
the values of the periodic and deadlines constraints. (3) A tool to evaluate the
designer's assumptions versus the runtime system behavior.

## 2 A Proposal to Trace MARTE Constraints

Traceability of RTES constraints is performed, in this study, by the adoption of enumerated and standard labels. A strategy is developed to trace the constraints along the system viewpoints. A specific constraint has different nomenclature in its ID at distinctive abstraction levels. However, the integer number which is part of the ID does not change in each viewpoint.

In the architectural models each constraint of the MARTE profile is labeled
as an specific “ID”. Figure 1 shows the trace of non-functional constraints in
different viewpoints. For example, a periodic constraint, of the Logical viewpoint,
has the following L_Nfp_T“x” identification where:

<figure><img src="image_2.png" /><figcaption>Fig. 1. Trace of << *NfpConstraint* >> from Functional Viewpoint to Logical Viewpoint.</figcaption></figure>

- The first parameter identifies the viewpoint. For example, **L** corresponds to the Logical viewpoint.

- The second parameter relates to the type of the constraint. In the example, **Nfp** recognizes a non-functional constraint.

- The third parameter defines an immutable number to identify the constraint. The variable "x" is an integer variable. This number represents a value which traces and distinguishes a constraint in different views and viewpoints.
○ Référence interne

○ Financement

○ Collaborations

Ajouter

Lancer la recherche

Recherche experte (SolR)

Recherche experte (SolR)

Lancer la recherche
Vers la recherche avancée

• Déposer

Portail INRIA.HAL.SCIENCE
Les publications, logiciels... des scientifiques Inria

• Accueil

• Publications Inria

○ Consulter les derniers dépôts

○ Par équipe de recherche

○ Par auteur

○ Rapports de recherche et techniques

○ Livres blancs

○ Rapports d'activité des équipes

○ Statistiques

• Boite à Outils

○ X2Hal : importer par lot

○ Logiciels : créer le Codemeta.json

○ Créer mon IDHal

○ Créer mon CVHal

○ Haltools : créer ma page de publications

○ Haltools : extraire des données (réservé Inria)

○ Les bonnes pratiques

■ Comment bien s'affilier ?
* In the case that the constraint is labelled by ≪ *NpfConstraint* ≫ stereotype, the label **P** or **F** is also applied in the third part of the ID. These characters describe if ≪ *NpfConstraint* ≫ relates to a periodic time (**P**) or timing duration (**T**). For example, **T** sets this constraint as computation time value (for example, deadline);

Figure 1 shows slices of the architectural viewpoint models labeled by suggested labels. As detailed in [12], automatic code generations are performed in order to provide an executable version of the system. Once the authors consider the proposed standard of the MARTeSys<sup>ReqD</sup> methodology, as introduced in this paper, in different abstraction levels the generated code also receives the translated non-functional annotations. Thus, the automatic translation, performed here, is able to generate graphical constraints, of viewpoint models, as textual information in the source code. After complete development of the system, partially manually made, the developed tool can combine, evaluate and compare the constraints values.

## 3 Case Study in the RTES Domain

The proposed case study and the architectural models were already detailed in [11] and [13]. This study relates to the Turn Indicator Controller System (TICS). The TICS is manipulated by drivers when they want to use the lights system to signalize the intention to change the directions of the car.

Requirements specification of TICS are defined in [13]. Figure 2 shows a usage scenario of the Turn Indicator. In this example, features which are related either with turn indicator or hazard controllers are shown.

<figure><img src="image_3.png" /><figcaption>**Fig. 2.** An Example Scenario of Turn Indicator System.</figcaption></figure>

In Figure 2 the labels 1 to 5 represent distinctive positions of the car based on the driver's actions as follows:

1. Driver identifies an accident and turns the hazard lights;

2. Driver needs to change lane and turns the flashing lights in hard manner to the left side;
■ Quelle version puis-je déposer ?

■ Choisir le bon « type de document »

■ Mettre en valeur ses publications

○ Les tutos IES Inria

■ Lier les notices dans HAL

■ Umbrhal Inria pour l'accessibilité

■ Personnaliser son CVHAL

■ Créer et Personnaliser sa collection

• Documentation

○ Aide en ligne HAL

○ Aide en ligne Haltools

○ Aide en ligne X2hal

○ Tutoriels video HAL

○ Documentation API HAL

○ Ajouter des vignettes

○ Identifiant auteur IdHAL et CV

○ Compléter son dossier ORCID avec ses dépôts HAL

○ Inria et la Science Ouverte

X

X

X

Loading...

X

Le document que vous demandez est en access restreint
jusqu'au 2026-01-01 !

Revenir a la notice

Retourner à l'accueil

Contact

•

Ressources
3. Driver turns off the flashing lights;

4. Driver needs to change lane and turns the flashing lights in soft manner to the right side;

5. Driver overpasses the anomaly situation and turns off the hazard lights.

RTES constraints have been annotated in architectural models following the MARTeSys<sup>ReqD</sup> methodology. From these annotations, as depicted in Figure 3, an early dynamics analysis of timing and precedence constraints to the developed system is performed. In order to perform the trace and analysis of the annotated constraints this study suggest the **NFP Constraints Simulation** and the **Comparison of Constraints** phases in order to suggest/allow the improvement and examination of the designers assumptions and runtime behavior of the tasks.

<figure><img src="image_4.png" /><figcaption>Fig. 3. Classes Diagram, from the Model and Unit Model, with RTES Constraints.</figcaption></figure>

**NFP Constraints Simulation** adopts empirical/experimental techniques to evaluate the system services realization and the constraints which are imposed on these services. The main objective of this Phase is to describe a common manner to simulate timing, schedulability and precedence constraints of RTES. **Comparison of Constraints** provides strategies to check if the constraints, under the system services, are reached in the final development stage. This phase provides automatic comparisons of constraints from different abstraction levels
* Documentation

* FAQ

* API

* OAI-PMH

* AuréHAL

## Informations

* À propos

* Données personnelles

* Mentions légales

* Accessibilité

* Conformité RGAA

## Questions juridiques

* Je publie, quels sont mes droits ?

* Loi pour une République numérique

* Stratégie de non-cession des droits

* SHERPA/RoMEO

## Portails

* Portails institutionnels

* HAL

* HAL SHS

* HAL Thèses

* MédiHAL

## CCSD

* CCSD

* Episciences

* Sciencesconf
regarding the implemented system. If any inconsistency between architectural constrained models and the final implementation models is identified, an error message appears as a recommendation to the designers.

## 3.1 Manual Analysis and Comparison of Constraints

The designer assumptions, already annotated in architectural models, can be compared with the executable values, from system' tasks. Figures 4 and 5 depict, in average, the period of 1500 executed samples to the constrained and periodic *TurnIndicatorFeature* and *HazardFeature* classes (see Figure 3). In the implemented system, the system constraints are respectively imposed in tasks *taskTurnFlashing* and *taskHazardFlashing*.

<figure><img src="image_5.png" /><figcaption>Fig. 4. Period of Turn Flashing Task.</figcaption></figure>

The empirical validation considers the runtime behavior of tasks. It allows timing measurements of design and development models. Moreover, it enables, by simulation techniques, to validate the constrained runtime behavior.

The tasks *taskTurnFlashing* and *taskHazardFlashing* have the same constrained period of 40 ms. Figures 4 and 5 present the results of the simulation activity of the mentioned tasks and it shows that the real period occurs within 35,33 ms. In this case, as detailed in following, $τ_1$ and $τ_2$ were executed respecting their predefined deadlines. The measurements of processor utilization of $τ_1$ and $τ_2$ are, respectively, $U_3^m = 1, 1/35, 3 = 0,031$ and $U_4^m = 1, 1/35, 3 = 0,031$.
<figure><img src="image_6.png" /><figcaption>Fig. 5. Period of Hazard Task.</figcaption></figure>

In this study, it is considered processor utilization [8], described in Equation 1, to analyse the feasibility of a given task set.

Function 1 shows that the utilization factor should be less or equal the $U_{lub}$. The attendance to this inequality ($U \le U_{lub}$) is sufficient, but not necessary to guarantee the feasibility of a given task set.

$$ \sum_{i=1}^{n} (C_i/T_i) \le n \cdot (2^{1/n} - 1) \quad (1) $$

From the proposed analysis, a tool to analyze the models assumptions and the runtime behavior of the tasks is proposed. It is possible to connect information from validating results (NFP Constraints Simulation phase) with early design artefacts and improve them (Comparison of Constraints). This analysis can denote that the RTES constraints can be represented in early design viewpoints, fulfilled at different abstraction levels and reached and simulated in the final development phase. Moreover, it proves that there is consistency between the architectural constrained models and the final model implementation regarding constraints estimation. Finally, it also indicates that constrained parameters, which are related with real-time schedule/precedence, can be satisfied and evaluated.
## 4 Proposed Tool to Automatic Analysis of Timing Constraints

The tool *constraintChecker* performs the interface between the architectural models, more specifically the .xml files, automatically generated from the Class diagram modeled on Papyrus tool [9], and the system developed. This tool allows automatic discovering of errors in the model’s assumptions to the non-functional constraints. Figure 6 depicts the tool interface.

<figure><img src="image_7.png" /><figcaption>Fig. 6. RTES Constraints Checker.</figcaption></figure>

The proposed tool reads the models in order to get pre-defined constraint values (Assumption field) and compare them with runtime behavior (Real field) of the related task. As can be observed in Figure 6, on the right side, these values are calculated based on Arduino execution logs that contain period/deadline values of the occurrence of each task. Finally, the phrase “Respect the Assumption” or “Discrepant values” is presented in the tool interface in order to inform whether the constraint is respected by designer assumptions. These messages collaborate with guidelines of necessary adaptations, refinements of requirements and improvements of architectural models since early stages of RTES development.
It is not a simple activity to categorize the period and deadline constraints.
The authors consider, in the evaluation of periodic constraints, if a task is exe-
cuted respecting its initial assumption. It means the task deadline is ≤ |period|.
Otherwise, if the task has a deadline ≥ period an error message and the con-
straint identification is presented to the user.

The developed tool provides a strategy to trace and verify the constraints at
different perspectives. Thus, it is possible to check the constraints from the ar-
chitectural design models, as for example, the Class diagram constraints, against
the implemented/executed constraints. In this case, it is possible to evaluate the
real values of timing constraints which were previously annotated by MARTE
stereotypes.

# 5 Discussion

Modeling, simulation and verification activities describe some of the most power-
ful techniques in modern RTES development [24]. Thus, in RTES development,
it is very important the adoption of well-defined, reliable and automated tech-
niques to timing prediction since the initial design stages [25].

The study proposed in [24] depicts a real-time simulation proposal for auto-
motive systems. The simulator works analyzing the XML format file of a UP-
PAAL model and transforming it into a model into the C++ code. The timed
automata in UPPAAL [21] can be simulated based on the C++ code analyzing
clock and event constraints.

An approach to automated timing prediction of real-time systems is pre-
sented in [14]. The authors develop a pivot model and transformation rules
which favoring the design process and allowing the verification of the system
timing behavior at the early design stages. It considers a timing pivot model
that must be followed in order to adapt all design models in the verification
tool semantic. Thus the verification models can be created and analyzed. In our
case, instead of creating an interface between two different tools - modeling tool
(CAPELLA [1]) and model-checking tool (ROMEO [7]), we develop a tool which
performs data analysis of timing constraints based on designers assumptions and
runtime system behavior.

The proposed modelChecker allows annotating real-time embedded constraints
and provides a standard manner to describe important system properties. More-
over, it allows tracing these constraints/properties in different abstraction levels.
The developed tool can be applied at different scenarios of RTES development
without needing transformation rules or extra-knowledge to perform the pro-
posed timing analysis.

In this study, simulation and measurements of constraints values are per-
formed in order to check correctness, consistency and feasibility of initial timing
annotations. These measurements are performed regarding execution time and
scheduling policy of each task. Here, the empirical evaluation of RTES con-
straints aims to answer two questions:

1. Do the system tasks hold their deadline?
2. Does the periodic task set fulfil the requirements of the scheduling policy?

Simulation of RTES constraints can support correctness of design decisions, favour quantitative analysis of non-functional concerns and contribute to refinements of these constraints even after system implementation. Furthermore, it contributes to investigation of empirical evaluation questions.

The system implementation respects and follows the traced constraints from the Class diagram model of Figure 3. From these annotations, timing analysis of annotated constraints are dynamically performed. The empirical analysis and the generated feedback also contributes to maintenance of timing constraints at different viewpoints. Therefore, it is possible to figure out possible discrepancies between the predefined values of constraints and the ones which come from the automated verification activities. Refinements can be proposed when there are inconsistencies between the initial values, which were modeled by designers, and the simulated values, after dynamic execution, of constrained values. Besides, if it is necessary to improve the models or to evaluate the design decisions regarding the software or hardware platform.

# 6 Conclusion

This paper presents an strategy to trace and evaluate consistency between models assumptions, performed by designers, and runtime behavior considering the developed system. Moreover, a technique to define and annotate constraints in architectural models, at different abstraction levels, is developed in order to provide a common manner to label related constraints along of architectural models.

Contributions of this research can be summarized the following: (1º) it traces RTES constraints along of architectural design to the system realization, (2º) it automatically compares annotated timing constraints against system implementation results and (3º) it shows an strategy to design and trace RTES constraints along architectural design.

The developed tool can visualize if the model constraints the timing con-
straints are fulfilled, and that they can be reached in the final development
phase. Moreover, it proves that there is a consistency between the architectural
timed constrained models and the final model implementation regarding con-
straints estimation. Finally, it also indicates that real-time schedule constrained
parameters are satisfied.

As future work, it is necessary to improve the toolset to automatically provide
guidelines for improvement of affected viewpoints and their models. In this case,
more than the identification of the constraints (by its ID), for refinement, the
proposed tool can link directly these changes to the support tool. Moreover, the
authors aim to apply the proposed approach in other case studies.

References

1. CAPELLA: https://polarsys.org/capella/ (2018), access in 05.15.2019
2. David, P., Idasiak, V., Kratz, F.: Reliability Study of Complex Physical Systems using SysML. Reliability Engineering & System Safety **95**, 431 – 450 (2010).
https://doi.org/2011.5979460

3. Gervasi, V., Nuseibeh, B.: Lightweight validation of natural language requirements. Softw., Pract. Exper. **32**, 113–133 (2002)

4. Jesus, T.O., Soares, M.S.: An event-based technique to trace requirements modeled with sysml. In: Computational Science and Its Applications - ICCSA. pp. 145–159 (2017). https://doi.org/10.1007/978-3-319-62407-5_10

5. Kaiya, H., Sato, R., Hazeyama, A., Ogata, S., Okubo, T., Tanaka, T., Yoshioka, N., Washizaki, H.: Preliminary systematic literature review of software and systems traceability. In: KES. Procedia Computer Science, vol. 112, pp. 1141–1150. Elsevier (2017)

6. Li, L., Ma, L., Wang, N., Yang, Q.: Modeling Method of Military Aircraft Support Process Based SysML. In: International Conference in Reliability, Maintainability and Safety (ICRMS). pp. 1247 – 1251. IEEE (2011). https://doi.org/2011.5979460

7. Lime, D., Roux, O.H., Seidner, C., Traonouez, L.: Romeo: A parametric model-checker for petri nets with stopwatches. In: Kowalewski, S., Philippou, A. (eds.) Tools and Algorithms for the Construction and Analysis of Systems. Springer Berlin Heidelberg, Berlin, Heidelberg (2009)

8. Liu, C.L., Layland, J.W.: Scheduling algorithms for multiprogramming in a hard-real-time environment. J. ACM **20**(1), 46–61 (Jan 1973).
https://doi.org/10.1145/321738.321743

9. Papyrus, T.: Papyrus: www.eclipse.org/papyrus/ (2018), access in 03.04.2019

10. Pohl, K., Hnninger, H., Achatz, R., Broy, M.: Model-based Engineering of Embedded Systems: The SPES 2020 Methodology. Springer Publishing Company, Incorporated, 1st edn. (2016)

11. Ribeiro, F.G.C., Pereira, C.E., Rettberg, A., Soares, M.S.I.p.: An Approach for Architectural Design of Automotive Systems using MARTE and SysML. In: CASE. pp. 1574–1580. IEEE (2018)

12. Ribeiro, F.G.C., Rettberg, A., Pereira, C.E., Botelho, S.C., Soares, M.S.: Guidelines for Using MARTE Profile Packages Considering Concerns of Real-Time Embedded Systems. In: 15th IEEE International Conference on Industrial Informatics, INDIN. pp. 917–922 (2017). https://doi.org/2017.8104894

13. Ribeiro, F.G.C., Rettberg, A., Pereira, C.E., Steinmetz, C., Soares, M.S.: SPES methodology and MARTE constraints in architectural design. In: ISCC. pp. 377–383. IEEE (2018)

14. Rioux, L., Henia, H., Sordon, N.: Using model-checking for timing verification in industrial system design. In: ICST Workshops. pp. 377–378. IEEE Computer Society (2017)

15. Santana, E.F.Z., Chaves, A.P., Gerosa, M.A., Kon, F., Milojicic, D.S.: Software platforms for smart cities: Concepts, requirements, challenges, and a unified reference architecture. ACM Comput. Surv. **50**(6) (2017)

16. Silva, B.N., Khan, M., Han, K.: Towards sustainable smart cities: A review of trends, architectures, components, and open challenges in smart cities. Sustainable Cities and Society **38**, 697–713 (2018)

17. Soares, M.S.: Architecture-driven Integration of Modeling Languages for the Design of Software-Intensive Systems. PhD thesis, Delft University of Technology, Delft, Holanda (2010)

18. Soares, M.S., Vrancken, J., Verbraeck, A.: User Requirements Modeling and Analysis of Software-Intensive Systems. The Journal of Systems and Software **84**(2), 328–339 (2011). https://doi.org/10.1016/j.jss.2010.10.020
19. Torkar, R., Gorschek, T., Feldt, R., Svahnberg, M., Akbar, R.U., Kamran, K.: Requirements traceability: A systematic review and industry case study. International Journal of Software Engineering and Knowledge Engineering **22** (05 2012). https://doi.org/10.1142/S021819401250009X

20. Umber, A., Bajwa, I.S.: Minimizing ambiguity in natural language software requirements specification. In: 2011 Sixth International Conference on Digital Information Management. pp. 102–107 (Sep 2011). https://doi.org/10.1109/ICDIM.2011.6093363

21. Uppaal, T.: Uppaal: http://www.uppaal.org/ (2018), access in 11.01.2019

22. Valles, B.F.: A formal model for the requirements diagrams of sysml. Latin America Transactions, IEEE (Revista IEEE America Latina) **8**, 259 – 268 (07 2010). https://doi.org/10.1109/TLA.2010.5538400

23. Winkler, S., Pilgrim, J.: A survey of traceability in requirements engineering and model-driven development. Softw. Syst. Model. **9**(4), 529–565 (2010). https://doi.org/10.1007/s10270-009-0145-0

24. Yan, X., Li, Y., Li, X.: Real-time simulation of automotive systems based on uppaal. In: 8th IEEE International Conference on Software Engineering and Service Science (ICSESS). pp. 173–176 (2017). https://doi.org/2017.8342890

25. Yang, C.H., Vyatkin, V., Pang, C.: Model-driven Development of Control Software for Distributed Automation: A Survey and an Approach. IEEE Transactions on Systems, Man, and Cybernetics: Systems **44**(3), 292–305 (2014)