LA TECHNOLOGIE AIDA

à la fois une méthodologie d'ingénierie des systèmes et la technologie associée, permet d'aborder, comprendre, simplifier, améliorer les systèmes très ou trop complexes, ce qui survient habituellement de plusieurs manières :

- devenus tels au fil du temps, ce qui est le cas le plus fréquent

Simples au départ parce que peu étendus (ce n'est pas la même chose), puis ayant pris de l'ampleur avec une structure qui suffisait au départ, mais qui touche ses limites. Il apparaît généralement plus simple d'ajouter des ressources et moyens divers. Si la tendance à l'expansion (matérielle, logique ou autre) se maintient, on arrive inéluctablement à la rupture entre les services demandés et la possibilité d'y répondre.

On trouvera des exemples de cette situation dans tout ce qui subit une inflation : le nombre des voitures en ville, celui des habitants sur Terre, le nombre de lois votées, le nombre des sous-particules en physique, la bureaucratie...

- conçus dès l'origine de manière intrinsèquement complexe

Là ou Léonardo fait simple du premier coup, nous autres humains savons d'abord faire compliqué, puis (éventuellement) simplifier une fois qu'on a bien mesuré le problème. Tout le monde, ou toute institution, ne va pas spontanément droit au but. Comprendre l'essence même d'un problème est difficile, aussi recourt-on habituellement à l'empilement des moyens existants ce qui, efficacité et élégance à part, permet toujours d'avancer jusqu'au point où le résultat est assez bon pour qu'on arrête là. Cette approche est favorite des grosses organisations car elle procure un consensus aisé.

SEA a pour clientèle les entreprises qui se heurtent à la limite de cette approche : plus un système est fait de "briques" nombreuses, plus le mur est fait de ciment. Les interfaces entre des éléments, utiles pris un par un, dominent l'ensemble et le rendent lourd, inefficace, cher. Il est alors impératif mais très difficile de faire admettre un gros risque : celui de remettre le problème à plat. Mais alors la solution est d'une simplicité généralement confondante.

- complexes parce qu'on croit si fort qu'ils le sont, qu'on ne pense pas à leur chercher une forme simple

Il est aussi possible de s'acharner indéfiniment sur un sujet non satisfaisant dont personne n'a fait la synthèse. Chacun voit dans une partie du problème le clou dont il tient le marteau à la main. Le destin de ces problèmes est l'inflation et l'insatisfaction, des nuisances prolongées.

... nous discutons dans ces pages du transport urbain comme problème-complexe-non-résolu.

On appelle généralement "système distribué", par exemple en pensant à Internet, ceux qui ne sont pas strictement gouvernés par un pouvoir central, un ordinateur ou "calculateur" dans le cas des machines.

SEA appelle "totalement distribué" un système ou il n'y a plus du tout  de contrôle central, et c'est tout à fait différent. Là, il faut que chaque cellule du système emporte :

- non seulement tout ce qu'il lui faut pour fonctionner, mais encore

- tout ce qu'il faut pour communiquer avec toute autre cellule du système avec laquelle ce sera nécessaire

- et tout ce qui permet au système, qu'on pense désormais comme un automate cellulaire, de rendre les services attendus. 

Ils sont contrôlés par un calculateur central (système centralisé) ou une grappe (système fédéré) équivalente. Cette dernière forme est générale dès que le système a une certaine complexité : une voiture, un avion, une ligne de métro, un oléoduc, etc. Caractéristiques de cette approche :

- ils sont fortement hétérogènes : chaque électronique est spécifique à une fonction, chaque logiciel, des réseaux hétérogènes requièrent autant de "passerelles" ad hoc entre réseaux.

- un faisceau imposant de fils discrets et de liaisons multiplexées diverses collectent les états des équipements (capteurs/actionneurs) et les acheminent vers les calculateurs en brisant quelque peu la synchronisation des mesures

- inversement le faisceau renvoie aux équipements les ordres non sans avoir inséré des retards considérables depuis la mesure des états

- la complexité du système le rend normalement indescriptible (une description "en compréhension"), si ce n'est à en étaler complètement l'état actuel (une description "en extension"). C'est au niveau du logiciel que la complexité culmine.

 Dans cette situation on cherche généralement à dépasser tel ou tel paramètre limite, mais les systèmes sont déjà ajustés aux limites de leur potentiel. Le dépassement recherché demande donc soit un effort considérable, soit ce que fait SEA : reculer un peu et prendre un autre chemin.

Quelques décennies d'exercice nous ont appris que ce qu'on appelle un système (- "de contrôle temps réel" en particulier) est fait de peu d'éléments, en réalité :

1- des actionneurs qui permettent au système d'agir sur le monde extérieur

2- des capteurs qui permettent au système de connaître l'effet de ses actions, ses états internes, l'état du monde extérieur

3- des lois de contrôle comprenant :

- des états désirés = ce qu'on attend du système

- des états redoutés = les pannes possibles

- tous les autres états = ce qu'on appelle un bug quand le système y entre

 ...et c'est tout. Le reste, c'est ce dont a besoin non pas l'utilisateur mais le constructeur. Or l'expérience AIDA montre systématiquement que ce reste représente les trois quarts, les neuf dixièmes... des systèmes traditionnels qu'on veut bien nous demander de reformuler.

Créer un système, ou en soigner un existant, consiste à suivre simplement les principes énoncés.

a- parcourir le système en notant où se trouve chaque équipement (le périmètre "dont l'utilisateur a besoin"), c'est-à-dire uniquement ce qui ressemble à un capteur (= qui injecte des données dans le système) ou un actionneur (= qui en plus agit sur l'extérieur).

