Reinert, Dietmar AJ

Reinert, Dietmar AJ

Adresse : Berufsgenossenschaftliches Institut für Arbeitssicherheit, Alte Heerstrsse 111, 53754 Sankt Augustin

Pays : Allemagne

Téléphone: 49 2241 231 645

Télécopieur : 49 2241 231 234

Courriel : 100565.2233@compuserve.com

L'Education: BA, 1984, Université de Bonn; Dr rer nat, 1987, Université de Bonn

Centres d'intérêt: Systèmes électroniques programmables dans des applications liées à la sécurité ; logiciel sécurisé; dispositifs de protection pilotés par capteur

 

Lundi, Avril 04 2011 18: 00

Applications liées à la sécurité

Au cours des dernières années, les microprocesseurs ont joué un rôle de plus en plus important dans le domaine de la technologie de sécurité. Étant donné que des ordinateurs entiers (c'est-à-dire l'unité centrale de traitement, la mémoire et les composants périphériques) sont désormais disponibles dans un seul composant en tant qu '«ordinateurs à puce unique», la technologie des microprocesseurs est utilisée non seulement dans le contrôle de machines complexes, mais également dans des protections de conception relativement simple. (ex. barrières immatérielles, commandes bimanuelles et barres palpeuses). Le logiciel contrôlant ces systèmes comprend entre un millier et plusieurs dizaines de milliers de commandes simples et se compose généralement de plusieurs centaines de branches de programme. Les programmes fonctionnent en temps réel et sont principalement écrits dans le langage d'assemblage des programmeurs.

L'introduction de systèmes commandés par ordinateur dans le domaine de la technologie de sécurité s'est accompagnée dans tous les équipements techniques à grande échelle non seulement de projets de recherche et de développement coûteux, mais également de restrictions importantes destinées à améliorer la sécurité. (La technologie aérospatiale, la technologie militaire et la technologie de l'énergie atomique peuvent être citées ici comme exemples d'applications à grande échelle.) Le domaine collectif de la production industrielle de masse n'a jusqu'à présent été traité que de façon très limitée. Cela s'explique en partie par le fait que les cycles rapides d'innovation caractéristiques de la conception des machines industrielles rendent difficile la transmission, sauf d'une manière très restreinte, des connaissances pouvant découler de projets de recherche portant sur les essais finaux de machines à grande échelle. dispositifs de sécurité. Cela fait du développement de procédures d'évaluation rapides et peu coûteuses un desiderata (Reinert et Reuss 1991).

Cet article examine d'abord les machines et les installations dans lesquelles les systèmes informatiques exécutent actuellement des tâches de sécurité, en utilisant des exemples d'accidents survenus principalement dans le domaine des protections des machines pour décrire le rôle particulier que jouent les ordinateurs dans la technologie de sécurité. Ces accidents donnent des indications sur les précautions à prendre pour que les équipements de sécurité pilotés par ordinateur qui se généralisent actuellement n'entraînent pas une augmentation du nombre d'accidents. La dernière section de l'article esquisse une procédure qui permettra d'amener même de petits systèmes informatiques à un niveau approprié de sécurité technique à des frais justifiables et dans un délai acceptable. Les principes indiqués dans cette dernière partie sont actuellement introduits dans les procédures internationales de normalisation et auront des implications pour tous les domaines de la technologie de la sécurité dans lesquels les ordinateurs trouvent une application.

Exemples d'utilisation de logiciels et d'ordinateurs dans le domaine de la protection des machines

Les quatre exemples suivants montrent clairement que les logiciels et les ordinateurs entrent actuellement de plus en plus dans les applications liées à la sécurité dans le domaine commercial.

Les installations de signalisation d'urgence personnelle se composent, en règle générale, d'une station de réception centrale et d'un certain nombre d'appareils de signalisation d'urgence personnelle. Les appareils sont portés par des personnes travaillant seules sur site. Si l'une de ces personnes travaillant seule se trouve dans une situation d'urgence, elle peut utiliser l'appareil pour déclencher une alarme par signal radio dans la centrale de réception. Un tel déclencheur d'alarme dépendant de la volonté peut également être complété par un mécanisme de déclenchement indépendant de la volonté activé par des capteurs intégrés dans les dispositifs d'urgence personnels. Les appareils individuels et la station de réception centrale sont fréquemment contrôlés par des micro-ordinateurs. Il est concevable que la défaillance de certaines fonctions spécifiques de l'ordinateur intégré puisse conduire, dans une situation d'urgence, à l'échec du déclenchement de l'alarme. Des précautions doivent donc être prises pour percevoir et réparer cette perte de fonction dans le temps.

