Une spéciﬁcation complète préalable à la sûreté de...

Jean-Pierre Elloy

Une spécification « complète »préalable à la sûreté de

fonctionnement ?

... ou la mise en place des mécanismes de vérification dans le processus de développement ...

IRCCyNSTR

AFSEC 26 octobre 2006

Système piloté

Système de pilotage

Impactexterne

Flux brut

Flux transformé

Procédé ou partie opérative

Système Composant Système sûr Spécification Processus de conception

Définitions

1 - Ce qu’on appelle système

2

Instrumentationd’actionnement

Instrumentationde mesure

Autres systèmes de

pilotage

Système superviséInter-système

Donneurd’ordres

Retourinformations

Supervision et IHM

... en automatique et systèmes de production

Systèmeà piloter

MatièreProduitEnergie

Information

MatièreProduitEnergie

InformationObjet de l’étude : le système de pilotage

plongé dans cet environnement

Endiguer la complexité par :

... la décomposition du système à piloter

... et celle du système piloté

3


Décomposition

- géographiques- techniques- prestations

- fourniture équipementiers- réutilisation

Décomposition en sous-systèmes

Décomposition en sous-architectures

Sous-systèmes géographiques :hayon arrière, toit ouvrant, train roulant, GMP

Sous-systèmes techniques :circuit hydraulique, multiplexage électronique, alimentation électrique

Sous-systèmes prestations :Freinage, éclairage, essuyage, suspension pilotée, assistance à la conduite, navigation

constituants

Constituants mécaniques :pédalier, disques, étriers, garnitures

Constituants hydrauliques :circuits hydrauliques, maître cylindre, piston

Constituants électriques :capteur vitesse roue, capteur usure frein, répartiteur AV/AR, relais feu stop

Constituants fonctionnels :freinage simple, ABS, BAS, ESP, allumage stop

... enfin celle du système de pilotage

... pour aboutir aux composants logiciels

4


Décomposition

Décomposition opérationnelle Décomposition structurelle

Composant de pilotage

- architecture logicielle- architecture matérielle

... eux-mêmes subdivisés en logiciels de base et d’application

... eux-mêmes regroupés en tâches opérationnelles (en fils d’exécution)

raffinement fonction de la granularité de

l’observation

- hiérarchique- modulaire

raffinement fonction de la structuration

algorithmique

Endiguer la complexité par :

A chaque niveau, le programme abstrait du niveau précédent est remplacé par un programme plus

complexe et plus concret

Un programme est décomposé en un assemblage de sous-programmes

ou de modules dont les échanges sont décrits


Autres systèmes

IHM

OrganesSystèmeà piloter

2 - Au niveau du composant Les entrées et sorties du pilotage

5


Entrées / Sorties


IHMAutres

systèmes

SupervisionAutres systèmes

CapteursMesures

Consignes

Ordres

Entrées

Sorties

Commandes

Signalisation

OrdresConsignesLois

de comm

ande

Lois de com

mande

Lois de com

mande

Lois de commande : - continues échantillonnées - discrètes - ou logiques combinatoires - ou logiques séquentielles

Entrées à valeurs : - continues - de type énuméré - logiques

... dans le cas général

Entrées à acquisition : - décidée par le pilotage - forçée par le procédé

Sorties à valeurs : - continues discrétisées - de type énuméré - booléennes

Sorties à émission : décidée par le pilotage

Un exemple concret

6

Energieélectrique

Balayagepare-brise

Ess

uyage

Rupteur

Moteur

RelaisCommodo

Batterie

Balayage

Appui vers le haut eav1

COMMODO

AH

eav2 ABAppui vers le bas

Relais R1

Commande relais

Relais R2

MOTEUR

+ ACC

B1

B2

R1 R2

Commodo

Capteur de

position du

balais

Logique de

gestion des

modes

d'essuyage

simplearefix

eav2

eav1

Relais

Mote

ur

R2

R1


