une spécification complète préalable à la sûreté de...
TRANSCRIPT
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
Système Composant Système sûr Spécification Processus de conception
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
Système Composant Système sûr Spécification Processus de conception
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
Composant de pilotage
Autres systèmes
IHM
OrganesSystèmeà piloter
2 - Au niveau du composant Les entrées et sorties du pilotage
5
Système Composant Système sûr Spécification Processus de conception
Entrées / Sorties
Composant de pilotage
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
Système Composant Système sûr Spécification Processus de conception
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
Système Composant Système sûr Spécification Processus de conception
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
Système Composant Système sûr Spécification Processus de conception
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
Système de pilotage
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➋
Système Composant Système sûr Spécification Processus de conception
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
Système de pilotage
Sorties
Lois de com
mande
Spécifications Vérification
➊
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
Système Composant Système sûr Spécification Processus de conception
Fautes du composant de pilotage
Les fautes logicie(es d ’un composant de pilotage
11
Système Composant Système sûr Spécification Processus de conception
Raisons de défaillances
4 - Spécification et modélisation
Système de pilotage
Entrées
SortiesLois
de comm
ande
Lois de com
mande
Lois de com
mande
Spécifications Vérification
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
Système Composant Système sûr Spécification Processus de conception
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
Système Composant Système sûr Spécification Processus de conception
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 »
Système Composant Système sûr Spécification Processus de conception
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
Système Composant Système sûr Spécification 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
Système Composant Système sûr Spécification Processus de conception
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
Système Composant Système sûr Spécification Processus de conception
A base du modèle de pilotage
19
EXIGENCEScomportementales
attendues du procédé piloté
PROCÉDÉ Déduit
Déduit
Exigences comportementales du système de pilotage
Déduit
Architecture matérielleContraintes temporelles
Sûreté de fonctionnement
Composants sur étagèresSous-architectures module
Boîtes noires et grises
Savoir-faire
Analyse
Un processus à base des modèles abstrait et opérationnel du système de pilotage
Système Composant Système sûr Spécification Processus de conception
A base du modèle de pilotage
20
EXIGENCEScomportementales
attendues du procédé piloté
PROCÉDÉ
Déduit
Déduit
Comportement attendu du procédé piloté
Savoir-faire
Projection
CalculThéorie des langages
commandables
Architecture matérielleContraintes temporelles
Sûreté de fonctionnement
Composants sur étagèresSous-architectures module
Boîtes noires et grises
Savoir-faire
Equivalence
Analy
se
Un processus à base du modèle du procédé piloté
Système Composant Système sûr Spécification Processus de conception
A base du modèle du procédé
21
Conclusion
Système Composant Système sûr Spécification Processus de conception
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
Système de pilotage
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
Modes Conception modale Partition Abstraction Convention
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
Modes Conception modale Partition Abstraction Convention
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 Conception modale Partition Abstraction Convention
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
Modes Conception modale Partition Abstraction Convention
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
Modes Conception modale Partition Abstraction Convention
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
Modes Conception modale Partition Abstraction Convention
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
Modes Conception modale Partition Abstraction Convention
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
Modes Conception modale Partition Abstraction Convention
Par partition