Conception conjointe commande/ordonnancement et ordonnancement régulé

Pour bénéficier des avantages de la commande fermée le contrôleur doit être correctement conçu, réalisé et paramétré. En revanche, une mauvaise conception peut entraîner une déstabilisation du système et un risque de divergence encore plus rapide qu'en boucle ouverte. Les divers aspects concernant l'algorithmique de commande et l'implémentation du contrôleur doivent être idéalement pris en compte simultanément pour tirer tous les bénéfices de l'approche boucle fermée.

Les systèmes de commande en boucle fermée sont pour la plupart périodiques, les entrées (lecture de capteurs), les calculs de commandes et les sorties (envoi de commandes aux actionneurs) sont effectués à une période unique et constante. Cependant, bien que la théorie classique de la commande des systèmes numérique repose sur l'utilisation d'un échantillonnage à période unique fixe, il a été mis en évidence, e.g. [3], que la réalisation d'un contrôleur sous forme multi-tâches et multi-cadences permet d'en améliorer les performances, même dans le cas de systèmes linéaires simples [4]. En effet, certaines parties d'un algorithme de commande (par exemple la mise à jour de paramètres) peuvent être moins urgentes à calculer que l'élaboration de la commande des modes rapides du système : leur calcul peut être sans dommage décalé dans le temps ou être exécuté à une cadence plus lente. En fait un système complexe est constitués de sous-ensembles aux dynamiques différentes devant être exécutées, puis coordonnées, en fonction de leurs caractéristiques temporelles respectives [44].

Ces diverses activités partagent un support d'exécution de capacité bornée en devant respecter des contraintes temps réel spécifiées sous la forme d'échéances temporelles à respecter. Le respect de ces échéances peut être strict (tout dépassement est interdit) ou lâche (les commandes périodiques peuvent tolérer sans dommage des variations autour de valeurs nominales de périodes et de latences). On peut aussi graduer une contrainte stricte et définir des systèmes ¨weakly hard¨, où la contrainte dure de respect d'échéance est remplacée une distribution précisément définie de dépassements autorisés, exprimée en terme du nombre d'échéances respectées ou dépassées sur une fenêtre temporelle donnée [5].

L'exécution de ces systèmes est souvent gérée par un système d'exploitation utilisant un ordonnanceur à priorités fixes et préemption. La variété des caractéristiques temporelles et l'incertitude liée aux valeurs connues uniquement à l'exécution de ces activités font qu'il est difficile et inefficace de spécifier un ordonnancement statique (e.g. une affectation statique de périodes), utilisant des majorants et conduisant à une sous-utilisation chronique du support d'exécution. Dans ce cas les dépassements d'échéance peuvent également conduire à une avalanche de fautes temporelles et à un écroulement du système. D'autre part, dans la littérature classique concernant l'ordonnancement temps réel, les algorithmes (par exemple la politique d'affectation des priorités) sont étudiés séparément du contexte applicatif [13].

Il est montré que la politique Rate Monotonic (les priorités fixes sont ordonnées dans l'ordre inverse des périodes) est optimale, i.e. tout ensemble de tâches ordonnançable de cette classe l'est par R.M. (et EDF est optimal pour des priorités dynamiques). De nombreuses extensions ont par la suite été apportées au modèle original pour, par exemple, prendre en compte les dépendances et l'exclusion mutuelle entre tâches ou encore l'existence de processus apériodiques [38].

Connaissance des paramètres temporels Ces approches supposent que l'on connaisse au départ la valeur des paramètres temporels des tâches. Si toutes les tâches ne sont pas périodiques, le problème peut être plus ou moins bien contourné par une ¨mise en réserve¨ de temps CPU (e.g. le serveur sporadique), ce qui suppose tout de même de connaître une borne inférieure du temps séparant deux activations successives. On peut difficilement intégrer des notions d'urgence ou d'importance de ces tâches.

La détermination de la durée d'exécution des tâches est un problème difficile. Cette durée dépend évidemment du langage hôte (et des optimisations éventuelles du compilateur) et de la machine cible. Pour une machine et un compilateur donné, cette durée dépend également du contexte, et est de plus en plus difficile à déterminer avec les processeurs modernes utilisant des caches et/ou des pipe-lines. Les branchements conditionnels dans le code génèrent également des durées d'exécution variables (potentiellement une durée par branche).