1. RTME-SL
Real Time Meta Event
Specification Language
Vincenzo Caruso
DEA - Informatique Fondamental et Applications
6/20/05 1

2. Systèmes Asynchrones
La plupart des applications temps réel ont

des fortes interactions avec le monde réel.
Le monde réel peut-être modelé par un

système asynchrone
Chaque framework conçu par le temps réel

doit présenter un système pour la gestion
des événement asynchrones

3. Asynchrony in RT-Java
RTSJ (Real Time Specification for Java)

contient depuis son lancement:
une implémentation pour le modèle à événement

ATC (Asynchronous Transfer of Control)

ATT (Asynchronous Thread Termination)

Ils sont conçu comme une généralisation du

modèle traditionnel de Java
Introduction des contraintes temporelles


4. Modèle à événement de RTSJ
javax.realtime.AsyncEvent

 Représente la possibilité de déclanchement pour un
événement asynchrone
javax.realtime.AsyncEventHandler

 Représente l’action à prendre lors qu’un événement est
déclanché
Enregistrement

addHandler(AsyncEventHandler) sur une instance

de AsyncEvent
any-to-any

Déclanchement

fire() sur une instance de AsyncEvent

schedulation des handlers associés


5. Modèle à événement de RTSJ

6. Handlers & Threads
L’handler encapsule une action

Il n’est pas une sous-classe de RealtimeThread!

...mais il a son comportement

En fait il implante Schedulable et Runnable

Il accepte des ReleaseParameters,

ScheduleParameters et MemoryParameters
Il est lié dynamiquement à un RealtimeThread par

le support à runtime
On évite de surcharger inutilement le scheduler par des

threads que on ne sait pas quand ils seront activés

7. Handlers & Threads (2)
Ce mécanisme ajoute un retard d’activation

variable
Si on ne peut pas tolérer cette pénalité

BoundAsyncEventHandler

L’handler a un RealtimeThread dédié dans lequel

il est exécuté
On l’utilise pour avoir une réponse immédiate à

l’événement
Souvent on lui donne une priorité très haute


8. Meta Evénement
On veut identifier et contrôler des situations

caractérisées par une séquence
d’événement
Cette séquence doit être exprimable par un

modèle rational, donc par un langage
On propose une description des séquences

basée sur les expression logiques

9. Meta Evénement
Un méta-événement est un AsyncEvent qui est

déclanché lors de la vérification de l’expression
logique qui décrive lui même
Deux entité sont toujours associées à un méta-

événement:
SUPPLIERS

 instances de AsyncEvent
 événements de base, utilisés pour décrire la condition de
déclanchement du méta-événement
CONSUMERS

 instances de AsyncEventHandler
 schedulés lors de la validation de la condition de
déclanchement

10. Proxy?
Le méta-événement peut être considéré

comme un proxy entre les suppliers
(AsyncEvents) et les consumers
(AsyncEventHandlers)
Mais il n’est pas un proxy « pure » !

Il a un état interne qui dépende des signaux en

entrée
Il active les suppliers lors de la détection d’une

bonne séquence des signaux en entrée

11. L’architecture

12. Un exemple
Scenario:

Un système de schedulation pour des taches real-

time
Le scheduler nous offre des événement pour

signaler les dépassement de coût et d'échéance
pour chaque tache
CostOverRunEvent, DeadLineMissedEvent

On veut réaliser un système pour la prévention

des fautes

13. Un exemple (2)
Trois taches, en ordre de priorité

t1, t2, t3

On a étudié le système et on a vu que

(statistiquement):
trois dépassements de coût par t3 ou deux par t2 amènent

à un dépassement d'échéance
deux dépassement d’échéance par t3 suivis par un de t2

amènent à un dépassement d’échéance par t1
On veut contrôler ces situations à l’aide des méta

événements

14. Un exemple (3)
On veut utiliser des meta-événements pour

contrôler et prévoir des crashes
CostOverrunMetaEvent

Dans son handler

Deschedulation des threads t2 et t3

Augmentation des leurs coûts

Reschedulation

DeadLineMissedMetaEvent

Dans son handler

Incrément de la deadline pour t2 et t3


15. Le langage
package rtme.test;
directives
import custom.events.*;
Suppliers {CostOverRun, DeadLineMissed};
déclarations
Consumers {COHandler, DLMHandler};
MetaEvents {CostOverRunMetaEvent, DeadLineMissedMetaEvent};
MetaEvent CostOverRunMetaEvent {
Suppliers CostOverRun co1, CostOverRun co2;
Consumers COHandler coh1;
EventCondition (( co3 TIMES 3 ) OR ( co2 TIMES 2 ));
};
définitions
MetaEvent DeadLineMissedMetaEvent {
Suppliers DeadLineMissed dl1, DeadLineMissed dl2;
Consumers DLMHandler dlmh1;
EventCondition (( dm3 TIMES 2 ) THEN dm2 ));
};
la grammaire complète est consultable sur le site du projet: http://www.linux.it/~vcaruso/RTME-SL

