Ministère de l’enseignement supérieur et de la recherche scientifique

Université de Ouargla

Faculté des Sciences Appliquées

Département de Génie Électrique

Cours 1

2eme année Master (E I,M et R) Mr. MEGHNI BILLEL

Intitulé de la matière : Implémentation d’une commande numérique
en temps réel

Code :
Semestre : 3 / Electrotechnique industrielle ,Machine électrique et
Réseaux Électriques,

Nombre d'heures d'enseignement : Cours: ...21hOO / TD: OOhOO /

TP:00HOO

Mode d'évaluation : Examen écrit / Contrôle continu / Test travaux

pratiques

Nombre de crédits : / Coefficient de la Matière :

Responsable de cours : Monsieur Dr : MEGHNI Billel
Adresse électronique : [email protected]
https://books.google.dz/books?id=z2rFTpmfs4UC&pg=PA548&lpg=PA548&dq=continu,+discret,
+tout+ou+rien+ou+analogique&source=bl&ots=1oBPWWqANR&sig=fjeVsMkT2ldhh-
Ty0j01sa45fCc&hl=fr&sa=X&ved=0ahUKEwi4qbb
gIbXAhVEbRQKHcH9AawQ6AEIOjAD#v=onepage&q=continu%2C%20discret%2C%20tout%20ou
%20rien%20ou%20analogique&f=false

Commande des systèmes dynamiques: introduction à la modélisation et au ...

Définition :
Nous pouvons définir un système de contrôle-commande comme un
système informatique en relation avec l’environnement physique réel
externe par l’intermédiaire de capteurs et/ou d’actionneurs, contrairement
aux systèmes d’informatiques scientifiques (gestion de base de données,
CAO, bureautique…) qui ont des entrées constituées de données fournies
par des fichiers ou éventuellement un opérateur. Les grandeurs physiques
acquises permettent au système de contrôle-commande de piloter un
procédé physique quelconque. Donnons ainsi une définition générale d’un
système de contrôle-commande (figure 1.1) :
Un système de contrôle-commande reçoit des informations sur l’état du
procédé externe, traite ces données et, en fonction du résultat, évalue
une décision qui agit sur cet environnement extérieur afin d’assurer un
état stable.
Cette notion d’état stable peut être différente selon les applications ou
procédés. Il dépend du cahier des charges de l’application (maintien d’une
température de consigne, régime moteur, qualité de service…).

Figure.1.1. Représentation schématique d’un système de contrôle-commande.

L’interaction du système de contrôle-commande avec le procédé extérieur
à piloter se décompose en deux parties (figure 1.2) :
• Observations par l’intermédiaire de capteurs
• Actions réalisées par l’intermédiaire d’actionneurs
Cette définition des systèmes de contrôle-commande ayant été faite, nous
pouvons replacer ces systèmes par rapport aux autres systèmes
informatiques en faisant trois catégories :

Figure .1.2. Représentation schématique de l’interaction du procédé physique piloté et du

système de contrôle-commande
 les systèmes transformationnels qui utilisent des données fournies à
l’initialisation par l’utilisateur. Ces données, leurs traitements et
l’obtention du résultat n’ont aucune contrainte de temps ;
 les systèmes interactifs dans le sens où les données sont produites par
interaction avec l’environnement sous différentes formes (clavier,
fichier, réseaux, souris, etc.). Mais le temps n’intervient pas en tant que
tel si ce n’est avec un aspect confort de travail ou qualité de service ;
 les systèmes de contrôle-commande ou réactifs qui sont aussi en