Exemple22 Chapitre 1. – Introduction et contexte

Appui vers le haut eav1

COMMODO

AH

eav2 ABAppui vers le bas

Fig. 1.11 – Le commodo

par exemple). Ces modes sont : Arret, Petite Vitesse (ou PV) et Grande Vitesse (ou GV). Lamodelisation du commodo est celle d’un equipement qui recoit en entree le mouvement du levier(AH et AB), et qui genere en sortie une combinaison de deux signaux booleens, eav1 et eav2 quicodent la demande de l’operateur. Ce systeme est presente figure 1.11. Les valeurs booleennes dessignaux AH et AB emis par les mouvements du levier, ainsi que le codage des sorties eav1 et eav2qui est e!ectue par le commodo sont indiques dans les tableaux suivants :

AH AB ʯԏϻſſӹ

0 0 levier immobile0 1 descente du levier d’un cran1 0 montee du levier d’un cran

eav1 eav2 ϻ˿ԏȶſӹ

0 0 Arret demande0 1 PV demandee1 1 GV demandee

L’automate d’etats finis qui modelise tous les fonctionnements possibles du commodo est pre-sente sur la figure 1.12. Sur cette figure, on a indique dans chaque etat les valeurs correspondantesdes entrees et des sorties du commodo dans l’ordre : AH AB, eav1 eav2.

Entrées :00 : levier immobile

01 : descente d'un cran

10 : montée d'un cran

Sorties :00 : arrêt

01 : petite vitesse demandée

11 : grande vitesse demandée

00,11

01,0110,11

00,01

10,0101,00

00,00levier immobile

arrêt

levier immobile

PV

levier immobile

GV

montée

montée

descente

descente

Fig. 1.12 – Modele du commodo incremental a 3 positions

��

�� ֊˿ӹÿ ֊ſ˿ # ֊ ˿֊# ֊#

��

ޱ �� ˿ ֊ſ˿ �˿ʯ�˿֊ ʯ ֊�ӹ

� �� ৺ੴ24

� �� ״� ſ॰4֊%ſ

� �� ״� ſ״ſݏੴ

� ��

��

��

��

��

La définition appliquée ici Un système sera qualifié de sûr de fonctionnement

s’il délivre un service spécifié même en cas de l’occurrence de défaillances

7


Ce sont les défaillances dont la probabilité d’occurrence, alliée à la gravité des conséquences et la probabilité de non-détection ont été évaluées comme

inacceptables dans le cahier des charges du système.

service «dégradé», service de «repli»,

service de «survie».

Définition

3 - La sûreté d’un système pilotéHigh Assurance system

Critical Computing System

Le service délivré en cas de défaillance peut être différent (le système peut abandonner le

service «nominal» pour délivrer un autre service) à condition qu’il soit spécifié Les défaillances prises en compte sont

celles qu’une « analyse préliminaire de risques » a identifiées comme critiques pour le système ou pour son environnement

Un système piloté peut-il être non sûr ?

8


Les dysfonctionnements

Les dysfonctionnements du procédé

Les dysfonctionnements du système de pilotage

Conséquences :- le système de pilotage doit traiter toutes ces fautes critiques - le système de pilotage doit connaître l’état du procédé

Fautes procédé : bris mécanique, coupures électriques, fuite hydraulique, panne d’auxiliaire, blocage mécanique, etc.

Fautes instrumentation : coupure Vcc, bobine relais coupé, coupure Gnd, composant

bloqué ou saturé, circuit ouvert, court-circuit, signal parasité, actionneur grippé, bris du corps

de mesure, rebond, dérive, gigue, etc.

Fautes matérielles : Coupure ou perturbation réseau, processeur défai/ant, altération ou blocage mémoire, interface d’E/S en circuit ouvert ou court-circuit

