Transcript  Patrice Micouin –Certification Together, Toulouse, October 2010 A/C System Requirement & Design Engineering: Implementing Airworthiness Requirements Dr Patrice MICOUIN MICOUIN Consulting LSIS, Arts et Métiers.

 Patrice Micouin –Certification Together, Toulouse, October 2010
A/C System Requirement &
Design Engineering:
Implementing Airworthiness Requirements
Dr Patrice MICOUIN
MICOUIN Consulting
LSIS, Arts et Métiers Paris’Tech,
 Patrice Micouin –Certification Together, Toulouse, October 2010
Purpose
To provide a development framework
consistent and complete as possible:
as
1.Contributing to the definition of an A/C Model Based
System Engineering
2. Dealing with certification requirements
3. Integrating tightly development and safety assessment
activities
4. Consistent with the ARP 4754 standard.
 Patrice Micouin –Certification Together, Toulouse, October 2010
Requirement & Design Engineering Statements
Requirement & Design Engineering deals with three kinds
of statements
• Epistemic statements
• Deontic statements
• Design choice statements
 Patrice Micouin –Certification Together, Toulouse, October 2010
Epistemic statements
 Record knowledge items
Under the control of the nature, social agreement, ..
 Designers use epistemic statements as lever in the design process
• Examples
 AC29.1309
EXTREMELY IMPROBABLE: “A probability on the order of 10-9 or less is assigned to this classification.”
AC29.1309
Catastrophic Failure conditions : Failure conditions which would prevent a safe landing.
 AC25.11A Table 5
Hazard
Classification
Qualitative
Probability
Loss of all barometric altitude displays, including standby display
Catastrophic
Extremely
Improbable
Display of misleading barometric altitude information on one primary display
combined with a standby failure (loss of altitude or incorrect altitude)
Catastrophic
Extremely
Improbable
Failure Condition
 Patrice Micouin –Certification Together, Toulouse, October 2010
Deontic statements
 Constitute obligations or prohibitions
 Under the control of authorities, acquirer, ..
 Designers have to comply with deontic statements
• Examples
1. The equipment shall be easy to repair
2. When condition  equipment .MTTR  30 mn
Text Based
Requirement
Interpretative
Material
Property Based
Requirement
 Patrice Micouin –Certification Together, Toulouse, October 2010
Design choice statements
 Constitute choices among various possibilities
 Under the control of designer
 Designers have to select design options relying on relevant epistemic
statements and complying with deontic statements
• Examples
 The flow path named « Provide an A/C vertical Position Indication » will be
designed as a sequence including the following processes:
o « To acquire the static pressure »
o « To sense the static pressure »
o « To converte the static pressure »
o « To compute the Vertical Position »
o « To compare computed Vertical Positions »
o « To display the Vertical Position »
 The flow path will be allocated to the following physical processors:
o Static probe
o Transducer
o Air Data Computer
o Flight Display
The process « To compare computed Vertical Positions » will be allocated to
the Flight Display processors
 Patrice Micouin –Certification Together, Toulouse, October 2010
Property Based Requirement
Patrice Micouin, Toward a property based requirements theory: System requirements structured as a semilattice
INCOSE Journal of Systems Engineering, Volume 11, Issue 3 (August 2008)
• Requirement determination is a process that interprets Text
Based Requirements (expectations) in one or more
Property Based Requirements (PBR)
• A PBR is a constraint on a property of an object [kind] that
shall be held [when a condition is met].
• Formal expression
PBR : [When Condition =>] val (Object.Property)  D
• Two relationships among PBRs related to an object kind :
• PBR-1 is more stringent than PBR-2 : PBR-1  PBR-2
• Conjunction of PBRs : PBR-1  PBR-2 is a PBR
 Patrice Micouin –Certification Together, Toulouse, October 2010
Example 1 : Specific Certification Requirement 1303.b
CS 29.1303 Flight and navigation instruments
The following are required flight and navigational instruments:
..
(b) A sensitive altimeter
What is a “sensitive altimeter »?
Interpretative material
AC29.1303 refers TSO C10b that refers AS 392C (canceled) and replaced
by AS 8002A (Air Data Computers) or AS 8009B (other altimeters)
--| PBR from CS29.1303(b)
When Avionics.Power_on val (Avionics.AC-Vertical-Position.Status) =Operative

When AC.Altitude [0ft,5000ft] val (Avionics. AC-Vertical-Position.Accuracy) ≤25ft

When AC.Altitude ]5000ft,8000ft] val (Avionics. AC-Vertical-Position.Accuracy) ≤30ft