relation avec l’environnement physique réel pour les données en
entrée ; mais, dans ce cas, l’aspect « temps » a une place importante
sous la forme d’un temps de réaction, d’une échéance à respecter
(dailé limite), etc,
Nous terminons cette section par des définitions qualifiant des systèmes
de contrôle commande ayant des spécifications particulières. La première
de ces catégories concerne les systèmes temps réel (real-time system)
dont la définition est : « un système de contrôle-commande dans lequel
l’exactitude des applications ne dépend pas seulement du résultat mais
aussi du temps auquel ce résultat est produit. Si les contraintes
temporelles de l’application ne sont pas respectées, on parle de
défaillance du système ». Ces contraintes temporelles peuvent être de
deux types :
• contraintes temporelles relatives ou lâches (temps réel mou : soft real-
time) : les fautes temporelles sont tolérables (ex. : jeux vidéo, applications
multimédia, téléphonie mobile…) ;
• contraintes temporelles strictes ou dures (temps réel dur : hard real-
time) : les fautes temporelles ne sont pas tolérables (ex. : avionique,
véhicules spatiaux, automobile, transport ferroviaire…).
Dans le cas des systèmes temps réel à contraintes temporelles relatives,
nous pouvons parler de systèmes de contrôle-commande classiques. Nous
pouvons aussi trouver les qualificatifs suivants :
• système de contrôle-commande embarqué (embedded real-time
system) : pas d’intervention humaine directe (pas de modification du
programme ou des paramètres du programme) ;
• système de contrôle-commande dédié (dedicated real-time system) :
les architectures matérielles ou logicielles sont spécifiques à
l’application (noyau, processeur…)
Figure 1.3 – Comparaison des systèmes de contrôle-commande par rapport aux
autres applications informatiques.
Principales caractéristiques des systèmes de contrôle-commande
Considérons un exemple représentatif d’une application de contrôle-
commande représenté sur la figure 1.4. Cet exemple de contrôle-
commande d’un moteur à combustion. Le contrôle-commande de cette
application est fait par l’intermédiaire d’un ensemble de capteurs et
d’actionneurs (pédale d’accélérateur, température air, pression air,
température eau, rotation vilebrequin, capteurs de pollution, injection
essence, allumage, admission air, etc.) et d’une connexion au réseau
interne à l’automobile. L’analyse de cet exemple d’application permet de
mettre en exergue les principales caractéristiques des systèmes de
contrôle-commande.
• grande diversité des dispositifs d’entrées/sorties : les données à
acquérir qui sont fournies par les capteurs et les données à fournir aux
actionneurs sont de types très variés (continu, discret, tout ou rien ou
analogique). Il est aussi nécessaire de piloter un bus de terrain pour les
communications ;
Figure 1.4 – Exemple d’une application de contrôle-commande d’un moteur à combustion
• prise en compte des comportements concurrents : l’ensemble de ces
données physiques qui arrivent de l’extérieur et le réseau qui permet de
recevoir des messages ne sont pas synchronisés au niveau de leurs
évolutions, par conséquent, les système informatique doit être capable
d’accepter ces variations simultanées des paramètres ;
• respect des contraintes temporelles : la caractéristique précédente
impose de la part du système informatique d’avoir une réactivité
suffisante pour prendre en compte tous ces comportements
concurrents et en réponse à ceux-ci, de faire une commande en
respectant un délai compatible avec la dynamique du système ;
• sûreté de fonctionnement : les systèmes de type contrôle-commande
mettent souvent en jeu des applications qui demandent un niveau
important de sécurité pour raisons de coût ou de vies humaines. Pour
répondre à cette demande, il est nécessaire de mettre en œuvre toutes
les réponses de la sûreté de fonctionnement (développements sûrs,
tests, méthodes formelles, prévisibilité, déterminisme (inévitable),
continuité de service, tolérance aux fautes, redondance, etc.)
Caractéristique temporelle des systèmes de contrôle-commande

Le respect des contraintes temporelles d’une application de contrôle-

commande dépend essentiellement de la dynamique du procédé. Cette
caractéristique temporelle peut être très différente suivant l’application
(figure 1.5) :
 Milliseconde : systèmes radar, systèmes vocaux, systèmes de mesures…
 Seconde : systèmes de visualisation, robotique…
 Minute : chaîne de fabrication…
 Heure : contrôle de réactions chimiques…

Ce paramètre temporel correspond à l’ordre de grandeur de la capacité de

réponse ou de traitement du système de contrôle-commande.

Figure 1.5 – Comparaison de la dynamique de différentes applications de contrôle-commande

Il est nécessaire de préciser et de formaliser cette caractéristique
temporelle qui peut prendre de nombreuses formulations. Ainsi, nous
pouvons définir de manière non exhaustive :

Durée d’exécution d’une activité : l’activité d’une application, qui peut être
l’enchaînement de plusieurs activités élémentaires (acquisition, traitement,
commande, affichage…), possède une durée d’exécution qui peut être
mesurée de diverses manières.

Cadence de répétition ou périodicité d’une activité : l’acquisition d’une

donnée ou la commande d’un actionneur peuvent nécessiter une régularité
liée par exemple à la fréquence d’échantillonnage.
Date au plus tôt ou date de réveil : dans certains cas, un traitement doit être
déclenché à une date précise relative par rapport au début de l’exécution de
l’application ou absolue (plus rarement).

Date d’activation : cet instant correspond à l’exécution effective de l’activité.