Les presses à imprimer utilisées aujourd'hui pour imprimer des magazines sont de grosses machines. Les bandes de papier sont normalement préparées par une machine séparée de manière à permettre une transition transparente vers un nouveau rouleau de papier. Les pages imprimées sont pliées par une plieuse et ensuite travaillées à travers une chaîne d'autres machines. Il en résulte des palettes chargées de magazines entièrement cousus. Bien que de telles installations soient automatisées, il y a deux points où des interventions manuelles doivent être faites : (1) dans le filetage des chemins de papier, et (2) dans le dégagement des obstructions causées par les déchirures de papier aux points dangereux sur les rouleaux rotatifs. Pour cette raison, une vitesse de fonctionnement réduite ou un mode pas à pas limité dans la trajectoire ou dans le temps doit être assuré par la technologie de commande pendant le réglage des presses. En raison de la complexité des procédures de pilotage, chaque poste d'impression doit être équipé de son propre automate programmable. Toute défaillance survenant dans la commande d'une imprimerie alors que les grilles de protection sont ouvertes doit être empêchée de conduire soit au démarrage intempestif d'une machine arrêtée, soit à un fonctionnement au-delà des vitesses réduites de manière appropriée.

Dans les grandes usines et les entrepôts, des robots guidés automatisés sans conducteur circulent sur des pistes spécialement balisées. Ces voies peuvent être piétinées à tout moment par des personnes, ou des matériaux et des équipements peuvent être laissés par inadvertance sur les voies, car elles ne sont pas séparées structurellement des autres voies de circulation. Pour cette raison, une sorte d'équipement de prévention des collisions doit être utilisé pour s'assurer que le véhicule sera arrêté avant qu'une collision dangereuse avec une personne ou un objet ne se produise. Dans des applications plus récentes, la prévention des collisions est effectuée au moyen de scanners à ultrasons ou à lumière laser utilisés en combinaison avec un pare-chocs de sécurité. Comme ces systèmes fonctionnent sous contrôle informatique, il est possible de configurer plusieurs zones de détection permanentes afin qu'un véhicule puisse modifier sa réaction en fonction de la zone de détection spécifique dans laquelle se trouve une personne. Les défaillances du dispositif de protection ne doivent pas entraîner de collision dangereuse avec une personne.

Les guillotines des dispositifs de contrôle de la coupe du papier sont utilisées pour presser puis couper des piles de papier épaisses. Ils sont déclenchés par un dispositif de commande à deux mains. L'utilisateur doit atteindre la zone dangereuse de la machine après chaque coupe. Une protection immatérielle, généralement une grille lumineuse, est utilisée en conjonction avec le dispositif de commande bimanuelle et un système de commande de machine sûr pour éviter les blessures lorsque le papier est alimenté pendant l'opération de coupe. Presque toutes les guillotines plus grandes et plus modernes utilisées aujourd'hui sont contrôlées par des systèmes de micro-ordinateurs multicanaux. La commande bimanuelle et la grille immatérielle doivent également être garanties pour fonctionner en toute sécurité.

Accidents avec des systèmes contrôlés par ordinateur

Dans presque tous les domaines d'application industrielle, des accidents avec des logiciels et des ordinateurs sont signalés (Neumann 1994). Dans la plupart des cas, les pannes informatiques n'entraînent pas de blessures aux personnes. De tels manquements ne sont en tout état de cause rendus publics que lorsqu'ils présentent un intérêt public général. Cela signifie que les cas de dysfonctionnement ou d'accident liés aux ordinateurs et aux logiciels entraînant des blessures corporelles représentent une proportion relativement élevée de tous les cas rendus publics. Malheureusement, les accidents qui ne provoquent pas beaucoup de sensations publiques ne font pas l'objet d'enquêtes quant à leurs causes avec la même intensité que les accidents plus importants, généralement dans les usines à grande échelle. Pour cette raison, les exemples qui suivent se réfèrent à quatre descriptions de dysfonctionnements ou d'accidents typiques des systèmes commandés par ordinateur en dehors du domaine de la sécurité des machines, qui sont utilisées pour suggérer ce qu'il faut prendre en compte lors des jugements concernant la technologie de sécurité.

Accidents causés par des pannes aléatoires du matériel

