Introduction to DO254 Clive Lee

1
Introduction to DO-254Clive Lee
2
Introduction to DO-254

• Aircraft/System/Safety Context of DO-254
• Regulations, Failure Condition, DALs
• Description of Contents of DO-254
• Summary

3
Guidance for Hardware Developers

• Reference RTCA DO-254/EUROCAE ED-80
• Title Design Assurance Guidance for
  Airborne Electronic Hardware
• Aim design assurance guidance to ensure
  Complex Electronic Hardware (CEH) will
  safely perform its intended function(s)
• CEH from LRUs, Circuit Boards, Integrated
  Circuits
• Audience system suppliers

4
Aircraft Safety - System Safety
5
Civil Certification Requirements

• FAR/CS 25.1309
• 25 Large Transport Aircraft
• 1309 Equipment, systems and installations
• Certification Requirement
• required equipment must perform as intended
• the probability of a Failure Condition must be
  shown to be inversely proportional to the
  severity of its effect, and
• a single failure must not result in a
  catastrophe.
• AMC 25.1309 provides guidance on showing
  compliance.
• Acceptable Means of Compliance.

6
Compliance

• Acceptable Means of Compliance
• AMC 25.1309
• describes system safety assessment required
• (System Analysis and Design) to demonstrate
  compliance
• Guidance
• SAE ARP 4761 Guidelines and Methods for
  Conducting the Safety Assessment Process on Civil
  Airborne Systems
• has the same intent as AMC 25.1309 but has more
  detailed guidance. (N.B. No official status)

7
Definition of Failure Condition

• A condition having an effect on the aeroplane
  and/or its occupants, either direct or
  consequential, which is caused or contributed to
  by one or more failures or errors, considering
• flight phase, and
• relevant adverse operational conditions,
• environmental conditions, or
• external events. AMC 25.1309

8
Examples of Critical Failure Conditions

• Display of misleading attitude information to
  pilot(s) without a warning.
• Display of misleading airspeed without warning
  together with loss of overspeed or underspeed
  protection.
• Autopilot hardover beyond structural limits.
• Uncommanded reverse thrust deployment at high
  engine power and critical flight phase.
• Engine rotational overspeed together with loss of
  overspeed protection.

100 such system Failure Conditions are assumed to
exist.
9
Regulatory Safety Targets

• Based on statistics for accidents. For most
  severe accidents (loss of aircraft, passenger or
  crew death ), world-wide rate is c. 1 per
  million flight hours.
• Safety target is set at this rate of 1 per
  million flight hours, equivalently, target
  probability of a catastrophic accident is 10-6
  per hour of flight.
• Only 10 percent of fatal accidents have been
  attributed to a critical Failure Condition
  involving aircraft systems i.e. factor of 0.1 for
  safety target

10
System Safety Targets

• There are c. 100 catastrophic Failure Conditions
• Thus, to prevent a deterioration of the current
  fatal accident rate, the probability of
  occurrence of each catastrophic Failure Condition
  must be shown to be at most
• ( 10-6 ) x (0.1) x (10-2 )
• 10-9 per flight hour.
• The certification criteria of 25.1309 is based on
  this fundamental safety target.

11
System Safety Assessment

• An analysis of the system design defines safety
  related requirements that specify the desired
  immunity from, and system responses to, failure
  conditions.
• These requirements are defined for hardware and
  software to preclude or limit the effects of
  faults, and may provide fault detection and fault
  tolerance.

12
Assessment Considerations

• The effects of system failures need to be
  considered with respect to
• Loss of function and recovery,
• Overall effect of anomalous behaviour, and
• Subsequent failures during the same flight.
• System architecture is a major consideration when
  determining Hardware level.
• The severity of anomalous behaviour depends on
  crew recognition and possible crew mitigating
  actions.

13
Development Assurance

• Defined in AMC 25.1309 as
• All those planned and systematic actions used
  to substantiate, to an adequate level of
  confidence, that errors in requirements, design,
  and implementation have been identified and
  corrected such that the system satisfies the
  applicable certification basis.

14
Development Assurance Levels

• The required confidence in development is related
  to the criticality of the system.
• ARP 4754
• Certification Considerations for
  Highly-Integrated or Complex Aircraft Systems
• Development Assurance Levels (DALs)
• DALs are used in both software and hardware
  development life cycles and determine the rigour
  of the processes involved.
