Co

pyr

igh

t

2

00

9 p

ar

Pa

tric

e M

ico

uin

–E

dité

et

util

isé

pa

r A

FIS

et

INC

OS

E a

vec

sa p

erm

issi

on

Ingénierie des exigences et conception des systèmes

d’aéronefs

Dr Patrice MICOUIN

MICOUIN Consulting

LSIS, Arts et Métiers Paris’Tech,

Co

pyr

igh

t

2

00

9 p

ar

Pa

tric

e M

ico

uin

–E

dité

et

util

isé

pa

r A

FIS

et

INC

OS

E a

vec

sa p

erm

issi

on

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

Co

pyr

igh

t

2

00

9 p

ar

Pa

tric

e M

ico

uin

–E

dité

et

util

isé

pa

r A

FIS

et

INC

OS

E a

vec

sa p

erm

issi

on

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

Co

pyr

igh

t

2

00

9 p

ar

Pa

tric

e M

ico

uin

–E

dité

et

util

isé

pa

r A

FIS

et

INC

OS

E a

vec

sa p

erm

issi

on

When AC.Altitude [0ft,1000ft] val (Provide-AC-Vertical-Position.Accuracy) ≤25ftWhen Power_on val (Avionics.Provide-AC-Vertical-Position) =True

Qu’est-ce qu’une exigence bien formée?

• Expression de la forme:

Ex: [When Condition =>] val (Object.Property) D

When Take-Off val (Aircraft.Weight) < nT

• Types d’exigence:• Structurelle• Comportementale• Mixte

• Sources d’exigence:• Certification• Sûreté• Maintenabilité• ..

Toward a property based requirements theory: System requirements structured as a semilatticeINCOSE Journal of Systems Engineering, Volume 11,  Issue 3  (August 2008)

Co

pyr

igh

t

2

00

9 p

ar

Pa

tric

e M

ico

uin

–E

dité

et

util

isé

pa

r A

FIS

et

INC

OS

E a

vec

sa p

erm

issi

on

Specification & Exigences

Attente

Exigence

Traduit en

L’équipement doit être facile à réparer

Le MTTR de l’équipement doit être inférieur à 30 minutes

Enoncé Déontique

énonce une obligation ou une interdiction

Enoncé épistemique

Specification

Plus ou moinsimplicite

Attente Exigences

AnalyseElicitationInterprétationTraduction

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 improbable; et

When In_Flight => Prob(AC_System_failed.severity=CAT) ≤10-9/fh

AC25.1309

Rappelle un élément de connaissance

Co

pyr

igh

t

2

00

9 p

ar

Pa

tric

e M

ico

uin

–E

dité

et

util

isé

pa

r A

FIS

et

INC

OS

E a

vec

sa p

erm

issi

on La structure d’un système

selon l’EIA 632

A tree ofbuilding blocks

Co

pyr

igh

t

2

00

9 p

ar

Pa

tric

e M

ico

uin

–E

dité

et

util

isé

pa

r A

FIS

et

INC

OS

E a

vec

sa p

erm

issi

on

AcquirerRequirements

OtherStakeholder

Requirements

SystemTechnical

Requirements

LogicalSolution

Representations

TechnicalDerived

Requirements

PhysicalSolution

Representations

DESIGNSOLUTION

trace to

trace to

assigned to

assigned to

assigned to

assigned to

drivedrive

Source of

SPECIFIEDREQUIREMENTS

Specified by

Requirement Definition

Solution Definition

De la conception d’un building block

AltitudeL’avionique doit fournir l’altitude

A la conception du système

Co

pyr

igh

t

2

00

9 p

ar

Pa

tric

e M

ico

uin

–E

dité

et

util

isé

pa

r A

FIS

et

INC

OS

E a

vec

sa p

erm

issi

on

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)

Co

pyr

igh

t

2

00

9 p

ar

Pa

tric

e M

ico

uin

–E

dité

et

util

isé

pa

r A

FIS

et

INC

OS

E a

vec

sa p

erm

issi

on

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.

• Exemple

Ex1 : Val (S.DAL) = A

Système S

Portion Primary

Portion Backup

Design Choice 1 :deux portions actives dissimilaires

et indépendantes : primary et backup

DEx2 : Val (Primary.DAL) = A

DEx3 : Val (Backup.DAL) = C

Système S

When Design Choice 1 => Ex1 ≤ DEx2 DEx3

Design pattern 5 du tableau 4 de l’ARP 4754

Co

pyr

igh

t

2

00

9 p

ar

Pa

tric

e M

ico

uin

–E

dité

