Article de référence | Réf : BM8071 v1

Défaillance logicielle
Sécurisation des systèmes mécatroniques. Partie 2 - Techniques de mises en sécurité d'une application logicielle

Auteur(s) : Jean-Louis BOULANGER

Date de publication : 10 janv. 2011

Pour explorer cet article
Télécharger l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !

Sommaire

Présentation

Version en anglais En anglais

RÉSUMÉ

Les systèmes mécatroniques sont de plus en plus complexes. Ils induisent par voie de conséquence de multiples défaillances. La sécurisation de ces systèmes vise à combattre ces erreurs et à tenter d'en limiter le risque. Cet article s'intéresse à l'aspect application logicielle, dont la sécurité passe par la maîtrise de la qualité. Sont présentées quelques techniques de programmation tolérante (redondance, détection d'ereurs ou programmation défensive). Les fautes sont souvent dues au caractère artisanal de la réalisation d'une application logicielle, et l'utilisation d'outils d'un environnement de développement ne retire pas au logiciel sa complexité intrinsèque.

Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.

Lire l’article

ABSTRACT

Mechatronic systems are becoming increasingly complex. As a result they induce multiple failures. Securing these systems is aimed at combating these errors and attempting to limit the risk. This article focuses on the software application aspect on which the security relies on quality control. Fault-tolerant programming techniques (redundancy, error detection or defensive programming) are presented. Errors are often due to the artisanal nature of the implementation of a software application, and the use of tools from a development environment that detracts from the software’s inherent complexity.

Auteur(s)

INTRODUCTION

Dans cette seconde partie [BM 8071] sur la sécurisation des systèmes mécatroniques, nous nous intéressons à l'aspect « application logicielle » (composante informatique). Le risque lié à l'architecture matérielle (composante électronique) ayant été traité dans la première partie [BM 8 070]. Pour ce qui concerne les concepts de base et les normes applicables à la sécurisation des systèmes mécatroniques, le lecteur se reportera également en [BM 8 070].

La sécurité d'une application logicielle passe principalement par la maîtrise de la qualité (évitement et élimination des fautes). Nous présentons :

  • les principes de la maîtrise de la qualité (ISO 9001:2000) ;

  • quelques techniques de programmation tolérante (la redondance, la détection d'erreur ou la programmation défensive) ;

  • l'apport des méthodes formelles.

La réalisation d'une application logicielle est actuellement une activité à la portée de tous. La mise à disposition d'environnements de développement (Case Tools , cf. [Doc. BM 8 070]), proposant la modélisation, des vérifications et la génération automatique de code, a grandement simplifié le développement d'une application logicielle. Mais la principale particularité du logiciel est la présence de fautes (bug ). Ces fautes peuvent être systématiquement exécutées et leur présence est due au caractère artisanal de la réalisation d'une application logicielle. L'utilisation d'environnements de développement donne l'impression d'industrialiser la réalisation d'une application logicielle mais il n'en est rien. En effet, les outils d'un environnement de développement sont développés classiquement et leur utilisation a tendance à faire oublier la complexité intrinsèque du logiciel au travers de représentations graphiques plus ou moins claires. La présence de fautes est un fait et il faut soit les accepter, soit les gérer, soit les corriger.

Cet article est réservé aux abonnés.
Il vous reste 94% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

DOI (Digital Object Identifier)

https://doi.org/10.51257/a-v1-bm8071


Cet article fait partie de l’offre

Métier : responsable bureau d’étude/conception

(371 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS

Version en anglais En anglais

1. Défaillance logicielle

Dans le cadre d'une application logicielle, nous dirons qu'il y a défaillance dès que le comportement de l'application logicielle n'est pas conforme à sa spécification. Cela signifie que la défaillance d'une application logicielle est détectable au travers de l'analyse des sorties de l'application.

Étant donné qu'une application logicielle ne s'use pas (pas de dégradation) mais qu'elle peut vieillir, la défaillance d'une application est donc systématique. Une défaillance est liée à une ou des erreurs. Les erreurs sont internes à l'application logicielle et sont la conséquence de la propagation d'autres erreurs ou de l'activation d'une faute. Une faute est localisée précisément dans une partie de l'application logicielle. L'activation de la faute génère une erreur qui peut avoir pour conséquence une défaillance ou la propagation d'erreur. Il est à noter que l'origine de la faute est :

  • humaine (frappe de « + » au lieu de « – ») ;

  • matérielle (un bit mémoire bloqué à 1) ;

  • due à un phénomène extérieur (évolution de bit lié à la mémoire du programme ou des données suite à une perturbation produite par un champ CEM et/ou à une particule).

L'environnement de développement d'une application logicielle se compose :

  • des bibliothèques ;

  • des logiciels de base ;

  • des utilitaires ;

  • d'un système d'exploitation ;

  • d'outils supports (compilateur, outil de téléchargement, outils de tests, générateurs de code...) ;

  • d'une architecture matérielle.

Chaque élément de l'environnement peut être défaillant et donc peut générer des fautes au sein de l'application logicielle.

HAUT DE PAGE

Cet article est réservé aux abonnés.
Il vous reste 93% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

Cet article fait partie de l’offre

Métier : responsable bureau d’étude/conception

(371 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS

Lecture en cours
Défaillance logicielle
Sommaire
Sommaire

BIBLIOGRAPHIE

  • (1) - ABRIAL (Jr.) -   The B book – Assigning programs to meanings.  -  Cambridge University Press, Cambridge, août 1996.

  • (2) - BALEANI (M.), FERRARI (A.), MANGERUCA (L.), PERI (M.), PEZZINI (S.) -   Fault-tolerant platforms for automotive safety critical applications.  -  Proceedings of the 2003 international conference on Compilers, architecture and synthesis for embedded systems, p. 170-177 (2003).

  • (3) - BIED-CHARRETON (D.) -   Concepts de mise en sécurité des architectures informatiques.  -  Recherche Transports Sécurité, no 64, p. 21-36, juil.-sept. 1999.

  • (4) - DUFOUR (J.L.) -   Automotive safety concepts : 10-9/h for less than 100E a piece.  -  Automation, Assistence and Embedded Real Time Platforms for Transportation, AAET, Braunschweig, Allemagne, 16-17 fév. 2005.

  • (5) - GEORGES (J.P.) -   Principes et fonctionnement du Système d'Aide à la Conduite, à l'Exploitation et à la Maintenance (SACEM). Application à la ligne A du RER.  -  Revue Générale des Chemins de Fer, no 6, juin 1990.

  • ...

Cet article est réservé aux abonnés.
Il vous reste 93% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

Cet article fait partie de l’offre

Métier : responsable bureau d’étude/conception

(371 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS