Contents
1.1 Defining Safety-Critical Software
1.2 Importance of Safety Focus
1.3 Book Purpose and Important Caveats
Part II Context of Safety-Critical Software Development
2 Software in the Context of the System
2.1 Overview of System Development
2.2.1 Importance of System Requirements
2.2.2 Types of System Requirements
2.2.3 Characteristics of Good Requirements
2.2.4 System Requirements Considerations
2.2.4.1 Integrity and Availability Considerations
2.2.4.2 Other System Requirements Considerations
2.2.5 Requirements Assumptions
2.3 System Requirements Validation and Verification
2.3.2 Implementation Verification
2.3.3 Validation and Verification Recommendations
2.4 Best Practices for Systems Engineers
2.5 Software’s Relationship to the System
3 Software in the Context of the System Safety Assessment
3.1 Overview of the Aircraft and System Safety Assessment Process
3.1.2 Functional Hazard Assessment
3.1.3 System Functional Hazard Assessment
3.1.4 Preliminary Aircraft Safety Assessment
3.1.5 Preliminary System Safety Assessment
3.1.7 Aircraft and System Safety Assessments
3.2.1 Development Assurance Levels
3.3 How Does Software Fit into the Safety Process?
3.3.2 Software Development Assurance
3.3.4 Some Suggestions for Addressing Software in the System Safety Process
Part III Developing Safety-Critical Software Using DO-178C
4 Overview of DO-178C and Supporting Documents
4.2 DO-178C and DO-278A Core Documents
4.2.1 DO-278A and DO-178C Differences
4.2.2 Overview of the DO-178C Annex A Objectives Tables
4.3 DO-330: Software Tool Qualification Considerations
4.4 DO-178C Technology Supplements
4.4.1 DO-331: Model-Based Development Supplement
4.4.2 DO-332: Object-Oriented Technology Supplement
4.4.3 DO-333: Formal Methods Supplement
4.5 DO-248C: Supporting Material
5.2 General Planning Recommendations
5.3.1 Plan for Software Aspects of Certification
5.3.2 Software Development Plan
5.3.3 Software Verification Plan
5.3.4 Software Configuration Management Plan
5.3.5 Software Quality Assurance Plan
5.4 Three Development Standards
5.4.1 Software Requirements Standards
5.4.2 Software Design Standards
5.4.3 Software Coding Standards
5.5 Tool Qualification Planning
5.6.2 Requirements Management Plan
6.3 Importance of Good Software Requirements
6.3.1 Reason 1: Requirements Are the Foundation for the Software Development
6.3.2 Reason 2: Good Requirements Save Time and Money
6.3.3 Reason 3: Good Requirements Are Essential to Safety
6.3.4 Reason 4: Good Requirements Are Necessary to Meet the Customer Needs
6.3.5 Reason 5: Good Requirements Are Important for Testing
6.4 The Software Requirements Engineer
6.5 Overview of Software Requirements Development
6.6 Gathering and Analyzing Input to the Software Requirements
6.6.1 Requirements Gathering Activities
6.6.2 Requirements Analyzing Activities
6.7 Writing the Software Requirements
6.7.1 Task 1: Determine the Methodology
6.7.2 Task 2: Determine the Software Requirements Document Layout
6.7.3 Task 3: Divide Software Functionality into Subsystems and/or Features
6.7.4 Task 4: Determine Requirements Priorities
6.7.5 A Brief Detour (Not a Task): Slippery Slopes to Avoid
6.7.5.1 Slippery Slope #1: Going to Design Too Quickly
6.7.5.2 Slippery Slope #2: One Level of Requirements
6.7.5.3 Slippery Slope #3: Going Straight to Code
6.7.6 Task 5: Document the Requirements
6.7.6.1 Document Functional Requirements
6.7.6.2 Document Nonfunctional Requirements
6.7.6.4 Uniquely Identify Each Requirement
6.7.6.6 Trace Requirements to Their Source
6.7.6.7 Identify Uncertainties and Assumptions
6.7.6.8 Start a Data Dictionary
6.7.6.9 Implement Characteristics of Good Requirements
6.7.7 Task 6: Provide Feedback on the System Requirements
6.8 Verifying (Reviewing) Requirements
6.8.1 Peer Review Recommended Practices
6.9.1 Basics of Requirements Management
6.9.2 Requirements Management Tools
6.11.1 Importance and Benefits of Traceability
6.11.2 Bidirectional Traceability
6.11.3 DO-178C and Traceability
6.11.4 Traceability Challenges
7.1 Overview of Software Design
7.1.2 Software Low-Level Requirements
7.2.1 Structure-Based Design (Traditional)
7.3 Characteristics of Good Design
8 Software Implementation: Coding and Integration
8.2.1 Overview of DO-178C Coding Guidance
8.2.2 Languages Used in Safety-Critical Software
8.2.3 Choosing a Language and Compiler
8.2.4 General Recommendations for Programming
8.2.5 Special Code-Related Topics
8.2.5.2 Compiler-Supplied Libraries
8.5 Verifying the Development Integration
9.2 Importance of Verification
9.3 Independence and Verification
9.4.1 Software Planning Review
9.4.2 Software Requirements, Design, and Code Reviews
9.4.4 Review of Other Data Items
9.5.1 Worst-Case Execution Time Analysis
9.5.3 Link and Memory Map Analysis
9.5.7 Errors and Warnings Analysis
9.6.1 Purpose of Software Testing
9.6.2 Overview of DO-178C’s Software Testing Guidance
9.6.2.1 Requirements-Based Test Methods
9.6.2.2 Normal and Robustness Tests
9.6.3 Survey of Testing Strategies
9.6.3.1 Equivalence Class Partitioning
9.6.3.2 Boundary Value Testing
9.6.3.3 State Transition Testing
9.6.3.4 Decision Table Testing
9.6.3.8 Complexity Measurements
9.6.3.9 Summary and Characteristics of a Good Test
9.6.5.4 Low-Level Requirements Testing versus Unit Testing
9.6.5.5 Handling Requirements That Cannot Be Tested
9.6.5.6 Obtaining Credit for Multiple Levels of Testing
9.6.5.7 Testing Additional Levels of Requirements
9.6.6.2 Reviewing Test Cases and Procedures
9.6.6.3 Using Target Computer versus Emulator or Simulator
9.6.6.4 Documenting the Verification Environment
9.6.6.6 Running Tests for Certification Credit
9.6.11 Automation in the Verification Processes
9.7 Verification of Verification
9.7.1 Review of Test Procedures
9.7.3 Requirements Coverage Analysis
9.7.4 Structural Coverage Analysis
9.7.4.1 Statement Coverage (DO-178C Table A-7 Objective 7)
9.7.4.2 Decision Coverage (DO-178C Table A-7 Objective 6)
9.7.4.3 Modified Condition/Decision Coverage (DO-178C Table A-7 Objective 5)
9.7.4.4 Additional Code Verification (DO-178C Table A-7 Objective 9)
9.7.4.5 Data Coupling and Control Coupling Analyses (DO-178C Table A-7 Objective 8)
9.7.4.6 Addressing Structural Coverage Gaps
9.7.4.7 Final Thoughts on Structural Coverage Analysis
9.9 Recommendations for the Verification Processes
10 Software Configuration Management
10.1.2 Why Is Software Configuration Management Needed?
10.1.3 Who Is Responsible for Implementing Software Configuration Management?
10.1.4 What Does Software Configuration Management Involve?
10.2.1 Configuration Identification
10.2.4.1 Problem Report Management with Multiple Stakeholders
10.2.4.2 Managing Open/Deferred Problem Reports
10.2.5 Change Control and Review
10.2.6 Configuration Status Accounting
10.2.9 Data Control Categories
10.2.11 Software Life Cycle Environment Control
10.4.3 Software Life Cycle Environment Configuration Index
10.4.4 Software Configuration Index
11.1 Introduction: Software Quality and Software Quality Assurance (SQA)
11.1.1 Defining Software Quality
11.1.2 Characteristics of High-Quality Software
11.1.3 Software Quality Assurance
11.1.4 Examples of Common Quality Process and Product Issues
11.2 Characteristics of Effective and Ineffective SQA
12.1 What Is Certification Liaison?
12.2 Communicating with the Certification Authorities
12.2.1 Best Practices for Coordinating with Certification Authorities
12.3 Software Accomplishment Summary
12.4 Stage of Involvement (SOI) Audits
12.4.2 Overview of the Software Job Aid
12.4.3 Using the Software Job Aid
12.4.4 General Recommendations for the Auditor
12.4.5 General Recommendations for the Auditee (the Applicant/Developer)
12.4.6.1 SOI 1 Entry Criteria, Expectations, and Preparation Recommendations
12.4.6.2 SOI 2 Entry Criteria, Expectations, and Preparation Recommendations
12.4.6.3 SOI 3 Entry Criteria, Expectations, and Preparation Recommendations
12.4.6.4 SOI 4 Entry Criteria, Expectations, and Preparation Recommendations
12.5 Software Maturity Prior to Certification Flight Tests
Part IV Tool Qualification and DO-178C Supplements
13 DO-330 and Software Tool Qualification
13.2 Determining Tool Qualification Need and Level (DO-178C Section 12.2)
13.3 Qualifying a Tool (DO-330 Overview)
13.3.2 DO-330 Tool Qualification Process
13.4 Special Tool Qualification Topics
13.4.3 Additional Tool Qualification Considerations
13.4.4 Tool Qualification Pitfalls
13.4.5 DO-330 and DO-178C Supplements
13.4.6 Using DO-330 for Other Domains
14 DO-331 and Model-Based Development and Verification
14.2 Potential Benefits of Model-Based Development and Verification
14.3 Potential Risks of Model-Based Development and Verification
14.5 Certification Authorities Recognition of DO-331
15 DO-332 and Object-Oriented Technology and Related Techniques
15.1 Introduction to Object-Oriented Technology
15.4 FAA-Sponsored Research on OOT and Structural Coverage
15.5.7 Frequently Asked Questions
16.1 Introduction to Formal Methods
16.3 Potential Benefits of Formal Methods
16.4 Challenges of Formal Methods
16.5.2 DO-333 and DO-178C Compared
16.5.2.1 Planning and Development
16.5.2.2 Configuration Management, Quality Assurance, and Certification Liaison
17 Noncovered Code (Dead, Extraneous, and Deactivated Code)
17.2.1 Avoiding Late Discoveries of Extraneous and Dead Code
17.2.2 Evaluating Extraneous or Dead Code
18.2 What Is Field-Loadable Software?
18.3 Benefits of Field-Loadable Software
18.4 Challenges of Field-Loadable Software
18.5 Developing and Loading Field-Loadable Software
18.5.1 Developing the System to Be Field-Loadable
18.5.2 Developing the Field-Loadable Software
18.5.3 Loading the Field-Loadable Software
18.5.4 Modifying the Field-Loadable Software
19.2 What Is User-Modifiable Software?
19.4 Designing the System for UMS
19.5 Modifying and Maintaining UMS
20 Real-Time Operating Systems
20.4 RTOS Kernel and Its Supporting Software
20.4.2 Application Program Interface
20.5 Characteristics of an RTOS Used in Safety-Critical Systems
20.5.3 Compatible with the Hardware
20.5.4 Compatible with the Environment
20.6 Features of an RTOS Used in Safety-Critical Systems
20.6.2 Guaranteed and Deterministic Schedulability
20.6.2.1 Scheduling between Partitions
20.6.2.2 Scheduling within Partitions
20.6.3 Deterministic Intertask Communication
20.6.4 Reliable Memory Management
20.7.1 Technical Issues to Consider
20.7.1.5 Intertask Interference
20.7.2 Certification Issues to Consider
20.7.2.1 Creating a Safe Subset
20.7.2.6 Disconnect with the System
20.7.2.7 Code Compliance Issues
20.7.2.8 Error Handling Issues
20.7.2.10 Partitioning Analysis
20.7.2.11 Other Supporting Software
20.8 Other RTOS-Related Topics
20.8.4 Multicore Processors, Virtualization, and Hypervisors
20.8.6 RTOS Selection Questions
21.1 Introduction to Partitioning
21.1.1 Partitioning: A Subset of Protection
21.1.2 DO-178C and Partitioning
21.2 Shared Memory (Spatial Partitioning)
21.3 Shared Central Processing Unit (Temporal Partitioning)
21.5 Some Partitioning-Related Challenges
21.5.4 Interpartition Communication
21.6 Recommendations for Partitioning
22.3 Summary of DO-178C Guidance on Parameter Data
23.2 DO-200A: Standards for Processing Aeronautical Data
23.3 FAA Advisory Circular 20-153A
23.4 Tools Used for Processing Aeronautical Data
23.5 Other Industry Documents Related to Aeronautical Data
23.5.1 DO-201A: Standards for Aeronautical Information
23.5.3 DO-272C: User Requirements for Aerodrome Mapping Information
23.5.4 DO-276A: User Requirements for Terrain and Obstacle Data
23.5.5 DO-291B: Interchange Standards for Terrain, Obstacle, and Aerodrome Mapping Data
23.5.6 ARINC 424: Standard, Navigation System Database
23.5.7 ARINC 816-1: Embedded Interchange Format for Airport Mapping Database
24.2 Designing Reusable Components
24.3 Reusing Previously Developed Software
24.3.1 Evaluating PDS for Use in Civil Aviation Products
24.3.2 Reusing PDS That Was Not Developed Using DO-178[ ]
24.3.3 Additional Thoughts on COTS Software
24.4.1 Definition of Product Service History
24.4.2 Difficulties in Seeking Credit Using Product Service History
24.4.3 Factors to Consider When Claiming Credit Using Product Service History
25.1 What Is Reverse Engineering?
25.2 Examples of Reverse Engineering
25.3 Issues to Be Addressed When Reverse Engineering
25.4 Recommendations for Reverse Engineering
26 Outsourcing and Offshoring Software Life Cycle Activities
26.3 Challenges and Risks in Outsourcing
26.4 Recommendations to Overcome the Challenges and Risks
Appendix A: Example Transition Criteria
Appendix B: Real-Time Operating System Areas of Concern