et

util

isé

pa

r A

FIS

et

INC

OS

E a

vec

sa p

erm

issi

on

Exigences dérivéesSystem

TechnicalRequirements

LogicalSolution

Representations

TechnicalDerived

Requirements

PhysicalSolution

Representations

DESIGNSOLUTION

assigned to

assigned to

assigned to

assigned to

drivedrive

Source de

SPECIFIEDREQUIREMENTS

Specified by

System Technical Requirements

Are derived

Assuming these logical and physical solution

representations are implemented

into Specified Requirements

Co

pyr

igh

t

2

00

9 p

ar

Pa

tric

e M

ico

uin

–E

dité

et

util

isé

pa

r A

FIS

et

INC

OS

E a

vec

sa p

erm

issi

on

Validation des exigences dérivéesSystem

TechnicalRequirements

LogicalSolution

Representations

TechnicalDerived

Requirements

PhysicalSolution

Representations

DESIGNSOLUTION

assigned to

assigned to

assigned to

assigned to

drivedrive

Source de

SPECIFIEDREQUIREMENTS

Specified by

(assuming that the logical and physical solution

representations are implemented)

If they are sufficiently complete and correct to

replace the system technical requirements

The specified requirements are validated

Co

pyr

igh

t

2

00

9 p

ar

Pa

tric

e M

ico

uin

–E

dité

et

util

isé

pa

r A

FIS

et

INC

OS

E a

vec

sa p

erm

issi

on

Vérification de la réalisation vs Exigences

SystemTechnical

Requirements

LogicalSolution

Representations

TechnicalDerived

Requirements

PhysicalSolution

Representations

DESIGNSOLUTION

assigned to

assigned to

assigned to

assigned to

drivedrive

Source de

SPECIFIEDREQUIREMENTS

Specified by

System integrated

System Integration

SubsystemsSubsystemverification

Systemverification

Designverification

Co

pyr

igh

t

2

00

9 p

ar

Pa

tric

e M

ico

uin

–E

dité

et

util

isé

pa

r A

FIS

et

INC

OS

E a

vec

sa p

erm

issi

on

Les exigences de certification et EIA 632

AcquirerRequirements

SystemTechnical

Requirements

LogicalSolution

Representations

TechnicalDerived

Requirements

PhysicalSolution

Representations

DESIGNSOLUTION

trace to

CertificationRequirements

trace to

assigned to

assigned to

assigned to

assigned to

drivedrive

Source of

SPECIFIEDREQUIREMENTS

Specified by

Requirement Definition

Solution Definition

Co

pyr

igh

t

2

00

9 p

ar

Pa

tric

e M

ico

uin

–E

dité

et

util

isé

pa

r A

FIS

et

INC

OS

E a

vec

sa p

erm

issi

on

Concevoir un building block “safe”

Acquirer &Certification

Requirements

Upper levelSafety

Requirements

SystemTechnical

Requirements

LogicalSolution

Representations

TechnicalDerived

Requirements

PhysicalSolution

Representations

DESIGNSOLUTION

trace to

trace to

assigned toassigned to

assigned to

assigned to

drive

drive

Source de

SPECIFIEDREQUIREMENTS

Specified by

Req

uir

emen

t D

efin

itio

n

So

luti

on

Def

init

ion

Failure Conditions&

Categorization

SafetyAssessment

Representationsassigned to

drive

Co

pyr

igh

t

2

00

9 p

ar

Pa

tric

e M

ico

uin

–E

dité

et

util

isé

pa

r A

FIS

et

INC

OS

E a

vec

sa p

erm

issi

on

Vérifier un building block “safe”

AcquirerRequirements

Upper levelSafety

Requirements

SystemTechnical

Requirements

LogicalSolution

Representations

TechnicalDerived

Requirements

PhysicalSolution

Representations

DESIGNSOLUTION

trace to

trace to

assigned toassigned to

assigned to

drive

Source de

SPECIFIEDREQUIREMENTS

Specified by

Req

uir

em

ent

Def

init

ion

So

luti

on

Def

init

ion

Failure ConditionsAnd

Categorization

SafetyAssessment

Representations

assigned to drive

assigned to

drive

Systemintegrated

System integration

SubsystemsSubsystem Safety

AssessmentResults & Data

System SafetyAssessment

Results

Designverification

assigned to

Co

pyr

igh

t

2

00

9 p

ar

Pa

tric

e M

ico

uin

–E

dité

et

util

isé

pa

r A

FIS

et

INC

OS

E a

vec

sa p

erm

issi

on

Merci de votre attention

des questions?