Transcript SE for Commercial A/C Scott Jackson

Copyright  2009 par Patrice Micouin –Edité et utilisé par AFIS et INCOSE avec sa permission
Ingénierie des exigences et
conception des systèmes
d’aéronefs
Dr Patrice MICOUIN
MICOUIN Consulting
LSIS, Arts et Métiers Paris’Tech,
Copyright  2009 par Patrice Micouin –Edité et utilisé par AFIS et INCOSE avec sa permission
Objectif
Proposer un cadre de développement aussi
cohérent et complet que possible qui permette de:
1. satisfaire aux exigences des autorités de certification
2. répondre à des standards tels que l’ARP 4754
3. intégrer les activités de développement et d’évaluation
de la sûreté (safety assessment)
4. contribuer à la définition d’une ingénierie des systèmes
aéronautiques basée sur les modèles
Copyright  2009 par Patrice Micouin –Edité et utilisé par AFIS et INCOSE avec sa permission
Plan
1.
Une théorie des exigences bien formées basée sur le
concept de propriété
2.
Le cadre de développement proposé par l’EIA 632
3.
Les exigences de certification et l’EIA 632
4.
Les exigences de sûreté et l’EIA 632
5.
Discussion
Copyright  2009 par Patrice Micouin –Edité et utilisé par AFIS et INCOSE avec sa permission
Qu’est-ce qu’une exigence bien formée?
Toward a property based requirements theory: System requirements structured as a semilattice
INCOSE Journal of Systems Engineering, Volume 11, Issue 3 (August 2008)
• Expression de la forme:
Ex: [When Condition =>] val (Object.Property)  D
When
Take-Off

val(Provide-AC-Vertical-Position.Accuracy)
(Aircraft.Weight) < nT
When AC.Altitude
When Power_on
[0ft,1000ft]
valval
(Avionics.Provide-AC-Vertical-Position)
=True ≤25ft
• Opération
Relation d’ordre:
de conjonction
“être plus contraignante que”
Ex=Ex1Ex2
(Ex)=Sat
(Ex1)∩Sat (Ex2)
Ex1 ≤ Ex2  
SatSat
(Ex1)
Sat (Ex2)
• Types d’exigence:
• Structurelle
• Comportementale
• Mixte
• Sources d’exigence:
•
•
•
•
Certification
Sûreté
Maintenabilité
..
Copyright  2009 par Patrice Micouin –Edité et utilisé par AFIS et INCOSE avec sa permission
Specification & Exigences
Rappelle un élément
de connaissance
Specification
énonce une obligation ou
une interdiction
Plus ou moins
implicite
Enoncé épistemique
Enoncé Déontique
Attente
Traduit en
L’équipement doit être
facile à réparer
Exigence
Le MTTR de l’équipement doit
être inférieur à 30 minutes
25.1309 :
b) Les systèmes de l'avion et les composants
associés, considérés séparément et en relation
avec d'autres systèmes, doivent être conçus de
façon que :
(1) L'apparition de toute condition de panne qui
empêcherait la poursuite du vol en sécurité et
l'atterrissage de l'avion, soit extrêmement
Attente
Analyse
AC25.1309
Elicitation
Interprétation
Traduction
When In_Flight =>
Prob(AC_System_failed.severity=CAT)
≤10-9/fh
Exigences
Copyright  2009 par Patrice Micouin –Edité et utilisé par AFIS et INCOSE avec sa permission
La structure d’un système
selon l’EIA 632
A tree of
building
blocks
Copyright  2009 par Patrice Micouin –Edité et utilisé par AFIS et INCOSE avec sa permission
la conception
dubuilding
systèmeblock
De laA conception
d’un
Requirement Definition
Acquirer
Altitude
L’avionique
doit fournir l’altitude
Requirements
trace to
Other
trace to
Stakeholder
Requirements
System
Technical
Requirements
assigned to
Solution Definition
assigned to
Logical
Physical
assigned to
Solution
Solution
Representations
Representations
drive
drive
Technical
Derived
Requirements
Source of
assigned to
DESIGN
SOLUTION
Specified by
SPECIFIED
REQUIREMENTS
Copyright  2009 par Patrice Micouin –Edité et utilisé par AFIS et INCOSE avec sa permission
Operations sur les exigences
 Generation (ex nihilo, traduction d’attentes)
 Derivation
 Validation des exigences (et hypothèses)
 Verification des réalisations vs exigences
 Modification & suppression (non traitées ici)
