Cours 10 De l`entité autonomique - Master informatique

—
Composition
Contractualisation
Simulation
Validation
—
—
Composition
Contractualisation
ALASCA — Architecture logicielles avancées
pour les systèmes complexes auto-adaptables
Simulation
Validation
—
Cours 10
c 2014–2016 Jacques Malenfant
De l’entité autonomique
Master informatique, spécialité STL – UFR 919 Ingénierie
Université Pierre et Marie Curie
[email protected]
1 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Objectifs pédagogiques du cours 10
2 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Plan
Comprendre les problématiques liés à la création d’une entité
autonomique par composition entre une entité adaptable et une
entité de contrôle.
Introduire la contractualisation comme moyen d’exprimer et de
vérifier les engagements réciproques entre entités adaptables et
entités de contrôle.
Étudier plus précisément la simulation comme moyen pour
supporter les tests, l’identification au déploiement des modèles
comportementaux, la détermination de la loi de contrôle et la
vérification dynamique des entités autonomiques.
3 / 58
1
Composition et déploiement
2
Contrats de contrôle
3
Techniques de simulation
4
Simulation et validation des systèmes autonomiques
4 / 58
—
Composition
Contractualisation
Auto-adaptabilité = contrôle
Simulation
Validation
—
adaptabilité
—
Composition
Contractualisation
Simulation
Validation
—
Principales activités à conduire pour la composition
Cours 6 à 9 : conception, implantation et tests fonctionnels
unitaires des entités adaptables et de contrôle individuellement.
Pour la composition, en phase de développement :
L’auto-adaptabilité est la composition verticale entre la fonction
de contrôle et les capacités d’introspection et d’adaptation d’un
système.
1
Recadrée dans le contexte des architectures logicielles, cette
composition conceptuelle devient la connexion d’une entité
adaptable avec une entité de contrôle.
2
3
Informatiquement parlant, cela revient à créer les liens entre les
deux entités, comment la connexion de ports via des connecteurs
dans une architecture à base de composants.
Vérification statique de la conformité des interfaces capteurs et
actionneurs requises et offertes et de leurs contrats.
Test d’intégration et vérification des contrats avec l’environnement.
Identification du domaine de fonctionnement correct.
Puis en phase de déploiement :
1
2
3
Sur le fond, la difficulté est moins dans l’établissement de ces
liens que dans l’obtention d’un bon comportement conjoint des
deux entités.
4
Détermination de la répartition sur l’architecture physique.
Connexion explicite entre les deux entités.
Identification des paramètres des modèles et des contrats.
Configuration des paramètres de fonctionnement des capteurs,
des actionneurs et du contrôleur.
Et enfin en phase d’exécution :
Note : la composition horizontale, entre contrôles, se réalise parfois par fusion,
1
mais plus généralement par coopération et coordination, sujets du cours 12.
2
Supervision et vérification dynamique des contrats.
Adaptation dynamique du contrôle (cours 13).
5 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Tests et domaine de fonctionnement
6 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Déploiement réparti et localisation
Ordinateur physique
Choix de localisation possibles :
Tests unitaires :
tester individuellement la fonctionnalité, avec des « bouchons »
pour remplacer les entités non-disponibles ;
compléter les « bouchons » fonctionnels déjà bien connus par des
« bouchons » de comportement plus rarement étudiés ;
les modèles de comportement fournissent des « bouchons » pour
générer des valeurs de capteurs réalistes.
contrôleur purement délibératif ou partie
délibérative d’un contrôleur hybride peut être
distant (a, b) de l’entité adaptable puisque ces
contrôleurs ne garantissent pas leurs délais de
réactions, donc les délais de communication
aléatoires sont absorbés dans la durée aléatoire
des calculs du contrôleur ;
il peut aussi être co-localisé (d, e) ;
contrôleur purement réactif ou encore partie
réactive d’un contrôleur hybride, généralement
co-localisé avec l’entité adaptable pour éviter les
délais aléatoires dans la communication par
réseau (a, c).
Tests d’intégration : les « bouchons » sont progressivement
retirés au profit des entités réelles, sauf qu’on en reste à des cas
génériques testés selon plusieurs hypothèses en modifiant les
paramètres des modèles.
Domaine de fonctionnement : une étude systématique faisant
varier les modèles de l’environnement et du contexte de
déploiement permet d’identifier les plages de valeurs de
paramètres pour lesquelles l’entité autonomique fonctionnera
correctement.
IP
IP
Contrôleur
réactif
Entité
adaptable
(b)
(a)
Ordinateur physique
Ordinateur physique
Contrôleur
purement
réactif
Contrôleur
délibératif
Entité
adaptable
Contrôleur
réactif
Entité
adaptable
(c)
Ordinateur physique
Contrôleur
purement
délibératif
l’entité adaptable est le sujet d’étude des systèmes de contrôle
7 / 58
Contrôleur
délibératif
Entité
adaptable
Note : la délocalisation des contrôleurs réactifs par rapport à
en réseau déjà évoqués.
Ordinateur physique
Contrôleur
délibératif
(d)
Entité
adaptable
(e)
8 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Critères de choix du déploiement
—
Composition
Contractualisation
Simulation
Validation
Identification des modèles au déploiement
Le choix du bon déploiement dépend du contrôle employé, mais
aussi de considérations d’architecture physique :
Rappel : en phase de conception, les modèles de comportement
et de l’environnement demeurent génériques car contextes de
déploiement pas encore connus ou trop variés.
si la fréquence de contrôle est élevée et les ressources
disponibles limitées, les solutions purement réactives ou hybrides
à partie délibérative délocalisée s’imposent ;
si la fréquence de contrôle est élevée et les ressources
disponibles suffisantes, une solution hybride co-localisée pourra
être privilégiée ;
si la fréquence du contrôle est faible, une solution purement
délibérative peut être employée, co-localisée ou non selon les
resources disponibles.
La détermination des paramètres pour une loi de commande
correcte dépendent de modèles de comportement précis.
Idée : au déploiement, soumettre l’architecture logicielle à un jeu
scénarios simulant l’environnement pour
mesurer le comportement de l’entité adaptable,
puis estimer les paramètres du modèle de comportement.
Il s’agit donc d’orchestrer les fonctionnalités introduites à cette fin
dans les entités adaptable et de contrôle.
Dans le cas d’un contrôleur hybride, les interactions entre les
parties délibérative et réactive seront aussi impactés :
un contrôleur hybride en supervision hiérarchique suggère la
co-localisation des parties délibératives et réactives ;
symétriquement, des parties délibératives et réactives distantes
poussent plutôt vers une implantation en contrôle adaptatif.
Ensuite, pour le modèle de l’environnement, selon les cas il peut
devenir nécessaire de collecter des données pendant l’exécution
réelle du système pour l’identifier correctement.
9 / 58
—
Composition
Contractualisation
—
Simulation
Validation
—
Plan
10 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Qu’est-ce que la programmation contractuelle ?
1
Composition et déploiement
2
Contrats de contrôle
3
Techniques de simulation
4
Simulation et validation des systèmes autonomiques
Idée : organiser la relation client/serveur autour d’engagements
réciproques et un raisonnement de type hypothèses/garanties.
Trois principaux types de contraintes :
pré-conditions : conditions devant être remplies par le requérant
lors d’un appel à l’offrant ;
post-conditions : garanties apportées par l’offrant si le requérant a
respecté ses pré-conditions ;
invariants : relations maintenues pendant son exécution, sauf
peut-être pendant ses changements d’états.
Raisonnement hypothèses/garanties :
Sous l’hypothèse que ses pré-conditions et l’invariant sont observés, le code
appelé garantit de rendre un résultat et un état de système respectant les
post-conditions et l’invariant.
Introduite principalement par B. Meyer en Eiffel, où ces
contraintes font partie intégrante du langage, à partir d’une
théorie appelée sémantique axiomatique.
11 / 58
12 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Contrats dans les architectures logicielles
—
Composition
Contractualisation
Simulation
Validation
Contrats dans les architectures autonomiques
La programmation contractuelle peut être étendue au-delà de la
relation client/serveur à toute composition entre entités logicielles.
Engagements réciproques entre entités adaptable et de contrôle
pour couvrir :
Notion déclinée dans plusieurs contextes, dont par exemple :
1
modèles à composants, par extension de leur interprétation dans
le monde des objets aux interfaces offertes et requises, plutôt
orienté fonctionnel ;
architectures fondées sur les services : « service level
agreements, service level objectives » (SLA/SLO), plus QdS.
2
3
4
Contrats sur les interfaces :
interfaces requises : contrats requis R
interfaces offertes : contrats offerts O
connexion : conformité entre contrats
des aspects fonctionnels, comme les signatures et les pré- et
post-conditions sur les interfaces capteurs et actionneurs ;
des aspects non-fonctionnels, comme la précision des valeurs de
capteurs ;
des aspects de qualité de service, comme la durée d’exécution
des actionneurs ;
des aspects de qualité de contrôle, comme le domaine de stabilité
du contrôle, le délai de réglage, ou le taux de variation maximal
des valeurs de capteurs que le contrôleur peut traiter.
Avant d’aborder les derniers aspects, peu abordés jusqu’ici,
regardons brièvement ce qui s’est fait dans le domaine de la
qualité de service.
O =) R
Ex. : durée requise < 5 =) durée offerte < 10
13 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Expression des contrats fonctionnels et de qualité de service
2
3
14 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Exemple QML : serveur de taux de change
interface RateServiceI {
Rates latest(in Currency c1, in Currency c2) ;
Forecast analysis(in Currency c) ;
}
Besoin pour les contrats de QdS : langage permettant
1
—
d’exprimer les contraintes requises et offertes,
de vérifier la conformité d’un contrat offert avec un requis, et
d’assurer le respect des contrats à l’exécution.
type Reliability = contract {
numberOfFailures : decreasing numeric no / year ;
TimeToRepair : decreasing numeric sec ;
availability : increasing numeric ;
}
type Performance = contract {
delay : decreasing numeric msec ;
throughput : increasing numeric no / sec ;
}
systemReliability = Reliability contract {
numberOfFailures < 10 no / year ;
TimeToRepair { percentile 100 < 20000 ; mean < 500 ; variance < 0.3 }
availability > 0.8 ;
}
rateServerProfile for RateServiceI = profile {
require systemReliability ;
// apply to all operations
from latest require Performance contract {
// refinements
delay { percentile 50 < 10 msec ;
percentile 80 < 20 msec ;
percentile 100 < 40 msec ; }
} ;
from analysis require Performance contract { delay < 4000 msec ; } ;
}
Un exemple : QML (Quality of service Modeling Language), dont
les concepts fondamentaux sont :
dimension de QdS : propriété nommée, avec son type de valeurs
et autres informations ;
type de contrats : un ensemble de dimensions caractérisant une
catégorie de QdS comme la performance, la disponibilité, la
sécurité ou le temps ;
contrat : instantiation d’un type de contrats avec des contraintes
particulières pour une certaine catégorie de QdS ;
profil : association d’un contrat à une interface.
15 / 58
16 / 58
—
Composition
Contractualisation
Simulation
Validation
—
De la qualité de service au contrôle
—
2
3
4
Contractualisation
Simulation
Validation
Communication de données par réseau sans fil :
l’application de l’adaptation de compression des données résulte
dans une diminution correspondante de la consommation de
bande passante (selon le taux de compression) ;
la période entre les adaptations ne doit pas être inférieure à la
durée de l’adaptation (si elle n’est pas interruptible).
stabilité
précision (accuracy )
réactivité (short settling time)
économie des moyens (small/no overshoot)
Il est essentiel de pouvoir analyser ces propriétés, ce qui
demande d’identifier les opérations d’adaptation par leurs effets
sur ses propriétés contrôlables et d’en fixer les limites
acceptables pour garantir les propriétés SASO.
Dans le meilleur des cas, il est souhaitable qu’il existe une
relation déterministe simple entre l’ampleur d’une opération
d’adaptation et l’ampleur de son impact.
En pratique, cela peut devenir plus compliqué et supposer
l’expression complète des modèles de comportement et de
contrôle (hybrides) dans le contrat de contrôle.
Allocation de machines virtuelles à une applications :
à taux d’arrivée des requêtes constant, l’ajout de machines
virtuelles résulte dans une diminution quantifiable de la durée de
traitement des requêtes (attente plus service) ;
la plage de variation de la dérivée du taux d’arrivée des requêtes
contrôlable fixée à partir des taux maximaux d’allocation ou de
désallocation des machines virtuelles.
Mais, rappelons que l’effet des opérations d’adaptation peut aussi
être aléatoire, voire non-déterministe, au prix d’un contrôle plus
complexe.
17 / 58
—
Composition
Contractualisation
Simulation
—
Exemples de propriétés de contrôle à exprimer
En contrôle, quatre propriétés importantes en caractérisent la
qualité, les propriétés dîtes SASO :
1
Composition
Validation
—
Contrat de contrôle, côté entité adaptable
18 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Contrats individuels sur les capteurs et actionneurs
Objectif : capturer les relations entre actionneurs et capteurs
permettant de caractériser le modèle de l’entité et de construire
un modèle de contrôle correct.
Les interfaces capteurs sont contractualisées sur leurs
méta-propriétés, incluant celles des mesures sous-jacentes.
Contrat logique : détermine quels actionneurs impactent quels
capteurs.
Contrat qualitatif : étend le contrat logique en donnant des relations
qualitatives entre les actions d’adaptation des
actionneurs et l’évolution des mesures observables sur
les capteurs (directions, ordres de grandeurs,
raisonnement dans l’imprécision).
Contrat quantitatif : étend le contrat qualitatif en donnant des relations
mathématiques entre les actions d’adaptation des
actionneurs et les mesures qui seront obtenues sur les
capteurs.
Les interfaces actionneurs peuvent être contractualisées sur leurs
méta-propriétés, incluant celles des opérations d’adaptation.
Pré-conditions : période d’appel.
Post-conditions : délai de mise en route, latence, fraîcheur des
données, cohérence temporelle, coût.
Invariants : mesures utilisées (qualitatif), portée des mesures,
réactivité, précision, biais, erreur, corrélation entre capteurs.
Pré-conditions : fonctionnelles (paramètres, état de l’entité) +
période minimale entre appels.
Post-conditions : fonctionnelles (résultats, état de l’entité) + durée,
coûts en ressources.
Invariants : fonctionnels (état de l’entité).
La notion de « relation » déborde des possibilités des contrats à
la QML, et sont beaucoup plus difficile à manier (conformité, ...).
19 / 58
20 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Relations entre actionneurs et capteurs
—
3
4
Simulation
Validation
Côté entité de contrôle, il exprime
1
Propriétés adaptables affectées par chacun des actionneurs.
Délais entre le lancement d’une adaptation et la stabilisation des
valeurs des propriétés adaptables puis le moment où elles seront
lisibles via les capteurs.
Engagement quantitatif entre l’ampleur de l’adaptation et
l’ampleur de son impact sur les valeurs stabilisées des propriétés
adaptables touchées.
Mieux, évolution temporelle des valeurs des propriétés adaptables
entre la fin de l’opération d’adaptation et leur stabilisation.
2
les méta-propriétés des capteurs et des actionneurs attendues
selon les hypothèses du modèle de contrôle, et
les méta-propriétés de la loi de contrôle ou de commande réalisée
(amplitude des variations contrôlables en entrée, amplitude des
actions d’adaptation, et les relations entre les deux).
C’est-à-dire la partie requise du contrat de contrôle.
À la composition des deux entités, sous l’hypothèse de
conformité offert/requis, s’ajoute l’expression des conditions par
rapport à l’environnement et aux parties intéressées :
Objectif : à partir de l’identification du modèle de l’entité
adaptable, calibrer le modèle de contrôle de l’entité de contrôle.
1
des contraintes sur les propriétés de l’environnement (taux
d’arrivée des requêtes, ...),
21 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Contractualisation de la relation de contrôle II
2
3
—
Du côté de l’entité adaptable, le contrat de contrôle exprime la
partie offerte du contrat de contrôle.
Nous avons indiqué que ces relations de causalité devraient être
explicitées de manière qualitatives et quantitatives :
2
Contractualisation
Contractualisation de la relation de contrôle I
Expliciter comment l’exécution des actionneurs affecte-t-elle la
lecture sur les capteurs.
1
Composition
22 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Expression du contrat de contrôle
Il s’agit d’exprimer des contraintes sur des valeurs de
méta-propriétés, comme nous l’avons déjà vu au cours 7 pour les
entités adaptables, mais aussi sur les objectifs du contrôle et les
méta-propriétés du contrôle lui-même.
des engagements sur le maintien des propriétés adaptables sur
des cibles précise (durée de service fixée à 1s ± 0.1),
des méta-propriétés associées à la manière de réaliser ce
maintien (délais de réaction aux variations des entrées ; rapidité,
la précision et le coût des actions ramenant l’entité adaptable sur
sa cible.
Il est possible d’exprimer par documentation ou annotation de
telles contraintes en utilisant une syntaxe comme celle de QML.
Exemple : performance d’une application web où d¯s est la durée
moyenne de service des requêtes et d le délai entre détection
hors cible et retour à la cible,
Objectif de contrôle : 0.9  d¯s  1.1
Délai maximal : d  120s
attention, ce n’est pas une politique à seuil !
Pénalité au contrôleur :
si d¯s > 1.1 alors e ⇥ d2 ⇥ (1 + (d¯s 1.1))3 euros
si d¯s < 0.9 alors e+ ⇥ d2 ⇥ (0.9 d¯s )2 euros
où e , e+ : taux déterminés entre parties contractantes.
23 / 58
24 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Vérification du contrat de contrôle
—
Composition
Contractualisation
Simulation
Validation
Supervision et vérification dynamique des contrats
Comme nous l’avons déjà indiqué en introduisant QML, la
vérification formelle de conformité entre offert et requis dépend
beaucoup des expressions (mathématiques) autorisées dans
l’expression du contrat.
Supervision et vérification dynamique suppose une
instrumentation supplémentaire pas nécessairement prévue pour
le contrôle.
Idée : collecter des données dynamiquement pour vérifier
Ex. : Comment vérifier la conformité entre deux fonctions ?
la bonne identification des modèles,
le respect des contrats offerts et leur conformité avec les contrats
requis,
le traitement adéquat des situations où les contrats ne sont plus
respectés par des mécanismes ad hoc (ex. : taux d’arrivée des
requêtes variant trop vite impliquant le rejet immédiat d’une partie
des requêtes).
Par ailleurs plusieurs des propriétés à contractualiser sont des
variables aléatoires dont la densité de probabilité sera imposée
par contrat, or la vérification de ce type de méta-propriétés
demande de faire des tests statistiques sur les valeurs
observées.
Comment vérifier que la densité de probabilité d’un échantillon est
conforme à la densité de la variable ?
Mais cette instrumentation et ces vérifications imposent un
surcoût à l’exécution.
Enfin, les modèles, contrats et leur identification ne sont jamais
parfaits.
Il faut trouver un équilibre entre l’importance de vérifier que les
entités respectent leurs engagements et le surcoût engendré par
cette vérification dynamique.
) Nécessité de la vérification et validation dynamique, plus simples
en pratique.
25 / 58
—
Composition
Contractualisation
—
Simulation
Validation
—
Plan
26 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Fondements
1
Composition et déploiement
2
Contrats de contrôle
3
Techniques de simulation
4
Simulation et validation des systèmes autonomiques
La simulation s’intéresse à reproduire synthétiquement le
comportement des systèmes pour mieux les comprendre, les
concevoir, les valider et les optimiser.
Confrontés depuis longtemps à des systèmes modélisés par des
équations différentielles trop complexes pour être résolues
analytiquement, les ingénieurs se sont intéressés à la simulation
vue comme la résolution (intégration) numérique de leurs
équations : la simulation continue !
En parallèle, des concepteurs de systèmes discrets,
principalement stochastiques, se sont intéressés à des
techniques de simulation appropriées à ce genre de systèmes, ce
qui a donné la simulation par événements discrets !
L’apparition des modèles hybrides a justifié une étude conjointe
des deux approches précédentes pour donner la simulation
hybride.
27 / 58
28 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Principes généraux
—
2
3
2
Simulation
Validation
Simulation continue
Simulation par événements discrets
Simulation hybride
Moteur de simulation continue : calcul numérique, et en
particulier l’intégration numérique qui, dans le cas le plus simple,
implante les équations différentielles en code exécutable,
adopte un pas d’intégration t représentant le temps qui avance
dans l’exécution du système (pouvant varier d’une étape à l’autre),
calcule les valeurs des variables à t0 , t0 + t, t0 + 2 t, ...
simulation déterministe versus stochastique
simulation centralisée versus répartie
Principaux concepts de mise en œuvre :
Cas stochastique :
horloge de simulation ;
modèle de simulation pour calculer l’état du système aux instants
utiles dans le temps simulé ;
collecter les mesures utiles comme résultats de la simulation ;
le simulations stochastiques échantillonnent les phénomènes
aléatoires ) répétitions pour obtenir des estimations précises.
variables aléatoires réalisées par leurs fonctions de distribution de
probabilité
) générateurs de nombres pseudo-aléatoires ;
mouvements browniens : équations différentielles stochastiques
et intégrale d’Itô numérique
) intégration numérique adaptée au cas stochastique.
29 / 58
—
Composition
Contractualisation
—
Systèmes d’équations trop complexes et trop difficiles pour être
résolus analytiquement ;
Mais aussi deux grandes modalités :
1
Contractualisation
Simulation continue, pourquoi ?
Donc, trois principales formes de simulation :
1
Composition
Simulation
Validation
—
Modèle d’un système à événements discrets
30 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Moteur de simulation par événements discrets.
Un système est composé d’entités qui ont des propriétés
capturées par les valeurs de leurs attributs. La collection de tous
les attributs de toutes les entités dans le système forme l’état du
système.
Un événement est une occurence instantanée où l’état du
système est calculé. Les événements débutent ou terminent des
activités d’une certaine durée, mais pendant lesquelles rien de
significatif nécessite d’être observé.
Le comportement d’un système est simulé en calculant les
attributs des entités au fil du temps restreint aux occurrences
d’événements selon l’impact de ces événements et des activités
sur l’évolution des valeurs des attributs.
Un modèle peut être déterministe, si toutes les activités, leurs
relations causales et leurs impacts sur les entités sont
déterminstes, ou stochastique si certaines de ces relations ou de
ces impacts sont aléatoires.
File des événements à venir : ensemble des événements triés en
ordre croissant de leurs instants d’occurrence t1 , t2 , ....
Algorithme d’exécution :
1
2
3
4
Prendre le premier événement dans la file.
Calculer ou générer aléatoirement les modifications qu’il entraîne
sur l’état du système et appliquer ces valeurs pour modifier l’état
Générer les événements futurs causés par l’événement courant et
les insérer dans la file des événements.
Tant que la file des événements n’est pas vide, reprendre à 1.
Gestion du temps et horloge de simulation :
temps simulé discret = extraction des occurrences d’événements
du temps réel ;
simulation en temps réel : horloge = temps réel ;
temps réel accéléré : relation linéaire constante entre l’horloge de
simulation et le temps réel.
31 / 58
32 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Exemple de système discret : guichets de banque
—
Composition
Contractualisation
Simulation
Validation
Exemple : cas particulier de la file d’attente M/M/1 I
n guichets de service permettant d’accueillir les clients.
m files d’attente, 1  m  n où les clients se mettent en attente
de service lorsque tous les guichets sont occupés.
Le système peut être modélisé par un ensemble de variables
comme la longueur des files d’attente à tout instant, les durées
de service de chaque client, leur durée d’attente, etc.
Dans un tel système, les changements d’état se produisent pour
l’essentiel à des instants précis : arrivée et mise en file d’un
client, début de service d’un client, fin de service d’un client.
Ces événements sont les seuls instants où il est nécessaire et
suffisant d’observer et faire évoluer le système pour en capturer
le comportement.
On s’intéresse à l’évaluation des propriétés, souvent selon
différents choix de conception : ici on peut s’intéresser à
déterminer le nombre de files permettant de minimiser le temps
total moyen que les clients passent dans la banque.
Entités : requête, serveur, file d’attente
Attributs :
requête : moment d’arrivée
serveur : libre ou occupé
file : suite des requêtes en ordre d’arrivée
événements : arrivée d’une requête, début de service d’une
requête, fin de service d’une requête.
arrivée : marque la requête par l’heure de son arrivée, et si le
serveur est libre, le change à occupé et provoque immédiatement
un début de service pour cette requête, sinon la requête est
ajoutée à la fin de la file d’attente.
début de service, passe le serveur à occupé et génère
l’événement de fin de service pour la requête correspondante.
33 / 58
—
Composition
Contractualisation
Simulation
Validation
—
—
Exemple : cas particulier de la file d’attente M/M/1 II
34 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Animation du modèle
Horloge : 0
fin de service : calcule le temps de service de la requête, puis si la
file n’est pas vide, provoque immédiatement le début de service
de la prochaine requête, sinon passe le serveur à libre.
File des événements
Arrivée Requete1
t:2
Les arrivées engendrent les débuts de service qui engendrent les
fins de service, qui elles-mêmes peuvent engendrer un début de
service, mais comment gérer les arrivées ?
Requete1
arrivée :
générer à l’avance toutes les arrivées et les insérer dans la file
des événements ?
) long et coûteux en espace pour les simulations longues.
générer la première arrivée, et ajouter une relation causale
synthétique faisant que le traitement de l’évenemnt arrivée génère
l’arrivée suivante.
) beaucoup moins coûteux en espace, mais peut s’avérer
difficile voire impossible dans certains cas (plutôt rares ?).
File d’attente
Serveur
état : libre
Somme des temps :
nombre de requetes :
35 / 58
36 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Animation du modèle
—
Composition
Contractualisation
Simulation
Validation
Animation du modèle
Horloge : 2
Horloge : 2
File des événements
File des événements
Début de service Requete1 Arrivée Requete2
t:2
t:3
Arrivée Requete2 Fin de service Requete1
t:3
t:5
Requete1
arrivée : 2
Requete1
arrivée : 2
Requete2
arrivée :
Requete2
arrivée :
File d’attente
File d’attente
Serveur
état : occupé
Serveur
état : libre
Somme des temps :
nombre de requetes :
Somme des temps :
nombre de requetes :
37 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Animation du modèle
38 / 58
—
Composition
Contractualisation
Horloge : 5
File des événements
File des événements
Fin de service Requete1 Arrivée Requete3
t:5
t:6
Début de service Requete2
t:5
Requete2
arrivée : 3
Simulation
Validation
—
Animation du modèle
Horloge : 3
Requete1
arrivée : 2
—
Requete2
arrivée : 3
Requete3
arrivée :
File d’attente
Arrivée Requete3
t:6
Requete3
arrivée :
File d’attente
Serveur
état : occupé
Serveur
état : occupé
Somme des temps :
nombre de requetes :
Somme des temps : 3
nombre de requetes : 1
39 / 58
40 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Animation du modèle
—
Composition
Contractualisation
Simulation
Validation
—
Animation du modèle
Horloge : 5
Et ainsi de suite jusqu’au temps de fin de simulation ou une liste
d’événements vide...
File des événements
Arrivée Requete3 Fin de service Requete2
t:6
t:9
Requete2
arrivée : 3
Requete3
arrivée :
File d’attente
Serveur
état : occupé
Somme des temps : 3
nombre de requetes : 1
41 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Première formalisation d’un modèle axé événements
42 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Comportement d’un modèle axé événements
L’algorithme générique du simulateur est :
Un modèle de simulation est un tuple M = (S , ⇥, E , Y , d, l, s, s0 ) où
1
2
S est l’ensemble des états et s0 2 S l’état initial.
⇥ = q1 [ ... [ qk est l’ensemble des types d’événements.
3
E = Eq1 [ ... [ Eqk , qi 2 ⇥ est l’ensemble des événements.
4
Y est l’ensemble des sorties.
5
d : S ⇥ E ⇥ R+ ! S est la fonction de transition.
6
l : S ⇥ R+ ! Y est la fonction de sortie.
7
s : ⇥ ⇥ S ⇥ R+ ! ⇧(Eq , R+ ) est l’ensemble des densités de probabilité
d’occurrence des événements de type q telle que P(e, t 0 |s, t ) est la probabilité
de la prochaine occurrence de l’événement e 2 Eq à l’instant t 0 t étant donné
8
Le système débute dans un état initial s0 au temps 0 d’horloge.
8q 2 ⇥, générer la prochaine occurrence de Eq selon la
probabilité s(q, s0 , 0) et l’insérer parmi les événements à traiter.
Extraire des événements à traiter l’occurrence e, t 0 dont t 0 est le
plus petit.
Calculer le prochain état s0 = d(s, e, t )
Avancer l’horloge à t 0
Calculer la sortie courante y = l(s0 , t 0 )
8q 2 ⇥, générer la prochaine occurrence de eq selon la
probabilité s(q, s0 , t 0 ) et l’insérer parmi les événements à traiter.
Si l’ensemble des événements à traiter n’est pas vide, aller à 3.
D’occurrences d’événements en occurrences d’événements, et de
sorties observées en sorties observées, la simulation produit une
trajectoire possible du système, et donc simuler revient à échantillonner
l’espace des trajectoires.
que le système est dans l’état s à l’instant t.
43 / 58
44 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Modèle de la banque à guichet unique
i : état initial.
a(c) : arrivée du client c.
s : début de service d’un client.
d : départ d’un client après service.
f : fin de la simulation.
S = {i , a, s, d , f } ⇥ FilehClient i⇥
⇥ = {a, s, d , f }
Client ⇥ R+ ⇥ N
d(hi , q , c , 0, 0i, a(c ), t ) = ha, q .insere(c ), c , 0, 0i
0
d(ha, q , c , r , ni, a(c 0 ), t ) = ha, q .insere(c 0 ), c , r , ni
/ 0.0, 0i, 0i
hs0 , t0 i = hhi , [], 0,
/ r , ni, s, t ) = hs, q .retire(), q .premier (), r , ni
d(ha, q , 0,
/ r + (t 0
d(hha, q , c , r , ni, d , t ) = hd , q , 0,
d(hha, q , c , r , ni, f , t ) = hf , q , c , r , ni
/ 0.0, 0i, 2i
hs1 , t1 i = hha, [c0 ], 0,
c .arr ), n + 1i
hs2 , t2 i = hhs, [], c0 , 0.0, 0i, 2i
hs3 , t3 i = hha, [c1 ], c0 , 0.0, 0i, 4i
/ 3.0, 1i, 5i
hs4 , t4 i = hhd , [c1 ], 0,
d(hs, q , c , r , ni, a(c ), t ) = ha, q .insere(c ), c , r , ni
0
0
/ r + (t
d(hs, q , c , r , ni, d , t ) = hd , q , 0,
hs5 , t5 i = hhs, [], c1 , 3.0, 1i, 5i
c .arr ), n + 1i
hs6 , t6 i = hha, [c2 ], c1 , 3.0, 1i, 6i
/ 6.0, 2i, 7i
hs7 , t7 i = hhd , [c2 ], 0,
s(f , h·, q , c , r , ni, t ) =
0
hs8 , t8 i = hhs, [], c2 , 6.0, 2i, 7i
d(hd , q , c , r , ni, s, t ) = hs, q .retire(), q .premier (), r , ni
1.0 si t 0 = 10
0.0 si t 0 =
6 10
s(a, h{i , a}, q , c , r , ni, t ) = Exp[t 0
t ; ta ]
ta : taux d’arrivée des clients.
/ 8.0, 3i, 8i
hs9 , t9 i = hhd , [], 0,
d(hd , q , c , r , ni, f , t ) = hf , q , c , r , ni
(
1.0 si t 0 = t ^ q 6= 0/
/ r , ni, t ) =
s(s, h{a, d }, q , 0,
0.0 si t 0 6= t _ q = 0/
s(d , hs, q , c , r , ni, t ) = Exp[t 0
Simulation
Validation
/ 8.0, 3i, 9i
hs10 , t10 i = hha, [c3 ], 0,
hs11 , t11 i = hhs, [], c3 , 8.0, 3i, 9i
hs12 , t12 i = hhf , [], c3 , 8.0, 3i, 10i
t ; ts ]
EAT = {hf , 10i}
EAT = {ha(c0 ), 2i, hf , 10i}
EAT = {hs, 2i, ha(c1 ), 4i, hf , 10i}
EAT = {ha(c1 ), 4i, hd , 5i, hf , 10i}
EAT = {hd , 5i, ha(c2 ), 6i, hf , 10i}
EAT = {hs, 5i, ha(c2 ), 6i, hf , 10i}
EAT = {ha(c2 ), 6i, hd , 7i, hf , 10i}
EAT = {hd , 7i, ha(c3 ), 9i, hf , 10i}
EAT = {hs, 7i, ha(c3 ), 9i, hf , 10i}
EAT = {hd , 8i, ha(c3 ), 9i, hf , 10i}
EAT = {ha(c3 ), 9i, hf , 10i}
EAT = {hs, 9i, hf , 10i, ha(c4 ), 12i}
EAT = {hf , 10i, hd , 11i, ha(c4 ), 12i}
EAT = {hd , 11i, ha(c4 ), 12i}
l(hhf , [], c3 , 8.0, 3i, 10i) = 8.0/3
ts : taux de service des clients.
45 / 58
—
Composition
Contractualisation
Simulation
—
Exécution :
d(hd , q , c , r , ni, a(c ), t ) = ha, q .insere(c ), c , r , ni
(
Contractualisation
d(hi , q , c , 0, 0i, f , t ) = hf , q , c , 0, 0i
0
l(hf , q , c , r , ni) = r /n
Composition
Exécution du modèle de la banque à guichet unique
0
d(hs, q , c , r , ni, f , t ) = hf , q , c , r , ni
Y = R+
—
Validation
—
Vers la simulation des systèmes hybrides
46 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Utilisation des simulations
Programmer une simulation n’est pas si difficile, mais plus difficile de bien
modéliser. Ne pas abuser des simplifications, en particulier lorsque des
activités ont des interactions restant implicites dans le modèle.
Ex. : modélisation de la communication par réseau par des événements
émission et réception, sans égard aux autres communications et à la
congestion éventuelle du réseau.
Couplent évolution continue et par événements discrets.
Principale technique : intégration pas-à-pas pour obtenir une
trajectoire du système continue par morceaux.
Interrompue par le traitement des événements discrets :
des événements se produisant selon leurs processus propres et
traités comme dans la simulation par événements discrets,
des événements générés par l’évolution continue du système
hybride et le franchissement de conditions aux frontières.
Dans le cas des modèles stochastiques, la disponibilité ou l’obtention des
données réelles pour estimer des lois de probabilités justes est souvent l’une
des plus grandes difficultés.
La génération de valeurs aléatoires est aussi cruciale. Évitez les mauvais
générateurs (ceux des bibliothèques standards de langages), préférez ceux des
bibliothèques spécialisées (comme common-math).
Grande difficulté : déterminer avec précision le moment où les
événements générés par l’évolution continue se produisent.
Aucun pas d’intégration t ne peut garantir une précision e
Une simulation sur des modèles pauvres avec des outils pauvres et des
données pauvres donnera des résultats pauvres (garbage in, garbage out...)
donnée sur l’évolution car les dérivées sont non-bornées.
Se fait généralement en deux temps : détection du franchissement
d’une frontière entre ti et ti +1 puis recherche du point de
franchissement précis à e près dans l’intervalle ] ti , ti +1 [.
Une seule exécution d’une simulation stochastique ne veut généralement rien
dire : il faut en faire un grand nombre, selon un plan d’expérimentation bien
défini et analyser scrupuleusement les résultats. L’aide d’un statisticien peut
s’avérer cruciale.
47 / 58
48 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Plan
—
Composition
Contractualisation
Simulation
Validation
—
Formes de simulation pour la validation des systèmes
1
Composition et déploiement
2
Contrats de contrôle
3
Techniques de simulation
La simulation est utilisée dans la validation progressive des systèmes
depuis l’utilisation de modèles purs en phase de conception jusqu’à
l’intégraiton de tout ou partie du système réel en phase finale de
validation :
Model-in-the-loop (MIL) : simulation des
modèles pour valider leur adéquation au
système réel et leur exactitude interne dans
différentes conditions logicielles, matérielles
et d’environnement.
Software-in-the-loop (SIL) : intégration entre
modèles et logiciels pour valider le logiciel
par rapport aux modèles dans différentes
conditions matérielles et d’environnement.
Simulation et validation des systèmes autonomiques
4
Modèle de
contrôle hybride
validation
Logiciel de
l'entité de contrôle
MIL
SIL
Modèle comportemental
hybride
validation
Système réel
Logiciel de
L'entité adaptable
HIL
Matériel informatique
réel
Hardware-in-the-loop (HIL) : intégration
entre modèles, logiciels et matériels dans
différentes conditions d’environnement.
49 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Simulation des grands systèmes
Décomposition des modèles.
Contractualisation
Simulation
Validation
—
Modèle DEVS déterministe atomique M = (X, Y, S, dint , dext , l, ta)
où X est l’ensemble des événements d’entrée, Y l’ensemble des
événements de sortie, S l’espace des états alors que la
dynamique du système est définie par les fonctions :
ta(s) : S ! R+ d’avancement du temps ;
dint (s) : S ! S de transition interne ;
l(s) : S ! Y produit un événement en sortie lors de la transition
Décentralisation des exécutions.
L’exécution conjointe de modèles et de parties réelles des
systèmes imposent une décentralisation, a fortiori pour les grands
systèmes répartis nécessitant de la simulation parallèle et
répartie.
3
Composition
DEVS est une approche de simulation par événements discrets
modulaire parallélisable et répartissable où un modèle est
décomposé en sous-modèles échangeant des événements dits
externes.
Pour être progressivement remplacés, les modèles doivent être
conçus de manière modulaire.
2
—
Modèles de simulation modulaire : DEVS
Cette approche de validation par la simulation impose trois besoins :
décomposition, décentralisation et gestion du temps.
1
50 / 58
Gestion du temps dédiée.
Parce qu’on ne contrôle pas le temps d’exécution des parties
réelles et parce que l’exécution est décentralisée, le temps simulé
doit pouvoir être contrôlé en fonction des formes de simulation.
Les simulations SIL et a fortiori HIL poussent à faire de la
simulation en temps réel.
depuis l’état s ;
définissant le comportement interne du modèle, et la fonction
dext (s, t , x ) : S ⇥ R+ ⇥ X ! S de transition externe appelée
lorsque ta(s) > t produisant un nouvel état s0 .
51 / 58
52 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Modèle DEVS atomique
—
Composition
Contractualisation
Simulation
Validation
Modèle DEVS couplé
s2
Entrée
s2
transition
externe
s1
s2
Entrée
s1
s6
s4
transition
interne
transition
interne
transition
externe
s1
s6
s4
s3
s5
avancement
du temps
transition
interne
s5
avancement
du temps
sortie
Modèle DEVS atomique
s3
s6
s4
s3
transition
externe
—
Modèle DEVS atomique
sortie
Sortie
s5
s2
transition
externe
avancement
du temps
s6
s4
s3
Sortie
sortie
Modèle DEVS atomique
s1
transition
interne
s5
avancement
du temps
Modèle DEVS atomique
sortie
53 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Simulation répartie et temps réel
2
3
—
Composition
Contractualisation
Simulation
Validation
—
Simulabilité des entités autonomiques
L’extension des simulations réparties DEVS aux modèles
hybrides pose des problèmes liés à l’échange de valeurs de
variables continues entre les modèles.
Approches actuelles :
L’exécution répartie de modèles DEVS couplés exige
(normalement) de synchroniser leurs horloges.
Trois approches :
1
54 / 58
synchronisation conservatrice : synchronisation totale de toutes
les horloges.
synchronisation optimiste (time warp) : les horloges avancent à
leur rythme mais si un événement arrivent dans le passé, un
retour général en arrière doit être fait.
aucune synchronisation : laisser les horloges évoluer à leurs
rythmes ce qui prduit des erreurs de simulation.
permettre le parallélisme mono-ordinateur mais pas la répartition ;
utiliser des modèles partitionnés où le partage des valeurs
continues est limité à l’intérieur des partitions, qui elles-mêmes
sont co-localisées.
Pour réaliser facilement les différentes formes de simulation (SIL,
HIL, ...), les composants autonomiques doivent être dotés d’une
capacité d’auto-simulation activée ou non en fonction de l’étape
de validation.
Dans un modèle à composants comme BCM, cela implique
l’intégration des modèles de simulation dans les composants et
l’introduction d’interfaces spécifiques pour les échanges
d’événements et de valeurs continues (lorsque nécessaire).
La synchronisation explicite utilisant des techniques classiques
(barrières cycliques, rendez-vous, ...) est coûteuse.
Techniques implicites fondées sur le temps :
synchronisation par temps réel (accéléré) : utilisation du temps
réel (horloges matérielles synchronisées) pour synchroniser
implicitement les modèles (avec un facteur d’accélération).
55 / 58
56 / 58
—
Composition
Contractualisation
Simulation
Validation
—
Récapitulons...
1
L’entité autonomique est la composition entre une entité adaptable et une
entité de contrôle pour former une entité auto-adaptable.
2
Parmi les activités à conduire lors de la composition et le déploiement des
entités autonomiques, il y a les tests et la validation où la simulation complète
les bouchons fonctionnels classiques par des bouchons comportementaux.
3
En plus de la technique de contrôle utilisée, le choix de la bonne architecture
d’entité de contrôle dépend également des facteurs de déploiement, dont la
nature répartie et les ressources disponibles sur les nœuds pour le contrôle.
4
La composition entre entité de contrôle et entité adaptable peut se formaliser
par un contrat de contrôle spécifiant les objectifs et les méta-propriétés du
contrôle.
5
La répartition sur plusieurs nœuds d’un système de contrôle soulève les
questions de la localité du temps et du caractère aléatoire des délais de
communication, incompatibles avec le contrôle en temps-réel.
6
Les techniques de simulation utilisables pour tester et valider les entités
autonomiques, on trouve principalement la simulation hybride modulaire
répartie en temps réel comme une extension des modèles DEVS de
simulation par événements discrets modulaires.
7
—
Composition
Contractualisation
Simulation
Validation
—
Pour aller plus loin : lectures recommandées
QML : A Language for Quality of Service Specification, S. Frølund
and J. Koistinen, Rapport de recherche HPL-98-10, Software
Technology Laboratory, Hewlett-Packard.
Contracts for Systems Design, A. Benveniste et al., rapport de
recherche INRIA n˚ 8147, novembre 2012, 64 p.
Guide to Modeling and Simulation of Systems of Systems, B.P.
Zeigler et H.S. Sarjoughian, Springer, 2013.
The split system approach to managing time in simulations of
hybrid systems having continuous and discrete event
components, J. Naturo et al., Trans. of the Society for Modeling
and Simulation, 88(3), 2012.
Simulation temps-réel distribuée de modèles numériques :
application au groupe motopropulseur, A. Ben Khaled, INRIA,
thèse de l’U. De Grenoble, 2014.
Pour faciliter les tests et la validation SIL puis HIL, les entités autonomiques
doivent avoir une capacité d’auto-simulation progressivement désactivable.
57 / 58
58 / 58