DO-254 Training Overview: One Hour DO-254 Intro by AFuzion - Copyright AFuzion Inc

DO-254 Training. 1-Hour
Overview Excerpt
Copyright AFuzion: 2004 – 2017 www.afuzion.com

Overview
The following presentation is a 1-hour Excerpt from AFuzion’s 2-day Basic
DO-254 Training course. Over 11,500 engineers trained worldwide by
AFuzion’s trainers in DO-254 and DO-178: more than all other trainers in the
world … COMBINED.
 Full Training information available at: http://afuzion.com/training/
 Free Avionics development technical whitepapers available at:
http://afuzion.com/avionics-safety-critical-training-whitepapers/
Copyright AFuzion Inc, 2004 – 2017: www. Afuzion.com Slide ‹#›

About Your Instructor
(Today: Vance Hilderman)
 BSEE, MBA, MSEE (Hughes Fellow)
 Founder of two of the world’s largest avionics
development services companies
 Has personally trained over 10,500 persons in DO-XXX;
more than any other instructor in the world
 Has successfully contributed to over 200 diverse avionics
projects
 Proven Systems, Hardware and Software success with
over 100 different clients
 Have worked with 40+ of North America’s largest avionics
companies and 75 of world’s 100 largest aerospace
companies

 First, Software:
 RTCA DO178C:
 “Software Considerations in Airborne Systems and
Equipment Certification”
 Developed 1980 – 1992
 via 100+ Industry and Government personnel
 Many compromises to satisfy different goals
 Not a recipe book or “How To” guide
 “Discussion” flow for guidance; able to accommodate
many different development approaches
 Lawyers versus Avionics Engineers; who wins?
 In practice: The Golden Rule …
History of DO-254 & DO-178C?

 Then, “Hardware”:
 RTCA DO-254:
 “Design Assurance Guidance for Airborne Electronic
Hardware”
 Developed 1996 – 2000
 via 100+ Industry and Government personnel
 The committee was mostly software people (Thus
similar to DO-178C)
 Strong focus on Complex Electronic Hardware (CEH)
devices (with embedded ‘logic’)
 Provides design assurance for CEH including
Programmable Logic Devices (PLDs) and Application
Specific Integrated Circuits (ASICs)
 Covers ALL Electronic Hardware
History of DO-178C & DO-254?

Guidance is applicable to, but not limited to:
Line
Replaceable
Units (LRUs)
Circuit Card
Assemblies
(CCAs)
Custom micro-
coded components
such as ASICs,
PLDs, FPGAs,
including any
associated macro
functions.
Integrated
technology
components,
such as
hybrids and
multi-chip
modules
Commercial-
Off-The-Shelf
(COTS)
hardware
components
Slide 6
Scope of DO-254

AC 20-152 then CAST 27 limited the scope
of the application of the DO-254 guidance:
Only complex devices
such as ASICs and
PLDs.
Application of the
guidance to level D
design assurance is
optional and on a
case by case basis to
Regulator oversight
and or approval.
The AC has also
strengthened the
exemption for
Commercial-Off-The-
Shelf (COTS)
microprocessors
Slide 7
DO-254 Scope
Limited by AC 20-152 & CAST 27

ARP 4754A’s Safety Regimen
Feedback Loops
Software
DO-178
Hardware
DO-254
System Development
ARP 4754A
Safety
Assessment
ARP 4761
• Architecture
• Criticality Level
SW Rqmts HW Rqmts
Tests Tests
Slide 8Copyright AFuzion Inc, 2004 – 2017: www. Afuzion.com Slide ‹#›

(DO-254)
ARP-4761A
Safety Guidelines
ARP-4754A
Aircraft & System Guidelines
Implementation Lifecycle Guidelines
DO-160: Environ. Testing DO-297: IMA
DO-178C: Airborne Software DO-330: Tool Qualification
DO-200A: Databases DO-331: MBD
DO-254: Airborne Hardware DO-332: OOT
DO-278A: CNS/ATM Software DO-333: Formal Methods
Avionics Development EcosystemTM

