Description et analyse d’architectures d’applications ...homepages.laas.fr/francois/STRQDS/reunions/160103/clara.pdf · d’applications temps réel - Le projet REACT Sebastien´

Description et analyse d’architecturesd’applications temps réel - Le projet REACT

Sebastien FAUCOU, Anne-Marie DEPLANCHE et Yvon TRINQUET

[email protected]

Institut de Recherche en Communications et Cybernetique de Nantes

Equipe « Systemes Temps Reel »

UMR no 6597 - CNRS / Ecole Centrale de Nantes, Universite de Nantes, Ecole des

Mines de Nantes

GDR ARP - Groupe StrQds - Journee ADL - 16/01/2003 – p.1/34

Plan de la présentation

1. Conception centree architecture

2. Application aux systèmes temps réel

3. Conclusions et perspectives


Introduction

Début 90’s : mise en évidence du rôle de l’architecture logicielle sur lecomportement et la qualité d’une application [GS94]

Soulève des questions :

I Comment comparer deux architectures ?

I Comment evaluer une architecture ?

I Comment decrire une architecture ? (et Quoi décrire ?)


Éléments de réponse

Quoi décrire :

I Niveau de conception abstrait : considère les entites quiconstituent le système et leurs interactions (programmation« gros grain » par rapport à la programmation « classique »)

Comment décrire :

I Évaluation ⇒ manipuler les architectures ⇒ description(semi-)formelle ⇒ définition de langages adaptés : ArchitectureDescription Language (ADL)

L’utilité d’un ADL est fonction des outils (d’analyse) qui lui sontassociés


Principes de base des ADL

Composant : entité (active ou inactive) du système. Visible /manipulable uniquement via son interface (séparation traitement/ interface)

Connecteur : permet de specifier les interactions entre lescomposants

Configuration : décrit l’interconnexion de composants via desconnecteurs pour réaliser une fonctionnalité

La description de l’architecture d’une application est constituée d’uneou plusieurs configurations


Exemple

SYS_EXEMPLE1

ACT2

ACT3

H1

ACT1

fromBAL

toBAL

data_out

data_in2

data_in1 toBAL

wake_ACT2

START

END

START

END

START

END do3

di2

di1

|

2


Exemple

des composants

SYS_EXEMPLE1

ACT2

ACT3

H1

ACT1

fromBAL

toBAL

data_out

data_in2

data_in1 toBAL

wake_ACT2

START

END

START

END

START

END do3

di2

di1

|

2


Exemple

dotés d’interfacesdes composants

SYS_EXEMPLE1

ACT2

ACT3

H1

ACT1

fromBAL

toBAL

data_out

data_in2

data_in1 toBAL

wake_ACT2

START

END

START

END

START

END do3

di2

di1

|

2


Exemple

interagissent via des connecteursdotés d’interfacesdes composants

SYS_EXEMPLE1

ACT2

ACT3

H1

ACT1

fromBAL

toBAL

data_out

data_in2

data_in1 toBAL

wake_ACT2

START

END

START

END

START

END do3

di2

di1

|

2


Exemple

au sein d’une configuration

interagissent via des connecteursdotés d’interfacesdes composants

SYS_EXEMPLE1

ACT2

ACT3

H1

ACT1

fromBAL

toBAL

data_out

data_in2

data_in1 toBAL

wake_ACT2

START

END

START

END

START

END do3

di2

di1

|

2


Caractéristiques

La plupart des ADL partagent des caractéristiques ([MT00]) :

I syntaxe textuelle et graphique

I semantique (semi)-formelle

I capacités d’analyse au niveau architectural (performances, sdf,simulation, vérification, etc.)

I approche hiérarchique (composant de composant)

I approche objet

Mais sont différents dans leurs objectifs, leurs portées, etc.


Conception centrée sur l’architecture logicielle

Besoins

Implémentations

Besoins

Implémentations

peut marchertout ce qui

Besoins

Implémentations

méthodes deconception

ArchitectureLogicielle

Niveau architectural au premier plan dans la conception


Avantages

Cette approche est reconnue pour apporter un certain nombred’avantages :

I meilleure conception : réutilisabilité, flexibilité, etc. (séparationdes pb, vue globale)

I validation de la conception tôt dans le processus dedéveloppement

I facilite le developpement : composants indépendants

I facilite la maintenance : documentation, traçabilité, évolution



1. Conception centrée architecture

2. Application aux systemes temps reel



Spécificités

Du point de vue description :

I expression des contraintes de temps

I description des modes de fonctionnement (et des commutations)

I aspects reactifs : interface du système et liaisons système -procédé, conditions d’activation des traitements

Du point de vue analyse, prise en compte de la criticité :

I validation temporelle

I sûreté de fonctionnement


ADL et systèmes temps réel