16. La compilation
On a plusieurs options qui caractérisant le comportement du

compilateur:
--parse-only

fait seulement le check syntactique

--generate-skeletons

engendre les classes (vides) pour suppliers et consumers

--output-dir [path]

dit où seront placés les fichiers engedrés

--use-bounds

utilise BoundAsyncEvents plutôt que AsyncEvents (nécessaire pour jRate)

--debug

mode « verbose »

--mesure

place des balises pour faire des mesures (exp.)

On compile l’exemple avec:

java -jar RTME.jar --generate-skeletons --use-bounds

exemple.mes
Et on obtient...


17. La compilation (2)
Chaque méta-événement

prend comme paramètres:
Les références aux

suppliers:
 instances de
AsyncEvent
Les références aux

consumers:
 instances de
AsyncEventHandler
Dans le méta-evenement:

Un AsyncEventHandler

pour chaque supplier
Un AsyncEvent auquel on

attache les consumers
Le système de détection de

sequence

18. Méta Evénement - la structure
interne

19. Définir les séquences
Les opérateurs sont:

AND

 s1 AND s2 valide avec {s1,s2} ou {s2,s1}
OR

 s1 OR s2 valide avec {s1} ou {s2}
THEN

 s1 THEN s2 valide avec {s1,s2} [introduit une relation
temporelle entre les signaux]
TIMES

 s1 TIMES 4 valide avec la répétition {s1,s1,s1,s1}
Bien sur on peut combiner les effets

( ( (s1 OR s2) AND s3 ) THEN s4) TIMES 4

Une séquence valide est {s1, s3, s4, s2, s3, s4, s3, s1, s4, s3, s1, s4}


20. Le détecteur des séquences
En gros, il peut être considéré comme un lexer, où

les tokens sont les signaux (événements)
Deux possibilité de réalisation:

approche classique: table des transitions

 PROs:
temps d'exécution constant

CONs:

non scalable, difficile ajouter nouveaux éléments, explosion des

états
notre approche: simulation d’une réseau logique


21. Deux possibilitées

22. L’approche « dynamique »
Chaque nœud de l’APT est représenté par le

détecteur correspondant
L’expression est modélisée comme une réseau

logique
Communication par événement entre gates

package org.sorbet.realtime.rtme.detectors

GATES: AndDetector, OrDetector, ThenDetector,

TimesDetector
Supplier’s handler: SignalDetector

Il est aussi un AsyncEventHandler (BoundAsyncEventHandler)

Final Gate: GlobalDetector

Il est aussi un AsyncEvent (auquel on attache les consumers)


23. Hierachie des détecteurs

24. Exemple d’implantation
public void handle (IDetector source) {
/* if the source is not registered, return */
if (!_sources.contains(source))
return;
/* turns off the connection */
source.disconnect();
/* records the event
* (_state is initialized to n in the constructor)
*/
_state--;
/* verifies fire condition */
if (_state==0) {
/* fire up the event */
this.fire();
/* reconnects inputs */
this.reconnect();
}
}

25. Dans la classe engendrée
Pour créer le détecteur de:

 (((s1 AND s2) OR s3) THEN s3 ) TIMES 4
/* creation of the global external event */
_globalDetector = new GlobalDetector(new AsyncEventHandler[] {c1});
/* creation of internal interconnections */
IDetector detector_0 = new TimesDetector(_globalDetector, 4);
IDetector detector_1 = new ThenDetector(detector_0);
IDetector detector_2 = new OrDetector(detector_1);
IDetector detector_3 = new AndDetector(detector_2, 2);
IDetector s1Handler_4 = new SignalDetector(s1, detector_3);
IDetector s2Handler_5 = new SignalDetector(s2, detector_3);
IDetector s3Handler_6 = new SignalDetector(s3, detector_2);
IDetector s3Handler_7 = new SignalDetector(s3, detector_1);

26. Prochainement
Nouveaux opérateurs

Possibilité d'intégrer directement du code Java

dans la définition de méta événement
Amélioration des performances

Création d’une nouvelle construction dans le

langage qui permet la construction d’une table de
transition avec AsyncEvents as inputs
ex: CurrentState -- Event -- NextState -- Action


27. Conclusions
Notre but est de séparer, dans l'ingénierie

des systèmes temps réel, la partie qui
concerne la logique de l’application e la
partie qui gère les événements asynchrones
Pour participer:

http://www.linux.it/~vcaruso/RTME

téléchargement des sources et de la

documentation
package pour le testing