1. Introduction
2. System Aspects
3. Design Lifecycle
4. Planning Process
5. Design Process
6. Validation & Verification
7. Configuration Mgmt
8. Process Assurance
9. Certification Liaison
10. Lifecycle Data
11. Additional Considerations
A. Modulation based on level
B. Level A & B Specifics
DO-254 Layout
Planning
Correctness
Development

 Planning Process – Occurs first
 Development Process – Follows Planning
 Integral Processes – Continuous Throughout Project
Slide 11
Three Key Processes
1. Planning
Process
2. Development
Process
3. Integral Processes

1. Detailed planning
2. Five Criticality Levels (A, B, C, D, E)
3. Consistency & Determinism
4. Traceability to detailed requirements
5. Path testing
6. “Guilty Until Proven Innocent”
DO-254 Key Attributes

Copyright 2016
Optimal DO-254 Engineering
Route (per Vance Hilderman, not FAA/EASA)
Safety
Assessment
& Rqmts
Systems
Rqmts
Develop Plans,
Stnds, Chklsts
Develop
Traceability
Implement
CM
HW Rqmts
Start QA/PA
Conceptual
Design
Detailed
Design
Logic
Verification & Validation
Time (Planning Phase)
Time (Development & Correctness Phases)
Integration
Conformity
Review
SOI
#1
SOI
#2
SOI
#3
SOI
#4
Cert

Assess Engineer’s
conformance to
Plans, Standards,
Checklists
Ensure Project’s
Plans, Standards,
Checklists Comply
with DO-254
Slide 14
Process Assurance – PA “only”
does two things …

 Engineering:
1. Create
2. Verify (Review, Test, Analyze)
 PA:
1. Approve Project Plans, Standards, Checklists
2. Assess Engineer’s “Creation” and “Verification”
Slide 15
PA versus Engineering

 PA does NOT Engineer:
 PA does NOT Create or work on Engineering artifacts
 PA does NOT Review
 PA does NOT Test
 PA does NOT Analyze
 What then does PA “do”?!?
 Again, PA:
1. Approves Project Plans, Standards, Checklists
2. Assesses Engineer’s “Creation” and “Verification”
Therefore PA ensures PROCESSES are followed
Slide 16
PA Does Not “Engineer”

PHAC: Plan for Hardware Aspects of Certification
PA/QA: Process/Quality Assurance Plan
CM: Configuration Management Plan
DP: Development Plan
V&VP: Verification & Validation Plan
** Plus 4 Standards (Requirements, Design, Coding,Verification)
1.
PHAC
2.
PA/QA
3.
CM
4.
DP
5.
V&VP
Five Key Plans

Plan for Hardware Aspect of Certification (PHAC)
 30 – 40 pages
 Overview of System, Architecture, & Hardware, Interfaces
 Discusses Safety, Criticality, & Certification
 References Other Plans & Artifacts
 Help prepared by and Approved by DER
 Submitted to and Approved by FAA
PHAC
1.
PHAC
2.
PA/QA
3.
CM
4.
DP
5.
V&VP

• Process/Quality Assurance Plan
 Addresses the Role of PA throughout process
 Ensures that all the plans are coordinated and integral part of
process, and are followed
 Ensures that Transition Criteria is adhered
 Addresses the conformity reviews and inspections
 Provides guidance and timelines for audits/reviews by PA
(Including checklists)
1.
PHAC
2.
PA/QA
3.
CM
4.
DP
5.
V&VP
PA/QA Plan

CM Plan
1.
PHAC
2.
PA/QA
3.
CM
4.
DP
5.
V&VP
Configuration Management Plan
 Established identification of data items
 Addresses the use of the CM system
 Defines criteria for Development CM
 Addresses the Problem reporting and change tracking
system
 Defines the accessibility and authority for data.
 Addresses security, maintainability and repeatability
 Addresses the reproduction of image and all data item