Date au plus tard ou échéance : le traitement ou la commande d’un

actionneur doivent être terminés à un instant fixé par rapport au début de
l’exécution de l’application.

Temps de réponse : cette caractéristique peut s’appliquer à une activité de

régulation ou à un ensemble d’activités de régulation ; elle est directement
liée à la dynamique du système. Ce paramètre correspond à la différence entre
la date de réveil et la date de fin de l’activité.
Gigue temporelle : ce paramètre caractérise la répétabilité d’une activité
au fur et mesure de ses occurrences.

Quelques exemples d’applications

Nous pouvons citer quelques exemples d’applications de contrôle-

commande :
Robot de production : un robot, réalisant une activité spécifique
(peinture, assemblage, tri) sur une chaîne de production, doit effectuer
son travail en des temps fixés par la cadence de fabrication. S’il agit trop
tôt ou trop tard, l’objet manufacturier traité sera détruit ou endommagé
conduisant à des conséquences financières ou humaines graves (oubli
d’un ou plusieurs rivets sur un avion).
Robot d’exploration : ce robot doit se déplacer dans un environnement en
principe non connu (zone radioactive après un accident, planète, épave
sous la mer…). Il est important qu’il puisse réagir aux obstacles fixes ou
mobiles afin de ne pas conduire à sa perte.
Architecture logicielle des applications de contrôle-commande
Architecture multitâche
Le comportement concurrent des événements et grandeurs physiques
externes amène à décrire l’environnement comme un système fortement
parallèle. Cela conduit naturellement à adapter les méthodes de
conception et de réalisation du système de contrôle-commande d’un tel
environnement à ce parallélisme. Aussi, l’architecture la mieux adaptée
pour répondre à ce comportement parallèle du procédé externe est une
architecture multitâche. Ainsi, au parallélisme de l’environnement, la
réponse est le parallélisme de conception. Nous pouvons définir la tâche
ou activité ou processus comme « une entité d’exécution et de
structuration de l’application »
Cette architecture logicielle multitâche facilite la conception et la mise en
œuvre et surtout augmente l’évolutivité de l’application réalisée
(applicable).
D’une manière très générique, la figure 1.6 donne l’architecture logicielle
d’une application de contrôle-commande multitâche. Nous pouvons ainsi
découper cet ensemble de tâches ou activités selon les groupes suivants :
Tâches d’entrées/sorties : ces tâches permettent d’accéder aux données
externes par l’intermédiaire de cartes d’entrées/sorties et ensuite de
capteurs et d’actionneurs directement liés au procédé géré. Ces tâches
peuvent être activées de façon régulière ou par interruption.
Tâches de traitement : ces tâches constituent le cœur de l’application.
Elles intègrent des traitements de signaux (analyse spectrale, corrélation,
traitement d’images, etc.) ou des lois de commande (régulation tout ou
rien, régulation du premier ordre, régulation PID, etc.). Dans le cadre de
cette étude, nous considérerons ces tâches comme des boîtes noires,
c’est-à-dire que le traitement effectué par ces tâches relève des domaines
comme le traitement du signal, le traitement d’images ou l’automatique,
production et énergie renouvelable.
Figure 1.6 – Architecture logicielle d’une application de contrôle commande multitâche.
Tâches de gestion de l’interface utilisateur : ces tâches permettent de
présenter l’état du procédé ou de sa gestion à l’utilisateur. En réponse,
l’opérateur peut modifier les consignes données ou changer les
commandes. Ces tâches peuvent être très complexes et coûteuses en
temps de calcul si l’interface gérée est de taille importante (tableau de
bord) ou de type graphique (représentation 3D).
Tâches de communications : ces tâches sont destinées à gérer les
messages envoyés ou reçus à travers un ou plusieurs réseaux ou bus de
terrain. Si ce type de tâches existe, l’application est dite distribuée ou
répartie.
Tâches de sauvegarde : ces tâches permettent de stocker l’état du
système à des instants fixés. Cette sauvegarde peut être utilisée a
posteriori pour analyser le fonctionnement de l’application ou lors d’une
reprise d’exécution à une étape précédente.
Modèles d’exécution et ordonnancement
Cette architecture logicielle peut être vue comme un ensemble de tâches
synchronisées, communicantes et partageant des ressources critiques
(vitales) . Le rôle essentiel du système informatique est donc de gérer
l’enchaînement et la concurrence des tâches en optimisant l’occupation
du processeur, cette fonction est appelée l’ordonnancement.
Nous pouvons distinguer deux modèles d’exécution des systèmes temps
réel : l’exécution dite synchrone et l’exécution asynchrone.
Nous allons présenter ces deux modèles d’exécution à l’aide d’un modèle
d’application très simple.
• Tâche de lecture des données entrées par l’opérateur à l’aide d’un
clavier, appelée « Lecture_consigne ». L’intervention humaine fait que
cette tâche peut être longue.
• Tâche d’alarme qui se déclenche sur un événement d’alerte
correspondant au dépassement d’un paramètre critique, appelée «
Alarme ». Celle-ci doit s’exécuter au plus vite pour éviter
l’endommagement du procédé.
Pour mettre en avant les différences entre les deux modèles d’exécution
nous allons étudier la situation dans laquelle la tâche « Lecture consigne »
s’exécute et la tâche « Alarme » demande son exécution alors que la tâche
« Lecture consigne » n’est pas terminée
Dans le modèle d’exécution synchrone, la perception (visualisation) de
l’occurrence de tout événement par le système est différée du temps
d’exécution de la tâche en cours. Dans l’exemple proposé, nous pouvons
constater que la prise en compte d’un signal d’alerte n’est effective que
lors de la fin de la tâche « Lecture_consigne » (voir fgure ). D’un point de
vue du procédé, la réaction est perçue comme différée, alors que du point
de vue du système informatique, elle est perçue comme immédiate.
L’occurrence des événements externes a donc été artificiellement
synchronisée avec le système informatique, d’où le nom d’exécution
synchrone.
 Figure.1.7 Modèle d’exécution synchrone d’une application de contrôle-commande.

