Lorsque les différentes fonctions à accomplir par un système de contrôle commande sont regroupées dans un même calculateur informatique, il est nécessaire qu’une sorte de chef d’orchestre organise et distribue les tâches à effectuer en fonction de l’état du système et des évènements à traiter. En informatique, ce chef d’orchestre s’appelle un système opératoire, ou système d’exploitation (ou OS Operating System), ou encore scheduleur. Il a pour rôle de contrôler et d’attribuer les ressources (mémoires, communication, etc…) aux tâches qui en font la demande selon des règles convenues. Il joue donc un rôle essentiel dans la performance globale de l’équipement, et dans sa sûreté de fonctionnement.

Les premiers minis calculateurs munis de « schedulers » microprogrammés, c’est-à-dire programmés « en dur » dans le « hardware » de la machine, n’ont vu le jour qu’après 1975. Ce fut le cas du Solar développé par la société Télémécanique, et qui a été utilisé dans le développement des SIT 3 (Système Informatisés de Téléconsuite de type 3) de la Direction de la Distribution.
Le Service du transport ayant fait le choix du Mitra 15, développé par la société CII et ne disposant pas de cette technique, la question du développement d’un scheduler s’est donc posée à la Direction des Etudes et Recherches d’EDF.

Un premier projet de réalisation d’un « moniteur temps réel » a été confié au Service IMA (Informatique et mathématique appliquée » de la DER en 1974. Arrêté en 1976, ce projet a été repris par la Division « Conduite des réseaux » du Service Etudes de réseaux, alors en charge du développement du premier EDT (Ensemble de traitement) de PCG (le Pupitre de Commande Groupée du SDART).

Le premier projet avait échoué pour des raisons de complexité. Ses concepteurs avaient opté pour un système « multi tâches » capable d’exécuter en parallèle des traitements d’événements survenant de façon quasi simultanée. Cela a posé des problèmes difficiles à résoudre. Ces problèmes sont principalement dus à la question de la « réentrance » des programmes. En effet, une tâche élémentaire n’est implantée que dans un endroit unique de la mémoire. Le « moniteur » doit donc savoir traiter le cas de deux sollicitations successives de cette tâche, la deuxième survenant alors que le traitement du premier n’est pas terminé. Un mauvais traitement de ce type de problème peut conduire à plusieurs genres de défauts plus ou moins graves : le non traitement d’un événement, une perte de chronologie, un engorgement des files d’attente des événements à traiter, etc.. Cela peut aussi entrainer un blocage pur et simple de la machine dans un cas bien connu des informaticiens sous le terme de « dead lock » ou d’interblocage par « verrou mortel ».
L’interblocage se produit lorsque 2 tâches font appel successivement aux même ressources dans un ordre différent.
Supposons que le programme de la tâche 1 fasse appel successivement aux ressources A et B, et libère la ressource B avant la ressource A
Supposons que le programme de la tâche 2 fasse appel successivement aux ressources A et B, et libère la ressource B avant la ressource A
Si les tâches 1 et 2 sont appelées concurremment, un interblocage se produira dans le cas suivant :
1. la tâche 1 obtient A
2. la tâche 2 obtient B
3. la tâche 1 demande B mais ne peut l’obtenir tant que la tâche 2 de l’a pas libérée
4. la tâche 2 demande A mais ne peut l’obtenir tant que la tâche 1 ne l’a pas libérée
5. les 2 tâches sont bloquées en attente l’une de l’autre

Le 2ème projet s’est orienté vers des choix plus simples pour atteindre la fiabilité requise.
Tous les processus ont été découpés en tâches élémentaires comportant un nombre d’instructions réduit pour s’exécuter dans un laps de temps court et défini. Ces tâches élémentaires ne devaient avoir qu’un point d’entrée et un point de sortie.
A chaque tâche était associé un ordre de priorité.
Un seul système de file d’attente gérait l’ensemble : tout événement donnait lieu à un message introduit dans cette file d’attente de type « fifo » (First In First Out).
Le moniteur donnait successivement la main aux tâches dans l’ordre leur priorité en fonction des messages à traiter dans la file d’attente.

Un tel système s’est révélé bien adapté aux traitements à réaliser dans l’EDT.
Rappelons que les moyens disponibles dans le Mitra 15 étaient rudimentaires : un jeu d’instructions très réduit, travaillant sur des octets (8 bits), la taille mémoire étant de 16 kilo-octets. La programmation se faisait en langage « assembleur » spécifique de la machine.
Les développements ultérieurs ont profité de la montée en gamme des Mitra : le Mitra 115 d’abord, permettant de passer à 32 puis à 64 koctets, puis au Mitra 225.

Plusieurs mécanismes de sauvegarde en cas d’erreur ont été implantés, notamment le mécanisme de « watch dog » ou « chien de garde ». Une tâche appelée tâche de fond, dont la priorité était la plus faible, avait pour seul but de réaliser un programme cyclique de quelques instructions pour activer un « bac de commutation » externe au Mitra 15. Accessoirement, elle lançait aussi l’allumage de voyants sur le pupitre du Mitra 15. Lorsque le système était trop chargé, les voyants s’allumaient donc avec une fréquence de plus en plus faible. Et si le système se bloquait, la tâche de fond n’était plus sollicitée, les voyants restaient immobiles, et le « bac de commutation » concluait à la panne de l’EDT et donnait la main au 2ème EDT, l’ensemble étant doublé pour des raisons de disponibilité.

(Une anecdote au passage : lors d’une publication sur ce thème à la CIGRE dans les années 1980, l’interprète avait traduit « watch dog » par « terre neuve » ! Le plus surprenant est que le public de connaisseurs n’avait pas réagi… )

Ce qui précède concerne principalement la partie PC (Poste de Conduite). Qu’en était-il de la partie PA (Postes asservis ?)
Ces PA étaient des machines très spécifiques, construits par les fournisseurs d’alors, notamment Jeumont Schneider et CGEE Alsthom. La problématique générale était équivalente, mais la partie informatique restait rudimentaire comparée aux questions posées par le traitement des entrées / sorties de nature particulière : les positions ou commandes d’organes en « tout ou rien » (appelées les entrées / sorties TOR, codées sur 1 seul bit), ou les mesures codées elles sur 8 bits.
Leur fonctionnement de la partie « scheduler » était simplifié à l’extrême : un examen cyclique permanent des entrées sorties donnait lieu à envoi d’un message vers le PC lors de toute détection de changement d’état.

Le point commun des PA des différents constructeurs et du PC est à noter : il s’agissait alors d’un développement « propriétaire », les standards n’ayant pas encore fait leur apparition.