Il existe aujourd’hui différents projets (achevés ou en cours) basés surl’approche ADL pour les systèmes temps réel :

Nom Maitre d’œuvre Domaine Analyseoperationnelle

Référence

Basement Consortium suédois automobile analyse d’ordonnan-

çabilité, simulation

[HLS+96]

MetaH/AADL Honeywell (+ SAE) avionique analyse d’ordon-

nançabilité, model-

checking

[BV01]

REACT IRCCyN contrôle de procédé simulation, model-

checking

[FAU02]

COTRE projet RNTL (Féria) logiciels temps réel

AEE/AIL Groupe AEE automobile couplage outils in-

dustriels et acadé-

miques

[ES02]


Le projet REACT

REACT = REal-time Application Configuration Tool

But : proposer un atelier logiciel d’aide a la conception dessystemes temps reel complexes

Systèmes visés :

I contrôle de procédé

I implementation logicielle

I approche asynchrone (utilisation d’un exécutif)

Approche suivie : conception centrée sur la notion d’architectureoperationnelle


Approche suivie par REACT

Architecture opérationnelle

Architecture logicielle Architecture support

− définition des types (activités, variables, etc.)

vue structurelle

− description de l’environnement− liens d’activation et d’interface

vue réactive

CLARA

− liens d’interaction

Architecture logicielle

vue composant

− protocole de com. de niveau application− middleware CLARA

− topologie du systèmesupport matériel d’exécution

Architecture support

− exécutif temps réel généralistesupport logiciel d’exécution

− descripttion des noeuds

Architecture opérationnelle

vue implémentation− tâches, variables, messages

1

2 − configuration des supports

vue système− squelettes d’applications

− description du placement

3

analysetemporelle de l’AO

modèles de comportement des activités

contraintes temporelles

modèle de l’environnement

4 code des activités

l’applicationconstruction de


Description de l’architecture logicielle

type: T_LogicOutput

attribut

attribut

type: T_MouldInfo

STARTAR

AV

Press

END

T_CmdPress

Ack

Pos_pr

Reqattribut

type: T_MouldId

(1) : definition (des types) de composants


Description de l’architecture logicielle (2)

Ack

Pos_Ch

Pos_m

FillDelay

Req

START

END

AR

AV

Desc

Recul

VV_Ch

CmdLoader

5

5

5

Cmd

ProdEv

STARTAR

AV

Press

ENDAck

CmdPress

Req

Pos_pr

START

END

sig_in sig_out

Ack

START

END

sig_in sig_out

Ack

START

END

sig_in sig_out

Ack

START

END

sig_in sig_out

Ack

START

END

sig_in sig_out

Ack

Mould1 Mould2 Mould3

Mould4 Mould5

START

END

m1

m2

m3

m4

m5

Supervisor

Press

Fill

(2) : vue » structurelle » de l’application



Ack

Pos_Ch

Pos_m

FillDelay

Req

START

END

AR

AV

Desc

Recul

VV_Ch

CmdLoader

55

Cmd

VV_Ch

AV_Ch

AR_Ch

Desc_Ch

Recul_Ch

AV_Pr

AR_Pr

Desc_Pr

MO4

MO3

MO2

MO1li20

li21

li22

li23

li24

sig_in

sig_insig_in

sig_in

FillDelay

sig_in

Cmd

ProdEv

STARTAR

AV

Press

ENDAck

CmdPress

Req

Pos_pr

li10

Pos_Chr

Pos_m

Pos_Pr

MO5

li25

li22START

END

sig_out

Ack

START

END

sig_out

Ack

START

END

sig_out

Ack

START

END

sig_out

Ack

START

END

sig_out

Ack

li9li8

li6

li20

li24li23

li7

li21

li1

li2

li3

MI1

MI2

MI3

MI4

MI5

li5

li6

li7

li9

li8

li10

li5

li3

li2

li10

li1

Mould1 Mould2 Mould3

Mould4 Mould5

START

END

m1

m2

m3

m4

m5

Supervisor

Press

Fill

START

T_ProduceCommand

ENDli25

(3) : vue « reactive » de l’application



0

H1

li3

li4

li5

li6

li3

li4

li5

li6

li7

li8

li9

li10

li11

li7

li8

li9

li10

li11

Desc_Pr

T1

T2

T3

Pression

FillDelay

END

START

ComputeFillDelay

CMD_U1

Pos_Chr

Pos_m

Pos_Pr

Depart_Pain

MI1

MI2

MI3

MI4

MI5

Cmd

FillDelay

VV_Ch

AV_Ch

AR_Ch

Desc_Ch

Recul_Ch

START

ProduceCommand

END

Bp_min

Bp_max

Pos_Chr

Pos_m

Pos_Pr

Depart_Pain

MI1

MI2

MI3

MI4

MI5

T1

T2

T3

Pression

Cmd