L'accident suivant a été causé par une concentration de pannes aléatoires dans le matériel combinées à un échec de programmation : Un réacteur surchauffé dans une usine chimique, après quoi des soupapes de décharge ont été ouvertes, permettant au contenu du réacteur d'être rejeté dans l'atmosphère. Cet incident s'est produit peu de temps après qu'un avertissement eut été donné indiquant que le niveau d'huile d'une boîte de vitesses était trop bas. Une enquête minutieuse sur l'accident a montré que peu de temps après que le catalyseur ait initié la réaction dans le réacteur - en conséquence de quoi le réacteur aurait nécessité plus de refroidissement - l'ordinateur, sur la base du rapport de faibles niveaux d'huile dans la boîte de vitesses, a gelé tout grandeurs sous son contrôle à une valeur fixe. Cela a maintenu le débit d'eau froide à un niveau trop bas et le réacteur a ainsi surchauffé. Une enquête plus approfondie a montré que l'indication de bas niveaux d'huile avait été signalée par un composant défectueux.

Le logiciel avait répondu conformément à la spécification avec le déclenchement d'une alarme et la fixation de toutes les variables opératoires. C'était une conséquence de l'étude HAZOP (analyse des dangers et de l'opérabilité) (Knowlton 1986) réalisée avant l'événement, qui exigeait que toutes les variables contrôlées ne soient pas modifiées en cas de défaillance. Le programmeur ne connaissant pas la procédure en détail, cette exigence a été interprétée comme signifiant que les actionneurs commandés (vannes de commande dans ce cas) ne devaient pas être modifiés ; aucune attention n'a été accordée à la possibilité d'une élévation de la température. Le programmeur n'a pas pris en considération qu'après avoir reçu un signal erroné le système pouvait se retrouver dans une situation dynamique d'un type nécessitant l'intervention active de l'ordinateur pour éviter un accident. La situation qui a conduit à l'accident était d'ailleurs si improbable qu'elle n'avait pas été analysée en détail dans l'étude HAZOP (Levenson 1986). Cet exemple permet de passer à une deuxième catégorie de causes d'accidents logiciels et informatiques. Ce sont les pannes systématiques qui sont dans le système depuis le début, mais qui ne se manifestent que dans certaines situations bien précises dont le développeur n'a pas tenu compte.

Accidents causés par des pannes de fonctionnement

Lors d'essais sur le terrain lors de l'inspection finale des robots, un technicien a emprunté la cassette d'un robot voisin et l'a remplacée par une autre sans en informer son collègue. De retour sur son lieu de travail, le collègue insère la mauvaise cassette. Comme il se tenait à côté du robot et s'attendait à une séquence particulière de mouvements de sa part - une séquence qui se déroulait différemment en raison du programme échangé - une collision s'est produite entre le robot et l'humain. Cet accident décrit l'exemple classique d'une panne de fonctionnement. Le rôle de ces défaillances dans les dysfonctionnements et les accidents augmente actuellement en raison de la complexité croissante de l'application des mécanismes de sécurité contrôlés par ordinateur.

Accidents causés par des défaillances systématiques du matériel ou des logiciels

Une torpille à ogive devait être tirée à des fins d'entraînement, depuis un navire de guerre en haute mer. En raison d'un défaut de l'appareil d'entraînement, la torpille est restée dans le tube lance-torpilles. Le capitaine a décidé de retourner au port d'attache afin de récupérer la torpille. Peu de temps après que le navire ait commencé à rentrer chez lui, la torpille a explosé. Une analyse de l'accident a révélé que les développeurs de la torpille avaient été obligés d'intégrer à la torpille un mécanisme destiné à empêcher qu'elle ne revienne sur la rampe de lancement après avoir été tirée et détruise ainsi le navire qui l'avait lancée. Le mécanisme choisi pour cela était le suivant : Après le tir de la torpille, on vérifiait, à l'aide de la centrale de navigation inertielle, si sa trajectoire s'était modifiée de 180°. Dès que la torpille a senti qu'elle avait tourné à 180 °, la torpille a explosé immédiatement, soi-disant à une distance de sécurité de la rampe de lancement. Ce mécanisme de détection a été actionné dans le cas de la torpille qui n'avait pas été correctement lancée, de sorte que la torpille a explosé après que le navire eut changé de cap de 180°. Il s'agit d'un exemple typique d'accident survenu en raison d'un défaut de spécification. L'exigence du cahier des charges selon laquelle la torpille ne devait pas détruire son propre navire en cas de changement de cap n'était pas formulée avec suffisamment de précision; la précaution a donc été programmée par erreur. L'erreur n'est apparue que dans une situation particulière, une situation que le programmeur n'avait pas considérée comme une possibilité.

