Entités dont l’exécution a une Contrainte "Périodique"

Règle 6:

Des Atomes non couplés temporellement (i.e. non reliés par un lien de couplage) ne pourront pas faire partie du même module même s’ils ont la même période d’exé- cution.

En effet, le fait qu’ils soient découplés temporellement signifie qu’il y a une forte probabilité qu’ils n’aient pas la même période d’exécution dans certaines applications. Or, un module ne pouvant avoir qu’une seule période d’exécution, celle du schéma auquel il appartient, il faut donc les placer dans des modules différents.

Règle 7:

Deux Atomes dont l’un serait situé en amont d’un groupe d’Atomes appartenant à un module et l’autre serait situé en aval de ce même groupe d’Atomes, comme illustré Figure 7.5, ne peuvent pas faire partie du même module.

Figure 7.5 – Illustration de la Règle 7

Ce choix s’explique par le fait que, si l’on regroupe les Atomes A et D dans le même module, alors D s’exécutera forcément immédiatement après A et les contraintes de précédence qui imposent l’ordre A,B,C,D ne pourront plus être respectées.

7.2. Règles de projection

Règle 8:

Des modules s’exécutant à la même période appartiendront au même schéma même si les Instances qu’ils contiennent ne sont pas couplées temporellement.

A l’origine, les modules contenant des Instances indépendantes temporellement devaient être placés dans des schémas différents pour offrir une plus grande modularité dans les change- ments de période. Néanmoins, comme à ce stade nous ne pouvons pas ordonnancer les schémas entre eux avec ContrACT, cela entraîne un non respect des Contraintes de précédence et cette solution n’a donc pas été retenue.

7.2.5

Alternatives

Règle 9:

Les Atomes appartenant à une Alternative seront toujours mis dans des modules sé- parés des Atomes externes à l’Alternative.

Originellement, vu que les Alternatives permettent de sélectionner les Atomes utilisés en fonction de la situation, il était prévu que les Atomes contenus dans les différentes entités substituables d’une Alternative appartiennent à des schémas dédiés afin de permettre leur substitution à l’exécution par un arrêt/lancement de schémas. Néanmoins, comme il est à ce stade impossible de faire porter des contraintes de précédence entre schémas, nous perdons alors le déterminisme dans l’ordonnancement. De fait, nous nous sommes limités à des chan- gements de modules, ce qui oblige à repenser la manière de gérer les commutations.

Règle 10:

Au sein d’une Alternative, en plus de l’application des règles précédentes (Règles 1 à 6), il faut noter qu’un Atome appartenant à une des entités substituables ne pourra pas être mis dans le même module qu’un Atome appartenant à une autre entité substituable. Par contre si plusieurs Atomes se retrouvent entre différentes entités substituables, il pourront être mis (en accord avec les Règles 1 à 6) dans le même module.

La Figure 7.6 illustre cette Règle au travers d’un exemple théorique.

Ainsi on voit que les Atomes B et C sont tous deux utilisés par les entités E1, E2 et E3

et peuvent dès lors être regroupés au sein du même module. Les Atomes D et E sont utilisés tous deux dans E1 et E2 donc peuvent être regroupés dans le même module mais ne peuvent

Figure 7.6 – Exemple de répartition des Atomes dans les modules au sein d’une Alternative

utilisés dans E3 et seulement dans E3 et peuvent être regroupés dans le même module. Enfin,

les Atomes A, F et G ne peuvent se trouver que dans des modules distincts.

Le traitement du mécanisme de commutation dépend de la complexité de l’Alternative, c’est-à-dire de l’importance des changements à effectuer et du nombre de modules impactés. Nous distinguons trois niveaux de complexité :

– Alternative locale : traduit l’application de modifications très localisées sur la Composi- tion. Dans la grande majorité des cas, toutes les Entités Composables de jonction de cette Alternative seront l’Atome V ide (i.e. pas d’actions spécifiques à exécuter à la commu- tation). Cette alternative ne va concerner qu’un module ou même que certaines entités utilisées dans ce module.

– Alternative partielle : traduit une modification d’une partie d’une fonctionnalité (activa- tion d’une partie de la fonctionnalité après son initialisation, changement de la manière de réaliser une fonctionnalité). Elle va généralement concerner la commutation d’un petit nombre de modules appartenant au même schéma. Ces changements seront induits par l’état du système (par exemple une valeur d’un capteur).