generated, and ability to repeat for manufacturing

Development Plan
 Defines the Schedule, Staffing, dependencies,
deliverables, milestones and organizations
 Addresses the development environment and tools
 Addresses the lifecycle processes (Requirements,
Conceptual Design, Detailed Design,
Logic(Implementation), Synthesis/Integration)
 Addresses the CM and QA/PA involvement (including
Transition Criteria) as well as deliverables
1.
PHAC
2.
PA/QA
3.
CM
4.
DP
5.
V&VP
Development Plan

Validation & Verification Plan
 Addresses Reviews and acceptance
 Traceability
 All aspects of testing and integration
 Test environments and tools
 Regression and re-verifications
 Resources and management
1.
PHAC
2.
PA/QA
3.
CM
4.
DP
5.
V&VP
Validation
Functional
Tests
Simulation
Verification
Validation & Verification Plan

Criticality Level Pyramid
A
B
C
D
E
• Level A: Catastrophic
• Level B: Hazardous/Severe
• Level C: Major
• Level D: Minor
• Level E: No Effect
Criticality Levels

“Hardware, whose anomalous behavior, as shown by the system safety assessment
process, would cause or contribute to a failure of system functions
 Level A; “resulting in a catastrophic failure condition for the aircraft”
 Level B; “resulting in a hazardous/severe-major failure condition for the aircraft”
 Level C; “resulting in a major failure condition for the aircraft”
 Level D; “resulting in a minor failure condition for the aircraft” – DO-254 Option per AC
20-152
 Level E: “with no effect on aircraft operational capability or pilot workload.”
** No further application of DO-254 is required.
Criticality Levels
(Part 25 Failure Rates)
Level E
(NA)
Level D
(>1E-05)
Level C
(<1E-05)
Level B
( <1E-07)
Level A
<1E-09

 Why Does DO-254 Have Different Criticality Levels?
 Who were major DO-178C & DO-254 contributors?
 What were their major concerns?
 Schedule
 Cost
 Safety, but with reasonableness
Level A
<1E-09
Level B
<1E-07
Level C
<1E-05
Level D
>1E-05
Level E
NA
Why Different Criticality
Levels?

Typical System Criticality Level
DAL examples of Systems
DO-178 Level Sample of historical Systems
Slide 26
A Flight controls, Engine Controllers, Primary Displays
B FMS, Many Radios and communication systems.
Many navigation Systems
C Back up Displays, back up communication
systems (SATCOM),
D Maintenance systems, Monitoring Systems (Engine
Vibration Monitors, etc.)
E In Flight entertainment Systems (May be Level D),
Video Systems. Coffee makers and galley services.

 (Note: for more DO-254 Cost/Benefit info, request AFuzion’s free whitepaper at
www.Afuzion.com) and defer to Cost Metrics section of this training on Day 2.
Slide 27
Clearly DO-254 Adds Costs
Why Adopt?
1 Earlier Defect Prevention & Fewer In-Field Defects
2 Greater Reusability
3 Improved Visibility & Confidence of Change Impact
4 Improved Visibility by Management, and of Suppliers
5 Quantified & Improved Safety Determination
6 Reduced Cost, Schedule, & Risks
7 Fewer Assumptions = Fewer Defects
8 More Known & Complete Test Coverage
9 More Complete Documentation Easier Maintenance
10 Wider & Deeper Market Penetration
11 Higher Quality

Safety & System Development
Slide 28

PA Approves 3 Artifact Categories
Checklists
Standards
Plans

DO-254 Level C, Level B, Level A differences
Copyright 2015Slide 30
Per
AC 20-152
DO-254 is
optional for
Level D
Per
AC 20-152
DO-254 is
intended for
complex
coded
components
only
RTCA DO-254
Appendix A
requires
independence for
all verification
activities for
Levels A& B.