Le 14 septembre 1993, un Airbus A 320 de la Lufthansa s'écrase lors de son atterrissage à Varsovie (figure 1). Une enquête minutieuse sur l'accident a montré que des modifications de la logique d'atterrissage de l'ordinateur de bord effectuées après un accident avec un Boeing 767 de Lauda Air en 1991 étaient en partie responsables de cet atterrissage forcé. Ce qui s'était passé lors de l'accident de 1991, c'est que la déviation de poussée, qui détourne une partie des gaz du moteur afin de freiner l'avion lors de l'atterrissage, s'était engagée alors qu'elle était encore en l'air, forçant ainsi la machine à piquer du nez incontrôlable. Pour cette raison, un verrouillage électronique de la déviation de poussée avait été intégré dans les machines Airbus. Ce mécanisme a permis à la déviation de poussée de n'entrer en vigueur qu'après que les capteurs des deux ensembles de trains d'atterrissage aient signalé la compression des amortisseurs sous la pression des roues touchant le sol. Sur la base d'informations erronées, les pilotes de l'avion à Varsovie ont anticipé un fort vent latéral.

Figure 1. Airbus de Lufthansa après un accident à Varsovie en 1993

ACC260F2

Pour cette raison, ils ont amené la machine avec une légère inclinaison et l'Airbus s'est posé avec la roue droite uniquement, laissant la gauche portant moins que le poids total. Du fait du verrouillage électronique du braquage de poussée, l'ordinateur de bord a refusé au pilote pendant neuf secondes les manœuvres qui auraient permis à l'avion d'atterrir en toute sécurité malgré des circonstances défavorables. Cet accident démontre très clairement que des modifications de systèmes informatiques peuvent conduire à des situations nouvelles et dangereuses si l'on ne considère pas à l'avance l'étendue de leurs conséquences possibles.

 

L'exemple de dysfonctionnement suivant montre également les effets désastreux que la modification d'une seule commande peut avoir sur les systèmes informatiques. La teneur en alcool du sang est déterminée, par des tests chimiques, à l'aide de sérum sanguin clair dont les globules sanguins ont été préalablement centrifugés. La teneur en alcool du sérum est donc plus élevée (d'un facteur 1.2) que celle du sang total plus épais. Pour cette raison, les valeurs d'alcool dans le sérum doivent être divisées par un facteur de 1.2 afin d'établir les parties pour mille légalement et médicalement critiques. Lors du test inter-laboratoires organisé en 1984, les taux d'alcoolémie déterminés lors de tests identiques effectués dans différents instituts de recherche utilisant du sérum devaient être comparés les uns aux autres. Comme il ne s'agissait que de comparaison, l'ordre de diviser par 1.2 a d'ailleurs été effacé du programme d'un des établissements pour la durée de l'expérimentation. Après la fin de l'essai interlaboratoires, une commande de multiplication par 1.2 a été introduite par erreur dans le programme à cet endroit. En conséquence, environ 1,500 1984 valeurs incorrectes de parties pour mille ont été calculées entre août 1985 et mars 1.0. Cette erreur était critique pour la carrière professionnelle des camionneurs dont le taux d'alcoolémie se situait entre 1.3 et 1.3 pour mille, puisqu'une sanction légale entraînant la confiscation du permis de conduire pour une période prolongée est la conséquence d'une valeur de XNUMX pour mille.

Accidents causés par des influences de contraintes de fonctionnement ou de contraintes environnementales

Suite à une perturbation causée par la collecte de déchets dans la zone effective d'une poinçonneuse et grignoteuse CNC (commande numérique par ordinateur), l'utilisateur a déclenché "l'arrêt programmé". Alors qu'il tentait d'enlever les déchets avec ses mains, la tige de poussée de la machine s'est mise à bouger malgré l'arrêt programmé et a gravement blessé l'utilisateur. L'analyse de l'accident a révélé qu'il ne s'agissait pas d'une erreur de programme. Le démarrage inattendu n'a pas pu être reproduit. Des irrégularités similaires avaient été observées par le passé sur d'autres machines du même type. Il semble plausible d'en déduire que l'accident doit avoir été causé par des interférences électromagnétiques. Des accidents similaires avec des robots industriels sont signalés au Japon (Neumann 1987).

