Transcript DO-178B and DO-178C Software Considerations in Airborne

RTCA DO-178C
“Software Considerations in Airborne Systems and
Equipment Certification”
Brock Greenhow
March 21, 2013
Software mishaps in
Aerospace Engineering
 Ariane Five rocket explosion
 Southern Airways 242
 Gimli Glider
 Patriot Missile
Future of Safety Critical
Software
 Increased lines of code
 Increased complexity
 Increased criticality
 Technology changes
 More with less
 Increased outsourcing and offshoring
 Attrition of experienced engineers
 Lack of available training
Background of DO-178
 1982 – DO-178
 1985 – DO-178A
 1992 – DO-178B
 2001 – DO-248B
 2011 – DO-178C and supplemental material
 2011 – DO-248C
Differences from DO-178B to
C
 Added examples and explanations
 Used clearer language and terminology
 Added more objectives
 Bi-directional tracing
 Parameter Data Item Files
 Technology Supplements
ARP4754A System
Development
 System Requirements
 Allocate requirements to software
 Validate requirements
 Communication
 Plan for changes to come from software
ARP4761 Aircraft and System
Safety
 Safety Program Plan
 FHA and SFHA’s
 PASA and PSSA’s
 Software Safety




Improves with time
Errors are not as obvious
Need specific requirements
Involve safety and systems in software requirement
reviews
Safety continued
Severity
Classification
Potential Failure Condition Effect
Assurance
Level
Catastrophic
Failures would result in multiple fatalities and possible complete
loss of the airplane.
A
Hazardous/Severe
major
Failures would reduce the abilities of airplane or crewmembers
to deal with conditions that could result in reduction of safety
margins, distress and excessive workload, or even serious or
fatal injuries to a small number of people.
B
Major
Failures would cause similar to issues to the Hazardous/Severe
major, but not as severe and likely only injuries and not
casualties.
C
Minor
Failures would not significantly reduce airplane safety, and only
slight increase of workload and minimal discomfort.
D
Failures have no effect on the safety of the aircraft.
E
No safety effect
Safety Continued
Level
Objective Count
Objectives with independence
E
0
0
D
26
2
C
62
5
B
69
18
A
71
30
Overview of DO-178C
 Software Planning
 Software Requirements
 Software Design
 Software Integration
 Software Verification
 Software Configuration Management
 Software Quality Assurance
 Software Certification
Software Planning
 Five Plans





PSAC
SDP
SVP
SCMP
SQAP
 Three Standards
 Software Requirement Standards
 Software Design Standards
 Software Coding Standards
Software Requirements
 Foundation to good software
 Refine Systems Requirements
 Allocate enough time
 Software Requirement Cycle
 Bi-Directional Tracing
 Baseline SWRD
Software Design
 Architecture
 Structural-based
 Object-oriented
 Low-level Requirements
 Bi-Directional Tracing
 SWDD
Software Implementation
 Coding




Languages and compilers
Good programming
Standards
Traceability
 Integration
 Build process
 Load process
 Analyze memory and addresses
Software Verification
 Reviews
 Plans, requirements, design, test data
 Analyses
 Code and integration
 Coverage
 Other
 Tests
 RBTs, integration
 Cases, procedures, results
 Tracing
Software Verification
Continued
 Verification of Verification
 SCA, MC/DC
 Test data reviews
 Problem Reporting
 Failures become PR or CR
 PR or CR process
 CIA
 SVCP
Software Configuration
Management
 Beginning to End
 All life cycle data
 CC1 or CC2
 SCI
 Life cycle data and versions
 SLECI and Problem Reporting
Software Quality Assurance
 Customer’s needs
 Review plans and write SQAP
 Life cycle data audits and approval
 Reviews
 Witness tests, builds, and loads
 Problem reporting
 Conformity review
 Document activities for records
Software Certification
 Develop and submit PSAC
 PSAC approval
 Submittal and approval of SCI and SAS
 SOIs
Supplemental Materials
 DO-330 Software Tool Qualification
 DO-331 Model-Based Development and Verification
 DO-332 Object-Oriented Technology
 DO-333 Formal Methods
Software Tool Qualification
 Separate Document compared to DO-178B
 Three criteria
 TQL
 Life Cycle similar to whole software
 Tool verification
 Reviews
 RBTs
Model-Based Development
and Verification
 2 types of Models
 Specification
 Design
 Benefits
 Potential Risks
Object-Oriented Technology
 Most popular
 Additional/Modified objectives
 Plans
 Development
 Verification
 Vulnerability guidance
Formal Methods
 Changes
 Plans
 Verification objectives
 Benefits
 Challenges
Sources

Pictures
 http://blog.copdfoundation.org/wp-content/uploads/2012/09/C-Users-sschlegelPictures-Question-Mark-Man.jpg

Information
 Rierson, L. (2013). Developing safety-critical software. Boca Raton, FL: CRC Press.
 Jacklin, S. A. NASA, (2012). Certification of safety-critical software under do-178c and do278a . Retrieved from Ames Research Center website:
http://ntrs.nasa.gov/search.jsp?R=20120016835

Arnold, D. (2000, August 23). The explosion of the ariane 5. Retrieved from
http://www.ima.unm.edu/~arnold/disasters/ariane.html

Arnold, D. (2000, August 23). The patriot missile failure. Retrieved from
http://www.ima.unm.edu/~arnold/disasters/patriot.html

Nelson, W. H. (1997). The gimli glider. Retrieved from
http://www.wadenelson.com/gimli.html

Fleury, M. K. (2009, April 29). Crash of southern airways flight 242, georgia. Retrieved from
http://suite101/article/crash-of-southern-airways-flight-242-a113420
Questions?