When AC.Altitude ]8000ft,11000ft] val (Avionics.AC-Vertical-Position.Accuracy) ≤35ft

When AC.Altitude ]11000ft,..ft] ..
 Patrice Micouin –Certification Together, Toulouse, October 2010
Example 2 : General Certification Requirement 1309.(b).(2).(i)
CS 29.1309 Equipment, systems, and installations
(b) The rotorcraft systems and associated components, considered separately and in relation to other systems, must be
designed so that –
(2) For Category A rotorcraft:
(i) The occurrence of any failure condition which would prevent the continued safe flight and landing of the
rotorcraft is extremely improbable; and
What does mean “extremely improbable »?
What is a “failure condition which would prevent the
continued safe flight and landing »?
Interpretative material
What about vertical position indication?
AC29.1309
AC29.1309Table 5:
AC25.11A
ED79/ARP4754:
IMPROBABLE:
on the order
10-9 or
less isaassigned
to this
--EXTREMELY
Failure conditions
catastrophic“A
: probability
Failure conditions
whichofwould
prevent
safe landing
: classification.”
Failure Condition Classification
Failure Condition
Catastrophic
Loss of all barometric altitude displays, including standby display
Display of misleading barometric altitude information on one primary display
combined with a standby failure (loss of altitude or incorrect altitude)
HazardDevelopment
Qualitative
System
Level
Classification
Probability
A
Extremely
Catastrophic
Improbable
Catastrophic
Extremely
Improbable
--| PBR from CS29.1309(b)(2)(i)
When In_Flight => Prob(Avionics.AC-Vertical-Position-Indication.Status=Loss) ≤10-9/fh

When In_Flight => Prob(Avionics.AC-Vertical-Position-Indication.Status=Misleading) ≤10-9/fh

Avionics.DAL=A
Failure Conditions
&
Categorization
Acquirer
Requirements
Other
Stakeholder trace to
Requirements
trace to
EIA 632 Process Framework
The meaning of « derived requirement » (DR) is not the one
generally used Extended
by the aeronautical
community. However, it is
Framework
consistent interpretation of the ARP 4754 definition of DRs. J. Scott
develops this approach of DRs.
ARP 4754
§ 4.4.3
System
High level
Technical
“While there
specific
recommended process for systems development, a
Safetyis no
trace
to
Requirements
Requirements
generic
development model
is described in Appendix A to assist in establishing
common terminology and understanding. The specific development process
Technical
selected should be described in sufficient detailDerived
to achieve mutual understanding
drive
of the key elements assigned
and their
relationships.”
to
Requirements
assigned to
Solution Definition
Requirement Definition
 Patrice Micouin –Certification Together, Toulouse, October 2010
Requirement & Design
Process Framework
assigned to
drive
drive
Logical
assigned to
Solution
Representations
Physical
Solution
Representations
assigned to
Safety
Assessment
Representations
Source de
DESIGN
SOLUTION
Specified by
SPECIFIED
REQUIREMENTS
Specified Requirements are
validated iff System Technical
Requirements  Specified
Requirements
Requirement
Logical Solution
 Patrice Micouin –Certification Together, Toulouse, October 2010
Requirement 1303.b logical implementation
Avionics shall provide a A/C vertical Position Indication
Atmosphere
To acquire
the static
pressure
To compute
the Vertical
Position
Atmosphere
Vertical-Position-Indication
Corrections
Pilot
Source
To display
the Vertical
Position
To correct
the
reference
static
pressure
Flow path
Sink
Provide a A/C vertical Position Indication Vertical Position Indication
Physical Solution
Logical Solution Representation
Representation
Safety Assessment
representation
 Patrice Micouin –Certification Together, Toulouse, October 2010
Requirement
Avionics shall provide the A/C vertical Position Indication
To
To sense
converte
To acquire
the static
the static
the
static
pressure
pressure
pressure
Atmosphere
To compute
the Vertical
Position
To display
the Vertical
Position
Vertical-Position-Indication
Corrections
To
To record
To
correct the reference
keyboard
the
the
static pressure
correction
Pilot
correction
Baro
Pilot
Redundancy = 1
Corrections
Atmosphere
Static
probe
Transducer
Vertical-PositionIndication.Loss
OR
p1
Static
probe .loss
Fli ght
Display
Air Data
Computer
p2
Transducer.
loss
Vertical-Position-Indication
Probabilty of loss=p
p=p1+p2+p3+p4
p3
Air Data
Computer
.loss
p4
Fli ght
Display .loss
Logical Solution
 Patrice Micouin –Certification Together, Toulouse, October 2010