Desc_Pr

AV_Pr

AR_Pr

MO1

MO2

MO3

MO4

MO5

li16

li16

Recul_Ch

VA_Bp

VV_Ch

AV_Ch

AR_Ch

Desc_Ch

AV_Pr

AR_Pr

MO1

MO2

MO3

MO4

MO5

End_Prod

li17

li17

min

max

cmd

END

START

TankLevelCtrl

[0,20]

[0,20]

[0,50]

(4) : + hierarchie, composants « passifs », contraintes de temps, etc.


Bilan sur Clara

Clara vs. UML :

I UML est (beaucoup) plus vaste

I on pourrait définir un profil Clara et « faire du Clara en UML »

Clara vs. MetaH, Basement, etc. :Clara se limite a l’architecture logicielle ⇒ langage de plus hautniveau ⇒ langage plus expressif (interactions, activations)


Analyse au niveau de l’AL

1. Des RdP et des règles de composition sont associés auxconstructions Clara

2. On fournit des RdP « décrivant » le comportement des activités

⇒ construction d’un modele RdP de l’architecture logicielle :

I vérification formelle de propriétés de sûreté, de vivacité

I vérification temporelle formelle sous hypotheses de « ressourcesmatérielles infinies » [DUR98]

I vérification temporelle formelle en tenant compte del’ordonnancement [RD02]

Peu ou pas de prise en considération des aspects operationnels


Analyse au niveau de l’AO

Nécessaire de considérer une vue « système » :

I une architecture materielle (µc, réseaux, E/S, etc.)

I équipée de logiciels systemes (exécutifs, protocoles de niv.application, middlewares, etc.)

I sur lesquels s’exécute une application

I pour contrôler un environnement

Approches exhaustives ? ⇒ soit abstraire, soit considérer dessous-systèmes (cf. React, MetaH)

Considérer une vue « système » ? ⇒ simulation (aide à la mise aupoint de l’AO)


Implémentation des architectures décrites

niveau conceptuel niveau implémentation

Architecture en 3 couches :

I les traitements associés aux activités 7→ couche application

I les liens 7→ couche middleware

I OSEK/VDX : système support, standard européen pour lesapplications automobiles




couche application

couche middleware

OSEK/VDX








couche application

couche middleware

OSEK/VDX








couche application

couche middleware

OSEK/VDX






Fonctionnement du middleware

OSEK/VDX OS et COM


p1

p2

END

ACT2

END

START

START

ACT1

sys_exemple



OSEK/VDX OS et COM


p1

p2

END

ACT2

END

START

START

ACT1

sys_exemple

tâches applicatives:projection des activités CLARA



OSEK/VDX OS et COM


p1

p2

END

ACT2

END

START

START

ACT1

sys_exemple


middleware CLARA :tâche serveur



OSEK/VDX OS et COM


p1

p2

END

ACT2

END

START

START

ACT1

sys_exemple





OSEK/VDX OS et COM


p1

p2

END

ACT2

END

START

START

ACT1

sys_exemple



end.req

end.cnf

end.req

end.cnf

start.req

start.cnf

p1.req

p1.cnf

start.req

start.cnf

p2.req

p2.cnf


Middleware : état et perspectives

I solution flexible par rapport aux modifications de l’AL et l’AO(répartition masquée)

I supporte tout Clara (approche systématique)

I permet aisément le passage de l’AL à l’AO (automatisation ...)

mais,

I overhead (inévitable)

I systemes logiciels complexes (validation formelle ...)

À étudier :

I interopérabilité

I sûreté de fonctionnement


Simulation système

Outil : ObjectGEODE

I simulation à événements discrets

I modélisation SDL (définition d’éléments reutilisables)

I atelier de simulation « confortable » : observateurs GOAL,générateur de MSC, etc.

Mais d’autres outils sont envisageables : OPNET, SES/Workbench,simulateur « sur mesure », etc.


Points de modélisation

Parties logicielles :

I découpage en blocs élémentaires (portion de code « interne »)

I bloc = traitements + transaction d’occupation du processeur

Gestion du temps : seuls certains elements du modèle ont la capacitéde faire « progresser le temps »

I processeurs

I bus

I environnement

Modélisation de l’ordonnancement, de la gestion des interruptions,etc.


Résultats

Prise en compte de la taille des modèles :

I utilisation d’observateurs pendant la simulation (des contraintesde temps ou autre métriques)

I filtrage, représentation visuelle pour l’aide a la lecture des traces

Types d’informations extraites d’une simulation :

I respect / violation des contraintes de temps (+ mesure desintervalles)

I temps de latence d’un message, d’une interruption, gigued’activation d’une tâche, etc.

⇒ interprétation selon la provenance du scénario : comparaison devaleurs des paramètres opérationnels (placement, attribution despriorités) , cas d’erreur detecte par verification formelle), etc.