DO-254 Level C, Level B, Level A differences
Design Assurance Strategy Differences Per Level
Failure
Classification
Design
Assurance
Level
Design Assurance Strategy Requirement
Catastrophic Level A Invokes Appendix B of DO-254
Hazardous Level B Invokes Appendix B of DO-254
Major Level C Invokes Appendix B of DO-254
OPTIONAL
Minor Level D May opt not to use DO-254 per FAA AC.
Invokes Appendix B of DO-254
OPTIONAL

“The Verification Equation”
Verification Reviews
Tests &
Analysis

What gets reviewed?
Everything …:
 Plans & Standards
 Requirements
 Design
 Logic
 Tests/Results
 Traceabilty
 Problem Reports/Corrections
 Etc.
Slide 33
“Reviews”

 All Reviews need configured Entry (input) Criteria
 Example: Logic Review (DAL A & B)
 What is needed to perform Logic Review?
1. _____________
2. _____________
3. _____________
4. _____________
5. _____________
6. _____________
Slide 34
Reviews Use Entry Criteria,
plus a checklist

Example:
Logic Review “Transition Criteria”
 What are the Inputs & Outputs for a Logic Review?
HW
Logic
Review
1. Source Logic
1. Completed Checklist
2. Logic Review Checklist
3. Logic Standard
4. Hardware Design
5. Hardware Requirements
6. Rqmts Trace Matrix
2. Action Items & Defects
“Transition”

What gets tested?
 Implementation versus specification:
 Requirements
 Logic
Slide 36
“Tests”

Hardware Verification
Tests Reviews Analyses
• Hardware
Requirements
Based Testing
• Logic Testing (A/B)
• Requirements
• Conceptual &
Detailed Design
• Logic
• Requirements Based
Test Results
• Low Level Test
Results Review (A/B)
• Traceability Analysis
(A/B/C)
• Requirements Coverage
Analysis (A/B/C)
• Low Level Test Coverage
Analysis (A/B)
• Structural Coverage (A/B)
• General System Analysis
(A/B/C)
• Static Timing
• Device Usage
• Thermal/Power
• Pin Coverage Analysis
(A/B/C)

Best Practice:
Write Tests BEFORE Design?
Traditional Engineering Sequence:
DO-178C
9. Review Tests & Results
8. Execute Test Cases
7. Write Test Cases Based on Requirements
6. Review Logic
5. Write Logic
4. Review Design
3. Develop Design
2. Review Requirements
1. Write Requirements

Best Practice:
Write Tests BEFORE Design!
Recommended “Best Practice” Engineering Sequence:
DO-178C
8. Review Tests & Results
7. Execute Test Cases
2. Write Test Cases Based on Requirements
6. Review Logic
5. Write Logic
4. Review Design
3. Develop Design
2. Review Requirements, by writing Test Cases!
1. Write Requirements

“The FPGA shall as a goal, calculate aircraft
heading, altitude, and global position to a
sufficient accuracy.”
Is this acceptable -- Why or Why Not?
Requirements Quiz

Sample Requirement
System Requirement:
Electrical power shall be regulated and include a backup voltage
regulator {XYZ_System_1072}.
Hardware Requirements:
The Voltage Regulation System (VRS) FPGA shall continuously
monitor primary power bus voltage and determine if the
voltage is within a valid operating range (XYZ_VRS_309}.
If the VRS FPGA determines the primary power bus voltage is
either above or below the valid operating range, the backup
voltage regulator shall be assigned to take over the role of
the primary voltage regulator {XYZ_VRS_310}.

Sample Requirement
More Hardware Requirements:
The valid operating range for the primary power bus
voltage shall be 24 to 28 Volts D.C. {XYZ_VRS_871}
When the backup voltage regulator becomes primary, a
Backup_Voltage_Regulator_Becomes_Primary message
shall be transmitted to the ground station
{XYZ_VRS_872}.
Derived Requirements (“Safety”):
If the backup voltage regulator is not healthy and the
primary power bus voltage is not within the valid
operating range for more than three consecutive
queries, the operator display shall alert via
Invalid_Operating_Condition message (XYZ_VRS_873}.

