La tolérance de panne

Il y a des systèmes informatiques dont des arrêts de courte durée pour cause de réparation sont acceptables, d'autres avec lesquels il faut l'éviter impérativement (réseaux bancaires, commande de processus industriels, centrales nucléaires…). Pour se protéger des anomalies matérielles, l'idée de la tolérance de panne a été développée. Le principe est d'avoir des choses en double dans les appareils : si le premier élément lâche brusquement, son jumeau prend le relais (il est très improbable que les 2 soient défectueux au même moment). Cela peut être 2 systèmes complets accolés ou un système où les éléments critiques existe en plusieurs exemplaires (une panne n'arrêtera pas la machine entière). De telles précautions impliquent évidemment un surcoût et elles ne sont utilisées que dans les cas où cela est nécessaire.

Pour ce qui est des logiciels, sans lesquels un ordinateur n'est qu'un meuble encombrant, il n'y a pas non plus de raison de croire à une fiabilité absolue. La différence est tout de même qu'un programme ne s'usera pas à l'usage. Un défaut qui apparaîtra un jour aura toujours été présent. Fort heureusement, avec différents systèmes d'exploitation il est possible d'employer des applications faisant fonctionner des processus en parallèle (multithreading). On pourra alors avoir au moins 2 processus qui devront réaliser exactement la même fonction. Ils auront été développés par des équipes différentes en apportant un soin tout particulier à la fiabilité - comme les composants matériels doivent logiquement être choisis selon ce critère. Il devrait y en avoir plus de 2 dans le cas où l'ordinateur doit déterminer lui-même immédiatement lequel est défectueux. En multipliant les processus il faut bien sûr aussi multiplier la puissance de traitement mais cela va dans le sens de l'évolution de l'électronique numérique.

Pour le suivi de la fiabilité il faut qu'une partie du logiciel vérifie la concordance des résultats fournis par les processus parallèles. Celle ci peut aussi signaler des pannes potentielles à partir de décalages minimes, ce qui signifierait qu'il faut réexaminer des parties des sources des programmes. En fait cette comparaison du comportement de portions d'une application pourrait être réalisée à chaque étape de sa mise au point.