Ce retard peut affecter la prise en compte de n’importe quel événement,

quelle qu’en soit la gravité pour l’application.
Dans le cas du modèle synchrone d’exécution, nous avons un système
d’ordonnancement complètement prévisible et, en conséquence, il est
possible en faisant une analyse exhaustive de l’exécution de produire une
séquence d’exécution qui est jouée de façon répétitive. Cette étude de la
séquence est appelée analyse de l’ordonnancement hors-ligne.
Dans le modèle d’exécution asynchrone, l’occurrence de tout événement
est immédiatement prise en compte par le système pour tenir compte de
l’urgence ou de l’importance. Dans l’exemple proposé, nous pouvons
constater que la prise en compte d’un signal d’alerte est immédiate sans
attendre la fin de la tâche « Lecture_consigne » (voir fgure 1.8). La prise en
compte de l’événement « alerte » est identique pour le procédé et le
système informatique.
L’occurrence des événements externes n’est pas synchronisée avec le
système informatique, d’où le nom d’exécution asynchrone.

Figure.1.8 Modèle d’exécution asynchrone d’une application de contrôle-commande.

Dans ce contexte, nous avons des tâches qui sont interruptibles ou
préemtibles. En conséquence, l’ordonnancement n’est pas totalement
prévisible et l’analyse de l’exécution des tâches doit se faire en ligne par
simulation ou par test. Cela nécessite l’utilisation d’un gestionnaire
centralisé des événements et de la décision d’exécution : exécutif ou
noyau temps réel.
Nous avons ainsi défini :
▶ Tâche non préemptible ou préemptible : Une tâche non préemptible ne
peut être interrompue qu’à des endroits spécifiques et à la demande de la
tâche elle-même : fin_de_tâche, attente_signal… Dans ce cas, la
programmation est plus simple et aucun mécanisme de partage de
ressources critiques n’est à prévoir.
En revanche, des temps de réponse longs peuvent se produire.
Une tâche préemptible peut être interrompue à n’importe quel instant et
le processeur être affecté à une autre tâche. Dans ce cas, les temps de
réponse à un événement externe peuvent être très courts ; mais nous
avons alors une programmation plus complexe avec un besoin de
mécanisme de partage de ressources critiques.
Analyse de l’ordonnancement hors-ligne ou en ligne :
Une analyse de l’ordonnancement hors-ligne correspond à la construction
d’une séquence d’exécution complète sur la base des paramètres
temporels des tâches en utilisant une modélisation (réseaux de Petri…) ou
une simulation (animation).
L’ordonnanceur nécessaire est simple puisque la séquence d’exécution est
prédéfinie, il se réduit à un séquenceur. En revanche, l’application est peu
fléxible.
Une analyse de l’ordonnancement en ligne correspond à un choix
dynamique de la prochaine tâche à exécuter en fonction des paramètres de
la tâche. Si le système a des contraintes temporelles, on doit utiliser
préalablement à la mise en exploitation du système des tests permettant
de vérifier qu’en toutes circonstances les contraintes temporelles seront
respectées. On appelle ces tests des tests d’ordonnançabilité.
Exécution synchrone ou asynchrone :
Une exécution est dite synchrone si les tâches sont non préemtibles et
s’exécutent les unes après les autres dans un ordre qui peut être défni par
une analyse hors-ligne de l’ordonnancement.
Une exécution est dite asynchrone si les tâches sont préemtibles et
s’exécutent selon l’ordonnancement. Une analyse de la séquence doit se
faire obligatoirement en ligne.
Applications et systèmes temps réel et embarqués
Domaines d’applications
Jusqu’à une date récente, les systèmes temps réel et embarqués étaient
destinés quasi-exclusivement aux applications de contrôle/commande de
procédés (ou de phénomènes) physiques (tels que des laminoirs ou des
usines de fabrication de voitures) et applications militaires. La notion de
temps réel se confondait alors avec ce type d’applications. Le
développement de l’informatique aidant, les applications temps réel et
embarqués sont présentes aujourd’hui dans des domaines très variés
comme le montre la liste suivante, même si elle n’est pas exhaustive :
• télécommunications (transport de la parole, systèmes de commutation,
• domaine médical (assistance et supervision de malades, …),
• contrôle de différents équipements dans les voitures, bus, trains, avions,
• contrôle et régulation de trafic en milieu urbain,
• guidage de véhicules en milieu urbain,
• industrie (contrôle/commande de procédés manufacturiers ou continus,
domaine militaire (suivi de trajectoires de missiles, …)
• aérospatial (suivi de satellites, simulation de vols, pilotage automatique,
• multimédia (transport d’images et de voie, téléconférences, …),
• finance (suivi du cours des devises et actions, ...),
• loisirs (consoles de jeu, ...), domotique (sécurité d’habitations, …),
• contrôle/commande d’appareils électroménagers
Définitions
La diversité des domaines d’applications rend difficile l’élaboration de
définitions sur lesquelles tout le monde s’accorde.
Systèmes embarqués
Voici quelques définitions pour cerner le concept de système embarqué :
Un système embarqué (SE) est un système informatisé spécialisé qui
constitue une partie intégrante d’un système plus large ou une machine.
Typiquement, c’est un système sur un seul processeur et dont les
programmes sont stockés en ROM. A priori, tous les systèmes qui ont des
interfaces digitales (i.e. montre, caméra, voiture…) peuvent être considérés
comme des SE. Certains SE ont un système d’exploitation et d’autres non
car toute leur logique peut être implantée en un seul programme
Un système embarqué est une combinaison de logiciel et matériel, avec
des capacités fixes ou programmables, qui est spécialement conçu pour un
type d’application particulier. Les distributeurs automatiques de boissons,
les automobiles, les équipements médicaux, les caméras, les avions, les
jouets, les téléphones portables et les PDA sont des exemples de systèmes
qui abritent des SE. Les SE programmables sont dotés d’interfaces de
programmation et leur programmation est une activité spécialisée.
Un système embarqué est une composante primordiale d’un système (i.e.
un avion, une voiture…) dont l’objectif est de commander, contrôler et
superviser ce système.
Un système embarqué est un système enfoui (embedded system)
Par rapport aux autres systèmes informatisés, les systèmes embarqués
sont caractérisés par :
• Encombrement mémoire (mémoire limitée, pas de disque en général)
• Consommation d’énergie (batterie : point faible des SE)
• Poids et volume
• Autonomie
• Mobilité
• Communication (attention : la communication affecte la batterie)
• Contraintes de temps réel
• Contraintes de sécurité
• Coût de produits en relation avec le secteur cible
Systèmes temps réel
Selon l’aspect abordé dans les systèmes temps réel, on choisit une
définition qui s’approche le plus de la problématique traitée. Ainsi, on
assimile, selon le cas, un système temps réel à un système rapide, à un
système en interaction directe avec un procédé physique, à un système
réactif, à un système qui ne fournit pas de réponse en différé, à un système
avec un comportement prédictible, à un système qui travaille sur des
données fraîches, à un système robuste, etc
Cependant, toutes les applications temps réel (dites aussi applications
contraintes par le temps ou encore applications temps contraint) ont en
commun la prépondérance du facteur temps.
Elles doivent réagir en tenant compte de l’écoulement du temps (on parle
de timeliness property, en anglais). Cette caractéristique fondamentale qui
distingue globalement les applications temps réel des autres types
d’applications informatiques (de gestion ou autres) est exprimée par la
définition suivante qui est la plus couramment référencée dans la littérature :
A real-time system is defined as a system whose correctness of the system depends not
only on the logical results of computations, but also on the time at which the results are
produced

Cette définition a conduit, en quelque sorte, à l’adage suivant que toute

personne intervenant dans le cycle de vie d’une application temps réel
connaît ou devrait connaître : Un résultat juste mais hors délai est un
résultat faux
Par ailleurs, toute application temps réel est en interaction (forte ou faible
selon les cas) avec son environnement. Lequel environnement peut être un
procédé industriel, un moteur d’avion, une ville (si on s’intéresse à la
pollution, par exemple), un malade, un groupe de participants à une
téléconférence, un enfant devant sa console de jeu, etc. La nature de
l’environnement à une incidence directe sur la criticité des actions
entreprises dans une application temps réel.
Notion de criticité et d’importance des opérations
La notion de “criticité” (ou criticality en anglais) a été introduite comme critère
pour pouvoir classer les applications temps réel selon la sévérité, en terme de
coût engendré par le non-respect des contraintes temporelles. On parle de
faute temporelle, quand les contraintes de temps ne sont pas respectées.
On distingue généralement les fautes bénignes n’affectant pas de manière
significative le service rendu par le système et les fautes catastrophiques
conduisant à des pertes de vies humaines, des pertes financières, de la
pollution de l’environnement, etc. En utilisant la notion criticité, on a
coutume de classer les systèmes temps réel en trois familles :
• Systèmes à contraintes temporelles critiques (hard real-time systems) où
le non-respect des contraintes de temps peut conduire à des défaillances
avec des conséquences pouvant être graves. Si l’échéance est dépassée,
il y a faute. Si l’échéance est dépassée, il y a faute.
• Systèmes à contraintes temporelles souples (soft real-time systems) où
le dépassement des échéances est considéré comme une faute bénigne.
Lorsqu’une échéance est dépassée, il n’y a pas faute ; le résultat peut être
exploitable même s’il est fourni après l’échéance.
• Systèmes à contraintes temporelles strictes (firm real-time systems) où
le dépassement occasionnel des échéances est toléré. Il y a faute
(bénigne) si l’échéance n’est pas respectée.
EXEMPLES.
1. Les systèmes d’interception de missiles ou de contrôle d’atterrissage
d’avions sont considérés comme étant des systèmes à contraintes
temporelles critiques. En effet, dans un système d’interception de missiles,
si un missile n’est pas intercepté à temps, cela peut conduire à des
conséquences graves.
Si une opération d’atterrissage d’un avion commencée n’est pas achevée au
bout d’un délai borné, un accident grave peut survenir.
2. Les systèmes de téléconférences et les systèmes de réservation des
compagnies aériennes sont considérés comme étant des systèmes à
contraintes temporelles souples. Dans un système de téléconférence, son
et image doivent être synchronisés, mais des dérives de synchronisation
(dues à des messages tardifs) sont souvent tolérées. Pour les systèmes de
réservation des compagnies aériennes, si une requête de réservation dure
un peu plus longtemps que prévu, la seule conséquence regrettable peut
être la perte d’un client qui quitte l’agence, car il ne souhaite plus attendre
davantage.
3. Certains systèmes de supervision d’installations industrielles sont
considérés comme des systèmes à contraintes strictes. Par exemple, des
pièces fabriquées sur une chaîne de production sont déposées sur un
convoyeur et passent devant une caméra qui doit détecter certaines
anomalies de fabrication. En fonction des anomalies détectées par le
système de reconnaissance, les pièces sont dirigées vers la cellule de
fabrication appropriée. La détection des anomalies doit se faire pendant
que la pièce est en mouvement. Si la détection d’anomalie ne s’est pas faite
dans les temps, la pièce est recyclée sur le convoyeur pour une deuxième
analyse. On accepte que le système recycle une pièce sur dix car s’il recycle
trop de pièces la chaîne de production s’en trouve ralentie.
Figure 1.8 Système de contrôle-commande
 BVR : boîte vitesse robotisée
Figure 1.9 Exemple de système de contrôle commande
Figure 1.10 Composants d’un système de contrôle-commande
Figure 1.11 Système temps embarqués et non embarqués
Vues de systèmes temps réel et embarqué