Avoid Temptation. Improve
Requirements First.
> Consider:
 For the preceding Voltage Regulation System FPGA
hardware equirements:
 Ask yourself:
 Are the Requirements fully testable?
 Are the Requirements deterministic?
 Does testing rely upon certain assumptions?
 Might two different hardware logic developers
implement differently?
 Finally, if you cannot unambiguously determine
expected intent, how could HW developer?
 Must improve requirements first: many, many assumptions
unaddressed:

Improve Requirements First.
Ask Clarifying Questions: Could you write test cases?!?
> Questions to clarify:
1. What happens with over-voltage, e.g. > 28 volts?
2. Is a single instance of over-voltage a trigger
3. Same as above for under-voltage, e.g. < 24 volts.
4. What determines “health”?
5. Do the Alerts have priorities, and what are the specific priorities?
6. How often is voltage monitored?
7. What is the resolution accuracy of the voltage monitoring?
8. Etc, Etc, Etc
 Ask yourself:
 “ Can two different developers read the same requirements and garner
different assumptions regarding correct implementation? “

Best Practice:
Conduct Requirements Reviews Often
Review Requirements Early and Often – Consider Lean
and Agile, even if informal for safety-critical aviation:
 Conduct more frequent iterative reviews
 Review requirements in smaller batches
 Increase quality by having more thorough reviews &
defined criteria
 Use collaborative techniques during review

Best Practice:
Review Requirements in Context
Review Requirements with their traces in context.
Slide 46
Checklist
LLR
HLR
Test

Best Practice:
Requirements Traceability-Related
When creating new requirements, tests cases, or logic:
 Establish the required traces immediately, not later
when you need to demonstrate those traces to the
auditor
 Make traceability updates mandatory for review of
Requirements, Logic, & Tests
 Two-way traceability for:
1. Requirements to Logic Functions
2. Logic Functions to Tests
3. Requirements to Tests
Slide 47
Requirements
Logic Tests

 Requirements are the foundation for the development
 Requirements specification is an art even if you know
what you want to build
 Requirements review (scrub) is important
 Most hardware errors are due to poorly specified
requirements
Slide 48
Requirements Summary

A Safety-Critical Requirements Quiz:
Answers
1. T/F: On most aviation projects, most requirements pertain to FALSE
Safety.
2. T/F: Hardware requirement development must follow a FALSE
Waterfall.
3. T/F: The best way to assess hardware requirements is via FALSE
test execution.
4. T/F: DO-254 provides clear guidance for FALSE
developing and assessing requirements.
5. T/F: Most hardware product defects are due to bugs FALSE
and manufacturing defects.
6. T/F: When using model-based development, both system and FALSE
hardware requirements must be textual and external to the model.


 DO-254 provides for design/documentation flexibility
 DO-254 Design includes four key processes:
1. Conceptual Design
2. Detailed Design
3. Implementation
4. Production Transition
Hardware Design
Overview

 Conceptual Design
 High-level Design, enabling “bridge” from requirement to
detailed design (see below).
 Detailed Design
 Depicts how the conceptual design is to be interpreted prior to
implementing hardware logic.
Hardware Design Terminology