• DO-254 uses the term Design Assurance Level
• DO-178B uses the term Software Level

15
Development Assurance Levels

• Level A Subsystem/Hardware/Software whose
  anomalous behavior, as shown by the system
  safety assessment, would cause or contribute to a
  failure of system function resulting in a
  catastrophic failure condition for the aircraft.
• The same definition is used for other levels but
  related as shown in the following table.

16
Relationship to Failure Conditions
17
Some Common Assurance Levels
18
System Hardware Safety
19
Contents of DO-254
20
SYSTEM ASPECTS RELATING TO H/w DESIGN
ASSURANCE -Section 2
INTRODUCTION
DO-254 OVERVIEW
21
Contents of DO-254

• System Aspects of H/w Design Assurance (Section
  2)
• H/w life cycle Planning Process (Section 3 and
  4)
• Hardware Design Processes (Section 5)
• Requirements Capture (Section 5.1)
• Conceptual Design (Section 5.2)
• Detailed Design (Section 5.3)
• Implementation (Section 5.4)
• Integral Processes (Sections 6 to 9)
• Validation and Verification (Section 6)
• Configuration Management (Section 7)
• Process Assurance (Section 8)
• Certification Liaison (Section 9)

22
Hardware Lifecycle and associated life cycle data
items

• Guidance is based around generic Hardware
  Lifecycle and its associated data items .
• Your project or organisation may have its own
  Hardware design process life cycle.
• You should show how your life cycle maps onto
  DO-254, paying attention to gaps.
• Similarly, you must show how your data items map
  to the generic list, paying attention to any data
  items in DO-254 that are not fully or explicitly
  addressed in your list.

23
Section 2 System Aspects

• Information Flow (Section 2.1)
• See following slides
• System Safety Assessment Process (Section 2.2)
• DALs (Table 2.1 Development/Design Assurance
  Levels)
• Describes FHA, PSSA and SSA
• Hardware Safety Assessment (Section 2.3)
• Functional Failure Path Analysis (Appendix B)
• Design Assurance Strategy (Figure 2.3)
• Entire item at highest DAL? Orindividual
  functions to their respective DALs(N.B.
  protection from adverse effects important issue)
  

24
Safety Assessment Process AMC 25.1309/ARP 4761
Function, Failure Safety Information
Intended Aircraft Function
System Design
System Development Process AMC 25.1309/ARP 4754
Functional system
Allocated Functions Requirements
Implementation
Hardware Development Life Cycle DO-254
Complex Functions
Software Development Life Cycle DO-178B
25
System Safety Assessment Process
Hardware Life Cycle Processes
Information Flow System Hardware Design
26
Developing Hardware Design Assurance Strategy
(Section 2.3)

• 1. Undertake Hardware Safety Assessment
• Determine Functional Failure Paths of item
• Allocate DAL to each FFP (use system safety
  assessment)
• 2. Select Special Methods (Appendix B)
• Required for complex, high integrity (DAL A or B)
  h/w
• 3. Address Fail-Safe Aspects (DAL ABC)
• Complete, analyse system and document strategy
• 4. Document Design Assurance Approach
• All DALs

27
Appendix B Design Assurancefor Complex, High
Integrity H/w

• Functional Failure Path Analysis (FFPA)
• Design Assurance for high integrity functions
• Architectural Mitigation
• Product Service Experience
• Advanced Verification Methods
• Elemental Analysis
• Safety-specific analysis
• Formal Methods

28
Functional Failure Path Analysis

• Start with system FFPs identified during PSSA
• Conventional Safety Assessment techniques
• Top-down decomposition techniques
• Fault Tree Analysis
• Complemented with other techniques
• Functional-FMEA, common mode analysis
• System level FFPs decomposed into
• Hardware level FFPs and then
• Circuit level FFPs
• Component level FFPs
• Elemental level FFPs

29
Appendix B Design Assurance

• Methods are based on FFPA and assume FFPs will be
  produced
• Architectural Mitigation
• Different architectural designs (e.g. redundancy,
  monitor) evaluated by checking each FFP.
• Product Service Experience
• A method for evaluating evidence based on service
  experience of products with similar FFPs is
  suggested. (not mature)
• Elemental Analysis
• A method used to check that all the FFPs are
  verified by appropriate verification test cases.

30
Presentation of DO-254

• Sections 1-3, introduce system context
  lifecycle
• Sections 10,11 list lifecycle data and extra
  material
