Eléments de spécification des systèmes temps réel

Eléments de spécification
des systèmes temps réel
Pierre-Yves Duval (cppm)
Ecole d’informatique temps réel - La Londes les Maures 7-11 Octobre 2002
- Evénements et architectures
- Spécifications de performances
- Spécification de composabilité
- Spécifications relatives a la sûreté de fonctionnement
- Spécifications relatives aux tests et diagnostiques
- Classes de systèmes temps réel
- Phases d’un projet en informatique temps réel
- Systèmes temps réel repartis
1
Spécification des événements
Lois
d’arrivée
Description
périodique
Arrivent à intervalle constant. On y associe parfois la
notion de phase pour donner la position relative dans le
temps par rapport à d’autres événements périodiques
irrégulier
Cycle d’arrivées connu à l’avance et qui se reproduit
cycliquement
bornée
Arrivent n’importe quand mais avec un intervalle
minimum entre deux occurrences
en rafale
Arrive par paquet imprévisibles mais avec une densité
maximum dans un intervalle
non bornée
La loi arrivée est décrite par une loi de probabilité
Prise en compte des événements
Scrutation (polling)
Le système prend l’initiative d’activer la fonction qui va lire une
entrée à un instant qui est programmé pour vérifier si un événement
a eu lieu. Le plus souvent cette scrutation sera faite périodiquement.
Sous interruption
Un signal hardware associe à l’arrive de l’événement déclenche
l’activation de la fonction qui va lire la donnée d’entrée.
2
Architectures des systèmes TR
L’interaction avec le monde externe induit deux types d’architectures
Systèmes séquencés par événements (système asynchrones)
Ces systèmes sont activés par des événements externes. Ils attendent les
sollicitations et réagissent à celles-ci
Systèmes séquencés par le temps (systèmes synchrones)
Dans ces systèmes il n’y a qu’une source d’événement, l’horloge. Ils
sont programmés pour exécuter leurs actions à des instants bien précis
qui restent immuables dans un mode de fonctionnement donné.
Spécification de performances
Latence du système
C’est le délai global de bout en bout entre un changement d’état dans
environnement et la réaction correspondante en sortie du système.
C’est un délai composite qui prend en compte:
-les délais de scrutation du système
-les délais dû à l’OS
-les délais de calcul applicatif
-les délais de transmission de message
3
Délais intervenant dans la latence d’une fonction simple
Production
de la sortie
Calcul de
la réponse
échantillonnage
A
B
Changement
d’état
1
2
C
Latence du système
3
4
5
6
7
8
9 10 11 12
Temps CPU utile
Temps d’attente
Temps dans la couche réseau
action
Spécification de performances
Gigue sur la latence:
Elle décrit l’incertitude sur la latence.
Liée à la concurrence qui va faire varier la charge du réseau
(problème d’accès) ou des nœuds de calcul (ordonnancement).
Dans les applications de contrôle il est souhaitable que cette gigue soit
faible devant la latence. Dans les applications rapides elle doit donc être très faible
Gigue
Transaction 1
Transaction 2
Transaction 3
Latence moyenne
4
Spécification de composabilité
Définition:
La composabilité (composability) est la propriété qui fait qu’une
caractéristique qui existe dans un composant du système pris
isolement se retrouve comme propriété inchangée dans le système
tout assemblé.
On dit aussi que l’assemblage des composants est dénué d’effet
de bord ou d’échelle.
Spécifications relatives à la
sûreté de fonctionnement
délai de détection des erreurs:
Dans un système critique on cherchera à ce qu'il soit minimum.
De l'ordre de grandeur de la boucle de contrôle la plus courte,
pour pouvoir réagir assez vite et mettre le système dans un état
sûr de fonctionnement (éviter les divergences).
5
Spécifications relatives à la
sûreté de fonctionnement
tolérance aux fautes:
Une application critique doit avoir un comportement du type
FO->FS (fail operational->fail safe). Il doit y avoir continuité
de fonctionnement tant qu'un certain nombre de défaillances
n'est pas atteint.
Ensuite lorsque la limite de capacité à assumer une
défaillance de plus est atteinte, le système doit s'arrêter de
façon sûre.
Spécification relatives aux tests
et diagnostiques
Cet aspect est capital dans un projet!! car les défaillances sont
souvent difficiles à reproduire
Un SITR doit avoir les propriétés suivantes:
- testabilité d'intégration,
- disposer de points de mesures utilisables en intégration ou
en fonctionnement pour injecter des séquences de tests,
- disposer d'outils pour superviser le trafic en fonctionnement,
- d'avoir la possibilité de mémoriser et restituer l'état
d'exécution d'un noeud (trace des valeurs datées).
6
Classes de systèmes temps réel
Systèmes à contraintes dures/strictes (hard real time, guaranteed)
Spécifications de temps doivent être réalises dans 100% des cas.
Spécifications très précises et exhaustives
(exemple: contrôle de central nucléaire, pilote automatique d’avion …)
- validation formelle en amont (mathématique si possible)
- tests exhaustifs en aval
Toute modification devra repasser par un cycle de validation amont et aval
avant d’être intégrée au système opérationnel.
Systèmes plutôt chers et difficiles à faire évoluer.
Régularité et le déterminisme au dépend de l’optimisation des ressources.
Classes de systèmes temps réel
Systèmes à contraintes souples (soft real time, best effort)
Spécifications de temps doivent être atteintes mais des erreurs rares sont
tolérables.
Spécifications définissent statistiquement les taux d’erreurs acceptables
(exemple: multimédia, DAQ en physique des particules …)
- conception aidée par de la simulation sur un modèle exécutable
- tests par exécution et mesures dans la durée des paramètres clefs
Les modifications peuvent être intégrées pour voir et validées en ligne.
Systèmes plus faciles à faire évoluer et permettant les compromis qui
conduisent à une optimisation des ressources.
7
Classes de systèmes temps réel
Systèmes temps réel critiques
Terminologie qui met l’accent sur les conséquences d’une défaillance
du système et concerne la sûreté de fonctionnement.
On dira qu’un système temps réel est critique si:
- il y a des conséquences humaines en cas de défaillance
- si le coût financier d’une défaillance du système est d’ordre supérieur
à celui du système
Phases d’un projet TR
Méthodologies classiques car c’est un système informatique,
AVEC quelques aspects spécifiques
Spécification:
- importance du contexte qui stimule le système et de la
caractérisation de cette stimulation (types d’événements)
- en plus des fonctions on trouvera leurs contraintes temporelles
- indication de la criticités des fonctions
- des contraintes liées au hardware à utiliser
- contraintes géographiques et de répartition
- caractérisation de l’environnement
8
Phases d’un projet TR
Conception générale et architecturale:
- choix des unités logiques et d’une architecture logique
- le système est décomposé en sous-systèmes
- un sous-système particulier sera identifié pour l’encapsulation
des fonctions assurées par le matériel (hardware wrapper)
(doit assurer indépendance matériel/logiciel)
Phases d’un projet TR
Analyse et réalisation:
- la description de la dynamique et du comportement (états, transitions
et modes de fonctionnement associés) plus développés et fils directeur
- boucle pour réajuster les hypothèses temporelles optimistes
En phase de conception détaillée:
- découpage en tâches (analyse des événements externes et de leur fils
de traitement)
- hypothèse/allocation concernant les temps d’exécution (prototypage)
- choix des modes de communication et de synchronisation entre tâches
- validation formelle en cas pire pour les tâches critiques
9
Phases d’un projet TR
Intégration:
-en plus des tests fonctionnels prévoir les tests de performances réelles
et l’évaluation des effets d’intégration sur les performances temporelles
(influence des différents composants sur la charge du système).
-pour un système stricte mesurer et caractériser précisément chaque
composant
Validation:
-peut se faire sur site, en exploitation, pendant une période considérée
comme probatoire d’un point de vue statistique pour un système souple.
-longue période de passage de tests systématiques (procédures strictes) et
mise en exploitation progressive pour un système critique
Système temps réel reparti
Configuration matérielle
noeud
noeud
Nœuds de
traitement
noeud
noeud
Réseau temps réel
noeud
Nœuds d’interface
Capteurs/actionneurs
noeud
Capteurs/actionneurs
10
Système temps réel reparti
Variables du système
échantillonnage
ITR
ITR
Objet TR
Image TR
Transmissions
Variable locale
Variable réelle= entité temps réel ETR
Valeur informatique = image temps réel ITR
Valeur diffusée et conservée dans des objets temps réel
ITR
ITR
Objet TR
Système temps réel reparti
Variables du système
Déterminisme de duplication (réplica determinism)
C'est une relation entre OTR répliqués.
Un ensemble d‘OTR répliqués est dit déterministe si
tous les OTR atteignent le même état "à peu près" au
même moment.
"à peu près" prend en compte la précision de la
synchronisation d'horloge dans un système TR
réparti.
11
Système temps réel reparti
Variables du système
Précision temporelle des variables du système
décalage maxi entre état d’une entité du monde réel et son image
dans un objet temps réel du système.
Stabilité
Définit la relation entre un message Mi qui arrive à un OTR et les
Mi-1, Mi-2 ,... messages précédents qui lui ont été envoyés
auparavant (dans le temps global du système).
Mi devient stable dès que tous les messages précédents sont arrivés.
Une décision prise sur un message instable peut être source
d'incohérence.
Système temps réel réparti
Variables du système
Stabilité
Définit la relation entre un message Mi qui arrive à un OTR et les
Mi-1, Mi-2 ,... messages précédents qui lui ont été envoyés
auparavant (dans le temps global du système).
Mi devient stable dès que tous les messages précédents sont arrivés.
Une décision prise sur un message instable peut être source d'incohérence.
Délai d’action
Le délai d'action est le temps qui s'écoule entre l'envoi d'un message
et le moment où il est considéré comme stable pour son récepteur et donc
qu’il peut l’exploiter ou le publier localement.
12
Système temps réel réparti
Variables du système
Dans un système TR réparti sans base de temps globale,
le délai d'action maximum est
dmax + e (temps transmission maximum + attente stabilité)
avec e = dmax - dmin (gigue sur le protocole)
Dans un système synchronisé avec une base de temps globale
de précision (granularité) g le délai d'action maximum est:
dmax + 2g (2g est l'incertitude sur les dates)
Si cette synchro est réalisée par matériel g peut être très faible
Système temps réel réparti
Variables du système
Théorème
Un système temps réel distribuée ne peut fonctionner correctement
que si le délai d’action est plus court que les précisions temporelles
requises par l’application.
13