« Système critique » : différence entre les versions
Contenu supprimé Contenu ajouté
m Retrait de 3 liens interlangues, désormais fournis par Wikidata sur la page d:q1996307 |
ajout d'un lien |
||
| (23 versions intermédiaires par 19 utilisateurs non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
[[Fichier:C-141C Glass Cockpit Upgrade.JPEG|vignette|Le [[Poste de pilotage]] d'un [[Lockheed C-141 Starlifter]] est un exemple de système critique.]] |
|||
Un '''système critique''' est un système dont |
Un '''système critique''' est un système dont la panne peut avoir des conséquences dramatiques, comme des morts ou des blessés graves, des dégâts matériels importants, ou des conséquences graves pour l'[[environnement]]. L'analyse des systèmes critiques ne se limite pas à celle que permet, aujourd'hui de plus en plus, l'informatique de contrôle des processus, fussent-ils mécaniques ou humains. |
||
== Domaines critiques == |
== Domaines critiques == |
||
Dans le monde de l'informatique, les logiciels qualifiés de |
Dans le monde de l'informatique, les logiciels qualifiés de « critiques » se retrouvent par exemple dans : |
||
* les ''[[systèmes de transport]]'' : pilotage des [[avion]]s, des [[train]]s, [[logiciels embarqués]] automobiles ; |
* les ''[[systèmes de transport]]'' : pilotage des [[avion]]s, des [[train]]s, [[logiciels embarqués]] automobiles ; |
||
* la ''production d'[[énergie]]'' : |
* la ''production d'[[énergie]]'' : contrôle des [[centrale nucléaire|centrales nucléaires]] ; |
||
* la ''[[santé]]'' : chaînes de production de médicaments, appareil médicaux (à rayonnement ou contrôle de dosages) ; |
* la ''[[santé]]'' : chaînes de production de médicaments, appareil médicaux (à rayonnement ou contrôle de dosages) ; |
||
* le ''système financier'' : paiement électronique ; |
* le ''système financier'' : paiement électronique ; |
||
* les applications militaires |
* les applications militaires. |
||
| ⚫ | |||
| ⚫ | |||
== Niveaux de criticité == |
== Niveaux de criticité == |
||
=== |
=== Évaluation === |
||
Il existe différents niveaux de criticité d'un système, suivant l'impact possible des dysfonctionnements. On apprécie ainsi différemment, par exemple, un dysfonctionnement provoquant des pertes coûteuses, mais sans mort d'homme (cas des missions spatiales non habitées) <!--[pas confirmé], un dysfonctionnement provoquant des pertes humaines modérées de volontaires (cas des missions spatiales habitées, des vols militaires)--> et un dysfonctionnement provoquant des morts dans le grand public (cas des vols commerciaux). De même, on apprécie différemment des dysfonctionnements faisant courir un danger de mort ou de blessure à des humains, ou des dysfonctionnements augmentant la charge de travail et les risques d'erreur de pilotage des opérateurs humains. |
Il existe différents niveaux de criticité d'un système, suivant l'impact possible des dysfonctionnements. On apprécie ainsi différemment, par exemple, un dysfonctionnement provoquant des pertes coûteuses, mais sans mort d'homme (cas des missions spatiales non habitées) <!--[pas confirmé], un dysfonctionnement provoquant des pertes humaines modérées de volontaires (cas des missions spatiales habitées, des vols militaires)--> et un dysfonctionnement provoquant des morts dans le grand public (cas des vols commerciaux). De même, on apprécie différemment des dysfonctionnements faisant courir un danger de mort ou de blessure à des humains, ou des dysfonctionnements augmentant la charge de travail et les risques d'erreur de pilotage des opérateurs humains. |
||
=== Cas particulier de l'aviation === |
=== Cas particulier de l'aviation === |
||
{{article détaillé | Sûreté de fonctionnement des logiciels aérospatiaux }} |
|||
En [[aviation]], la norme [[DO-178B]] sépare les logiciels [[avionique]]s en 5 catégories : |
En [[aviation]], la norme [[DO-178B]] sépare les logiciels [[avionique]]s en 5 catégories : |
||
* ''niveau A'' : un dysfonctionnement du logiciel provoquerait ou contribuerait à une condition de perte catastrophique de l'appareil ; |
* ''niveau A'' : un dysfonctionnement du logiciel provoquerait ou contribuerait à une condition de perte catastrophique de l'appareil ; |
||
| Ligne 31 : | Ligne 30 : | ||
=== Conséquences sur la sécurité === |
=== Conséquences sur la sécurité === |
||
La criticité du système définit un niveau d'[[exigence]] par rapport à la [[tolérance aux pannes]]. Elle aura des conséquences sur l'[[Evaluation Assurance Level|évaluation des niveaux d'assurance]] pour la [[sécurité du système d'information|sécurité]]. |
La criticité du système définit un niveau d'[[exigence (ingénierie)|exigence]] par rapport à la [[tolérance aux pannes]]. Elle aura des conséquences sur l'[[Evaluation Assurance Level|évaluation des niveaux d'assurance]] pour la [[sécurité du système d'information|sécurité]]. |
||
== Logiciel critique == |
== Logiciel critique == |
||
| Ligne 44 : | Ligne 43 : | ||
Les précautions à prendre dans le [[Développement de logiciel|développement]] sont généralement fixées par une norme, et dépendent du domaine d'application et surtout de la criticité du logiciel. Généralement, on trouve des impératifs : |
Les précautions à prendre dans le [[Développement de logiciel|développement]] sont généralement fixées par une norme, et dépendent du domaine d'application et surtout de la criticité du logiciel. Généralement, on trouve des impératifs : |
||
* de documentation : tous les composants doivent être documentés, notamment dans l'[[interface]] qu'ils présentent aux autres composants ; |
* de documentation : tous les composants doivent être documentés, notamment dans l'[[interface (informatique)#En électronique|interface]] qu'ils présentent aux autres composants ; |
||
* de traçabilité : le système doit répondre à chaque [[spécification]], soit dans sa mise en œuvre, soit dans des spécifications intermédiaires (auquel il faudra aussi répondre) ; on doit donc avoir une chaîne complète de traçabilité entre les spécifications fonctionnelles et la [[mise en œuvre]] du système ; |
* de traçabilité : le système doit répondre à chaque [[spécification (norme technique)|spécification]], soit dans sa mise en œuvre, soit dans des spécifications intermédiaires (auquel il faudra aussi répondre) ; on doit donc avoir une chaîne complète de traçabilité entre les spécifications fonctionnelles et la [[mise en œuvre]] du système ; |
||
* de limitation des pratiques dangereuses : certaines techniques de programmations, sources possibles de problèmes, sont interdites, ou du moins leur usage doit être justifié par des raisons impératives (ex. : [[Allocation de mémoire|allocation]] dynamique de mémoire, [[Récursivité|procédures récursives]]) ; |
* de limitation des pratiques dangereuses : certaines techniques de programmations, sources possibles de problèmes, sont interdites, ou du moins leur usage doit être justifié par des raisons impératives (ex. : [[Allocation de mémoire|allocation]] dynamique de mémoire, [[Récursivité|procédures récursives]]) ; |
||
* de [[test (informatique)|test]] : on devra essayer le logiciel dans un grand nombre de configurations, qui couvrent tous les points et un maximum des chemins de fonctionnement du programme ; |
* de [[test (informatique)|test]] : on devra essayer le logiciel dans un grand nombre de configurations, qui couvrent tous les points et un maximum des chemins de fonctionnement du programme ; |
||
* d'utilisation d'outils de développement et de vérification eux-mêmes sûrs. |
* d'utilisation d'outils de développement et de vérification eux-mêmes sûrs. |
||
=== Contraintes d'exploitation === |
|||
La mise en œuvre de systèmes critiques implique une adaptation de l'architecture physique dans une optique de fiabilité et de sécurisation. L'architecture doit répondre aux risques identifiés. |
|||
La fiabilité passe par un [[Plan de continuité d'activité (informatique)|plan de continuité d'activité]] et des infrastructures adaptés. Des exemples de mesure sont : |
|||
* [[Redondance des matériels|redondance]] des systèmes ; |
|||
* [[Durcissement (électronique)|durcissement]] des équipements. |
|||
La sécurité peut être renforcée par: |
|||
* l'emploi de systèmes d'[[authentification forte]] |
|||
* l'isolation des systèmes critiques, par l'usage d'une architecture [[Réseau privé virtuel|VPN]], voire « [[air gap (informatique)|air gap]] » |
|||
* la protection physique des équipements (bâtiments sécurisés, contrôle des accès physiques...) |
|||
== Certification == |
== Certification == |
||
| Ligne 60 : | Ligne 72 : | ||
* [[Profil d'application]] |
* [[Profil d'application]] |
||
* [[Analyse décisionnelle des systèmes complexes]] (méthode de conception de systèmes critiques) |
* [[Analyse décisionnelle des systèmes complexes]] (méthode de conception de systèmes critiques) |
||
* [[Capella (ingénierie)|Capella]] - atelier de modélisation des architectures système, logicielles et matérielles |
|||
== Bibliographie == |
|||
* {{en}} [http://www.cs.virginia.edu/~jck/publications/knight.state.of.the.art.summary.pdf ''Safety Critical Systems: Challenges and Directions'', John C. Knight, 2002] |
|||
* {{en}} [http://dl.acm.org/citation.cfm?id=524721 ''Safety Critical Computer Systems'', Neil R. Storey, 1996] |
|||
{{Portail|sécurité informatique|sécurité de l'information}} |
{{Portail|sécurité informatique|sécurité de l'information}} |
||
[[Catégorie:Santé]] |
|||
{{DEFAULTSORT:Systeme critique}} |
|||
[[Catégorie:Sécurité du système d'information]] |
[[Catégorie:Sécurité du système d'information]] |
||
[[Catégorie:Terminologie du logiciel]] |
[[Catégorie:Terminologie du logiciel]] |
||
[[Catégorie:Méthode formelle]] |
[[Catégorie:Méthode formelle]] |
||
[[Catégorie:Panne informatique]] |
|||
[[Catégorie:Risque]] |
|||
[[Catégorie:Sûreté de fonctionnement]] |
[[Catégorie:Sûreté de fonctionnement]] |
||
Dernière version du 23 juin 2024 à 00:49
Un système critique est un système dont la panne peut avoir des conséquences dramatiques, comme des morts ou des blessés graves, des dégâts matériels importants, ou des conséquences graves pour l'environnement. L'analyse des systèmes critiques ne se limite pas à celle que permet, aujourd'hui de plus en plus, l'informatique de contrôle des processus, fussent-ils mécaniques ou humains.
Domaines critiques
[modifier | modifier le code]Dans le monde de l'informatique, les logiciels qualifiés de « critiques » se retrouvent par exemple dans :
- les systèmes de transport : pilotage des avions, des trains, logiciels embarqués automobiles ;
- la production d'énergie : contrôle des centrales nucléaires ;
- la santé : chaînes de production de médicaments, appareil médicaux (à rayonnement ou contrôle de dosages) ;
- le système financier : paiement électronique ;
- les applications militaires.
En fait, de par la diffusion généralisée des technologies logicielles et donc de l'impact plus massif d'un défaut quelconque, la notion de criticité tend à se diffuser même s'il s'agit plus souvent d'un risque de désorganisation sur les plans économique, social ou financier.
Niveaux de criticité
[modifier | modifier le code]Évaluation
[modifier | modifier le code]Il existe différents niveaux de criticité d'un système, suivant l'impact possible des dysfonctionnements. On apprécie ainsi différemment, par exemple, un dysfonctionnement provoquant des pertes coûteuses, mais sans mort d'homme (cas des missions spatiales non habitées) et un dysfonctionnement provoquant des morts dans le grand public (cas des vols commerciaux). De même, on apprécie différemment des dysfonctionnements faisant courir un danger de mort ou de blessure à des humains, ou des dysfonctionnements augmentant la charge de travail et les risques d'erreur de pilotage des opérateurs humains.
Cas particulier de l'aviation
[modifier | modifier le code]En aviation, la norme DO-178B sépare les logiciels avioniques en 5 catégories :
- niveau A : un dysfonctionnement du logiciel provoquerait ou contribuerait à une condition de perte catastrophique de l'appareil ;
- niveau B : un dysfonctionnement du logiciel provoquerait ou contribuerait à une condition dangereuse ou un dysfonctionnement sévère et majeur de l'appareil ;
- niveau C : un dysfonctionnement du logiciel provoquerait ou contribuerait à un dysfonctionnement majeur de l'appareil ;
- niveau D : un dysfonctionnement du logiciel provoquerait ou contribuerait à un dysfonctionnement mineur de l'appareil ;
- niveau E : aucun impact sur le fonctionnement de l'appareil ou la charge de travail du pilote.
Conséquences sur la sécurité
[modifier | modifier le code]La criticité du système définit un niveau d'exigence par rapport à la tolérance aux pannes. Elle aura des conséquences sur l'évaluation des niveaux d'assurance pour la sécurité.
Logiciel critique
[modifier | modifier le code]Définition, enjeux
[modifier | modifier le code]Un logiciel critique est un logiciel dont le mauvais fonctionnement aurait un impact important sur la sécurité ou la vie des personnes, des entreprises ou des biens.
L'ingénierie logicielle pour les systèmes critiques est particulièrement difficile, dès lors que les systèmes sont complexes, mais l'industrie aéronautique, ou plus généralement l'industrie du transport de passagers, a réussi à définir des méthodes pour réaliser des logiciels critiques. Des méthodes formelles peuvent servir à améliorer la qualité du logiciel des systèmes critiques. Le coût de réalisation d'un logiciel de « système critique » est beaucoup plus élevé que celui d'un logiciel ordinaire.
Contraintes particulières de développement
[modifier | modifier le code]Les précautions à prendre dans le développement sont généralement fixées par une norme, et dépendent du domaine d'application et surtout de la criticité du logiciel. Généralement, on trouve des impératifs :
- de documentation : tous les composants doivent être documentés, notamment dans l'interface qu'ils présentent aux autres composants ;
- de traçabilité : le système doit répondre à chaque spécification, soit dans sa mise en œuvre, soit dans des spécifications intermédiaires (auquel il faudra aussi répondre) ; on doit donc avoir une chaîne complète de traçabilité entre les spécifications fonctionnelles et la mise en œuvre du système ;
- de limitation des pratiques dangereuses : certaines techniques de programmations, sources possibles de problèmes, sont interdites, ou du moins leur usage doit être justifié par des raisons impératives (ex. : allocation dynamique de mémoire, procédures récursives) ;
- de test : on devra essayer le logiciel dans un grand nombre de configurations, qui couvrent tous les points et un maximum des chemins de fonctionnement du programme ;
- d'utilisation d'outils de développement et de vérification eux-mêmes sûrs.
Contraintes d'exploitation
[modifier | modifier le code]La mise en œuvre de systèmes critiques implique une adaptation de l'architecture physique dans une optique de fiabilité et de sécurisation. L'architecture doit répondre aux risques identifiés.
La fiabilité passe par un plan de continuité d'activité et des infrastructures adaptés. Des exemples de mesure sont :
- redondance des systèmes ;
- durcissement des équipements.
La sécurité peut être renforcée par:
- l'emploi de systèmes d'authentification forte
- l'isolation des systèmes critiques, par l'usage d'une architecture VPN, voire « air gap »
- la protection physique des équipements (bâtiments sécurisés, contrôle des accès physiques...)
Certification
[modifier | modifier le code]Les systèmes les plus critiques sont généralement soumis à des autorités de certification, qui vérifient que les impératifs prévus par la norme ont été remplis.
L'usage de méthodes formelles pourra, à l'avenir, être encouragé, voire imposé.
Voir aussi
[modifier | modifier le code]- Sûreté de fonctionnement
- Profil d'application
- Analyse décisionnelle des systèmes complexes (méthode de conception de systèmes critiques)
- Capella - atelier de modélisation des architectures système, logicielles et matérielles
