modélisation des systèmes Émbarqueslipari/courses/semba/print-final-07.pdf · contraintes sur le...

Modélisation des Systèmes Émbarques

Giuseppe Lipari

LIFL - Université de Lille 1

4 octobre 2015

Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 1 / 42

Résumé

Systèmes embarqués

Qu’est-ce que c’est un modèle ?

Langages de modélisation

Analyse des réquisits


Crédits

Ces diapositives sont en part l’élaboration :

des diapositives du cours "Embedded Systems Design" par Marco DiNatale à la Superiore Sant’Anna (http://retis.sssup.it/~marco/teaching/embeddedsystems/)

des diapositives de Pierre Boulet pour le cours SEMBA de l’annéedernière


Système Embarqué : définition

Des "Wikipedia" :

An embedded system is a special-purpose computer system

designed to perform one or a few dedicated functions, sometimes

with real-time computing constraints. It is usually embedded as part

of a complete device including hardware and mechanical parts. In

contrast, a general-purpose computer, such as a personal computer,

can do many different tasks depending on programming.

Since the embedded system is dedicated to specific tasks, design

engineers can optimize it, reducing the size and cost of the product,

or increasing the reliability and performance.


Caractéristiques

Embedded - Dedicated

Interaction avec des processus physiquescapteurs, actionneurs← contraintes temporelles (latency, jitters)

Réactivitéil faut opérer à la même vitesse que l’environnement

Des propriétés fonctionnelles et non-fonctionnellesreal-time, fault recovery, power, security, robustness,

Hétérogénéitéhardware/software tradeoffs

Concurrenceinteraction avec plusieurs processus

Contraintes sur le ressourcesÀ cause du coût, de l’énergie, de l’espace


Caractéristiques

Il y a des différences entre le développement logiciel traditionnel, et ledéveloppement d’un système embarqué

Le développement logiciel traditionnelil se concentre sur la fonctionnalitéil oublié complètement le matérielexemple : développement d’un logiciel webil est best effort, le temps n’est pas important

Le développement des systèmes embarquésil comprend le choix du matérielil doit tenir en compte l’interaction avec l’environnement (contraintes tempsréel)il doit tenir en compte les autres contraintes non-fonctionnelles(fault-tolerance, energy, etc.)


Les systèmes temps réel

En informatique temps réel, le comportement correct d’un système

dépend, non seulement des résultats logiques des traitements, mais

aussi du temps auquel les résultats sont produits

{John Stankovic. « Misconceptions about real-time computing ». IEEE Computer,

October 1988}

Système prédictible : on cherche à déterminer a priori si le système varépondre aux exigences temporelles.

Un système temps réel n’est pas un système "qui va vite" mais unsystème qui satisfait à des contraintes temporelles


Modèle

Un modèle est une représentation abstrait d’un système qui nous

permit de répondre à des questions sur le système.

Les modèles sont utiles quand on a des systèmes trop grands, ou

trop petits, ou trop compliqués, ou qui n’existe plus, ou à construire

de : "Object Oriented Software Engineering, using UML Patterns and Java", Bernd Bruegge, Allen H. Dutoit


Pourquoi un modèle du système ?

La modélisation est un activités fondamental dans le Science, et il estpartie du méthode scientifique

Faire un modèle abstrait d’un système réel est utile pourétudier les lois à la base du phénomène en essayant sur letester des hypothèses sur le modèle

Faire un modèle d’un système imaginaire est aussi très utile :il s’agit d’essayer le fonctionnement du système avant de le construireon peut prévoir le résultat finale en analysant le modèleon peut facilement changer des choses qui ne vont pas

L’abstraction permet d’ignorer les détails non essentiels


Abstraction

Deux définitions :

L’abstraction est un processus de pensée dans lequel l’idée s’éloigne desobjets

Abstraction comme activité

L’abstraction est l’idée résultant d’un processus de pensée dans lequell’idée s’est éloignée d’un objet

Abstraction en tant qu’entité


Modèles dans l’ancienneté

Competition between architects was an old and honoured custom. Patrons

had been making architects compete against another for their commissions

since at least 448 B.C. [. . . ] Under these circumstances, it was normal

practice for architects to produce models as a means of convincing patrons

or panel judges of the virtues of their particular design.

{From Brunelleschi’s Dome : how a renaissance genius reinvented architecture, by Ross King}


Modèles dans l’ancienneté


Comment construire un modèle ?

Un modèle n’est pas une petite copie exact du système finale

Normalement, beaucoup de détails sont caché (Abstraction)Si le système finale est très compliqué, il faut d’abord construire un modèleplus simple qui capture que les aspects d’intérêtÀ fur et à mesure que on progressait dans la compréhension du modèle,on peut ajouter de détails (Raffinement)


Un seul modèle, ou plusieurs ?

On peut penser de construire plusieurs modèles pour un système

à différentes niveau d’abstraction et de complexitépar exemple, un boiler pour réchauffer l’eau peut être représente par unsimple finite state machine (on/off) ou par un ensemble d’équationsdifférentiels

ou, chaque modèle peut décrire un aspect diffèrent du systèmeDans un avion, un modèle décris le sub-système de guide, un autremodèle décrit le système Audio/Vidéo de divertissement

Dans le deuxième cas, il s’agit de deux sous-systèmes différentes etindépendantes, donc il peut être utile de séparer les deux modèles

sauf que on peux avoir de l’interférence électromagnétique entre le deuxsystèmes. . .

Dans le premier cas, il s’agit de deux descriptions du même système, ilest nécessaire garantir que il sont consistent

comme règle général, il est mieux d’avoir un seul modèle pour un mêmesystème, et appliquer de transformations pour raffiner/abstraire le modèle


Méthodologie de conception et développement d’un logiciel

The V-model


Le V-Model

Le V-Model est une méthodologie de conception et de développementd’un système

les phasesUser RequirementsFunctional SpecificationFunctional ModelingArchitecture ExplorationComponent ModelingBehaviour ModelingCodingModule TestingIntegration TestingSystem VerificationValidation


Le V-Model

Il s’agit d’un méthodologie à cascade ou il y à un correspondance entreles premières phases et les dernières


Modèle

À chaque phase, il faut construire un modèle qui décrit le système finale

Le premier modèle (User Requirements) doit forcement être très abstrait

À fur et a mesure qu’on progresse dans le phases, le modèle devient plusconcret (raffinement)

Le logiciel finale qui nous allons développer peut être considéré aussicomme un modèle très détaillé de notre système

il s’agit de une abstraction exécutable

Donc la méthodologie de développement peut être considéré comme unetransformation entre modèles


Model-based design

Quatre concepts importantes

Test and Verification,Simulation, Validation

Automatic code generation,porquoi ?

Le langage est très important


UML (Unified Modeling Language)

Modeling language for Object Oriented Design

Convergence of notations used in object-oriented methodsOMT (James Rumbaugh and collegues)Booch (Grady Booch)OOSE (Ivar Jacobson)Current Version : UML 2.5Information at the OMG portal http://www.uml.org/

Commercial tools : Rational – RSA (IBM),Together (Borland), VisualArchitect (business processes, BCD)

Open Source tools : ArgoUML, Omondo, Papyrus


UML diagrams

Use case diagramsDescribe the functional behavior of the system as seen by the user

Class diagramsDescribe the static structure of the system : Objects, attributes,associations

Sequence diagramsDescribe the dynamic behavior between objects of the system

Statechart diagramsDescribe the dynamic behavior of an individual object

Activity diagramsDescribe the dynamic behavior of a system, in particular the workflow.


Class diagrams

Class diagrams represent the structure of the system

Classes represent types of objects, linked by relationships

Probably the most important UML diagram


Class diagrams


Sequence diagrams

Sequence diagrams represent the behavior of a system as messages(“interactions”) between different objects


Activity Diagrams

Represent an interesting behavior of the system


Other diagrams

UML 2 has many other diagramsStructural : Profile diagrams, Deployment diagrams, Package diagrams, . . .Behavioral : Timing diagram, Interaction Overview diagram, . . .UML 2 is also extensible, thanks to profiles

it is possible to describe the semantic of new concepts and diagrams directlyin UML 2 using the concept of stereotypes

Therefore, UML can be used as a Domain Specific Language (DSL)


UML profiles

In a profile, it is possible to define stereotypesa stereotype is a new concept that can later be applied to elements of UML

Example :Suppose you want to create a special type of class that represents activethreads ;it is like a regular class, but it always contains a property called active oftype booleanthen, we define a stereotype ActiveClass that extends the metaclassClass of UML2, and contains a boolean property called activeLater, users of this profile can label some of their UML classes with thestereotype ActiveClass.


UML profiles

To create your own profile is useful if you need to specialise some of theUML concept for your own domain, giving them a more precise semantic

In particular, instead of having only the generic concept of class torepresent everything, we can define the concept of OS, Thread,Semaphore, etc. for the domain of real-time programming

Somebody has already worked in this direction, and proposed MARTE


MARTE

MARTE = UML profile for Modeling and Analysis of Real-Time and Embeddedsystems

The goal is to be able to design and analyse real-time systems

It introduces the concepts of time, clock, thread, service, priority etc. thatallow to model the platform specific aspect of a software

It is now implemented in Eclipe Papyrus (but no analysis tool)


SysML

SysML was born as a separate language to describe both software aswell as the hardware and the physical environment

Later there has been a convergence among SysML and UML, howeversome of the concept of SysML are not part of UML2

Therefore, strictly speaking, SysML is not a profile of UML

however, some modeling tool treatSysML as a separate language

some tool, like Papyrus, treatSysML as an extension of UML2


V-model


Réquisits

Explique le problème, pas la solution

D’accord avec les clients

Écrit en langage naturel (français, anglais)

Malheureusement, le langage naturel est imprécis

Il faudra être plus précis en utilisant des langages formellesFSM, Z language, LTL, CTL . . .

Quand on passe du langage naturel à un langage formel, on est dans laphase de Specification


Analyse des réquisits

On peut utiliser plusieurs techniques pour guider la collecte et l’analysede réquisits, et pour organiser les réquisits

Les objectives sontClartéIntégralité et exhaustivitéPas d’ambiguïté, pas d’inconsistance, pas de redondance

On peut partir de :les états du systèmele modèle des donnée gérées par le systèmeles cas d’utilisation du système et les acteursles activités du système, ou ses réactions, ou les événements typiqueetc.


Analyse des réquisits II

Des besoins en conflit :il faut communiquer avec des personnes qui ne sont pas des techniciens,utilisant le langage naturelil faut être précis dans la spécification du système pour éviter desambiguïtés et des inconsistances

Les réquisits peuvent changer pendant le développement du systèmeraffinement par itération

Les document des réquisits est un document toujours vivante, pendanttoute la durée du projet


modélisation des systèmes Émbarqueslipari/courses/semba/print-final-07.pdf · contraintes sur le...

Documents