Choix pour la conception de l'implantation

(voir livre de Braek et al.: "Engineering Real Time Systems", chapitre 9. Ce livre considère le "co-design" : choix de conception du système concernant le matériel ET le logiciel)

1. C'est quoi, la conception de l'implantation

• But: définir une correspondance entre la spécification fonctionnelle et le système implanté (en forme de matériel et logiciel)
• Travail à faire: prendre les décisions nécessaires et les documenter en assez de détail pour définir les propriétés de l'implantation à réaliser
• Résultat: description de la conception de l'implantation qui explique comment les fonctions abstraites sont à réaliser

 La portée de la conception de l'implantation est montrée sur le diagramme suivant:

Exemple du système de contrôle d'accès - Question: "Quelle partie à implanter en matériel, quelle partie en logiciel, quelle forme de logiciel ?"

Les deux diagrammes suivantes montrent (a) le cas simple (on choisit une alternative d'implantation équivalente à la spécification fonctionnelle), et (b) le cas où la conception de l'implantation nous amène à réviser la spécification SDL (appelée "SDL description") pour y inclure des aspects de fonctionnalités qui sont pertinents pour l'implantation ou de l'adapter aux contraintes d'implantation (exigences non fonctionnelles).

Les sous-étapes de la conception de l'implantation

1. Choix ("trade-off") entre matériel et logiciel
2. Définir l'architecture matériel
3. Définir l'architecture logiciel
4. Réviser et raffiner la conception fonctionnelle

2. Aspects ignorés par la spécification fonctionnelle

La différences entre la spécification fonctionnelle et la description de l'implantation à élaborer dans cette phase du génie de systèmes ont deux raisons d'être:

• Les concepts inhérents au langage de description utilisé pour la spécification fonctionnelle ne correspondent pas toujours aux concepts utilisés pour l'implantation des parties correspondantes du système. Il faut donc penser comment ces concepts (par exemple les processus concurrents des machines à états et leur communication par messages) sont à réaliser dans l'implantation. Ceci n'est pas élaboré dans la suite.
• Certains aspects du système à construire, en relation avec les exigences non fonctionnelles, sont souvent ignorés par la spécification fonctionnelle. Ces aspects doivent être considérés lors de la conception de l'implantation, en particulier les aspects suivants:

2.1 Le temps de traitement

• Note: En SDL, le temps d'exécution des transitions et de propagation des messages est ignoré; dans l'implantation, il faut le prendre en considération.
• Les exigences non fonctionnelles mentionnent typiquement les deux aspects suivants:
  • temps de réponse du système (délai entre l'envoi d'une requête et la réception d'une réponse)
  • débit (nombres de requêtes à traiter par seconde)
• Lors de la conception de l'implantation, il faut donc trouver des solutions matérielles / logicielles satisfaisant ces contraintes
• L'interface entre les parties matérielles et logicielles requiert une préoccupation particulière: Le logiciel doit être assez vite pour capter les signaux qui arrivent par les canaux matériels. C'est le rôle des "drivers" (voir les processus IO-Channel dans la figure 10.1 ci-dessous, qui sont des processus concurrents qui s'exécutent dans l'environnement de multiprogrammation fourni par le Concurrency Support du système d'exploitation).
• 
• Estimer la performance de l'implantation planifiée: Il est important d'estimer la performance de l'implantation future avant qu'elle soit construite. Il est aussi important de considérer que la performance d'un système qui supporte plusieurs usagers, le temps de réponse dépend de la charge (débit) du système, c'est-à-dire, plus qu'il y a des requêtes, plus long sera le temps de réponse; lorsque le débit maximum est atteint, le temps de réponse sera complètement dégradé - le système est débordé. Pour obtenir une estimation de la performance du système, on a besoins des trois points suivants:
  • Estimation réaliste de la charge du système: (a) fréquence des requêtes; (b) importance rélative des différents types de requêtes qui pourraient avoir différentes exigences concernant les ressources du système (CPU, accès disque, besoin de communication). Il faut considérer la charge moyenne, aux heures de pointe. Des "benchmarks" sont des scénarios de requêtes qui sont utilisés pour comparer la performance de différents systèmes existants; et pourraient être utilisé pour mesurer la performance d'un prototype.
  • Estimation des ressources requises pour chaque type de requête: Ceci pourrait être une estimation du nombre d'instructions CPU réquises pour exécuter une requête simple; si on connait le cycle d'horloge de l'ordinateur, ceci donne une estimation du temps CPU nécessaire pour exécuter la requête. Ceci pourrait impliquer une estimation du nombre de fois qu'une boucle sera exécutée en moyenne. De telle estimations peuvent aussi être faites à un niveau d'abstraction plus haut: par exemple, estimer le nombre de transitions SDL à exécuter d'après la spécification fonctionnelle, et estimation de temps CPU moyen nécessaire pour exécuter une transition SDL.
  • Méthodes d'estimation de performance quand la charge et les exigences de ressources sont données: Les méthodes suivantes sont souvent utilisées:
    • Raisonnement direct: un exemple est donné dans le livre de Braek et al.:
      • déterminer le nombre de transitions SDL impliquées dans la préparation de la réponse à la requête,
      • estimer le temps CPU requis pour une transition SDL en moyenne,
      • et il faut estimer quel fraction de temps le CPU est alloué à la tâche en question (parmi d'autres tâches concurrentes).
      • Si l'on veut aussi estimer le débit qui peut être offerte par l'implantation, il faut faire cette estimation pour toutes les types de requêtes et estimer la fréquence relative des différentes requêtes.
    • Modèles de file d'attente et modèles de simulation : voir notes de cours ci-haut.
• Note: L'évaluation de la performance d'une conception préliminaire de l'implantation peut aboutir à la proposition d'une nouvelle architecture pour satisfaire les exigences de performance. Un exemple est donné dans le livre de Braek et al.: architecture matérielle initiale, architecture matérielle révisée incluant des unités "Cluster", description en SDL revisée de l'implantation (vue globale, structure de blocs détaillée incluant des blocs fonctionnels pour les protocoles de communication et la validation (banque de données) dans les unités "Cluster").
• Dans le cas d'un système avec des contraintes de temps-réel dures ("hard real-time systems"), il faut garantir que le temps de réponse reste toujours en dessous d'une limite maximum. Il faut alors être plus stricte: au lieu de faire des estimations, il faut démontrer que le temps de réponse reste en dessous de la limite. Cela est beaucoup plus difficile, e.g. la machine virtuelle Java normal n'est plus appropriée comme environnement d'exécution parce que, par exemple, la récupération de mémoire pourrait interrompre l'exécution d'une tâche et ainsi allonger le temps d'exécution d'une durée non déterminée.

2.2 Les imperfections du matériel et logiciel: erreurs, fautes, bruit de fond, etc.

• La spécification fonctionnelle ne considère normalement pas des erreurs de lectures ou d'écriture matérielles, de communication, ou des dommages physiques des composantes dus aux accidents ou au vieillissement. Un cas spécial est qu'une réponse n'arrive pas (à cause d'une perte de message ou à cause d'une panne de l'ordinateur sur lequel le programme serveur s'exécute). - Voici un exemple d'exigences concernant l'impact d'erreurs sur le fonctionnement du système de contrôle d'accès (du livre de Braek et al.)
• Si de telles problèmes sont à prévoir, il faut alors déterminer comment les détecter et quel traitement exceptionnel à prévoir. Dans ce contexte, on distingue les trois actions suivantes:
  • détection de la faute (souvent on utilise aussi le mot "erreur": quelque observation indique une erreur, une situation non conforme à la spécification)
  • isolation de la faute, c'est-à-dire, la localiser, trouver la cause de l'erreur observée
  • récupération de la faute (si possible), c'est-à-dire, faire en sorte que le système réalisera sa tâche spécifiée malgré la présence d'une faute. Dans le cas d'une faute matériel, cela implique ou la réparation ou le remplacement de la composante fautive (ce qui prend du temps), ou du matériel redondant qui prend alors la relève.
    • Note: Dans le cas de systèmes ultra-fiables, on utilise souvent des composantes triples qui exécutent tous les trois la même tâche en parallèle. À la fin de l'opération, une unité de comparaison compare les trois résultats obtenus et s'ils ne sont pas identiques on peut identifier la composante fautive (sous l'hypothèse que seulement une seule composante devient fautive à la fois). On utilise alors de résultats des deux autres composantes (le système est tolérante à une faute simple); et on essaie de remplacer la composante fautive aussitôt que possible (avant qu'une autre composante ne devienne fautive).
• Voici d'autres concepts importants:
  • tolérance aux fautes (voir exemple ci-dessus)
  • résilience aux fautes: Une faute peut avoir un impact, mais les fonctions importantes du systèmes continuent à être offertes.
  • sûreté dans le cas d'une faute ("a fail-safe system"): Dans le cas d'une faute, le comportement du système assure qu'il n'y a pas de "catastrophe", c'est-à-dire, une situation qui ne devrait jamais arriver (comme par exemple l'explosion d'un réacteur nucléaire, ou l'ouverture d'une porte d'un train en mouvement).

2.3 La distribution physique

• Avantages d'une implantation distribuée sur plusieurs ordinateurs:
  • La panne d'un ordinateur n'affecte, n'immobilise pas nécessairement le système au complet. L'isolation de la faute est possible.
  • Augmentation du débit du système (en faisant du traitement parallèle).
• Désavantages:
  • Communication entre ordinateurs implique des délais supplémentaires.
  • Des protocoles de communication sont nécessaires pour récupérer les erreurs de transmission et autres problèmes de communication.

2.4 Les ressources limitées

• Dans l'implantation les ressources sont limitées. Par exemple: nombre de processus dans un ordinateur, espace mémoire disponible, longueur maximum de tampons pour la réception de messages.
• Note: Des tampons de longueur limitée peuvent facilement donner lieu à des blocages (quand un producteur ne peut pas envoyer son message parce que la file de réception est plaine); il faut être vigilant lors de la conception de systèmes de communication par messages.

2.5 Autres choix 

• La sécurité
• Les exigences concernant l'opération du système et sa maintenance
• Les coûts de développement et de production matériel
  • Note: Le coût de développement existe une fois; le coût de production matériel dépend du nombre d'unités à construire.
• La réutilisation de composantes existantes
  • Cela implique que la fonctionnalité de la composante existante ne devrait pas être dupliquée par les parties nouvelles à construire.
  • Cela implique aussi que les parties nouvelles à construire devraient prévoir des interfaces appropriés pour la communication avec les composantes existantes

L'exemple de l'application de ces considérations d'implantation au système de contrôle d'accès est discuté dans le livre de Braek et al. (voir section  9.4).

Note: Le livre de Braek et al. utilise certaines notations graphiques pour décrire les architectures matérielles et logicielles. Ces notations ne sont pas généralement acceptées dans la communauté; vous n'avez pas besoin de les apprendre.

Initialement écrit: 22 mars 2003; revisions: 2004; 2011; mars 2015