Copyright  2009 par Patrice Micouin –Edité et utilisé par AFIS et INCOSE avec sa permission
Dérivation d’exigences
• La dérivation d’exigence est une transformation qui
remplace une exigence de niveau N par des exigences de
niveau N+1 sous l’hypothèse que des choix de conception
seront effectivement réalisés.
Design Choice 1 :
• Exemple
deux portions actives dissimilaires
et indépendantes : primary et backup
Ex1 : Val (S.DAL) = A
DEx2 : Val (Primary.DAL) = A
Portion Primary
Système S
When Design Portion
ChoiceBackup
1 => Ex1 ≤ DEx2  DEx3
Design pattern 5 du tableau 4 de l’ARP 4754
DEx3 : Val (Backup.DAL) = C
Copyright  2009 par Patrice Micouin –Edité et utilisé par AFIS et INCOSE avec sa permission
Exigences dérivées
System
Technical
Requirements
assigned to
System Technical
Requirements
Are derived
Assuming these logical and
physical solution
representations are
implemented
assigned to
Logical
Physical
assigned to
Solution
Solution
Representations
Representations
drive
drive
Technical
Derived
Requirements
Source de
assigned to
DESIGN
SOLUTION
Specified by
SPECIFIED
REQUIREMENTS
into Specified Requirements
Copyright  2009 par Patrice Micouin –Edité et utilisé par AFIS et INCOSE avec sa permission
Validation des exigences dérivées
System
Technical
Requirements
assigned to
The specified requirements
are validated
(assuming that the logical and
physical solution
representations are
implemented)
assigned to
Logical
Physical
assigned to
Solution
Solution
Representations
Representations
drive
drive
Technical
Derived
Requirements
Source de
assigned to
DESIGN
SOLUTION
Specified by
SPECIFIED
REQUIREMENTS
If they are sufficiently
complete and correct to
replace the system technical
requirements
Copyright  2009 par Patrice Micouin –Edité et utilisé par AFIS et INCOSE avec sa permission
Vérification de la réalisation vs Exigences
System
Technical
Requirements
System
verification
assigned to
System integrated
assigned to
Logical
Physical
assigned to
Solution
Solution
Representations
Representations
drive
Design
verification
System
Integration
drive
Technical
Derived
Requirements
Source de
assigned to
DESIGN
SOLUTION
Specified by
SPECIFIED
REQUIREMENTS
Subsystem
verification
Subsystems
Copyright  2009 par Patrice Micouin –Edité et utilisé par AFIS et INCOSE avec sa permission
Les exigences de certification et EIA 632
Requirement Definition
Acquirer
Requirements
trace to
Certification trace to
Requirements
System
Technical
Requirements
assigned to
Solution Definition
assigned to
Logical
Physical
assigned to
Solution
Solution
Representations
Representations
drive
drive
Technical
Derived
Requirements
Source of
assigned to
DESIGN
SOLUTION
Specified by
SPECIFIED
REQUIREMENTS
Failure Conditions
&
Categorization
Acquirer &
Certification
Requirements
trace to
Upper level
trace to
Safety
Requirements
Solution Definition
Requirement Definition
Copyright  2009 par Patrice Micouin –Edité et utilisé par AFIS et INCOSE avec sa permission
Concevoir un building block “safe”
System
Technical
Requirements
assigned to
assigned to
Technical
Derived
Requirements
assigned to
drive
drive
drive
Logical
assigned to
Solution
Representations
Physical
Solution
Representations
Source de
DESIGN
SOLUTION
Specified by
SPECIFIED
REQUIREMENTS
assigned to
Safety
Assessment
Representations
Failure Conditions
And
Categorization
Acquirer
Requirements
trace to
Upper level
Safety
Requirements
trace to
System Safety
Assessment
Results
System
Technical
Requirements
Technical
Derived
Requirements
assigned to
Solution Definition
Requirement Definition
Copyright  2009 par Patrice Micouin –Edité et utilisé par AFIS et INCOSE avec sa permission
Vérifier un building block “safe”
drive
assigned to
drive
assigned to
drive
Logical
Physical assigned to
Safety
assigned to
Solution
Solution
Assessment
Representations
Representations
Representations
System
integrated
System integration
Design
verification
Source de
DESIGN
SOLUTION
Specified by
SPECIFIED
REQUIREMENTS
Subsystem Safety
Assessment
Results & Data
Subsystems
Copyright  2009 par Patrice Micouin –Edité et utilisé par AFIS et INCOSE avec sa permission
Merci de votre attention
des questions?