Four Categories of Tests:
1. Functional Tests
– All Requirements
2. Normal Range Tests
– “Sunny Day” conditions
3. Robustness Tests
– “Rainy Day” conditions
4. Advanced Methods
– Includes Element Analysis
(Structural Coverage – DAL A &
B: Cover all logic/circuits
Functional
Tests
Normal
Range Tests
Robustness
Tests
Advanced
Methods
Verification Testing

System
Rqmts
HW
Rqmts
HW
Conceptual
Design
HW
Detailed
Design
Logic
Functions
Func.
Tests
Coverage
Analysis
0 %
100 %
Traceability Matrix as Metric

Top DO-254 Mistakes
1. Neglecting “Independence”
2. Science projects versus proven technologies
3. Inadequate formal plans and not following them
4. Inadequate level of detail in Requirements
5. Inadequate and non-automated Traceability
6. Excessive logic iterations via inadequate reviews/tools
7. Lack of path coverage capture during functional tests
8. Lack of automated testing = Expen$ive Regression Test
9. Neglecting to eliminate early-stage coding errors
10. Neglecting to prevent unwarranted changes via CM
11. Insufficient PHAC
12. Insufficient Tool Qualification
13. Not taking credit for existing legacy work => “Gap Analysis”
14. Weak DO-254 Checklists & poor Checklist management
Full Details on avoiding above DO-254 Mistakes on Day 2.

DO-254:
Best Practices 2015
DO-254: Best Practices
For 2017.
(1-Hour Module – See
AFuzion Training Day-2)

Gap Analysis
Full DO-254 Gap Analysis Info at: http://afuzion.com/gap-
analysis/
Typical “Gaps” for a
CMMI Level 3
Organization
Versus Level B
CERTIFICATION ACTIVITY % “GAP”
PHAC 80%
PA Plan 20 - 30%
HW CM Plan 10 - 20%
HW Development Plan 40 - 50%
HW Verification & Validation Plan 60 - 70%
Safety Assessment 80 - 90%
Requirements Definition 20 – 30%
Design / Top Level Drawings 10 – 15%
Implementation 5 - 10%
Functional Test 5 – 10%
Elemental Analysis (Levels A/B) 90 – 100%
CM Process 10 – 30%
PA Process 50%
Traceability 40-75%
Tool Qualification 100%
Checklists 30 – 50%
Reviews 30 – 50%
Audits 30 – 50%
DER Liaison 100%
GAPS

ISSUES Hardware
Considerations
 Functionality with no regulatory basis
 Search & Rescue
 Dedicated communication radios
 Coupled flight
 Dedicated communications radios
 Autoflight customizations
 Aerial refueling software
 Boom control
 Fuel management
 Weapons delivery
 Terrain following or low-level operations
 “Black” or “Silent” communications/navigation
 High-performance operations

ISSUES Hardware
Considerations
 Differences for Military DO-254:
 Less, but different, emphasis on Safety Analysis
 Less redundancy but harsher operational
environments; does Commercial measure up?
 Agency approval: generally not FAA/EASA
 All documents reviewed by military/customer; not
just PHAC & HAS

Military “Criticality Level”
Considerations
 Criticality Level:
 based upon passenger safety? No.
 Aircraft safety?
 Civilian areas?
 Aircraft protection (anti-missile defense, etc)?
 Mission success probability?
Copyright AFuzion Inc, 2004 – 2017: www. Afuzion.com

MilitaryIntegrator/Supplier
Considerations
Ensure compliance baseline; reference and use if
appropriate:
 Applicable Technical Standard Orders (TSO’s)
 Applicable Advisory Circulars (AC’s)
 Applicability of ARP-4761 (Safety) and ARP-4754A
(Systems) Guidelines
 Applicability of DO-254 (Airborne Hardware)
 Applicability of DO-278 (Ground Based Software)
 Ensure Military Authority has:
 Right to access & audit ALL artifacts.
 Ability to attend all SOI’s
 Ongoing visibility into supplier Problem Reports/Resolution

Conclusion Q & A
Coming late 2016:
For additional free technical
information:
1. “DO-178C For Engineers & Managers” –
LinkedIn group
2. www.afuzion.com/whitepapers
(free whitepapers for training attendees)
DO-178C
DO-254
DO-278A ISO 26262
AFuzion: When Safety is Critical.TM

Conclusion Q & A
2017:
For additional technical
information:
1. “DO-254 For Engineers & Managers” –
LinkedIn group; free.
2. www.afuzion.com/whitepapers
(free whitepapers for training attendees)

DO-254 Training Overview: One Hour DO-254 Intro by AFuzion - Copyright AFuzion Inc

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (15)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

DO-254 Training Overview: One Hour DO-254 Intro by AFuzion - Copyright AFuzion Inc