Un dysfonctionnement de la sonde spatiale Voyager 2 le 18 janvier 1986 rend encore plus claire l'influence des contraintes environnementales sur les systèmes contrôlés par ordinateur. Six jours avant l'approche la plus proche d'Uranus, de grands champs de lignes noires et blanches couvraient les images de Voyager 2. Une analyse précise a montré qu'un seul bit dans un mot de commande du sous-système de données de vol avait causé la panne, observée comme les images ont été compressées dans la sonde. Ce bit avait très probablement été déplacé dans la mémoire du programme par l'impact d'une particule cosmique. La transmission sans erreur des photographies compressées de la sonde n'a été effectuée que deux jours plus tard, en utilisant un programme de remplacement capable de contourner le point mémoire défaillant (Laeser, McLaughlin et Wolff 1987).

Résumé des accidents présentés

Les accidents analysés montrent que certains risques qui pourraient être négligés dans des conditions utilisant une technologie électromécanique simple, gagnent en importance avec l'utilisation d'ordinateurs. Les ordinateurs permettent le traitement de fonctions de sécurité complexes et spécifiques à la situation. Une spécification claire, sans erreur, complète et testable de toutes les fonctions de sécurité devient donc particulièrement importante. Les erreurs dans les spécifications sont difficiles à découvrir et sont souvent la cause d'accidents dans les systèmes complexes. Les commandes librement programmables sont généralement introduites dans le but de pouvoir réagir de manière flexible et rapide à l'évolution du marché. Cependant, les modifications, en particulier dans les systèmes complexes, ont des effets secondaires difficiles à prévoir. Toutes les modifications doivent donc être soumises à une procédure de gestion des modifications strictement formelle dans laquelle une séparation claire des fonctions de sécurité des systèmes partiels sans rapport avec la sécurité aidera à garder les conséquences des modifications pour la technologie de sécurité faciles à étudier.

Les ordinateurs fonctionnent avec de faibles niveaux d'électricité. Ils sont donc sensibles aux interférences provenant de sources de rayonnement externes. La modification d'un seul signal parmi des millions pouvant entraîner un dysfonctionnement, il convient de porter une attention particulière au thème de la compatibilité électromagnétique en lien avec les ordinateurs.

La maintenance des systèmes commandés par ordinateur devient actuellement de plus en plus complexe et donc de plus en plus floue. L'ergonomie logicielle des logiciels d'utilisation et de configuration devient donc plus intéressante du point de vue de la technique de sécurité.

Aucun système informatique n'est testable à 100 %. Un mécanisme de contrôle simple avec 32 ports d'entrée binaires et 1,000 4.3 chemins logiciels différents nécessite 10 × XNUMX12 tests pour un contrôle complet. A raison de 100 tests par seconde exécutés et évalués, un test complet prendrait 1,362 XNUMX ans.

Procédures et mesures pour l'amélioration des dispositifs de sécurité contrôlés par ordinateur

Des procédures ont été développées au cours des 10 dernières années qui permettent de maîtriser des enjeux spécifiques de sécurité liés à l'informatique. Ces procédures s'adressent aux pannes informatiques décrites dans cette section. Les exemples décrits de logiciels et d'ordinateurs dans la protection des machines et les accidents analysés montrent que l'étendue des dommages et donc aussi le risque encouru dans diverses applications sont extrêmement variables. Il est donc clair que les précautions nécessaires à l'amélioration des ordinateurs et des logiciels utilisés dans les techniques de sécurité doivent être établies en fonction du risque.

La figure 2 montre une procédure qualitative par laquelle la réduction de risque nécessaire pouvant être obtenue à l'aide de systèmes de sécurité peut être déterminée indépendamment de l'ampleur et de la fréquence des dommages (Bell et Reinert 1992). Les types de défaillances des systèmes informatiques analysés dans la section « Accidents avec des systèmes contrôlés par ordinateur » (ci-dessus) peuvent être mis en relation avec ce que l'on appelle les niveaux d'intégrité de sécurité, c'est-à-dire les installations techniques de réduction des risques.

Figure 2. Procédure qualitative de détermination des risques

ACC260F3

La figure 3 montre clairement que l'efficacité des mesures prises, dans un cas donné, pour réduire les erreurs dans les logiciels et les ordinateurs doit croître avec l'augmentation du risque (DIN 1994 ; IEC 1993).

Figure 3, Efficacité des précautions prises contre les erreurs indépendamment du risque

ACC260F4