Requirement 1309.b logical implementation
Atmosphere
To acquire
the static
pressure
To compute
the Vertical
Position
To display
the Vertical
Position
Vertical-Position-Indication
To prevent such CAT FCs, the following safety requirement is raised:
--| PBR from CS29.1309(b)(2)(i)
Provide-AC-Vertical-Position
flow path shall be triplicated to allow a ≤10
comparison
-9/fh
When
In_Flight
=> Prob(Avionics.AC-Vertical-Position-Indication.Status=Loss)
With
this minimal
flow path, the occurrence of loss or misleading vertical
position
with at least one dissimilar path-9
 mechanism
indication
has a probability greater than 10 /fh.
--|
PBR
When
In_Flight => Prob(Avionics.AC-Vertical-Position-Indication.Status=Misleading)
≤10-9/fh
-9
Prob(Avionics.AC-Vertical-Position-Indication.Status=Loss) >>10 /fh
 Val(Provide-AC-Vertical-Position.redundancy) 3
-9
 Prob(Avionics.AC-Vertical-Position-Indication. Status=Misleading)>> 10 /fh
Avionics.DAL=A
Val(Provide-AC-Vertical-Position.similarity)  2
Atmosphere
To acquire
the static
pressure
Atmosphere
To acquire
the static
pressure
Atmosphere
To acquire
the static
pressure
To compute
the Vertical
Position
To compute
the Vertical
Position
To compute
the Vertical
Position
To compare
computed
Vertical
Position
To display
the Vertical
Position
Vertical-Position-Indication
To compare
computed
Vertical
Position
To display
the Vertical
Position
Vertical-Position-Indication
To display
the Vertical
Position
Vertical-Position-Indication
 Patrice Micouin –Certification Together, Toulouse, October 2010
DAL Requirement Derivation
• Requirement derivation is a substitution that replaces a level-n
requirement by the conjunction of level-n+1 requirements under the
assumption that design choices will be actually implemented.
• Example
Req-S : Val (Avionics.DAL) = A
Atmosphere
dReq-P :
Val (Avionics.Primary.DAL) = A
Portion Primary
Avionics
AC-VerticalPosition-Indication
Portion Backup
Design pattern 5, ARP 4754 Table 4
dReq-B : Val (Avionics.Backup.DAL)  C
When ARP4754. Design pattern 5 => Val (Avionics.DAL) = A ≤ Val (Primary.DAL) =
A  Val (Backup.DAL)  C
 Patrice Micouin –Certification Together, Toulouse, October 2010
Logical Solution Representation
Atmosphere
To acquire
the static
pressure
Atmosphere
To acquire
the static
pressure
Atmosphere
To acquire
the static
pressure
To compute
the Vertical
Position
To compute
the Vertical
Position
To compute
the Vertical
Position
To compare
computed
Vertical
Position
To display
the Vertical
Position
Vertical-Position-Indication
To compare
computed
Vertical
Position
To display
the Vertical
Position
Vertical-Position-Indication
To display
the Vertical
Position
Vertical-Position-Indication
 Patrice Micouin –Certification Together, Toulouse, October 2010
Physical Solution Representation
 Patrice Micouin –Certification Together, Toulouse, October 2010
Safety Assessment Representation
 Patrice Micouin –Certification Together, Toulouse, October 2010
Conclusion
The PBR theory and the Requirement & Design process
framework described hereabove are suitable to address an
A/C Model Based System Engineering
1. Dealing with all categories of requirements including
certification requirements and safety requirements,
2. Integrating tightly development and safety assessment
activities
3. Consistent with the ARP 4754 standard.
 Patrice Micouin –Certification Together, Toulouse, October 2010
The latest version of this presentation will be available here :
http://www.micouin.com/archives.html
More information:
 about Property Based Requirement Theory:
Patrice Micouin, Toward a property based requirements theory: System requirements
structured as a semilattice INCOSE Journal of Systems Engineering, Volume 11, Issue
3 (August 2008)
 Derived requirements:
JACKSON Scott, Systems engineering for commercial aircraft, Ashgate Publisher, 1997
McDERMID, John & NICHOLSON, Mark, Extending PSSA for Complex Systems, ISSC
Ottawa, August 2003
 Model Based Engineering
SAE-AS5506A, Architecture Analysis & Design Language (AADL) , 2009-01
OMG Systems Modeling Language, (OMG SysML™) Version 1.2, June 2010
 EIA 632 :
James Martin, Processes for Engineering a System, in The Avionics Handbook edited by C.
Spitzer, CRC Press, 2007
ANSI/EIA 632: Processes for Engineering a System, GEIA, Arlington, VA, 2003.