Compositional modeling of globally asynchronous … · Compositional modeling of globally asynchronous ... globally asynchronous locally synchronous (GALS) architectures ... Case

HAL Id: tel-00675438https://tel.archives-ouvertes.fr/tel-00675438

Submitted on 1 Mar 2012

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

L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.

Compositional modeling of globally asynchronous locallysynchronous (GALS) architectures in a polychronous

model of compotationYue Ma

To cite this version:Yue Ma. Compositional modeling of globally asynchronous locally synchronous (GALS) architecturesin a polychronous model of compotation. Embedded Systems. Université Rennes 1, 2010. English.<tel-00675438>

https://tel.archives-ouvertes.fr/tel-00675438

https://hal.archives-ouvertes.fr

No d’ordre : 4245 ANNÉE 2010

THÈSE / UNIVERSITÉ DE RENNES 1sous le sceau de l’Université Européenne de Bretagne

pour le grade de

DOCTEUR DE L’UNIVERSITÉ DE RENNES 1Mention : Informatique

Ecole doctorale MATISSEprésentée par

Yue MApréparée à l’unité de recherche 6074 IRISA

Institut de Recherche en Informatique et Systèmes AlèatoiresIFSIC

Compositional

modeling of globally

asynchronous locally

synchronous (GALS)

architectures in a

polychronous model

of computation

Thèse soutenue à Rennesle 29 Novembre 2010devant le jury composé de :

Jean-Paul BODEVEIXProfesseur à l’Université Paul Sabatier /rapporteur

Frank SINGHOFFProfesseur à Université de Bretagne Occidentale /rapporteur

Christophe WOLINSKIProfesseur à l’Université de Rennes 1 /examinateur

Abdoulaye GAMATIÉChargé de recherche CNRS /examinateur

Thierry GAUTIERChargé de recherche INRIA /examinateur

Jean-Pierre TALPINDirecteur de recherche INRIA /directeur de thèse

2

Acknowledgements

First of all, I am grateful to all the members of my dissertation committee. I wish to thankProf. Christophe Wolinski for his acceptance to be the president of committee.

I would like to thank Jean-Paul Bodeveix, professor of Université Paul Sabatier, andFrank Singhoff, professor of Université de Bretagne Occidentale, for their acceptance tobe reporters for this thesis.

I would like also to thank Abdoulaye Gamatié, CNRS researcher, to judge this work.I wish to thank Thierry Gautier, INRIA researcher, to judge this thesis, and help me con-stanly writing my articles and progressing my French during my three years.

This thesis would not have been possible without the guidance of my thesis advisor,Jean-Pierre Talpin. His continuous supervision, encouragement, and of course construc-tive criticism have been great help and support in my research work.

I also need to thank all the members of INRIA ESPRESSO team for sharing the goodambiance during my stay at INRIA. In addition, I appreciate the review of this thesis byPaul Le Guernic. I also want to express my additional gratitude to Loïc Besnard for shar-ing accommodation with me, and Huafeng Yu for sharing experiences when we workedtogether for the demo.

Special thanks to my family, I could not accomplish my study in France without yoursupport and encouragement for these three years.

Acknowledgements

II

Contents

Introduction 1

I Résumé en français 11

1 Résumé en français 131.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.2 Introduction au langage AADL et aux architectures avioniques . . . . . . 15

1.2.1 Abstractions du langage AADL . . . . . . . . . . . . . . . . . . 151.2.2 Annexe comportementale de AADL . . . . . . . . . . . . . . . . 161.2.3 Architecture avionique et ARINC 653 . . . . . . . . . . . . . . . 16

1.3 Langage Signal et modélisation ARINC en Signal . . . . . . . . . . . . . 161.3.1 Le langage Signal . . . . . . . . . . . . . . . . . . . . . . . . . . 171.3.2 Modélisation de concepts ARINC en Signal . . . . . . . . . . . . 18

1.4 Travaux reliés : formalisations de AADL . . . . . . . . . . . . . . . . . . 191.5 Modélisation de composants AADL en processus Signal . . . . . . . . . 20

1.5.1 Chaîne de transformation . . . . . . . . . . . . . . . . . . . . . . 201.5.2 Principes de transformation . . . . . . . . . . . . . . . . . . . . 211.5.3 Du temps logique abstrait vers un temps de simulation concret . . 211.5.4 Modélisation de thread . . . . . . . . . . . . . . . . . . . . . . . 241.5.5 Modélisation des autres composants . . . . . . . . . . . . . . . . 27

1.6 Spécification de comportements AADL . . . . . . . . . . . . . . . . . . 281.6.1 Forme SSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291.6.2 Systèmes de transition AADL . . . . . . . . . . . . . . . . . . . 291.6.3 Interprétation des transitions / actions . . . . . . . . . . . . . . . 30

1.7 Génération de modèles de simulation distribués . . . . . . . . . . . . . . 341.7.1 Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341.7.2 Ordonnanceur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361.7.3 Ajout des communications . . . . . . . . . . . . . . . . . . . . . 36

1.8 Vérification et simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 371.8.1 Vérification formelle . . . . . . . . . . . . . . . . . . . . . . . . 371.8.2 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

1.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

CONTENTS

II Conceptions of AADL and Signal 41

2 Introduction to AADL and Avionic architectures 432.1 AADL language abstractions . . . . . . . . . . . . . . . . . . . . . . . . 44

2.1.1 The SAE AADL standard . . . . . . . . . . . . . . . . . . . . . 442.1.2 AADL meta-model and models . . . . . . . . . . . . . . . . . . 452.1.3 AADL open source tools . . . . . . . . . . . . . . . . . . . . . . 46

2.2 Summary of the core AADL components . . . . . . . . . . . . . . . . . 482.2.1 Software components . . . . . . . . . . . . . . . . . . . . . . . . 502.2.2 Execution platform components . . . . . . . . . . . . . . . . . . 552.2.3 System component . . . . . . . . . . . . . . . . . . . . . . . . . 58

2.3 System binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592.4 Component interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

2.4.1 Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602.4.2 Port connection . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

2.5 Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632.6 AADL behavior annex . . . . . . . . . . . . . . . . . . . . . . . . . . . 642.7 Avionics system architecture and ARINC653 . . . . . . . . . . . . . . . 65

2.7.1 Avionics system architecture overview . . . . . . . . . . . . . . . 652.7.2 ARINC standard . . . . . . . . . . . . . . . . . . . . . . . . . . 662.7.3 AADL and ARINC . . . . . . . . . . . . . . . . . . . . . . . . . 69

2.8 AADL components considered in this thesis . . . . . . . . . . . . . . . . 702.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

3 Signal Language and modeling ARINC in Signal 733.1 Signal language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

3.1.1 Signal, execution, process . . . . . . . . . . . . . . . . . . . . . 743.1.2 Data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753.1.3 Elementary processes . . . . . . . . . . . . . . . . . . . . . . . . 763.1.4 Process operators . . . . . . . . . . . . . . . . . . . . . . . . . . 773.1.5 Parallel semantic properties . . . . . . . . . . . . . . . . . . . . 783.1.6 Modularity features . . . . . . . . . . . . . . . . . . . . . . . . . 793.1.7 Endochronous acyclic processes . . . . . . . . . . . . . . . . . . 803.1.8 Time domains and communications in Signal . . . . . . . . . . . 803.1.9 Non-determinism modeling in Signal . . . . . . . . . . . . . . . 823.1.10 Adequacy of Signal for AADL modeling . . . . . . . . . . . . . 83

3.2 Modeling ARINC concepts in Signal . . . . . . . . . . . . . . . . . . . . 843.2.1 Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843.2.2 Partition-level OS . . . . . . . . . . . . . . . . . . . . . . . . . . 853.2.3 Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863.2.4 APEX services . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

IV

CONTENTS

III Prototyping AADL models in a polychronous model of com-putation 89

4 Formalizing AADL 914.1 AADL background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914.2 Related works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4.2.1 Modeling AADL in MARTE . . . . . . . . . . . . . . . . . . . . 934.2.2 Modeling AADL in SystemC . . . . . . . . . . . . . . . . . . . 944.2.3 Code generation from AADL to C . . . . . . . . . . . . . . . . . 944.2.4 Modeling AADL in Fiacre . . . . . . . . . . . . . . . . . . . . . 944.2.5 Modeling AADL in TASM . . . . . . . . . . . . . . . . . . . . . 964.2.6 Modeling AADL in ACSR . . . . . . . . . . . . . . . . . . . . . 984.2.7 Modeling ARINC653 systems using AADL . . . . . . . . . . . . 984.2.8 Modeling AADL in BIP . . . . . . . . . . . . . . . . . . . . . . 984.2.9 Modeling AADL in Lustre . . . . . . . . . . . . . . . . . . . . . 101

4.3 Summary and comparison . . . . . . . . . . . . . . . . . . . . . . . . . 1034.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

5 From AADL components to Signal processes 1055.1 Transformation chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075.2 Transformation principles . . . . . . . . . . . . . . . . . . . . . . . . . . 1075.3 From abstract logical time to more concrete simulation time . . . . . . . 110

5.3.1 Modeling computation latencies . . . . . . . . . . . . . . . . . . 1115.3.2 Modeling propagation delays . . . . . . . . . . . . . . . . . . . . 1125.3.3 Towards modeling time-based scheduling . . . . . . . . . . . . . 113

5.4 Thread modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145.4.1 Interpretation of a thread . . . . . . . . . . . . . . . . . . . . . . 1155.4.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

5.5 Processor modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1215.6 Bus modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1255.7 System modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1275.8 Other components modeling . . . . . . . . . . . . . . . . . . . . . . . . 130

5.8.1 Process modeling . . . . . . . . . . . . . . . . . . . . . . . . . . 1305.8.2 Subprogram modeling . . . . . . . . . . . . . . . . . . . . . . . 1325.8.3 Data modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . 1335.8.4 Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

5.9 Port and port connection modeling . . . . . . . . . . . . . . . . . . . . . 1355.9.1 Port modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1355.9.2 Port connection modeling . . . . . . . . . . . . . . . . . . . . . 136

5.10 Towards AADLv2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395.11 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

6 AADL behavior specification 1416.1 Static Single Assignment (SSA) . . . . . . . . . . . . . . . . . . . . . . 1426.2 AADL transition systems . . . . . . . . . . . . . . . . . . . . . . . . . . 143

6.2.1 States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1446.2.2 Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

V

CONTENTS

6.2.3 Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1466.3 Interpretation of transitions/actions . . . . . . . . . . . . . . . . . . . . . 148

6.3.1 Step 1: actions to basic actions . . . . . . . . . . . . . . . . . . . 1496.3.2 Step 2: basic actions to SSA form actions . . . . . . . . . . . . . 1556.3.3 Step 3: SSA to Signal . . . . . . . . . . . . . . . . . . . . . . . 1606.3.4 Global interpretation . . . . . . . . . . . . . . . . . . . . . . . . 162

6.4 Case study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1626.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

7 Distributed simulation model generation 1677.1 Distributed code generation in Polychrony . . . . . . . . . . . . . . . . . 167

7.1.1 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1697.1.2 Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1717.1.3 Adding communications . . . . . . . . . . . . . . . . . . . . . . 173

7.2 An example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1757.2.1 System description . . . . . . . . . . . . . . . . . . . . . . . . . 1777.2.2 Modeling and Distributing the example in Signal . . . . . . . . . 177

7.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

IV Validation 183

8 Validation of GALS systems 1858.1 Formal verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

8.1.1 Case study of a dual flight guidance system . . . . . . . . . . . . 1878.1.2 FGS Modeling in AADL . . . . . . . . . . . . . . . . . . . . . . 1888.1.3 Interpreting the model in Signal . . . . . . . . . . . . . . . . . . 1908.1.4 Checking safety properties with Sigali . . . . . . . . . . . . . . . 190

8.2 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1938.2.1 Case study of a door management system . . . . . . . . . . . . . 1938.2.2 System Modeling in AADL . . . . . . . . . . . . . . . . . . . . 1948.2.3 Interpreting the model in Signal . . . . . . . . . . . . . . . . . . 1968.2.4 Other models and system integration . . . . . . . . . . . . . . . . 1978.2.5 Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1998.2.6 VCD-based simulation . . . . . . . . . . . . . . . . . . . . . . . 200

8.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Conclusion 203

Bibliography 207

A SDSCS example 219A.1 AADL specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219A.2 Signal specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

VI

CONTENTS

B FGS example 229B.1 AADL specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229B.2 Signal specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

VII

CONTENTS

VIII

Introduction

This thesis aims at developing a methodology to model and verify globally asynchronouslocally synchronous (GALS) systems in an integrated modular avionics (IMA) designframework. This methodology consists of composing the synchronous models of indi-vidual processes according to the asynchronous model of an architecture. The resultingmodel can be simulated and verified using multi-clocked synchronous toolkits such as thePolychrony environment. Translations of heterogeneous models to polychronous modelshave been designed and implemented.

The modeling of real-time embedded systems

An embedded system [151, 48] is a computing system designed to perform dedicatedfunctions often with real-time computing constraints. It is embedded as part of a completedevice including electronic parts and mechanical parts. Nowadays, embedded systemscan be found everywhere in our daily life and are often used to perform safety criticalfunctions [105, 77] in domains such as avionics, automobile and telecommunications.

A real-time embedded system [150, 76] is one whose actions are subject to precisetiming deadlines. A real-time system responds to periodic and sporadic input events(from, e.g., sensors) by timely calculating and performing output actions (on, e.g., ac-tuators). Failing to respect deadlines may compromise correctness and have severe con-sequences [108]. One common example real-time software is that embedded within theABS of modern cars. While the car is braking, the ABS periodically monitors speed (ofthe car, of the wheel) and may sporadically command to release the brake in order to pre-vent the wheel to lock while the car is not stopped. In other words, a real-time embeddedsystem [96, 103, 150] is defined as a system whereby the correctness of the system de-pends not only on the logical result of computations, but also on the time at which theresult is produced [150].

Examples of real-time embedded systems are aircraft engine control systems, nuclearmonitoring systems and medical monitoring equipment, in which many embedded com-ponents (like the ABS) are operating and communicating in real-time. They are becomingmore and more complex. This increasing complexity presents new challenges for systemdesign: embedded systems can be constrained in time but also in size, power consumptionor cost.

Model-based engineering enables the designers to deal with these concerns using thearchitecture description of the system as the main axis during the design phase.

Some of the classical design methodologies for real-time embedded systems are:structured analysis and design methods [160], object-oriented analysis and design meth-

Introduction

ods (UML [30]) and formal system specification and design methods (SDL [32], Es-telle [156, 79]).

Defining the architecture of the system before its implementation enables the analysisof the constraints imposed on the system from the beginning of the design cycle until thefinal implementation. Formal languages have been developed to support such architecturaldescriptions. They are known as architectural description languages (ADLs [129, 128,131, 31, 4, 141]), modeling the system as a set of components and the interactions amongthem. One of the main ADLs currently used in avionics industry in system design forembedded systems is AADL (Architecture Analysis and Design Language) [1, 28, 41,80].

AADL is developed as a new methodology for embedded system design, which wasproposed around 2004. In AADL, the general purpose computing hardware, such as mem-ories, processors, buses, etc., can all be modeled by software, which provides more flexi-bility. This modeling aspect of system design activity is becoming increasingly essential,since it allows prototyping and experiments without necessarily having a physical imple-mentation of the system. This gives AADL a higher flexibility in design choices, lowercost, earlier decisions and fast to be adapted to new applications. Moreover, component-based approaches provide a way to significantly reduce overall development costs throughmodularity and re-usability. Thanks to this technology, a single AADL model can specifyand analyze real-time embedded and high dependability systems, and map software ontocomputational hardware elements.

The AADL can model locally synchronous systems as well as asynchronous systems.The synchronous pattern consists of periodic threads which are logically simultaneousat every global real time. While for a globally asynchronous system, there are multi-ple reference times, for example, the threads executed on different clock processors, theyrepresent different synchronization domains. This Globally Asynchronous Locally Syn-chronous (GALS) [71] model can be reflected in AADL by multiple synchronizationdomains and the asynchronous communications across synchronization domains.

From synchronous to GALS systems

The synchronous model

The synchronous assumption [50] was proposed in the late 80s for modeling, specifying,validating and implementing reactive and real-time system applications in an efficient andconvenient way.

A synchronous model [52, 51, 93] follows the basic assumptions: first, the compu-tations and internal communications are abstracted as instantaneous actions: they havea zero logical duration. Second, logical time is presented as a succession of events: itis handled according to a partial order over classes of simultaneous events; there is noexplicit reference to a notion of physical time.

The synchronous model has had major successes due to several advantages: syn-chronous languages have formal and clear semantic definition, synchronous parallel com-position reduces programming complexity and is useful for structuring programs, andmany verification methods have been developed on the synchronous framework.

2

Introduction

A synchronous system is viewed through the chronology and simultaneity of observedevents during its execution. This is a main difference from classical approaches where thesystem execution is rather considered under its chronometric aspect (i.e., duration hasa significant role). The mathematical foundations of the synchronous approach provideformal concepts that favor the trusted design of embedded real-time systems [88].

Typical synchronous languages are: Signal [115, 54, 90, 114], Lustre [92, 95] (data-flow synchronous languages), and Esterel [55, 162] (state based language). The threelanguages are built on a common mathematical framework that combines synchrony (i.e.,time advances in lockstep with one or more clocks) with concurrency (i.e., functionalconcurrency) [52]. These synchronous languages benefit from the simplicity of the syn-chronous assumption.

The asynchronous model

An asynchronous system [145, 46, 91] is one to which a request is sent out and does notneed to wait for a response. If a response is generated, notification from the system isreceived once it is complete. No global clock exists in the asynchronous paradigm.

An asynchronous system is represented by a program, which consists of a denumer-able number of tasks. Under the control of a particular device, e.g., real-time operatingsystem, these tasks run concurrently to achieve the system functions. The temporal logicof the system behavior is strongly influenced by the execution platform. The length of thelogical execution of the task is unknown, which induces non-determinism [83].

In contrast to the synchronous model, the asynchronous model has the following char-acteristics [51]:

1. Reactions (programs progress via an infinite sequence of reactions) can not be ob-served any more. Since no global clock exists, global synchronization barrierswhich indicate the transition from one reaction to the next one are no more ob-servable.

2. Composition occurs by means of interleaving flows shared between two processes.

This paradigm is much closer to distributed architectures than synchrony. It only re-quires communication channels to respect the condition that an ordered stream of sentdata reaches its destination in the same order. In the domain of distributed systems, asyn-chronous languages (e.g., SDL [32], Ada [5]) are naturally and variously used. An asyn-chronous model may be used simply for the interfacing of a synchronous system to itsenvironment and to other synchronous systems, or possibly for more complete applica-tions. Examples of asynchronous systems are distributed computer networks and I/Osystems for conventional computers.

The GALS model

The synchronous model turns out to be difficult to satisfy certain embedded systems’requirements, especially large distributed real-time systems. Providing a fully synchro-nized clock over multiple distributed nodes may make the model synchronization very

3

Introduction

expensive and actually infeasible. Thus, a combination of synchronous and asynchronousdesign patterns is required.

Recent approaches introduce a growing amount of asynchrony, a mix of synchronousand asynchronous design patterns. This situation has been known as GALS (GloballyAsynchronous Locally Synchronous [71, 134, 66]), which was proposed by Chapiro in1984 [71]. Gathering the benefits of both the synchronous and asynchronous approaches,the GALS model is emerging as an architecture of choice for implementing complexspecifications in both hardware and software. It is composed of several independent syn-chronous components which operate with their own local synchronous clocks, and con-nected through asynchronous communication schemes. In circuit design, it relates to themodeling of small synchronous blocks communicating asynchronously. In software de-sign, it relates to finite automata that communicate with registers.

The main feature of these systems is the absence of a global timing reference andthe use of several distinct local clocks, possibly running at different frequencies. Thus,unlike for a purely asynchronous design, the existing synchronous tools can be used formost of the development process, while the implementation can exploit the more efficientasynchronous communication schemes.

The idea of the GALS approach is to combine the advantages of synchronous andasynchronous design methodologies while avoiding their disadvantages: the clock distri-bution in a GALS circuit can be realized easier than in a synchronous circuit. A GALSmodel is easier to implement than a synchronous model, particularly when different com-ponents are distributed far away or that their computation speed is very high. Anotheradvantage of the GALS implementation, specifically in the case of embedded systems, isthe electric consumption. A distributed GALS system consumes less than its equivalentsynchronous system, because each component can adjust its operation speed by reportingits workload, even pause when not seeking. In a synchronous system, the componentscan operate at different but constant speeds. Moreover, at each cycle, each component isactive even if there is no data to be processed.

Existing problems and our solution

GALS designs have emerged in the recent years in response to the above mentionedchallenges and have received major attention from the system level design commu-nity [134, 66]. However, developing separately synchronous software components anddeploying them on the target architecture using classical design methods for asynchronoussystems, it is difficult to validate the integrated system. The problem of validating thewhole system is crucial: the execution of the software on the target architecture is gen-erally asynchronous, but this phase of the design is the most error-phone. The validationcan be performed by testing the implementation, however, this will result in later errordetection. Further more, testing an asynchronous implementation is difficult.

In this thesis, we propose a methodology of modeling and validating of globallyasynchronous composition of synchronous components in a multi-clock synchronous pro-gramming framework, Polychrony, especially in an IMA [39, 37] design architecture. Amain goal of such an approach is to study properties of globally asynchronous systemsusing existing simulation and model-checking toolkits for the synchronous framework.

4

Introduction

In order to support the virtual prototyping, simulation and formal validation of early,component-based, embedded architectures, we define a model of the AADL into the poly-chronous model of computation of the Signal programming language.

Our solution can be seen as a transformation of the design of asynchronously con-nected local synchronized components to a synchronous model. Since it may be non triv-ial to represent adequately asynchrony and non-determinism in a synchronous framework,we propose a method to use existing techniques and libraries of the Signal environment,consisting of a model of the APEX-ARINC-653 [37] real-time operating system services.It provides a suitable and adequate library to model embedded architectures in the specificcase of Integrated Modular Avionics (IMA). This framework is the one considered in theTopCased [29] project.

Related works

Synchronous modeling of asynchronous systems is also studied in [94]. The authorsdefine a generic semantic model for synchronous and asynchronous computation, afterthat, the attention is focused on implementing communication mechanisms.

There are also some tools to modeling non-synchronous systems using synchronouslanguages and developing system level design methodology:

- [124] relies on the MARTE [14] Time Model and the operational semantics ofits companion language CCSL [142], to equip UML activities with the executionsemantics of an AADL specification. It investigates how MARTE can be madeto represent AADL periodic/aperiodic tasks communicating through event or dataports, in an approach to end-to-end flow latency analysis.

- AADL2Fiacre [56] deals with the transformation of AADL models into Fiacre [56]models to perform formal verification and simulation.

- AADL2BIP [138] models AADL data communication with BIP (Behavior Inter-action Priority [7]). It focuses on deterministic data communication, and showshow BIP deals with the modeling of immediate and delayed data communicationssupporting undersampling and oversampling of AADL.

- [140] proposes a formal semantics for the AADL behavior annex using TimedAbstract State Machine (TASM [135]). A semantics of AADL execution model isgiven, and a prototype of behavior modeling and verification is proposed.

- AADL2SYNC [3] is an AADL to synchronous programs translator, which is ex-tended in the framework of the European project ASSERT, resulting in the system-level tool box translating AADL to LUSTRE.

Polychrony

Polychrony is a framework based on Signal, a domain-specific, synchronous data-flowlanguage dedicated to embedded and real-time system design [113]. While being declar-ative like Scade or Lustre, and not imperative like Esterel [72], its multi-clocked model

5

Introduction

of computation (MoC) stands out by providing the capability to design systems wherecomponents own partially related activation clocks. This polychronous MoC is calledpolychrony [115].

The main characteristic of Polychrony is that it can be used to describe systems thatcontain components, which work at different or even independent clocks. Instead of re-quiring the user to define a global clock, Polychrony calculates clock trees, that resultfrom the different clock dependencies expressed in the description.

Polychrony provides models and methods for a rapid, refinement-based, integrationand a formal conformance-checking of GALS architecture. It contains tools for propertiesverification, and integrates the Signal compiler, which is able to generate sequential codeor distributed code in some conditions, and it also includes a graphical user interface forSignal. It goes beyond the domain of purely synchronous circuits to embrace the contextof architectures consisting of synchronous circuits and desynchronization protocols.

In the Polychrony workbench, time is represented by partially ordered synchronizationand scheduling relations, to provide an additional ability to model high-level abstractionsof systems paced by multiple clocks: locally synchronous and globally asynchronoussystems. This gives the opportunity to seamlessly model heterogeneous and complexdistributed embedded systems at a high level of abstraction, while reasoning within asimple and formally defined mathematical model.

In Polychrony, design can proceed in a compositional and refinement-based mannerby first considering a weakly timed data-flow model of the system under consideration,and then providing expressive timing relation to gradually refine its synchronization andscheduling structure to finally check the correctness of the assembled components. Signalfavors the progressive design of correct by construction systems by means of well-definedmodel transformations, that preserve the intended semantics of early requirement specifi-cations to eventually provide a functionally correct deployment on the target architecture.

As mentioned earlier, the multi-clock polychronous model differs from other syn-chronous specification models by its capability to allow the design of systems, whereeach component holds its own activation clock as well as single-clocked systems in a uni-form way. A great advantage is its convenience for component-based design approachesthat allow modular development of increasingly complex modern systems.

Polychrony provides the ability to model and build GALS systems in a fully syn-chronous design framework, and deploy it on an asynchronous network preserving allproperties of the system proven in the synchronous framework. Thanks to the poly-chronous approach, bounded FIFOs [86] are provided for communications between syn-chronous components, allowing to find a desynchronizing protocol to formally investigatethe behavior of synchronous components in an asynchronous environment [133, 75].

Contribution

This thesis focuses on the modeling and validation of AADL systems in a multi-clock syn-chronous programming framework, Polychrony, especially in a IMA design architecture.The synchronous modeling and high-level validation, which are based on the synchronouslanguage Signal, are the main contributions of this thesis.

We define a translation based on the semantics of AADL into the polychronous model

6

Introduction

of computation of the Signal programming language. This solution can be seen as atransformation of the design of asynchronously connected local synchronized componentsto a synchronous model.

AADL Metamodel

Signal (SME)Metamodel

AADL Model SignalModel

Conforms to Conforms toModeltransformation

Codegeneration

architecture behavior

Applicationdescription

ModelingSignal code

Polychrony

VerificationSimulationEvaluation

Figure 1: A global view of the approach

A global view of the transformation is illustrated in Figure 1. It starts from usingthe AADL language to model real-time applications, which may be represented froman initial textual description. Then by giving the semantics of AADL components inthe polychronous model of computation, the AADL model is transformed into Signalmodel. Finally, Signal code is generated, and verification, simulation and other analysesare performed.

Since there are some difficulties in representing asynchrony and non-determinism in asynchronous framework, we propose to use existing techniques and libraries of the Signalenvironment [84, 85, 87], consisting of a model of the APEX-ARINC-653 [37] real-timeoperating system services. Consequently, the components can be translated into or pro-jected onto different APEX-ARINC services.

AADL has been extended to describe complex behaviors without introducing exter-nal source code, by the Behavior Annex. To implement a complete system specification,we also translate the behaviors into synchronous equations. We formalize the semanticsof the actions and transitions, and interpret them using SSA as an intermediate formal-ism [61, 154]. In this interpretation, we show not only how to translate the core imperativeprogramming features into Signal equations, but also extend it to the mode automata thatcontrol the activation of such elementary transitions and actions.

Signal-Meta Under Eclipse (SME) [24] is the model-driven front-end of Polychronyframework. It provides the meta-model on which Signal model is based. The resultingSignal model generated from this transformation conforms to the SME meta-model. High-level validation is then carried out with the generated Signal code in order to check thecorrectness of the corresponding AADL specifications.

The implementation of the transformation has been carried out in the framework ofOpenEmbeDD [17], which is an Eclipsed-based “Model Driven Engineering” platformdedicated to embedded and real-time systems.

7

Introduction

All the preceding studies have been experimented with the Polychrony toolset. Acase study of door management system is finally illustrated, with emphasis on the high-level modeling through AADL, and the simulation and formal validation through the toolsassociated with the Signal language.

Outline

In the present document, we propose a methodology to model and verify a GALS systemin a polychronous framework. This method transforms the AADL model using the IMAarchitecture to Signal model. This dissertation has four parts:

Part I

Part I gives an extended abstract in French.

Chapter 1. The first chapter presents an extended abstract of this thesis in French. Eachsection presents an abstract of the corresponding chapter.

Part II

Part II presents the background. It has two chapters.

Chapter 2. This chapter introduces the AADL language. AADL is an SAE standardaimed at high level design and evaluation of the architecture of embedded systems. Weintroduce the components and behaviors of AADL. The IMA architecture and the ARINCstandard, especially the ARINC653 specification which defines an APplication EXecutive(APEX) for space and time partitioning, are presented in this chapter.

Chapter 3. Chapter 3 is related to the Signal language. It first introduces the model ofSignal. It starts with an introduction of polychronous model of computation, and thencontinues with a specification of the syntax and semantics of the Signal language. Themodeling library of IMA ARINC applications in Signal is also presented.

Part III

Part III exhibits our contributions for modeling, prototyping and implementation, whichincludes four chapters.

Chapter 4. Chapter 4 reviews related works. It proposes an overview of existing AADLmodels and transformations. A brief comparison of these works is given in this chapter.

8

Introduction

Chapter 5. Chapter 5 describes the modeling of AADL specifications into the poly-chronous model using APEX-ARINC services in the IMA framework. The general mod-eling approach and transformaton principles are first presented. Then the problems inAADL to Signal transformation are depicted, and solutions are given. The transformationof a subset of AADL components is described, including the main executable and schedu-lable component, the thread, the component responsible for scheduling, the processor, andcommunication components, bus, etc. Apart from the component modeling, two types ofdata port communication are also represented in Signal.

Chapter 6. In Chapter 6, we present the transformation of AADL behavior specifica-tion, mainly for the transitions and actions. This interpretation uses SSA as an inter-mediate formalism. It gives a thorough description of an inductive SSA transformationalgorithm across transitions and actions that produces synchronous equations.

Chapter 7. Chapter 7 focuses on the distribution. The principles that generate dis-tributed Signal from the AADL specification are presented. Then the scheduler and com-munication between the distributed programs are described. A case study is given toexplain the distribution.

Part IV

Part IV contains one chapter about verification and simulation.

Chapter 8. Chapter 8 presents the verification and simulation of GALS systems in thecase of our considered approach from AADL. We present the static resolution and dy-namic model-checking techniques that come with the Polychrony environment to verifythe functional requirements of the system. A case study of dual flight guidance system ispresented, which gives formal verification. Then another case study of door managementsystem is given, which illustrates the implementation of the proposed transformation ofAADL and the simulation.

Conclusion. We conclude the thesis and discuss some perspectives of these works.

9

Introduction

10

Part I

Résumé en français

Chapter 1

Résumé en français

1.1 Introduction

Les systèmes embarqués se rencontrent aujourd’hui partout, y compris dans la vie quo-tidienne, et sont souvent utilisés pour effectuer des tâches critiques [105, 77] dans desdomaines tels que l’avionique, l’automobile et les télécommunications. Un système em-barqué temps réel [150, 76] est un système dont les actions sont assujetties à des délaistemporels. Un système temps réel répond à des événements d’entrée périodiques ou spo-radiques (par exemple, à partir de capteurs) par le calcul et l’exécution d’actions perme-ttant de produire des sorties (par exemple, sur des actionneurs). Un défaut de respectdes délais peut compromettre l’exactitude des résultats et avoir des conséquences graves(temps réel strict) [108].

Le langage AADL (Architecture Analysis and Design Language) est proposé commesupport à une nouvelle méthodologie pour la conception de systmes embarqués. EnAADL, la partie matérielle, tel que mémoires, processeurs, bus, etc, peut être modéliséesous forme logicielle, ce qui offre une plus grande souplesse car cela permet des prototy-pages et expérimentations sans nécessairement disposer d’une implantation physique dusystème. En outre, les approches à base de composants, comme c’est le cas en AADL,fournissent un moyen de réduire considérablement les coûts de développement via la mod-ularité et la réutilisation de composants.

Le modèle synchrone a obtenu des succès majeurs dans les systèmes temps réel enraison d’un certain nombre d’avantages : les langages synchrones sont basés sur unedéfinition sémantique précise et claire ; la composition parallèle synchrone réduit la com-plexité de programmation et est utile pour structurer les programmes ; et de nombreusesméthodes de vérification ont été développées dans le cadre synchrone.

Les approches les plus récentes tendent à introduire dans les modèles un nombrecroissant d’éléments asynchrones, tout en essayant de préserver les bonnes propriétés desmodèles synchrones. On obtient ainsi un mélange de modèles de conception synchroneset asynchrones, comme par exemple le modèle GALS (Globalement Asynchrone Locale-ment Synchrone [71, 134, 66]). Rassemblant les avantages des deux approches, synchroneet asynchrone, le modèle GALS est en train de devenir une architecture de choix pour lamise en œuvre de spécifications complexes à la fois matérielles et logicielles.

Les approches GALS sont l’objet d’une attention particulière de la part de la com-munauté des concepteurs au niveau système [134, 66]. Le problème de la validation de

CHAPTER 1. RÉSUMÉ EN FRANÇAIS

l’ensemble du système est essentiel : l’exécution du logiciel sur l’architecture cible estgénéralement asynchrone, mais cette phase de la conception est la plus sujette aux er-reurs. La validation peut être effectuée au moyen de tests de la mise en œuvre, cependant,cela implique une détection tardive des erreurs. De plus, tester une implémentation asyn-chrone pose des problèmes de non déterminisme.

Dans cette thèse, nous proposons une méthodologie de modélisation et de validationde la composition globalement asynchrone de composants synchrones. Nous nous plaçonsdans le cadre de la programmation synchrone multi-horloge, ou polychrone, en consid-érant plus particulièrement les architectures de type IMA [39, 37]. Un des principauxobjectifs de l’approche est d’étudier les propriétés des systèmes globalement asynchronesen utilisant des outils de simulation et de vérification de modèle (model-checking) exis-tant dans le cadre synchrone. Pour permettre le prototypage virtuel, la simulation et lavalidation formelle au plus tôt des architectures embarquées à base de composants, nousdéfinissons une modélisation de AADL dans le modèle de calcul polychrone du langagede programmation Signal.

Notre solution peut être considérée comme une transformation d’une conception encomposants localement synchronisés connectés de façon asynchrone, vers un modèle syn-chrone. Une vision globale de la transformation est illustrée sur la figure 1.1. On utiliseen premier lieu le langage AADL pour modéliser une application temps réel, qui peutêtre représentée à partir d’une description textuelle initiale. Étant donné la sémantiquedes composants AADL dans le modèle de calcul polychrone, le modèle AADL est alorstransformé en modèle Signal. À partir de ce modèle, un programme Signal est généré,et l’outil Polychrony peut être utilisé pour effectuer de la vérification, des simulations etd’autres analyses.

AADL Metamodel

Signal (SME)Metamodel

AADL Model SignalModel

Conforms to Conforms toModeltransformation

Codegeneration

architecture behavior

Applicationdescription

ModelingSignal code

Polychrony

VerificationSimulationEvaluation

Figure 1.1: Vision globale de l’approche.

Sachant qu’il peut être non trivial de représenter de façon adéquate l’asynchrone et lenon déterminisme dans un cadre synchrone, nous proposons une méthode qui utilise destechniques et des bibliothèques existant dans l’environnement de Signal, consistant no-tamment en un modèle des services du système d’exploitation temps réel APEX-ARINC-653 [37]. Nous disposons ainsi d’une bibliothèque permettant de modéliser des architec-tures embarquées dans le cadre IMA.

14

1.2. INTRODUCTION AU LANGAGE AADL ET AUX ARCHITECTURESAVIONIQUES

1.2 Introduction au langage AADL et aux architecturesavioniques

1.2.1 Abstractions du langage AADL

Le langage AADL est une norme de la SAE, qui a été défini pour les systèmes embarquéscritiques temps réel. Il doit rendre possible l’utilisation d’approches formelles diversespour l’analyse de systèmes constitués de composants matériels et logiciels.

Catégories de composants Pour modéliser les systèmes embarqués complexes, AADLfournit trois catégories de composants : composants logiciels, composants de plate-formed’exécution et composants “composites”.

• Les données, les sous-programmes, les “threads”1 et les processus représentent col-lectivement le logiciel d’une application ; ils sont appelés composants logiciels.

• Les composants de la plate-forme d’exécution comprennent les processeurs, lesdispositifs (device), les mémoires et les bus. Ils supportent l’exécution des threads,le stockage des données et du code, et la communication entre les threads.

• Les systèmes sont appelés composants composites. Ils permettent d’organiser enstructures hiérarchiques avec des interfaces bien définies les composants logicielset les composants de la plate-forme d’exécution.

Types et implémentations de composants Les composants AADL sont définis par desdéclarations de type et d’implémentations. Un type de composant représente l’interfacefonctionnelle du composant et ses attributs observables de l’extérieur. Une implémen-tation décrit le contenu du composant, spécifie sa structure interne en termes de sous-composants, les connexions entre les éléments de ces sous-composants, les flots sur uneséquence de sous-composants, les modes permettant de représenter les états de fonction-nement, et les propriétés.

Propriétés Une propriété spécifie des caractéristiques du composant qui s’appliquent àtoutes les instances de ce composant, sauf si elles sont redéfinies dans des implémentationsou des extensions. Des valeurs peuvent être attribuées aux propriétés par des déclarationsd’association de propriété.

Domaine temporel Trois horloges (td, ts, t f ) sont associées à chaque thread t. L’horlogetd est l’horloge à laquelle le thread est “dispatché”. Si le port prédéfini dispatch estconnecté, l’arrivée d’un événement sur ce port entraîne le dispatch du thread. L’horlogets est l’horloge à laquelle le thread démarre, et t f est l’horloge à laquelle le thread setermine. Ces deux horloges peuvent être spécifiées respectivement par les propriétésInput_Time et Output_Time. De nombreuses autres caractéristiques temporelles, parexemple l’échéance, le temps d’exécution, le temps de transmission, etc., peuvent êtrespécifiées par les propriétés définies dans AS5506 [41].

1Nous gardons ici le terme anglais plutôt que “fil d’exécution” ou “tâche”.

15


1.2.2 Annexe comportementale de AADL

L’annexe comportementale (Behavior Annex) de AADL [74] est une extension au noyaudu standard qui fournit un moyen de spécifier le comportement fonctionnel local des com-posants. Elle permet une description précise des comportements, tels que les calculs, lescommunications au moyen des ports, etc. Une annexe comportementale peut être attachéeà un thread ou à un sous-programme. Les threads et les sous-programmes démarrent à par-tir d’un état initial, et une transition vers un état final (resp., un état de retour) termine lethread (resp. le sous-programme). Les transitions peuvent être gardées par des conditions,et des actions peuvent y être attachées.

1.2.3 Architecture avionique et ARINC 653

Architecture IMA Une caractéristique forte des architectures IMA [39] est le fait queplusieurs applications avioniques peuvent être hébergées sur un seul système, partagé. Cesapplications sont assurées d’une allocation statique sécurisée des ressources partagées,de sorte qu’aucune propagation de faute ne se produise d’un composant à un autre. Ceproblème est adressé au moyen d’un partitionnement fonctionnel des applications selonla disponibilité des ressources en temps et en mémoire [37].

Une partition est composée de processus qui représentent les unités d’exécution.Chaque processus est caractérisé par des informations utiles à l’OS de niveau partition,responsable de l’exécution correcte des processus dans une partition. Des mécanismesappropriés sont prévus pour la communication et la synchronisation entre processus (parexemple, buffers, événements, sémaphores) et entre partitions (par exemple, ports etcanaux).

La norme avionique ARINC définit les principes de base du partitionnement, ainsiqu’un ensemble de services, conformes à l’architecture IMA. L’interface APEX, définiedans la norme ARINC, comprend les services de communication et de synchronisation,et les services de gestion des processus et des partitions.

AADL et ARINC AADL peut être utilisé en particulier pour une modélisation con-forme à ARINC. AADL et ARINC ont certaines caractéristiques similaires. La parti-

tion ARINC est proche du processus AADL. Le processus AADL représente un espaced’adressage protégé, un espace de partitionnement où une protection est assurée contreles accès d’autres composants à l’intérieur du processus. Ainsi, la partition ARINC etle processus AADL sont des unités du partitionnement. Les mécanismes de communica-tion définis dans ARINC supportent les communications de messages en file et sans file.Cela est similaire aux connexions AADL. Une différence est que ARINC ne prend pas encompte, à ce niveau, la connexion matérielle par bus entre les différents composants.

1.3 Langage Signal et modélisation ARINC en Signal

L’approche synchrone est l’une des solutions possibles pour une conception sûre des sys-tèmes embarqués. Le modèle multi-horloge ou polychrone se distingue des autres mod-èles synchrones par son cadre uniforme. Il permet aussi bien la conception de systèmes

16

1.3. LANGAGE SIGNAL ET MODÉLISATION ARINC EN SIGNAL

dans lesquels chaque composant dispose de sa propre horloge d’activation, que de sys-tèmes mono-horloge. Cette caractéristique rend la sémantique de Signal plus proche de lasémantique de AADL que ne l’est celle d’autres modèles purement synchrones ou asyn-chrones. Cela facilitera ainsi la validation du système.

1.3.1 Le langage Signal

Le langage flot de données synchrone Signal est dédié à la conception de systèmes embar-qués dans des domaines d’applications critiques. Les caractéristiques propres au modèlerelationnel qui sous-tend Signal sont d’une part de fournir la notion de polychronie —c’est-à-dire la capacité à décrire les circuits et les systèmes avec plusieurs horloges — etd’autre part de permettre le raffinement — autrement dit, la capacité à permettre la con-ception de système depuis les étapes initiales de spécification des exigences, jusqu’auxétapes finales de synthèse et de déploiement.

Signal est un langage relationnel qui s’appuie sur le modèle polychrone [58]. Signalmanipule des suites non bornées de valeurs typées (xt)t∈N, appelées signaux, notées x etindexées implicitement par les valeurs discrètes de leur horloge, notée x. À un instantdonné, un signal peut être présent ou absent. Deux signaux sont dits synchrones s’ils sonttoujours présents (ou absents) aux mêmes instants.

En Signal, un processus (dénoté P ou Q ) consiste en la composition synchrone (notéeP ||Q) d’équations sur signaux (notées x := y f z). Une équation x := y f z définit le signalde sortie x par la relation sur ses signaux d’entrée y et z auxquels est appliqué l’opérateurf . Le processus P/x restreint la portée du signal x au processus P. La syntaxe abstraited’un processus P en Signal est définie comme suit :

P,Q ::= x := y f z | P ||Q | P/x

Domaines temporels et communications en Signal Nous discutons ici certains écartset similitudes sémantiques entre AADL et Signal. Signal peut fournir un outillage à based’opérateurs dérivés permettant de réduire les écarts.

• Outillage d’horloges. Les horloges peuvent être étroitement liées aux domainestemporels AADL et des opérateurs sont définis en Signal pour manipuler les hor-loges.

• Horloges périodiques en Signal. Des horloges périodiques peuvent être spécifiéesen Signal à l’aide de relations affines sur les horloges. Dans Polychrony, le cal-cul d’horloges de Signal implémente des règles de synchronisabilité basées sur lespropriétés des relations affines, et vis-à-vis desquelles les contraintes de synchroni-sation peuvent être examinées.

• Communications. Le principe de base de la communication en Signal est la dif-fusion, ce qui signifie qu’un signal donné est transmis comme plusieurs signauxidentiques. Il est également possible en Signal d’avoir plusieurs signaux ou expres-sions associés à un signal donné, au moyen de définitions partielles.

• Outillage pour le report des communications. Le report des communicationspeut être implémenté en Signal à l’aide de cellules mémoire et de FIFO.

17


• Outillage pour briser l’atomicité. Pour un programme Signal, l’horloge la plusrapide d’un processus n’est pas toujours une horloge d’entrée : des instants nou-veaux peuvent être insérés entre les instants existants. Le sur-échantillonnage per-met la spécification de contraintes entre les entrées et les sorties de telle sorte qu’ilne puisse pas se produire de valeur d’entrée supplémentaire tant que les contraintesen question ne sont pas respectées par les calculs (intermédiaires) de la sortie [115].

1.3.2 Modélisation de concepts ARINC en Signal

Les applications avioniques qui s’appuient sur la norme avionique ARINC 653, baséesur l’architecture IMA, peuvent être spécifiées dans le modèle de Signal. Une biblio-thèque de services APEX ARINC est fournie en Signal. L’environnement de conceptionPolychrony comprend ainsi une bibliothèque Signal de composants correspondant auxservices d’exécutif temps réel définis dans ARINC [37]. Cette bibliothèque, conçue parAbdoulaye Gamatié [83], s’appuie sur quelques blocs de base [84, 85], qui permettentde modéliser les partitions : il s’agit des services APEX-ARINC-653, d’un modèle deRTOS, et d’entités d’exécution.

Services de l’APEX Les services de l’APEX modélisés en Signal comprennent les ser-vices de communication et de synchronisation utilisés par les processus (par exemple,SEND_BUFFER, WAIT_EVENT, READ_BLOCKBOARD), les services de gestion desprocessus (par exemple, START, RESUME), les services de gestion des partitions (parexemple, SET_PARTITION_MODE), et des services de gestion du temps (par exemple,PERIODIC_WAIT).

OS de niveau partition Le rôle de l’OS de niveau partition est d’assurer l’exécutioncorrecte des processus dans une partition. Chaque fois que la partition s’exécute, l’OS de

niveau partition sélectionne un processus actif dans la partition.

Processus ARINC La définition d’un modèle de processus ARINC en Signal prend encompte d’une part sa partie calcul et d’autre part sa partie contrôle. Le sous-composantCONTROL spécifie la partie contrôle du processus. Il s’agit d’un système de transitionqui indique quelles instructions doivent être exécutées lorsque le modèle du processus estactif. Le sous-composant COMPUTE décrit les actions effectuées par le processus. Ilest composé de blocs d’actions. Ces blocs représentent des pièces élémentaires de code àexécuter sans interruption. Les calculs associés à un bloc sont supposés se terminer dans

un laps de temps borné.

Partitions Après la phase d’initialisation, la partition est activée (par exemple, lors dela réception d’un signal Active_partition_ID). L’OS de niveau partition sélectionne unprocessus actif dans la partition. Ensuite, la sous-partie CONTROL de chaque processus

vérifie si le processus concerné peut s’exécuter. L’exécution du modèle de la partition

suit ce schéma de base jusqu’à ce que l’OS de niveau module sélectionne une nouvellepartition à exécuter.

18

1.4. TRAVAUX RELIÉS : FORMALISATIONS DE AADL

1.4 Travaux reliés : formalisations de AADL

Le langage AADL fournit un bon support pour la description et l’analyse de systèmesembarqués complexes. Afin de valider des propriétés formelles sur un modèle AADL,d’effectuer des analyses d’ordonnançabilité ou de performance, d’effectuer de la vérifica-tion, un cadre formel qui puisse fournir des diagnostics sur le système doit être défini etutilisé. Un tel objectif ne peut être atteint que si l’on peut transformer le modèle AADLdans un autre modèle, dont les outils associés offrent ces fonctionnalités. Nous donnonsici un bref apercu de quelques transformations de AADL.

• L’utilisation de MARTE pour modéliser AADL a concerné principalement les deuxprotocoles de communication, immédiat et retardé, dans l’optique d’une analyse dela latence sur les flots “end-to-end”. Ce travail s’efforce de construire un simulateurgénérique pour AADL, mais l’objectif d’un langage analysable formellement resteune perspective [119].

• La modélisation de AADL en Fiacre se concentre sur un objectif de vérification demodèle [56]. Par rapport à BIP, Fiacre a des constructions moins puissantes mais ila de bonnes propriétés au niveau de la compositionnalité et du temps réel.

• La traduction de AADL vers BIP permet la simulation de modèles AADL, ainsique l’application de techniques de vérification. L’absence de localité dans BIP renddifficile le raisonnement compositionnel [138].

• La modélisation de AADL en TASM permet de présenter la sémantique temporellede l’annexe comportementale de AADL en utilisant TASM. TASM dispose de mé-canismes de consommation de ressources plus abstraits, mais prend difficilement encompte certains modèles d’ordonnancement [140].

• La traduction référencée de AADL vers SystemC vise la simulation et l’analyse deperformances. Cependant, les spécifications de comportement n’ont pas été prisesen considération [157].

• L’objet de la génération de code C depuis AADL développée dans Ocarina est decibler des applications distribuées à haute intégrité. Avec l’outil PolyORB-HI-C,des blocs Simulink peuvent être utilisés comme sous-programmes AADL [?]. Unetransformation de blocs Simulink (utilisés en tant que threads AADL) en Signal estégalement implémentée dans notre travail coopératif effectué dans le cadre du projetCESAR [35]. Nous utilisons AADL pour modéliser l’architecture et Simulink pourmodéliser les parties fonctionnelles.

• L’objectif de la modélisation de ARINC653 à l’aide de AADL est de proposer unprocessus approprié de développement de type MDE permettant de saisir et de pren-dre en compte les exigences architecturales en utilisant AADL et son annexe AR-INC653 [73]. Cette approche modélise des architectures ARINC653 en AADL,alors que notre travail consiste en une démarche inverse : nous modélisons un sys-tème AADL en Signal dans un cadre ARINC653.

19


• L’objectif principal de AADL2SYNC est d’effectuer une simulation et une vali-dation qui prennent en compte à la fois l’architecture du système et les aspectsfonctionnels. Ce travail construit un simulateur exprimé dans un langage purementsynchrone : Lustre. Un protocole de communication quasi-synchrone est utilisépour émuler l’asynchronisme et remédier ainsi aux limitations dues au caractèrepurement synchrone ; néanmoins sa capacité d’expression reste limitée [3, 99].

Par rapport à ces travaux, notre approche a des objectifs multiples. Nous modélisonsun système AADL en Signal afin d’effectuer de la vérification formelle (en utilisant Si-gali), de la simulation (en utilisant VCD), et de la génération de code C/Java, puisque lemodèle polychrone du langage Signal offre en effet un support formel pour l’analyse, lavérification, la simulation et la génération de code, mises en œuvre dans la plate-formePolychrony. En outre, le modèle polychrone fournit des modèles et des méthodes pourl’intégration rapide, basée sur le raffinement, et la vérification formelle de conformité desarchitectures GALS [152].

1.5 Modélisation de composants AADL en processus Sig-nal

Cette section se concentre sur la modélisation synchrone des composants AADL dansune architecture IMA, de sorte qu’un modèle AADL puisse être traduit en un modèleexécutable du langage flot de données polychrone Signal. Cette modélisation est unecontribution qui doit aider à combler le fossé existant entre modèles asynchrones et syn-chrones.

1.5.1 Chaîne de transformation

Notre transformation de modèles AADL en spécifications synchrones est séparée en deuxétapes : d’une part, la transformation elle-même, des modèles AADL vers des modèlessynchrones, puis la génération de code synchrone à partir des modèles synchrones obtenusà la première étape.

Nous formalisons la transformation de AADL en isolant les catégories syntaxiquesde base qui caractérisent ses capacités expressives : systèmes, processus, threads, sous-programmes, données, dispositifs, processeurs, bus et connexions.

GRAPHICAL AADL Ecore model

SME Signal

Eclipse OPENEMBEDDOSATE/ADELE

AADL model

Code generation

model transformation


codeSignal/Polychrony model

Csyntax/ semantics

transformation

code

AADL modeling Polychrony frameworkTEXTUAL

AADL codemodel

transformationOSATE

Ecore model

transformation

Code generation

Figure 1.2: Vue globale de la chaîne de transformation AADL-SME/Signal.

20

1.5. MODÉLISATION DE COMPOSANTS AADL EN PROCESSUS SIGNAL

La figure 1.2 illustre la chaîne de transformation semi-automatique d’un modèleAADL vers un modèle Signal, jusqu’à la génération de code exécutable, en C ou Javapar exemple. Dans la transformation, les modèles SME [24], qui sont conformes au méta-modèle de Signal, sont considérés comme des modèles intermédiaires.

Le modèle ecore de AADL est traduit en un modèle SME/Signal en utilisant ATL(Atlas Transformation Language), dans lequel sont définies les règles de transformation.Le modèle SME peut ensuite être transformé en programme Signal. Le programme Signalest alors compilé et un code exécutable C (ou Java/C++) peut être généré.

1.5.2 Principes de transformation

Cette transformation de modèle est basée sur l’étude des similarités entre AADL et lesservices APEX-ARINC. La transformation d’un modèle AADL vers Signal repose surl’architecture IMA [121]. Les principes de base de la transformation de base sont présen-tés dans la table 5.1.

AADL Signalthread processus ARINC

processus partition ARINCport FIFO bornée

connexion de ports de données processus Signal (selon le type de la connexion)processeur OS de niveau partition en ARINC

type de données type de données Signalsystème processus Signal constitué de sous-processus

bus processus de communication Signaldispositif processus Signal

Table 1.1: Principes de base de la transformation.

Un exemple permet de donner une première idée de la transformation. Le système SD-SCS (dont la description détaillée se trouve dans l’annexe A), représenté sur la figure 1.3,a un processus doors_process qui traite les messages provenant des dispositifs Door1,Door2, LGS, DPS et OCU. Le processus doors_process se compose de trois threads :door_handler1, door_handler2 et doors_mix, qui calculent et génèrent les sorties.

Le modèle Signal correspondant (dans l’architecture ARINC) est montré (partielle-ment) sur la figure 1.4. Le processus doors_process est traduit en une partition ARINC,partition_doors_process. Les trois processus qui la composent, process_door_handler1,process_door_handler2 et process_doors_mix, correspondent aux trois threads de la fig-ure 1.3. L’ordonnanceur est modélisé par l’OS de niveau partition (partition_level_OS).Les dispositifs sont implémentés comme des processus Signal extérieurs à la partition, àlaquelle ils fournissent leur interface externe.

1.5.3 Du temps logique abstrait vers un temps de simulation concret

Le paradigme synchrone fournit une représentation idéalisée du parallélisme. Tandis queAADL prend en compte les durées de calcul et les délais de communication, permettant

21


Figure 1.3: Les threads du processus doors_process.

systempartition_doors_processDoor1

Door2

SPS1SPT1

process_door_handler1

SPS2SPT2


SPS3SPT3

process_doors_mix

scheduler(partition_level_OS)

LGSDPS

OCU

Figure 1.4: Modèle Signal du système SDSCS simplifié.

22


ainsi de produire des données d’un même instant logique à des instants différents dansla mise en œuvre. Ces instants sont définis précisément dans les propriétés des ports etdes threads. Pour résoudre ce problème, nous conservons la vision idéale de calculs etcommunications instantanés, et déportons le calcul des latences et des délais de commu-nication vers des processus spécifiques de “mémorisation”, qui introduisent les retardset synchronisations requis. En conséquence, certaines propriétés entraînent la définitionde signaux de synchronisation explicites. L’utilisation du cadre polychrone, adapté à lamodélisation d’un temps logique abstrait, doit faire face aux problèmes décrits ci-après.

Modélisation des latences de calcul. Une caractéristique principale des programmespolychrones est l’exécution logique instantanée, par rapport au temps logique. Les com-posants dans le modèle polychrone ne consomment pas de temps logique : les sorties sontgénérées immédiatement lorsque les entrées sont reçues. Alors qu’en AADL, un threadpeut exécuter une fonction ou un calcul pendant un intervalle de temps spécifié, définipar les propriétés temporelles. Par conséquent, la modélisation de AADL dans le cadrepolychrone nécessite une forme d’adaptateur pour interfacer le temps logique abstrait etle temps de simulation concret.

io'Start_Thread

Output_Time

P at

P_o P_o = defer_Output (P) process P_o = (? i; event Start_Thread,Output_Time; ! o'; ) (| o := P(i,Start_Thread) | o' := at(o,Output_Time) |) where o; end;

o

Figure 1.5: Modélisation d’une tâche consommant du temps.

À chaque sortie o d’un processus P, nous associons un processus P_o dont la sortieest la valeur de o retardée jusqu’à ce que son Output_Time représenté par le signal événe-ment d’entrée Output_Time se produise (figure 1.5). En raison de l’ordonnancement, unprocessus qui est logiquement synchrone d’un signal “dispatch” peut être effectivementdémarré plus tard. Ainsi, à chaque processus P, nous associons un signal événementd’entrée “Start_Thread” et l’exécution de P est synchronisée avec Start_Thread.

Modélisation des délais de propagation. Lors de l’exécution de programmes syn-chrones, chaque événement ou signal significatif est précisément daté par rapport auxautres signaux, et par rapport à la séquence des pas de calcul. Alors que pour un modèleAADL, l’instant de disponibilité des entrées peut être déterminé par différentes valeurs depropriétés.

Le langage Signal fournit des moyens d’exprimer l’activation : ce sont les horlogesdes signaux. L’idée principale pour modéliser le temps non précisément connu de AADLdans un cadre synchrone est d’utiliser des entrées supplémentaires, appelées conditionsd’activation, pour modéliser les délais de propagation.

Une condition d’activation (pour l’instant de démarrage) peut être utilisée pour ex-primer l’activation d’un thread, qu’il soit périodique ou apériodique. La modélisation

23


Pi oStart_Thread P_i

at

P_i = retime_Input(P) process P_i = (? i; event e; ! o;) (| i' := at(i,e) | o := P(i') |) where i'; end;

i'

Figure 1.6: Condition d’activation.

représentée sur la figure 1.6 considère un programme synchrone P (qui est la transforma-tion d’un thread), une entrée d’activation Start_Thread, et définit un nouveau programmeP_i dont l’activation est conditionnée.

Vers la modélisation d’ordonnancement basé sur le temps. Un autre problème sepose à partir des mécanismes d’activation et de retard tels que décrits dans les paragraphesprécédents : comment contrôler ces conditions d’activation et de retard, et d’où doivent-elles être générées ?

Pour réoudre ce problème, nous supposons qu’est associé à chaque thread P unenvironnement temporel S PS , qui calcule les horloges de démarrage et de terminai-son du thread, ainsi que d’autres signaux de contrôle, lorsque le thread est activé parl’ordonnanceur. Quand que le thread est dispatché, les instants de démarrage et de termi-naison peuvent être calculés en fonction des propriétés temporelles spécifiées.

1.5.4 Modélisation de thread

Les threads sont les principaux composants AADL exécutables et ordonnançables.Un thread Th représente une unité concurrente ordonnançable d’exécution séquentielledéfinie par un code source. Pour caractériser sa capacité expressive, un thread Th encap-sule une fonctionnalité qui peut consister en des ports P ∈ F , des connexions C = P× P,des propriéts R ∈ R, des spécifications de comportement T/S et des sous-programmesS u qui peuvent être invoqués par le thread.

Th = < P, C, R, S u, T/S >

La sémantique d’exécution d’un thread AADL est la suivante :

1. Lire et geler les entrées. Le contenu des données entrantes est gelé pour la duréed’exécution du thread. Par défaut, l’entrée est gelée au moment du dispatch. Sila propriété Input_Time est spécifiée, ce moment est déterminé par la valeur de lapropriété. Toute entrée arrivant après ce gel devient disponible à l’instant d’entréesuivant.

2. Exécuter et calculer. Quand l’activité du thread entre dans l’état de calcul,l’exécution de la séquence de code source correspondant au point d’entrée du threadest gérée par un ordonnanceur.

3. Actualiser et rendre disponibles les sorties. Par défaut, une sortie est transférée versd’autres composants à l’instant de terminaison (au moment de l’échéance en cas

24


de connexion de port de données retardée), ou comme spécifié par la valeur de lapropriété Output_Time.

Étapes d’interprétation

1. Un thread AADL Th est d’abord traduit en un processus Signal SP, qui correspondà un processus ARINC, du point de vue de la structure fonctionnelle. SP a lesmêmes flots d’entrée/sortie que Th, plus un “tick” additionnel, qui est un tick in-terne provenant du processeur (l’ordonnanceur). Ce tick sera utilisé dans la trans-formation des comportements et des actions/calculs qu’ils contiennent. Les actionseffectives, représentées par la spécification du comportement, sont décrites dans lasection consacrée à la spécification du comportement.

Th yx

SPSstartsuspend

resume

dispatch

SPT

x ly

startSPat

start at

complete

lxy

Pinner timing environment

completedeadline

deadline

tick

Figure 1.7: Traduction d’un thread AADL en un thread Signal.

2. En raison de la différence de sémantique temporelle entre AADL et Signal, les pro-priétés temporelles d’un thread AADL sont traduites par un autre processus Signal,SPT (figure 1.7), qui joue le rôle d’interface sémantique temporelle entre AADL etSignal.

Les principales fonctions de SPT en regard de SP sont : 1) mémoriser les signauxd’entrée, et les conserver jusqu’à ce que le thread soit activé par l’événement start,2) activer le processus Signal fonctionnel SP au moment du start, 3) mémoriser lessorties du thread jusqu’à la date de terminaison (lorsque l’événement s_complete

est arrivé). La mémorisation des signaux et l’activation du thread servent ici depont entre la sémantique des threads en AADL et le modèle synchrone.

3. L’exécution d’un thread est caractérisée par certains aspects temps réel. Un threadest ordonnancé suivant des propriétés temporelles. En raison de cette sémantique decontrôle temps réel, un nouveau processus, SPS (figure 1.7), est ajouté, à l’intérieurduquel les signaux de contrôle temporel sont automatiquement calculés lorsqu’il est

25


activé. Quand il reçoit les signaux gérant l’ordonnancement (par exemple, dispatch)depuis l’ordonnanceur de threads, il commence à calculer ses propres signaux tem-porels pour l’activation et la complétion du processus SPT.

Règles d’abstraction Nous donnons une description abstraite des règles de transfor-mation d’un thread Th = < P, C, R, S u, T/S > en un processus Signal (en tant queprocessus APEX ARINC). La notation I représente l’interprétation.

1. Un composant thread est traduit par un processus ARINC, paramétré parI(P), I(C), I(R), I(S u), I(T/S ). La notation Programparameters est utilisée pourdénoter que les paramètres parameters serviront à la définition du Program. Le rôlede ces paramètres est expliqué plus en détail ci-dessous. La fonctionnalité du threadest traduite en deux sous-processus, S PS et S PT , à l’intérieur du processus.

I(Th) = (S PS I(R) | S PTI(P), I(C), I(S u), I(T/S ))

2. Le sous-processus S PS est paramétré par les propriétés R. L’interface de S PS

inclut les entrées tick, dispatch, suspend, resume et les sorties start, complete, dead-

line.

S PS = (? event tick, dispatch, suspend, resume;

! event start, complete, deadline; )

Les propriétés r ∈ R, par exemple, Input_Time, Output_Time, sont interprétées dansS PS . Les valeurs de ces propriétés sont utilisées pour compter les ticks logiquespour les instants de démarrage et de terminaison du thread.

3. Le sous-processus S PTI(P), I(C), I(S u), I(T/S ) est paramétré parI(P), I(C), I(S u), I(T/S ). Les ports P sont traduits comme des entrées/sorties, et les connexions, sous-programmes et comportements sont traduits dans lesous-processus S PT . Le détail de ces paramètres est expliqué ci-dessous.

4. Les ports d’entrée/sortie P du thread sont traduits en entrées/sorties de Signal.L’interface du processus ARINC inclut ces signaux et les entrées événements tick,

dispatch, suspend, resume reçues de l’ordonnanceur. La valeur p.direction désignela direction d’un port p.

inputs = {tick, dispatch, suspend, resume} ∪ I(p) ∀p ∈ P, p.direction = in

outputs = {I(p)} ∀p ∈ P, p.direction = out

26


5. Les transitions/actions T/S sont interprétées dans un processus synchrone S P ensuivant les étapes présentées dans la section suivante. Ce processus synchrone S P

est encapsulé dans le sous-processus S PT . La valeur c.type désigne le type de laconnexion c, qui peut être soit immediate ou delayed.

S PT = (IM | S PI(S u),I(C) | OM)

où

S PI(S u),I(C) = I(T/S )

IM = (iipk1:= at(I(pk1), start) | iipk2

:= at(I(pk2), start) | . . . )

pour tous pk j∈ P, t.q. pk j

.direction = in

OM = (OMimm | OMdelayed)

OMimm = (oopk1:= at(I(pk1), complete) | oopk2

:= at(I(pk2), complete) | . . . )

pour tous pk j∈ P, t.q. ∃c ∈ C, c = (p1, pk j

), c.type = immediate, pk j.direction = out

OMdelayed = (oopk1:= at(I(pk1), deadline) | oopk2

:= at(I(pk2), deadline) | . . . )

pour tous pk j∈ P, t.q. ∃c ∈ C, c = (p1, pk j

), c.type = delayed, pk j.direction = out

6. Chaque sous-programme su ∈ S u est interprété comme un processus Signal PPsu :

I(su) = PPsu(? In1, . . . Inm; ! Out1, . . .Outn; ) PPsu_BODY

Il est invoqué comme une instance dans le sous-processus S P :

(| o1 := Out1 | . . . | on := Outn | PPsu_BODY | In1 := i1 | . . . | Inm := im)

Une connexion dans un thread c = (p1, p2) ∈ C relie les ports (paramètres) desprocessus correspondant aux sous-programmes invoqués. Une telle connexion estinterprétée comme une affectation reliant les entrées/sorties des modèles de sous-programmes :

I(p2) := I(p1)

1.5.5 Modélisation des autres composants

Modélisation de processeur Un composant processeur est une abstraction du matérielet des logiciels chargés de l’exécution et de l’ordonnancement des threads. Le processeurest transformé en un ordonnanceur, qui correspond à l’OS de niveau partition de la parti-

tion.

Modélisation de bus Un composant bus représente le matériel et les protocoles de com-munication associés qui permettent les interactions entre les autres composants de la plate-

27


forme d’exécution. Pour modéliser un bus en Signal, nous considérons deux fonctions de“bufferisation” de données (deux buffers) qui communiquent par une fonction connect.Chaque buffer reçoit les données et les stocke jusqu’à ce que le bus (resp. le lecteur) lesrécupère. La fonction connect transfère les données vers le buffer du lecteur.

Modélisation de système Le système est le composant de plus haut niveau d’un mod-èle AADL, il représente un composite de logiciels applicatifs qui interagissent, d’uneplate-forme d’exécution, et de composants système. Un système est transformé en unprocessus Signal, qui comporte une composition de modules ARINC et un ordonnanceurpermettant d’activer les modules. Un module est un processus Signal qui se compose dessous-processus interprétés à partir des processus AADL (liés à un même processeur).

Modélisation de processus Un processus AADL est traduit en une partition ARINC(représentée comme un processus Signal). Les threads contenus dans le processus seronttraduits par des processus ARINC à l’intérieur de la partition, afin qu’ils puissent accéderaux ressources restreintes à la partition. Un ordonnanceur interne est nécessaire pourordonnancer ces threads. Les processus liés à un même processeur sont interprétés dansun module ARINC.

Modélisation de sous-programme Les sous-programmes sont des éléments pouvantêtre invoqués, qui fournissent une fonction de serveur aux composants qui les appel-lent. Un sous-programme est traduit en un processus Signal paramétré par les ports(paramètres) eux-mêmes traduits.

Modélisation de données Les types de données sont similaires structurellement auxdéclarations de types de Signal. Chaque type de données simple est transformé en unedéclaration de type de Signal. Le composant “donnée composée” est interprété commeun type structure.

Modélisation de connexion de port Deux types de connexions de ports de donnéessont modélisés : les connexions immédiates et les connexions retardées. Sur la basede leur sémantique temporelle spécifique, l’implémentation assure une communicationdéterministe entre les threads.

1.6 Spécification de comportements AADL

L’annexe comportementale décrit les comportements sous la forme d’un système de tran-sition [42]. Elle peut être attachée à l’implémentation d’un composant, principalementpour les threads et les sous-programmes. Les comportements décrits dans cette an-nexe sont basés sur des variables d’état dont l’évolution est spécifiée par les transitions.L’annexe comportementale fournit une extension du mécanisme de dispatch du modèled’exécution.

Pour effectuer la vérification de modèle (model checking) d’un système décrit enAADL, il est nécessaire de disposer des comportements des composants. En vue d’une

28

1.6. SPÉCIFICATION DE COMPORTEMENTS AADL

validation et d’une vérification au plus tôt du système, nous proposons une approchepermettant d’interpréter automatiquement les comportements AADL dans un modèle decalcul approprié. Dans cette méthode, les notations de l’annexe comportementale sontintégrées dans le modèle de calcul polychrone, à des fins de vérification formelle et degénération de code.

Dans l’annexe comportementale AADL, les affectations multiples d’une même vari-able dans une même transition sont légales, alors qu’en Signal, il n’est pas autorisé dedéfinir plusieurs fois un signal dans un même instant. Par conséquent, une réécrituredes affectations est nécessaire dans l’interprétation. Dans la forme SSA (static single as-

signment) [70, 161], chaque variable n’apparaît qu’une seule fois en partie gauche desaffectations : elle n’est définie qu’une seule fois. Notre interprétation utilise SSA commeformalisme intermédiaire.

Les transitions et les actions sont transformées en un ensemble d’équations syn-chrones. Cette transformation de modèle repose sur un algorithme inductif de transfor-mation vers SSA appliqué sur les transitions et les actions [122]. Pour ce qui concerneles exigences de vérification, cet algorithme minimise le nombre d’états des automates, etpermet donc un model checking avec de bonnes performances.

1.6.1 Forme SSA

Un programme est dit en forme SSA [70, 64, 63, 69] lorsque chaque variable dans leprogramme n’apparaît qu’une seule fois en partie gauche des affectations. Une seulenouvelle valeur au plus d’une variable x peut être définie dans un instant donné. La formeSSA d’un programme remplace les affectations d’une variable x du programme par desaffectations à de nouvelles versions x1, x2. . . de x, en indiçant de manière unique chaqueaffectation.

Un opérateur, noté PHI, est nécessaire pour choisir la valeur en fonction du flot decontrôle du programme, lorsqu’une une variable peut être affectée dans les deux branchesd’une instruction conditionnelle ou dans le corps d’une boucle. Comme SSA est unereprésentation intermédiaire, l’introduction de nœuds PHI n’entraînera pas nécessaire-ment de surcoût d’exécution. La compilation de Signal permettra d’optimiser le coded’exécution final.

Cette approche introduit une méthode effective pour transformer les spécifications decomportement consistant en des transitions et des actions en un ensemble d’équationssynchrones. Notre transformation minimise les variables d’état nécessaires et la synchro-nisation des composants.

1.6.2 Systèmes de transition AADL

Des spécifications de comportement peuvent être attachées aux implémentations de com-posants AADL à l’aide d’une annexe. L’annexe comportementale de AADL décrit unsystème de transition.

Transitions La section des transitions déclare un ensemble de transitions T . Lorsque laspécification de comportement d’un thread est déclenchée pour la première fois, le threaddémarre son exécution depuis un état initial, spécifié comme s : initial state. L’exécution

29


se termine dans un état complete (return pour un sous-programme), spécifié comme t :complete state (ou t : return state). Depuis un état s, si la garde g est vraie, une transitionest activée, la partie action S est effectuée, puis un nouvel état, t, est atteint ; cela s’écrit :s − [g]→ t {S }. La notation “;” en AADL dénote la composition parallèle de transitions.

T ∋ T ::= s − [g]→ t {S } | T1; T2 s, t : états

g : garde

S : actions

Actions Une action S ∈ S est, récursivement, une séquence d’actions, une bouclesur des actions, une instruction conditionnelle, une action temporelle (computation(),delay()), ou une action de base. Une action de base B ∈ B est, récursivement, uneséquence d’actions de base, une action d’affectation w := f (y, z), une action de réceptionde message (p?(x)), ou une action d’émission de message (p!(x)).

B ∋ B ::= w := f (y, z) | p?(x) | p!(x) | B1; B2

S ∋ S ::= if x then S 1 else S 2

| for (x in X) S

| delay(min, max)

| computation(min, max)

| B

| S 1; S 2

1.6.3 Interprétation des transitions / actions

Afin de distinguer entre les transitions de phases d’interprétation différentes, nous intro-duisons quelques notations. Nous utilisons S ∈ S pour représenter une action généralede la transition d’origine T ∈ T , et U ∈ U pour représenter les transitions intermédiaires,dites transitions de base, dont les actions sont des actions de base B ∈ B.

U ∋ U ::= s − [g]→t {B} | U1; U2

T ∋ T ::= s − [g]→t {S } | T1; T2

La notation de f (A) est introduite pour désigner la partie gauche w d’une actiond’affectation A (w := f (y, z)), et use(A) pour désigner la partie droite f (y, z).

Une action en forme SSA A ∈ A est, récursivement, une séquence d’actions en formeSSA, ou une affectation w := f (y, z), où w est défini au plus une fois dans A. En d’autres

30


termes, pour tout S ∋ A = A1; A2, si w ∈ de f (A1), alors w < de f (A2), et de même pourl’inverse. La transition associée est appelée transition en forme SSA W ∈ W .

A ∋ A ::= w := f (y, z) | A1; A2

W ∋ W ::= s − [g]→t {A} | W1; W2

Comme les actions sont attachées aux transitions, nous devons prendre en considéra-tion les états de départ et d’arrivée dans l’interprétation des actions.

T/S : original transition/actions

U/B : basic transition/actions

W/A : SSA form transition/actions

P : Signal programs

Step 1

Step 2

Step 3

IT

IU

Iw

Figure 1.8: Chaîne de transformation de l’annexe comportementale.

Nous utilisons I(T ) pour dénoter l’interprétation d’une transition T vers un processusSignal. La transformation des transitions/actions AADL vers I(T ) en Signal est adresséeen trois étapes (comme illustré sur la figure 1.8) :

I(T ) : TIT

7→ UIU

7→ WIW

7→ P

Étape 1 : actions vers actions de base. TIT

7→ U. Chaque transition T ∈ T avecune séquence d’actions générales S ∈ S est décomposée en ensembles de transitions debase U ∈ U , dans lesquelles toutes les actions sont des actions de base B ∈ B.

Nous utilisons IT (T ) pour représenter cette interprétation, d’une transition généraleT ∈ T vers des transitions de base U ∈ U .

IT (T ) : T 7→ U où T ∈ T

U ∈ U

Pour la décomposition d’une transition d’origine T en transitions de base U, il suffitde décomposer les actions non basiques (par exemple, les instructions conditionnelles et

31


les boucles) vers des actions de base, avec des transitions intermédiaires. En premier lieu,lors du traitement des séquences, les actions non basiques doivent être séparées dans lesactions d’origine ; en second lieu, la décomposition des actions non basiques en actionsde base est effectuée.

• Traitement des séquences. Nous utilisons une fonction récursive intermédiaireITS pour rendre explicite la séparation des actions d’une transition T comme lacomposition séquentielle d’un premier bloc d’actions de base déjà traitées, notéB, et d’un deuxième bloc, noté S , où les actions ne sont pas encore transformées.La règle de base de la transformation récursive est que, depuis les premières ac-tions d’origine, si une action est une action de base, alors elle est déplacée dans B,ceci jusqu’à occurrence d’une action non basique. B est séparé, et une transitionintermédiaire est introduite pour les actions B, depuis l’état source s vers un état in-termédiaire s1. Pour les actions restantes S , les actions non basiques seront d’aborddécomposées en utilisant les règles présentées dans la section sur la décomposition,puis pour le reste, la séparation se poursuit selon les règles dcrites ici.

• Décomposition. La décomposition d’une action composite S (S ∈ S et S < B)d’une transition T — action conditionnelle ou boucle ou action temporelle (com-putation() ou delay()) — retourne une transition intermédiaire U ∈ U (qui peutêtre une composition de transitions) où les actions de U sont des actions de base.

Étape 2 : actions de base vers actions en forme SSA. UIU

7→ W. Pour chaquetransition intermédiaire U ∈ U , les actions de base B ∈ B sont représentées en formeSSA A ∈ A et de nouvelles transitions sont introduites si nécessaire. Chaque définitiond’une variable d’origine w est remplacée par une nouvelle version (puisqu’il ne peut pas yavoir de définitions multiples dans la forme SSA), de sorte que les actions en forme SSApeuvent être exécutées dans un même instant.

Comme les actions de base sont constituées récursivement d’une séquence de troistypes d’actions, l’affectation, la réception de message et l’émission de message, danscette étape, seuls ces types d’actions (resp. de transitions) doivent être interprétés. Danscette étape, l’interprétation est effectuée en deux phases : d’une part, l’interprétation desactions de base en forme SSA ; d’autre part, le traitement des séquences de transitions debase vers la forme SSA.

La function IU est utilisée pour représenter l’interprétation d’une transition intermé-diaire U ∈ U , d’action B ∈ B, qui sera représentée en transitions de forme SSA W ∈ W ,d’actions A ∈ A . Dans cette étape, une transition intermédiaire U = s − [c] → t {B}

(de l’état source s vers l’état destination t, gardée par la condition c, et d’action de baseB) sera interprétée en transitions de forme SSA W ∈ W , dans laquelle les actions A sonttoutes en forme SSA.

IU : U → W où U ∈ U

W ∈ W

32


Étape 3 : SSA vers Signal. WIW

7→ P. Les actions en forme SSA A ∈ A et lestransitions sont traduites en équations Signal.

• Interprétation des actions de forme SSA. L’interprétation IA(A)g = P d’une ac-tion en forme SSA A prend en paramètre la garde g qui conduit à l’exécution decette action, et retourne une équation Signal P. La seule action en forme SSA estl’affectation, ou la séquence d’affectations. Par conséquent, l’interprétation danscette étape ne considère que l’action d’affectation et la séquence.

Pour une affectation x := f (y, z), les signaux utilisés (en partie droite del’affectation) seront échantillonnés par la garde g : when g. Une définition par-tielle ::= est utilisée ici car il peut y avoir d’autres définitions de x avec d’autresgardes. Un opérateur cell est introduit sur les opérandes pour les rendre disponiblesà leur horloge commune minimale.

IA(x := f (y, z))g = (x ::= f (y cell h, z cell h) when g | h := y+z)/h

Pour une séquence d’affectations, l’interprétation peut être effectuée en parallèle.La notation “|” est utilisée pour dénoter la composition parallèle en Signal.

IA(A1; A2)g = IA(A1)g | IA(A1)g

• Interprétation des transitions de forme SSA. La notation IW(W)st,nst est utiliséepour représenter l’interprétation de la transition en forme SSA W ∈ W vers unprocessus Signal. Elle est paramétrée par les variables st, nst représentant respec-tivement l’état courant et l’état suivant du système de transition.

IW(W1; W2)st,nst = IW(W1)st,nst | IW(W2)st,nst

IW(W)st,nst = (P | nst ::= t when g) où W = s − [c]→ t {A}

g = when (st = s) when c

P = IA(A)g

L’équation nst ::= t when g exprime que, lorsque la garde g est vraie, ce qui signifielorsque l’état courant st est s et lorsque la condition c est satisfaite, l’état suivantnst de la transition sera t. Lorsqu’une transition se termine, l’état de sortie devientl’état courant.

Interprétation globale. Au final, la transformation globale I d’un système de transitionT = (T1; . . . ; Tn)s0, tick, en suivant l’interprétation en trois étapes, doit tenir compte de l’étatinitial s0 du système de transition et de l’horloge, notée tick, représentant les instantsauxquels le thread considéré est actif — cette horloge est définie par l’ordonnanceur. Lesignal d’entrée tick, qui est un signal de contrôle de type event, connecte le système

33


d’exploitation (l’ordonnanceur) au thread pour l’informer qu’il est sélectionné pour êtreeffectivement exécuté.

I(T1; T2)s0, tick = I(T1)s0, tick | I(T2)s0, tick

I(T )s0, tick = (P | st := nst $ init s0 | st ˆ = tick) /st, nst où P = IW(W)st,nst

W = IU(U)

U = IT (T )

Dans cette transformation, nous montrons non seulement comment traduire les fonc-tionnalités de base de la programmation impérative en équations, mais nous considéronsaussi les automates de modes qui contrôlent l’activation de ces transitions et actions élé-mentaires.

1.7 Génération de modèles de simulation distribués

Un système distribué [44, 116] peut être beaucoup plus étendu et puissant que des combi-naisons de systèmes autonomes. Polychrony fournit des méthodes générales de compila-tion, en particulier pour la génération de code distribué [47, 58].

Pour une transformation complète, nous considérons deux spécifications. La premièreest le programme Signal qui comprend tous les composants de calcul et représente lesflots de données, programme traduit à partir des composants AADL. La seconde est laspécification de l’architecture matérielle : dans la spécification d’architecture AADL, lafaçon dont le système doit être distribué est clairement définie ; par exemple, quels pro-cessus doivent être exécutés et ordonnancés par quel processeur, et comment le processeurordonnancera périodiquement ou sporadiquement les processus.

La figure 1.9 illustre les étapes permettant de distribuer semi-automatiquement unprogramme Signal. Tout d’abord, les composants spécifiés sont placés (mapping) surl’architecture cible, un ordonnanceur est ajouté pour chaque processeur, et les synchro-nisations d’horloges entre les composants partitionnés sont synthétisées. Le mécanismedes pragmas en Signal (pragma “RunOn”) est utilisé pour représenter les informations deplacement. Ensuite, des modèles de communication sont ajoutés entre ces composants.MPI, qui est un protocole du communication indépendant du langage, utilisé pour pro-grammer des ordinateurs parallèles, est utilisé ici pour les communications entre les pro-grammes distribués. L’étape finale consiste en la génération des codes exécutables dis-tribués [123].

1.7.1 Placement

Comme un processus AADL est traduit en une partition ARINC, et qu’il est lié à unprocesseur comme spécifié dans les propriétés, on peut affecter chaque partition à un pro-cesseur donné. Chaque partition est rythmée par sa propre horloge. Le pragma Signal“RunOn” [58] est utilisé dans l’environnement Polychrony pour les informations de par-titionnement : quand un partitionnement basé sur l’utilisation du pragma “RunOn”est ap-

34

1.7. GÉNÉRATION DE MODÈLES DE SIMULATION DISTRIBUÉS

Figure 1.9: Génération de code distribué.

pliqué à un système, l’application globale est partitionnée selon les différentes valeurs dupragma de façon à obtenir des sous-modèles de processus. L’arbre des horloges (la racinede l’arbre représente l’horloge la plus fréquente) et l’interface de ces sous-modèles peu-vent être complétés de manière à ce qu’ils représentent des processus endochrones [153](un processus endochrone est insensible aux délais de propagation internes et externes).

Les principes du placement sont les suivants :

1. Description flot de données du logiciel, en utilisant le langage Signal (pro-gramme P).

2. Description de l’architecture cible. Celle-ci est spécifiée dans le modèle AADL, enparticulier dans les propriétés.

3. Placement du programme logiciel sur l’architecture cible. Le programme P estainsi récrit sous la forme (|P1|...|Pn|), où n est le nombre de “processeurs”.Cette étape n’est qu’une restructuration syntaxique du programme d’origine. Unprocessus Signal Pi est annoté avec un pragma “RunOn i”. Ce pragma sera utilisépour le partitionnement.

35


1.7.2 Ordonnanceur

L’ordonnanceur sélectionne les tâches à exécuter en fonction de la politiqued’ordonnancement. Dans le modèle APEX-ARINC, l’OS de niveau module estl’ordonnanceur qui va ordonnancer les partitions à l’intérieur d’un même module.L’ordonnancement des partitions est strictement déterministe (du point de vue du temps)dans la norme ARINC 653. Chaque partition est ordonnancée selon sa fenêtre temporellede partition. L’ordonnancement est fixe pour une configuration particulière de partitionssur le processeur. À l’intérieur de la partition, un OS de niveau partition est utilisé pourl’ordonnancement des processus (traduits des threads AADL).

Les principes d’ordonnancement sont les suivants :

1. Ordonnancement des partitions. Nos règles de transformation suivent la normeAADL, selon laquelle chaque processeur peut être attribué à plusieurs proces-sus, ce qui signifie qu’un processeur peut exécuter plusieurs partitions. Commel’ordonnanceur des partitions s’exécutant sur un processeur est déterministe, il eststatique et fixe selon les tables de configuration. Nous créons à cette fin un ordon-nanceur statique simple (cf. Module_Level_OS de APEX-ARINC).

2. Compilation globale. Après avoir ajouté l’ordonnanceur dans le programme, celui-ci peut être compilé globalement afin de permettre la séparation ultérieure desdifférentes parties. Cette phase rend explicites toutes les synchronisations del’application, puis synthétise, si elle existe, l’horloge maîtresse du programme, etdétecte les contraintes de synchronisation.

Le compilateur utilise le calcul d’horloges pour analyser statiquement chaque équa-tion du programme, pour identifier la structure des horloges des variables, et pourordonnancer l’ensemble des calculs. Si la composition des équations contient descontraintes d’horloges, cela signifie qu’il existe des contraintes de synchronisation.

Le programme distribué est généré automatiquement dans l’environnement Poly-chrony, en appliquant la compilation en mode distribution.

Par rapport au programme d’origine, une réécriture a été effectuée pour les partiesséparées. Toutes les propriétés de calcul sont préservées, et un ordonnanceur a étéajouté pour chacun des processeurs.

1.7.3 Ajout des communications

Un programme distribué consiste en un ensemble de processus interagissant avecl’environnement et communiquant entre eux. Les raisons de ces communications sontd’envoyer des données ou des signaux à d’autres processus, de se synchroniser avecd’autres processus, ou de demander une action à un autre processus.

Il existe deux solutions de base pour les communications : les variables partagées etl’envoi de messages. Les variables partagées ne permettent pas la synchronisation entreprocessus parallèles, à moins qu’un mécanisme complexe soit défini au-dessus. En outre,elles rendent la vérification formelle plus difficile. L’autre solution est la communicationpar envoi de messages. Les messages permettant de communiquer dans les systèmesdistribués peuvent être de type synchrone ou asynchrone. Dans notre implémentation,

36

1.8. VÉRIFICATION ET SIMULATION

nous utilisons MPI (Message Passing Interface) [159]. Il s’agit d’une interface de passagede messages, ainsi que de protocoles et de spécifications sémantiques pour la façon dontses fonctions doivent se comporter dans une mise en œuvre.

MPI préserve l’ordre et l’intégrité des messages (par exemple, par des accusés deréception et des numéros de séquence). Cela permet d’assurer que les valeurs ne sontpas mélangées dans les séquences, pourvu que les actions send soient exécutées sur unemplacement dans le même ordre que les actions recv correspondantes sur l’autre em-placement. À partir de la spécification de distribution, une balise unique est attribuée àchaque variable commune du programme.

Pour exécuter les parties distribuées, il est nécessaire de configurer les machinesphysiques pour leur exécution. La table 7.3 donne un exemple détaillé de configura-tion : le fichier binaire exécutable généré qui se trouve dans DIRECTORY0 (resp. DI-RECTORY1) sera exécuté sur node0 (resp. node1). Les deux machines (noeuds) sontspécifiées par les adresses hôtes dans le fichier “lamhosts”.

lamhosts:10.0.1.3 %the first machine%10.0.1.5 %the second machine%c0 -wd DIRECTORY0 10.0.1.3 % node0 runs on 10.0.1.3%c1 -wd DIRECTORY1 10.0.1.5 % node1 runs on 10.0.1.5%

Table 1.2: Exemple de configuration.

Finalement, les parties peuvent être compilées localement et exécutées respectivementsur les différentes machines. Les programmes sont exécutés sur les processeurs distribués.

1.8 Vérification et simulation

Dans cette section, nous décrivons une chaîne d’outils de vérification formelle et de simu-lation pour AADL. Nous donnons une vue de haut niveau des outils impliqués et illustronsles transformations successives requises par notre processus de vérification. Deux étudesde cas sont présentées pour illustrer la validation d’applications AADL, en particulier parvérification formelle et par simulation.

1.8.1 Vérification formelle

Ces dernières années, AADL a été de plus en plus utilisé pour des systèmes embarquéscritiques dans le domaine avionique à des fins de démonstration. L’objectif principaln’est pas seulement lié à l’exploration d’architecture et l’analyse. La vérification formelledes aspects fonctionnels devient aussi une démarche de validation très intéressante. Lavalidation de modèles AADL par des méthodes formelles a été étudiée dans [132, 67,164, 139], où des sémantiques formelles sont associées aux spécifications AADL, de tellesorte qu’une vérification formelle puisse être effectuée.

Notre approche s’inscrit dans la vérification de modèle dans le cadre de Polychrony.Les spécifications AADL sont traduites en Signal, puis l’outil de vérification de modèleassocié à Polychrony, appelé Sigali [126], est utilisé pour vérifier des propriétés de sûreté.

37


Sigali utilise des systèmes dynamiques polynomiaux [125] sur Z/3Z = {-1, 0, 1}) commemodèle formel. Les programmes Signal peuvent être transformés en équations polyno-miales, qui sont manipulées par Sigali. Les trois états d’un signal booléen peuvent êtrecodés comme : présent ∧ vrai ⇔ 1; présent ∧ faux ⇔ −1; absent ⇔ 0. Pour lessignaux non booléens, seules leurs horloges sont encodées, c’est-à-dire que leurs valeurssont ignorées.

La première étude de cas permet d’illustrer la vérification de modèle de modèlesAADL via Polychrony. AADL est utilisé pour modéliser un système de guidage de volsimplifié (FGS). Les modèles AADL sont alors traduits, via Signal, en une représenta-tion symbolique, des systèmes dynamiques polynomiaux, manipulés par le vérificateur demodèle Sigali. Avec Sigali, des propriétés de sûreté exprimées en CTL sont vérifiées surle système.

1.8.2 Simulation

Dans cette section, nous décrivons le processus de conception pour la co-modélisation etla co-simulation d’une étude de cas du projet CESAR dans le cadre de Polychrony. Ceprocessus de conception est basé sur une approche de co-conception au niveau système.Polychrony est utilisé comme plate-forme commune de développement. La simulation estréalisée à des fins de vérification et d’analyse temporelle au niveau système.

Le “profilage” de logiciel peut être considéré comme une sorte d’analyse dynamiquede programme au moyen des informations recueillies lorsque le programme s’exécute.Une telle analyse est en général effectuée à des fins d’amélioration des performances.Le profilage est aussi adopté dans Polychrony pour l’évaluation de performance des pro-grammes Signal [106] [82]. Le processus de profilage comprend la spécification de pro-priétés temporelles, un homomorphisme temporel, et une co-simulation.

Dans le cadre de Polychrony, le profilage se réfère à l’analyse temporelle parl’association d’informations de date et de durée à des programmes Signal. À chaquesignal, x, du programme, est associé un signal de date, date_x, pour indiquer ses instantsde disponibilité. Ce signal de date peut être spécifié avec une horloge métrique, une hor-loge logique ou des cycles d’horloge. Dans le premier cas, les signaux de date sont desnombres réels positifs, et dans les autres cas, ce sont des entiers positifs. À chaque opéra-tion dans le programme Signal est associée une information de durée, qui peut avoir lesmêmes types de donnée que les signaux de dates. La durée peut aussi être représentée parun couple de nombres correspondant au meilleur et au pire cas. En outre, ces informationssont fonction de plusieurs paramètres tels que le type d’opération, les types de données,et les architectures de mise en œuvre.

La seconde étude de cas est un système simplifié de contrôle des portes et toboggans(SDSCS) en avionique. En plus de la simulation AADL, cette étude de cas illustre égale-ment une approche de co-conception de système de haut niveau et hétérogène, basée surles modèles, pour une architecture de système globalement asynchrone et localement syn-chrone (GALS). Dans cette étude de cas, l’architecture matérielle distribuée, ainsi queles aspects asynchrones, sont modélisés en AADL, tandis que le comportement fonction-nel, exprimé dans le modèle à flots de données synchronisés, est modélisé en Simulink.SME/Polychrony est adopté comme formalisme commun permettant de faire la liaisonentre deux modèles hétérogènes. La modélisation AADL et les résultats de transforma-

38

1.9. CONCLUSION

Figure 1.10: Co-simulation d’un programme Signal et de son comportement temporel.

tion en Signal sont présentés. Une co-simulation rapide (phase initiale) avec profilagepar prise en compte des contraintes de temps (figure 1.10), ainsi qu’une démonstration desimulation par des afficheurs VCD (figure 1.11) ont été réalisées dans le cadre de Poly-chrony.

Figure 1.11: Simulation avec afficheur VCD : GTKWave

1.9 Conclusion

La principale motivation des travaux présentés dans cette thèse est de combler le fosséentre les modèles de AADL et Polychrony. Nous proposons pour cela une méthodologiepour la modélisation de niveau système et la validation de systèmes embarqués spécifiésen AADL via le modèle de calcul polychrone. Cette méthodologie comprend la modéli-sation de niveau système via AADL, des transformations automatiques à partir du modèleAADL de haut niveau vers le modèle polychrone, la distribution de code, la vérificationformelle, la simulation du modèle polychrone obtenu, et le raffinement du modèle enfonction des résultats de validation.

Contributions Notre conception au niveau système prend en compte à la foisl’architecture du système, plus spécialement pour une architecture décrite selon le mod-èle “avionique modulaire intégrée” (IMA), et les aspects fonctionnels, par exemple, avecdes composants logiciels implémentés dans le langage de programmation synchrone Sig-nal. À partir de spécifications AADL de haut niveau, la distribution automatique de code

39


pour la simulation a été expérimentée via le modèle polychrone et les pragmas de distri-bution de Signal. En outre, l’annexe comportementale de AADL, qui est une extensionpour la spécification des comportements effectifs, est également prise en compte dans latraduction de AADL vers Signal. Elle repose sur l’utilisation de SSA (Static Single As-

signment) comme formalisme intermédiaire. La simulation, la validation et la vérificationde haut niveau sont ensuite effectuées au moyen de technologies et outils associés, commel’utilisation de Sigali, le profilage, ou les démonstrateurs de changements de valeurs, quipermettent de vérifier formellement et d’analyser le modèle résultant. Des techniqueset des bibliothèques existantes de Polychrony, qui consistent en un modèle des servicestemps réel de APEX-ARINC, ont notamment été utilisées.

Perspectives Nous prévoyons d’étendre cette modélisation afin de couvrir un périmètreplus large de AADL, ainsi que des aspects temporels supplémentaires qui sont liés à laconception GALS et permettent des analyses temporelles plus sophistiquées. Une autreextension consistera à fournir une bibliothèque de modèles Signal adaptés à la mod-élisation de composants standards. Cette bibliothèque permettra de réduire les tâchesrépétitives de modélisation. Des connexions à d’autres outils de simulation pour ce quiconcerne l’analyse temporelle sont aussi prévues, comme par exemple SynDEx [25] ouRT-Builder [22]. Pour la modélisation et la vérification de systèmes GALS, il serait in-téressant de pouvoir insérer des buffers de désynchronisation dans une démarche de raf-finement, et de vérifier la correction du raffinement vis-à-vis de la préservation de flotet des contraintes temps réel. Au-delà des connexions point à point, différents typesd’interconnexions entre les composants synchrones permettraient la vérification de sys-tèmes GALS plus complexes. Enfin, des extensions de notre modèle d’ordonnancementconstituent aussi une perspective à ce travail.

40

Part II

Conceptions of AADL and Signal

Chapter 2

Introduction to AADL and Avionicarchitectures

Contents2.1 AADL language abstractions . . . . . . . . . . . . . . . . . . . . . . 44

2.1.1 The SAE AADL standard . . . . . . . . . . . . . . . . . . . . 44

2.1.2 AADL meta-model and models . . . . . . . . . . . . . . . . . 45

2.1.3 AADL open source tools . . . . . . . . . . . . . . . . . . . . . 46

2.2 Summary of the core AADL components . . . . . . . . . . . . . . . 48

2.2.1 Software components . . . . . . . . . . . . . . . . . . . . . . . 50

2.2.2 Execution platform components . . . . . . . . . . . . . . . . . 55

2.2.3 System component . . . . . . . . . . . . . . . . . . . . . . . . 58

2.3 System binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

2.4 Component interaction . . . . . . . . . . . . . . . . . . . . . . . . . 60

2.4.1 Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

2.4.2 Port connection . . . . . . . . . . . . . . . . . . . . . . . . . . 61

2.5 Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

2.6 AADL behavior annex . . . . . . . . . . . . . . . . . . . . . . . . . . 64

2.7 Avionics system architecture and ARINC653 . . . . . . . . . . . . . 65

2.7.1 Avionics system architecture overview . . . . . . . . . . . . . . 65

2.7.2 ARINC standard . . . . . . . . . . . . . . . . . . . . . . . . . 66

2.7.3 AADL and ARINC . . . . . . . . . . . . . . . . . . . . . . . . 69

2.8 AADL components considered in this thesis . . . . . . . . . . . . . . 70

2.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

This chapter is devoted to the introduction of the Architecture Analysis and DesignLanguage (AADL).

Developed by the Society of Automotive Engineers (SAE), AADL was approved andpublished as SAE standard (AS5506) in November 2004. The purpose of the SAE AADL

CHAPTER 2. INTRODUCTION TO AADL AND AVIONIC ARCHITECTURES

standard is to provide a standard and sufficiently precise way of modeling the architectureof an embedded real-time system, such as an avionics system or automotive control sys-tem, to permit analysis of its properties, and to support the predictable integration of itsimplementation.

As an architecture description language, AADL supports modeling of the embeddedsoftware runtime architecture, the execution hardware, and the interface to the physi-cal environment of embedded systems. A system can be automatically integrated fromAADL models, when fully specified and when source code is provided for the softwarecomponents.

The AADL standard consists of a suite of documents: the core AADL language stan-dard and a series of extensible annexes. In this chapter, we focus on the core AADLstandard (SAE AS5506) and the Behavior Annex.

This chapter gives a brief introduction of AADL language. First, an overview ofAADL standard is given in Section 2.1. The meta-model, model representations andavailable toolsets are introduced. Then section 2.2 presents the core components consid-ered in this thesis. The components are separated into three distinct sets of categories:software, execution platform and system components. For a complete system specifica-tion, the system binding (section 2.3), component communication (section 2.4) are takeninto consideration. The Behavior Annex, which is an extension of the core standard tooffer a way to specify the local functional behavior of the components, is presented inSection 2.5. The behaviors described in this annex are seen as specifications of the actualbehaviors. They are based on state variables, whose evolution is specified by the tran-sitions. ARINC specification is dedicated to provide a general interface with the set ofbasic services to access the operating-system and other system-specific resources. Thesecond version of AADL standard includes an ARINC653 annex (not complete) involv-ing a definition of ARINC653 architectural elements in AADL. A brief introduction ofIMA architecture and ARINC653 standard is given in Section 2.6.

2.1 AADL language abstractions

2.1.1 The SAE AADL standard

The SAE AADL is a standard that has been developed for embedded real-time safetycritical systems, which will support the use of various formal approaches to analyze theimpact of the composition of systems from hardware and software.

In 2001, MetaH [158, 107] has been taken as the basis of a standardization effort, aim-ing to define an Avionics Architecture Description Language standard. The first AADLstandard was released in 2004, named AS5506. AADL version 2 was published in January2009. This version introduces virtual processor and virtual bus components, in supportof partitions, virtual channels and protocol stacks. Other improvements include abstractcomponents, classifier parameterization, and component multiplicity to better support ar-chitecture patterns for system families and reference architectures as well as scaling tolarge-scale systems [40]. The main basic components remain the same. Our work onlytake these components in consideration.

An AADL specification describes the software, hardware, and system part of an em-bedded real-time system. It defines a system by describing jointly software and hardware

44

2.1. AADL LANGUAGE ABSTRACTIONS

components and their interactions. The language can also be used to describe the dynamicbehavior of the runtime architecture by providing support to model operational modes andmode transitions.

While the core language provides a number of modeling concepts with precise se-mantics including the mapping to execution platforms and the specification of executiontime behavior, it is not possible to foresee all possible architecture analysis. The languageis designed to be extensible to accommodate analysis of the runtime architectures thatthe core language does not completely support. The objective is to be able to performvarious analysis (schedulability, sizing analysis, safety analysis) very early in the devel-opment process. Such extensions will be defined as part of a new Annex appended to thestandard. The SAE AADL standard consists of a suite of documents: the core languagestandard (AS5506) and a series of annexes, such as Error Model Annex, Behavior Annex,etc., listed in Figure 2.1.

SAE AADL standardAS5506

Behavior Annex

Graphical AADL Notation AnnexAADL Meta Model and XMI Interchange Formats AnnexLanguage Compliance and Application Program Interface Annex

Error Model Annex

UML Profile for AADL Annex

Figure 2.1: AADL core standard and annexes

The Behavior Annex enables the expression of high level composition concepts. Thebehaviors described in this annex are seen as specifications of the actual behaviors. Theyare based on state variables whose evolution is specified by the transitions expressed inthe behavioral annex.

2.1.2 AADL meta-model and models

The AADL is a textual and graphical language used to model and analyze the softwareand hardware architecture of embedded systems. It is used to describe the structure ofcomponent-based systems as an assembly of software components mapped onto an exe-cution platform, and specially targets real-time embedded systems.

The AADL meta-model defines the structure of AADL models. This meta-modelis represented as a set of class diagrams with additional EMF-specific properties, thatsupport the automatic generation of methods for manipulation of AADL object models.

45


AADL defines seven EMF Ecore meta-model packages: core, component, feature, con-nection, flow, instance and property.

An object representation of AADL specification corresponds to a semantically deco-rated abstract syntax tree. This object representation of AADL model can be persistentlystored as XML format. An AADL model can also be represented as textual code modelor graphical model.

Figure 2.2: AADL model representations

Figure 2.2 shows the three model representations and their roles with respect to thetextual and graphical AADL representation:

• A declarative AADL model: AADL specifications in the form of textual represen-tations. Checking the syntax and semantics of the AADL text is done by parsing itand reporting errors.

• An AADL instance model: an arborescent hierarchic representation of the system,its components and subcomponents, whose root is a system implementation. Itdefines an abstract syntax tree. It can be converted to XML representation.

• A graphical model: graphical display of AADL models. The diagram representationgives a more intuitive view of the model.

2.1.3 AADL open source tools

OSATE [18] (Open Source AADL Tool Environment) was developed in the Eclipseframework, providing the standardized XML definitions for use by Eclipse AADL plug-in analysis or interfacing with external toolsets. The current OSATE1.5 is based on thefirst AADL standard version. It permits creating AADL textual specifications (.aadl files,shown in Figure 2.3) and XML-related object models (.aaxl files, shown in Figure 2.4).

Figure 2.3 is a textual AADL file example. The textual specification is a readable col-lection of textual declarations that comply with the AADL standard. The editor includes a

46

2.1. AADL LANGUAGE ABSTRACTIONS

Figure 2.3: AADL textual model representation

Figure 2.4: AADL object model representation

47


parser to verify the syntax and semantic aspects of the specification. The keywords, suchas system implementation, subcomponents, features and data port, are reserved.

Figure 2.4 represents an XML-related object model (.aaxl file), which can be generatedby converting from the (.aadl) text file. The AADL object editor allows viewing thesystem instance hierarchy through the declarative AADL model. Subcomponents can berecursively expanded into the corresponding component implementation referenced bythe subcomponent.

An AADL graphical editor is provided by the ADELE Eclipse plug-in environment,see figure 2.5. The top-level diagram represents a library of component declarations.Each component implementation has its own instance diagram. Here we present a generalsystem to give a first impression. A flow starts from Device1 and sinks in Device2 throughtwo process instances: ProcessA and ProcessP. The two processes are hosted on twodifferent processors, (the allocation information is specified in the properties). The devicescommunicate via a bus Bus1. We will present the components in detail in the followingsubsections.

Figure 2.5: AADL graphical model representation

We also list some other AADL open source toolsets:

• TOPCASED [29]: develops a meta-modeling framework.

• OCARINA [15]: develops an AADL graphics toolset.

• CHEDDAR [8]: advanced scheduling analysis toolset.

• GME [104]: AADL architecture specification and safety analysis framework.

2.2 Summary of the core AADL components

AADL supports the modeling of application software components, execution platformcomponents and the binding of software onto execution platform. To model complex

48

2.2. SUMMARY OF THE CORE AADL COMPONENTS

embedded systems, AADL provides three distinct sets of component categories: software,execution and composite component.

• Data, subprograms, threads, and processes collectively represent application soft-ware, they are called software components.

• Execution platform components support the execution of threads, the storage of dataand code, and the communication between threads.

• Systems are called composite components. They permit software and executionplatform components to be organized into hierarchical structures with well-definedinterfaces.

Type and implementation AADL components are defined through type and implemen-tation declarations.

A component type represents the functional interface of the component and externallyobservable attributes.

The implementation describes the contents of the component, specifies an internalstructure in terms of subcomponents, connections between the features of those subcom-ponents, flows across a sequence of subcomponents, modes to represent operational statesand properties. Following is a partial code from a real example (Appendix A), showing atype and implementation declaration of a periodic thread door_handler.

thread door_handler

features

in_flight: in data port;

cll: out data port;

end door_handler;

thread implementation door_handler.impl

properties

Dispatch_Protocol => Periodic;

Period => 50 ms;

end door_handler.impl;

AADL allows multiple implementations to be declared with the same functional inter-face, that is to say, each type may be associated with zero, one or more implementations.

Components may be hierarchically decomposed into collections or assemblies of in-teracting subcomponents. A subcomponent declares a component that is contained inanother component. A component implementation can contain arrays of subcomponents.A subcomponent names a component type and component implementation to specify aninterface and implementation for the subcomponent. Thus, component types and imple-mentations act as component classifiers. The hierarchy of a system instance is based uponthe set of subcomponents of the top-level system implementation. It is completed by it-eratively traversing the tree of the component classifiers specified starting at the top-levelsystem implementation subcomponents.

49


Features A feature specifies the interaction points with other components, includingthe inputs and accesses required by the component, and all the outputs and items thecomponent provides. Features are specified in the component type. In the above example,two ports in_flight and cll are declared as in and out data port respectively in the featuresclause.

Properties A property specifies properties of the component that apply to all instancesof this component, unless overwritten in implementations or extensions. Properties can beassigned values through property association declarations. They can be defined either incomponent type or implementation. If they are specified in the component type, then theimplementations of the type will inherit all the properties. In the above thread implemen-tation door_handler.impl example, two properties are defined: Dispatch_Protocol andPeriod, and associated values are given: Periodic and 50ms.

2.2.1 Software components

AADL has the following categories of software components: process, thread, threadgroup, subprogram and data.

2.2.1.1 Process

The process abstraction represents a protected virtual address space, a space partitioningunit where protection is provided from other components accessing anything inside theprocess.

The virtual address space contains the program formed by the source text associatedwith the process and its subcomponents. Three subcomponent categories are allowed:thread, thread group and data. Table 2.1 summarizes the permitted type declaration andimplementation declaration elements of a process. A process can only be a subcomponentof a system component. A complete implementation of a process must contain at least oneexplicitly declared thread or thread group subcomponent.

Category Type ImplementationFeatures : Subcomponents :• server subprogram • data• provides/requires data access • thread (group)

process Flow specifications: yes Connections: yesProperties: yes Modes: yesModes: yes Properties: yes

Table 2.1: Summary of Permitted Process Declarations

Figure 2.6 presents an example of process called pcs. The process implementationpcs.impl contains two subcomponents: thsnd and thrcv, and three types of connections(event port, event data port and data port connections).

50


Figure 2.6: Example of AADL thread and process

2.2.1.2 Thread

A thread represents a sequential flow of control that executes instructions within a binaryimage produced from source text. A thread always executes within the virtual addressspace of a process, and it models a schedulable unit that transits between various schedul-ing states. Multiple threads model concurrent executions of tasks. A scheduler managesthe execution of threads. A generic semantics for a thread is defined based on automata.

An example can be seen in Figure 2.6 (right part). Two threads are given in thisexample: thsnd and thrcv. The thread type gives the interaction interface: for example,dr1 is declared as in event port, ds1 as out event data port. The detailed implementationis not shown.

Table 2.2 summarizes the legal type and implementation declarations for a thread.

Category Type ImplementationFeatures : Subcomponents :• port (group) • data• provides/ requires data access • subprogram (group)

thread • provides/ requires subprogram access Subprogram calls: yes• provides/ requires subprogram group access Flows: yesFlow specifications: yes Connections: yesProperties: yes Modes: yesModes: yes Properties: yes

Table 2.2: Summary of Permitted Thread Subclause Declarations

Timing domain Three events (td, ts, t f ) are associated with each thread t. The event td

indicates when the thread is dispatched, ts represents a signal at which the thread starts,and t f is the one at which the thread finishes.

Thread dispatching The Dispatch_Protocol property of a thread determines the char-acteristics of dispatch requests to the thread. The supported dispatch protocols are: peri-

51


odic, aperiodic, sporadic and background.

1. Periodic: repeated dispatches occurring at a specified time interval. A dispatchrequest is issued at the beginning (td) of time intervals specified by Period propertyvalue. The period value is the thread period.

T1ST1fT2ST2f

T1dT2d

dispatch start completeFigure 2.7: Periodic thread clock relations.

Figure 2.7 represents the execution of two synchronized periodic threads (T1 and T2)in the absence of preemption or other interruptions (events, abort, call subprograms,get resource, exit (mode), etc.). The two threads do not have the same period, butshare simultaneous dispatch (every three T1 or every two T2, the two threads aredispatched at the same time).

2. Aperiodic: event-triggered dispatch of threads. A dispatch request is the result ofan event or event data arriving at an event or event data port of the thread, or aremote subprogram call arriving at a provides subprogram access feature of thethread. There is no constraint on the inter-arrival time of events, event data orremote subprogram calls.

T1ST1fT2ST2f

start completeFigure 2.8: Aperiodic threads clock relations.

An aperiodic thread is event-triggered. Figure 2.8 illustrates the alternation rela-tions. In this example, the termination of T1 asynchronously triggers the start ofT2.

3. Sporadic: event-driven dispatch of threads with a minimum dispatch separation.A dispatch request is the result of an event or event data arriving at an event orevent data port of the thread, or a remote subprogram call arriving at a provides

subprogram access feature of the thread. The time interval between successivedispatch requests will never be less than the associated Period property value.

52


4. Background: a dispatch initiated once with execution until completion. A back-ground thread is scheduled to execute when all other threads’ timing requirementsare met. If more than one background thread is dispatched, the processor’s schedul-ing protocol determines how such background threads are scheduled.

Thread states and actions Figure 2.9 shows the state transitions of thread executionunder normal operation.

Thread halted

Initialization

Suspended awaiting mode

Activation

Suspended awaiting dispatch

Computation

Finalize Deactivation

loaded(process)

complete activation

dispatch complete

thread abort thread unrecoverable error detected

started systeminitial mode

enter modestop(process,processor, system)

stopped (process)

exit mode

complete deactivation

abort (process, system, processor)

stop(process,processor, system)

stop(process,processor, system)

thread unrecoverable error detected

abort (process, system, processor)

thread exit modethread enter mode

Figure 2.9: Thread states and actions

All threads start from the initial state: thread halted. When the loading of the vir-tual address space as declared by the enclosing process completes, a thread is initializedby performing an initialization code sequence in the source text. Once initialization iscompleted, the thread enters the suspended awaiting mode state, if the thread is not inthe initial mode, otherwise, it enters the suspended awaiting dispatch state. When in thesuspended awaiting dispatch state, a thread is awaiting a dispatch request for performingthe execution.

Thread scheduling and execution A thread is provided with a priority given in associ-ated property field, which is determined by the chosen scheduling policy. When a systemis started, all threads are in a halted state. They are initialized and enter in the await-ing state, waiting for activation. The scheduler manages the activation of the threads. Itchooses a thread with highest priority from the ready threads. The selected thread startsrunning. After its completion, it returns to the awaiting state.

53


When a thread is in computation state (see the bottom of Figure 2.9, here we give amore detailed description of the computation state), the execution of the thread’s entry-point source text code sequence is managed by a scheduler. The scheduler coordinatesall thread executions on one processor as well as concurrent access to shared resources.While executing an entrypoint, a thread can be in one of the five substates: ready, run-ning, awaiting resource, awaiting return, and awaiting resume (in Figure 2.10).

ready running

awaitingresource

awaitingreturn

Computationresumepreempt

call serversubprogram

return server subprogram

block

unblock

Dispatch complete

suspended awaiting dispatch

awaitingresume

abort (process, processor, system) thread unrecoverable

error detected

backgoundexit mode

backgoundenter mode

Figure 2.10: Thread Scheduling States

A thread initially enters the ready state. The thread in the ready state that has themaximum priority starts or continues its execution. It ensures that only one thread is inthe running state on a particular processor. If no thread is in the ready state, the processoris idle until a thread enters the ready state.

A thread will remain in the running state until it completes execution of the dispatch,or until a thread entering the ready state preempts it if the specified scheduling protocolprescribes preemption, or until it blocks on a shared resource, or until an error occurs. Inthe case of completion, the thread goes back to the suspended awaiting dispatch state(described in Figure 2.9), ready to waiting for another dispatch request. In the case ofpreemption, the thread returns to the ready state. In the case of resource blocking, thethread transits to the awaiting resource state.

2.2.1.3 Thread group

A thread group represents an organizational component to logically group threads con-tained in processes. The type of a thread group component specifies the features andrequired subcomponent access through which threads contained in a thread group interactwith components outside the thread group. Thread group implementations represent thecontained threads and their connectivity.

54


2.2.1.4 Data

Data represent static data and data types within a system. Figure 2.11 contains textual(left) and corresponding graphical (right) declaration of a substructure of a data. Thesubstructure of the data implementation Person.impl consists of four data subcomponents:name, surname, age and gender. They are typed by AADL basic type string, int and anenumerated type Gender.

Person.implname

surname

age

gender

Figure 2.11: Sample data component text and graphical representations

2.2.1.5 Subprogram

A subprogram component represents sequentially executed source text that is called withparameter. Subprograms can be called from threads and from other subprograms. Thesecalls are sequential calls local to the virtual address space of the thread. Ordering of sub-program calls is by default determined by the order of the subprogram call declarations.

2.2.2 Execution platform components

This subsection describes a subset of execution platform components: processor, deviceand bus. Execution platform components can represent high-level abstractions of phys-ical and computing components. A detailed AADL model of their implementation canbe represented by system implementations that are associated with the execution platformcomponent.The AADL describes interfaces and properties of execution platform com-ponents including processor, memory, communication channels, and devices interfacingwith the external environment. Detailed designs for such hardware components may bespecified by associating source text written in a hardware description language such asVHDL.

2.2.2.1 Processor

A processor is an abstraction of hardware and associated software that is responsible forscheduling and executing threads. It may have port, port group and bus access features,and its implementation may have memory as its subcomponents. Figure 2.12 shows bothtextual and graphical representations of a processor, with a memory subcomponent con-tained.

55


Figure 2.12: Sample processor component text and graphical representations

2.2.2.2 Device

Device abstractions represent entities that interface with the external environment of anapplication system. A device may represent a physical entity or its software equivalent.Devices are logically connected to application software components and “physically” con-nected to processors.

A device can be viewed to be a primary part of either the application system or theexecution platform. Examples of devices are sensors and actuators that interface with theexternal physical world.

Figure 2.13: A sample device specification

A device interacts with both execution platform components and application softwarecomponents. It has physical connections to processors via bus access connections. Thismodels software executing on a processor accessing the physical device. The logical con-nections are represented by connection declarations between device ports and applicationsoftware component ports.

Figure 2.13 shows an excerpt from an AADL specification that describes a deviceRDC interacting through a bus AFDX with a processor CPIOM. The requirement for busaccess is specified in the type declaration for RDC. Similarly, the need for bus access isdeclared within the processor type declaration for CPIOM. Notice that the out data portdeclared on the sensor device provides the rate data.

56


2.2.2.3 Bus

A bus represents hardware and associated communication protocols that enable interac-tions among other execution platform components. This communication is specified usingaccess and binding declaration to a bus.

In the example of Figure 2.13, there are a bus type declaration (AFDX), a processortype declaration (CPIOM) and a device type declaration (RDC). Both the CPIOM proces-sor and the RDC device declare a requires bus access of bus AFDX. They are connectedby the bus AFDX.

We give a simple implementation of the bus AFDX. A property Transmission_Time

is given. A bus implementation must not contain a connection, flow or subprogram callsubclause. It can only have properties or mode declarations.

bus AFDX

end AFDX;

bus implementation AFDX.impl

properties

Transmission_Time => 1 ms .. 2 ms;

end AFDX.impl;

2.2.2.4 Memory

Memory represents storage components for data and executable code. Memory com-ponent consists of randomly accessible physical storage (i.e., RAM, ROM) or complexpermanent storage (e.g., disks, reflective memory). Since they have a physical runtimepresence, memory components have properties such as word size and word count.

memory RAM

features

bus1: requires bus access X_1553;

properties

Word_Size: Size => 8 bits;

end RAM;

bus X_1553

end X_1553;

In the example of Figure 2.12, there is a memory type declaraion: RAM. A moredetailed declaration of the type RAM is given here with a feature bus1 that establishesthat all instances of RAM require access to the bus X_1553, and a property Word_Size

that specifies the size of the smallest independently readable and writable unit of storagein the memory.

Since memory is related to the physical storage, we do not translate it in Signal, butleave it to be used in the simulation phase.

2.2.2.5 Virtual processor

A virtual processor represents a virtual machine or hierarchical scheduler. Threads canbe bound to virtual processors, and a virtual processor must be bound to or must be asubcomponent of a processor.

57


2.2.2.6 Virtual bus

A virtual bus represents virtual channel or communication protocol that performs trans-mission within processors or across buses. Virtual buses can be contained in or boundto processors and buses. Virtual buses within a processor support connections betweencomponents on the same processor. Virtual buses on buses support connections betweencomponents across processors.

Virtual processor and virtual bus are two new components introduced in AADLv2.0.These two components are not taken into account in our work.

2.2.3 System component

A system represents an assembly of software, execution platform, and system compo-nents. Systems may require access to data and bus components declared outside the sys-tem, and may provide access to data and bus components declared within it. Systems maybe hierarchically nested.

A system instance represents the runtime architecture of an operational physical sys-tem. It consists of application software components and execution platform components.Component type and component implementation declarations must be instantiated to cre-ate a complete system instance. A system instance that represents the containment hierar-chy of the physical system is created by instantiating a top-level system implementationand then recursively instantiating the subcomponents and their subcomponents.

Figure 2.14: A sample system specification: textual and graphical

58

2.3. SYSTEM BINDING

The composition of a system implementation is declared through subcomponents.Figure 2.14 provides both textual and graphical representations of a system inte-

grated_control. The details of the type declarations are not included. The explicit sub-component declarations are shown in the system implementation. It consists of a processcontrol_process, a data set_point_data, a sub system navigation_system, a processorreal_time_processor, a memory hs_memory and a bus high_speed_bus. The supportingsubcomponent type or implementation declarations are not shown. In the graphical viewof the system implementation, the subcomponents of integrated_control_system of thetype integrated_control are shown.

2.3 System binding

For a complete system specification, the application component instances must be boundto appropriate execution platform components. The decisions and methods required tocombine the components of a system to produce a physical system implementation arecollectively called binding. For example, threads must be bound to processing elements,and processes must be bound to memory. Similarly, interprocessor connections must bebound to buses. These bindings are defined through property associations.

Binding properties are declared in the system implementation that contains in its con-tainment hierarchy both the components to be bound and the execution platform compo-nents that are the target of the binding.

There are three categories of binding properties that provide support for: allowed

bindings, actual bindings and identified available memory and processor resources.

Figure 2.15: Textual example of system binding

A set of properties are predeclared in the property set AADL_Properties, which is partof AADL specification. In this section, we only list three properties that will be used

59


in our transformation. The others can be referenced to in Appendix A of SAE AS5506standard.

• The Allowed_Processor_Binding property specifies the set of processors that areavailable for binding.

• A thread is bound to the processor specified by the Actual_Processor_Binding prop-erty. The process of binding threads to processors determines the value of this prop-erty. If there is more than one processor listed, a scheduler will dynamically assignthe thread to one at a time.

• Connections are bound to the bus, processor or device specified by the Ac-

tual_Connection_Binding property.

Figure 2.15 shows a textual example of system binding. The Al-

lowed_Processor_Binding property declares that processors cpiom1, cpiom2 areavailable for thread pa.ta, and processor cpiom1 is available for thread pa.tb.Thread ta of Process pa is actually bound to processor cpiom2 specified by theActual_Processor_Binding property.

2.4 Component interaction

The interactions among components represent the connections established between in-terface elements at runtime. Connections establish one of the following interactions:port connections which are explicit relationship declared between ports or between portgroups, component access connections that access to a common data or bus component,subprogram calls, and parameter connections. In this thesis, we mainly take into accountthe port connections among components.

2.4.1 Port

A port represents a communication interface for the directional exchange of data, eventor both event data between components. Three types of ports are defined in AADLstandard:

• Data port: interface without queuing.

• Event port: interface for the communication of event that may be queued.

• Event data port: interface for message transmission with queuing.

The port properties: Queue_Size, Queue_Processing_Protocol, and Over-

flow_Handling_Protocol specify queue characteristics of the event or event data ports.If an event arrives and the number of queued events (and any associated data) is morethan the specified queue size, the Overflow_Handling_Protocol property determines theaction. If the property value is Error, an error is emitted. If the property value is set to beDropNewest or DropOldest, the newly arrived or oldest event in the queue is dropped.

60

2.4. COMPONENT INTERACTION

a) b)

Figure 2.16: Port graphical representation

The graphical representations of data port, event port and event data port are summa-rized in Figure 2.16 (a).

Ports are declared as features in component type declarations. They are directional,and can be specified as in, out or inout (Figure 2.16 (b)).

2.4.2 Port connection

Port connections are explicit relationships declared between ports or between port groupsthat enable the directional exchange of data and events among components. Connec-tion declarations between ports are shown in Figure 2.17. For example, the connec-tion data_con is between the out data port data_out of the process compute (writtenas compute.data_out) and the in data port data_in of the process control (written as con-

trol.data_in). The connection control_con connects the out data port control_out of theprocess control to the in data port control_in of the process compute.

A port can be the source of more than one port connection, but a port cannot be thedestination of more than one port connection, which means that a source port can connectto several destination ports, but the destination port has only one source port.

The type of connection between thread data ports establishes specific timing semanticsfor data that are transferred between originating and terminating threads.

AADL provides two types of data port communication mechanisms between threads:immediate and delayed connections. These two connections can only be applied to peri-odic threads.

Immediate connection For immediate port connections (data port x → y), data trans-mission is initiated when the source thread completes and enters the suspended state.

Immediate connections execution orders are illustrated in Figure 2.18. The sendingand receiving threads (T1 and T2) must share a common (multiple simultaneous) dispatch.The value provided to the receiving thread T2 is the value produced by T1 at its last recentexecution. In Figure 2.18(a), the sending thread T1 is dispatched at a higher frequency thanthe receiving thread T2. The execution of T2 is delayed until T1 has completed. In suchan under-sampling case, the third value produced by T1 is ignored, since in an immediateconnection, the sender always communicates with the receiver in the same dispatch frame.In Figure 2.18(b), the receiving thread T2 is dispatched at a higher frequency than thesending thread T1. In this case, the values available for the first two sequential executionsof T2 are the same: the value produced by the first execution of T1.

61


Figure 2.17: Sample declaration of port connection

T1T2

T1T2

a) under-sampling with immediate connections

b) over-sampling with immediate connections

T1 dispatch T2 dispatch

Figure 2.18: Immediate connection execution order

Delayed connection For delayed port connections (data port x ։ y), the value fromthe sending thread is transmitted at its deadline, and is available to the receiving thread atits next dispatch.

In case of delayed connection, the value that the receiving thread receives is the outputat the most recent deadline of the sending thread. Figure 2.19 shows the delayed connec-tion execution order in case of under-sampling and over-sampling. In Figure 2.19(a), anunder-sampling case is shown: the data provided to the receiving thread T2 is the value

62

2.5. FLOWS

T1T2

T1T2

a) under-sampling with delayed connecti ons

b) over-sampling wit h delayed connectio ns

T1 dispatch T2 dispatch T1 deadline

Figure 2.19: Delayed connection execution order

produced by T1 that is available at its deadline before the dispatch of T2. In Figure 2.19(b),the receiving thread T2 is dispatched at a higher frequency than the sending thread T1. Inthis case, the values available for the second and third sequential executions of T2 are thesame: the value produced by the first execution of T1, because the value produced by thesecond execution of T1 is not available for the third dispatch of T2.

2.5 Flows

Flows describe externally observable flow of information in terms of application logicthrough a component. Flows describe actual flow sequences through components and setsof components across one or more connections. Flows specification enables the detaileddescription and analysis of an abstract information path through a system. The specifica-tion of an end-to-end flow involves the declaration of the elements of the flow (sources,sinks and paths), and explicit implementation declarations that describe the details of acomplete path through the system. A flow can involve port connections in its specifica-tion declaration.

Flows are directional. Within a component implementation, flow declarations definethe details of:

• Flow path through a component. A flow path through a component consists of alter-nation sequences of paths through and connections among subcomponents withinthe component.

Figure 2.20 is a graphical representation of the flow path. It shows the flows im-plementation declarations through the component cruise_control. The flow im-plementation originates at the brake_event event data port, and sinks in the dataport throttle_setting. The flow involves the connections C1, C3 and C5 within thecomponent implementation, as well as the paths through the subcomponents of thatimplementation. Partial code specification of this flow path is shown:

flows

brake_flow: flow path brake_event -> C1 ->

63


drake_event throttle_setting

flow pathin_flow1 flow path

laws_flow1

Figure 2.20: Flow path through a component

data_in.in_flow1 -> C3 -> control_laws.laws_flow1

-> C5 -> throttle_setting;

• End-to-end flows within a component. An end-to-end flow within a componentinvolves the declaration of a path from a flow source to a flow sink within the com-ponent.

Figure 2.21: An end-to-end flow within a component

Figure 2.21 illustrates this type of declaration: an end-to-end flow is defined be-tween the source Flow1 in the device component brake_pedal, and the sink Flow1

in the device component throttle_actuator. Partial code specification of this end-to-end flow is illustrated:

flows

brake_flow: end to end flow brake_pedal.Flow1 -> C1 ->

cruise_control.brake_flow -> C2 -> throttle_actuator.Flow1;

2.6 AADL behavior annex

The AADL Behavior Annex [74] is an extension of the core of the standard to offer away to specify the local functional behavior of the components. It supports describingprecisely the behaviors, such as port communication, computation, timing, etc.

A Behavior Annex can be attached to a thread or a subprogram: threads or subpro-grams start from an initial state, and a transition to a complete (resp. return) state ends athread (resp. subprogram). Transitions may be guarded by conditions, and actions maybe attached.

64

2.7. AVIONICS SYSTEM ARCHITECTURE AND ARINC653

Figure 2.22: Behavior Annex example

The example presented in Figure 2.22 is a behavior specification of a door_handler

thread from a SDSCS (Simplified Doors and Slides Control System) [109]. It comprisestwo transitions with an initial state s0 which is also a complete state. The thread willexecute the transitions depending on the guarded conditions. Take the first transition forinstance, when the guard condition (on (dps > 3) and handle) is satisfied, it is triggered,the attached actions (two assignments and a condition action) are executed. When theexecution finishes, it will enter back to the state s0.

In this section, we only give a brief introduction of the AADL behavior annex. Thedetailed semantics of transitions and actions will be described in Chapter 6.

2.7 Avionics system architecture and ARINC653

The second version of AADL standard is defining the ARINC653 architectural elementsin AADL architecture, included in ARINC653 annex (but not completed yet). In thissection, we will give an overview of the ARINC653 standard. First, a brief introductionof avionics system architecture is presented.

2.7.1 Avionics system architecture overview

In the field of avionics, increasing complexity and high criticality of embedded real-timesystems are a number of challenges relating to their development. These challenges in-clude the correct system design, the development effort, the system reliability, and the timeof placing the “product” on the market. Thus there is a great need to design methodolo-gies that take into account the mentioned challenges. Such methodologies must includeformal specifications, to make possible verification and analysis. On the other hand, theautomatic generation of code (possibly distributed) should also be possible.

In this section, we will introduce some concepts of avionics systems. Two archi-tectures in avionic systems are presented: the Federated architecture and the Integrated

Modular Avionics architecture.

65


2.7.1.1 Federated architecture

Traditionally, avionics functions are implemented such that each function has its dedi-cated fault-tolerant computer system. This architecture is called federated [143]. A greatadvantage of such an architecture is fault containment. However, there is a potential riskof massive usage of computing resources, since each function may require its dedicatedcomputer. As a result, maintenance costs may increase rapidly.

2.7.1.2 Integrated Modular Avionics architecture

Advances in the computer technology encouraged the avionics industry to deal with ma-jor obstacles in federated architecture, with an integrated suite of control modules thatshare the computing resources. The new approach, which is called Integrated Modular

Avionics (IMA) [39], introduces methods that can achieve high levels of reusability andcost effectiveness.

Figure 2.23: IMA: different functions can share a fault-tolerant computer

A main feature in a IMA architecture is that several avionics applications can be hostedon a single, shared computer system (Figure 2.23). They are guaranteed a safe staticallocation of shared resources, so that no fault propagation occurs from one component toanother one. This is addressed through a functional partitioning of the applications withrespect to available time and memory resources [37].

The avionics standard ARINC defines the basic principles of partitioning and a set ofservices, following the IMA architecture.

2.7.2 ARINC standard

In this section, we will present the notions defined in document 653 by the ARINC stan-dard, which follows the IMA architecture.

A partition is a logical allocation unit resulting from a functional decomposition ofthe system. IMA platforms consist of a number of modules grouped in cabinets through-out the aircraft. A module can contain several partitions that possibly belong to functionsof different criticality levels. Any memory access outside of a partition’s defined area isprohibited. The processor is allocated to each partition for a fixed time window within a

66


major time frame. Partitions are composed of processes which represent the basic execu-tion units. Processes in a partition share the resources allocated to the partition, and canbe executed concurrently with other processes of the same partition [87].

The ARINC653 specification [37] is dedicated to provide a general interface with theset of basic services to access the operating system and other system-specific resources.This interface, called APEX (APplication-EXecutive), presented in Figure 2.24, providesthe execution control of the partitions, including the communication between them. It isconstituted of a set of services that are called APEX services.

partition 1 partition 2 partition 3

Operating System(logical communication, exception handling, partitioning, scheduler, health monitor)

Hardware Interface System(memory management, physical communication, device handler, context switching, interrupt handler, BIT)

Hardware(communication media, interrupt controller, MMU, clock, BITE)

APEX

COEX

Figure 2.24: Software architecture for IMA system

The IMA software architecture consists of hardware interface system, operating sys-tem and application software, as shown in Figure 2.24. Combined with the hardware, thehardware interface system forms a core module to support operating system and applica-tion execution via the COEX (COre-EXecutive) interface. The operating system executiveimplements a set of services defined in the APEX interface, such that application softwarecan use the system resources and control the scheduling and communication.

2.7.2.1 Partition

Central to the IMA philosophy is the concept of partitioning, where the functions residenton a core module are partitioned with respect to space and time. A partition representssuch a unit of the application designed to satisfy these constraints. It is characterized bysome unique attributes, such as configuration and context. These information are used tomanage the partitions within a module.

Partition management The core module OS is responsible for enforcing partitioningand managing the individual partitions within that core module.

A processor is allocated to each partition for a fixed time window within a major timeframe maintained by the module-level OS. In other words, through a predefined configu-

67


ration table of partition windows, the APEX imposes a cyclic scheduling to ensure thateach partition receives a fixed amount of processing time.

The order of partition activation is defined at configuration time using configurationtables. This provides a deterministic scheduling methodology, where the partitions arefurnished with a predetermined amount of time to access processor resources. Timingpartitioning therefore ensures each partition uninterrupted access to common resourcesduring their assigned time periods.

Each partition has predetermined areas of memory allocated to it. These unique mem-ory spaces are identified based upon the requirements of the individual partitions, and varyin size and access rights. Memory partitioning is ensured by prohibiting memory accessesoutside of a partition’s defined memory area.

Partition communication A partition cannot be distributed over multiple processors,neither in the same module nor in different modules. Suitable mechanisms and devicesare provided for communication between partitions.

The basic mechanisms for linking partitions are logical ports and channels. A channeldefines a logical link between one source and one or more destination partitions. Partitionshave access to channels via defined access points, called ports. Each individual channelmay be configured to operate in a specific mode: sampling mode or queuing mode. Noqueuing is performed in the former mode: a message remains in the source port, until it istransmitted via the channel, or it is overwritten. In the queuing mode, ports are allowed tostore messages from a source partition in queues, until they are received by the destinationpartition. No messages will be lost in this mode. The queuing discipline for messages isbounded First-In First-Out (FIFO).

Process 1

Process 2

Process 3

Partition 1Process 1

Process 2

Process 1

Partition 2

Partition 3semaphore

buffer

blackboard

ports

channels

Module_level_OS 1

Module_level_OS 2

Partition_level_OS 1



Module 1 Module 2

processor1 processor2

Figure 2.25: An example of IMA application partitioning

Figure 2.25 describes an application executed on two processors. It consists of threepartitions: partition 1, partition 2 and partition 3. The first partition executes on the first

68


processor, the other two share the second processor. Each partition comprises processes.We will present the process and its characteristics in the next subsection.

2.7.2.2 Process

Within each application partition, the basic execution unit is a process. Processes in a par-tition share the resources allocated to the partition, and can be executed concurrently withother processes of the same partition. When a partition is activated, its owned processesrun concurrently to perform the functions associated with the partition.

Process management Each process is uniquely characterized by information useful tothe partition-level OS, which is responsible for the correct execution of processes withina partition.

The scheduling algorithm within each partition is priority preemptive. At any processrescheduling event, the scheduler always selects the highest priority process in the readystate to receive processor resources. That process will control processor resources untilanother process reschedule event occurs.

Process communication Communication mechanisms between processes are buffer

and blackboard, which can support the communication of a single message type betweenmultiple source and destination processes. The communication is indirect, in that the par-ticipating processes address the buffer or blackboard rather than the opposing processesdirectly, thus providing a level of process independence.

• The bounded buffer allows to send and receive messages following a FIFO order.Each new instance of a message may carry uniquely different data and is not allowedto overwrite previous ones during the transfer. No message should be lost.

• The blackboard is used to display and read message. No message queuing is al-lowed. Any message written to a blackboard remains there, until it is either cleared,or overwritten by a new instance of the message. This allows processes to displaymessages at any time, and processes to access the latest message at any time.

Inter-process synchronization is achieved by semaphore and event. The event permitsthe application to notify some processes in the partition of the occurrence of a condition.

2.7.3 AADL and ARINC

ARINC653 is an avionics standard following the IMA architecture. AADL can be usedfor ARINC653 modeling, e.g., processes as partitions. In this section, we list some simi-larities between the two.

A main feature of ARINC653 is the partitioning: several avionics applications (pro-

cesses) can be hosted on a single partition. They can share the resources in this partition,but have no right to access the resources in other partitions. The feature is similar toAADL process. The AADL process represents a protected address space, a space par-titioning where protection is provided from other components accessing anything inside

69


the process. Hence, both the ARINC partition and AADL process have a “partitioning”application.

The communication mechanisms defined in ARINC support both queuing and no-queuing message communication. This is similar to the AADL connection. The differenceis that ARINC does not take into account the hardware bus connection between differentcomponents.

The ARINC scheduling mechanism can also be used as a targeted operating systemof AADL. The difficulty is that the scheduling in ARINC653 is divided in two levels:the module_level_OS and partition_level_OS. The former one is a static scheduling: themodules are scheduled based on a predefined configuration table. However, the parti-

tion_level_OS is still suitable for modeling the scheduling of the AADL threads in thesame process.

This utilization needs improvements, which is addressed in AADLv2 as an annex forcommon guidelines for ARINC653 modeling, and extensible to other partitioned archi-tectures.

2.8 AADL components considered in this thesis

In this thesis, we take into account the architecture and functionality aspects of an AADLsystem. The architecture aspects considered in this thesis mainly consist of the basicsoftware components, the hardware for executing and communications, the compositesystem component, and some related properties. The Behavior Annex is considered tospecify the local functional behaviors of the components.

As an architecture description language, AADL can describe the connected compo-nents that form an architecture. A subset of components is considered and implementedin this work: the thread (especially for periodic thread), which is the main executable andschedulable component; the processor, which is responsible for executing and schedul-ing (a specific static scheduler is implemented as an instance); the bus, that representsthe communication execution platform; the process, which is the protected address space;the subprogram, that is the callable server function provider; the data type; the device,which is the external environment inerface; the data/event/event data port, that representsthe communication interface; immediate and delayed data port connections; top-level sys-tem component; and properties related to thread temporal specifications and process al-location information. Each component instance is considered with its associated type orimplementation. The transformation of these components will be presented in Chapter 5.

The functionality of a component specifies its functional behavior when it is in ex-ecution. The behaviors in the Behavior Annex are specified in order to perform modelchecking and advanced code generation. In reason of early system validation and veri-fication, the interpretation of Behavior Annex is considered in this thesis as one of thecontributions in Chapter 6.

2.9 Conclusion

This chapter presented the language AADL, intended for modeling embedded real-timesystem architecture. This language is used to describe the structure of such systems as an

70

2.9. CONCLUSION

assembly of software components that are mapped to an execution platform. It supportsthe modeling of both software and hardware.

The components are presented in three categories: software, execution platform andsystem. The system binding, component interactions, thread scheduling and execution arealso presented for a complete system specification. These notations will be specified indetail and transformed into Signal in Chapter 5. We also give a short introduction of anextensible annex: Behavior Annex. The formal syntax and semantics of Behavior Annexwill be defined in Chapter 6. A brief introduction of the Integrated Modular Avionics(IMA) architecture, and the associated standard ARINC653, is presented then, which isused as a basic framework in our transformation.

71


72

Chapter 3

The Signal Language and modelingARINC in Signal

Contents3.1 Signal language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

3.1.1 Signal, execution, process . . . . . . . . . . . . . . . . . . . . 74

3.1.2 Data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

3.1.3 Elementary processes . . . . . . . . . . . . . . . . . . . . . . . 76

3.1.4 Process operators . . . . . . . . . . . . . . . . . . . . . . . . . 77

3.1.5 Parallel semantic properties . . . . . . . . . . . . . . . . . . . 78

3.1.6 Modularity features . . . . . . . . . . . . . . . . . . . . . . . . 79

3.1.7 Endochronous acyclic processes . . . . . . . . . . . . . . . . . 80

3.1.8 Time domains and communications in Signal . . . . . . . . . . 80

3.1.9 Non-determinism modeling in Signal . . . . . . . . . . . . . . 82

3.1.10 Adequacy of Signal for AADL modeling . . . . . . . . . . . . 83

3.2 Modeling ARINC concepts in Signal . . . . . . . . . . . . . . . . . . 84

3.2.1 Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

3.2.2 Partition-level OS . . . . . . . . . . . . . . . . . . . . . . . . . 85

3.2.3 Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

3.2.4 APEX services . . . . . . . . . . . . . . . . . . . . . . . . . . 87

3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

In this chapter, the synchronous language Signal and its polychronous model of com-putation will be presented, with a description of its syntax and semantics. Since the Signallanguage is used to describe a real world avionic application based on the recent IntegratedModular Avionics concept (IMA), we will also present the modeling of the IMA ARINCcomponents in Signal.

The synchronous approach is one of the possible solutions for a safe design of em-bedded systems. Its mathematical basis provides formal concepts that favor the trusted

CHAPTER 3. SIGNAL LANGUAGE AND MODELING ARINC IN SIGNAL

design of embedded real-time systems. The multi-clock or polychronous model standsout from other synchronous models, by its uniform framework. It allows the design ofsystems, where each component holds its own activation clock, as well as single-clockedsystems in a uniform way. This feature makes the Signal semantics closer to AADL se-mantics than other pure synchronous or asynchronous models. This will facilitate thesystem validation.

The data-flow synchronous Signal language is dedicated to the design of embeddedsystems for critical application domains. The unique features of the relational model be-hind Signal are to provide the notion of polychrony: the capability to describe circuits andsystems with several clocks, and to support refinement—the ability to assist and supportsystem design from the early stages of requirement specification, to the later stages ofsynthesis and deployment.

The IMA architecture is a recently proposed architecture in avionics applications. Inan IMA system, several functions can be grouped into one core module, and are allowedto share the same computer resources. They are guaranteed a safe allocation of sharedresources, so that no fault propagation occurs from one component to another. Avionicsapplications which rely on the avionics standard ARINC653, based on the IMA architec-ture, can be specified in the Signal model. A library of APEX ARINC services is providedin Signal.

The remainder of this section is organized as follows: section 3.1 first introduces theSignal language, and section 3.2 concentrates on the modeling of ARINC concepts inSignal. The modeling of a library of components based on the avionic APEX-ARINCstandard is presented. Finally, conclusions are given.

3.1 Signal language

Signal [110, 111, 112, 49, 113, 89, 60] is a declarative language expressed within the poly-chronous model of computation. Signal relies on a handful of primitive constructs, whichcan be combined using a composition operator. These core constructs are of sufficientexpressive power to derive other constructs for comfort and structuring. In the following,we present the main features of the Signal language and its associated concepts. We givea sketch of the primitive constructs and a few derived constructs often used. For eachof them, the corresponding syntax and definition are mentioned. Since the semantics ofSignal is not the main topic of this thesis, we give simplified definitions of operators. Forfurther detail, interested readers can refer to [115, 58].

3.1.1 Signal, execution, process

A pure signal is a total function T → D, where T , its time domain, is a chain in a partialorder (for instance an increasing sequence of integers) and D is some data type; we namepure flow of such a pure signal s, the sequence of its values in D. In this context, the lackof value is usually represented by nil or null; we represent it by the symbol # (stating for“no event”).

For all chains TT , T ⊂ TT , a pure signal s : T → D can be extended to a synchronized

signal ss : TT → D# (where D# = D ∪ {#}) such that for all t in T , ss(t) = s(t) and

74

3.1. SIGNAL LANGUAGE

ss(t) = # when t is not in T ; where we name synchronized flow of a synchronized signal

ss the sequence of its values in D#; conversely we name pure signal of the synchronized

flow ss, the unique pure signal s from which it is extended and pure flow of ss the pureflow of s. The pure time domain of a synchronized signal is the time domain of its puresignal. Given a pure signal s (respectively, a synchronized signal ss), st (respectively, sst)denotes the tth value of its pure flow (respectively, its synchronized flow).

An execution is the assignment of a tuple of synchronized signals defined on thesame time domain (as synchronized signals), to a tuple of variables. Let TT be thetime domain of an execution, a clock in this execution is a “characteristic function”clk : TT → {#, true}; notice that it is a synchronized signal. The clock of a signal x

in an execution is the (unique) clock that has the same pure time domain as x; it is denotedby x.

A process is a set of executions defined by a system of equations over signals thatspecifies relations between signal values and clocks. A program is a process.

Two signals are said to be synchronous in an execution iff they have the same clock (orequivalenty the same pure time domain in this execution). They are said to be synchronous

in a process (or simply synchronous), iff they are synchronous in all executions of thisprocess.

Consider a given operator which has, for example, two input signals and one outputsignal all being synchronous. They are logically related in the following sense: for any t,the tth token on the first input is evaluated with the tth token on the second input, to producethe tth token on the output. This is precisely the notion of simultaneity. However, for twooccurrences of a given signal, we can say that one is before the other (chronology). Then,for the synchronous approach, an event is associated with a set of logically instantaneousordered calculations and communications.

3.1.2 Data types

A flow is a sequence of values that belong to the same data type. Standard data types suchas Boolean, integer. . . (or more specific ones such as event–see below) are provided in theSignal language. One can also find more sophisticated data types such as sliding window

on a signal, bundles (a structure the fields of which are signals that are not necessarilysynchronous), used to represent union types or signal multiplexing.

1. The event type: to be able to compute on (or to check properties of) clocks, Signalprovides a particular type of signals called event. An event signal is true if andonly if it is present (otherwise, it is #).

2. Signal declaration: tox x declares a signal x whose common element type is tox.Such a declaration is a process that contains all executions that assign to x a signalthe image of which is in the domain denoted by tox.

In the remainder of this chapter, when the type of a signal does not matter or when itis clear from the context, one may omit to mention it.

75


3.1.3 Elementary processes

An elementary process is defined by an equation that associates with a signal variable anexpression built on operators over signals; the arguments of operators can be expressionsand variables.

• Stepwise extensions. Let f be a symbol denoting a n-ary function ~ f � on values(e.g., Boolean, arithmetic or array operation). Then, the Signal expression

y := f(x1,...,xn)

defines the process equal to the set of executions that satisfy:

{

− the signals y, x1, ..., xn are synchronous,− their pure flows have same length l and satisfy ∀t ≤ l, yt = ~ f �(x1t, . . . , xnt)

If f is a function, its stepwise extension is a pure flow function. Infix notation isused for usual operators.

• Delay. This operator defines the signal whose tth element is the (t − 1)th element ofits (pure flow) input, at any instant but the first one, where it takes an initializationvalue. Then, the Signal expression

y := x $ 1 init c


{ −y, x are synchronous,

− pure flows have same length l and satisfy ∀t ≤ l,

{ (t > 1)⇒ yt = xt−1

(t = 1)⇒ yt = c

The delay operator is thus a pure flow function. For short, it can be denoted y:=x$and the initialization can be implicit.

Derived operator

◦ Constant: x := v; when x is present its value is the constant value v; x := vis a derived equation equivalent to x := x $ 1 init v.

Note that this equation does not have input: it is a pure flow function with arity0.

• Sampling. This operator has one data input and one Boolean “control” input. Whenone of the inputs is absent, the output is also absent; at any logical instant whereboth input signals are defined, the output is present (and equal to the current datainput value) if and only if the control input holds the value true. Then, the Signalexpression

y := x when b

76



{ −y, x, b are extended to the same infinite domain T, respectively as yy, xx, bb,

− synchronized flows are infinite and satisfy ∀t ∈ T,

{ (bbt = true)⇒ yyt = xxt

(bbt , true)⇒ yyt = #

The when operator is thus a synchronized flow function.

• Deterministic merging. The unique output provided by this operator is defined(i.e., with a value different from #) at any logical instant where at least one of itstwo inputs is defined (and non-defined otherwise); a priority makes it deterministic.Then, the Signal expression

z := x default y


{

− the time domain T of z is the union of the time domains of x and y,

−z, x, y are extended to the same infinite domain TT ⊇ T, resp. as zz, xx, yy,

− synchronized flows satisfy ∀t ∈ TT,

{ (xxt , #)⇒ zzt = xxt

(xxt = #)⇒ zzt = yyt

The default operator is thus a synchronized flow function.

3.1.4 Process operators

A process is defined by composing elementary processes.

• Restriction. This operator allows one to consider as local signals a subset of thesignals defined in a given process. If x is a signal with type tox defined in a processP,

P where tox x or P where x

defines a new process Q where communication ways (for composition) are thoseof P, except x. Let A the variables of P and B the variables of Q: we say that Pis restricted to B, and executions of P are restricted in Q to variables of B. Moreprecisely, the executions in Q are the executions in P from which x signal is re-moved (the projection of these executions on remaining variables). This has severalconsequences:

- if P has a single output signal named x, then P where x is a pure synchro-nization process. The generated code (if any) is mostly a synchronization codeused to ensure signal occurrence consumptions.

- if P has a single signal named x, P where x denotes the neutral process: itcannot influence any other process. Hence no code is generated for it.

Derived equations

77


◦ (| P where x, y |) =∆ (| (| P where x |) where y |)

For short, it can be denoted P/x,y.

• Parallel composition. Resynchronizations (by freely inserting #’s) have to takeplace when composing processes with common signals. However, this is only aformal manipulation. If P and Q denote two processes, the composition of P and Q,written (| P | Q |) defines a new process in which common names refer to com-mon synchronized signals. Then, P and Q communicate (synchronously) throughtheir common signals. More precisely, let XPP (resp., XQQ) be the variables of P(resp., Q); the executions in (| P | Q |) are the executions whose projections onXPP are executions of P, and projections on XQQ are executions of Q. In other words,(| P | Q |) defines the set of behaviors that satisfies both P and Q constraints(equations).

Polychrony example : (| x := a | y := b|) defines a process that has twoindependent clocks. This process is a Kahn [102] process (i.e., is a flow function);it can be executed as two independent threads, on the same processor (provided thatthe scheduler is fair) or on distinct processors; it can also be executed as a singlereactive process, scanning its input and then executing none, one or two assignmentsdepending on the input configuration.

3.1.5 Parallel semantic properties

Process expression in normal form. The following properties of parallel compositionare intensively used to compile processes:

• associativity: (| P | Q |) | R ≡ P | (| Q | R |)

• commutativity: P | Q ≡ Q | P

• idempotence: P | P ≡ P is satisfied by processes that do not produce side effects(for instance due to call to system functions). This property allows to replicateprocesses.

• externalization of restrictions: if x is not a signal of P, P | (| Q where x |) ≡(| P | Q |) where x

Hence, a process expression can be normalized, modulo required variable substitution,as the composition of elementary processes, included in terminal restrictions.

Process abstraction. A process Pa is, by definition, a process abstraction of a processP if P|Pa = P. This means that every execution of P restricted to variables of Pa is an ex-ecution of Pa and thus all safety properties satisfied by executions of Pa are also satisfiedby executions of P. This is the key concept to verify properties of AADL descriptions.

78


3.1.6 Modularity features

Process model Given a process (a set of equations) P_body, a process model MP asso-ciates an interface with P_body, such that P_body can be expanded using this interface.A process model is a Signal term

process MP ( ? t_I1 I1; ...; t_Im Im;

! t_O1 O1; ...; t_On On;)

P_body

that specifies its typed input signals after “?”, and its typed output signals after “!”.Assuming that there is no name conflict (such a conflict is solved by trivial renaming), theinstantiation of MP is defined by:

(| (Y1, ..., Yn) := MP(E1, ..., Em) |)

=∆

(| I1:=E1 |...| Im:=Em | P_body | Y1:=O1 |...| Yn:=On |)

where t_I1 I1; ...; t_Im Im; t_O1 O1; ...; t_On On;

Example Here we use primitive operators to define a rudimentary increasing counter,that can be reset to 0. The process Count accepts an input reset signal and delivers theinteger output signal val. The process allows input signal reset and output val to haveindependent clocks.

The local variable counter is initialized to 0 and stores the previous value of the signalval (equation counter := val$ 1 init 0). When an input reset occurs, the signal val isreset to 0 (expression (0 when reset)). Otherwise, the signal val takes an increment of thevariable counter (expression (counter+1)).

process Count =

(? event reset; ! integer val; )

(| counter := val $1 init 0

| val := (0 when reset) default (counter + 1)

|) where integer counter;

end;

Figure 3.1 presents a trace of the Count process execution. The activity of Count isgoverned by the clock of its output val which differs from that of its input reset. If the sig-nal val is solicited by the environment, then either reset is absent and Count incrementsval, or reset is present and Count sets val to 0. Count is a polychronous process.

79


t1 t2 t5 t6t3 t9t4 t7 t8 t10 t11 t12 t13 t14true true true

1 0 1 2 3 4 0 1 2 3 0 0 1 20 1 0 1 2 3 4 0 1 2 3 0 0 1

count eventreset

valcounter

Figure 3.1: Execution trace of process count

3.1.7 Endochronous acyclic processes

When considering embedded systems specified in Signal, the purpose of code generationis to synthesize an executable program that is able to deterministically compute the valueof all signals defined in a process. Because these signals are timed by symbolic synchro-nization relation, one first needs to define a function from these relations to compute theclock of each signal. We say that a process is endochronous when there is a unique (deter-ministic) way to compute the clocks of its signals. Note that, for simulation purpose, onemay wish to generate code for non deterministic processes (for example, partially definedones) or even for processes that may contain deadlocks. Endochrony is a crucial propertyfor processes to be executable: an endochronous process is a function over pure flows.It means that the pure flows resulting from its execution on an asynchronous architecturedo not depend on propagation delays or operator latencies. It results from this propertythat a network of endochronous processes is a Kahn Process Network (KPN) and thus isa function over pure flows [60]. But it is not necessarily a function over synchronizedflows: synchronizations related to the number of #’s are lost because #’s are ignored.

3.1.8 Time domains and communications in Signal

In this section, we introduce the reader to AADL-Signal semantic gaps and similarities.Signal provides some derived operators, operations and tools that can bridge the gaps.

• Signal clock tools. Clocks can be strongly related to AADL time domains andoperators are defined to handle clocks.

◦ Clock of a signal: ^x returns the clock of x; it is defined by (^x) =∆(x = x), where = denotes the stepwise extension of usual equality operator.

◦ Clock selection: when b returns the clock that represents the (implicit) set ofinstants at which the signal b is true; in semantics, this clock is denoted by[b]. (when b) =∆ (b when b) is a pure flow function.

◦ Clock union (or clock max): x1^+x2 (denoted by + as a semantic op-erator) returns an event signal that is present iff x1 or x2 is present.(x1^+x2)=∆((^x1) default (^x2))

◦ Clock difference: x1^-x2 returns an event signal that is present iff x1 is presentand x2 is absent. (x1^-x2)=∆(when ((not ^x2) default ^x1))

◦ Null clock: the signal when(b when (not b)) is never present: it is callednull clock and is denoted by ^0 in the Signal syntax, 0 as a semantic constant.

80


◦ Clock product: x1^∗x2 (denoted by ∗ as a semantic operator) returns the clockthat represents the intersection of pure time domains of the signals x1 and x2.When their clock product is 0, x1 and x2 are said to be exclusive. (x1^∗x2)=∆ (^x1) when (^x2))

◦ Synchronization: x1^=x2 specifies that x1 and x2 are synchronous.(| x1 ^= x2 |) =∆ (| h := (^x1 = ^x2) |) where h

◦ Clock inclusion: x1 ^< x2 specifies that time domain of x1 is included intime domain of x2. (| x1 ^< x2 |) =∆ (| x1 ^= (x1^∗x2) |)

• Signal periodic clocks. Periodic clocks can be specified in Signal using affine clockrelations. A calculus of affine clock relations has been defined [147, 163, 148], inwhich symbolic signal clocks are associated with affine functions: two periodicsignals x, y are said in (n, φ, d)-affine relation iff their respective clocks x, y can beexpressed as functions x = {n · t + φ1 | t ∈ z} and y = {d · t + φ2 | t ∈ z} of a commonreference of discrete time z (n, d, φ1, φ2 are integers, n, d > 0 and φ = φ2 − φ1).

Affine clock relations yield an expressive calculus for the specification and the anal-ysis of time-triggered systems. A particular case of affine relation is the case of(1, φ, d)-affine relation, with φ ≥ 0: y is a subsampling of positive phase φ andstrictly positive period d on x. Most of the decidable and algorithmically affordableanalysis concerns (1, φ, d)-affine relations.

In Polychrony, the Signal clock calculus implements synchronisability rules basedon properties of affine relations, against which synchronization constraints can beassessed.

• Communications. General communication principle in Signal is broadcast, whichmeans that, one signal is communicated as several ones. It is also possible in Signalto have several signals or expressions associated with one signal by partial defini-tions.

◦ Partial signal definition: y ::= x is a partial definition for the signal y whichis equal to x, when x is defined; when x is not defined its value is free.(|y ::= x|) =∆ (|y := x default y|)

This process is generally non deterministic. Nevertheless, it is very usefulto define components such as transitions in automata, or modes in real-timeprocesses, that contribute to the definition of the same signal.

The clock calculus can compute sufficient conditions to guarantee that theoverall definition is consistent (different components cannot give different val-ues at the same instant) and total (a value is given at all instants of the timedomain of y).

• Tools for deferring communications. Deferring communications can be imple-mented in Signal using memory cell and FIFO.

◦ y := x cell c init x0 behaves as a synchronized memory cell: yis present with the most recent value of x when x is present or

81


c is present and true. It is defined by the following program:(| y := x default (y $1 init x0) | y ^= x ^+ when c |)

◦ y := var x init x0 behaves as a standard memory cell: when y is present,its value is the most recent value of x (including the current instant); the clockof x and the clock of y are mostly independent (the single constraint is thattheir time domains belong to a common chain). It is defined by the followingprogram: y := (x cell ^y init x0) when ^y

◦ Bounded FIFO [86] is intended to be used for message exchanges betweenseveral entities. A basic FIFO queue works as follows: on a write request,the incoming message is inserted in the queue regardless of its size limit. Ifthe queue was full, the oldest message is lost. The other messages are shiftedforward, and the incoming one is put at the end of the queue. On a readrequest, there is an outgoing message: if the queue was empty, an arbitrarymessage called default message is returned; otherwise the outgoing messageis the message that has been read last. The corresponding Signal interface ofthe basic FIFO is given below [86]:

process basic_FIFO =

{ type message_type; integer fifo_size, message_type default_mess;}

( ? message_type mess_in; event access_clock;

! message_type mess_out; integer nbmess; boolean OK_write, OK_read;)

A safe queue is also modeled in [86]. Read and write control are added for thepurpose of ensuring a safe access to the basic queue. A safe queue can serve inthe description of some communication protocol such as the LTTA (LooselyTime-Triggered Architectures) protocol [53].

• Tools for breaking atomicity. For a Signal program, the fastest clock of a process isnot always an input clock, new instants can be inserted between existing ones. Over-sampling enables the specification of constraints between inputs and outputs in sucha way that no further input may occur as long as the given constraints are not met bythe (intermediate) calculations of the output [115]. The abstract notion of absencebetween two occurrences of useful values along a signal is flexible enough to enablereasoning on the successive refinements and transformations of the description of asystem.

3.1.9 Non-determinism modeling in Signal

Determinism is a key property for critical program execution. However, specificationlevel, property description, abstractions need non-determinism resulting from partial de-scriptions. In the Polychrony framework, one can give the non-determinism modeling andrefine it to determinism by adding the constraints. There existes several ways to illustrateit, in verification, since the Signal model does not need to be executable, so it may be anon-deterministic specification.

For example, a processprocess oracle(? ! x,y;)

(| x^= when z

82


| y^= when not z

|)

where boolean z; end;

which could be used by Sigali [126] for verifier whether x and y are execlusive.For the simulation which needs to be an executable specfication, we can parameterize

such a system with a clock “oracle” of a non-deterministic choice. This could be usefulin testing, with the automatically generated sequences of tests.

process oracle (? boolean z; ! x,y;)

(| x^= when z

| y^= when not z

|)

Here, “z” is then provided by the test sequences, or simply by building a dis-tributed simulator from sepetated compiled Signal modules (not by the verification ofthese isochronous properties). Therefore in principle, we can effectively model the non-determinism in Signal.

3.1.10 Adequacy of Signal for AADL modeling

In the polychronous language Signal, time is represented by partially ordered synchro-nization and scheduling relations, to provide an additional ability to model high-levelabstractions of systems paced by multiple clocks: globally asynchronous systems. Themulti-clock model stands out from other synchronous specification models and adaptswell for AADL thanks to several capabilities:

• Multi-clock. The multi-clock feature allows Signal to model systems with severalclocks, where each component holds its own activation clock, as well as single-clocked systems, in a uniform way. This feature well suits for the GALS architec-ture.

• Refinement. Polychrony supports formal system design refinement, from the earlystages of requirements specification, to the late stages of synthesis and deployment.In the polychronous model of computation, one can design a system with partiallyordered clocks, and then refine it to obtain master-clocked components, integratedwithin a multi-clocked architecture.

• Modularity. A great advantage of its modularity feature is its convenience forcomponent-based design approach, that allows modular development of complexsystems. This feature makes it possible to address the design of each componentseparately.

• Parallelism model. Synchronous parallel composition reduces programming com-plexity. Parallel composition relates the activation clocks of the different compo-nents, allowing to build complex systems.

83


3.2 Modeling ARINC concepts in Signal

The Polychrony design environment includes a library in Signal containing real-time executive services defined by ARINC [37], which was designed by AbdoulayeGamatié [83]. It relies on a few basic blocks [84, 85], which allow to model partitions:APEX-ARINC-653 services, an RTOS model and executive entities. In the following,each block and the way its corresponding Signal model is obtained is shown.

Figure 3.2: An example of partition model composed of three processes

3.2.1 Partitions

In Chapter 2, we have already presented the notion of partition. A partition is composedof processes which represent the basic execution units. Processes in a partition share theresources allocated to the partition, but cannot access the resources in other partitions. InFigure 2.25, Partition1 is composed of three processes.

Figure 3.2 roughly shows a global view of a partition composed of three processesin Signal. In this model, the component GLOBAL_OBJECTS appears for structuring. Inparticular, it provides the processes with communication and synchronization mechanisms(e.g. buff, sema).

Figure 3.3 gives a textual example of a partition, named ON_FLIGHT. It con-tains three processes: POSITION_INDICATOR(), FUEL_INDICATOR() and PARAME-

TER_REFRESHER(). Each process has a unique identifier specified in the parameter,for example, process POSITION_INDICATOR is identified 1. All the processes are cre-ated at the initialization phase of the partition. After the initialization phase, the partitiongets activated (i.e. when receiving active_partition_ID – this signal is produced by the

84

3.2. MODELING ARINC CONCEPTS IN SIGNAL

Figure 3.3: A Signal textual example of partition model

module-level OS, which is in charge of the partitions management). Whenever the parti-tion executes, the PARTITION_LEVEL_OS selects an active process within the partition.This is represented by its output signal active_process_ID, which is sent to each process.The communication mechanisms buffers and blackboards are created when the partitionis initialized, e.g. CREATE_BLACKBOARD{}.

3.2.2 Partition-level OS

The role of the partition-level OS is to ensure the correct concurrent execution of processeswithin the partition (each process must have exclusive control on the processor). A samplemodel of the partition-level OS is depicted in Figure 3.4.

Active_partition_ID

dt

Timedout

Active_process_ ID

Partition−level OSinitialize

Figure 3.4: Interface of the partition-level OS

In Figure 3.4, the input Active_partition_ID represents the identifier of the run-ning partition selected by the module-level OS, and it denotes an execution order when itidentifies the current partition. The presence of the input signal initialize corresponds

85


to the initialization phase of the partition: creation of all the mechanisms and processescontained in the partition. Whenever the partition executes, the partition_level_OSselects an active process within the partition. The process is identified by the value car-ried by the output signal Active_process_ID, which is sent to each process. The signaldt denotes duration information corresponding to process execution. It is used to updatetime counter values. The signal timedout produced by the partition-level OS carriesinformation about the current status of the time counters used within the partition. Forinstance, a time counter is used for a wait when a process gets interrupted on a service re-quest with time-out. As the partition-level OS is responsible for the management of timecounters, it notifies each interrupted ARINC process of the partition with the expirationof its associated time counter. This is reflected by the signal timedout.

3.2.3 Processes

The definition of an ARINC process model basically takes into account its computationand control parts. In Figure 3.5, two sub-components are clearly distinguished within themodel: CONTROL and COMPUTE.

....

....

.....

....

Inputs

Outputs

Active_process_ID

timedout dt

CONTROL

COMPUTE

Block

Block

Block

Block

Figure 3.5: ARINC process model.

Any process is seen as a reactive component, which reacts whenever an executionorder (denoted by the input Active_process_ID) is received. The input timedout no-tifies processes of time-out expiration, while the output dt is emitted by the process aftercompletion. In addition, there are other inputs (resp. outputs) needed for (resp. producedby) the process computations. The CONTROL and COMPUTE sub-components cooperateto achieve the correct execution of the process model.

The CONTROL sub-component specifies the control part of the process. Basically,it is a transition system that indicates which statements should be executed when theprocess model reacts. Whenever the input Active_process_ID identifies the ARINCprocess, this process “executes”. Depending on the current state of the transition systemrepresenting the execution flow of the process, a block of actions in the COMPUTE sub-component is selected to be executed instantaneously (with respect to logical time of thesynchronous modeling).

The COMPUTE sub-component describes the actions computed by the process. It iscomposed of blocks of actions. They represent elementary pieces of code to be executed

86

3.2. MODELING ARINC CONCEPTS IN SIGNAL

without interruption. The statements associated with a block are assumed to complete

within a bounded amount of time. Since a block is supposed to be non-interrupted, it isimposed that it contains either one single system call, or one or more data computationfunctions. In this way, a block can be executed instantaneously.

3.2.4 APEX services

The APEX services modeled in Signal include communication and synchronization ser-vices used by processes (e.g. SEND_BUFFER, WAIT_EVENT, READ_BLACKBOARD),process management services (e.g. START, RESUME), partition management ser-vices (e.g. SET_PARTITION_MODE), and time management services (e.g. PERI-

ODIC_WAIT).In the following, the modeling of the READ_BLACKBOARD service is presented. This

service is used to read a message in a blackboard. The input parameters are the blackboardidentifier, and a time-out duration that limits the waiting time if the blackboard is empty.The outputs are a message and a return code for the diagnostics of the service request.

Figure 3.6: Signal model of READ_BLACKBOARD

Figure 3.6 presents a graphical description of the service. There are four mainsub-processes, which are represented by inner boxes in the figure. The sub-processesCHECK_BOARD_ID and CHECK_TIMEOUT verify the validity of input parametersboard_ID and timeout. If these inputs are valid, PERFORM_READ tries to readthe specified blackboard. Afterward, it has to send the latest message displayed onthe blackboard. PERFORM_READ also transmits all the necessary information toGET_RETURN_CODE, which defines the final diagnostic message of the service request.

process READ_BLACKBOARD =

{ ProcessID_type process_ID; }

( ? Comm_ComponentID_type board_ID;

87


SystemTime_type timeout;

! MessageArea_type message;

MessageSize_type length;

ReturnCode_type return_code; )

(| board_ID ^= timeout ^= present ^= outofrange ^= available

^= C_return_code (s1)

| board ^= empty ^= when present (s2)

| message ^= length ^= when (not empty) (s3)

| is_err_handler ^= when empty when available (s4)

| preemp_enabled ^= when (not is_err_handler) (s5)

| C_return_code := (when ((not present) or outofrange)) default

(when empty when (not available)) default

(when ((not preemp_enabled) default is_err_handler)) default

(when (not empty)) default false (s6)

| return_code ^= when C_return_code (s7)

|)

Here we list the interface and partial textual implementation of theREAD_BLACKBOARD. The equations (s1), (s2), (s3), (s4) and (s5) ex-press some synchronization. The signal C_return_code denotes the presence of a returncode, as described in equation (s6). The detailed communication and computation couldbe implemented in external C code.

3.3 Conclusion

We introduced the language Signal and its polychronous model of computation in thischapter. Signal is a polychronous data-flow language. The Signal formal model providesthe capability to describe systems with several clocks as relational specifications. UsingSignal allows to specify an application, to design an architecture, to refine detailed com-ponents to RTOS or hardware description. The syntax and semantics of Signal have beenpresented.

We also focus on the definition of Signal models of components required for the de-scription of avionics applications. The Signal framework has solid mathematical foun-dations enabling formal methods for specification, verification, analysis and transforma-tions. The modularity and abstraction of the Signal language allow for scalability. Thedescription of a large application is achieved by specifying first, either completely orpartially (by using abstractions), sub-parts of the application. After that, the resulting pro-grams can be composed in order to obtain new components. These components can bealso composed and so on, until the application description is complete. A crucial issueabout the design of safety critical systems, such as avionics, is the correctness of these sys-tems. In Polychrony, the functional properties of a system can be checked using tools likethe compiler or the model checker Sigali. Therefore, the design of avionic applicationscan be addressed and well modeled based on model refinement within the developmentenvironment Polychrony, associated with the synchronous language Signal.

A library of APEX-ARINC services, providing Signal models of RTOS functionali-ties, is provided. It specifes a Signal description of avionic applications based on IMA.The synchronous modeling of AADL components, which is based on the IMA architec-ture, will be presented in Chapter 5 as a major contribution of this thesis.

88

Part III

Prototyping AADL models in apolychronous model of computation

Chapter 4

Formalizing AADL

Contents4.1 AADL background . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.2 Related works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4.2.1 Modeling AADL in MARTE . . . . . . . . . . . . . . . . . . . 93

4.2.2 Modeling AADL in SystemC . . . . . . . . . . . . . . . . . . 94

4.2.3 Code generation from AADL to C . . . . . . . . . . . . . . . . 94

4.2.4 Modeling AADL in Fiacre . . . . . . . . . . . . . . . . . . . . 94

4.2.5 Modeling AADL in TASM . . . . . . . . . . . . . . . . . . . . 96

4.2.6 Modeling AADL in ACSR . . . . . . . . . . . . . . . . . . . . 98

4.2.7 Modeling ARINC653 systems using AADL . . . . . . . . . . . 98

4.2.8 Modeling AADL in BIP . . . . . . . . . . . . . . . . . . . . . 98

4.2.9 Modeling AADL in Lustre . . . . . . . . . . . . . . . . . . . . 101

4.3 Summary and comparison . . . . . . . . . . . . . . . . . . . . . . . 103

4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

This chapter is devoted to the introduction of some related AADL model formalizationand transformations. Section 4.1 gives an overview of the AADL background and currentusers. In order to support some analysis or verification or other purposes, the AADLmodel is formalized by many other languages. Section 4.2 presents the different formal-ization of AADL. In section 4.3, a brief comparison of these formalization is presented.Conclusions are given in section 4.4.

4.1 AADL background

The AADL language offers advantages of actually being an international standard, whileprecisely defining the semantics of a predefined set of components, including real-timeconcerns. It targets critical developments and offers appropriate modeling techniques tocover system and software engineering activities.

CHAPTER 4. FORMALIZING AADL

Traditionally, embedded systems specification, design, development and validation ofsystems has been lacking in a precise capture of the system architecture and its analysisearly in and throughout the development process. System integration becomes high risk,and system evolution becomes expensive and results in rapidly outdated components.

By contrast, improved embedded systems engineering practice would be architecture-based and model-driven. Well-defined software system architecture provides a frameworkto which system components are designed and integrated. System models that preciselycapture this architecture provide the basis for predictable embedded system engineeringthrough repeated analysis early in and throughout the development life cycle. The SAEAADL is such an industry standard notation that was explicitly designed to support suchmodel-based embedded system engineering.

In [2], it is reported that some companies and research centers are using AADL, or arecontributing to AADL:

• Honeywell [12]. As the originator of MetaH, experiences with the MetaH languageand toolset have led to the development of the AADL standard.

• SEI [23]. The Software Engineering Institute (SEI) has provided technical leader-ship in the development of AADL. A hands-on course on Model-based Engineeringwith AADL and the open source AADL tool environment has been developed.

• Rockwell Collins [21]. Rockwell Collins has done a pilot study on modeling andanalysis of an avionics systems architecture using AADL.

• ESA [11]. The European Space Agency (ESA) in cooperation with Axlog has iden-tified AADL as a key technology for their future.

• ElliDiss [10]. Ellidiss has enhanced its STOOD tool environment to support AADL.

• EADS [9]. The European Aeronautic Defense and Space company (EADS Ger-many) has investigated the use of AADL for modeling the reference architecturefor the Allied Standard Avionics Architecture Council (ASAAC) program.

• Airbus [6]. Airbus France has investigated the use of AADL and UML2.0 underthe COTRE initiative. The TopCased [29] project, started by Airbus, sets out toprovide new development tools of AADL, i.e., OSATE and behavioral annex editor.Our work is founded by Airbus.

4.2 Related works

The AADL language provides an efficient support to take into account complex embed-ded systems. In order to validate formal properties on AADL models, or schedulability,or performance analysis, or verification of an AADL model, a formal framework whichprovides diagnostics on the system must be used. This goal can be achieved if we cantransform the AADL model into some other model, whose associated toolsets offer thesecapabilities. Here we give a brief view of some related AADL transformations. We try toclassify these works according to their main purpose, from the point of view of modeling,simulation, verification and other purpose, though this classification is not a strict one.

92

4.2. RELATED WORKS

4.2.1 Modeling AADL in MARTE

For the purpose of modeling, MARTE [14] (Modeling and Analysis of Real Time andEmbedded systems) is used to model AADL, especially for the communications. MARTEis a UML profile recently adopted by OMG (Object Management Group). Being a UMLprofile, it benefits from the large set of rapidly improving UML graphical editors and hasstrong connections with SysML, offering an opportunity to have a complete and integrateddesign flow, from system-level specification and requirement analysis to implementation,code generation, schedulability and performance analysis.

Using MARTE as a foundation profile to model AADL specific concepts would ben-efit to both communities. It would ease interoperability of AADL with UML models, andwould allow some selected MARTE models to be analyzed by AADL tools.

[119] builds the semantic construction using MARTE Time Model [45], to representfaithfully AADL periodic/aperiodic tasks communicating through event or data ports, inan approach to end-to-end flow latency analysis. The idea is to define once a model libraryfor AADL with MARTE.

The authors choose to represent the AADL flow using a UML activity diagram. Fig-ure 4.1 gives an example of end-to-end flow with UML and MARTE.

Figure 4.1: End-to-end flow with UML and MARTE

This UML diagram is untimed, to make it behave the exact same way as an AADLmodel, they propose to use the MARTE Time Profile. The MARTE Time subprofile,inspired from the theory of tags systems [117], provides a set of general mechanisms todefine the model of computation and communication.

Two kinds of communications are modeled in MARTE:

• Data-driven communications. The execution of a given task is triggered by theavailability of the data produced by the preceding task. The CCSL clock relationalternatesWith can be used to model such data-driven communications:

step1.finish alternatesWith step2.start

• Sampled communications. Pure data are only sampled and used as such wheneverthe task is activated.

93


[124] relies on the MARTE Time Model and the operational semantics of its compan-ion language CCSL, to equip UML activities with the execution semantics of an AADLspecification. This is part of a much broader effort to build a generic simulator for UMLmodels with semantics explicitly defined within the model.

4.2.2 Modeling AADL in SystemC

SystemC is a set of C++ classes and macros which provide an event-driven simulationkernel in C++. SystemC is applied to system-level modeling, architectual exploration,performance modeling, software development, functional verification, and high-level syn-thesis.

For the purpose of simulation, AADS [157] is developed as an AADL SystemC sim-ulation tool. It supports the performance analysis of AADL specifications throughoutthe refinement process from the initial system architecture till the complete applicationand execution platform are developed. It parses the AADL model, so the functionality istranslated to an equivalent POSIX model and the architecture is represented in XML.

The generation of the SystemC model from the AADL specification is not straight-forward. Nevertheless, the SystemC model generated by AADS is able to capture thefundamental dynamic properties of the initial system specification.

4.2.3 Code generation from AADL to C

PolyORB-HI-C [20] is an AADL runtime used by C code generator. It is developed byOcarina [15] for distributed high-integrity applications based on the Ada Ravenscar [120]profile. Two target languages are supported: Ada2005 and C. It is used for system prim-itives and resource management. This piece of software is a link between Ocarina gener-ated code and the underlying runtime system.

[65] presents an experimentation: code generation from a sub-part of AADL modelto C code (compliant with a specific standard (OSEK/VDX)) using MDA tools. In theexperimentation, the authors focus on the AADL thread component. Two transformationsgenerate either C language code (compliant with OSEK/VDX) and corresponding OILconfiguration code.

Within only one mode, without fault handling and without considering subprogramcalls, the suspended, ready and running states of AADL threads and OSEK/VDX tasksfollow the same semantics. Thus, generated OSEK/VDX tasks may respect the AADLthread execution semantics for periodic, sporadic or aperiodic threads.

In the OSEK/VDX standard, all threads execute on the same processor, share a virtualaddress space. Thus, if many threads may be considered, only one process is used. Thegenerated C code corresponds to the implementation of dynamic thread semantics.

4.2.4 Modeling AADL in Fiacre

Fiacre [57] is a formal intermediate model to represent both the behavioral and timingaspects of systems in embedded and distributed systems for formal verification and simu-lation purposes. It is designed both as the target language of model transformation engines

94

4.2. RELATED WORKS

from various models, such as SDL, UML, AADL, and also as the source language of com-pilers into targeted verification toolboxes, such as CADP and Tina. In order to supportverification of AADL models, modeling AADL in Fiacre is proposed.

The Fiacre language has two main notions:

• process. A process describes the behavior of sequential components. A processis defined by a set of control states and parameters, each associated with a set ofcomplex transitions.

• component. A component describes the composition of processes, possibly in ahierarchical manner.

The component root presented in the following is a simple token ring example. Themodel consists of a component root that chooses non-deterministically the process Node

that initially owns the token (process start).

process Start [ start0 : none , start1 : none , start2 : none ] is

states s0 , s1

from s0 select start0 [ ] start1 [ ] start2 end ; to s1

process Node [ prev : none , succ : none , start : in none ] is

states idle , wait , cs , st_1

from idle select start ; to st_1 [ ] prev ; to st_1 end

from st_1 succ ; select to idle [ ] to wait end

from wait prev ; to cs

from cs succ ; to idle

component root is

port s0 : none , s1 : none , s2 : none ,

p0 : none , p1 : none , p2 : none ,

par * in

Start [ s0 , s1 , s2 ]

|| Node [ p0 , p1 , s0 ]

|| Node [ p1 , p2 , s1 ]

|| Node [ p2 , p0 , s2 ]

end

root

AADL2Fiacre [56] deals with the transformation of AADL models into Fiacre mod-els to perform formal verification and simulation. The transformation relies on AADLproperties and on the behavioral annex of AADL. The authors follow a model-driven ap-proach. They developed a meta-model of the Fiacre language. Hence the transformationfrom AADL to Fiacre is obtained through model transformation. This translation is basedon the formal semantics of the AADL execution model.

The transformation of AADL code into Fiacre includes the following main features:

• Transformation of an AADL architecture. To consider the system as a hierarchyof components, the hardware components are ignored. In order to offer to threads asimple access to their ports, a new component, called a glue, is introduced at eachlevel of the hierarchy, which desynchronizes sender and receiver ports. The AADLthreads do not communicate directly: the glue process manages communicationsand scheduling protocols (Figure 4.2).

95


thread 1 thread �...glue

Figure 4.2: Threads and the glue

• Transformation of thread behaviors. A thread is translated into a Fiacre processtaking as parameters ports linked to the glue. Annex specific constructs associ-ated to the AADL programming interface are translated to communications throughcontrol channels managed by the glue. Thread dispatch is synchronized with datatransfers within the glue.

• Modeling communication semantics. Two communication protocols are consid-ered: immediate and delayed. The use of an immediate communication avoidsdeclaring an explicit offset for the reader process. The delayed mechanism ensuresa deterministic communication between threads of different periods.

Tina (TIme Petri Net Analyzer) provides a software environment to edit and analyzePetri Nets and Time Petri Nets. For verification purposes, Fiacre programs are compiledinto suitable input formalisms for the Tina and CADP toolboxes. The Tina back-endtranslates Fiacre programs into Time Transition System and the specification requirementsinto State-Event LTL formulas. It is used to verify the model in some expected properties.

4.2.5 Modeling AADL in TASM

The Timed Abstract State Machine (TASM) [136] is based on the theory of Abstract StateMachine (ASM) [62]. It extends ASM to enable expression of timing, resource, commu-nication, composition, parallelism. A basic TASM specification contains an abstract statemachine and an environment. The environment contains environment variables and theuniverse of types that variables can have. The machine consists of three parts: monitored

variables, controlled variables and mutually exclusive rules with the form of “if condition

then action”.In brief, the execution model of TASM is a loop: read input variables, wait for the

duration of the execution, write output variables, and wait for synchronization.Technically, a TASM specification is made up of machines. A specification must hold

at least one main machine with its set of rules. Beside main machines, it is also possibleto define sub machines and function machines.

[165] proposes a formal semantics for the AADL behavior annex using TASM. Asemantics of AADL execution model is given, and a prototype of behavior modeling andverification is proposed.

Only the synchronous execution model is considered in [165]. It gives the relationbetween execution model and behavior annex (Figure 4.3).

A periodic thread is specified in TASM by two main machines: one to manage period,and the other one to represent the execution of thread with deadline, WCET, resource andexecution rules.

96

4.2. RELATED WORKS

Figure 4.3: Behavior annex and execution model

MAIN MACHINE: Period

Rule: period

{ t := period;

if Nextdispatch = false then Nextdispatch := true;}

MAIN MACHINE: Execution

Rule: execution

{ t :=[0,deadline];

processor := WCET*100/deadline;

if Complete = false then Complete := true;}

TASM explicit time model with powerful logical time constraints allows specifyingprecisely the scheduling aspects of threads, parallel and communication mechanisms canbe used to describe the synchronization. The immediate and delayed communicationsemantics are defined in TASM. The delayed communication modeling is detailed for thecase of synchronous, oversampling and undersampling.

To define the formal semantics of behavior annex, as the hierarchical composite mech-anism in TASM, state is mapped to controlled/monitored variables, guard is specified us-ing function machines with boolean output parameter, action is specified using functionor sub machines, and the whole transition is expressed by rules of a main machine.

A subset of actions are modeled, including: send/receive events, remote subprogramcall, client-server protocol and time behavior. For example, the time behaviors (compu-

tation(min, max) and delay(min, max)) are modeled by the main machines. A control/monitored variable is defined: CurrentState:={Current, Next}.

MAIN MACHINE: Computation

Rule: computation{min, max}

{ t := [min, max]

processor := WCET*100/deadline;

if CurrentState = Current then CurrentState := Next;}

MAIN MACHINE: Delay

Rule: delay{min, max}

{ t := [min, max]

if CurrentState = Current then CurrentState := Next;}

97


The purpose of modeling AADL in TASM is to perform formal verification. This ver-ification is achieved with UPPAAL by mapping each main machine to a timed automaton.Timing correctness is defined as a reachable state of the system, being reachable withinan acceptably bounded amount of time.

4.2.6 Modeling AADL in ACSR

Algebra of Communicating Shared Resources (ACSR) [118] is a real-time process algebrathat makes the notion of resource explicit in system models. Restrictions on simultaneousaccess to shared resources are introduced into the operational semantics of ACSR, whichallow to perform analysis of scheduling properties of the system model.

[149] presents a semantics-preserving translation of AADL models into the real-timeprocess algebra ACSR, to perform schedulability analysis of AADL models. The authorsdescribe an approach to provide formal analysis of timing properties, including schedula-bility analysis of AADL models. In order to analyze a model, they automatically translateit into the real-time process algebra ACSR, and use the ACSR-based tool VERSA to ex-plore the state space of the model, looking for violations of timing requirements.

The basis for the translation is given by the semantic definition for thread componentsin the AADL standard. Schedulability analysis of the translated ACSR model is enabledby the ability of ACSR to describe resource requirements and use priorities to controlaccess to shared resources. Furthermore, this analysis tool offers a set of failing scenariosin the case when the system is non-schedulable or violations of timing requirements arediscovered.

4.2.7 Modeling ARINC653 systems using AADL

[73] presents an approach for the modeling, verification, implementation and simulationof ARINC653 systems using AADL. It details a modeling approach exploiting the newfeatures of AADLv2 for the design of ARINC653 architectures.

The approach uses Cheddar [8] scheduling analysis tool to check scheduling aspectswith regards to runtime requirements. Then an AADL-to-ARINC653 code generator(Ocarina [15]) and a dedicated AADL/ARINC653 runtime (POK [19]) are used to gener-ate the system automatically.

In this work, an ARINC653 module is represented in AADL by a processor. AnARINC653 partition modeling is achieved with AADL virtual processor and process. AnARINC653 process is mapped to AADL thread. The intra-partition and inter-partitioncommunication services are also represented in AADL, listed in Table 4.1.

Advantages of this approach are the use of verification mechanisms to automaticallydetect potential problems before implementation efforts, and provide an ARINC653 com-pliant runtime to operate the produced system.

4.2.8 Modeling AADL in BIP

BIP [7] (Behavior Interaction Priority) is a language for the description and compositionof components as well as associated tools for analyzing models and generating code on

98

4.2. RELATED WORKS

ARINC653 AADLmodule processorpartition virtual processor and processprocess threadbuffer event data port

blackboard data portevent event port

queuing port event data portsampling port data port

Table 4.1: Modeling ARINC653 architecture in AADL

a dedicated platform. It is used to model heterogeneous real-time components. The BIPcomponent model is the superposition of three layers:

• Lower layer. The lower layer describes the behaviors of a component as a set oftransitions. An atomic component consists of a set of ports used for the synchro-nization with other components, a set of transitions and a set of local variables.Transitions describe the behavior of the component, and they are represented asa labeled relation between control states. Figure 4.4 shows an atomic componentwith two control states S i and S j, ports in and out, and corresponding transitionsguarded by guard gi and g j. A compound component allows defining new com-ponents from existing sub-components by creating their instances, specifying theconnectors between them and the priorities.

Figure 4.4: BIP atomic component

• Intermediate layer. The intermediate layer includes connectors describing the in-teractions between transitions of the layer underneath.

• Upper layer. The upper layer consists of a set of priority rules used to describescheduling policies for interactions.

[68] studies a general methodology and an associated tool for translating AADL andbehavior annex specification into the BIP language. The software, hardware and systemcomponents are translated from AADL to BIP. The behavior annex and connections arealso translated. For example, a thread is modeled in BIP by an atomic component, anda subprogram is translated into an atomic or compound BIP component. This translation

99


allows simulation of AADL models, as well as application of verification techniques.Two model checking techniques for verification have been applied, once the BIP modelis generated: deadlock detection by using the tool Aldebaran, and verification of threaddeadlines and component synchronization by using BIP observers.

[138] models AADL data communication with BIP. It focuses on deterministic datacommunication, and shows how BIP deals with the modeling of immediate and delayeddata communications supporting undersampling and oversampling of AADL.

Since the two types of communication rely on the notion of periodic thread, the authorsfirst propose a model of AADL periodic thread in BIP. Compared to [68], they ignoreinitialization states as well as the support for the behavior annex. An AADL periodicthread is modeled in BIP by a compound component.

Figure 4.5: BIP model of an immediate connection

Figure 4.5 describes the automation associated with an immediate connection. Whentime is aligned to the LCM (Least common multiple) of the periods of the two interact-ing threads, the data transfer is allowed through the synchronization on the port comple-

tion_immediate. In this case, the execution of the receiving thread is delayed until thecompletion of the sender thread: execution is not allowed in the SYNC state. Otherwise(ASYNC state), completion of the first thread and execution of the second thread are notsynchronized and no data transfer is performed.

The specification of a delayed communication in BIP is specified by the automatonshown in Figure 4.6.The component declares two variables: the variable next is trans-mitted by the sender thread at completion. It is copied to the variable current at senderdeadline. This variable is transmitted to the receiver thread at its dispatch. Thus, twovariables are needed to manage delayed communication. So in case of a communicationbetween synchronous processes, the reader will get the new input at the start of the nextperiod. It is therefore necessary to keep the last data to send it at the end of period. Dataare always sent with nearly a period of delay.

100

4.2. RELATED WORKS

Figure 4.6: BIP model of a delayed connection

4.2.9 Modeling AADL in Lustre

AADL2SYNC [3] is an AADL to synchronous programs translator, which is extended inthe framework of the European project ASSERT, resulting in the system-level tool boxtranslating AADL to Lustre.

The main object is to perform simulation and validation that take into account boththe system architecture and the functional aspects. The authors proposed in [99] to buildautomatically a simulator of the architecture, expressed in a synchronous language. Thenon-synchronous composition of synchronous processes is expressed by sporadic activa-tion and oracle-driven non-determinism.

An activation condition is added to periodic and sporadic components (processes andthreads). The following gives an example of a periodic clock generator. For a componentC of period p, the scheduler defines a boolean variable C_activate_clk that is true everyp cycles of the outer processor. The returned activation condition is a boolean that is setto true when the node needs to be activated.

node clock_of_period(period: int; qs_tick: bool)

returns (activate_clock: bool);

let

pcpt = period -> pre cpt;

cpt = if activate_clock then period else

if qs_tick then (pcpt - 1) else pcpt;

activate_clock = true -> (pcpt = 1) and qs_tick;

tel

The general construction is that: the processes are all sporadically activated accordingto activation conditions emitted by a global scheduler. The scheduler is non-deterministic:it receives one boolean oracle for each condition it has to elaborate.

Although this approach also translates AADL to a synchronous language, it considersa purely synchronous model of computation (that of Lustre), in which clocks need tobe totally ordered (by contrast to the relational, multi-clocked MoC considered in Signal).This limitation requires the emulation of asynchrony by using a specific protocol of quasi-synchronous communication. Its expressive capability is limited compared to simplyabstracting asynchrony using partially-ordered clock relations.

101


A quasi-synchronous clock generator shown below is given in [100]. Node qs is themain node of the quasi-synchronous scheduler for processors with the same clock rate.The idea is that, starting from a n-array of boolean values containing candidate values forthe quasi-synchronous clocks (i.e., chosen randomly), to check that no clock drift excessoccurs, and to force the culprit clocks to be false when necessary to avoid this drift excess.The node compute_advance computes the relative advance of ck1 with regard to ck2. Thenode ba_fill creates an array of size n filled with x. Node ba_none checks if all elementsof the array are false.

-- Compute the relative advance of clk1 w.r.t. clk2

node compute_advance(clk1, clk2 : bool) returns (c : int);

var pc : int;

let

pc = 0 -> pre c;

c = if clk2 then 0 -- reset the advance of clk1

else if clk1 then pc + 1 -- clk1 got ahead of one tic

else pc;

tel

-- Create an array of size n filled with x

node ba_fill(const n: int; x : bool) returns (t: bool^n);

let

t = x^n;

tel

-- Check if all elements of the array are false

node ba_none(const n : int; I : bool^n) returns ( ok : bool);

var

Nor : bool^n;

let

Nor = [not I[0]] | (Nor[0..n-2] and not I[1..n-1]);

ok = Nor[n-1];

tel

node qs(const n:int; const d:int; alea:bool^n) returns (select:bool^n);

var

advance_max_is_reached, problems : bool^n^n;

filter : bool^n;

advance, padvance : int^n^n;

let

advance_max_is_reached = padvance >= d^n^n;

-- there is a problem if the max advance is reached and no tic occurs

problems = advance_max_is_reached and not alea^n;

-- force the tic for clocks that would be more than d tics late

filter = ba_none(n^n, problems);

select = alea and filter;

advance = compute_advance(ba_fill(n^n, select), select^n);

padvance = 0^n^n -> pre advance;

tel

Synchronous modeling of asynchronous systems is also studied in [94]. The authorsdefine a generic semantic model for synchronous and asynchronous computation, afterthat, the attention is focused on implementing communication mechanisms.

102

4.3. SUMMARY AND COMPARISON

[97] deals with expressing the behavior of complex scheduling policies managingshared resources. A synchronous specification for different shared resource schedulingprotocols is provided: no lock, blocking, the well-known basic priority inheritance pro-tocol (BIP) and the priority ceiling protocol (PCP). The authors also show how variousproperties related to determinism, schedulability, or the absence of inter-locking can beautomatically model-checked on given architecture models. This results in an automatedtranslation of AADL models into a purely boolean synchronous (Lustre) scheduler, thatcan be directly model checked, possibly with the actual software.

4.3 Summary and comparison

In this section, we will make a short comparison of these related works, mainly from theobjective and some characteristics.

Using MARTE to model AADL mainly concerns the two communication protocols:immediate and delayed, for a purpose of end-to-end flow latency analysis. One char-acteristic of this work is: to define once, and for all, a model library for AADL withMARTE [119]. The end-user is not expected to enter into the detail about this library.Compared to our work, this work makes efforts to build a generic simulator specificallyfor AADL, but targeting a formal analyzable language remains a perspective.

Modeling AADL in Fiacre focuses on the objective of model verification, since Fiacreis a front end of Tina verification toolset. Compared to BIP, Fiacre has less powerfulconstructs but has good compositional and real-time properties. It offers basic conceptscoming from timed transition system which permit the expression of real-time featuresquite easily [138].

The translation from AADL to BIP allows simulation of AADL models, as well asapplication of verification techniques, i.e., state exploration or component-based deadlockdetection. This work takes into account threads, processes and processors as well asBehavior Annex, but do not include the AADL communication protocols.

Modeling AADL in TASM allows presenting timing semantics of the AADL behav-ioral annex using TASM, which is based on abstract state machines extended with re-source consumption annotations. This work focuses on formal verification and analysisof AADL models with regards to mode change. TASM offers more abstract resourceconsumption mechanisms, but hardly supports some scheduling patterns [140]. Resourcemanagement allows the specification of a fair preemptive scheduler. However, specifyingother scheduling policies has to be evaluated [137].

The translation from AADL to SystemC aims at simulation and performance analysis.An AADL SystemC simulation tool is developed. However, the behavior specificationshave not been taken into consideration.

The objective of code generation from AADL to C code developed by Ocarina is fordistributed high-integrity application. The generated code can be run on both POSIX orRTEMS platforms. With the PolyORB-HI-C tool, the Simulink blocks can be used asAADL subprograms. In that case, the generated code from AADL automatically callsthe generated code from Simulink. A transformation of Simulink blocks (used as AADLthreads) in Signal is also implemented in our cooperation work in project CESAR [35].We use AADL to model the architecture and Simulink to model the functional applica-

103


tions. A case study is implemented for the simulation and analysis.Compared to our work, the translation of AADL models into ACSR focuses on formal

analysis of timing properties, including schedulability analysis, of AADL models. A setof failing scenarios in case the system is non-schedulable are offered.

The goal of modeling ARINC653 using AADL is to propose an appropriate MDE-based development process to capture architecture requirements using AADL and its AR-INC653 annex. It models ARINC653 architectures in AADL, while our work is the in-verse: we model an AADL system in Signal in a framework of ARINC653. There aremany similarities between these two works, i.e., the ARINC653 partition is mapped toan AADL process in this work, while the AADL process is translated to an ARINC653partition in our transformation, and the ARINC653 process is mapped to an AADL threadin this work, while we translate the AADL thread to an ARINC653 process presented inSignal, etc. Of course, many differences exist, for example, an ARINC653 module is rep-resented by an AADL processor in [73], but in our transformation, we interpret an AADLprocessor as a scheduler for scheduling the processes (threads) that are bound to it. Thevirtual processor has not been considered in our work.

The main objective of AADL2SYNC is to perform simulation and validation that takeinto account both the system architecture and the functional aspects. This work buildsa simulator expressed in a synchronous language: Lustre. Various asynchronous aspectsof AADL, e.g., task execution time and clock drifts, are taken into account. Comparedto Signal, Lustre is a purely synchronous model of computation. On one side, a quasi-synchronous communication protocol is used to emulate asynchrony to resolve this limi-tation, still its expressive capability is limited. On the other side, an automated translationof a purely synchronous scheduler is defined in [98], that can be directly model-checked.

Compared to these works, our work has multi-purpose objectives. We model theAADL system in Signal in order to perform formal verification (using Sigali), simulation(using VCD), and C/Java code generation, since the polychronous model of the Signallanguage offers formal support for analysis, verification, simulation and code generationin the Polychrony platform. Furthermore, the polychronous model provides models andmethods for a rapid, refinement-based, integration and a formal conformance-checking ofGALS architectures [152].

4.4 Conclusion

We introduced some background of AADL in this chapter. AADL is a well-defined soft-ware/hardware co-design language which supports model-based embedded system engi-neering. The formalization of AADL model in other languages is required, in order toprovide formal property validation, schedulability analysis, resource sharing, and verifi-cation. We list some of the AADL model transformations to give an idea of the relatedworks. A comparison of these works is given in the final section.

104

Chapter 5

From AADL components to Signalprocesses

Contents5.1 Transformation chain . . . . . . . . . . . . . . . . . . . . . . . . . . 107

5.2 Transformation principles . . . . . . . . . . . . . . . . . . . . . . . 107

5.3 From abstract logical time to more concrete simulation time . . . . 110

5.3.1 Modeling computation latencies . . . . . . . . . . . . . . . . . 111

5.3.2 Modeling propagation delays . . . . . . . . . . . . . . . . . . . 112

5.3.3 Towards modeling time-based scheduling . . . . . . . . . . . . 113

5.4 Thread modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

5.4.1 Interpretation of a thread . . . . . . . . . . . . . . . . . . . . . 115

5.4.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 117

5.5 Processor modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

5.6 Bus modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

5.7 System modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

5.8 Other components modeling . . . . . . . . . . . . . . . . . . . . . . 130

5.8.1 Process modeling . . . . . . . . . . . . . . . . . . . . . . . . . 130

5.8.2 Subprogram modeling . . . . . . . . . . . . . . . . . . . . . . 132

5.8.3 Data modeling . . . . . . . . . . . . . . . . . . . . . . . . . . 133

5.8.4 Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

5.9 Port and port connection modeling . . . . . . . . . . . . . . . . . . . 135

5.9.1 Port modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

5.9.2 Port connection modeling . . . . . . . . . . . . . . . . . . . . 136

5.10 Towards AADLv2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

5.11 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

CHAPTER 5. FROM AADL COMPONENTS TO SIGNAL PROCESSES

Embedded systems are an integral part of safety critical systems. On one side, ar-chitectural design and early analysis of embedded systems are two of the major chal-lenges for designers using modeling languages (for example, AADL). On the other side,synchronous languages (such as Signal) have been used successfully for the design ofreal-time critical applications, to significantly ease the modeling and validation of soft-ware components. The synchronous parallel composition helps in structuring the model,without introducing non-determinism. Their associated toolkits provide formal transfor-mation, automatic code generation and verification.

AADL provides a standardized textual and graphical notation for describing softwareand hardware system architectures and their functional interfaces. The language is aimedat high level design and evaluation of the architecture of embedded systems. Such systemsare described as an assembly of software components that are mapped to an executionplatform in AADL.

Although AADL allows one a fast design entry and software/hardware co-design, sys-tem validation and verification is a critical challenge. In order to support the virtual proto-typing, simulation and formal validation of early, component-based, embedded architec-tures, we propose to use formal methods to ensure the quality of system design. Our majorobjective is to perform simulation and validation that take into account both the systemarchitecture and the functional aspects. We consider the case where software componentsare implemented in the synchronous programming language Signal. We propose a modelof the AADL into the polychronous model of computation of the Signal programminglanguage. This modeling is based on the IMA architecture. Since a thread is the mainexecutable component and it is the only component that can be scheduled in AADL, ourwork mainly focuses on the thread component (especially the periodic thread) and its as-sociated components modeling, e.g., the execution model, communications, behaviors,etc.

This chapter focuses on the synchronous modeling of AADL components in the IMAarchitecture, so that an AADL model can be translated into an executable model of syn-chronous dataflow language. This modeling is a contribution to bridge the gap betweenasynchronous and synchronous languages.

This translation can be seen as a basis to establish a formal semantics of AADL exe-cution model and to perform verification of AADL models. For this purpose, we presentthe abstract transformation from asynchronous model to a synchronous model. The gen-eral modeling approach and transformation principles are first presented in section 5.1and 5.2. Then in section 5.3, we depict the problems in this asynchronous-synchronoustransformation, and also give the possible solutions in the Signal programming language.We show how an AADL architecture can be automatically translated into a synchronousmodel in Signal.

Our approach is based on the IMA modeling concepts. We use the Signal library ofAPEX ARINC services to represent the AADL architectures and components, and alsothe communications between the components. We give an implementation of a subsetof the AADL components. Since thread is the main executable and schedulable compo-nent, thread model is first presented in section 5.4. Processor is responsible for schedul-ing threads, hence processor modeling is presented just after the thread modeling in sec-tion 5.5. Bus is the communication among execution platform components, so the mod-

106

5.1. TRANSFORMATION CHAIN

eling of bus is then presented in section 5.6. System modeling is presented in section 5.7.The modeling of other components is briefly presented in section 5.8. Port connectionsenable directional exchange of data among components, their modeling is presented insection 5.9. Finally, the concluding remarks are given.

5.1 Transformation chain

The transformation of AADL models into synchronous specifications is separated in twosteps: firstly, a transformation of AADL models into synchronous models; then, genera-tion of synchronous code from synchronous models obtained from the first step.

We formalize the transformation of AADL by isolating the core syntactic categoriesthat characterize its expressive capability: systems, processes, threads, subprograms, data,devices, processors, buses and the connections.

Figure 5.1 illustrates the automatic model transformation chain from AADL model toSignal model, so that the final executable code, such as C or Java, is generated. In thetransformation, SME models, which conform to the Signal meta-model, are considered asintermediate models.

GRAPHICAL AADL Ecore model

SME Signal

Eclipse OPENEMBEDDOSATE/ADELE

AADL model

Code generation



codeSignal/Polychrony model

Csyntax/ semantics

transformation

code

AADL modeling Polychrony frameworkTEXTUAL

AADL codemodel

transformationOSATE

Ecore model

transformation

Code generation

Figure 5.1: A global view of AADL-SME transformation chain

The AADL model can be either presented as textual or graphical specifications. Tech-nically, using the AADL graphical editor ADELE, the graphical xx.adeleli model cangenerate xx.aadl text code. The xx.aaxl ecore model, which conforms to the AADL meta-model, can be generated automatically from the xx.aadl in OSATE toolkit.

The AADL ecore model is translated to SME Signal model using ATL (Atlas Trans-formation Language) defining the transformation rules. The details of the transformationwill be presented in the next subsections. The SME model can be transformed to Signalcode. After compilation, the executable C (or Java/C++) code is generated.

5.2 Transformation principles

This model transformation is based on the studying of the similarity relationship betweenAADL and APEX-ARINC services. The transformation from the AADL model to Signalis based on the IMA Architecture [121].

ARINC653 (Avionics Application Standard Software Interface) is a standard thatspecifies an API for software of avionics, following the IMA architecture. It defines an

107


APplication EXecutive (APEX) for space and time partitioning. An ARINC partition is alogical allocation unit resulting from a functional decomposition of the system.

As mentioned in Chapter 2, a main feature of ARINC653 is the partitioning: severalexecutive units (processes) can be logically hosted on a single partition. They are onlyallowed to share the resources in this partition. This feature is similar to AADL process:an AADL process represents a protected address space, a space partitioning where pro-tection is provided from other components accessing anything inside the process. Hence,an AADL process can be modeled by the ARINC partition.

Similarly, an AADL thread is the main executable unit executed in a process, whilean ARINC process is the executive unit in the partition. Therefore, this relation makes itpossible to model the AADL thread by the ARINC process.

The processor is responsible for the scheduling of threads in AADL, and it may havememory subcomponents. It could correspond to an "infrastructure" containing a sched-uler and local resources. For a simple implementation, we consider it as the schedulerin ARINC. The difficulty is that the scheduling in ARINC653 is divided in two levels:the module_level_OS and partition_level_OS (refer to Section 3.2.2). The former one isa static scheduling: the modules are scheduled based on a predefined configuration ta-ble. However, the partition_level_OS is still suitable or at least partially suitable (withsome improvements) for modeling the scheduling of the AADL threads in the same pro-cess. The scheduler in a partition_level_OS can either be static or dynamic, dependingon the chosen scheduling protocol. In general, the ARINC scheduling policy is prioritypreemptive. The priorities could be fixed, e.g., Rate_Monotonic, or dynamic, e.g., Ear-liest_Deadline_First. In Section 5.5, a general purpose scheduler structure referring topartition_level_OS is modeled in Signal, the detailed scheduling policy is left for furtherdevelopment (e.g., using external C code implementation). Schedulability analysis, com-parison, and other analyses, such as WCET/BCET, can be performed based on differentschedulers. A specific static scheduler is given in Appendix A as a simple implementation.

Other mechanisms defined in ARINC, e.g., the communication mechanism (queuingand no-queuing), can be used as some implementation of AADL connection.

AADL Signalthread ARINC process

process ARINC partition

port bounded FIFOdata port connection Signal process (according to the connection type)

processor ARINC partition_level_OS

data type Signal data typesystem Signal process consisting of sub-processes

bus Signal communication processdevice Signal process

Table 5.1: Basic transformation principles

Basic transformation principles are first given in Table 5.1. For example, a threadis an executable unit with behavior specifications described in either target language orbehavior annex. The detailed execution behavior will be presented in Chapter 6. In this

108

5.2. TRANSFORMATION PRINCIPLES

chapter, we only consider the thread execution temporal semantics. A thread is associatedwith some temporal properties: period, dispatch, start, complete and deadline. A threadP can be defined by these properties, noted as S PS , and its internal behavior transition-s/actions T/S : P =< S PS ,T/S >. The interpretation will be the composition of temporalproperties S PS and actual execution transitions/actions T/S . The thread is dispatched atdispatch time. The executions are activated at start time, and the outputs are availableto send out at complete or deadline time. These properties are implemented in the S PS

timing environment. The transitions/actions T/S are implemented in a process S PT . Thesignals that enter or depart S PT are based on these temporal signals (generated by S PS )as specified in the AADL properties. The interpretation is described in Section 5.4.

Door1

war_pres

lockedhandle

Door2

war_pres

handlelocked

LGS

in_fligh

on_ground

DPS

dps

doors_processdoor1_locked

door1_handle

door2_locked

door2_handle

in_fligh on_ground dps

door1_warn_pres

door2_warn_pres

cll

door1_info_ECAM door2_info_ECAM

OCU

cll

door1_info_ECAM door2_info_ECAM

door_handler1

lockedhandle

on_grounddps

in_flighwarn_pres

cll

info

door_handler2

warn_pres

cll

infolockedhandle

in_flighon_grounddps

doors_mix

clldoor1_locked

door2_locked

Figure 5.2: A simple illustration of SDSCS system

The details of each component modeling will be given in the following sections. Inthis section, we will show an example to just give a first idea of the transformation. TheSDSCS system (the detailed description can be found in Chapter 8 and Appendix A) inFigure 5.2 has one process doors_process processing (or sending) the messages from (orto) the devices: Door1, Door2, LGS, DPS and OCU. The doors_process consists of threethreads: door_handler1, door_handler2 and doors_mix, computing and generating theoutputs.

The corresponding Signal (within ARINC architecture) model is partially shownin Figure 5.3. The process doors_process is translated to an ARINC partition parti-

tion_doors_process. The three compositional processes, process_door_handler1, pro-

cess_door_handler2 and process_doors_mix, are corresponding to the three threads inFigure 5.2. The scheduler is modeled by the partition_level_OS. The devices are imple-mented as Signal processes outside the partition providing external interface.

109


systempartition_doors_processDoor1

Door2

SPS1SPT1


SPS2SPT2


SPS3SPT3

process_doors_mix

scheduler(partition_level_OS)

LGSDPS

OCU

Figure 5.3: Signal model of the simple SDSCS system

5.3 From abstract logical time to more concrete simula-tion time

A high-level view of the transformation from AADL to synchronous model is given inthis section. Synchronous paradigm provides an idealized representation of parallelism.While AADL takes into account computing latencies and communication delays, allowingto produce data of the same logical instants at different implementation instants. Thoseinstants are precisely defined in the port and thread properties. To tackle this problem, wekeep the ideal view of instantaneous computations and communications moving comput-ing latencies and communication delays to specific “memory” processes, that introducedelays and well suited synchronizations. As a consequence, various properties result inexplicit synchronization signals. Using the polychronous framework to model abstractlogical time has to resolve the problems described in the following subsections.

First we briefly recall three simple Signal operations that will be used later.

• Delay. This operation (the ‘$’ operator of Signal) gives access to past values ofa signal. The delayed signal of s has the same clock as s. This delayed signal,s$1 init s0, takes the previous value of s.

• Sampling. The sampling operation (s when b) returns the value of s when b is true.The clock of s when b is less frequent than the clock of s and the clock of b.

• Cell. The cell operation is introduced for repeating some signal s on the instants ofanother boolean signal b. The result contains all values of s, and also the value ofprevious s when b is true. The clock of s cell b is the union of clock of s and ofwhen b (Figure 5.4).

110

5.3. FROM ABSTRACT LOGICAL TIME TO MORE CONCRETESIMULATION TIME

cellsb

o o := s default o$ o ^= s ^+ when b

Figure 5.4: Cell example.

5.3.1 Modeling computation latencies

Problem A main feature of polychronous programs is the logical instantaneous exe-cution, with respect to logical time. Components in polychronous model take no logi-cal time: the outputs are immediately generated when the inputs are received. While inAADL, a thread may perform a function or a computation for a specified time interval,defined by the timing properties. Therefore, modeling AADL in the polychronous frame-work requires some adapter for interfacing abstract logical time and concrete simulationtime.

With each output o of a process P, we associate a process P_o the output of whichis the value of o delayed until its Output_Time represented by the input event signal Out-

put_Time occurs. Due to scheduling, a process that is logically synchronous to a dispatchsignal “dispatch”, can be actually started later. Thus, for each process P, we associate aninput event signal “Start_Thread” and execution of P is synchronized to Start_Thread.

io'Start_Thread

Output_Time

P at

P_o P_o = defer_Output (P) process P_o = (? i; event Start_Thread,Output_Time; ! o'; ) (| o := P(i,Start_Thread) | o' := at(o,Output_Time) |) where o; end;

o

Figure 5.5: Modeling a time consuming task.

Solution We propose to translate P_o as a logical instantaneous process P and to de-lay P’s outputs until they are (AADL) available. This function is noted as P_o =

de f er_Output(P). In Figure 5.5, the modeling principle is that: the task (e.g., a thread)itself is modeled by a Signal process P (which represents the synchronous program withactivation condition), activated by an activation condition Start_Thread, which will bespecified in the next subsection. The output of P is immediately available when it is com-puted. An additional delay component (the at operation) is introduced to hold the value.The output will be delayed and available until the next occurrence of the output enablingclock Output_Time.

A new operation is defined to express this delay action: at. Figure 5.6 shows its graph-ical representation. The process at is defined as a composition of a cell and samplingoperations (the complete definition of this function is listed on the right of Figure 5.6):

o := i cell e when e

111


This at operation repeats the input signal i on the instants of activation signal e. Theclock of the result output o is synchronous with the activation signal e. The value of theoutput takes the most recent value of i.

i oe

cell whenat process at =

(? i; event e; ! o) (| mm := i cell e | o := mm when e |) where mm; end;

Figure 5.6: The “at” operation

In AADL, the output of a thread is available and transferred to other components atcompletion time by default, or at deadline time in the case of delayed port communication.Therefore, the clock of Output_Time is based on the type of the communication, whichwill be explained in later sections.

5.3.2 Modeling propagation delays

Problem During the execution of synchronous programs, each significant event or sig-nal is precisely dated with respect to other signals, and with respect to the sequence ofsteps. While for AADL model, the input available time can be determined by differentproperty values (a more detailed description is presented in Section 5.4).

Solution The Signal language provides features for expressing activation (the clocks ofsignals). The main idea to model AADL unprecisely known time within a synchronousframework is to use additional inputs, called activation condition, to model the propaga-tion delays.

Pi oStart_Thread P_i

at

P_i = retime_Input(P) process P_i = (? i; event e; ! o;) (| i' := at(i,e) | o := P(i') |) where i'; end;

i'

Figure 5.7: Activation condition.

An activation condition (for start time) is used to express the activation of a thread,either periodic or aperiodic. In Figure 5.7, the modeling takes a synchronous programP (which is the transformation of a thread), an activation event input Start_Thread,and produces a new conditional activation program P_i. This function is noted asP_i = retime_Input(P). The activation program P_i is represented as follows: it in-troduces an event input Start_Thread, the input i is resynchronized with Start_Thread

before entering synchronous P. So that, the synchronous program P is activated by theactivation condition Start_Thread.

112

5.3. FROM ABSTRACT LOGICAL TIME TO MORE CONCRETESIMULATION TIME

5.3.3 Towards modeling time-based scheduling

Problem Based on the activation and delay mechanism as described in the previoustwo subsections, another problem comes out: how to control these activation and delayconditions, and from where they are generated.

at atP

SPS_P

scheduler

at atQ

SPS_Q

dispatch_P dispatch_Q

i1

Start_Thread_P Output_Time_P Output_Time_Q

o1 i2o2P_i P_o Q_i Q_o

process SPS =(? event dispatch; ! event Start_Thread,Output_Time;)spec (| dispatch --> Start_Thread | dispatch --> Output_Time

%Start_Thread and Output_Time are present some ticks after dispatch, depending on the timing properties% |);

Start_Thread_Q

Figure 5.8: Modeling asynchronous composition.

Solution To solve this problem, we suppose that each thread P is associated with atiming environment S PS (Figure 5.8), which computes the start and completion clocksand other timing control signals of the thread, once it is activated by the scheduler. Aswe have mentioned in Chapter 2, each thread has some associated timing properties, suchas Deadline, Execution_Time and so on. Once the thread is dispatched, the start andcompletion time can be calculated according to the specified timing properties.

Figure 5.8 shows a composition of two threads P and Q presented in Signal. Eachcomponent is activated by its own activation event Start_Thread. The two activationevents Start_Thread_P and Start_Thread_Q are unrelated if there is no further control,which in this case, will result in non-deterministic execution. To avoid this situation, atiming environment process S PS is added for each thread and activated by the scheduler.Once S PS is triggered by the signal dispatch from the scheduler, it generates activationclock Start_Thread to activate the component, and computes the output available clockOutput_Time that satisfies the specified clock properties.

Thus the input and output enabling signals Start_Thread and Output_Time are pro-vided by the timing environment process S PS : this program calculates the input and out-put available time, according to the timing specification, once the thread is scheduled. Theinner synchronous process P is started when the activation signal Start_Thread is present,and the outputs are available for sending when the signal Output_Time is present. Theright part of Figure 5.8 shows an abstract specification of the process S PS . The signalsStart_Thread and Output_Time are present some ticks after the dispatch of the thread.

The scheduler will decide when and which component can be activated. At eachinstant, only one component may be running. The scheduler calculates on the actualscheduling policy, and grantees the generated timing environment activations never occurat the same instant.

113


Having resolved these problems, now we can model the AADL threads and other com-ponents easily. The component modeling will be arranged in the following order: first,the main executable and schedulable component, which is the thread; then, the proces-sor, which is responsible for scheduling the threads; then, the communication executioncomponent, the bus, and the system; finally, the other components.

5.4 Thread modeling

Threads are the main executable and schedulable AADL components. A thread Th rep-resents a concurrent schedulable unit of sequential execution through source code. Tocharacterize its expressive capability, a thread Th encapsulates a functionality that mayconsist of ports, connections, properties, behavior specifications and subprograms thatcan be called by the thread.

Th = < P, C, R, S u, T/S >

• P ∈ F is the feature that consists of the ports, which declares the interface of thethread.

• C = P × P is the port connection, which is an explicit relation between ports thatenables the directional exchange of data or event among its ports and other compo-nents.

• R ∈ R is the properties, which provide runtime aspects. For example, propertyPeriod declares the period for a periodic thread, and Compute_Deadline specifiesthe maximum amount of time allowed for the execution of a thread’s computationsequence.

• S u is the subprograms called by the thread.

• T/S is the transition system defined with actions to provide the functional behavior.

The execution semantics of an AADL thread is as follows:

1. Read and freeze inputs. The content of incoming data is frozen for the duration ofthe thread execution. By default, the input is frozen at the time of dispatch. If theInput_Time property is specified, it is determined by the property value. The valuecan be Dispatch_Time (the default value, t = 0), Start_Time (the time is within aspecified time range, Start_Timelow ≤ t ≤ S tart_Timehigh), Completion_Time (inputis frozen at a specified amount of execution time relative to execution completion,ccomplete + Completion_Timelow ≤ t ≤ ccomplete + Completion_Timehigh) and None

(input is not frozen). Any input arriving after this frozen time becomes available atthe next input time.

2. Execute and compute. When a thread action enters in computation state, the execu-tion of the thread’s entrypoint source text code sequence is managed by a scheduler.The actions can be external source text code, or represented by AADL behaviorannex (which will be presented in next chapter).

114

5.4. THREAD MODELING

3. Refresh and make available the actual output. The output is transferred to othercomponents at complete time by default (at deadline time in case of delayed dataport connection) or as specified by the value of the Output_Time property. Thusthe value produced by the thread is available only for the threads that start after thecompletion of thread.

Figure 5.9 shows the default execution timing of an AADL thread.

��tch start complete

input frozen output availablecompute

Figure 5.9: Default execution timing of a thread

5.4.1 Interpretation of a thread

Before starting the interpretation, let us recall the process concept of APEX ARINC. InAPEX ARINC, processes represent the executive unit for an application. A process isa programming unit contained within a partition which executes concurrently with otherprocesses of the same partition. It comprises the executable program, and attributes suchas priority, period and deadline. These processes share common resources and executeconcurrently within a partition.

An AADL thread Th is translated to an ARINC process P (a Signal process). Thetiming aspects of the thread will be translated as process attributes. The notation I isused to represent the translation.

I(Th) = P where Th is a thread, P is a Signal process representing an ARINC process

The detailed transformation from a thread Th to an ARINC process (represented as aSignal process) P can be obtained as follows, in these successive steps:

Interpretation steps

1. An AADL thread Th is firstly translated to a Signal process SP, which correspondsto an ARINC process, from the point of view of functional structure. SP has thesame input/output flows as Th, plus an additional tick, which is an internal tickcoming from the processor (the scheduler). This tick will be used later in the trans-formation of the behaviors or inside actions/computations. Each input (resp. out-put) port corresponds to an input (resp. output) signal. The actual inside actions,represented by the behavior specification, will be described in the next chapter.

In this step, we only consider the interface of the components. The functional im-plementation will be presented in Chapter 6. SP is a synchronous interpretation ofTh. It does not correspond to the real case of the actual AADL thread. The timingspecifications will be taken into account in the next step.

115


Th yx

SPSstartsuspend

resume

dispatch

SPT

x ly

startSPat

start at

complete

lxy

Pinner timing environment

completedeadline

deadline

tick

Figure 5.10: Translation of AADL thread with Signal thread.

2. According to the AADL specification, the input signals of a thread are transmittedfrom the sending threads at the complete time of these threads. Since the completionof each thread may take place at different instants, the input signals are not guaran-teed to be synchronized. Due to the different timing semantics between AADL andSignal, timing properties of the AADL thread are translated by another Signal pro-cess, SPT (Figure 5.10), which plays the role of timing semantics interface betweenAADL and Signal.

Three main functions of SPT with regard to SP are:

(a) Memorize the input signals, which are received and frozen at the dispatchtime, and preserve them until the thread is activated by the start event.

(b) Activate the functional Signal process SP at the time of start. So that the inputsignals of SP are all synchronized at the clock of start.

(c) Memorize the outputs of the thread until the time of completion (when theevent s_complete is arrived).

The memorization of signals and activation of thread are adopted here to bridge theAADL thread semantics and the synchronous model.

3. The execution of a thread is characterized by some real-time aspects. The timingproperties specified in the thread, including period, dispatch time, start time, etc.,are useful for the thread scheduling and execution. The thread will be scheduledfollowing these properties. Due to this real-time control semantics, a new process

SPS (Figure 5.10) is added, inside which the timing control signals are automati-cally computed once it is activated. When it receives the scheduling signals (e.g.,dispatch) from the real thread scheduler, it starts to compute its own timing signalsfor activating and completing the process SPT.

116


SPS records all the temporal properties of the thread, e.g., Period=10ms, Com-

pute_Dealine=8ms, and calculates the timing signals (start, deadline. . . ). Whenit receives a scheduling signal (e.g., dispatch), a deadline signal is generated 8msafter dispatch (this is represented by 8 logical ticks in the example).

5.4.2 Implementation

As shown in Figure 5.10, an AADL thread Th is implemented as a Signal process, in-cluding an internal timing environment SPS, and a synchronization process SP which isincluded in a container process SPT:

I(Th) = (| S PS | S PT |)

• SPS is a timing environment for the thread. It interfaces the scheduler and thethread. It receives the scheduler control signals, and computes the time of whenstarting execution, when completing, when ending deadline. When the thread isscheduled, SPS is triggered by the dispatch signal, it will generate the executiontiming signals for SPT.

• SPT is an interface for synchronizing and activating the inputs and outputs of syn-chronous interpretation process SP. Its interface contains the declaration of the IOflows of SP, and some additional input events, e.g. start, complete.

S PT = (| IM | S P | OM |) where Ldecl end

• IM is the composition of the memorization of each input signal x bylx:=at(x, start), where at is the process we have already introduced in previ-ous section, defined as lx:=x cell start when start.

• OM is the composition of the “retiming” of every output signal ly of process SP byy:=at(ly, complete) (by default) or by y:=at(ly, deadline). So that thesynchronous outputs are delayed until the complete (or deadline) time.

• SP is the synchronous interpretation of thread Th. It is guaranteed that SP is ac-tivated at the time of start by requiring each input appearing at start time beforeentering SP.

• Ldecl is the declaration of the signals lx,...; ly,... that have been introduced.

Abstract rules An abstract description of the rules for the transformation of threadTh = < P, C, R, S u, T/S > into Signal process (as APEX ARINC process) is given.The notation I represents the interpretation.

1. The thread component is translated as an ARINC process, parameterized byI(P), I(C), I(R), I(S u), I(T/S ). The notation Programparameters is used to notethat the parameters will serve in the definition of the Program. The role of theseparameters is further explained below. The functionality of the thread is translatedinto two subprocesses, S PS and S PT , within the process.

117


I(Th) = (S PS I(R) | S PTI(P), I(C), I(S u), I(T/S ))

2. The subprocess S PS is parameterized with the properties R. The interface of S PS

includes the inputs tick, dispatch, suspend, resume and outputs start, complete,

deadline.

S PS = (? event tick, dispatch, suspend, resume;

! event start, complete, deadline; )

The properties r ∈ R, e.g., Input_Time, Output_Time, are interpreted in S PS . Thevalues of these properties (Input_Time_value, Compute_Execution_Time_value,

Output_Time_value) are used to count the logical ticks of the start and completiontime of the thread.

count := 0 when dispatch

default count$ + 1 when tick

default count$

S tart := true when (count = Input_Time_value)

Complete := true when (count = Compute_Execution_Time_value)

Deadline := true when (count = Output_Time_value)

3. The subprocess S PTI(P), I(C), I(S u), I(T/S ) is parameterized withI(P), I(C), I(S u), I(T/S ). The ports P are translated as the inputs/out-puts, and the connections, subprograms and behaviors are translated in thesubprocess S PT . The detail of these parameters are explained below.

4. The in/out ports P of the thread are translated to Signal inputs/outputs (the interpre-tation is presented in section 5.9.1). The interface of the ARINC process includesthese signals and the event inputs tick, dispatch, suspend, resume received from thescheduler. The value p.direction denotes the direction of a port p.

inputs = {tick, dispatch, suspend, resume} ∪ I(p) ∀p ∈ P, p.direction = in

outputs = {I(p)} ∀p ∈ P, p.direction = out

5. The transitions/actions T/S are interpreted into a synchronous process S P follow-ing the steps presented in Chapter 6. This synchronous process S P is encapsulated

118


in the subprocess S PT . The value c.type denotes the connection type of connectionc, which can be either immediate or delayed.

S PT = (IM | S PI(S u),I(C) | OM)

where

S PI(S u),I(C) = I(T/S )

IM = (iipk1:= at(I(pk1), start) | iipk2

:= at(I(pk2), start) | . . . )

for all pk j∈ P, s.t. pk j

.direction = in

OM = (OMimm | OMdelayed)

OMimm = (oopk1:= at(I(pk1), complete) | oopk2

:= at(I(pk2), complete) | . . . )

for all pk j∈ P, s.t. ∃c ∈ C, c = (p1, pk j

), c.type = immediate, pk j.direction = out

OMdelayed = (oopk1:= at(I(pk1), deadline) | oopk2

:= at(I(pk2), deadline) | . . . )

for all pk j∈ P, s.t. ∃c ∈ C, c = (p1, pk j

), c.type = delayed, pk j.direction = out

6. Each subprogram su ∈ S u is interpreted as some Signal process PPsu as presentedin section 5.8.2:

I(su) = PPsu(? In1, . . . Inm; ! Out1, . . .Outn; ) PPsu_BODY

It is invoked as an instance in the subprocess S P:

(| o1 := Out1 | . . . | on := Outn | PPsu_BODY | In1 := i1 | . . . | Inm := im)

A connection in a thread c = (p1, p2) ∈ C connects the ports (parameters) amongthe invoked subprogram processes. Such connection is interpreted as an assignmentconnecting the input/output instances of the subprogram models:

I(p2) := I(p1)

Example The thread doors_mix shown here is a periodic thread. Only the port featuresare listed.

thread doors_mix

features

cll1: in data port behavior::boolean;


cll: out data port behavior::boolean;

end doors_mix;

thread implementation doors_mix.impl

properties

119



Period => 50 ms;

end doors_mix.impl;

The corresponding Signal code is shown in Figure 5.11. The thread is firstly translatedto a Signal process SP_doors_mix, in which the synchronization is not considered. Thetwo inputs cll1 and cll2 are guaranteed to be synchronized in a synchronization containerSPT_doors_mix.

Figure 5.11: Signal code of the thread

The two inputs cll1 and cll2 are delayed until start event occurs, seelcll1 := at(cll1,start). Therefore, the input signals entering SP_doors_mix aresynchronous. The output generated by SP_doors_mix is also delayed until complete, seecll:= at(lcll, complete).

Since these timing events are not received directly from the scheduler, the processSPS_doors_mix is used to generate these events, once it receives the scheduling sig-nals, dispatch, suspend, resume. The whole transformation is integrated in the processT_doors_mix.

120

5.5. PROCESSOR MODELING

5.5 Processor modeling

Processor component is an abstraction of hardware and software responsible for executingand scheduling threads. The property Scheduling_Procotol defines the way the processorwill be shared between the threads of the application. The possible scheduling protocolscould be: Rate_Monotonic, Earliest_Deadline_First, Deadline_Monotonic or other userdefined schedulers.

In ARINC services, processes run concurrently and execute functions associated withthe partition in which they are contained. The partition_level_OS selects an active process

within the partition whenever it executes, that is to say, at any time, there is only oneprocess that is activated. The scheduling policy for processes is priority preemptive.

The processor can be abstracted as the scheduler of the AADL processes/threadswhich are bounded to the processor, corresponding to the partition_level_OS in Signal,which is the control for the concurrent execution of processes within the partition. Forthe Rate_Monotonic scheduler we consider in the implementation, we can set the ARINCprocesses priorities according to the thread period, then the priority preemptive schedulercan be used.

As mentioned before, the ARINC scheduling policy is priority preemptive. The prior-ity can be fixed or dynamic, depending on the scheduling policy. Each time the scheduleris active, the active process is the one in ready state which has the highest priority. Todescribe the scheduling and the choice of the active process (Figure 5.12), two additionalservices are considered for the scheduling: PROCESS_SCHEDULINGREQUEST andPROCESS_GETACTIVE.

ready processesactive process

...

...scheduler(...)

process descriprtion

...

Figure 5.12: A process scheduler module

• The PROCESS_SCHEDULINGREQUEST service is invoked when the schedulerstarts to choose an active process, or a process requests for rescheduling. It has aninput event signal request and an output boolean signal diagnostic. The receivingof request signal will trigger a rescheduling. The output diagnostic is produced inthe same instant. It is set to be true when the rescheduling is successful, otherwiseit takes the value false. The interface of this service is given here.

process PROCESS_SCHEDULINGREQUEST =

( ? event request; ! boolean diagnostic; )

spec (| (| request --> diagnostic |)

121


| (| request ^= diagnostic |)

| )

pragmas

C_Code "&o1 = GLOBAL_PROCESS_MANAGER -> ProcessScheduling Request()"

end pragmas;

• The PROCESS_GETACTIVE service is invoked after each rescheduling request forgetting the information of the new active process. The Signal code is shown below.The input request denotes a receiving request. The output process_ID returns theactive process identifier.

process PROCESS_GETACTIVE =

( ? event request;

! ProcessID_type process_ID;

ProcessStatus_type status;)

(| (pid, pstatus, ok) := prag_PROCESS_GETACTIVE{}()

| process_ID := pid when ok

| status := pstatus when ok

| ok ^= request

|)

where

ProcessID_type pid;

ProcessStatus_type pstatus;

boolean ok;

process prag_PROCESS_GETACTIVE =

( ! ProcessID_type process_ID;

ProcessStatus_type status;

boolean ok;)

spec (| process_ID ^= status ^= when ok |)

pragmas

C_Code "&o1 = GLOBAL_PROCESS_MANAGER -> ProcessGetActive(&o2, &o3)"

end pragmas;

Interpretation We give an abstract interpretation of the processor in this part. Aprocessor Pr is interpreted into a Signal process, and the ARINC service PRO-

CESS_CREATION is invoked for each one of the threads which is bound to this proces-sor (property actual_processor_binding). ARINC system services, PROCESS_START,PROCESS_SCHEDULINGREQUEST, etc., are used for the scheduling.

1. The Processor is transformed into a scheduler, which corresponds to the parti-

tion_level_OS of the partition.

I(Pr) = (CREAT ION | S T ART | S CHEDULING | S US PEND)

2. CREATION. The ARINC processes (transformed from the threads) are recordedand created in the scheduler, with invocations to PROCESS_CREATION.

The timing properties are set as the attributes of the thread. For example, the periodof the process is set according to the property Period.

I(Rperiod) = Period := period_value

122

5.5. PROCESSOR MODELING

process PROCESS1_CREATION = ( ? event initialize; ! ProcessID_type pid1;) (| recorded1 := PROCESS_RECORDING{} (“T1" when initialize) | att1.Name := “T1" | att1.Base_Priority := 3 | att1.Period := 5.0 | att1.Deadline := 4.0 | att1 ˆ= when recorded1 | (pid1,ret1) := CREATE_PROCESS{}(att1) |) where boolean recorded1; ProcessAttributes_type att1; ReturnCode_type ret1; end;

T1period = 5.0 msdeadline = 4.0 ms

Figure 5.13: A process creation example

The period attribute is set to −1.0 when it is aperiodic.

Period := −1.0 if Value(Dispatch_Protocol) = aperiodic

The process priority is based on the scheduling policy. For example, in case ofRate_Monotonic, the process with the lowest period is set to the highest priority. InFigure 5.13, as an example, the attributes are set for a periodic thread named T1:the period and deadline attributes are set as the property of the thread, the priorityis based on the comparison of the thread periods.

3. START. The START() process is invoked from the ARINC library to start the processto be active.

4. SCHEDULING. When the partition is activated, the process schedulingstarts, a priority preemptive scheduling policy is provided. The PRO-

CESS_SCHEDULINGREQUEST() process in invoked.

5. SUSPEND. The process will suspend when it finishes. The SUSPEND_SELF()

process in invoked.

Abstract rules An abstract description of the rules for the transformation of processorPr into Signal process is given.

1. A processor component Pr is translated to a Signal process PP, parameterized bythe properties R that are defined in the bounded AADL processes and an activationsignal e.

I(Pr) = (CREAT IONI(R) | S T ART | S CHEDULINGe | S US PEND)I(R), e

2. The properties R used here are specified in the bounded processes or threads. Thefunction BindingProcess(Pr) is used to get the processes that are bound to pro-cessor Pr. The property Actual_Processor_Binding (noted RActual_Processor_Binding,

123


specified in system component) has two parameters, reference and appliesTo: thereferenced processes are applied to the specified processor.

BindingProcess(Pr) ={

ps ∈ Ps

∣

∣

∣

∣

∣

∃r = RActual_Processor_Binding ∈ R,

r.appliesTo = Pr ∧ ps = r.re f erence

}

From these processes ps, the period of each thread subcomponent can be obtained.The Period property is noted as RPeriod, and its value is noted as period_value. EachPeriod property is interpreted into a period attribute of the corresponding ARINCprocess in the CREATION subprocess.

I(RPeriod) = Period := period_value

3. The START, SCHEDULING and SUSPEND subprocesses invoke the processesfrom ARINC libraries: START(), PROCESS_SCHEDULINGREQUEST(), andSUSPEND_SELF(). When the activation signal e is received, the SCHEDULINGstarts to schedule the processes.

Example A Scheduler with two processes is given in Figure 5.14. The two processes

are created and started. Then a scheduling request is performed, and one process isselected as active process.

Figure 5.14: A scheduler example in Signal

First, the scheduler creates the two processes at initialize time, see lines 6 and 8.The PROCESS1_CREATION() and PROCESS2_CREATION() can be referenced on theexample of Figure 5.13. The attributes are based on properties of the threads. Once theyare created, they will be started, see process START() in lines 7 and 9. In this START

process, the process will be checked whether it is valid or not, and its state will be set toREADY.

124

5.6. BUS MODELING

The partition is activated when the received active_partition_ID equals to its Parti-

tion_ID itself, shown in line 10. After that, the scheduling starts when the partition is run-ning. The processes PROCESS_SCHEDULINGREQUEST and PROCESS_GETACTIVE

will be invoked. The UPDATE_COUNTERS in line 15 manages the time counters as-sociated with the processes. When all the processes end processing, the scheduler willsuspend itself, see line 17, by SUSPEND_SELF.

5.6 Bus modeling

A bus component represents hardware and associated communication protocols that en-able interactions among other execution platform components (i.e., memory, processorand device). For example, a connection between two threads, each executing on a sepa-rate processor, is done through a bus between those processors. This communication isspecified in AADL using access and binding declarations to a bus.

• Bus access. The execution platform components can declare a need for access to abus through a requires bus reference. For example,

processor Intel_Linux

features

f1: requires bus access bus1;

end Intel_Linux;

bus bus1

end bus1;

• Connection binding. Connections between software components that are boundto different processors transmit their information across buses. The property Ac-tual_Connection_Binding can be used to specify the actual bus applying to theport connections. For example, the connection conn1 is bound to bus bus1.

Actual_Connection_Binding => reference bus1 applies to conn1

The connection binding of a port connection conn1 is translated as the connectiontransfer through the bus process, see the top part of Figure 5.15. The output of process1 ispassed to bus transfer. The output from the bus is then sent directly to process2. The in-ternal processing of the bus can be implemented as simple data transfer, or more elaboratequeued or delayed transfer.

A bus connecting two components, for example, two threads which are bound to twodifferent processors, is not granted to be synchronous. If the bus connects the input di-rectly to the output, without any delay, there will be some problem. In AADL model, theinput of the receiver and the output of the sender may not appear at the same instant. Inthat case, a delay is needed for the adapter. In our transformation, as described before, theoutput and input of a thread are both buffered before becoming available.

125


task1 task2

component1 component2o i

busconn1

binding

bus

t1 t2

x1tb

x2t2

buffer_w buffer_rconnectxb x'bf1 fb

Figure 5.15: Translation of AADL connection binding bus to Signal Process

Interpretation We consider a simple case study, as presented at the bottom of Fig-ure 5.15. The clock t1 is the clock of the writer task1 generating or releasing the outputx1. At any time when t1 is present, the writer’s output x1 contains the last value that isavailable. At time tb, the bus fetches the last value of x1, and transfers it to store in theinput buffer of the reader task2, denoted by xb. At t2, the reader loads the input buffer xb

into the variable x2.

To model such a bus in Signal, we consider two data-buffering functions (two buffers)that communicate by a connect function, as shown in Figure 5.15. In Signal, we model aninterface of these functions that exposes their control.

The buffer_w accepts an input x1, which is generated by the writer, and buffers it untilthe bus tick tb arrives, and defines the boolean flag f1 that is carried along with it over thebus. The output xb gets the last value of x1 at each tick of tb (the at() function has alreadybeen defined in Section 5.3.1).

(xb, f1) = buffer_w(x1, tb)def=

xbˆ = f1ˆ = when tb

| xb := at(x1, when tb)| f1 := not ( f1$1 init true)

The connect forwards the input xb and f1 to the reader’s buffer. In general, it can be aFIFO [86] or some specification of buffer. In this first implementation, for simplicity, thisconnection is defined as the output equal to the input, x′

b:= xb, and the flag fb equal to f1.

(x′b, fb) = connect(xb, f1)def= (x′b := xb | fb := f1)

The buffer_r receives the input x′b

if the value of x′b

changes, detected by the processfilter, and stores it until the reader fetches it at t2. The process filter receives a booleaninput signal fb, and produces an output signal f ′ every time the value of the input changes.

126

5.7. SYSTEM MODELING

f ′ = filter( fb)def= ( f ′ := true when ( fb , z f ) | z f := fb$1 init true)/z f

x2 = buffer_r(x′b, fb, t2)def= (x2ˆ = when t2 | x2 := at(x′b when filter( fb), when t2))

The process bus is defined by its three components buffer_w, connect and buffer_r.

x2 = bus(x1, t1, tb, t2)def= (x2 := buffer_r(connect(buffer_w(x1, tb)), t2))

5.7 System modeling

The system is the top-level component of the AADL model, it represents a composite ofinteracting application software, execution platform, or system components. System canbe organized into a hierarchy that can represent complex systems of systems as well asthe integrated software and hardware of a dedicated application system.

A system S =< P,C,R,W,Z > specifies the runtime architecture of an operationalphysical system.

(system) S ::= < P,C,R,W,Z >

(connection) C ::= P × P

(flow) W ::= C ×C

(subcomponents) Z ::= S | Ps| Pr| M| B| Dv| Da| Z ‖ Z

• P ∈ F is the feature that consists of the ports, which declares the interface of thesystem.

• C = P×P is the port connection, which is an explicit relation between ports that en-ables the directional exchange of data or event among components, or a data/bus ac-cess connection, which enables multiple components access to a common data/buscomponent.

• R ∈ R is the property which provides descriptive information. For example, prop-erty Actual_processor_binding declares the processor binding property along withthe AADL components and functionality to which it applies.

• W = C×C specifies the flows that enable the detailed description and analysis of anabstract information path through a system. The flow path declares the flow througha component from one feature (port) to another.

• Z ∈ Z is the subcomponents of the system, which may consist of system, processPs, processor Pr, memory M, bus B, device Dv and data Da.

A system may have one or several processors, and each processor can execute oneor several processes, whereas an ARINC partition cannot be distributed over multiple

127


processors. The processor is allocated to each partition for a fixed time window withina time frame maintained by the core module level OS. So here we translate the systemto a top-level Signal process, and separate it into several modules according to its ownedprocessors.

Interpretation An abstract description of the interpretation is presented.

1. The system S =< P,C,R,W,Z > is transformed into a Signal process, including acomposition of ARINC modules M1 | M2 | . . . | Mn, and a scheduler MS for acti-vating the modules. A module M is a Signal process which consists of the subpro-cesses that are interpreted from the AADL processes (bound to a same processor).The corresponding Signal process is parameterized by a global tick gt, which is amain clock of the system, and the inputs/outputs that are translated from the portsI(P) (refer to Section 5.9.1).

I(S ) =

MI(C), I(R), I(W), I(Z)1

| MI(C), I(R), I(W), I(Z)2

| . . .

| MI(C), I(R), I(W), I(Z)n

| MS gt

I(P), gt

2. The processes bound to the same processor pr ∈ Pr, are translated to a module

Mi, which receives control from its active signal ei (generated by scheduler MS ).The processes binding information can be obtained using the function BindingPro-

cess(Pr) (refer to Section 5.5). The translation of the processor (I(Pr)) is a sched-uler PS , which is responsible for scheduling the processes. The interpretation of theprocessor (I(Pr)) and process (I(Ps)) can refer to Section 5.5 and Section 5.8.1 re-spectively. The interpretation of connection I(C) is similar to that presented inSection 5.4.2. A flow can be separated in a sequence of connections, hence itsinterpretation I(W) can refer to the interpretation of the connection.

Mi = (PS | P′)I(C), I(R), I(W), I(Z), ei

PS ei = I(pr)

P′ = (I(ps1) | . . . | I(psm) | I(C) | I(W))I(R)

where Psi = {ps1, . . . , psm} in the set of processes defined in Z such that

Psi = BindingProcess(pr) ={

ps ∈ Ps

∣

∣

∣

∣

∣

∃r = RActual_Processor_Binding ∈ R,

r.appliesTo = pr ∧ ps = r.re f erence

}

3. MS is a scheduler responsible for scheduling or activating the modules. The enable

128

5.7. SYSTEM MODELING

Figure 5.16: An AADL system example

clock ei of a module is related to the global tick gt. We use a process f to note therelation, which may depend on the scheduling policy.

MS = (e1, . . . , en) := f (gt)

In our translation, each processor corresponds to only one module, which meansthat no modules share the same processor. Hence for scheduling the modules, inthis simple implementation, an activation clock ei for the module is generated whenthe global tick gt is received.

MS = (e1 := gt | . . . | en := gt)

129


4. The subcomponents Z are transformed to Signal processes referring to their respec-tive transformation rules.

5. The connection C is transformed into a Signal process, referring to section 5.9.

Example The system in Figure 5.16 shows both graphical and textual code of a clientsystem. It contains two processors: processor1 and processor2. The three processesare distributed to different processors: process1 is bound to processor1, and the othertwo processes are bound to processor2, see the properties defined, for example, Ac-

tual_Processor_Binding => Process1 applies to Processor1.The corresponding Signal model contains two modules (Figure 5.17). They are sched-

uled by a module_level_OS, which defines a static scheduling timing window for eachmodule. The device subcomponent is translated as a Signal process in the model.

module_level_OS

device

partition1

partition2partition3

module1

module2

scheduler1

scheduler2

Figure 5.17: Signal process of the AADL system example

Each module is composed of a scheduler (translated from the processor) and the par-

titions on this processor. For instance, module1 contains scheduler1 (translated from Pro-

cessor1) and partition1 includes the subcomponent threads (translated as ARINC pro-

cess1, process2 and process3) of process1.

5.8 Other components modeling

5.8.1 Process modeling

The AADL process component represents a protected address space, a space partitioningwhere protection is provided from other components accessing anything inside the pro-cess. A process x encapsulates a functionality A that may consist of threads or threadgroup subcomponent, flows, connections, features and properties.

(process) process x A where A, B ::= connection x A | subcomponent x A | A‖B

130

5.8. OTHER COMPONENTS MODELING

Interpretation of a process The unit of IMA partitioning is called a partition. Parti-tion is a logical allocation unit resulting from a functional decomposition of the system.A partition is composed of processes that represent the executive units. A partition isbasically the same as a program in a single application environment.

An AADL process A is translated to an ARINC partition P (represented as a Signalprocess). The threads contained in the process will be translated as ARINC processes

within the partition, so that they can access the resource restricted in the partition. Aninner scheduler is needed for scheduling these threads, which has already been presentedin the section 5.5. The processes bound to the same processor are interpreted into anARINC module M.

A function BoundProcessor(A) is introduced to return the processor to which theprocess A is bound. For example, for two processes process1, process2 bound to the sameprocessor, this can be denoted as:

BoundProcessor(process1) = BoundProcessor(process2)

Abstract rules An abstract description of the rules for the interpretation of a processPs =< P, Th, C, R > into Signal process (as APEX ARINC partition) is given. A processPs may have threads Th as its subcomponents, and it may contain ports P, connections C

and some properties R.

1. A process Ps is interpreted into a Signal process consisting of a set of subprocessestranslated from the threads and a scheduler. This process is parameterized by theinterpretation of the ports I(P).

I(Ps) = (PPsI(Th), I(C) | S chedulerI(R))I(P)

2. The interpretation of the threads I(Th) and connections I(C) can refer to Sec-tion 5.4 and Section 5.9.2.

PPs = (I(th1) | . . . | I(thn) | I(c1) | . . . | I(cm)) where thi ∈ Th, ci ∈ C

3. The interpretation of the scheduler (S chedulerI(R)) can refer to Section 5.5.

Example A process example is given here (partial code from the doors_process processin the SDSCS system, refer to Appendix A). There are three threads in this process assubcomponents.

process doors_process

features

in_flight: in data port behavior::boolean;


end doors_process;

process implementation doors_process.imp

subcomponents

131


door_handler1: thread door_handler.imp;


door_mix: thread doors_mix.imp;

connections

conn1: data port in_flight -> door_handler1.in_flight;


conn3: data port door_mix.cll -> cll;

end doors_process.imp;

The corresponding Signal process is composed of three subprocesses interpreted fromthe threads, and one subprocess for scheduling, see Figure 5.18. The detailed code canrefer to Appendix A.

Partition1door_handler1door_handler2door_mix

scheduler

Figure 5.18: An AADL process in Signal

5.8.2 Subprogram modeling

Subprograms are callable components providing server functions to components that callthem. A subprogram S u defines a functional unit of compilation and of execution that canbe called from many contexts in the system under design.

Subprogram components represent elementary pieces of code that processes inputs toproduce outputs. A subprogram encapsulates an expressive functionality that may consistof behavior specifications, ports (parameters), subprogram calls and connections amongthese called subprograms.

S u = < T/S , P, S uCall, C >

Interpretation A subprogram is translated to a Signal process parameterized by thetranslated ports (parameters) I(P).

I(S u) = ( I(T/S ) | I(S uCall) | I(C) )I(P)

The interpretation of the ports I(P) and the interpretation of the behavior specificationof transitions/actions I(P) can refer to Section 5.9.1 and Chapter 6 respectively.

The subprogram calls SuCall are interpreted as instantiations of the called subpro-grams. For example, a subprogram S u1 is interpreted to a Signal process:

I(S u1) = PPS u1(? In1, . . . Inm; ! Out1, . . .Outn; ) PPS u1_BODY1

132

5.8. OTHER COMPONENTS MODELING

The instance of called subprogram S u1 is interpreted as a Signal process invocation.

S u1Call = (| o1 := Out1 | . . . | on := Outn | PPS u1_BODY1| In1 := i1 | . . . | Inm := im)

where S u1Call ∈ S uCall

The connections C = P × P connect the ports in the called subprograms, and theyare interpreted similarly to the connections (between the subprograms) presented in Sec-tion 5.4.2.

I(c) = I(p2) := I(p1) where c = (p1, p2) ∈ C

5.8.3 Data modeling

Data represent static data and data types within a system in AADL. A data, noted datax A, defines an application data type. It could be used in the component properties.

(data) data x A where A ::= aadlinteger A | aadlfloat A

| aadlboolean A | aadlstring A | A1 ‖ A2

Data types are structurally similar to Signal type declarations. Each simple Data typeis transformed into a Signal type declaration.

I(aadlinteger A) = 〈integer A〉

I(aadlfloat A) = 〈dreal A〉

I(aadlboolean A) = 〈boolean A〉

I(aadlstring A) = 〈string A〉

The compound data component is interpreted as a struct type.

I(A ‖ B) = 〈struct (I(A) ;I(B))〉

Data access A thread is considered to be in a critical region when it is accessing ashared data component. When a thread enters a critical region, a Get_Resource oper-ation is performed on the shared data component. Upon exit from a critical region, aRelease_Resource operation is performed.

Example Figure 5.19 is a data type example. On the left, the AADL data implemen-tation includes three subcomponents: name, text and size. Each subcomponent is a basicdata type (aadlstring, aadlinteger). On the right part of the figure is the corresponding

133


Signal data type structure. It is translated as a compound data structure, consisting ofthree attributes typed as string or integer.

Figure 5.19: Data example and its Signal representation

5.8.4 Device

A device device x A interfaces the AADL model with its environment. A device often hascomplex behaviors, in this thesis, we only take its interfaces into consideration.

Figure 5.20: AADL device example

Devices are not translated as the other components, they are modeled outside the par-

tition, the behavior implementation can be provided in some host language, such as C orJAVA.

134

5.9. PORT AND PORT CONNECTION MODELING

Interpretation Each device is transformed into a Signal process, outside the partitions,providing external environment and complex behaviors. The input/ output ports are trans-lated as the interfaces to the partition.

Example Figure 5.20 is a device example which has one output data port temperature.It is connected to two processes: process1 and process2.

It is transformed into a Signal process with an output temperature, and this output isconnected to the partititon as a source, shown in Figure 5.21. The interface of the deviceprocess is shown in the right.

sensor1

partition1

partition2

Figure 5.21: Signal representation of a device

5.9 Port and port connection modeling

Since ports are declared as features in all the component type declarations, and the portconnections are declared between the ports of different components, the port and portconnection modeling are presented in this separate section.

5.9.1 Port modeling

Port is a communication interface for the directional exchange of data, events, or bothbetween components. Data ports allow communication without queuing. Event and eventdata ports represent buffered communications. They are declared as features in com-ponent type declarations. Ports are directional (in or out). An in port represents inputneeded by the receiver, and an out port represents output provided by the sender.

(port) port x ::= in data port x X | in event port x X | in event data port x X

| out data port x X | out event port x X | out event data port x X

Interpretation The event and event data ports represent interfaces for the communica-tion of bounded queuing. They can be interpreted to bounded FIFO [86] in Signal. This isfacilitated by offering a sliding window [58] operator, which allows for the specificationof bounded FIFO protocols. It is not implemented in the current state, and a unique no-queuing signal is used instead for simple. The in/out port is interpreted to an input/outputof the corresponding Signal process. The type is interpreted from the data type.

135


Example Figure 5.22 gives a simple port specification in a thread: request is an inevent port, and response is an out data port, which is typed of message data. Thecorresponding Signal code is shown on the right. These two ports are translated as input/output of the process.

Figure 5.22: Port example

5.9.2 Port connection modeling

Connections are explicit relationships declared between ports that enable the directionalexchange of data or events among components. Interface elements are declared within thefeatures section of a component type declaration. Paths of interaction between interfaceelements are declared explicitly within component implementations.

A connection can connect an event port x to an event port y, written event x → y,or a data port x to a data port y, written data x → y, or an event data port x to an eventdata port y, written event data x → y. A connection from data port x to data port y, caneither be an immediate connection, written data x → y, or a delayed connection, writtendata x ։ y. For a delayed data port connection, the value from the sending thread istransmitted at its deadline and is availabe to the receiving thread at its next dispatch. Inthis case, the data available to a receiving thread is that value produced at the most recentdeadline of the sending thread.

The event and event data port connections can be implemented as bounded FIFO com-munication in Signal [86]. In the next subsections, we will focus on the data port connec-tion.

5.9.2.1 Data port connection

Each periodic thread is scheduled periodically. A periodic thread is associated with sometiming properties:

• The Dispatch_Protocol property is set to be Periodic.

• The period Pi is a fixed interval between two adjacent release of thread Ti.

• The deadline Di is defined by Deadline property.

• The Compute_Execution_Time defines the execution time between best executiontime Bi and worst case execution time Wi.

Once the periodic thread is dispatched, it calculates the actual execution time, whichtakes time between Bi and Wi. The thread has to be ended before Di. A small example ofperiodic thread with timing properties is shown below:

136

5.9. PORT AND PORT CONNECTION MODELING

thread T1

end T1;

thread implementation T1.impl

properties


Period => 10 ms;

Compute_Execution_Time => 3 ms .. 5ms;

Deadline => 10 ms;

end T1.impl;

The type of connection between thread data ports requires specific timing semantics.Figure 5.23 illustrates the instants where execution and communications take place.

In general, a message is fetched at the dispatch time. In case of an immediate connec-tion, (the sending and receiving threads must share a common simultaneous dispatch), amessage is received at the start time. The output data is available at completion for animmediate data connection, or at deadline for a delayed data connection.

�ataeventevent data

immediatedata

immediatedata sent

delayeddata sent

periodcomplete deadlinedispatch start (next)

dispatch

Figure 5.23: Thread communication time in AADL.

These connections have an influence on the following two aspects: first on the time atwhich the inputs and outputs are available and second, on the scheduling of the threads.

Figure 5.24: An example of communicating threads with different frequencies

The two data port communications have three types of thread configuration: same pe-riod sharing the same dispatch, oversampling and under-sampling. Figure 5.24 illustratesdata consumption and scheduling of threads in consideration of two types of communi-cation and threads with different frequencies. T2 is twice quicker than T1 and T3. The

137


connection from T1 to T2 is immediate, so the values available for two sequential execu-tions of T2 are the same: the value produced within the 10Hz execution frame of T1. Theconnection from T1 to T3 is delayed, and the two threads share a common period. T3receives the value produced by T1 in the previous period. The connection from T2 to T3is also delayed, but T2 has a higher frequency. The data provided to an execution of T3is the value produced by T2 that is available at the previous dispatch of the thread.

5.9.2.2 Data port connection modeling

For a communication of data port connection, the system satisfies the following form:

• The port connection is of type data port connection.

• The sender and receiver threads are both periodic, they have a Dis-

patch_Protocol=>Periodic.

• Periodic threads are guaranteed to be dispatched at each period.

The communication specification ensures that the time of transfer between the threadsis well-defined. While the application code operates on the port variables, buffers arerequired to guarantee the availability of the variables. In this subsection, we propose aspecification in Signal of the two data port communication types.

Modeling immediate data port connection For an immediate data port connection,both communicating periodic threads must be synchronized and dispatched simultane-ously. Figure 5.25 illustrates immediate communication.

T_1 T_2o ii

SPT_1

atstart_2

ats_complete_1

SPT_2

o'

o

o iSP SPi'

Figure 5.25: Translation of AADL immediate data connection with Signal processes

An immediate communication is implemented as a direct data dependency betweentwo processes. The output is memorized until the complete time of the sending thread,and then transmitted to the receiving thread. It is memorized until the start time of thereceiving thread.

An immediate communication is implemented as:

138

5.10. TOWARDS AADLV2.0

process immediate =

(? event s_complete_1, start_2; o; ! i;)

(| o_1:=at(o, s_complete_1)

| i:=at(o_1, start_2)

| )

where o_1; end;

The use of an immediate connection avoids declaring an explicit offset for the com-municating threads. The scheduler will dispatch the sender first, and ensure the receiverstarts after the completion of the sender.

Modeling delayed data port connection Figure 5.26 illustrates this type of data con-nection. The output is buffered until the deadline of the sender thread, and then sent outto the receiver. The receiver will memorize the input until next dispatch.

T_1 T_2oi i o||

SPT_1o iat

SPT_2at

start_2deadline_1

atdispatch_2o_1

DelayedSP1 SP2

Figure 5.26: Translation of AADL delayed data connection with Signal processes

A delayed communication is implemented as

process delayed =

(? event s_deadline_1, dispatch_2, start_2; o; ! i;)

(| o_1:=at(o, s_deadline_1)

| o_2:=at(o_1, dispatch_2)

| i:=at(o_2, start_2)

| )

where o_1, o_2; end;

This protocol ensures a deterministic communication between threads. Data avail-ability depends on the deadline of the sender, which is specified and fixed by the threadproperty.

5.10 Towards AADLv2.0

AADLv2.0 [38] was published in January 2009. This version makes some improvementswith respect to AADLv1.0 mainly for subprogram support, and introduces new com-ponents, i.e., virtual processor and virtual bus, and refines flows (allows flows throughaccess features) and bus access (provided bus access for processor, memory and device),

139


etc. [38, 40]. The main basic components (i.e., threads, processes, bus, connections) re-main the same or almost the same.

Since AADL thread is the main executable and schedulable component, it is takenas one of the most concerned components in our consideration. In AADLv2.0, the re-finements for threads are mainly focused on the port access input time and output time.The difference is that the port send/receive time can be specified explicitly. New proper-ties, Input_Time and Output_Time, are defined to specify the time values. For these newproperties, the implementation can be improved, e.g., the activation of the inputs (resp.outputs) depends on the Input_Time (resp. Output_Time) if it is specified, otherwise thestart time (resp. complete time).

The data port communication in AADLv2.0 introduces a declaration of sampling con-nection besides the immediate and delayed connection. In a sampling semantic connec-tion, the recipient samples the output of the sender at dispatch time or as specified by theInput_Time property of the recipient port. This will require the improvement of data portconnection implementation. For this new type of data port connection, a sampling processwill be needed for the receiving thread. The output of the sender will be sampled by thesignal (dispatch or Input_Time) depending on the specification.

AADLv2.0 provides bus access for processor, memory and device. The communica-tions among these execution platforms can be explicitly specified through the bus. Thisfeature can easily be implemented as bus connection in Signal similar to the bus connec-tion binding.

The new introduced virtual processor and virtual bus are similar to process and bus.Virtual processors must be bound to or be a subcomponent of processors. It representsa logical resource that is capable of scheduling and executing threads. A virtual busrepresents logical bus abstraction such as a virtual channel or communication protocol.These two components may have similar and refined implementations as processor andbus.

5.11 Conclusion

This chapter presents the AADL components transformation and their representations inSignal. The translation principles are given firstly. The transformation is based on theIMA architecture. Then we explain how we express AADL architectures and componentsin a synchronous framework, by allowing activation conditions, and modeling time con-suming by means of delay outputs. We give a transformation description of a subset ofAADL components, from the main execution component thread, the responsible sched-uler processor, to communication execution platform bus and whole system and the othercomponents. Apart from the component models, two types of data communication arealso proposed for the Signal representation. This model transformation only considers thesystem architecture, further functional behaviors and implementation will be detailed innext chapter.

140

Chapter 6

AADL behavior specification

Contents6.1 Static Single Assignment (SSA) . . . . . . . . . . . . . . . . . . . . . 142

6.2 AADL transition systems . . . . . . . . . . . . . . . . . . . . . . . . 143

6.2.1 States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

6.2.2 Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

6.2.3 Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

6.3 Interpretation of transitions/actions . . . . . . . . . . . . . . . . . . 148

6.3.1 Step 1: actions to basic actions . . . . . . . . . . . . . . . . . . 149

6.3.2 Step 2: basic actions to SSA form actions . . . . . . . . . . . . 155

6.3.3 Step 3: SSA to Signal . . . . . . . . . . . . . . . . . . . . . . 160

6.3.4 Global interpretation . . . . . . . . . . . . . . . . . . . . . . . 162

6.4 Case study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

This chapter focuses on the transformation of AADL behavior specification [42]. Ar-chitecture and functionality are two main aspects of a system in AADL. The functionalityof a component specifies the functional behaviors when it is in execution. In the previouschapter, we have presented the architecture and components of AADL and the transfor-mation to Signal. The semantics and transformation of AADL behavior will be presentedin this chapter.

The behavioral aspects can be described either with target languages, such asSimulink, VHDL, etc., or with AADL Behavior Annex. The AADL Behavior Annex, pro-posed in 2006, is an extension of the core AADL standard to specify the local functionalbehaviors of the components, without expressing them with external target language. Thedetailed behaviors are specified in this annex in order to perform model checking andadvanced code generation [81]. It extends AADL with precise behavioral and timinganalysis.

Behavior Annex lies in the computing state, which is an extension of the dispatchmechanism of execution model. The behaviors described in this annex are based on state

CHAPTER 6. AADL BEHAVIOR SPECIFICATION

variables whose evolution is specified by the transitions.The behavior specifications de-scribe a transition system [42]. It is attached to component implementations, mainly forthreads and subprograms.

To perform model checking of a system described in AADL, the components behav-iors are required. In reason of early system validation and verification, as mentioned inChapter 5, an approach to automatically interpret the AADL behaviors into a suitablemodel of computation is proposed. In this method, notations of the Behavior Annex areembedded in the polychronous model of computation, for the purpose of formal verifica-tion and code generation.

In AADL Behavior Annex, multiple assignment of the same variable in the sametransition is legal, while in Signal, it is not allowed to multi-define a signal in the sameinstant. Therefore, a rewriting of the assignments is required in the interpretation. In SSA(static single assignment) [70, 161] form, each variable appears only once on the left handside of an assignment: it is assigned only once. Therefore, our interpretation uses SSA asan intermediate formalism.

The transitions and actions are transformed into a set of synchronous equations. Thismodel transformation relies on an inductive SSA transformation algorithm across transi-tions/actions [122]. With regard to verification requirements, it minimizes the number ofstates across automata, hence provides better model checking performances.

This transformation is addressed in three steps: first, from the original transitions/ac-tions to basic form transitions/actions (actions only consisting of assignments or send-ing/receiving actions); second, from the basic form transitions/actions to SSA form tran-sitions/actions; Finally, from SSA form transitions/actions to Signal equations. The firsttwo steps are used to get its SSA form representation, since the translation from SSA toSignal is easy to implement, and similar experiments have already been performed forobtaining Signal code through SSA from C/C++ programs [61].

In this chapter, a brief description of SSA is first given in section 6.1. The syntaxand informal semantics of the Behavior Annex are described in section 6.2. Then, insection 6.3, we present general rules to interprete the AADL Behavior Annex into Sig-nal, which results in a model transformation chain from Behavior Annex to synchronousmodels. A case study is presented in section 6.4. Conclusions are given finally.

In this transformation, we show not only how to translate the core imperative pro-gramming features into equations, but we also consider the mode automata that controlthe activation of such elementary transitions and actions.

6.1 Static Single Assignment (SSA)

A program is said to be in static single assignment (SSA) [70, 64, 63, 69] form whenevereach variable in the program appears only once on the left hand side of an assignment.Only one new value of a variable x should at most be defined within an instant. The SSAform of a program replaces assignments of a program variable x with assignments to newversions x1, x2, ... of x, uniquely indexing each assignment.

void ones(int x, int *y) | bb_0: ix_1=x;

{ int ix, count; | count_1=0;

ix=x; | goto L1;

142

6.2. AADL TRANSITION SYSTEMS

count=0; | L_0: count_2=count_3+ix;

while (ix) { | ix_2=ix_3-1;

count=count+ix; | L_1: count_3=PHI<count_1, count_2>;

ix=ix-1;} | ix_3=PHI<ix_1, ix_2>;

*y=count ; | if (ix_3!=0) goto L_0;

} | L_2: *y=count_3;

| return;

We depict the structure of the SSA form with a typical C program (see above). ItsSSA form (right) consists of four blocks. The block labeled bb_0 initializes the localstate variables ix and count. Then it passes control to the block L_1. L_1 evaluates thetermination condition of the loop. If the termination condition is satisfied, control goes toblock L_2 where the result is copied to the output y. Otherwise, control goes back to L_0,which contains the actual loop contents that decreases ix.

In this SSA form, each variable is rewritten with a new version, for example, ix isrewritten as ix_1, ix_2 and ix_3. For each assignment, the use of ix (on the right side ofthe equation) refers to the last version of ix.

In block L_1, ix_3=PHI<ix_1,ix_2>, a PHI node is added to choose the value ofix. It merges all the different versions of the variables coming from the predecessors ofthe current block. It has the form xi = PHI < . . . , x j, . . . , xk, · · · >, where operands ofPHI are new names of x associated with the predecessors of the current block. The PHI

operator is needed to choose the value depending on the program control-flow, where avariable can be assigned in both branches of a conditional statement or in the body of aloop.

As SSA is an intermediate representation, introducing the PHI-node will not necessar-ily consume execution cost. The compilation from Signal will optimize the final executioncode.

This approach introduces an effective method for transforming behavior specificationsconsisting of transitions and actions into a set of synchronous equations. Our transforma-tion minimizes the needed state variables and component synchronization.

6.2 AADL transition systems

Behavior specifications can be attached to AADL component implementations using anannex. The AADL Behavior Annex describes a transition system. The overall structureof the behavior annex is a non-deterministic hierarchical automaton [81] using a State-flow [27]-like mode automaton syntax: the annex mainly declares states and transitionswith guards and an action part. The actions are related to the transitions not to the states.The skeleton of the annex behavior specification is first given. This annex consists ofthese optional sections: state variables, states and transitions.

annex behavior_specification {**

state variables

x: Tox;

states

s: initial state;

t: return state;

transitions

143


s-[g]->t {S};

**};

We will formalize a semantics of AADL Behavior Annex by isolating the core syn-tactic categories that characterize its expressive capability: states, transitions and actions.

6.2.1 States

A state variable x declares typed identifier. State variable x : Tox declares a state variablex whose type is Tox. Type Tox is a data classifier of the AADL model. A state variablex1 with a type of Behavior::integer is declared in the example.

state variables

x1: Behavior::integer;

States s declare automaton states which can be qualified as initial, complete or re-turn: s : (initial | complete | return) state. A state s0 qualified as initial and return isdeclared in the example.

states

s0: initial return state;

6.2.2 Transitions

A transition T defines a system transition from a source state s to a destination state t.The transition can be guarded with events or boolean conditions g, and actions S can beattached.

Guard The guard g contains an optional event or event data receipt e and an optionalboolean condition.

g ::= on exp | when exp | e

e ::= p?[(x)]

• An event e can be a receipt from an event port (p?), or from an event data port(p?(x)) where x is a state variable or a data subcomponent.

• The condition may depend on the received data, and it can be split in two parts: theon part expresses conditions over the current state, and the when part expresses acondition over the data to be read.

An expression exp may be a port identifier port_id, or a constant, or an arithmeticor boolean operation over expressions.

144


exp ::= exp op exp binary operation

| not exp unary operation

| port_id port identifier

| constant constant value

op ::= and | or boolean operation

| < | <= | > | >= | = | ! = boolean operation

| + | − | ∗ | / arithmetic operation

Transition The transitions section declares a set of finite transitions T . When the be-havior specification of a thread is first triggered, it starts execution from an initial state,specified as s : initial state, and ends with a complete (return for subprogram) state,specified as t : complete state (or t : return state). From state s, if the guard g is true,a transition is enabled, the action part S is performed, and then enters state t, writtens − [g]→ t {S }. The notation “;” in AADL notes the parallel composition of transitions.

T ∋ T ::= s − [g]→ t {S } | T1; T2 s, t : state

g : guard

S : actions

Figure 6.1 introduces the behavior specification at a syntactic level. It comprises twotransitions with an initial state s0, which is also a complete state, written s0: initial com-plete state. The thread will execute the transitions depending on the guarded conditions.

Figure 6.1: Behavior Annex example

145


• When dispatched, the execution of the component starts on an initial state. Whenthe thread door_handler.impl in Figure 6.1 is dispatched and started to compute, ittransits from state s0.

• From the current state, if the guard is satisfied, the transition is enabled. For theexample in Figure 6.1, if the boolean condition (dps>3) and handle is true, the firsttransition will be triggered, otherwise, the second one will be triggered. Meanwhile,the attached actions are executed during this transition. After that, it enters back tothe destination state s0.

• A thread completes its execution after reaching a complete state. It will resumefrom that state at next dispatch.

6.2.3 Actions

An action S ∈ S is recursively a sequence of actions, a loop on actions, an if statement,a timing action (computation(), delay()) or basic actions. A basic action B ∈ B is recur-sively a sequence of basic actions, assignment action w := f (y, z), or message receptionaction (p?(x)), or message emission action (p!(x)).

B ∋ B ::= w := f (y, z) | p?(x) | p!(x) | B1; B2

S ∋ S ::= if x then S 1 else S 2

| for (x in X) S

| delay(min, max)

| computation(min, max)

| B

| S 1; S 2

• An assignment w := f (y, z) defines the value of w from the function f of the currentvalues of y and z. w, y, z can be a port identifier, or a state variable, or an unsignednumeric or constant. The function f can either be a boolean function (not, and, or,>, >=, <, <=, !=) or an arithmetic function (+, -, *, /).

• The message sending or receiving actions express the communication of messages.A statement p!(x) writes data x to the event data port p and calls the send service.Each time instant, the same port p can only call the send service once. The eventis immediately sent to the destination with the stored data. Message sending onoutput ports is always non blocking. If present, the data value is written into theoutput port, and a send call is implicitly performed. A statement p?(x) dequeues adata from event port p in the variable x.

• The conditional if x then S 1 else S 2 executes S 1 if the current value of x is true,otherwise executes S 2.

146


Figure 6.2: A loop example, iteration over finite integer ranges and over enumerated type

• The finite loop for (x in X) S allows iterations over finite integer ranges or overunparameterized types, which are specified by a data classifier (for example, a sub-component data of enumerated type). Figure 6.2 (left) gives an example of loop.In the first transition, labeled l1, the loop iterates over integer range 1..2. In thesecond transition, labeled l2, the loop iterates over an enumerated data type DataX.The constants of this type DataX are declared as subprograms having one outputparameter of this type, shown in Figure 6.2 (right).

• The timing actions delay(min, max) and computation(min, max) specify non-deterministic waiting time and computation time intervals: delay(min, max) ex-presses a suspension for a possibly non-deterministic period of time between min

and max; computation(min, max) expresses the use of the CPU for a possiblynon-deterministic period of time between min and max. The difference of the twoactions is whether using CPU or not. For a delay action, the thread or subprogramwill be suspend and preempted.

The timing actions are different from the timing properties specified in the compo-nent. For example, the start property of a thread specifies the moment when thethread can start its execution, and deadline property specifies the moment whenthe thread must stop its execution. When a computation(2ms, 3ms) action is trig-gered, its execution will last for 2.5ms, for example. It can be seen that, duringthese 2.5ms, the thread does some computation which consumes CPU but is notspecified.

start complete deadline

computation(2ms,3ms)

transitions/actions execution

Figure 6.3: A computation example in the execution of a thread

Figure 6.3 shows a thread having a computation action during the execution. The

147


transitions/actions are performed in the time interval from start time to complete

time, labeled with yellow line. A computation action (labeled with red rectangle)is executed somewhere when it is triggered, which takes a time duration between2ms and 3ms (2.5ms for example). It is an action, but with specified duration time.

• Sequences of actions S 1; S 2 are executed in order.

The action is related to the transition, and not to the states: if a transition is enabled,the action part is performed, and then enters the transition destination state. The executionof an action starts at an occurrence of its active clock (when the transition to which it isattached is enabled), and shall end before the next occurrence of that event.

6.3 Interpretation of transitions/actions

Since the Behavior Annex supports precise behavior specification without requiring ex-ternal source code, it offers a way to specify the functional behaviors locally. Therefore,the modeling of AADL in Signal also includes the interpretation of Behavior Annex.

In order to distinguish between the transitions of different interpretation stages, wefirst introduce some notations. We use S ∈ S to represent a general action in the originaltransition T ∈ T , and U ∈ U to represent the intermediate transitions, called basictransitions, that are attached with the basic actions B ∈ B.

U ∋ U ::= s − [g]→t {B} | U1; U2

T ∋ T ::= s − [g]→t {S } | T1; T2

A notation de f (A) is introduced to refer the left hand side w of an assignment actionA (w := f (y, z)), and use(A) to refer the right hand side f (y, z).

A SSA form action A ∈ A is recursively a sequence of SSA form actions, or anassignment of w := f (y, z), in which w is defined at most once in A. In other words, forany S ∋ A = A1; A2, if w ∈ de f (A1), then w < de f (A2), the same for the reverse. Itsassociated transition is called SSA form transition W ∈ W .

A ∋ A ::= w := f (y, z) | A1; A2

W ∋ W ::= s − [g]→t {A} | W1; W2

Transformation steps Because actions are attached to the transitions, we must takeinto consideration the states which they depart from and enter in, when interpreting theactions.

We use I(T ) to note the interpretation of a transition T to Signal process. The trans-formation of the AADL transitions/actions to Signal I(T ) is addressed in three steps (asillustrated in Figure 6.4):

148

6.3. INTERPRETATION OF TRANSITIONS/ACTIONS

T/S : original transition/actions

U/B : basic transition/actions

W/A : SSA form transition/actions

P : Signal programs

Step 1

Step 2

Step 3

IT

IU

Iw

Figure 6.4: Behavior annex transformation chain

I(T ) : TIT

7→ UIU

7→ WIW

7→ P

• Step 1: TIT

7→ U. Each transition T ∈ T with attached sequence of generalactions S ∈ S , is decomposed into sets of basic transitions U ∈ U , in which allthe actions are basic actions B ∈ B.

• Step 2: UIU

7→ W. For each intermediate transition U ∈ U , depict the basicactions B ∈ B in SSA form A ∈ A and introduce new transitions if necessary.Each definition of an original variable w is replaced by a new version, no multipledefinitions exist in SSA form, so that the SSA form actions can be executed in thesame instant.

• Step 3: WIW

7→ P. Translate the SSA form actions A ∈ A and transitions toSignal equations.

Each step of the interpretation IT ,IU ,IW will be explained in detail in the followingsubsections.

6.3.1 Step 1: actions to basic actions

The first step of the AADL behavior actions/transitions interpretation involves the decom-position of original transition T ∈ T into sets of basic transitions U ∈ U .

A transition from a source state s when condition (guard) c is satisfied, to a destinationstate t, with attached general action S , noted as s − [c] → t{S }, can be decomposed intoa set of intermediate transitions U ∈ U , in which the actions in each new transition arebasic actions B ∈ B.

We use IT (T ) to represent this interpretation from a general transition T ∈ T to basictransition U ∈ U .

149


IT (T ) : T 7→ U where T ∈ T

U ∈ U

The interpretation of the transitions can be performed in parallel. The operator “;”notes the composition of transitions.

IT (T1; T2) = IT (T1);IT (T2)

For the decomposition of an original transition T into basic transitions U, we onlyneed to decompose the non-basic actions (i.e., if and loop statement) into basic actionswith intermediate transitions. For this purpose, first, processing the sequences, the non-basic actions need to be separated from the original actions; second, the decomposition ofnon-basic actions to basic actions is performed.

6.3.1.1 Processing sequences

We use an intermediate recursive function ITS to make explicit the separation of theactions of a transition T as the sequential composition of a first block of processed basicactions, noted B, and a second block, noted S , where the actions are not yet transformed.The application of this function is denoted ITS (B, S )s, c, t, for of a transition T = s−[c]→t {B; S }, where B consists of the basic actions from the beginning of actions, S includesthe remaining actions, and s, c, t are respectively the source state, the guard and the exitstate.

The basic rule of the recursive transformation is that, from the beginning of the originalactions, if an action is a basic action, it is moved to B, until a non basic action occurs. B

is separated, and an intermediate transition is introduced with actions B, from the sourcestate s to an intermediate state s1. For the remaining actions S , first the non basic actionswill be decomposed using the rules that will be presented in section 6.3.1.2, then for therest, the separation will continue following the same rules.

1. For a transition T = s − [c] → t {S }, at the very beginning of the interpretation,there is no basic action before S . We set B to be empty, represented by φ.

IT (s − [c]→ t {S }) = ITS (φ, S )s,c,t

Example 1 Take the first transition presented in Figure 6.1 for example. Theactions attached to this transition are noted as S . At this stage, no basic action isset, B is empty, noted as B = φ.

150


B = φ

S = {warn_diff_pres := true;

door_info := locked;

if (on_ground) door_locked := false; else door_locked := true; end if; }

2. If there is no actions following B in the interpretation, which means that all theactions are basic actions, then the resulting transition is the same as the originalone.

ITS (B, φ)s,c,t = s − [c]→ t {B}

Example 2 The actions in the following example are two assignments, both arebasic actions, and there is no action after them. So the resulting transition is thesame as the one presented here.

s − [c]→ t {warn_diff_pres := true; door_info := locked; }

3. If the action to be processed is a basic action B′ ∈ B, it can be merged to theprevious basic action set B. So that, B; B′ becomes the new basic action set, and theremaining actions S will continue the processing.

ITS (B, B′; S )s,c,t = ITS (B; B′, S )s,c,t if B′ ∈ B

Example 3 Take the same example as the one in Example 1. The first actionB′ = {warn_diff_pres := true} is an assignment, which is a basic action. So B′ ismerged to B, and the remaining actions will continue applying the rules.

B = φ

B′ = {warn_diff_pres := true}

S = {door_info := locked;

if (on_ground) door_locked := false; else door_locked := true; end if; }

4. If the action to be processed is not a basic action, S ′ < B, separate the actions B, S ′

and the remaining actions S in three transitions, and continue the separation forthe last transition with the actions S . The non basic action S ′ will be decomposedapplying the rules that will be given in section 6.3.1.2.

151


ITS (B, S ′; S )s,c,t =

s − [c]→ s′ {B};s′ − []→ s′′ {S ′};ITS (φ, S )s′′,true,t {S }

, if S ′ < B

Example 4 The conditional action S ′ = {if (on_ground) door_locked :=false; else door_locked := true; end if; } is not a basic action. Since B is notempty, and there is no action after S ′ (S = φ), we will introduce an intermediatestate s′ for a new transition with the action B. From state s′ to the destination state t,a transition with the conditional action S ′ is generated. This transition will continuebe decomposed into basic actions using the rules in the next subsection.

B = {warn_diff_pres := true; door_info := locked; }

S ′ = {if (on_ground) door_locked := false; else door_locked := true; end if; }

S = φ

Applying these rules, a transition T is separated into such new transitions that foreach new transition, either the actions are all basic actions, or the action is a single non-basic action. In the next subsection, the non-basic actions will be decomposed into basicactions.

6.3.1.2 Decomposition

An intermediate function IT D is used for decomposing a composite action S (S ∈ S andS < B) of a transition T , which is a condition or a loop or timing actions (computation()and delay()). The application of this function is denoted IT D(S )s, c, t, for S the compositeaction and s, c, t the source state, guard and exit state (respectively) of the transition. Inthat case: ITS (φ, S )s, c, t = IT D(S )s, c, t. It returns an intermediate transition U ∈ U

(which may be a composition of transitions) where the actions in U are basic actions.

1. Condition

A condition statement if x then S 1 else S 2 evaluates S 1 with the condition (when x)and evaluates S 2 with condition (when not x).

IT D(if x then S 1 else S 2)s,c,t =

(

s − [c and x]→ t {S 1};s − [c and not x]→ t {S 2}

)

The two generated transitions need to be processed recursively. If S 1 or S 2 still con-tains non-basic actions, continue applying the rules (separation and decomposition),until only basic actions exist. The same for the other composite actions.

152


Example 5 Figure 6.5 (upper) shows a transition with a condition action attached.Each branch is decomposed into a new transition (Figure 6.5 (bottom)): starts fromthe source state s, guarded with the condition (on_ground or not on_ground), at-tached with the corresponding actions in the branch, and enters in the destinationstate t.

Figure 6.5: Conditional action decomposition example

2. Loop

A loop statement for (x in X) {S } allows iterations over finite integer ranges or overunparameterized enumerated types, which are specified by a data classifier.

Integer range For an integer range, i in M..N, which means that M and N are twointegers and M < N, the loop statement can be refined as:

IT D(for (i in M..N) {S })s,c,t =

s − [c]→ s′ {i := M};s′ − [on (i ≤ N)]→ s′{S ; i := i + 1};s′ − [on (i > N)]→ t { }

Example 6

s-[]->t {for (i in 1..3) | s-[]->s1 {i:=1};

{ r:= r+1;}} | s1-[on (i<=3)]->s1 {r:= r+1; i:= i+1};

| s1-[on (i>3)]->t {}

The original transition (left) has one loop action attached. The corresponding de-composed transitions are represented on the right. First, initialize the iterator i.The second transition includes the actions (r := r + 1) in the body of the loopand increases the iterator. The last transition controls the automaton to enter in thedestination state t, if the loop condition is no longer satisfied.

Enumeration range For an iteration over unparameterized enumeration, x in X,in which X is a data classifier of enumerated type X = {x1, x2, ..., xn}, the loopstatement can be translated as:

153


IT D(for (x in X) {S })s,c,t =

s − [c]→ s′{i := 1};s′ − [on (i ≤ n)]→ s′ {x = xi; S ; i := i + 1};s′ − [on (i > n)]→ t {}

where X = {x1, x2, ..., xn} and |X| = n

3. Computation(m,n)

Computation(m, n) expresses the use of CPU for a possibly non-deterministic pe-riod of time between m and n. For this non-deterministic choice, we introduce afunction random(m, n) to choose a random period r (m ≤ r ≤ n) while translating.For simple, we consider here a conversion of the time unit into integers.

IT D(computation (m, n))s,c,t =

s − [c]→ s′ {i := 1}s′ − [on (i < r)]→ s′ {i := i + 1}s′ − [on (i = r)]→ t

where r = random(m, n)

4. Delay(m,n)

The difference between delay and computation is that computation consumesCPU, while delay does not, which means that, when a thread delays some timeinterval, other threads can execute during this time.

The interpretation of delay is more complicated, in reason of rescheduling request.The delay service request suspends execution of the requesting thread for an amountof elapsed time. The current thread state is set to WAITING, and a time counter isinitialized with a duration which is a random value between the delay lower boundm and upper bound n. A rescheduling is performed. The scheduler will selectthe highest priority process in the READY state. When the counter is expired, thethread will return to the READY state, and a rescheduling is required. A simpleexample is given in Figure 6.6.

Figure 6.6: Delay

154


Let us consider a transition s − [c] → t {delay(m, n)} that calls a delay. In theresulting Signal translation, the corresponding transition (at the instant at which thesource state is s and the guard c is true) will be viewed as the activation clock of adelay system call. This may be represented by an output signal delay, that encodesthe clock at which control has to be returned to the scheduler, due to delay systemcalls.

In this solution, some specific input and output signals, called control signals, areadded. These signals include:

input signal tick : This signal specifies the clock at which the process is running.The final Signal equations are sampled by the signal tick.

output signals corresponding to system calls: For example, a signal delay isproduced corresponding to the clock of the delay, and signals dmin, dmax corre-spond to the lower and upper bound of the delay. If these signals are not used in theprocess, their clock is the empty clock.

IT D(delay (m, n))s,c,t = s − [c]→ t {delay := c; dmin := m; dmax := n}

In [101, 61], a translation of C/SystemC and FairThreads system calls in Signal ispresented. Our approach is similar to these works.

Using the rules presented, the non-basic actions can now be decomposed into basicactions. Next step, the basic actions will be interpreted into SSA forms.

6.3.2 Step 2: basic actions to SSA form actions

In SSA form, a variable x is defined only once within a given sample of time or instant.New versions of x are used to uniquely index each assignment of x. Each variable in theSSA form program appears only once on the left hand side of an assignment.

Since the basic actions are recursively a sequence of three types of actions: assign-ment, message reception and message emission, in this step, only these types of actions(resp. transitions) need to be interpreted. The interpretation in this step is addressed intotwo stages: first, the interpretation of the basic actions in SSA form; second, the process-ing of sequences of basic transitions in SSA form.

The function IU is used to represent the interpretation of intermediate transition U ∈

U with action B ∈ B, to be represented in SSA form transition W ∈ W with actionA ∈ A . In this step, an intermediate transition U = s − [c] → t {B} (from source states to destination state t, guarded with condition c, and attached with the basic actions B)will be interpreted into SSA form transition W ∈ W , in which the actions A are all in SSAform.

IU : U → W where U ∈ U

W ∈ W

155


We use an environment E to associate each variable x ∈ X with its definitions (newversions of x), E : X → 2X. The environment of x is noted E(x), and the domain of E isnotedV(E).

Example 8 A variable x is renamed with x1, x2, x3, and variable y is renamed with y1, y2.The environment E associates the variable x, y to their corresponding definitions.

E :

(

x 7→ (x1, x2, x3)y 7→ (y1, y2)

)

E(x) = (x1, x2, x3)

E(y) = (y1, y2)

V(E) = (x, y)

We write useE(x) for the expression that returns the current definition of the variablex defined in environment E. If x is defined in the domain of E, x ∈ V(E), it will returnthe current version of x, otherwise, x is not defined in the current environment, then theprevious instant of x will be returned. The notation newE(x) is used to return a new versionx′ of variable x, which has not been defined in environment E.

useE(x) =

{

xn if x ∈ V(E), E(x) = (x1, . . . , xn)x$ otherwise

newE(x) = x′ where x′ < V(E)

The following two subsections present the two stages, respectively: interpret the basicactions to SSA form, and interpret the basic transitions to SSA form.

6.3.2.1 Interpretation of basic actions in SSA form

The notation IUA(B)E = AF is used to note the interpretation of the basic action B ∈ B

defined in environment E to SSA form action A ∈ A with an updated environment F.

1. For an assignment basic action x := f (y, z) in an environment E, the new action willtake its SSA form assignment: x is renamed with a new version, and y, z use theircurrent version in E. F is an updated environment.

IUA(x := f (y, z))E = (a := f (b, c))F where a = newE(x)

b = useE(y)

c = useE(z)

F = E⊎

(x 7→ a)

156


• The definition of x will take a new version a that has not been defined in theenvironment E.

• The SSA form of y and z will use their current version defined in environmentE, represented by useE(y) and useE(z).

• The new environment F stores the new version of x defined in E: F =

E⊎

(x 7→ newE(x)).

Example 9 An assignment x := y + z with an environment E = (y 7→ (y1, y2))is interpreted in SSA form: the definition of x takes a new version x1, and y usesits current version y2. Since no z is defined in environment E, it takes the previousvalue z$.

IUA(x := f (y, z))E = (a := f (y2, z$))F where E = (y 7→ (y1, y2))

a = newE(x)

F = (x 7→ a, y 7→ (y1, y2))

2. For a receiving action p?(x) with an environment E, the interpretation takes itsSSA form as follows. The action p?(x) transfers a data received from port p to thevariable x. The received data from port p is written to variable x, represented asx := p. The representation needs to be conformed to SSA form in the environmentE.

IUA(p?(x))E = (a := b)F where a = newE(x)

b = useE(p)

F = E⊎

(x 7→ a)

Example 10 The interpretation of p?(x) with an environment E = (p 7→ p1)returns its SSA form transition:

IUA(p?(x))E = (a := p1)F where a = newE(x)

E = (p 7→ p1)

F = (p 7→ p1, x 7→ a)

3. The sending message action p!(x) writes data x to event or event data port p, andcalls the Send service. A new unique version p′ of p ({p 7→ p′}) is added to update

157


the original environment E, F = E⊎

{p 7→ p′}. This action can be considered as anassignment of p with the value x. So the interpretation will take the SSA form ofthe assignment p := x. The definition of p will be a new version p′, which is not inthe domain of E. The current definition of x defined in environment E (useE(x)), isused for the assignment of p.

IUA(p!(x))E = (a := b)F where a = newE(p)

b = useE(x)

F = E⊎

(p 7→ a)

Example 11 An action p!(x) with an environment E = (x 7→ (x1, x2, x3)) is inter-preted as follows. The port p takes a new version, and stores it in the new environ-ment F, which takes the environment E and the new version of p ({p 7→ a}) as aplus.

IUA(p!(x))E = (a := x3)F where a = newE(p)

E = (x 7→ (x1, x2, x3))

F = (x 7→ (x1, x2, x3), p 7→ a)

4. For a sequence of basic actions B1; B2, the interpretation is the composition of theinterpretations of B1 and B2. Here F is the environment that merges E and the newupdates introduced by B1 (noted E(B1)).

IUA(B1; B2)E = AF1 ;IUA(B2)F where IUA(B1)E = AF

1

F = E⊎

E(B1)

6.3.2.2 Interpretation of basic transitions in SSA form

Normally, the basic actions attached in the same transition can be performed in the sameinstant, except for the sending message action p!(x) (refer to Section 6.2.3). Each timeinstant, the port p can only send out one message and writes data to output port once.Therefore, in the interpretation of a transition, if there is a second (or third, . . . ) occurrenceof a p!(x), it has to be separated in two SSA form transitions.

We use an intermediate recursive function IUT to make explicit the decompositionof the basic actions attached to a basic transition into successive actions in time. Theapplication of this function in an environment E to a basic transition s − [c] → t {B1; B2}

is denoted IUT (B1, B2)Es,c,t, where B1 consists of the actions from the beginning that can

158


be executed in the same instant, and B2 includes the remaining actions. The function IUT

uses the function IUA defined in the previous subsection for basic actions.

1. For a transition U = s − [c] → t {B}, at the very beginning of the interpretation,B1 is empty, which is represented by φ, and the environment E is set to be empty.Then:

IU(s − [c]→ t {B}) = IUT (φ, B)φs,c,t

2. If all the actions can be executed in the same instant, the resulting transition will thea transition attached with the actions represented in SSA form.

IUT (B, φ)Es,c,t = s − [c]→ t {IUA(B)E}

3. An assignment x := f (y, z) or receiving message action p?(x) can be merged to theprevious basic action B1.

IUT (B1, B′; B2)Es,c,t = IUT (B1; B′, B2)E

s,c,t if B′ = x := f (y, z) | p?(x)

4. For a transition U = s − [c] → t {B1; p!(x); B2}, if p has not been defined in thistransition, p!(x) can be merged to the previous basic action set B1. The notationV(U) notes the domain of variables that are defined in transition U.

IUT (B1, p!(x); B2)Es,c,t = IUT (B1; p!(x), B2)E

s,c,t if p < V(U)

Example 12 In a transition U = s − [c]→ t {x := 1; p!(x); p?(x); }, no p has beendefined before p!(x). Therefore, p!(x) can be merged to the previous actions B1.

B1 = {x := 1; }

B2 = p?(x);

IUT (x := 1, p!(x); p?(x); )Es,c,t = IUT (x := 1; p!(x), p?(x); )E

s,c,t

Otherwise, there has been already a definition of p in this transition, p ∈ V(U),since in each instant, the port p can only call the Send service once, so this p!(x)will be separated from B1. The transition is separated.

159


IUT (B1, p!(x); B2)Es,c,t = s − [c]→ s′ {IUA(B1)E} ; IUT (p!(x), B2)F

s′,c,t if p ∈ V(U)

with F = E⊎

E(B1)

In case of p ∈ V(U), the action B1 is interpreted in SSA form, and an intermediatestate s′ is introduced for a transition from state s. The remaining actions p!(x); B2

will continue applying the transformation rules, from the intermediate state s′ to thedestination state t, with an updated environment F which merges E and the newenvironment introduced by B1 (noted as E(B1)).

Example 13 In a transition U = s− [c]→ t {x := 1; p!(x); p!(x); y := x+ z}, thereis already a p defined in this transition before the second one occurs. The actions inthe first part (x := 1; p!(x);) will be separated, and form an intermediate transition.The remaining actions (p!(x);) will continue the interpretation.

B1 = {x := 1; p!(x); }

B2 = {y := x + z; }

IUT (x := 1; p!(x), p!(x); y := x + z)Es,c,t =

(

s − [c]→ s′ {IUA(x := 1; p!(x))E};IUT (p!(x), y := x + z)F

s′,c,t

)

F = E⊎

E(B1) = E⊎

(x 7→ newE(x), p 7→ newE(p))

Applying the rules in this step, the basic actions, sequence of assignments and send-ing/receiving message actions can be represented in SSA form, and the correspondingbasic transitions are interpreted in SSA form too. In the next step, these SSA form transi-tions/actions will be interpreted into Signal.

6.3.3 Step 3: SSA to Signal

From the interpretation of step 2, all the transitions/actions can be represented in SSAform. In this section, the SSA form transitions/actions are interpreted in Signal processes.

6.3.3.1 SSA form action interpretation

The interpretation IA(A)g = P of an SSA form action A takes as parameter the guard g

that leads to it, and returns a Signal equation P.The only action in SSA form is the assignment, or sequence of assignments. There-

fore, the interpretation in this step will only take the assignment action and the sequencein consideration.

• For a single assignment x := f (y, z), the signals to be used (on the right side of theassignment) will be sampled by the guard g: when g. A partial definition ::= is used

160


here since there may be other definitions of x with other guards. A cell is introducedfor the operands to make them available at their minimal common clock.

IA(x := f (y, z))g = (x ::= f (y cell h, z cell h) when g | h := y+z)/h

• For a sequence of assignments, the interpretation can be performed in parallel. Thenotation “|” is used to note the parallel composition in Signal.

IA(A1; A2)g = IA(A1)g | IA(A1)g

Next step, the transitions will be interpreted in Signal.

6.3.3.2 SSA form transition interpretation

The notation IW(W)st,nst is used to represent the interpretation of the SSA form transi-tion W ∈ W to a Signal process. It is parameterized by variables st, nst representingrespectively the current state and next state of the transition system.

IW(W1; W2)st,nst = IW(W1)st,nst | IW(W2)st,nst

IW(W)st,nst = (P | nst ::= t when g) where W = s − [c]→ t {A}


P = IA(A)g

The equation nst ::= t when g expresses that when the guard g is true, which meanswhen the current state st is s and when the condition c is satisfied, the next state nst of thetransition will be t. When a transition completes, the exit state becomes the current state.

Example 14 A transition W, from state s to t, guarded by c, attached with an actionA = x := y + z, is interpreted into the following Signal process. The assignment of x

is sampled by the guard c and the current state variable st. The signal nst represents thenext state: when the current state st is in state s, and the guard c is satisfied, the next statewill be t.

IW(s − [c]→ t {A})st,nst = (P | nst ::= t when g)

where A = x := y + z

P = IA(A)when g = (x ::= (y cell h) + (z cell h) when g | h := y+z)/h


161


6.3.4 Global interpretation

Finally, following the three steps’ interpretation, the global transformation I of a tran-sition system T = (T1; . . . ; Tn)s0, tick has to take into account the initial state s0 of thetransition system and the clock, denoted tick, representing the instants at which the con-sidered thread is active—this clock is defined by the scheduler. The input signal tick,which is a control signal of type event, connects the operating system to the thread tonotify it that it is selected to be actually running.

I(T1; T2)s0, tick = I(T1)s0, tick | I(T2)s0, tick

I(T )s0, tick = (P | st := nst $ init s0 | st ˆ = tick) /st, nst where P = IW(W)st,nst

W = IU(U)

U = IT (T )

In the next section, a case study will be presented to help the explanation of the inter-pretation steps.

6.4 Case study

Figure 6.7 is a graphical representation of the example previously shown in Figure 6.1,which is a behavior specification of a door_handler thread from a SDSCS (SimplifiedDoors and Slides Control System). There is only one state in this automaton: s0, whichacts as both initial and complete state. When the source state is s0 and the guard((dps > 3) and handle) is satisfied, then the first transition is triggered, so that thetwo assignments and the condition action are executed (see Figure 6.1). After the com-pletion of the computation, the transition enters state s0 again. If the guard conditionnot(dps > 3) and handle is true, then the second transition will be executed.

S0(dps>3) and handle / {...} not (dps>3) and handle / {...}initial

complete

Figure 6.7: Automata of the door_handle thread

Step 1: TIT

7→ U. From original actions/ transitions to basic actions/ transitions.The intermediate generated code of the basic transitions/actions for the door_handler

thread is depicted below. It contains a transformation of the transitions as well as itsattached actions. The interpretation introduces two intermediate states: STATE_0 andSTATE_1.

annex behavior_specification{**

states

s0 : initial complete state;

162

6.4. CASE STUDY

STATE_0 : state;

STATE_1 : state;

transitions

s0 -[ on (dps>3) and handle ] -> STATE_0 {

warn_diff_pres := true;

door_info := locked; };

STATE_0 -[ on on_ground ] -> s0 {

door_locked := false; };

STATE_0 -[ on not on_ground ] -> s0 {

door_locked := true; };

s0 -[ on not (dps>3) and handle ] -> STATE_1 {

warn_diff_pres := false;

door_info := locked; };

STATE_1 -[ on in_flight ] -> s0 {

door_locked := true; };

STATE_1 -[ on not in_flight ] -> s0 {

door_locked := false; };

**}

The first three transitions rewrite the first original one. The new transition first entersan intermediate state STATE_0, when the guard (on dps > 3 and handle) is true. The twoassignments ({warn_diff_pres := true; door_info := locked; }) are interpreted in the sametransition. For the condition action, depending on the condition, a transition is introducedfor each branch. The two branches both end with state s0.

S0STATE_1 STATE_0not dps>3 and handle / {...}

in_flight / {...}not in_flight/ {...}

on_ground / {...}

not on_ground / {...}

dps>3 and handle / {...}

Figure 6.8: Automata for the intermediate Behavior code of the door_handler thread

The automaton including these intermediate transitions is also shown in Figure 6.8.The three transitions on the right represent the first transition of the original specification.From the initial state s0, when guard (dps > 3 and handle) is true, the transition willenter state STATE_0, attached with the two assignment actions. The two transitions fromSTATE_0 to state s0 are the two branches of the condition action. The others on the leftrepresent the second one.

Step 2: UIU

7→ W. From basic actions/ transitions to SSA form actions/ transitions.In this example, the SSA form actions and transitions are the same as depicted in step

one, since all the variables are already uniquely defined in each of the transitions.

Step 3: WIW

7→ P. From SSA form actions/ transitions to Signal process.Each transition will then be interpreted into Signal equations. The generated Signal

code is shown in Figure 6.9. Two state variables (st, nst) are added: st represents the

163


Figure 6.9: Signal code for the door handler example

current state, and nst represents the next state; st takes the previous value of nst, and it isinitialized by the initial state s0:

st := nst $ init s0

The next state nst takes the destination state of each transition, sampled with thecurrent state and the guard. For example, the first transition in step two (the same asin step one in this example) starts from state s0, ends with state STATE_0, guarded by(dps > 3 and handle). So the Signal equation for this state transition is defined as:

nst := STATE_0 when (st = s0) when ((dps > 3) and handle)

Each assignment is sampled with the source state and the guard:

warn_diff_pres := true when (st = s0) when ((dps > 3) and handle)

The variable warn_diff_pres has two partial assignments in two different transitions.We use a default operation to merge these two definitions:

164

6.5. CONCLUSION

warn_diff_pres := true when (st = s0) when ((dps > 3) and handle

default false when (st = s0) when ((not (dps > 3)) and handle

The state variables st and nst are declared as type of state, which is an enumeratedtype, including all the state instances:

type state = enum (s0, S T AT E_0, S T AT E_1)

The program is translated into Signal following the general rules described above. Thethread is activated at the instants defined by the scheduler. Depending on the schedulingpolicy, the scheduler will set one of the enabled threads to be active at each time instant,denoted by an associated tick event. Then simulation code (for example, C code) is gen-erated with the help of the Polychrony toolset. Traces can be added to be able to followthe simulation. Properties can be checked using Sigali [126] which is a Signal companionmodel-checker. Similar experiments have been described in [61] for Signal code obtainedthrough SSA from C/C++ parallel programs.

6.5 Conclusion

This chapter presents the principle and implementation of an interpretation of the AADLBehavior Annex into a synchronous data-flow and multi-clocked model of computation.This interpretation is based on the use of SSA as an intermediate format. It gives a thor-ough description of an inductive SSA transformation algorithm across a hierarchy of tran-sitions that produce synchronous equations.

We obtain an effective method for transforming a hierarchy of behavior specificationsconsisting of transitions and actions into a set of synchronous equations.

Our approach and tools are based on the studies and experimental results on thetranslation of C/C++ parallel codes into synchronous formalism using SSA transforma-tion [61]. In the ANR project SPACIFY, [154] proposes an approach to model notationsof the Synoptic language and to embed them in a suitable model of computation for thepurpose of formal verification and code generation. It consists of an inductive SSA trans-formation algorithm across a hierarchy of blocks that produces synchronous equations.

With Chapter 5 and this chapter, a system specified in AADL can be modeled in apolychronous framework, including both the architecture and behaviors. In next chapter,a distribution of the system will be considered.

165


166

Chapter 7

Distributed simulation modelgeneration

Contents7.1 Distributed code generation in Polychrony . . . . . . . . . . . . . . 167

7.1.1 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

7.1.2 Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

7.1.3 Adding communications . . . . . . . . . . . . . . . . . . . . . 173

7.2 An example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

7.2.1 System description . . . . . . . . . . . . . . . . . . . . . . . . 177

7.2.2 Modeling and Distributing the example in Signal . . . . . . . . 177

7.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

In this chapter, a distribution model will be presented. Distribution will provide thepossibility to build complex but powerful systems. The previous two chapters have shownhow to model partially asynchronous applications from system-level AADL specifica-tions, this chapter will present how to generate distributed simulation code.

We are interested in the system allocation and communication between them. For thispurpose, we address the distribution in three steps: mapping, scheduling and communi-cation. The Signal pragma “RunOn” is used for the partitioning mapping information.MPI is a language independent communication protocol used to program parallel com-puter. We use MPI to communicate between distributed programs. An example is givento illustrate the distribution application.

7.1 Distributed code generation in Polychrony

Given the combined capabilities of the distributed components, a distributed sys-tem [44, 116] can be much larger and more powerful than combinations of stand-alonesystems. Polychrony provides general compilation methods particularly for distributedcode generation [47, 58].

CHAPTER 7. DISTRIBUTED SIMULATION MODEL GENERATION

The purpose of our distribution is, given a centralised program and the distributionspecifications, to build the program on different processors. These programs must be ableto communicate harmoniously, such that their combined behavior will be functionallyequivalent to the behavior of the initial centralised source program.

In Chapter 5 and Chapter 6, we have given the transformation of the AADL compo-nents and functional behaviors to Signal. They can be represented in Signal programs.For a complete transformation, we are interested in two specifications. The first one isthe Signal program which includes all the computation components and depicts flows ofdata, translated from the AADL components. The other one is the hardware architecturespecification: in the AADL architecture specification, it is clearly defined how the sys-tem should be distributed, for example, which process should be executed and scheduledby which processor, and how the processor will periodically or sporadically schedule theprocesses.

In this chapter, our goal is to obtain automatic distributed code generation from:

1. the software architecture of the application,

2. a representation of the distributed target architecture,

3. a manual mapping of the software modules onto the hardware components (givenby an AADL/Signal description).

Figure 7.1: Distributed code generation

168

7.1. DISTRIBUTED CODE GENERATION IN POLYCHRONY

To automatically distribute a Signal program, Figure 7.1 illustrates the steps of this dis-tribution. First, the specified components are mapped on the target architecture, a sched-uler is added for each processor, and the clock synchronizations between the partitionedcomponents are synthesized. Then add communications between these components. Andfinally generate executable distribution code [123].

7.1.1 Mapping

Figure 7.2: AADL distribution specification

In this section, we illustrate the mapping by an example with two processors (Fig-ure 7.2). The system system1 contains two processes: CLIENT and SERVERS, and two

169


processors: Processor1 and Processor2. Each process is distributed on a differentprocessor. From the properties definition of the system implementation, we can see thatprocess CLIENT is bound to processor Processor1, and SERVERS is bound to processorProcessor2.

By analyzing the AADL architecture, the system is composed of two processes. Ac-cording to Chapter 5, we have two partitions translated for the processes from this AADLmodel.

Then we need to distribute the partitions to different machines/processors. Becauseeach partition is translated from a process, which is bound to a different processor asspecified in the properties, the two partitions do not share the same processor, so we canassign each partition to a different processor.

Each partition is paced by its own clock. The Signal pragma “RunOn” [58] in thePolychrony environment is used for partitioning information: when a partitioning basedon the use of the pragma “RunOn” is applied to an application, the global application ispartitioned according to the different values of the pragma so as to obtain sub-models. Thetree of clocks (the root of the tree represents the most frequent clock) and the interfaceof these sub-models may be completed in such a way that they represent endochronousprocesses [153] (an endochronous process is mostly insensitive to internal and externalpropagation delays).

The mapping principles are the following:

1. Description of the software data flow program, using the Signal language (noted asprogram P). This step is already done following Chapter 5.

2. Description of the target architecture. This is specified in the AADL model, espe-cially in the properties.

3. Mapping of the software program on the target architecture. So, the program P isrewritten as (|P1|...|Pn|), where n is the number of “processors”. This step isonly a syntactic restructuration of the original program. The Signal process Pi isannotated with a pragma “RunOn i”. This pragma will be used for partitioning.

Here we give a simple example for distributing two partitions run on different proces-sors, of which the AADL model is described in Figure 7.2:

process system1 =

(? event tick; )

pragmas

target "MPI"

RunOn {e1} "1"

RunOn {e2} "2"

end pragmas

(|e1::(| x:= CLIENT(y,ptick1)

|(ptick1):= SCHEDULE1(tick)

|)

|e2::(| y:= SERVERS(x,ptick2)

|(ptick2):= SCHEDULE2(tick)

|)

|)

where

170


label e1,e2;

Message_type x,y;

event ptick1, ptick2;

end;

The Signal processes CLIENT() and SERVERS() are implemented as explained inChapter 5. We put the SCHEDULE() implementation details off until later refinementstages, and focus on distribution in this step: the two partitions are assigned to two differ-ent labels: CLIENT() with label e1 and SERVERS() with label e2. The pragma RunOnis used: RunOn {e1} "1" and RunOn {e2} "2". So that, the programs labeled with e1(resp. e2) will run on processor 1 (resp. 2). Therefore, the two partitions are distributedto two different processors.

7.1.2 Scheduler

The purpose of scheduling is to be able to structure the code into pieces of sequentialcode, and guarantee the ordered execution of these codes. To express the mapping ofexecution tasks to platform processors, we will first recall the scheduler modeling in ourtransformation.

Module_Level_OS

Partition1

Partition2

Partitionn...

Partition_Level_OS

Process1Process2Processn...

startstart

start

dispatchsuspendresume SPS SPTstart

completedeadline

Figure 7.3: Scheduling

The scheduler selects enabled tasks for execution according to the scheduling pol-icy. In APEX-ARINC model, the Module_Level_OS is the scheduler for scheduling thepartitions within the same module (see Figure 7.3). Scheduling partitions is strictly deter-ministic over time in the ARINC653 standard. Based upon the configuration of partitionswithin the core module, overall resource requirements/availability and specific partitionrequirements, a time-based activation schedule is generated that identifies the partitionwindows allocated to the individual partitions.

Each partition is then scheduled according to its respective partition window. Theschedule is fixed for the particular configuration of partitions on the processor. Sincepartitions have no priority, the scheduling algorithm is predetermined, repetitive with a

171


fixed periodicity, and is configurable by the system integrator only. At least one partition

window is allocated to each partition during each cycle.Within the partition, there is a Partition_Level_OS (in Figure 7.3, zoom of Partition

n) for scheduling the processes (translated from the AADL threads), which is alreadyimplemented during the transformation phase in Chapter 5.

In this scheduling step, the principles are the following:

1. Scheduling the partitions. In our transformation rules, each processor may apply toseveral processes, which means that a processor may run several partitions. Sincethe scheduler for the partitions running on a processor is deterministic, it is staticand fixed according to the configuration tables. We will create a static scheduler forsimple, refer to the Module_Level_OS in APEX.

We give a scheduler example below, named S CHEDULE(). The processes INIT ()and GET_ACT IVE_PART IT ION() are used for initializing and activating the par-titions. Although our mock-up implementation considers only one partition (as it isthe case for the example of the previous subsection), they can be implemented forseveral partitions. The implementation can be written as an external C program.

process SCHEDULE =

(? event tick;

! integer active_partition;)

(|(| initialize := INIT(tick)

|)

|(| active_partition := GET_ACTIVE_PARTITION()

| b_init := (not initialize)$1 init true

| active_partition ^= when (not b_init)

|)

|)

where

event initialize;

boolean b_init;

end;

2. Global compiling. This phase makes explicit all the synchronizations of the appli-cation, then synthesizes, if it exists, the master clock of the program, and detectssynchronization constraints.

After adding the scheduler to the program, now we can make a global compilingto separate the parts for further development. This phase makes explicit all thesynchronizations of the application and detects synchronization constraints.

The compiler uses clock calculus to statically analyze every program statement,identify the structure of the clocks of variables, and schedule the overall compu-tations. If the collection of the statements as a whole contains clock constraintsviolation, then synchronization constraints exist.

The distributed program is automatically generated in the Polychrony environment,applying the distribution compiling. Partial distributed code of the example shownin previous subsection is given here:

172


process system1_1 = | process system1_2 =

(? Mess_type y; | (? Mess_type x;

event ptick; | event ptick;

! Mess_type x;) | ! Mess_type x;)

pragmas | pragmas

RunOn "1" | RunOn "2"

end pragmas | end pragmas

(|...|); | (|...|);

The program is separated into two parts. Each part is made of the code pieces thathave the same label. The part is labeled as XX_i (XX represents the name of theoriginal Signal program, “system1” in this example, and i is the name of the RunOnprocessor), and the internal inputs/outputs from the other part are automaticallyadded. In our example, the two parts system1_1 and system1_2 are generated afterthe global compiling, message x is transfered from system1_1 to system1_2, andsystem1_1 will receive message y from system1_2.

Compared with the original program, a rewriting has been performed for the sepa-rated parts. All the computation properties are preserved, and a scheduler is addedfor each of the processors.

7.1.3 Adding communications

A distributed program consists of a set of processes interacting with the environment andcommunicating between themselves. Reasons for the communication are to send data orsignal to another process, to synchronize with other processes, or to request an actionfrom another process.

A common distributed processing environment is constituted by several parts that areinterconnected forming a network and they communicate and coordinate their actions bypassing messages. Usually a real-time distributed executive provides services such as timeand resource management, allocation and scheduling of processes and inter-processescommunication and synchronization. Among these services, one of the most importantis the communication support. We emphasize this issue because of the peculiar role ofinter-processor communications in distributed memory multi-processors.

In distributed computing, a common assumption is that, when a task sends a messageto some other task, it should not need to know where this task is situated, making the mes-sage communication transparent. Some commercial operating systems (e.g. VAX/ELN)provide a distributed kernel, which directly supports this transparency in the messagecommunication. If this property is not available then a Distributed Task Manager (DTM)is usually developed to provide this transparency. This middleware is a layer of soft-ware that stands above each operating system on each node. Therefore some form ofcommunication and synchronization mechanism which guarantees that the semantics ofsynchronous communication will be preserved needs to be added.

There are two basic solutions for communications: shared variables and message pass-ing.

Shared variables do not allow synchronization between parallel processes, unlesssome complex mechanism is built on top of them. Moreover, they make formal verifi-cation harder.

173


The other solution is message passing. Message passing in distributed systems can besynchronous or asynchronous. In our implementation, we use MPI (Message Passing In-terface) [159]. MPI is a language-independent communication protocol used to programparallel computers. It is a message passing application programmer interface, togetherwith protocol and semantic specifications for how its features must behave in any imple-mentation.

MPI technology tends to provide an efficient and portable standard for message pass-ing communication programs used in distributed memory and parallel computing. Thetarget platforms are systems which consist of massively parallel computing (the program-mer is responsible for identifying the parallelism) such as workstation clusters or hetero-geneous networks. There are currently several MPI implementations such as MPI/Pro,IBM MPI, Open MPI [16] and LAM [13]. These implementations provide different com-munication modes such as asynchronous communication, virtual topologies and efficientmessage buffer management.

The problem of timed synchronous communication between two processes, P and Q,can be stated as follows:

• Send. To send a message to process Q, process P executes MPI_Send as displayedin Table 7.1. A unique tag is assigned to the message.

int MPI_Send ( void *buf, int count, MPI_Datatype datatype,int dest, int tag, MPI_Comm comm )

Input Parametersbuf initial address of sending buffer (choice)count number of elements in sending buffer (non-negative integer)datatype data type of each sending buffer element (handle)dest rank of destination (integer)tag message tag (integer)comm communicator (handle)

Table 7.1: Synopsis of MPI_Send

• Receive. Meanwhile, process Q executes a receive command as presented in Ta-ble 7.2. The parameters in receive command are almost the same as the ones insend. The tag is labeled the same as the one assigned in the send command. Thesource parameter specifies the rank of source.

int MPI_recv (void *buf, int count, MPI_Datatype datatype, int source,int tag, MPI_COMM comm, MPI_STATUS *status)

Table 7.2: Synopsis of MPI_recv

MPI preserves the ordering and the integrity of the messages (for example, by ACKschemes and sequence numbers). This will ensure that values are not mixed up or out ofsequence, provided that the send actions are executed on one location in the same orderas the corresponding recv actions in the other location.

174

7.2. AN EXAMPLE

Based upon the distribution specification, a unique tag is assigned to each commonvariable of the program. Figure 7.4 shows the communications in the case of the sameexample. The message x from part system1_1 is tagged with tag 0. On the receiving side,it reserves the same tag. The same for the other message, y (with tag 1) in the reversedirection.

system1_1 system1_2MPI_send()MPI_recv()

x (tag 0) x (tag 0)y (tag 1) y (tag 1)

tick tick

Figure 7.4: MPI Communication

To execute the distributed parts, we need to configure the actual physical machinesfor their execution. In our example, we configure the hosts as follows: the generatedexecutable bin file system1_1 (resp. system1_2) which is located in DIRECTORY0 (resp.DIRECTORY1) will be executed on node0 (resp. node1). The two node machines arespecified by the host address in the “lamhosts” file. The detailed configuration is given inTable 7.3.

lamhosts:10.0.1.3 %the first machine%10.0.1.5 %the second machine%c0 -wd DIRECTORY0 10.0.1.3 % node0 runs on 10.0.1.3%c1 -wd DIRECTORY1 10.0.1.5 % node1 runs on 10.0.1.5%

Table 7.3: Configuration of the example

Finally the parts can be compiled locally and executed on different machines respec-tively. The programs are run on distributed processors.

7.2 An example

Our approach is a practical application of formal results that have been proved in thepolychronous MoC. It has been shown that if P=(|P1|...|Pn|) is such that Pi’s areendo-isochronous (all of them are endochronous and the pairwise compositions of theirrestrictions on their common variables are endochronous) [71], assume the deploymentis simply performed by using an asynchronous mode of communication between the dif-ferent processes, then the original semantics of each individual process of the deployedGALS architecture is preserved (the sequence of values are preserved for all flows).

In this section, we illustrate this methodology by a real example, showing how theSignal program is obtained from the AADL specification, and then how the distributioncode is generated in the Polychrony framework.

175


Figure 7.5: An example of process allocation176

7.2. AN EXAMPLE

7.2.1 System description

AADL allows the specification of functionality allocation on hardware. The allocationincludes: binding systems/processes/threads on processors; mapping connections on bus.They are specified in the properties.

A thread is bound to the processor specified by the Actual_Processor_Binding prop-erty. Connections between different execution platforms are bound to the bus specified bythe Actual_Connection_Binding property.

Figure 7.5 is a simplified door management system example. The system is aimed tomonitor on the flight status, control the pressurisation and the residual pressure warninglights. This system is present on all the Airbus aircrafts. Here, since we only focus on thedistribution specification in this chapter, the detailed functional component implementa-tions are ignored, and the complex door system is simplified as a device.

The basic architecture is shown in Figure 7.5. There are a door_management systemtype and a system implementation declaration. The subcomponents subclause declarestwo devices, two processes, two processors and a bus contained in the system implemen-tation. The two devices are connected to the two processes through data port connec-tions. These connections are bound to the bus afdx, seen in the graphical representation ofFigure 7.5 (bottom). The two processes doors_process1 and doors_process2 are appliedto different processors, which is specified in the properties. The process doors_process1

is bound to processor cpiom1, and doors_process2 is bound to cpiom2:

Actual_Processor_Binding => reference cpiom1 applies to doors_process1;Actual_Processor_Binding => reference cpiom2 applies to doors_process2;

7.2.2 Modeling and Distributing the example in Signal

In this subsection, we will show the Signal model of the example, and its distribution codefollowing the steps we have presented.

7.2.2.1 Modeling in Signal

The example is modeled in Signal following the transformation rules we have presentedin Chapter 5. The process is modeled into an ARINC partition (a Signal process), whichcontains a scheduler for scheduling the threads inside the process. The device is trans-lated into a Signal process, outside the partition, that provides some external environmentinformation. The bus is transformed to a Signal process, connecting the communicationswhich are specified bound to it. The whole system is a Signal process, including all theprocesses translated from the subcomponents.

Figure 7.6 shows partial generated Signal code that is transformed from the examplein Figure 7.5. The detailed implementations are omitted, only the interface is shown here.

The processes PART_cpiom1 and PART_cpiom2 are the two partitions translated fromthe AADL processes doors_process1 and doors_process2. Each partition contains ascheduler Scheduler_CPIOM, which corresponds to the processor that it is bound to.The process BUS_AFDX represents the bus connection. The communication between

177


the device Device_Door and the partition is through the bus BUS_AFDX (can be refinedusing the same bus instead of using two bus instances).

Figure 7.6: Signal model of the door management system

Since we are interested in the distribution specification in this chapter, the detailedimplementation for each of the processes is not shown here.

7.2.2.2 Distribution

From the AADL specification, we know that the two processes are bound to differentprocessors. We can distribute the generated partitions to different physical machines inStep 1.

Step 1: Mapping. Since each partition is bound to a unique processor, we can dis-tribute it directly, by applying the “RunOn” pragma.

178

7.2. AN EXAMPLE

Figure 7.7 rewrites the program in Figure 7.6. The processes doors_process1 anddoors_process2 are explicitly specified in the AADL specification to run on different pro-cessors. So the generated programs PART_cpiom1 and PART_cpiom2 are assigned re-spectively a label e1 and e2. The devices and bus are not declared to be bound to someprocessor. In such a case, we suppose that they run on some other processor, labeledwith e3. So that, the program is distributed to run on three machines.

Figure 7.7: Distribution of Signal model

The Signal pragma “RunOn” is applied to this application. The application is par-titioned according to the different values of the pragma. For example, the pragmaRunOn {e1} “1” specifies that the program labeled with e1 will run on processor “1”.

Figure 7.8: A simple scheduler for one partition

Step 2: Scheduler. The code in Figure 7.7 has introduced a process SCHEDULE()

both in labels e1 and e2. This scheduler is used for selecting the correct partition during

179


execution within the module (a module is composed of the processes that are bound to thesame processor).

In our example, each module contains only one process. So the scheduler SCHED-

ULE() will allocate to the partition one partition window during each cycle. Figure 7.8gives a simple implementation of the scheduler with static scheduling (it is trivial in thatcase and has to be refined for scheduling several partitions).

The process SCHEDULE1 selects the partition PART_cpiom1 as the active partition

each time the scheduler receives a signal tick, which represents the main clock of thesystem. We suppose that the processor cpiom1 has the same frequency as the main clock.Therefore, the activation of the partition is synchronized with the main clock. The samefor the other scheduler SCHEDULE2.

Figure 7.9: Distributed signal code

The distributed program is automatically generated, applying the distribution com-piling. The original program is compiled into three parts. Figure 7.9 shows partof the generated distributed code of the first node, MODULE_door_management_1,that runs on the first machine (denoted by “1”). The other two are similar toMODULE_door_management_1. The internal inputs and outputs from other distributedparts are automatically added.

lamhosts:10.0.1.3 %the first machine%10.0.1.5 %the second machine%10.0.1.8 %the third machine%run.config:c0 -wd /home/user/Polychrony-V4.17/example/MODULE_door_management_1

10.0.1.3 % node0 runs on the first machine%c1 -wd /home/user/Polychrony-V4.17/example/MODULE_door_management_2

10.0.1.5 % node1 runs on the second machine%c2 -wd /home/user/Polychrony-V4.17/example/MODULE_door_management_3

10.0.1.8 % node2 runs on the third machine%

Table 7.4: Configuration table

Step 3: Adding communications. The communication will be added automatically,since we declared in the pragma: target “MPI”, for using MPI as message passing com-munication protocol in this distributed computing. The messages between the distributed

180

7.3. CONCLUSION

programs are tagged with a unique integer tag. So that the sequence and the integrity ofthe message are guaranteed.

The final physical configuration is shown in Table 7.4. Each distributed node (pro-gram) is configured to a different machine. So that, the distributed programs can be com-piled locally, and run on independent physical processors.

7.3 Conclusion

This chapter presents the principles that generate distributed Signal code from the AADLspecification. The centralized Signal model can be obtained following Chapter 5. Thehardware allocation information is specified in the AADL model. The distribution is basedon the processor binding. The translated partitions that are applied to the same processoras described in AADL specification, are distributed to the same physical machine. Thisdistribution is implemented by using the Signal pragma “RunOn”. The Message PassingInterface (MPI) is used for the communication between the distributed programs. Theapplication is then explained by a real case of door management system.

As a conclusion, from a complete representation of an application, including its virtualdistribution on a target architecture, it is possible to make a global compilation, partition-ing, insertion of communication features, and to simulate the application on the consid-ered architecture.

181


182

Part IV

Validation

Chapter 8

Validation of GALS systems

Contents8.1 Formal verification . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

8.1.1 Case study of a dual flight guidance system . . . . . . . . . . . 187

8.1.2 FGS Modeling in AADL . . . . . . . . . . . . . . . . . . . . . 188

8.1.3 Interpreting the model in Signal . . . . . . . . . . . . . . . . . 190

8.1.4 Checking safety properties with Sigali . . . . . . . . . . . . . . 190

8.2 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

8.2.1 Case study of a door management system . . . . . . . . . . . . 193

8.2.2 System Modeling in AADL . . . . . . . . . . . . . . . . . . . 194

8.2.3 Interpreting the model in Signal . . . . . . . . . . . . . . . . . 196

8.2.4 Other models and system integration . . . . . . . . . . . . . . . 197

8.2.5 Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

8.2.6 VCD-based simulation . . . . . . . . . . . . . . . . . . . . . . 200

8.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Hardware/software co-design of embedded systems needs to meet restricted time, costand performance requirements. Many improvements of classical design approaches havebeen adopted to satisfy these requirements, including parallel development of hardwareand software, high-level modeling, early validation, component-based methods, GALSarchitecture, etc. In this chapter, we briefly show how these improvements are integratedinto our work to tackle the problems of time, cost and performance in the system co-designof avionics.

Our design approach is mainly inspired by the following projects: the Ptolemy project[78], MoBIES project [43], SML-Sys modeling frameworks [144], ForSyDe modelingframeworks [127], etc. In these projects, heterogeneous models or components, basedon different models of computation are integrated into a system either through agent-based methods or through translating them into certain common formalism. We adopt asimilar system-level co-design approach, which is also adopted by Polychrony for the tooldemonstration in the framework of CESAR project [36].

CHAPTER 8. VALIDATION OF GALS SYSTEMS

The proposed approach consists of high-level and/or heterogeneous modeling,semantic-preserving transformation and integration of models, formal verification, andsimulation with regard to performance evaluation. Polychrony is adopted as a commondevelopment platform to bridge heterogeneity between modeling, formal verification andsimulation. The advantages of this approach is that high-level models and transformationsare developed in parallel to reduce time cost; early validation and performance analysisare carried out on high-level models; Polychrony and its associated tools allow the fastvalidation with no need for additional translations to other formalisms.

Two avionic case studies: simplified flight guidance system and simplified door man-agement system, are used in this chapter to illustrate our approach. Formal verificationand simulation, particularly profiling and value change dump (VCD) based demonstra-tion, are also presented with these two case studies.

8.1 Formal verification

In recent years, AADL has been increasingly used for embedded safety-critical systemsfor demonstration purpose in the avionics domain. The main objective is not only re-lated to architecture exploration and analysis. Formal verification of functional aspectsbecomes a very interesting validation approach. Validation of AADL models via formalmethods has been studied in [132, 67, 164, 139], where AADL specifications are associ-ated with formal semantics so that formal verification is performed.

Our approach is involved in model checking in the framework of Polychrony. AADLspecifications are translated into Signal, then the model checking tool associated withPolychrony, called Sigali [126], is used to check safety properties. Sigali adopts polyno-

mial dynamical systems (PDS) [125] over Z/3Z = {-1, 0, 1}) as the formal model. Signalprograms can be transformed into polynomial equations, which are manipulated by Si-gali. The three states of a Boolean signal can be encoded as: present ∧ true ⇔ 1;present ∧ false ⇔ −1; absent ⇔ 0. In case of non-Boolean signals, only their clocksare encoded, i.e., their values are ignored.

PDS can be seen as an implicit representation of an automaton. Each set of statescan be represented by its associated polynomials. By manipulating polynomial equations,Sigali avoids the enumeration of the state space. In Sigali, a polynomial is represented bya Ternary Decision Diagram (TDD), which is an extension of Binary Decision Diagram(BDD).

Model checking can be carried out on PDS [125] with regard to the following proper-ties: liveness, invariance, reachability, and so on. Liveness implies the system can alwaysevolve. This property can be checked through the Sigali command: alive(system),where system is the system to be checked. Invariance indicates that a set of states isinvariant when all the recursive reachable states are also in this set. This property can bechecked through the Sigali command: invariant(system, proposition). Each statein an automaton is associated with propositions. In previous command, propositioncan be considered as a set of states whose proposition is true. When checking reacha-bility, iff the system has always a trajectory towards a state starting from the initial states,this state is considered reachable. This property can be checked through the command:reachable(system, proposition).

186

8.1. FORMAL VERIFICATION

8.1.1 Case study of a dual flight guidance system

To illustrate our approach to formal verification, we take a subsystem of a Flight Con-trol System (FCS) [130] as an example, whose main architecture is shown in Figure 8.1.The subsystem is mainly composed of Flight Guidance System (FGS), which has twosymmetric and redundant implementations (FGS L and FGS R in Figure 8.1). Each im-plementation is situated at one of the two sides of an aircraft. Each FGS implementationconsists of two parts: mode logic and control laws. Mode logic is used to determine theactivation of FGS operation mode. And the operation mode is then used to select rightcontrol laws, which compare the measured state of the aircraft (position, speed, and at-titude) with the desired state in order to generate pitch and roll guidance commands tominimize the difference between the measured and desired state.

ModeLogic

ControlLaws

FGSLModeLogic

ControlLaws

FGSR

Autopilot

Figure 8.1: The simplified flight control system

FGS L and FGS R communicate with each other over a cross-channel bus. These twoFGSs work in two modes: dependent and independent. In normal conditions, only oneFGS (the pilot flying side) is active, while the other one operates as a silent, hot spare.This corresponds to dependent mode of operation. In this mode, the active FGS providesguidance information to other systems. Moreover, the pilot and copilot can switch whichside is the pilot flying side manually. Whereas in some critical conditions, both sides areactive and independently generate guidance information. This corresponds to independent

mode. In this mode, both sets of guidance information are provided to the Autopilot, whichis in charge to verify if they agree with regard to a predefined tolerance value. In case ofagreement, the values are averaged and are taken into account. Otherwise, the situationis sent to the pilots for further decision. A more detailed description of the FGS can befound in [130].

The desired safety requirements for the dual FGS system are presented informallyhere according to [130]: 1) At least one FGS is always active. When the system is on,at least one FGS always provides guidance information. 2) One and only one side is

always identified as pilot flying side. It ensures to avoid that, in the dependent mode ofoperation, both sides provide guidance to the pilots and/or autopilot at the same time. 3)Both FGS are active in the independent mode of operation. This mode is considered ascritical phases of flight, during which system safety requirements shall be satisfied.

187


8.1.2 FGS Modeling in AADL

We only consider a critical part of FGS that deals with the determination of FGS side acti-vation in the formal verification. In addition, the dual FGS system is assumed that neitherFGS implementation can fail, that they execute synchronously, and they communicateover a channel that does not lose data.

In the first step of modeling, components, connections, and inputs/outputs of the over-all system are specified. Based on the system specification, the modeled system consistsof a left and right FGS, and a cross channel bus that connects them (Figure 8.2). Systeminputs include sensor readings and pilot commands.

left FGS

right FGS

left Input right Inputleft Output right OutputBus

Figure 8.2: Architecture for the FGS system

An AADL model of the simplified system and partial code is shown in Figure 8.3.Each FGS is modeled as a thread executed within a separate protected virtual ad-dress space of a process. Each process binds to its own processor so that two FGSwork independently. The system inputs are the transfer, left_independent_mode andright_independent_mode. The system outputs are left_FGS_active and right_FGS_active,which indicate the activation of corresponding side.

The pilot_flying and independent status of each FGS is communicated with the othervia a bus. These two values convey each FGS’ determination of whether it is the pilotflying side and whether it is in independent mode. In the synchronous modeling, the busholds communication data for one step and then send them to their destination.

Partial code of the thread of FGS is shown below. The AADL behavior annex is usedto specify the computation. The FGS thread transits between primary and backup states.When it transits to primary state, the pilot_flying and active status is set to be true.

thread FGS_thread

features

ts: in event data port behavior::boolean;

inde_mode: in event data port behavior::boolean;

other_pf: in event data port behavior::boolean;

other_inde: in event data port behavior::boolean;

pf: out event data port behavior::boolean;

tindependent: out event data port behavior::boolean;

tactive: out event data port behavior::boolean;

properties

Period => 100 Ms;

end FGS_thread;

thread implementation FGS_thread.impl


states

primary: state;

backup: state;

188


Figure 8.3: AADL model for the ideal FGS system

transitions

primary -[other_pf?(true) ]-> backup

{ pf!(false); tindependent := inde_mode;};

backup -[ts?]-> primary { pf!(true); tactive!(true);

tindependent := inde_mode;};

189


**};

end FGS_thread.impl;

8.1.3 Interpreting the model in Signal

Each FGS process is interpreted as an ARINC partition (PART_cpu1, PART_cpu2) illus-trated in Figure 8.4. They communicate with each other through two buses: bus1 andbus2.

Figure 8.4: The Signal code for the FGS system

In order to make it more clear and more readable, we simplify and refine the generatedFGS thread Signal code as shown below. Appendix B shows the complete generatedSignal code of the FGS system.

process ThreadT_tFGS =

{boolean Ini_PF;boolean Ini_OPF;} % init for pilot flying and other side pilot flying%

( ? boolean Transfer,Other_PF,Other_Independent,Inde_mode;

! boolean Independent,PF,Active;)

(| ZPF := PF$ init Ini_PF % previous pilot flying %

| ZOPF := Other_PF$ init Ini_OPF % previous other side pilot flying %

| FC := Transfer and (not ZPF) % when transfer and previous pilot flying is not true %

| PF := (true when FC)

default (false when (Other_PF and (not ZOPF)) when not FC)

% when other side becomes pilot flying from not pilot flying %

default ZPF

| Independent := Inde_mode % independent mode %

| Active := PF or (Other_Independent and Inde_mode) % active state %

|)

where

boolean ZOPF, ZPF, FC;

end;

8.1.4 Checking safety properties with Sigali

Polynomial dynamical systems, as symbolic represention of the Sigali-based modelchecking, are obtained by compiling the Signal programs with the -z3z parameter. For in-stance, the following command is used to translate the generated Signal programs (namedDFGS.sig file) to polynomial dynamical systems:

signal -z3z DFGS.sig

190


The z3z file DFGS.z3z is generated as output after the compiling. This file, togetherwith library files, is loaded in the verification system by using the load or read command.The following commands are used for loading the files for our example:

%sigali

*-----------------------------------------------*

* Sigali - version 2.3 (Dec 2005) *

*-----------------------------------------------*

Sigali: read("DFGS.z3z");

-------------------------------------------------

Sigali: read("Creat_SDP.lib");

-------------------------------------------------

Sigali: read("Bibli.lib");

-------------------------------------------------

In the next, previously presented safety properties are formalized with Sigali propertyspecifications, which are mainly based on computational tree logic (CTL). With thesecommands, Sigali verifies if the properties hold for the overall system in an interactiveway:

• Property 1: At least one FGS is always active.

To show this, we first define Property 1 in Sigali as follows (S represents the polyno-mial dynamical system of Signal program DFGS.sig generated by Sigali, Lactiveand Ractive are the two outputs in the Signal program representing respectivelyleft and right side active):

Property1 := B_Or(B_True(S, Lactive),B_True(S, Ractive)),

and the property 1 in CTL to be checked:

AG(Property1)

which states that Property 1 is always globally true.

The result of the verification is illustrated in the next. The Property 1 is alwayssatisfied according to the result.

Sigali : subset(initial(S),AG(B_Or(B_True(S,Lactive),

B_True(S,Ractive))));

-------------------------------------------------

True

-------------------------------------------------

• Property 2: One and only one side is always identified as pilot flying side

We define Property 2 in Sigali as follows (LPF and RPF are the two outputs in theSignal program representing respectively the left and right pilot flying):

Property2 := B_Or(Equal(B_True(S,LPF), B_False(S,RPF)),

Equal(B_False(S,LPF),B_True(S,RPF))),

191


and the property in CTL to be checked:

AG(Property2)

We check the property with Sigali:

Sigali : subset(initial(S),AG(B_Or(Equal(B_True(S,LPF),B_False(S,RPF)),

Equal(B_False(S,LPF),B_True(S,RPF)))));

----------------------------------------------------------------------

False

-----------------------------------------------------------------------

The verification result states that this property is not always satisfied. Analysis hasbeen carried out to find counter-examples. According to the analysis, in certaincases as illustrated in Table 8.1, when pilot flying side is switched by pilot com-mand, the new side takes effect immediately. However, the previous pilot flyingside is switched off until the next tick because of one tick communication delay.

Transfer 1Inputs L_inde_mode 1

R_inde_mode 1LPF 1RPF 1

Outputs Lactive 1Ractive 1

Table 8.1: A counter-example exhibited by one single tick of analysis

Actually, even this property is not hold for one tick, it is still acceptable. Hence werelax the property:

AG(!Property2 -> AX(Property2)).

It implies that for all states, the property can be false for at most one tick. Thisproperty is checked by Sigali and it always holds:

Sigali : subset(initial(S),AG(B_Or(B_Or(Equal(B_True(S,LPF),

B_False(S,RPF)),Equal(B_False(S,LPF),B_True(S,RPF))),AX(B_Or

(Equal(B_True(S,LPF),B_False(S,RPF)),Equal(B_False(S,LPF),

B_True(S,RPF)))))));

-----------------------------------------------------------

True

-----------------------------------------------------------

• Property 3: Both FGS are active in the independent mode of operation.

We define Property 3 in Sigali as follows (LIndependent and RIndependent arethe two outputs in the Signal program representing respectively the left and rightindependent mode):

192

8.2. SIMULATION

Property3 := B_Or(Complementary(

B_And(B_True(S,LIndependent),B_True(S,RIndependent))),

B_And(B_True(S,Lactive),B_True(S,Ractive))).

Property 3 does not always hold according to the verification result. Similar toProperty 2, Property 3 is relaxed by one tick, and we retry the check:

AG(!Property3 -> AX(Property3)).

This turns out to be true and acceptable.

8.2 Simulation

In this section, we depict the design process for the co-modeling and co-simulation ofa CESAR case study in the framework of Polychrony. This design process is based on aco-design approach at the system level [166]. Polychrony is served as a common develop-ment platform. Simulation is carried out for the purpose of verification and timing-relatedanalysis at the system level.

8.2.1 Case study of a door management system

SDSCS (Simplified Doors and Slides Control System) is a generic simplified version ofthe system that allows managing doors on Airbus series aircrafts. It is a safety-critical sys-tem since incorrect door closing or opening during flight may lead to fatal crashes. Thereliable system design and validation are therefore very important. In addition to the ful-fillment of safety objectives, high-level modeling and component-based development arealso expected for fast and efficient design. SDSCS has been chosen for the demonstrationof capabilities developed in the CESAR project [35].

An Airbus aircraft has several kinds of doors, such as passenger, cargo and emergencydoors. Here we focus on the management of two passenger doors. Each passenger doorhas a software handler, which achieves the following four tasks:

• monitor door status via door sensors;

• control flight lock actuators;

• manage the residual pressure of the cabin by controlling the outflow valves, visualstatus indication and an aural warning;

• and inhibit cabin pressurization if any external door is not closed, latched andlocked.

The four tasks are implemented with simple logic that determines the status of monitors,actuators, etc., according to the sensor readings. In addition to sensors and actuators,SDSCS is equipped with other hardware components, such as processing units, commu-nication link, and concentrators. The SDSCS is implemented on the IMA (IntegratedModular Avionics) platform, in which CPIOMs (Core Processing Input/Output Modules)

193


and RDCs (Remote Data Concentrators) are connected via the AFDX (Aircraft Full Du-pleX) network (Figure 8.5). Sensors and actuators are also connected to RDCs via AFDX.CPIOMs receive sensor readings via RDCs and communicate also with other systems viaAFDX.

Figure 8.5: A simple illustration of the SDSCS system architecture.

This case study is simple yet complete to illustrate the effectiveness of our proposedAADL-based system-level simulation. In the next, the AADL modeling of this avionicsystem, model transformation and integration with other high-level models, and systemco-simulation are presented.

8.2.2 System Modeling in AADL

Figure 8.6 shows an overview of the SDSCS modeled in AADL. The whole system ispresented as an AADL system. The two doors, door1 and door2, are modeled as subsys-

tems. They are controlled by two processes doors_process1 and doors_process2 respec-tively. These processes are bound to two processors: CPIOM1 and CPIOM2, to performthe computation independently. Sensors and Actuators, such as LGS, DPS, OCU, etc.,are modeled as AADL devices that interface with external environment of the system.The sensors and actuators inside a door are gathered either in door1 or door2. All thecommunication between the devices and processors is through the bus: AFDX1. SD-SCS has three threads to manage doors: door_handler1, door_handler2, and doors_mix.These threads are implemented by Simulink models. In addition, each processor runs onedoors_process. These two components are placed into one ARINC partition. Each pro-

cessor is associated with an ARINC partition_level_OS, which is responsible for schedul-ing all the processes in the same partition. In this example, all the threads and devices areperiodic, and share the same periodicity. The detailed AADL textual model can be foundin Appendix A.

Figure 8.7 gives a more precise description of the doors_process. It contains threethreads for the door management: door_handler1, door_handler2, and doors_mix. Athread is a schedulable functional unit that executes instructions in the virtual space as-signed to the process owning it. In this case study, AADL is mainly used for the modelingof system architecture. The functional modeling is expected to be open for other high-level modeling languages. Simulink is adopted in this case study, i.e., the behavior ofthree threads are modeled in Simulink.

194

8.2. SIMULATION

Figure 8.6: An overview of the AADL modeling of SDSCS

Figure 8.7: The threads in the doors_process

195


Figure 8.8: Graphical representation of an AADL door subsystem

A detailed modeling of the door1, as an AADL subsystem, is illustrated in Figure 8.8.It contains nine devices as its subcomponents.These devices are models of door sensorsand actuators.

AADL SMEa: component :: ThreadType sme :: ModelDeclaration

and b:component :: ThreadImpl and its instance (sme :: ModelInstance)and b.compType = a

instance name ModelDeclaration.name

ProcessType. f eatures.dataPort ModelDeclaration.inputs

ProcessType. f eatures.eventPort or ModelDeclaration.outputs

ProcessType. f eatures.eventDataPort depending on the port direction attributeFor each of its subcomponents defined sme :: ModelDeclaration and its instance

in ProcessImpl.subcomponents (sme :: ModelInstance) included inthe parent’s attribute modelDeclarations

ProcessImpl.connections sme :: Data f lowConnection

Table 8.2: Thread Transformation

8.2.3 Interpreting the model in Signal

This model contains two processes. Each process has three periodic threads. The process

is transformed into an ARINC partition, and thread is transformed into an ARINC pro-

cess. Table 8.2 summarizes the AADL Ecore model and its corresponding transformationin SME model. SME is the Signal meta under Eclipse, and it includes the meta-model ofthe Signal language extended with mode automata concepts.

Figure 8.9 gives a partial code specification of the process doors_process in Sig-nal. The Signal process Scheduler_CPIOM() is a scheduler that schedules the three

196

8.2. SIMULATION

threads. Each thread is translated into a timing environment process (e.g. Proper-

tyT_door_handler()) and a functional process (e.g. ThreadT_door_handler()). The de-tailed implementation of these processes can be found in Appendix A.

Figure 8.9: Partial Signal code of doors_process

8.2.4 Other models and system integration

As mentioned previously, functional part of SDSCS can be modeled with other modelinglanguages. In this case study, Simulink and/or Stateflow in the Matlab family are adopted.Dataflow models and state machines are common models of computation adopted in thesystem design of avionics, automotive applications, etc. One of the most popular toolsthat accept these models is Simulink/Stateflow [26]. Gene-Auto is a framework for codegeneration from a safe subset of Simulink and Stateflow models for safety critical embed-ded systems [155]. This safe subset is also adopted in our work. From now on, Simulinkis used for short to indicate the subset of Simulink and/or Stateflow languages that isadopted by Gene-Auto.

197


Only discrete time of Simulink is taken into account here. Moreover, each block ofSimulink is associated with a specific activation clock. A global activation clock is usedto synchronize the activation clocks of Simulink blocks. From this point of view, ourSimulink model is synchronous. The Simulink model is shown in Figure 8.10. Sensors,such as flight_status, dps, and door_io_in, are connected to four Simulink blocks, eachof which implements a SDSCS task as mentioned in the previous subsection. The modeltransformation chain from functional models in Simulink to Signal which is similar to thetransformation from AADL to Signal, is under development by other colleagues.

Figure 8.10: The door handler component of the SDSCS modeled in Simulink

In addition to the high-level Simulink and AADL models, additional models are alsoneeded in the SDSCS for the complete simulation. They include an allocation model, ascheduler model and an environment model.

In this case study, the allocation of functionality onto architecture is specified in theAADL model. In the AADL to Signal transformation, all the threads mapped on to thesame processor (CPIOM) are placed in the same partition. The generated Signal pro-grams are annotated with allocation information. All the Signal processes translated fromthe same partition have the same Signal pragma RunOn “i” [59], which enables the distri-bution of these processes onto the same processor i (as presented in Chapter 7).

According to the AADL specification, a partition-level scheduler is needed for thesimulation. In this case study, a simple static scheduler is implemented. This schedulertakes events, such as dispatch, start, completion, etc., into account for the scheduling ofthreads in the same partition. Simple non-preemption partition-level schedulers have beencoded in Signal manually for the simulation. More sophisticated schedulers, such as thatprovided by Cheddar [146] are expected to be integrated into the system.

Sensors and actuators are the media between SDSCS and its environment. The en-vironment with regard to SDSCS includes the aircraft system outside SDSCS as well asthe environment outside the aircraft which provides flight altitude, air speed, etc. Theenvironment modeling is carried out directly in Polychrony. Several Signal processes areadded as environment models. For instance, a process detects the close status of physi-

198

8.2. SIMULATION

cal doors and sends the close signals to door sensors, another process provides air speedreadings to aircraft speed signals sensors. These Signal processes that model the environ-ment are composed with other Signal processes that are transformed from the high-levelSimulink and AADL models.

Once all the needed models are obtained, the composition of these models is pos-sible. All the parts, such as system behavior, hardware architecture, environment, andschedulers, are expressed by Signal processes, thus a composition of these processes im-plies system integration. Functional models in Figure 8.11 imply the composition ofall processes translated from Simulink. The communication of distributed processes isimplemented by MPI (Message Passing Interface). Architecture models indicate the com-position or connection of hardware interfaces and hardware implementations. Simulation

clocks are used to provide reference clocks and periodical clocks for simulation. The in-tegrated system is then used for C or Java code generation via the Signal compiler forsimulation purpose.

Figure 8.11: The system integration from the point of view of Signal processes

8.2.5 Profiling

Software profiling is considered as a kind of dynamic program analysis through the infor-mation gathered when the program executes. This analysis is always involved in perfor-mance improvement. Profiling is also adopted in Polychrony for the performance evalua-tion of Signal programs [106] [82]. The profiling process includes: temporal propertiesspecification, temporal homomorphism, and co-simulation.

In the framework of Polychrony, profiling refers to timing analysis through associat-ing date and duration information to Signal programs. Each signal x in the program isassociated with a date signal, date_x, to indicate its availability time. This date signalmay be specified with metric clock, logical clock or clock cycles. In the first case, datesignals are positive real numbers, and in other cases they are positive integers. Each oper-ation in Signal programs is associated with the duration information, which has the samedata type as date signals. The duration is represented by a pair of numbers correspondingto the worst and best case. Furthermore, it is a function of several parameters related tooperation type, data types, and implementations on different architectures, etc.

199


A morphism of Signal processes represents a series of transformations of Signal pro-cesses without changing their synchronous semantics. The set of homomorphic Signalprocesses exhibits different behavioral aspects of original Signal processes. Temporalproperties are introduced in the morphism of Signal processes so that they are used toreveal the timing aspect of these processes. A Signal process can be considered as a di-rected graph of signals and operations, where signals are arcs and operations are nodes. Atemporal morphism of Signal process preserves the graph structure. However, nodes arereplaced by operation durations and arcs are replaced by date signals.

In addition, duration parameters of Signal operations allow the parameterization ofhomomorphism. These parameters together with their values allow specifying the execu-tion of operations on specific architecture (particularly processing elements). They alsoenable to import and use specific libraries of cost functions in the homomorphism.

As the temporal homomorphism preserves the synchronous semantics, the homomor-phic Signal processes can be composed together for the co-simulation. The latter exhibitsthe timing behavior with regard to previously mentioned temporal properties. Figure 8.12illustrates a schema of the co-simulation that has been carried out successfully. SDSCS

is the original Signal program, whose inputs I are provided by Inputs. T(SDSCS) is thetemporal homomorphism of SDSCS with regard to specified Temporal properties and aparameterization of Library of cost functions. Date provides date signals to T(SDSCS) ac-cording to I. The input signals are synchronized to their corresponding date signals. Con-trol values of SDSCS, which decide specific traces of execution, are sent to T(SDSCS) sothat they have the same execution traces. Date signals of inputs and outputs of T(SDSCS)

are finally sent to Observer in order to obtain the simulation result V.

Figure 8.12: The co-simulation of Signal programs with regard to their temporal behavior

8.2.6 VCD-based simulation

In addition to profiling, another simulation has also been carried out. It aims at the vi-sualization of value change during the execution of programs via VCD. VCD files aregenerally generated by EDA (Electronic Design Automation) logic simulation tools, andthey adopt an ASCII-based file format, whose simplicity and compact structure allows awide spread in application simulation. Moreover, the four-value VCD format has beendefined as IEEE Standard [33] together with VHDL (Verilog Hardware Description Lan-guage). In our simulation, traces are recorded in VCD format. The VCD files are used forthe visualization of simulation results through graphical VCD viewers, such as GTKWave

200

8.3. CONCLUSION

[34]. Figure 8.13 shows a visualization result of the simulation. In this figure, the changeof signal values with regard to the fastest clock is shown. The visualization can also bedone dynamically at the same time as the execution.

Figure 8.13: Simulation by a VCD viewer: GTKWave

8.3 Conclusion

In this chapter, we describe a formal verification and simulation tool chain for AADL. Wegive a high-level view of the tools involved and illustrate the successive transformationsrequired by our verification process. Two case studies are presented for the illustration ofAADL application validation, particularly, formal verification and simulation.

With the first case study, model checking of AADL models via Polychrony is brieflyillustrated. AADL is used to model a simplified flight guidance system (FGS). Then theAADL models are translated into a symbolic representation, i.e., polynomial dynamicalsystems, manipulated by the model checker Sigali. With Sigali, safety properties ex-pressed in CTL are checked on the system.

The second case study is called Simplified Doors and Slides Control System (SDSCS)from avionics. In addition to the AADL simulation, this case study also illustrates an ap-proach to address high-level and heterogeneous model based system co-design, based onthe globally asynchronous locally synchronous system architecture (GALS). In this casestudy, distributed hardware architecture, together with their asynchronous aspects, is mod-eled in AADL, whereas functional behavior, expressed with the synchronized dataflowmodel, is modeled in Simulink. SME/Polychrony is adopted as a common formalismto bridge between two heterogeneous models. The AADL modeling and transformationresults in Signal are given. An early phase simulation via profiling in consideration oftiming constraints and also a simulation demonstration by VCD viewers are enabled inthe framework of Polychrony.

As a perspective, connections to more simulation tools with regard to timing analysisare expected, such as Syndex [25] and RT-Builder [22].

201


202

Conclusion

AADL (Architecture Analysis and Design Language), as an SAE (Society of AutomotiveEngineers) standard, is dedicated to the high-level design and evaluation for embeddedsystems. It is particularly used in the modeling and analysis of avionic applications. Itallows describing both system structure and functional aspects via a component-basedapproach, e.g., locally synchronous processes are allocated onto a distributed architectureand communicate in a globally asynchronous manner (GALS system). In order to enableearly-phase validation and step-wise refinement, our objective of this thesis is to model,transform and validate such systems in a synchronous programming framework, and thenautomatically generate its GALS implementation.

The polychronous model of computation (MoC), based on the concepts of the syn-chronous approach, allows specifying a system whose components can have their ownworking frequency, or their local activation clock. It is well adapted to support a GALS de-sign methodology. In addition, formal verification, simulation and analysis technologieshave been developed over this model for the design of embedded systems. Polychrony,based on the polychronous model, is a unified framework of modeling, transformation,refinement, validation of embedded systems design.

The main motivation of the work presented in this thesis is to bridge the gaps be-tween AADL and Polychrony: a proposition of a methodology for system-level modelingand validation of embedded systems specified in AADL via the polychronous MoC. Thismethodology includes system-level modeling via AADL, automatic transformations fromthe high-level AADL model to the polychronous model, code distribution, formal verifi-cation, simulation of the obtained polychronous model, and model refinement accordingto the validation results.

Contributions

Our system-level design takes into account both the system architecture, particularly de-scribed in Integrated Modular Avionics (IMA), and functional aspects, e.g., software com-ponents implemented in the synchronous programming language Signal. Starting fromhigh-level AADL specifications, automatic code distribution for simulation has been ex-perimented via the polychronous model and Signal distribution pragmas. In addition,AADL Behavior annex, an extension for the specifications of the actual behaviors, is alsoinvolved in the translation from AADL to Signal. It relies on the use of SSA (Static SingleAssignment) as intermediate formalism. High-level simulation, validation and verifica-tion are then carried out by associated technologies and tools, such as Sigali, profiling,and value change demonstration, to formal check and analyze the result model. Existing

Conclusion

techniques and libraries of Polychrony, which consist of a model of the APEX-ARINCreal-time operating system services, have been used. The main contributions are detailedin the following:

Synchronous modeling of a subset of the AADL model. We have proposed a formalmethodology to model a subset of the AADL model into synchronous formalism in theIMA architecture [121]. This modeling bridges the gaps between AADL and synchronouslanguages with the help of Polychrony. By analyzing the time domains, the AADL archi-tectures and components with abstract logical time are expressed in the polychronousframework with more concrete simulation time. Since we use a modular approach todefine the AADL model, it supports a structured design of the semantics of the AADLapplication. The resulting Signal model from the transformation of the AADL modelpreserves the structured semantics of the original design. It turns out to be an effectiveapproach to transform a hierarchy of AADL applications into a set of synchronous equa-tions. On one hand, this transformation preserves the structural and semantic propertiesof original AADL specifications, which insures that verifications carried out on the Signalmodel are also valid for the AADL model. On the other hand, it keeps the characteristicsassociated with synchronous languages, enabling a formal and clear semantic definition.

Formal interpretation of AADL Behavior Annex. AADL Behavior Annex specifiesthe local functional behaviors of the AADL components, without requiring external targetlanguages. We have presented an interpretation of the Behavior Annex into a synchronousdata-flow and multi-clocked MoC [122]. In this interpretation, SSA is used as an interme-diate formalism. A thorough description of an inductive SSA transformation algorithmacross a hierarchy of transitions that produces synchronous equations is presented. Withregard to verification requirements, this interpretation minimizes the number of statesacross automata, hence provides good model checking performance. The interpretation isexpressed by a set of flexible transformation rules, which simplifies the interpretation.

Distributed code generation. We use Polychrony to distribute the centralized code todifferent physical processors. We have presented, from a complete representation of anAADL model, including its virtual distribution on target hardware components, how it ispossible to have distributed Signal programs, making a partitioning of the application onthe target physical architecture [123]. Our approach is a practical application of formal re-sults that have been proved by the polychronous MoC, for which it has been shown that ifthe distributed programs or processes are endo-isochronous (assume that the deploymentis simply performed by using an asynchronous mode of communication), then the originalsemantics of each individual process of the deployed GALS architecture is preserved.

Formal verification, simulation and analysis. Besides that the synchronous model issuitable to express real-time applications, the code generated from this model allows oneto reason about safety-critical behavior of these applications. In that way, formal veri-fication and simulation, based on the generated Signal code, are possibly carried out tocheck the reliable design of AADL applications. With the model checker Sigali, a model

204

Conclusion

checker associated with Polychrony, properties and functional correctness of the applica-tion can be checked. The verification results help to reveal safety-related problems in theoriginal design in AADL. Early-phase simulation, including profiling and value changedemonstration, in consideration of timing constraints are also carried out in our work.Profiling, together with parameters that represent chararcteristics of specific architecture,is performed to illustrate performance-related analysis, for example, worst case executiontime. Another simulation is involved in value change demonstration via value changedump (VCD). It shows the signal value change during the system execution.

Perspectives

Extension of the modeling. A subset of AADL has been handled in the synchronousmodeling in this thesis, which includes periodic threads, immediate and delayed connec-tions, buses, Bebavior Annex, etc. The accomplished modeling and transformations showan interesting and promising result. An extension of this modeling is expected to covera larger scope of AADL, e.g., different types of threads, data, subprogram calls, client-server protocol [165], semi-synchronous protocol, as well as more temporal aspects thatare related to GALS design and enable more sophisticated timing analysis. Indeed, thisextension of the modeling would enable to verify more complex system behavior of ap-plications specified in AADL. Another extension consists in providing a model libraryin Signal, which addresses standard component modeling. This library includes canon-ical models, which can be parameterized to model similar components of AADL, e.g.,aperiodic and sporadic threads. Models of AADL hardware components, e.g., bus andprocessor, can be included in this library. This library helps to reduce the repetitive mod-eling task.

Extension of validation. We are currently using Sigali in the formal verification pro-cess. One possible perspective of this work is to perform timed model checking, whichrequires a translation of the Signal model into other timed model for verification. In thatcase, it would be possible to formally define best-case and worst-case time behavior ofthe AADL model [119]. In addition to the verification and simulation, connections tomore simulation tools with regard to timing analysis are expected, such as SynDEx [25],RT-Builder [22], etc. Starting with modules described in AADL architecture descriptionlanguage, we are seeking for an approach for the verification of GALS systems. Onecould also model and verify GALS systems using a combination of synchronous lan-guages and other languages, such as Promela, process calculi, etc., for communicationchannels and asynchronous concurrency [75]. We can extend this work as the refinementof a synchronous component into a set of asynchronous modules. Insert desynchroniza-tion buffers into such a refinement and model check the correctness of the refinementusing flow preservation refinement and real-time constraints are desired. Moreover, wecan study different types of interconnections between the synchronous components. Thiswould allow for verification of more complex GALS systems going beyond point-to-pointconnections.

205

Conclusion

Extension of the scheduling model. Scheduling specified in AADL has been addressedin a simple and static way in this thesis. Extensions of our scheduling model is also aperspective. First extension is involved in the integration of complete scheduling statemachines into threads. Certain scheduling states have already been introduced in ourmodeling, but it is not complete compared to AADL specification. Then a partition-levelscheduler, in accordance with ARINC, can be integrated into each processor. Second ex-tension concerns the integration of standard or off-the-shelf schedulers into the system forsimulation purpose, e.g., an existing scheduler has been written in Signal for ARINC [85],or Cheddar [8] provides schedulers that implement standard scheduling strategies.

206

Bibliography

[1] AADL. http://www.aadl.info/.

[2] AADL Users. http://www.aadl.info/aadl/currentsite/start/who.

html.

[3] AADL2SYNC, Verimag. http://www-verimag.imag.fr/~synchron/index.php?page=aadl2sync.

[4] ACME. http://www.cs.cmu.edu/~acme/.

[5] Ada. http://www.adaworld.com/.

[6] AIRBUS. http://www.airbus.com/en/.

[7] BIP, Verimag. http://www-verimag.imag.fr/BIP,196.html.

[8] Cheddar Project. http://beru.univ-brest.fr/~singhoff/cheddar.

[9] EADS, European Aeronautic Defense and Space company. http://www.eads.com.

[10] Ellidiss Software. http://http://www.ellidiss.com/.

[11] ESA, European Space Agency. http://www.esa.int/esaCP/index.html.

[12] Honeywell. http://www51.honeywell.com/honeywell/.

[13] LAM MPI. http://www.lam-mpi.org/.

[14] MARTE. http://www.omgmarte.org/.

[15] Ocarina Project. http://ocarina.enst.fr/.

[16] Open MPI. http://www.open-mpi.org/.

[17] OpenEmbeDD. http://openembedd.org/home_html.

[18] OSATE. http://gforge.enseeiht.fr/projects/osate/.

[19] POK. http://penelope.enst.fr/aadl/wiki/PokUsageWithOcarina.

[20] PolyORB-HI-C. http://penelope.enst.fr/aadl/wiki/

PolyorbhicPresentation.

http://www.aadl.info/

http://www.aadl.info/aadl/currentsite/start/who.html

http://www.aadl.info/aadl/currentsite/start/who.html

http://www-verimag.imag.fr/~synchron/index.php?page=aadl2sync

http://www-verimag.imag.fr/~synchron/index.php?page=aadl2sync

http://www.cs.cmu.edu/~acme/

http://www.adaworld.com/

http://www.airbus.com/en/

http://www-verimag.imag.fr/BIP,196.html

http://beru.univ-brest.fr/~singhoff/cheddar

http://www.eads.com

http://www.eads.com

http://http://www.ellidiss.com/

http://www.esa.int/esaCP/index.html

http://www51.honeywell.com/honeywell/

http://www.lam-mpi.org/

http://www.omgmarte.org/

http://ocarina.enst.fr/

http://www.open-mpi.org/

http://openembedd.org/home_html

http://gforge.enseeiht.fr/projects/osate/

http://penelope.enst.fr/aadl/wiki/PokUsageWithOcarina

http://penelope.enst.fr/aadl/wiki/PolyorbhicPresentation

http://penelope.enst.fr/aadl/wiki/PolyorbhicPresentation

BIBLIOGRAPHY

[21] Rockwell Collins. http://www.rockwellcollins.com/.

[22] RT-Builder. http://www.geensoft.com/.

[23] SEI. http://www.sei.cmu.edu/.

[24] SME, ESPRESSO, INRIA. http://www.irisa.fr/espresso/Polychrony/.

[25] Syndex. http://www-rocq.inria.fr/syndex/.

[26] The MathWorks Simulink. http://www.mathworks.com/products/

simulink/.

[27] The MathWorks Stateflow. http://www.mathworks.com/access/helpdesk/help/toolbox/stateflow.

[28] Topcased-aadl. http://gforge.enseeiht.fr/projects/topcased-aadl.

[29] Topcased Project. http://www.topcased.org.

[30] Unified Model Language. http://www.omg.org/.

[31] ADL, 2005. http://www.itl.nist.gov/div897/ctg/adl/adl_info.html.

[32] Cinderella SDL 1.3, 2005. http://www.cinderella.dk/.

[33] IEEE Standard for Verilog Hardware Description Language (VHDL), 2006. IEEEStd 1364 -2005.

[34] GTKWave, 2010. http://gtkwave.sourceforge.net/.

[35] T.C. Project, Cost-efficient methods and processes for safety relevant embeddedsystems, 2010. http://www.cesarproject.eu.

[36] The CESAR project, Cost-efficient methods and processes for safety relevant em-bedded systems. http://www.cesarproject.eu, 2010.

[37] Avionics Application Software Standard Interface. Airlines Electronic Engineering

Committee, ARINC Specification 653, January 1997.

[38] Architecture Analysis and Design Language, AS5506. Society of Automotive En-

gineers, SAE standard, V2.0, January 2009.

[39] Design Guidance for Integrated Modular Avionics. Airlines Electronic Engineering

Committee, ARINC Report 651-1, November 1997.

[40] AADL. Carnegie Mellon University. http://www.aadl.info/aadl/

currentsite/newsbriefs.html.

[41] SAE Aerospace. Architecture Analysis and Design Language (AADL). SAE

AS5506, 2004.

208

http://www.rockwellcollins.com/

http://www.geensoft.com/

http://www.sei.cmu.edu/

http://www.irisa.fr/espresso/Polychrony/

http://www-rocq.inria.fr/syndex/

http://www.mathworks.com/products/simulink/

http://www.mathworks.com/products/simulink/

http://www.mathworks.com/access/helpdesk/help/toolbox/stateflow

http://www.mathworks.com/access/helpdesk/help/toolbox/stateflow

http://gforge.enseeiht.fr/projects/topcased-aadl

http://www.topcased.org

http://www.omg.org/

http://www.itl.nist.gov/div897/ctg/adl/adl_info.html

http://www.cinderella.dk/

http://gtkwave.sourceforge.net/

http://www.cesarproject.eu

http://www.cesarproject.eu

http://www.aadl.info/aadl/currentsite/newsbriefs.html

http://www.aadl.info/aadl/currentsite/newsbriefs.html

BIBLIOGRAPHY

[42] SAE Aerospace. Annex Behavior Language Compliance and Application ProgramInterface. SAE AS5506, 2006.

[43] R. Alur, T. Dang, J. Esposito, Y. Hur, F. Ivancic, V. Kumar, I. Lee, P. Mishra,G. J. Pappas, and O. Sokolsky. Hierarchical modeling and analysis of embeddedsystems. Proc. IEEE, 91(1):11–28, 2003.

[44] Ross Anderson. Security Engineering: A Guide to Building Dependable Dis-

tributed Systems. Wiley, Computer Laboratory, University of Cambridge, January2001.

[45] Charles André, Frédéric Mallet, and Robert de Simone. Modeling Time(s). InLNCS, pages 559–573. Springer, 2007.

[46] Eshrat Arjomandi, Michael J. Fischer, and Nancy A. Lynch. Efficiency of Syn-chronous Versus Asynchronous Distributed Systems. J. ACM, 30(3):449–456,1983.

[47] P. Aubry, P. Le Guernic, and S. Machard. Synchronous Distribution of SIGNALPrograms. Hawaii International Conference on System Sciences, 0:656, 1996.

[48] Felice Balarin and Alberto Sangiovanni-Vincentelli. Schedule Validation for Em-bedded Reactive Real-Time Systems, 1997.

[49] A. Benveniste, P. Le Guernic, and C. Jacquemot. Synchronous programming withevents and relations: the SIGNAL language and its semantics. Science of Computer

Programming, pages 16:103–149, 1991.

[50] Albert Benveniste and Gérard Berry. The synchronous approach to reactive andreal-time systems. In Proceedings of the IEEE, pages 1270–1282, 1991.

[51] Albert Benveniste, Benoït Caillaud, and Paul Le Guernic. From synchrony to asyn-chrony. In CONCUR’99, Concurrency Theory, 10th International Conference, Vol-

ume 1664 of Lecture Notes In Computer Science, pages 162–177. Springer, 1999.

[52] Albert Benveniste, Paul Caspi, Stephen A. Edwards, Nicolas Halbwachs, Paul LeGuernic, and Robert De Simone. The synchronous languages twelve years later. InProceedings of the IEEE, pages 64–83, 2003.

[53] Albert Benveniste, Paul Caspi, Paul Le Guernic, Hervé March, Jean-Pierre Talpin,and Stavros Tripakis. A protocol for loosely time-triggered architectures. In In

Embedded Software Conference, pages 252–266. Springer, 2002.

[54] Albert Benveniste, Paul Le Guernic, and Christian Jacquemot. Synchronous pro-gramming with events and relations: the SIGNAL language and its semantics. Sci.

Comput. Program., 16(2):103–149, 1991.

[55] Gérard Berry and Georges Gonthier. The Esterel Synchronous Programming Lan-guage: Design, Semantics, Implementation, 1992.

209

BIBLIOGRAPHY

[56] Bernard Berthomieu, Jean-Paul Bodeveix, Patrick Farail, Mamoun Filali, HubertGaravel, Pierre Gaufillet, Frederic Lang, and François Vernadat. Fiacre: an Inter-mediate Language for Model Verification in the Topcased Environment. In ERTS

2008, Toulouse France, 2008.

[57] Bernard Berthomieu, Jean-Paul Bodeveix, Patrick Farail, Mamoun Filali, HubertGaravel, Pierre Gaufillet, Frederic Lang, and François Vernadat. Fiacre: an Inter-mediate Language for Model Verification in the Topcased Environment. In ERTS

2008, Toulouse France, 2008.

[58] L. Besnard, T. Gautier, and P. Le Guernic. SIGNAL V4-Inria Version: Referencemanual. http://www.irisa.fr/espresso/Polychrony.

[59] L. Besnard, T. Gautier, P. Le Guernic, and J.-P. Talpin. Compilation of poly-chronous data flow equations. In Sandeep Shukla and Jean-Pierre Talpin, edi-tors, Correct-by-Construction Embedded Software Synthesis: Formal Frameworks,

Methodologies, and Tools, 2010.

[60] Loïc Besnard, Thierry Gautier, Paul Le Guernic, and Jean-Pierre Talpin. Com-pilation of polychronous data flow equations. Correct-by-construction embedded

software design, 2010.

[61] Loïc Besnard, Thierry Gautier, Matthieu Moy, Jean-Pierre Talpin, Kenneth John-son, and Florence Maraninchi. Automatic translation of C/C++ parallel code intosynchronous formalism using an SSA intermediate form. In Ninth International

Workshop on Automated Verification of Critical Systems (AVOCS’09). ElectronicCommunications of the EASST, September 2009.

[62] Egon Börger. Abstract State Machines: A Method for High-Level System Design

and Analysis. Springer-Verlag Berlin Heidelberg New York, 2003.

[63] Marc M. Brandis and Hanspeter Mössenböck. Single-pass generation of staticsingle-assignment form for structured languages. ACM Transactions on Program-

ming Languages and Systems, 16(6):1684–1698, Nov 1994.

[64] Preston Briggs, Keith D. Cooper, Timothy J. Harvey, and L. Taylor Simpson. Prac-tical Improvements to the Construction and Destruction of Static Single Assign-ment Form. Software—Practice and Experience, 28(8):859–881, Jul 1998.

[65] Matthias Brun, Jero Delatour, and Yvon Trinquet. Code Generation from AADLto a Real-Time Operating System: An Experimentation Feedback on the Use ofModel Transformation. Engineering of Complex Computer Systems, IEEE Inter-

national Conference, pages 257–262, 2008.

[66] Jonas Carlsson, Kent Palmkvist, and Lars Wanhammar. Synchronous Design Flowfor Globally Asynchronous Locally Synchronous Systems.

[67] M. Y. Chkouri, A. Robert, M. Bozga, and J. Sifakis. Translating AADL into BIP -Application to the Verification of Real-Time Systems. In International Workshop

on Model Based Architecting and Construction of Embedded Systems (ACES’08),Toulouse, France, September 2008. Springer-Verlag.

210

http://www.irisa.fr/espresso/Polychrony

BIBLIOGRAPHY

[68] M. Y. Chkouri, A. Robert, M. Bozga, and J. Sifakis. Translating AADL into BIP- Application to the Verification of Real-Time Systems. Models in Software Engi-

neering: Workshops and Symposia at MODELS 2008, pages 5–19, 2009.

[69] J.-D. Choi, V. Sarkar, and E. Schonberg. Incremental computation of static singleassignment form. In Sixth International Conference on Compiler Construction,volume 1060 of Lecture Notes in Computer Science, pages 223–237, Apr 1996.

[70] Ron Cytron, Jeanne Ferrante, Barry K. Rosen, Mark N. Wegman, and F. KennethZadeck. Efficiently Computing Static Single Assignment Form and the ControlDependence Graph. ACM Transactions on Programming Languages and Systems,13(4):451–490, Oct 1991.

[71] M. Chapiro Daniel. Globally-Asynchronous Locally-Synchronous Systems. PhDthesis, Stanford University, October 1984.

[72] B. de Simone. The ESTEREL language. In Proceedings IEEE, 79-9, 1991.

[73] Julien Delange, Laurent Pautet, Alain Plantec, Mickael Kerboeuf, Frank Singhoff,and Fabrice Kordon. Validate, Simulate and Implement ARINC653 Systems us-ing the AADL. ACM SIGAda Ada Letters. Volume 29. Number 3, Pages 31-

44. ISSN:1094-3641. Also published in the proceedings of the international ACM

SIGAda conference, Tampa Bay, Florida, USA, November 2009.

[74] P. Dissaux, J.P. Bodeveix, M. Filali, P. Gaufillet, and F. Vernadat. AADL Behav-ioral annex, 2006.

[75] Frédéric Doucet, Massimiliano Menarini, Ingolf Kruger, Jean-Pierre Talpin, andRajesh Gupta. A verification approach for gals integration of synchronous com-ponents. In Proceedings of the International Workshop on Formal Methods for

Globally Asynchronous Locally Synchronous Design (FMGALS), Verona, Italy,July 2005.

[76] Bruce Powel Douglass. Doing Hard Time: Developing Real-Time Systems With

UML, Objects, Frameworks, And Patterns . Addison-Wesley Professional, May,1999.

[77] William R. Dunn. Designing Safety-Critical Computer Systems. Computer, 36:40–46, 2003.

[78] J. Eker, J. W. Janneck, E. A. Lee, J. Liu, J. Ludwig, S. Neuendorffer, S. Sachs, andY. Xiong. Taming heterogeneity: The Ptolemy approach. Proc. IEEE, 91(1):127–144, 2003.

[79] Mariusz A. Fecko, M. Ümit Uyar, Paul D. Amer, Adarshpal S. Sethi, Ted Dzik,Raymond Menell, and Mike Mcmahon. A Success Story of Formal Descrip-tion Techniques: Estelle Specification and Test Generation for MIL-STD 188-220,1999.

211

BIBLIOGRAPHY

[80] P.H. Feiler, D.P. Gluch, and J.J. Hudak. The Architecture Analysis & Design Lan-guage (aadl): An Introduction. Technical Note CMU/SEI-2006-TN-011, February2006.

[81] Ricardo Bedin Franca, Jean-Paul Bodeveix, Mamoun Filali, Jean-Francois Rolland,David Chemouil, and Dave Thomas. The AADL behaviour annex – experimentsand roadmap. In ICECCS ’07: Proceedings of the 12th IEEE International Con-

ference on Engineering Complex Computer Systems, pages 377–382, Washington,DC, USA, 2007. IEEE Computer Society.

[82] A. Gamatié, T. Gautier, and L. Besnard. Modeling of Avionics Applications andPerformance Evaluation Techniques using the Synchronous Language SIGNAL. InSLAP’03. Elsevier Science B.V., 2003.

[83] Abdoulaye Gamatié. Modélisation polychrone et évaluation de systèmes temps

réel. PhD thesis, IFSIC/IRISA, May 2004.

[84] Abdoulaye Gamatié and Thierry Gautier. Modeling of avionics applications andperformance evaluation techniques using the synchronous language Signal. In Pro-

ceedings of SLAP’03, volume 88 of ENTCS. Elsevier, 2003.

[85] Abdoulaye Gamatié and Thierry Gautier. Synchronous Modeling of Avionics Ap-plications using the SIGNAL Language. In RTAS ’03: Proceedings of the The 9th

IEEE Real-Time and Embedded Technology and Applications Symposium, page144, Washington, DC, USA, 2003. IEEE Computer Society.

[86] Abdoulaye Gamatié and Thierry Gautier. The SIGNAL Approach to the Designof System Architectures. Parallel and Distributed Systems, IEEE Transactions on,21:641–657, August 2009.

[87] Abdoulaye Gamatié, Thierry Gautier, and Paul Le Guernic. An Example of Syn-chronous Design of Embedded Real-Time Systems based on IMA. In 10th Inter-

national Conference on Real-time and Embedded Computing Systems and Appli-

cations (RTCSA’2004), Gothenburg, Sweden, August 2004.

[88] Abdoulaye Gamatié, Thierry Gautier, Paul Le Guernic, and Jean-Pierre Talpin.Polychronous design of embedded real-time applications. ACM Trans. Softw. Eng.

Methodol., 16(2):9, 2007.

[89] Gamatié, A. Designing Embedded Systems with the SIGNAL Programming Lan-

guage. Springer, 2009.

[90] Thierry Gautier, Paul Le Guernic, and Olivier Maffeïs. For a New Real-TimeMethodology. In IRISA PUBLICATION INTERNE NO. 870, 1994.

[91] N. Halbwachs and S. Baghdadi. Synchronous modeling of asynchronous systems.In EMSOFT’02, Grenoble, oct 2002. LNCS 2491, Springer Verlag.

[92] N. Halbwachs, P. Caspi, P. Raymond, and D. Pilaud. The synchronous dataflowprogramming language LUSTRE. In Proceedings of the IEEE, pages 1305–1320,1991.

212

BIBLIOGRAPHY

[93] Nicholas Halbwachs. Synchronous Programming of Reactive Systems. KluwerAcademic Publisher, 1993.

[94] Nicolas Halbwachs and Siwar Baghdadi. Synchronous Modelling of AsynchronousSystems. In EMSOFT ’02: Proceedings of the Second International Conference on

Embedded Software, pages 240–251. Springer-Verlag, 2002.

[95] Nicolas Halbwachs, Fabienne Lagnier, and Christophe Ratel. Programming andverifying real-time systems by means of the synchronous data-flow language LUS-TRE, 1994.

[96] Derek J. Hatley and Imtiaz A. Pirbhai. Strategies for real-time system specification.Dorset House Publishing Co., Inc., New York, NY, USA, 1987.

[97] Erwan Jahier, Nicolas Halbwachs, and Pascal. Raymond. Synchronous Modelingand Validation of Priority Inheritance Schedulers. In Fundamental Approaches to

Software Engineering Fundamental Approaches to Software Engineering, LectureNotes in Computer Science, pages 140–154, York Royaume-Uni, 2009. SpringerVerlag.

[98] Erwan Jahier, Nicolas Halbwachs, and Pascal Raymond. Synchronous modelingand validation of schedulers dealing with shared resources. Technical Report, Ver-imag, July 2008. http://www-verimag.imag.fr/Technical-Reports,264.html?lang=en&number=TR-2008-10.

[99] Erwan Jahier, Nicolas Halbwachs, Pascal Raymond, Xavier Nicollin, and DavidLesens. Virtual execution of aadl models via a translation into synchronous pro-grams. In EMSOFT ’07: Proceedings of the 7th ACM & IEEE international con-

ference on Embedded software, pages 134–143, New York, NY, USA, 2007. ACM.

[100] Erwan Jahier, Louis Mandel, Nicolas Halbwachs, and Pascal Raymond.The aadl2sync User Guide. Technical Report, Verimag, June 2007.http://www-verimag.imag.fr/DIST-TOOLS/SYNCHRONE/aadl2sync/

aadl2sync-man.pdf.

[101] Kenneth Johnson, Loïc Besnard, Thierry Gautier, and Jean-Pierre Talpin. A Syn-chronous Approach to Threaded Program Verification. Technical Report RR-7320,INRIA.

[102] G. Kahn. The semantics of a simple language for parallel programming. J. L.

Rosenfeld, pages 471–475, 1974.

[103] Alan Kaminsky. Real-Time Systems and Their Programming Languages. Com-

puter, 24:150–151, 1991.

[104] G. Karsai, J. Sztipanovits, A. Ledeczi, and T. Bapty. Model-Integrated Develop-ment of Embedded Software. In Proceedings of the IEEE, Vol. 91, No.1, pages145–164, January, 2003.

[105] John C. Knight. Safety Critical Systems: Challenges and Directions. In ICSE 2002,2002.

213

http://www-verimag.imag.fr/Technical-Reports,264.html?lang=en&number=TR-2008-10

http://www-verimag.imag.fr/Technical-Reports,264.html?lang=en&number=TR-2008-10

http://www-verimag.imag.fr/DIST-TOOLS/SYNCHRONE/aadl2sync/aadl2sync-man.pdf

http://www-verimag.imag.fr/DIST-TOOLS/SYNCHRONE/aadl2sync/aadl2sync-man.pdf

BIBLIOGRAPHY

[106] A. Kountouris and P. Le Guernic. Profiling of Signal Programs and its application inthe timing evaluation of design implementations. In Proceedings of the IEE Colloq.

on HW-SW Cosynthesis for Reconfigurable Systems, HP Labs, Bristol, UK, 1996.

[107] J.W. Krueger, S. Vestal, and B. Lewis. Fitting the pieces together: system/softwareanalysis and code integration using METAH. In Digital Avionics Systems Confer-

ence, 1998. Proceedings., 17th DASC. The AIAA/IEEE/SAE, Bellevue, WA , USA,November 1998.

[108] Phillip A. Laplante. Real-Time Systems Design and Analysis: An Engineer’s Hand-

book. IEEE Press, Piscataway, NJ, USA, 1992.

[109] O. Laurent and F. Pouzolz. Airbus generic pilot application Aircraft doors manage-ment system, May 2009.

[110] P. Le Guernic. SIGNAL: Description algébrique des flots de signaux. Architecture

des machines et systèmes informatiques, pages 243–252, November 1982.

[111] P. Le Guernic and A. Benveniste. Real-time, synchronous, data-flow programming:the language SIGNAL and its mathematical semantics. Technical Report TechnicalReport 533 (revised version: 620), INRIA, June 1986.

[112] P. Le Guernic and T. Gautier. Data-flow to von Neumann: the SIGNAL approach.Advanced Topics in Data-Flow Computing, pages 413–438, 1991.

[113] P. Le Guernic, T. Gautier, M. Le Borgne, and C. Le Maire. Programming real-timeapplications with Signal. In Proceeding of the IEEE, v.79, September 1997.

[114] Paul Le Guernic, Thierry Gautier, M. Le Borgne, and C. Le Maire. Programmingreal-time applications with SIGNAL. In Proceedings of the IEEE, pages 1321–1336, 1991.

[115] Paul Le Guernic, Jean-Pierre Talpin, and Jean-Christophe Le Lann. Polychrony forSystem Design. Journal for Circuits, Systems and Computers, 12:261–304, 2002.

[116] Gérard Le Lann. Distributed Systems - Towards A Formal Approach. pages 12–25.Information Processing 77, B.Gilchrist, Editor, North-Holland Publishing Com-pany, 1977.

[117] Edward A. Lee and Alberto Sangiovanni-Vincentelli. A Framework for Compar-ing Models of Computation. IEEE Transactions on Computer-Aided Design of

Integrated Circuits and Systems, 17:1217–1229, 1998.

[118] Insup Lee, Patrice Brémond-Grégoire, and Richard Gerber. A Process AlgebraicApproach to the Specification and Analysis of Resource-Bound Real-Time Sys-tems. In Proceedings of the IEEE, pages 158–171, 1994.

[119] Su-Young Lee, Frédéric Mallet, and Robert de Simone. Dealing with AADL End-to-End Flow Latency with UML MARTE. Engineering of Complex Computer Sys-

tems, IEEE International Conference, pages 228–233, 2008.

214

BIBLIOGRAPHY

[120] Kristina Lundqvist and Lars Asplund. A Formal Model of the Ada RavenscarTasking Profile. pages 12–25. Springer-Verlag, 1999.

[121] Yue Ma, Jean-Pierre Talpin, and Thierry Gautier. Virtual prototyping AADL archi-tectures in a polychronous model of computation. MEMOCODE08, 2008.

[122] Yue Ma, Jean-Pierre Talpin, and Thierry Gautier. Interpretation of AADL Behav-ior Annex into Synchronous Formalism Using SSA. Computer and Information

Technology, International Conference, pages 2361–2366, 2010.

[123] Yue Ma, Jean-Pierre Talpin, Sandeep K. Shukla, and Thierry Gautier. DistributedSimulation of AADL Specifications in a Polychronous Model of Computation. Em-

bedded Software and Systems, Second International Conference, pages 607–614,2009.

[124] Frédéric Mallet, Charles André, and Julien De Antoni. Executing AADL Modelswith UML/MARTE. In ICECCS ’09: Proceedings of the 2009 14th IEEE Interna-

tional Conference on Engineering of Complex Computer Systems, pages 371–376,Washington, DC, USA, 2009. IEEE Computer Society.

[125] H. Marchand, E. Rutten, M. Le Borgne, and M. Samaan. Formal Verification ofprograms specified with Signal: Application to a Power Transformer Station Con-troller. Science of Computer Programming, 41(1):85–104, August 2001.

[126] Hervé Marchand and Michel Le Borgne. Synthesis of discrete-event controllersbased on the Signal environment. In In Discrete Event Dynamic System: Theory

and Applications, pages 325–346, 2000.

[127] D. Mathaikutty, H. Patel, and S. Shukla. A Functional Programming Frameworkof Heterogeneous Model of Computation for System Design. In Forum on Specifi-

cation and Design Languages (FDL), 2004.

[128] Nenad Medvidovic and David S. Rosenblum. Domains of Concern in SoftwareArchitectures and Architecture Description Languages, 1997.

[129] Nenad Medvidovic and Richard N. Taylor. A Classification and ComparisonFramework for Software Architecture Description Languages. IEEE Transactions

on Software Engineering, 26:70–93, 2000.

[130] Steven P. Miller and Jan Duffy. FGS Partitioning Final Report. Research ReportNCC-01001, Rockwell Collins, Advanced Technology Center, 2004.

[131] Prabhat Mishra, Aviral Shrivastava, and Nikil Dutt. Architecture description lan-guage (ADL)-driven software toolkit generation for architectural exploration ofprogrammable SOCs. ACM Trans. Des. Autom. Electron. Syst., 11(3):626–658,2006.

[132] Daniel Monteverde, Alfredo Olivero, Sergio Yovine, and Victor Braberman. VTS-based Specification and Verification of Behavioral Properties of AADL Models. InInternational Workshop on Model Based Architecting and Construction of Embed-

ded Systems (ACES’08). Springer-Verlag, 2008.

215

BIBLIOGRAPHY

[133] Mohammadreza Mousavi, Paul Le Guernic, Jean-Pierre Talpin, Sandeep KumarShukla, and Twan Basten. Modeling and Validation of Globally Asynchronous De-sign in Synchronous Framework. In Digital Automation and Test Europe (Date’04),2003.

[134] Jens Muttersbach, Thomas Villiger, and Wolfgang Fichtner. Practical design ofglobally-asynchronous locally-synchronous systems. In Proc. International Sym-

posium on Advanced Research in Asynchronous Circuits and Systems, pages 52–59,2000.

[135] Martin Ouimet and Kristina Lundqvist. The Timed Abstract State Machine Lan-guage: An Executable Specification Language for Reactive Real-Time Systems.In Proceedings of the 15th International Conference on Real-Time and Network

Systems (RTNS ’07, 2007.

[136] Martin Ouimet and Kristina Lundqvist. The Timed Abstract State Machine Lan-guage: An Executable Specification Language for Reactive Real-Time Systems.In Proceedings of the 15th International Conference on Real-Time and Network

Systems (RTNS ’07, 2007.

[137] Lei Pi, J-P Bodeveix, and M. Filali. A comparative study of different for-malisms to define aadl data communication. www.cert.fr/feria/svf/FAC/2009/Papiers/11.pdf.

[138] Lei Pi, Jean-Paul Bodeveix, and Mamoun Filali. Modeling AADL Data Commu-nication with BIP. In Ada-Europe ’09: Proceedings of the 14th Ada-Europe In-

ternational Conference on Reliable Software Technologies, pages 192–206, Berlin,Heidelberg, 2009. Springer-Verlag.

[139] Lei Pi, Jean-Paul Bodeveix, and Mamoun Filali. Modeling AADL data communi-cation with BIP. In Ada-Europe’09, pages 192–206. Springer-Verlag, 2009.

[140] Lei Pi, Zhibin Yang, J-P Bodeveix, M. Filali, Kai Hu, and Dianfu Ma. A com-parative study of FIACRE and TASM to define AADL real time concepts. InICECCS’09, 2009.

[141] Mónica Pinto, Lidia Fuentes, and Jose María Troya. Daop-adl: an architecturedescription language for dynamic component and aspect-based development. InGPCE ’03: Proceedings of the 2nd international conference on Generative pro-

gramming and component engineering, pages 118–137, New York, NY, USA,2003. Springer-Verlag New York, Inc.

[142] Jan Rothe, Hendrik Tews, and Bart Jacobs. The Coalgebraic Class SpecificationLanguage CCSL. Journal of Universal Computer Science, 7:175–193, 2000.

[143] J. Rushby. Partitioning in Avionics Architectures: Requirements, Mechanisms,and Assurance. Research Report, NASA Langley Research Center, June 1999.

[144] I. Sander and A. Jantsch. System modeling and transformational design refinementin ForSyDe. IEEE Trans. Comput. Aided Design Integr. Circuits Syst., 23(1):17–32,2004.

216

www.cert.fr/feria/svf/FAC/2009/Papiers/11.pdf

www.cert.fr/feria/svf/FAC/2009/Papiers/11.pdf

BIBLIOGRAPHY

[145] Hauck Scott. Asynchronous Design Methodologies: An Overview. In PROCEED-

INGS OF THE IEEE, pages 69–93, 1995.

[146] Frank Singhoff and Alain Plantec. AADL modeling and analysis of hierarchicalschedulers. In ACM international conference on Ada (SIGAda’07), 2007.

[147] I. Smarandache. Transformations affines d’horloges: application au codesign de

systèmes temps réel en utilisant les langages Signal et Alpha. PhD thesis, Univer-site de Rennes 1, October 1998.

[148] Irina M. Smarandache, Thierry Gautier, and Paul Le Guernic. Validation of MixedSignal-Alpha Real-Time Systems through Affine Calculus on Clock Synchronisa-tion Constraints. In World Congress on Formal Methods (2), pages 1364–1383,1999.

[149] Oleg Sokolsky, Insup Lee, and Duncan Clark. Schedulability Analysis of AADLmodels. In 20th International Parallel and Distributed Processing Symposium,

IPDPS 2006, 2006.

[150] John A. Stankovic. Misconceptions About Real-Time Computing: A Serious Prob-lem for Next-Generation Systems. Computer, 21(10):10–19, 1988.

[151] John A. Stankovic. Strategic Directions in Real-Time and Embedded Systems.ACM Computing Surveys, 28(4):751–763, 1996.

[152] Jean-Pierre Talpin, Paul Le Guernic, Sandeep Kumar Shukla, Rajesh Gupta, andFrédéric Doucet. Polychrony for Formal Refinement-Checking in a System-LevelDesign Methodology, 2003.

[153] Jean-Pierre Talpin, Julien Ouy, Loïc Besnard, and Paul Le Guernic. Compositionaldesign of isochronous systems. In DATE ’08: Proceedings of the conference on

Design, automation and test in Europe, pages 928–933, New York, NY, USA, 2008.ACM.

[154] Jean-Pierre Talpin, Julien Ouy, Thierry Gautier, Loïc Besnard, and Cortier Alexan-dre. Modular interpretation of heterogeneous modeling diagrams into synchronousequations using static single assignment. Research Report RR-7036, INRIA, 2009.

[155] Andres Toom, Tonu Naks, Marc Pantel, Marcel Gandriau, and Indra Wati. Gene-Auto: An Automatic Code Generator for a Safe Subset of SimuLink/StateFlow andScicos. In European Conference on Embedded Real-Time Software (ERTS’08),2008.

[156] Kenneth J. Turner. Using Formal Description Techniques: An Introduction to Es-

telle, Lotos, and SDL. John Wiley & Sons, Inc., New York, NY, USA, 1993.

[157] Roberto Varona-Gomez and Eugenio Villar. AADL Simulation and PerformanceAnalysis in SystemC. Engineering of Complex Computer Systems, IEEE Interna-

tional Conference on, 0:323–328, 2009.

217

BIBLIOGRAPHY

[158] Steve Vestal and Jonathan Krueger. Technical and Historical Overview of MetaH.In Honeywell Technology Center, 2000.

[159] David Walker and Jack J. Dongarra. Mpi: A Standard Message Passing Interface.Supercomputer, 12:56–68, 1996.

[160] Paul T. Ward and Stephen J. Mellor. Structured Development for Real-Time Sys-

tems. Prentice Hall Professional Technical Reference, 1991.

[161] Mark N. Wegman and F. Kenneth Zadeck. Constant propagation with conditionalbranches. ACM Transactions on Programming Languages and Systems, 13(2):181–210, Apr 1991.

[162] Daniel Weil, Valérie Bertin, Etienne Closse, Michel Poize, Patrick Venier, andJacques Pulou. Efficient compilation of ESTEREL for real-time embedded sys-tems. In CASES ’00: Proceedings of the 2000 international conference on Compil-

ers, architecture, and synthesis for embedded systems, pages 2–8, New York, NY,USA, 2000. ACM.

[163] Doran K. Wilde. The ALPHA Language. Technical Report, IRISA-INRIA,Rennes, 1994. www.irisa.fr/bibli/publi/pi/1994/827/827.html.

[164] Zhibin Yang, Kai Hu, Dianfu Ma, and Lei Pi. Towards a formal semantics forthe AADL behavior annex. In Design, Automation and Test in Europe (DATE’09),pages 1166–1171, 2009.

[165] Zhibin Yang, Kai Hu, Dianfu Ma, and Lei Pi. Towards a Formal Semantics for theAADL Behavior Annex. In DATE’09, Toulouse, France, 2009, 2009.

[166] H.F. Yu, Y. Ma, Y. Glouche, J.-P. Talpin, L. Besnard, T. Gautier, P. Le Guernic,A. Toom, and O. Laurent. System-level Co-simulation of Integrated Avionics UsingPolychrony. the 26th ACM Symposium On Applied Computing, 2011.

218

www.irisa.fr/bibli/publi/pi/1994/827/827.html

Appendix A

SDSCS example

A.1 AADL specifications

system door_management

features

engine_running: in data port behavior::boolean;


on_ground: in data port behavior::boolean;

airspeed1: in data port behavior::float;



emerg_evac: in data port behavior::boolean;

slide_armed1_1: out data port behavior::boolean;




cll1: out data port behavior::boolean;


cll1_1: out data port behavior::boolean;




end door_management;

system implementation door_management.imp

subcomponents

door1: system Door.imp;

door2: system Door.imp;

dps1: device DPS;

dps2: device DPS;

ocu1: device OCU;

ocu2: device OCU;

doors_process1: process doors_process.imp;

doors_process2: process doors_process.imp;

cpiom1: processor CPIOM.imp;

cpiom2: processor CPIOM.imp;

rdc1: device RDC;

rdc2: device RDC;

afdx: bus AFDX.imp;

connections

APPENDIX A. SDSCS EXAMPLE

c1: data port engine_running -> doors_process1.engine_running;

c2: data port on_ground -> doors_process1.on_ground;

c3: data port in_flight -> doors_process1.in_flight;

c4: data port airspeed1 -> doors_process1.airspeed1;



c7: data port emerg_evac -> doors_process1.emerg_evac;

c8: data port engine_running -> doors_process2.engine_running;

c9: data port on_ground -> doors_process2.on_ground;

c10: data port in_flight -> doors_process2.in_flight;




c14: data port emerg_evac -> doors_process2.emerg_evac;

c15: data port doors_process1.cll -> ocu1.cll1;




c19: data port dps1.dps -> doors_process1.dps1;




c23: data port doors_process1.slide_armed1 -> slide_armed1_1;


c25: data port doors_process1.cll -> cll1;



c28: data port doors_process2.cll -> cll2;

c29: data port doors_process1.flight_lock1 -> door1.lock1;

c30: data port doors_process1.pres_warn1 -> door1.pressure_warn1;

c31: data port doors_process1.slide_warn1 -> door1.slide_warn1;




c35: data port door1.closed1 -> doors_process1.closed1_1;


c37: data port door1.ll1 -> doors_process1.ll1_1;



c40: data port door1.handle -> doors_process1.handle_pos1;
















220

A.1. AADL SPECIFICATIONS










c65: data port door1.slide_armed -> doors_process1.slide_armed_in1;




c69: bus access rdc1.door_iface -> door1.rdc;

c70: bus access rdc1.door_iface -> door2.rdc;

c71: data port doors_process1.cll1 -> cll1_1;




c75: bus access afdx -> rdc1.afdx_access;

c76: bus access afdx -> rdc2.afdx_access;

c77: bus access afdx -> cpiom1.afdx_access;

c78: bus access afdx -> cpiom2.afdx_access;

properties

Actual_Processor_Binding => reference cpiom1 applies to doors_process1;

Actual_Processor_Binding => reference cpiom2 applies to doors_process2;

Actual_Connection_Binding => reference afdx applies to c29;





























221













end door_management.imp;

system Door

features

handle: out data port behavior::boolean;

ll1: out data port behavior::boolean;



closed1: out data port behavior::boolean;

closed2: out data port behavior::boolean;

slide_armed: out data port behavior::boolean;

slide_warn1: in data port behavior::boolean;


pressure_warn1: in data port behavior::boolean;


lock1: in data port behavior::boolean;


rdc: requires bus access AFDX.imp;

end Door;

system implementation Door.imp

subcomponents

handle1: device Handle;

locklatched1: device LockLatched;



closedsensor1: device ClosedSensor;

closedsensor2: device ClosedSensor;

pressurewarn: device PressureWarn;

slidelight: device SlideLight;

flightlock: device FlightLock;

slidearmed: device SlideArmed;

connections

con1: data port handle1.handle -> handle;

con2: data port closedsensor1.closed -> closed1;

con3: data port closedsensor2.closed -> closed2;

con4: data port locklatched1.ll -> ll1;



con7: data port slide_warn1 -> slidelight.slide_warn1;

con8: data port slide_warn2 -> slidelight.slide_warn2;

con9: data port pressure_warn1 -> pressurewarn.pressure_warn1;

con10: data port pressure_warn2 -> pressurewarn.pressure_warn2;

con11: data port lock1 -> flightlock.lock1;

222


con12: data port lock2 -> flightlock.lock2;

con13: data port slidearmed.slide_armed -> slide_armed;

end Door.imp;

device FlightLock

features



end FlightLock;

device SlideLight

features



end SlideLight;

device Handle

features

handle: out data port behavior::boolean;

end Handle;

device LockLatched

features

ll: out data port behavior::boolean;

end LockLatched;

device ClosedSensor

features

closed: out data port behavior::boolean;

end ClosedSensor;

device PressureWarn

features



end PressureWarn;

device SlideArmed

features


end SlideArmed;

device DPS

features

dps: out data port behavior::boolean;

end DPS;

device OCU

features



end OCU;

processor CPIOM

features

223


afdx_access: requires bus access AFDX.imp;

end CPIOM;

processor implementation CPIOM.imp

end CPIOM.imp;

bus AFDX

end AFDX;

bus implementation AFDX.imp

end AFDX.imp;

device RDC

features

afdx_access: requires bus access AFDX.imp;

door_iface: provides bus access AFDX.imp;

end RDC;

process doors_process

features

flight_lock1: out data port behavior::boolean;

flight_lock2: out data port behavior::boolean;

pres_warn1: out data port behavior::boolean;

pres_warn2: out data port behavior::boolean;

slide_warn1: out data port behavior::boolean;

slide_warn2: out data port behavior::boolean;

closed1_1: in data port behavior::boolean;




ll1_1: in data port behavior::boolean;






handle_pos1: in data port behavior::boolean;

handle_pos2: in data port behavior::boolean;

slide_armed_in1: in data port behavior::boolean;

slide_armed_in2: in data port behavior::boolean;








dps1: in data port behavior::boolean;


slide_armed1: out data port behavior::boolean;

slide_armed2: out data port behavior::boolean;




end doors_process;

224


process implementation doors_process.imp

subcomponents



door_mix: thread doors_mix.imp;

connections

conn1: data port engine_running -> door_handler1.engine_running;

conn2: data port on_ground -> door_handler1.on_ground;


conn4: data port airspeed1 -> door_handler1.airspeed1;



conn7: data port emerg_evac -> door_handler1.emerg_evac;

conn8: data port dps1 -> door_handler1.dps1;


conn10: data port closed1_1 -> door_handler1.closed1;


conn12: data port ll1_1 -> door_handler1.ll1;



conn15: data port handle_pos1 -> door_handler1.handle_pos;

conn16: data port door_handler1.slide_armed -> slide_armed1;

conn17: data port door_handler1.slide_warn -> slide_warn1;

conn18: data port door_handler1.flight_lock -> flight_lock1;

conn19: data port door_handler1.pres_warn -> pres_warn1;

conn20: data port door_handler1.cll -> door_mix.cll1;

conn21: data port engine_running -> door_handler2.engine_running;

conn22: data port on_ground -> door_handler2.on_ground;





conn27: data port emerg_evac -> door_handler2.emerg_evac;








conn35: data port handle_pos2 -> door_handler2.handle_pos;

conn36: data port door_handler2.slide_armed -> slide_armed2;

conn37: data port door_handler2.slide_warn -> slide_warn2;

conn38: data port door_handler2.flight_lock -> flight_lock2;

conn39: data port door_handler2.pres_warn -> pres_warn2;

conn40: data port door_handler2.cll -> door_mix.cll2;

conn41: data port door_mix.cll -> cll;

conn42: data port slide_armed_in1 -> door_handler1.slide_armed_in;

conn43: data port slide_armed_in2 -> door_handler2.slide_armed_in;

conn44: data port door_handler1.cll -> cll1;

conn45: data port door_handler2.cll -> cll2;

end doors_process.imp;

thread door_handler

225


features

handle_pos: in data port behavior::boolean;

ll1: in data port behavior::boolean;



closed1: in data port behavior::boolean;

closed2: in data port behavior::boolean;










slide_armed_in: in data port behavior::boolean;



slide_warn: out data port behavior::boolean;

flight_lock: out data port behavior::boolean;

pres_warn: out data port behavior::boolean;

end door_handler;

thread implementation door_handler.imp

properties


Period => 50 Ms;

end door_handler.imp;

thread doors_mix

features




end doors_mix;

thread implementation doors_mix.imp

properties


Period => 50 Ms;

end doors_mix.imp;

A.2 Signal specifications

Model door_handler thread in Signal

process ThreadT_door_handler =

(? event dispatch, deadline,scomplete, start;

boolean handle_pos,ll1,ll2,ll3,closed1,closed2,

in_flight,on_ground,engine_running;

dreal airspeed1,airspeed2,airspeed3;

boolean emerg_evac,dps1,dps2,slide_armed_in;

! boolean slide_armed,cll,slide_warn,flight_lock,pres_warn;)

226

A.2. SIGNAL SPECIFICATIONS

(|(l_slide_armed, l_cll, l_slide_warn, l_flight_lock, l_pres_warn)

:= SPT_door_handler{}(dispatch, deadline, scomplete, start, handle_pos,

ll1, ll2, ll3, closed1,closed2, in_flight, on_ground, engine_running,

airspeed1, airspeed2, airspeed3,emerg_evac, dps1, dps2, slide_armed_in)

| slide_armed := at{}(l_slide_armed,scomplete)

| cll := at{}(l_cll,scomplete)

| slide_warn := at{}(l_slide_warn,scomplete)

| flight_lock := at{}(l_flight_lock,scomplete)

| pres_warn := at{}(l_pres_warn,scomplete)

|)

where ...

end;

process SPT_door_handler =

( ? event dispatch, deadline,scomplete,start;

boolean handle_pos,ll1,ll2, ll3,closed1,closed2,

in_flight, on_ground,engine_running;

dreal airspeed1, airspeed2,airspeed3;

boolean emerg_evac,dps1,dps2,slide_armed_in;

! boolean slide_armed,cll,slide_warn,flight_lock,pres_warn;)

(| l_handle_pos := at{}(handle_pos,start)

| l_ll1 := at{}(ll1,start)



| l_closed1 := at{}(closed1,start)

| l_closed2 := at{}(closed2,start)

| l_in_flight := at{}(in_flight,start)

| l_on_ground := at{}(on_ground,start)

| l_engine_running := at{}(engine_running,start)

| l_airspeed1 := at{}(airspeed1,start)

| l_airspeed) := at{}(airspeed2,start)

| l_airspeed3 := at{}(airspeed3,start)

| l_emerg_evac := at{}(emerg_evac,start)

| l_dps1 := at{}(dps1,start)

| l_dps2 := at{}(dps2,start)

| l_slide_armed_in := at{}(slide_armed_in,start)

| (slide_armed, cll, slide_warn, flight_lock, pres_warn) := SP_door_handler{}

(l_handle_pos, l_ll1, l_ll2, l_ll3, l_closed1, l_closed2, l_in_flight,

l_on_ground, l_engine_running, l_airspeed1, l_airspeed2, l_airspeed3,

l_emerg_evac, l_dps1, l_dps2, l_slide_armed_in)

|)

where ...

end;

process SP_door_handler =

( ? boolean handle_pos, ll1,ll2, ll3, closed1, closed2,

in_flight, on_ground, engine_running;

dreal airspeed1, airspeed2, airspeed3;

boolean emerg_evac, dps1, dps2, slide_armed_in;

! boolean slide_armed, cll, slide_warn, flight_lock, pres_warn; )

(| ...|) ;

Model doors_mix thread in Signal

process ThreadT_doors_mix =

227


( ? event dispatch,deadline,scomplete,start;

boolean cll1,cll2;

! boolean cll;)

(| l_cll := SPT_doors_mix{}(dispatch,deadline, scomplete,start, cll1, cll2)

| cll := at{}(l_cll,scomplete)

|);

process SPT_doors_mix =

( ? event dispatch,deadline,scomplete,start;

boolean cll1,boolean cll2;

! boolean cll;)

(| l_cll1 := at{}(cll1,start)

| l_cll2 := at{}(cll2,start)

| cll:= SP_doors_mix{}(l_cll1,l_cll2)

|)

where ...

end;

process SP_doors_mix =

( ? boolean cll1, boolean cll2;

! boolean cll;)

(|cll := doors_process_nb1_ii(cll1,cll2)

|) ;

A simple partition scheduler modelprocess partition_scheduler =

(? event tick, ptick;

! event dispatch_1, dispatch_2, dispatch_3, start_handler_1_1,

start_handler_1_2,start_mix_1, complete_handler_1_1,

complete_handler_1_2, complete_mix_1, deadline_handler_1_1,

deadline_handler_1_2, deadline_mix_1;)

(| cnt := 1 when ptick when tick default pre_cnt + 1

| pre_cnt := cnt $ 1 init 0

| tick ^= cnt ^= pre_cnt

| dispatch_1 := when ( cnt = 2 )

| start_handler_1_1 := when ( cnt = 3 )

| complete_handler_1_1 := when ( cnt = 4 )

| deadline_handler_1_1 := when ( cnt = 5 )


| start_handler_1_2 := when ( cnt = 7 )

| complete_handler_1_2 := when ( cnt = 8 )

| deadline_handler_1_2 := when ( cnt = 9 )


| start_mix_1 := when ( cnt = 11 )

| complete_mix_1 := when ( cnt = 12 )

| deadline_mix_1 := when ( cnt = 13 )

|)

where integer cnt, pre_cnt;

end;

228

Appendix B

FGS example

B.1 AADL specifications

system DFGSsys

features

transfer: in event data port behavior::boolean;

L_inde_mode: in event data port behavior::boolean;

R_inde_mode: in event data port behavior::boolean;

Lactive: out event data port behavior::boolean;

Ractive: out event data port behavior::boolean;

end DFGSsys;

system implementation DFGSsys.impl

subcomponents

cpu1: processor CPU.impl;

LFGS: process FGS.impl;

cpu2: processor CPU.impl;

RFGS: process FGS.impl;

bus1: bus net.impl;

bus2: bus net.impl;

connections

c1: event data port transfer -> LFGS.transfer;

c2: event data port transfer -> RFGS.transfer;

c3: event data port L_inde_mode -> LFGS.inde_mode;

c4: event data port R_inde_mode -> RFGS.inde_mode;

c5: event data port LFGS.pactive -> Lactive;

c6: event data port RFGS.pactive -> Ractive;

c7: event data port LFGS.pilot_flying -> RFGS.other_pilot_flying;

c8: event data port LFGS.independent -> RFGS.other_independent;

c9: event data port RFGS.pilot_flying -> LFGS.other_pilot_flying;

c10:event data port RFGS.independent -> LFGS.other_independent;

properties

Actual_Processor_Binding => reference cpu1 applies to LFGS;

Actual_Processor_Binding => reference cpu2 applies to RFGS;

Actual_Connection_Binding => reference bus1 applies to c7;




end DFGSsys.impl;

APPENDIX B. FGS EXAMPLE

processor CPU

end CPU;

processor implementation CPU.impl

end CPU.impl;

bus net

end net;

bus implementation net.impl

end net.impl;

process FGS

features

transfer: in event data port behavior::boolean;


other_pilot_flying: in event data port behavior::boolean;

other_independent: in event data port behavior::boolean;

pilot_flying: out event data port behavior::boolean;

independent: out event data port behavior::boolean;

pactive: out event data port behavior::boolean;

end FGS;

process implementation FGS.impl

subcomponents

tFGS: thread FGS_thread.impl;

connections

c11: event data port transfer -> tFGS.ts;

c12: event data port inde_mode -> tFGS.inde_mode;

c13: event data port other_pilot_flying -> tFGS.other_pf;

c14: event data port other_independent -> tFGS.other_inde;

c15: event data port pilot_flying -> tFGS.pf;

c16: event data port independent -> tFGS.tindependent;

c17: event data port pactive -> tFGS.tactive;

end FGS.impl;

thread FGS_thread

features

ts: in event data port behavior::boolean;


other_pf: in event data port behavior::boolean;

other_inde: in event data port behavior::boolean;

pf: out event data port behavior::boolean;

tindependent: out event data port behavior::boolean;

tactive: out event data port behavior::boolean;

properties

Period => 100 Ms;

end FGS_thread;

thread implementation FGS_thread.impl


states

primary: state;

backup: state;

transitions

230

B.2. SIGNAL SPECIFICATIONS

primary -[other_pf?(true) ]-> backup { pf!(false);};

backup -[ts?]-> primary { pf!(true); tactive!(true);};

**};

end FGS_thread.impl;

B.2 Signal specifications

process DFGS =

(? boolean Transfer, R_inde_mode, L_inde_mode;

! boolean Ractive, Lactive, RPF, LPF, LIndependent, RIndependent;)

(| (LIndependent,LPF,Lactive) := PART_cpu1{true,false}

(Transfer,ORPF,ORI,L_inde_mode)

| (RIndependent,RPF,Ractive) := PART_cpu2{false,true}

(Transfer,OLPF,OLI,R_inde_mode)

| OLI := bus1{false}(LIndependent)

| OLPF := bus1{true}(LPF)

| ORI := bus2{true}(RIndependent)

| ORPF := bus2{false}(RPF)

|)

where

use SIGALI;

boolean ZTS,OLI,ORI,OLPF,ORPF;

process PART_cpu1 = {boolean Ini_PF;boolean Ini_OPF;}

(? boolean Transfer,Other_PF,Other_Independent,Inde_mode;


(| ZPF := PF$ init Ini_PF

| ZOPF := Other_PF$ init Ini_OPF

| FC := Transfer and (not ZPF)



default ZPF

| Independent := Inde_mode

| Active := PF or (Other_Independent and Inde_mode)

|)

where


end;

process PART_cpu2 = {boolean Ini_PF;boolean Ini_OPF;}

(? boolean Transfer,Other_PF,Other_Independent,Inde_mode;







default ZPF



|)

where


end;

231

APPENDIX B. FGS EXAMPLE

process bus1 = {boolean IniS;}

(? boolean S; ! boolean DS;)

(| DS := S$1 init IniS |)

process bus2 = {boolean IniS;}

(? boolean S; ! boolean DS;)

(| DS := S$1 init IniS |)

end;

end;

process ThreadT_tFGS = {boolean Ini_PF;boolean Ini_OPF;}

( ? boolean Transfer,Other_PF,Other_Independent,Inde_mode;







default ZPF



|)

where


end;

232

Modélisation compositionnelle d’architectures globalement asynchrones - localementsynchrones (GALS) dans un modèle de calcul polychrone

AADL est dédié à la conception de haut niveau et l’évaluation de systèmes embarqués. Il permet de décrirela structure d’un système et ses aspects fonctionnels par une approche à base de composants. Des pro-cessus localement synchrones sont alloués sur une architecture distribuée et communiquent de manièreglobalement asynchrone (système GALS). Une spécificité du modèle polychrone est qu’il permet de spéci-fier un système dont les composants peuvent avoir leur propre horloge d’activation : il est bien adapté à uneméthodologie de conception GALS. Dans ce cadre, l’atelier Polychrony fournit des modèles et des méth-odes pour la modélisation, la transformation et la validation de systèmes embarqués. Cette thèse proposeune méthodologie pour la modélisation et la validation de systèmes embarqués spécifiés en AADL via lelangage synchrone multi-horloge Signal. Cette méthodologie comprend la modélisation de niveau systèmeen AADL, des transformations automatiques du modèle AADL vers le modèle polychrone, la distribution decode, la vérification formelle et la simulation du modèle polychrone. Notre transformation prend en comptel’architecture du système, décrite dans un cadre IMA, et les aspects fonctionnels, les composants logicielspouvant être mis en œuvre en Signal. Les composants AADL sont modélisés dans le modèle polychroneen utilisant une bibliothèque de services ARINC. L’annexe comportementale d’AADL est interprétée dansce modèle via SSA. La génération de code distribué est obtenue avec Polychrony. La vérification formelleet la simulation sont effectuées sur deux études de cas qui illustrent notre méthodologie pour la conceptionfiable des applications AADL.

Mots clefs: AADL, Signal, GALS, IMA, ARINC, modèle polychrone, modèle synchrone, simulation,

vérification.

Compositional modeling of globally asynchronous locally synchronous (GALS)architectures in a polychronous model of computation

AADL is dedicated to high-level design and evaluation of embedded systems. It allows describing bothsystem structure and functional aspects via a component-based approach, e.g., GALS system. The poly-chronous model of computation stands out from other synchronous specification models by the fact that itallows one specifying a system whose components can have their own activation clocks. It is well adapted tosupport a GALS design methodology. Its framework Polychrony provides models and methods for model-ing, transformation and validation of embedded systems. This thesis proposes a methodology for modelingand validation of embedded systems specified in AADL via the multi-clock synchronous programming lan-guage Signal. This methodology includes system-level modeling via AADL, automatic transformationsfrom the high-level AADL model to the polychronous model, code distribution, formal verification andsimulation of the obtained polychronous model. Our transformation takes into account both the systemarchitecture, particularly described in Integrated Modular Avionics (IMA), and functional aspects, e.g.,software components implemented in the polychronous language Signal. AADL components are modeledinto the polychronous MoC within the IMA architecture using a library of ARINC services. The AADLBehavior Annex is interpreted into the multi-clocked MoC using SSA as an intermediate formalism. Dis-tributed code generation is obtained with Polychrony. Formal verification and simulation are carried out ontwo case studies that illustrate our methodology for the reliable design of AADL applications.

Keywords: AADL, Signal, GALS, IMA, ARINC, polychronous model, synchronous model, simulation,

verification.

Documents

Compositional modeling of globally asynchronous … · Compositional modeling of globally asynchronous ... globally asynchronous locally synchronous (GALS) architectures ... Case