L'analyse des accidents esquissée ci-dessus montre que la défaillance des sauvegardes pilotées par ordinateur est causée non seulement par des défauts aléatoires de composants, mais également par des conditions de fonctionnement particulières dont le programmeur n'a pas tenu compte. Les conséquences non immédiatement évidentes des modifications du programme effectuées au cours de la maintenance du système constituent une autre source d'erreur. Il s'ensuit qu'il peut y avoir des défaillances dans les systèmes de sécurité commandés par des microprocesseurs qui, bien que réalisées lors de la mise au point du système, ne peuvent conduire à une situation dangereuse qu'en cours de fonctionnement. Des précautions contre de telles défaillances doivent donc être prises pendant que les systèmes liés à la sécurité sont en phase de développement. Ces mesures dites d'évitement des pannes doivent être prises non seulement pendant la phase de conception, mais également pendant le processus de développement, d'installation et de modification. Certaines défaillances peuvent être évitées si elles sont découvertes et corrigées au cours de ce processus (DIN 1990).

Comme le montre clairement le dernier incident décrit, la panne d'un seul transistor peut entraîner la défaillance technique d'équipements automatisés très complexes. Étant donné que chaque circuit unique est composé de plusieurs milliers de transistors et d'autres composants, de nombreuses mesures d'évitement des pannes doivent être prises pour reconnaître de telles pannes qui se produisent en fonctionnement et pour initier une réaction appropriée dans le système informatique. La figure 4 décrit les types de pannes dans les systèmes électroniques programmables ainsi que des exemples de précautions qui peuvent être prises pour éviter et contrôler les pannes dans les systèmes informatiques (DIN 1990 ; CEI 1992).

Figure 4. Exemples de précautions prises pour contrôler et éviter les erreurs dans les systèmes informatiques

ACC260F5

Possibilités et perspectives des systèmes électroniques programmables dans les technologies de sécurité

Les machines et installations modernes deviennent de plus en plus complexes et doivent accomplir des tâches de plus en plus complètes dans des délais de plus en plus courts. Pour cette raison, les systèmes informatiques ont envahi presque tous les domaines de l'industrie depuis le milieu des années 1970. Cette augmentation de la complexité à elle seule a contribué de manière significative à l'augmentation des coûts impliqués dans l'amélioration de la technologie de sécurité dans de tels systèmes. Bien que les logiciels et les ordinateurs représentent un grand défi pour la sécurité sur le lieu de travail, ils permettent également la mise en œuvre de nouveaux systèmes sans erreur dans le domaine de la technologie de sécurité.

Un vers drôle mais instructif d'Ernst Jandl aidera à expliquer ce que l'on entend par le concept erreur facile. "Lichtung: Manche meinen lechts und rinks kann man nicht velwechsern, werch ein Illtum". ("Dilection: Beaucoup croient que la lumière et le repos ne peuvent pas être échangés, quel ellol".) Malgré l'échange des lettres r et l, cette phrase est facilement compréhensible par un humain adulte normal. Même quelqu'un avec une faible maîtrise de la langue anglaise peut le traduire en anglais. La tâche est cependant presque impossible pour un ordinateur de traduction seul.

Cet exemple montre qu'un être humain peut réagir d'une manière beaucoup plus favorable aux erreurs qu'un ordinateur de langage. Cela signifie que les humains, comme toutes les autres créatures vivantes, peuvent tolérer les échecs en les référant à l'expérience. Si l'on regarde les machines en usage aujourd'hui, on constate que la majorité des machines pénalisent les défaillances des utilisateurs non pas par un accident, mais par une baisse de production. Cette propriété conduit à la manipulation ou au contournement des garanties. La technologie informatique moderne met à la disposition de la sécurité au travail des systèmes capables de réagir intelligemment, c'est-à-dire de manière modifiée. De tels systèmes permettent ainsi un mode de comportement sans erreur dans les nouvelles machines. Ils avertissent d'abord les utilisateurs lors d'une mauvaise manipulation et n'arrêtent la machine que lorsque c'est le seul moyen d'éviter un accident. L'analyse des accidents montre qu'il existe dans ce domaine un potentiel considérable de réduction des accidents (Reinert et Reuss 1991).

 

Retour

" AVIS DE NON-RESPONSABILITÉ : L'OIT n'assume aucune responsabilité pour le contenu présenté sur ce portail Web qui est présenté dans une langue autre que l'anglais, qui est la langue utilisée pour la production initiale et l'examen par les pairs du contenu original. Certaines statistiques n'ont pas été mises à jour depuis la production de la 4ème édition de l'Encyclopédie (1998)."

Table des matières