Systèmes en temps réel Sujets divers. Sujets divers - 2 Synopsis Services dexceptions Encore plus sur les services de chrono Cardinalité et structure.

Présentation au sujet: "Systèmes en temps réel Sujets divers. Sujets divers - 2 Synopsis Services dexceptions Encore plus sur les services de chrono Cardinalité et structure."— Transcription de la présentation:

1 Systèmes en temps réel Sujets divers

2 Sujets divers - 2 Synopsis Services dexceptions Encore plus sur les services de chrono Cardinalité et structure de capsule

3 Sujets divers - 3 Services dexceptions Comme nous allons voir dans les semaines qui viennent, la tolérance en défaillance est un requis critique de la majorité des systèmes en temps réel; le traitement des exceptions devient alors un aspect très important de design Les Services dexceptions de RoseRT fournit un concept de ports dException (système) avec lequel les capsules peuvent lever et traiter les signaux dexception (RTExceptionSignal)

4 Sujets divers - 4 Services dexceptions (2) Les ports dexceptions sont de type Exception Les signaux dexceptions sont de type RTExceptionSignal RTExceptionSignal méthodes: raise( ); {exceptions doivent être levées par lapplication} Signaux dexceptions définis: userError(une valeur RTTyped définit par lutilisateur); arithmaticError( … ); error(…); notFoundError( … ); notUnderstoodError( … ); serviceAccessError( … ); streamError( … ); subclassResponsibilityError( … ); timesliceError( … );

5 Sujets divers - 5 Services dexceptions (3) exemple // en entrée dans létat deliver // lève une erreur si lenregistrement SAP plante if ( robotPort.registerSAP(deliveryService) != 1 ) { errorPort.serviceAccessError(ne peut pas connecter au service de livraison).raise( ); } // dans la transition à létat Error RTString eMessage = *(RTString *)getMsg()->getData(); char *eMessage = (char *)getMsg()->getData(); eLog.log(eMessage);

6 Sujets divers - 6 Encore plus sur les services de chrono Un autre aspect critique dans le design des systèmes en temps réel est la capacité de modéliser linformation temporelle Lapproche événementielle et centré sur les machines détats utilisée en RT-UML supporte bien la modélisation des événements ordonnancés temporellement, Cependant, pour modéliser les événements chronologiques ou périodiques (communément retrouvés dans les STR), nous avons besoin dun autre ensemble de services – Les services de chrono

7 Sujets divers - 7 Encore plus sur les services de chrono (2) Les services de chrono fournissent les fonctions de chrono relatif ou absolu Le type RTTimespec fournit une façon de spécifier des variables de temps en secondes (ou nsecs) Les ports chronos fournissent un mécanisme pour régler/canceller des chronos pour les capsules et daccéder le temps de système méthodes: informIn( ), informEvery( ), informAt( ), cancelTimer( RTTimerID), currentTime( ) Le type RTTimerID fournit une façon didentifier des actions de ports chronos spécifiques

8 Sujets divers - 8 Encore plus sur les services de chrono (3) exemple // règle un chrono périodique en entrant létat Operate // note: RTTimerID perTID est définit sur la capsule RTTimespec updatePeriod(0, 750000000); perTID = perTimerPort.informEvery(updatePeriod); // canceller le chrono entrant létat Shutdown if ( perTimerPort.cancelTimer(perTID) != 1 ) {systemErrorPort.userError(erreur de cancellation chrono).raise( ); }

9 Sujets divers - 9 Encore plus sur les services de chrono (4) Un autre exemple // note: ce qui suit donne une erreur commune // à lexécution (mauvaise priorité sur un port chrono) someTimerPort.informIn(3, 500000000); // informIn est une méthode surchargé //où dans la signature suivante, prio est optionnel Timing::informIn( RTTimespec, [int prio]); // et ce que vous vouliez était probablement: someTimerPort.informIn(RTTimespec(3, 500000000));

10 Sujets divers - 10 Cardinalité et Structure de Capsule cardinalité sur les rôles de capsule fixe : définit le nombre de rôles de capsule répliqué pour créer lors de la création de la capsule contenant optionnel / plug-in : définit le nombre de rôles de capsule maximum qui peuvent être créés dynamiquement par la capsule contenant cardinalité sur ports détermine le nombre dinstances dun port requis pour permettre les connections avec les rôles de capsule répliqués chaque port répliqué partage un protocole commun

11 Sujets divers - 11 Cardinalité et Structure de Capsule - Patterns structurels communs Étoile 2 2 2

12 Sujets divers - 12 Cardinalité et Structure de Capsule - Patterns structurels communs (2) Bus 22

13 Sujets divers - 13 Cardinalité et Structure de Capsule - Patterns structurels communs (3) Tableau 2 2

14 Sujets divers - 14 Cardinalité et Structure de Capsule - Patterns structurels communs (4) Combinaison 3 3 2 3 3 2

15 Sujets divers - 15 Exercice Divers Modifiez le diagramme de structure de Production Line pour supporter les requis suivants: deux lignes de productions ou plus ont été ajoutées chaque ligne de production est équipée avec 5 Workstations identiques capable de produire des widgets a. initialement 3 Robots sont disponibles, un pour chaque ligne de production b. plus tard, un 4ième Robot devient disponible et le gestionnaire décide quil est mieux quils soient vues comme faisant partie à la manufacture entière et sont donc partagés par toutes les lignes de production.