b- évaluer pour chacun, devenu un "nœud" du réseau, son besoin de communication :

1- quel est le niveau de criticité/risque/sécurité etc. maximal des données qu'il échange

2- par quels chemins ces données ont-elles le droit de circuler (ex. aérospatial : données critiques => chemins séparés)

3- quelle est leur latence (pire cas de temps de transfert) admissible, quelle bande passante nécessaire (ex. image=énorme, flag=rien)

c- dessiner le graphe, la toile d'araignée qui permet à chacun, en parlant au bon voisin, d'envoyer et propager les données au bons endroits

Le travail d'architecture est terminé. Du graphe on déduit par des calculs automatiques (donc sans insérer d'erreur de manipulation) les éléments techniques de la réalisation :

d- associer à chaque équipement, si ce n'est déjà fait, la petite électronique (exemple d'électronique) :

1- qui assure sa communication dans le maillage du système. SEA a développé un coupleur simple, performant et sûr.

2- qui pilote l'équipement. Comme le système est divisé en éléments unitaires, ce contrôle est extrêmement sûr, performant et simple par rapport à ce que peut faire le meilleur calculateur distant au travers du meilleur faisceau de fils traditionnel.

Capital : quand ce travail est fait pour un équipement (un moteur, une lampe, une pompe, un bouton, un capteur, un radar, un écran etc. il ne sera plus jamais nécessaire de le refaire, pour tout système de tout constructeur.

e- tirer entre chaque nœud le lien série qui satisfait au besoin de débit/latence pour cet arête du graphe. On admet généralement d'appliquer partout le même type de lien, c'est plus simple à normaliser, mais ce n'est pas toujours la meilleure solution.

Exemple : si un avion fonctionne bien en mettant partout un bus LVDS à 3Gbps (ce qui est du luxe), il y aura cent capteurs de température/pression/vibration qui travailleront parfaitement à 1Mbps, alors pourquoi payer plus cher ? La communication AIDA tolère parfaitement de tels écarts, ou pire.

f- générer automatiquement la messagerie qui achemine de chaque émetteur à chaque récepteur les trames requises, avec les chemins direct, de secours, de double secours etc. Cela prend une bonne seconde pour un système de la taille d'un A380.

g- générer parallèlement pour chaque nœud les petites tables de routage lui permettant de savoir dans quel direction, s'il a le choix, propager les trames qu'il voit passer et lesquelles le concernent.

h- compiler, mettre sous tension.

1- disparition complète des calculateurs de contrôle complexes et de leur logiciel, qui sont les causes principales des erreurs, des coûts et délais de développement, des consommations d'énergie, de l'encombrement, de la maintenance des systèmes.

2- les calculateurs qui ont à effectuer "des calculs" et surtout, qu'on nous impose de conserver dans le système tant que personne ne sait réécrire les applications contenues (bel exemple de la "portabilité" et "abstraction du matériel" tant vantées), on les garde : ce sont des sortes d'équipements dont la présence est imposée, comme si l'utilisateur en avait besoin.

3- disparition totale des faisceaux de câblage discret transportant du signal, de leur connecteurs, des chemins de câblage, goulottes, frette, pannes, incendie, CEM etc.

4- disparition des passerelles, "gateways", adaptateurs et interfaces divers, devenus superflus dans un réseau homogène, plus performant et plus économique.

5- les systèmes conçus ou reconçus selon cette démarche dépassent largement les traditionnels (typ. ceux déployés en 2016) à la fois en performance, sûreté de fonctionnement, qualité électromagnétique, ré-utilisabilité, standardisation, économie en conception, à l'usage, et en évolutivité.

L'analyse de l'existant, détaillée ci-dessus, est applicable en dehors du domaine des systèmes de contrôle, parce que ses principes dépendent plus d'une culture de milieu professionnel que de technologies spécifiques.

Pour vérifier ce point, SEA a concentré ses efforts depuis 2013 sur un autre domaine présentant des caractéristiques similaire, et à une échelle autrement plus problématique : le transport en zone urbaine.

Dans ce secteur la confusion est telle que, malgré l'énormité des enjeux et des efforts qui y sont consacrés, on ne trouve pas trace d'une tentative de poser tout cela comme un problème technique et donc, encore moins, d'y apporter une solution. Au lieu de quoi on observe ce que nous décrivions en commençant cette page :

1- l'opinion universelle que le sujet est trop complexe pour être résolu du vivant des observateurs

2- le placage perpétuel de techniques existantes (route, rues, automobile, bus, métro, tram, train, téléphérique, PRT etc.) sans que jamais aucune n'ait plus d'ambition que de soulager temporairement les difficultés ressenties.

3- la conservation et l'amplification de techniques reconnues unanimement comme nuisibles, dangereuses, indésirables comme l'automobile.- les villes les plus avancées, au nord de l'Europe, qui "bannissent" l'automobile ne font que la repousser de quelques centaines de mètres au mieux, ménageant des zones piétonnes hautement désirées mais dont on n'imagine même pas qu'elles puissent fonctionner sans l'automobile à son pourtour.

4- et nous nous arrêterons là provisoirement. 

a_comme on n'imagine plus revenir à un fonctionnement urbain où la mobilité, au moins celle des livraisons, des urgences, des personnes en cas d'intempéries etc. se passe de machines, on est donc bien face à un besoin technique.

b_comme le service attendu est non seulement exprimable mais connu, à savoir une ville sans nuisances et durable, reconquise par les circulations douces, une mobilité quantifiable, on a tous les éléments d'une expression de besoin, la première étape de l'ingénierie.

c_l'extrême confusion qui règne sur le sujet, l'application de solutions toujours plus dispendieuses pendant que le problème s'amplifie en tout point du globe, sont la marque indubitable d'une question mal/non posée.

d_il ne nous reste plus qu'à faire ce que proclament toutes les méthodologies reconnues : chercher la solution idéale au problème sans laisser les solutions existantes corrompre une démarche qui doit (il est temps) n'être que rationnelle.

e_on découvre, et sans surprise quand on a pratiqué AIDA :

- qu'il y a une solution

- qu'elle est simple et économique, et n'a pas besoin de technologies nouvelles

- qu'il est bienvenu d'avoir AIDA pour la réaliser proprement, mais qu'on pourrait y arriver en traditionnel

 - qu'on peut le faire rapidement. Nous détaillons notre proposition ici...

Contactez Paul Ortais pour en savoir plus.