Exemple de traces : niveau « application »

simulation_these_appli

gogo

go

cwaitevent( 0.0,0xf )rwaitevent( 24.0,e_ok )

cgetresource( 0.0,2 )

rgetresource( 37.0,e_ok )csendmessage( 37.0,1,’2’ )

rsendmessage( 86.0,e_ok )

cgetevent( 24.0,2 )

rgetevent( 99.0,e_ok,0x1 )cclearevent( 99.0,0x1 )

rclearevent( 103.0,e_ok )creceivemessage( 103.0,1 )

rreceivemessage( 128.0,e_ok,’2’ )cgetcpu( 128.0,11.0 )rgetcpu( 139.0,0.0 )

cwaitevent( 139.0,0xf )

creleaseresource( 86.0,2 )

cgetresource( 0.0,2 )

inst_osek_layer

BLOCK /ex_ao/

osek_layer

inst_1_serverexPROCESS /

ex_ao/appli/

serverex(1)

inst_1_tcons

PROCESS /ex_ao/appli/

tcons(1)

inst_1_tprod

PROCESS /ex_ao/appli/

tprod(1)


Exemple de traces : niveau « noyau »

sendmessage( 37.0,1,’2’ )

cpu_req( 37.0,49.0 )cpu_ack( 86.0 )

update_msg( 1,’2’ )internal_notif( { (. 2,0x1 .) } )

servicestatus( 86.0,e_ok,0x0,’’ )sched_ready( 86.0 )sched_ready( 86.0 )sched_running( 86.0 )


Bilan sur la simulation

Points positifs :

I travail reellement sur l’AO (ex : étudier l’influence des ISR, dudébit du bus, du type d’E/S, etc.)

I permet de jouer à « et si ... »

I retours rapides

⇒ mise au point de l’AO

Limites :

I technique lourde (taille des modèles, temps de calcul,exploitation des resultats)

I technique non exhaustive

I ObjectGEODE : uniquement systèmes discrets (pb pour modèledu procédé)



1. Conception centrée architecture

2. Application aux systèmes temps réel



REACT : Développements et perspectives

Travaux en cours : outils d’accompagnement du developpement

I construction de la vue système : placement (algo. génétique),ordonnancement des traitements et des messages (analysed’ordonnançabilité)

I simulation fine (niveau cycle) pour la mise au point du système

Travaux envisagés : définition de styles au sein de Clara

I guides par les techniques d’analyse : assurer l’adéquationmodèle / implémentation (Ex : systèmes périodiques et techniqued’analyse d’ordonnançabilité compatible)

I guides par les metiers (Ex : profil automobile, profil robotique,etc.)


Conclusions

L’approche « centrée architecture » :

I offre un cadre solide et adapté pour le développement desystemes temps reel complexes

I fait apparaître naturellement le niveau operationnel

I permet d’intégrer les différents outils de développement « tempsréel » dans un processus coherent

Problèmes ouverts :

I « équilibre » entre l’expressivité de l’ADL et les modèlesanalysables (styles ?)

I relier les erreurs détectées et l’architecture logicielle

I évaluation de l’aspect qualitatif des architectures

I etc.


References[BV01] P. Binns et S. Vestal. Formalizing software architecture for embedded systems. In Proc’ of

EMSOFT 01, vol. 2211 de LNCS. Springer, 2001.

[DUR98] E. Durand. Description et vérification d’architectures d’application temps réel : Clara et les

réseaux de Petri temporels. Thèse de doctorat, École Centrale de Nantes, 1998.

[ES02] J.-P. Elloy et F. Simonot-Lion. An Architecture Description Language for In-Vehicle

Embedded System Development. In Proc’ of IFAC 15th World Congress, IFAC, 2002.

[FAU02] S. Faucou. Description et construction d’architectures opérationnelles validées

temporellement. Thèse de doctorat, Université de Nantes, 2002.

[GS94] D. Garlan et M. Shaw. An introduction to software architecture. Rapport technique

CMU/SEI-94-TR-21, CMU SEI, 1994.

[HLS+96] H. Hansson et al. Basement : A Distributed Architecture for Vehicle Applications. Journal of

RTS, 11, 1996.

[MT00] N. Medvidovic et R. Taylor. A Classification and Comparison Framework for Software

Architecture Description Languages. IEEE TSE, 26(1), Janvier, 2000.

[RD02] O. Roux et A.-M. Déplanche. A T-time Petri net extension for real-time task scheduling

modeling. JESA, 36(7), 2002.GDR ARP - Groupe StrQds - Journee ADL - 16/01/2003 – p.34/34

Documents

Description et analyse d’architectures d’applications ...homepages.laas.fr/francois/STRQDS/reunions/160103/clara.pdf · d’applications temps réel - Le projet REACT Sebastien´