– Alternative globale : traduit un remplacement d’une ou plusieurs fonctionnalités qui en- traîne une restructuration d’une grande partie de la Composition (par exemple, passage de la téléopération du cap du robot à l’asservissement de ce même cap comme décrit à l’Exemple 5.8). Elle peut concerner un nombre important de modules et peut même af- fecter plusieurs schémas. Il s’agit en outre souvent de changements en partie contrôlables par l’utilisateur.

7.2. Règles de projection

Règle 11:

Une Alternative locale sera mise en œuvre sous la forme d’une instruction condition- nelle portant sur l’Entité Composable de sélection qui sera de fait intégrée directement au module dans lequel est mise en œuvre l’Alternative.

Règle 12:

Une Alternative partielle sera mise en œuvre via un envoi de paramètres au module qui seront utilisés dans une instruction conditionnelle et les Entités Composables de jonction seront effectuées directement au sein du module dans lequel est mise en œuvre l’Alternative.

Règle 13:

Une Alternative globale sera mise en œuvre sous la forme d’un changement de sché- mas. Les Entités Composables de jonction pourront soit être activées directement dans le ou les modules contenant l’entité substituable via un paramètre fixé par le superviseur (cas où elles sont peu nombreuses), soit utilisées directement par le superviseur ou un module asynchrone manipulé par ce dernier puis le résultat sera transmis sous forme de paramètres aux modules concernés.

Il est à noter qu’originellement les Alternatives partielles devaient être implémentées de la même manière que les Alternatives globales. Néanmoins, comme cela a été souligné pour la Règle 7, nous avons parfois dû regrouper des modules dans des mêmes schémas afin d’avoir de meilleures garanties sur le déterminisme de notre application. De fait, les changements relativement localisés de ce type d’Alternative engendraient malgré tout une commutation de schémas sur une grande partie de l’application d’où un coût temporel important pour la commutation, coût incompatible avec des modifications de fonctionnalité demandées par le contrôleur et nécessitant, souvent, une réponse rapide pour préserver la réactivité du contrôle. Nous avons donc dû adopter une solution "dégradée" mais les évolutions envisagées du Midd- leware ContrACT, notamment sur l’exécution des schémas, nous permettront de résoudre ces problèmes et d’unifier les mécanismes d’implémentation des deux approches.

7.2.6

Liens

Ici, nous traitons naturellement des Liens qui sont effectués entre des entités situées dans des modules différents.

Règle 14:

Les Liens vers des Besoins avec des Contraintes de nature P ´eriodique ou Coupl´e seront mis en œuvre sous forme de flux de données.

Ces Liens relient des Atomes s’exécutant de manière périodique, qui sont donc contenus dans des modules synchrones et liés entre eux par des flux de données.

Règle 15:

Les Liens entre un Atome dont la Physique a une Contrainte de nature Sporadique et un Besoin de nature Sporadique seront mis en œuvre différemment suivant le type de module destination et le type de module source. Les différents cas sont présentés dans le Tableau 7.1

Tableau 7.1 – Types de liaisons intermodules utilisées pour mettre en œuvre des Liens de nature Sporadique ❵ ❵ ❵ ❵ ❵ ❵ ❵ ❵ ❵ ❵ ❵ ❵ ❵ ❵ ❵ ❵ ❵ ❵ ❵❵ Module source Module cible

Module synchrone Module asynchrone Module synchrone

(Règle 2) Flux de données Flux d’évènements Module asynchrone

(Règle 3)

Envoi d’un évènement à un superviseur puis fixation de paramètre(s)

Flux d’évènements

Si les trois autres cas sont triviaux, le fait de créer un lien depuis un module asynchrone vers un module synchrone est plus intéressant. En effet, les modules asynchrones ne peuvent qu’envoyer des évènements. Par contre, de par leur définition dans ContrACT, les modules synchrones ne peuvent pas recevoir d’évènements. Dès lors, une connexion directe est impos- sible. De fait, la seule solution est de passer par un superviseur qui va servir de relais. Le module asynchrone va transmettre un évènement au superviseur. Ce dernier, en retour, va venir fixer un (ou plusieurs) paramètre(s) du module synchrone permettant ainsi de mettre à jour la donnée de manière sporadique. Cette procédure est schématisée à la Figure 7.7.

7.2. Règles de projection