• Sections 49 describe the objectives for each
  process and how to achieve them.
• Section 5 Design Processes
• (Requirements Capture, Design,Implementation)
• Section 6 Validation and Verification
• Section 7,8,9 Config. Man, Assurance, Liaison
• For each Process in lifecycle, the guidelines
  present
• Objectives for the Process
• Activities for achieving those objectives

31
H/w Design Life Cycle (Section 3)

• Overview Generic Life Cycle Processes
• Planning (Section 4)
• Hardware Design Processes (Section 5)
• Requirements Capture (5.1)
• Conceptual Design, Detailed Design (5.2,5.3)
• Implementation (5.4)
• Validation and Verification (Section 6)
• Configuration Management (Section 7)
• Process Assurance (Section 8)
• Certification Liaison (Section 9)

32
H/w Design Life Plans(Section 11)

• Planning
• Plan for Hardware Aspects of Certification
• Hardware Design Plan
• Requirements Standards
• Hardware Design Standards
• Hardware Archive Standards
• H/w Validation Plan and H/w Verification Plan
• H/w Configuration Management Plan
• Process Assurance Plan
• Certification Liaison (see PHAC)

33
H/w Design Life Data (Section 10)

• Hardware Design Data
• Hardware Requirements
• Hardware Design Representation Data
• Conceptual and Detailed Design Data
• Validation and Verification Data
• Hardware Acceptance Test Criteria
• H/w Configuration Management Records
• H/w Process Assurance Records
• Problem Reports
• Certification Liaison
• Hardware Accomplishment Summary

34
Example Conceptual Design

• Objectives in Section 5.2.1
• Design is consistent with requirements
• Derived requirements fed back to Reqs Capture
• Activities in Section 5.2.2
• Generate high-level description
• Identify major components
• Feed back Derived requirements to Reqs Capture
• .

35
Hardware Requirements Definitions

• High-level - Hardware requirements developed from
  analysis of system requirements, safety-related
  requirements, and system architecture.
• Derived - Additional requirements resulting from
  the Hardware development processes, which may not
  be directly traceable to higher level
  requirements.
• Low-level - Hardware requirements derived from
  high-level requirements, derived requirements,
  and design constraints

36
Appendices

• There are four appendices
• Appendix A Modulation of Hardware Life Cycle
  Data based on Hardware DAL
• Appendix B Design Assurance Considerations for
  Level A B functions
• Appendix C Glossary
• Appendix D Acronyms

37
Purpose of DO-254

• DO-254 provides guidelines for the production
  of Complex Electronic Hardware for airborne
  systems and equipment.
• Its use aims to deliver CEH with a level of
  confidence that complies with airworthiness
  requirements.
• The guidance consists of
• Objectives for Hardware life cycle processes
• Descriptions of design considerations and
  activities for achieving those objectives.
• Descriptions of the evidence that indicate that
  the objectives have been satisfied.

38
Compliance with DO-254

• Compliance is established by ensuring that
  specified objectives have been met and that
  evidence is provided in related data items.
• The specific objectives to be met are determined
  by the Hardware DAL (Appendix A)
• Depending also on the Hardware Level,
  establishing that an objective has been met may
  require the assessor to be independent from the
  developer.

39
A Compliant Safety Process

• Hardware safety requirements are a product of the
  avionic system development processes. They are
  not set by RTCA document DO-254.
• AMC 25.1309 describes System Safety Assessment
  processes that can establish safety requirements.
  
• It is important to set the context of DO-254 in
  relation to AMC 25.1309.
• The AMC references RTCA document DO-254 together
  with SAE Recommended Practices ARP 4761 and ARP
  4754 as guidance and advisory material.

40
Summary

• Safety is considered within the whole system
  concept not just the Hardware.
• Hardware Levels A to E relate to Failure
  Condition effects NOT to system failure rates.
  They set process rigour..
• Confidence is obtained by process assurance since
  failure rates for design (systematic) errors
  cannot be quantified hence cannot be used in the
  statistical analyses.

41
Acronyms
42
Questions
43
Common Problems found by ERA

• Inadequate Hardware Requirements Specification
• No Requirements Traceability
• Compliance and Conformance Assessment following
  development
• Re-engineering of Processes
• Inadequate Configuration Management and Change
  Control
• Long time to issue and accept standards
• Proliferation of COTS / SOUP, including tool
  qualification
• Unrealistic timescales and cost restrictions
• Hardware or Software?