Fautes logicielles : spécifications non respectées, exigences incomplètes, synchronisations incorrectes, incompatibilité de formats de données, erreurs de programmation ou de codage, couverture incomplète de l ’évolution du procédé et des signaux d ’entrée, non conformité du fonctionnement du support d’exécution (protocoles, exécutif, middleware), réutilisation abusive ...

Le système de pilotage accroît la criticité des fautes du procédé par

l’amplification de ses réactions

9

Processeur

Entrées


Sorties

Lois de com

mande

Spécifications Vérification

➊

➊ Les lois de commande engendrées ne répondent pas aux spécifications

Autressystèmes

Middleware

Protocole

Réseau

CapteursIHM

➋

Exécutif

➋ Les spécifications sont incomplètes

➌

➍

➌ Un capteur défaille et transmet des données non prévues

➍ Une application distante défaille et transmet des données non prévues

Il ne s’agit pas de sorties «erronées» (quel sens lui donner ?), mais de sorties non prévues dans l’état courant du système piloté

Modèles➋Expression➋


Fautes du composant de pilotage

Les fautes logicie(es d ’un composant de pilotage

Il ne s’agit pas de sorties «erronées» (quel sens lui donner ?), mais de sorties non prévues dans l’état courant du système piloté

Processeur

Entrées


Sorties

Lois de com

mande


➊

Autressystèmes

Middleware

Protocole

Réseau

CapteursIHM

➋

Exécutif

➋ Les spécifications sont incomplètes

➌

➍

➎

➎

➎

➎ Le support d’exécution défaille et transmet des données incohérentes

➏

➏ Le réseau défaille (devient silencieux) ➐

➐ Le processeur ou la mémoire défaille

Intrusions➑

➑ Intrusions =- atteinte à la sécurité- données non prévues dans l’état courant

10


Fautes du composant de pilotage

Les fautes logicie(es d ’un composant de pilotage

11


Raisons de défaillances

4 - Spécification et modélisation


Entrées

SortiesLois

de comm

ande

Lois de com

mande

Lois de com

mande


Modélisation

Inadéquation de la modélisation vis-à-vis des propriétés à vérifier : abstraction réductrice, propriétés des

opérateurs

De multiples défaillances ont pour origine les spécifications :

omission, incompréhension, différence d ’interprétation

Enquête Nasa (Vols Voyager & Galileo) : 289 des 354 erreurs découvertes lors de la phase de test provenaient des spécifications

Récents accidents d’avion impliquant une défaillance informatique : - dans aucun cas, en raison de la défaillance d’un composant informatique, - ni parce que la réalisation des composants informatiques élémentaires ne

respectait pas ses spécifications, - mais parce que l’interaction de ces composants avait abouti à un

comportement catastrophique ➜ question de modélisation ?

Y remédier pourrait passer par la complétude des spécifications ➔ c’est-à-dire par assurer la couverture de la réalisation vis-à-vis de toutes les valeurs

des entrées

Des raisons de défai/ances

12


Défaillances de spécification

De multiples défaillances ont pour origine les spécifications : omission,

incompréhension, différence d ’interprétation

Pourquoi des défai/ances de spécification ?

Gestion des exigences : Partition des exigences (éclatement et répartition)Partage des exigences (réalisation en commun)Création d’exigences (en fonction des choix structuraux)

Quelles spécifications ? Les erreurs de spécification peuvent porter aussi bien sur le comportement du procédé (lorsqu’il n’est pas encore réalisé) que sur le comportement souhaité du procédé piloté

Evénements raresIngénierie des exigences

Quels événements ? - Enchevêtrement de transitions non envisagé- Interactions inter-systèmes non prévues

- hiérarchique - modulaire

13


Défaillances de modélisation

Inadéquation de la modélisation vis-à-vis des propriétés à vérifier :

abstraction réductrice, propriétés des opérateurs

Pourquoi des défai/ances de modélisation ?

Les propriétés à vérifier sont exprimées dans le référentiel causal

et temporel d’un observateurExemple : modélisation des

chevauchements des transitions entre système de pilotage et procédé

Exemple : des transitoires de commutation réduits aux seuls

états initiaux et finaux

Preuve de programme : La propriété porte sur l’exécution du programme, observée en suivant les étapes de ces exécutions. L’observateur est le système informatique qui est modélisé : pas de distorsion de référentiel

Preuve de procédé piloté :L’observateur est le système informatique de pilotage (les propriétés sont généralement exprimées dans son référentiel) et le système observé est le procédé : des distorsions possibles de référentiel

La « granularité » de l’observation n’est pas seule en cause puisqu’il s’agit de s’assurer de la vérification de l’hypothèse de l’instantanéité des transitions (qui est en fait relative)

Modélisation sous forme de systèmes à événements discrets:

systèmes de transitions, automates d’états finis, automates hybrides,

réseau de Petri généralisés, temporels, temporisés, etc.

14

La question de la modélisation La perception des informaticiens

Objet de l’étude = le système de pilotage

(son logiciel)

Exigences de comportement (de temps) exprimées dans une logique d’expression

- comportement intrinsèque- comportement applicatif

Modélisation SdTpar composants

Modèle global par composition des modèles

de composants

Vision réduite aux seuls aspects pertinents (synchronisation, évolution

d’une grandeur). C’est une modélisation sans « dégradation »


Modélisation Informatique

Validité du modèle ?

... pour le spécifierou le vérifier

ou le synthétiser

Génération de code

La sémantique du modèle (la classe d’équivalence des comportements

modélisés) ➜ est à choisir en fonction de la propriété à étudier

La logique d’expression doit être compatible avec la sémantique (cad ne pas

distinguer des comportements équivalents) Validité de la composition ?

Le produit cartésien construit un état composé comme la composition des états des systèmes composés : c’est

conforme à la sémantique d ’entrelacement et à la sémantique basée sur la causalité (//)

Respect des exigences

15

La question de la modélisationSystème Composant Système sûr Spécification Processus de conception

Modélisation Automatique

La perception des automaticiensObjet de l’étude =

le système piloté (système de pilotage + procédé)

Exigences du comportement (de temps) applicatif du procédé piloté exprimées

dans une logique d’expression

Modèle de connaissance

Modèle de transfert E/S

Modèles naturels des automaticiens

Modélisation SdTpar composants

Modèle global par composition des modèles

de composants

Obligation de recourir à un modèle composable avec le modèle du système

de pilotage (de même sémantique)

Respect des exigences

Génération du squelette du code

lois de commande

+ Exigences de SdF, de consommation, d’occupation mémoire, de CEM, etc.

Génération du code complet

Vision simplifiée (imprécise, rudimentaire) du procédé. C’est une

modélisation « dégradée »

Validité du modèle ?

Validité de la composition ?

Le produit cartésien ne permet pas la création de tiers-états, c’est-à-dire d’états modélisant des influences

mutuelles entre composants

Les techniques de SdF

16

4 - La sûreté d’un système piloté dans le processus de conception


Prévention de fautesInterdire l’apparition de fautes

Prévision des fautesEstimer la présence et les conséquences des fautes

Détection de fautesDétecter les fautes acceptées

Contournement des fautesContourner les fautes en anticipant leurs conséquences

... par le contrôle du procédé... non détectées ou

impossibles à imaginer

... possibles à imaginer

Intégrée dans la conception des lois de

commande

Tolérance aux fautesTraiter les fautes acceptées

... critiques et qu’il est possible d’interdire d’arriver

... critiques et qu’il est possiblede tolérer par une stratégie adéquate

Techniques de SdF

... par la complétude des spécifications ... par l’observation et la

réaction d’empaquetâches... par l’observation des

combinaisons d’états de tâches et “reset” partiels

17

EXIGENCEScomportementales

attendues du procédé piloté

PROCÉDÉ

Déduit

Déduit

Exigences comportementales du système de pilotage

Architecture matérielleContraintes temporelles

Sûreté de fonctionnement

Composants sur étagèresSous-architectures module

Boîtes noires et grises

Savoir-faire

Formules de satisfaction de propriétés temporelles

Déduit

Calcul

Analyse

CTL* :Computation

Tree Logic

Satisfaction des formules par le

modèle

Calcul

InterblocageFamine

Un processus à base du modèle abstrait du système de pilotage


A base du modèle de pilotage

18

Vecteurs de tests (scénarios)

Génération

Savoir-faire

METIERIntégration

Configuration Déploiement

Impla

ntation

Placeme

nt

Tests d’intégration

Phase finale du processus de conception



19



PROCÉDÉ Déduit

Déduit

Exigences comportementales du système de pilotage

Déduit





Savoir-faire

Analyse

Un processus à base des modèles abstrait et opérationnel du système de pilotage



20



PROCÉDÉ

Déduit

Déduit

Comportement attendu du procédé piloté

Savoir-faire

Projection

CalculThéorie des langages

commandables





Savoir-faire

Equivalence

Analy

se

Un processus à base du modèle du procédé piloté


A base du modèle du procédé

21

Conclusion


Spécification : une difficulté à facettes Modélisation : le piège des référentiels Processus : ouvert A/er vers une démarche de conception modale

Modes Conception modale Partition Abstraction Convention

Maîtriser la complexité de l’application par les modes

Conception modale intuitive

Conception modale par partition du fonctionnement

22

pour aider à la complétude des spécifications

1 - Une démarche de conception... de conception détai/ée

Sorties


Structuration modale

Entrée

1 - Maîtriser la complexité ➔ modes... par une modélisation hiérarchique

combinantdécompositionmodulaire

en modes de fonctionnement

Mode M1 Sortiesmodales

Séle

cteu

rde

mod

e

Variablesde mode

Sous-mode Mi

Sous-mode Mj

Séle

cteu

rde

sort

ies

Moderepli

23


en 3 étages

et parraffinement des modes

en sous-modes

Traitement de l’arrêt d’urgence et des conditions de sécurité

Entrées

Principe

24

Entités fonctionnelles (EF) de l’application

Moteur d’essuie-glace

Capteur de pluie

Commodo

ACT

CAPT

CONDESSUIE

Entité fonctionne(e de gestion du capteur

(driver)

Le capteur lui-même

Exemple : la fonction essuyage


Essuyage

* ACT est l’EF qui émet la commande du moteur d’essuie-glace* CAPT est l’EF qui relève la mesure du capteur de pluie et la transforme en donnée* COND est l’EF qui détecte la position du commodo

3 positions : haute ➩ Arrêt, médiane ➩ Balayage manuel, basse ➩ Balayage autoDri

vers

des

ca

pteu

rsLo

i de

com

man

de * ESSUIE est l’EF qui calcule la commande de l’essuie-glace à partir de - la consigne = position du commodo transmise par COND - la mesure de l’humidité sur le pare-brise transmise par EF-CAPT

25

2

3

1

2a

2b3a

3b

« 2b » est un sous-mode de fonctionnement du

mode FIXE

basse AUTO ACT CAPTnominal COND ESSUIE

auto

médiane FIXE ACTCAPT

nominalCAPTpanne

COND ESSUIEmanuel

haute STOPCAPT

nominalCAPTpanne

COND ESSUIEarrêt

Modes de fonctionnement

de l’essuyage

blanc = toujours hors-service dans ce mode

Modes de la fonction essuyage


Modes de l’essuyage

CAPT nominal = nom de l’EF en service lorsque le capteur de pluie est opérationnelCAPT panne = nom de l’EF en service lorsque le capteur de pluie est en panne

Positionsdu

commodo Entités fonctionne(es de l’application

26

FctEssuyage

ESSUIE

ESSUIEbalayagemanuel

ESSUIEbalayage

auto

ESSUIEarrêt

“Organe” fonction d’essuyage

CONDOrgane commodo

ACT

Organe moteur

d’essuie-glace

CAPTnominal

CAPTpanne

Organe capteur de pluie

Fonction gérant les 2 modes de

fonctionnement du capteur

CAPT

Décomposition organique

Décomposition modale LOCALE

Structuration organique des modes


Structuration organique

27

AUTO

FIXE

STOP

FctEssuyage

ESSUIEbalayage

auto

CAPTnominal

COND

Mode AUTO

ACT

1ESSUIE

balayagemanuel

CAPTpanne

COND

ACT

CAPT

CAPTnominal

Mode FIXE2

ESSUIEarrêt

COND

CAPTpanne

CAPT

CAPTnominal

Mode STOP

3Le même organe

est impliqué plusieurs fois

(en exclusion mutue(e)

Décomposition modale GLOBALE

Décomposition organique2a 2b

3b3a

Mode LOCAL = sous-mode GLOBAL

Structuration modale des modes


Structuration modale

FctEssuyage

ESSUIE

ESSUIEbalayagemanuel

ESSUIEbalayage

auto

ESSUIEarrêt

CAPTnominal

CAPTpanne

COND

ACTCAPT

AUTO1

FIXECaptOpér

FIXECaptPanne

2a 2b

STOPCaptOpér

STOPCaptPanne

3a 3b

FIXE2

STOP3

ModesEssuyage

– La structure fonctionnelle est développée organe par organe indépendamment de leurs interactions

– Les modes de fonctionnement de l’application sont définis et hiérarchisés indépendamment des entités fonctionnelles

Principe de développement d ’une architecture fonctionne/e modale

28

12

1

2b3b

12a3a

123

3 2

– Des relations statiques entre structure fonctionnelle et structure des modes fixent les diagrammes fonctionnels par mode

– La gestion des commutations de mode est confiée aux modes abstraits qui prennent le rôle de superviseur

Modes abstraits utiles pour construire des

modes inter- systèmes

Architecture modale


Architecture modale

Entrées

2 - Conception modale

Mode M1Entrée Sortie

SortieVariablesde mode

Conception indépendante des lois modales. - Entrée dans le mode : explicite, conditionnée par la variable de mode- Sortie de mode : implicite (entrée dans un autre mode)

... que devient le mode abandonné ?

... et les combinaisons non traitées ?

... et la cohérence des transitoires ?

Réponses ... à la main ...

- Pré-traitement des entrées- Correspondance entrecombinaison entrées ➔ mode- Codage des modes ➔ variables

Séle

cteu

rde

mod

e

Séle

cteu

rde

sort

ies

Moderepli

... et le retour dans un mode nominal ?

29


Sortiesmodales

Sélecteur indépendant des valeurs des sorties

Conception indépendante

Intuitive

Conception intuitive

Mode Mi

Mode M1

Mode repli

EntréeEntréeSorties

Sortie

Sorties

Modélisation indépendante des modes. Le maintien dans le mode est explicite et est conditionné par les entrées. La sortie du mode est explicite par les entrées

Construction automatique des commutations de mode en fonction des entrées et garantissant la

stabilité des transitions

Saturation automatique des lois de commande dans l’espace des valeurs des entrées garantissant la complétude de la commande

Construction indépendante des valeurs des sorties. Les sorties ne

sont produites que quand le mode est actif

Le résultat concret peut être un processus mono-

tâche

30

... comme en modélisation intuitive

... maintien et non entrée dans le mode

... explicite et non due à l’entrée dans un mode

... comme en modélisation intuitive

... et non sélectionnée a posteriori

... et non manue(e

...c’est-à-dire le maintien dans l’état d’arrivée à entrées constantes

Conception par partition


Par partition

Une spéciﬁcation complète préalable à la sûreté de...

Documents

Transcript of Une spéciﬁcation complète préalable à la sûreté de...