Appendix B: Real-Time Operating System Areas of Concern
by Leanna Rierson
Developing Safety-Critical Software
- Cover
- Half title
- Title Page
- Copyright
- Dedication
- Preface
- Acknowledgments
- Author
- Part I Introduction
- Part II Context of Safety-Critical Software Development
- 2 Software in the Context of the System
- 2.1 Overview of System Development
- 2.2 System Requirements
- 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.2.6 Allocation to Items
- 2.3 System Requirements Validation and Verification
- 2.3.1 Requirements Validation
- 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.1 Safety Program Plan
- 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.6 Common Cause Analysis
- 3.1.7 Aircraft and System Safety Assessments
- 3.2 Development Assurance
- 3.2.1 Development Assurance Levels
- 3.3 How Does Software Fit into the Safety Process?
- 3.3.1 Software’s Uniqueness
- 3.3.2 Software Development Assurance
- 3.3.3 Other Views
- 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.1 History of DO-178
- 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 Software Planning
- 5.1 Introduction
- 5.2 General Planning Recommendations
- 5.3 Five Software Plans
- 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 Other Plans
- 5.6.1 Project Management Plan
- 5.6.2 Requirements Management Plan
- 5.6.3 Test Plan
- 6 Software Requirements
- 6.1 Introduction
- 6.2 Defining Requirement
- 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.3 Document Interfaces
- 6.7.6.4 Uniquely Identify Each Requirement
- 6.7.6.5 Document Rationale
- 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 Managing Requirements
- 6.9.1 Basics of Requirements Management
- 6.9.2 Requirements Management Tools
- 6.10 Requirements Prototyping
- 6.11 Traceability
- 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 Software Design
- 7.1 Overview of Software Design
- 7.1.1 Software Architecture
- 7.1.2 Software Low-Level Requirements
- 7.1.3 Design Packaging
- 7.2 Approaches to Design
- 7.2.1 Structure-Based Design (Traditional)
- 7.2.2 Object-Oriented Design
- 7.3 Characteristics of Good Design
- 7.4 Design Verification
- 8 Software Implementation: Coding and Integration
- 8.1 Introduction
- 8.2 Coding
- 8.2.1 Overview of DO-178C Coding Guidance
- 8.2.2 Languages Used in Safety-Critical Software
- 8.2.2.1 Assembly Language
- 8.2.2.2 Ada
- 8.2.2.3 C
- 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.1 Coding Standards
- 8.2.5.2 Compiler-Supplied Libraries
- 8.2.5.3 Autocode Generators
- 8.3 Verifying the Source Code
- 8.4 Development Integration
- 8.4.1 Build Process
- 8.4.2 Load Process
- 8.5 Verifying the Development Integration
- 9 Software Verification
- 9.1 Introduction
- 9.2 Importance of Verification
- 9.3 Independence and Verification
- 9.4 Reviews
- 9.4.1 Software Planning Review
- 9.4.2 Software Requirements, Design, and Code Reviews
- 9.4.3 Test Data Reviews
- 9.4.4 Review of Other Data Items
- 9.5 Analyses
- 9.5.1 Worst-Case Execution Time Analysis
- 9.5.2 Memory Margin Analysis
- 9.5.3 Link and Memory Map Analysis
- 9.5.4 Load Analysis
- 9.5.5 Interrupt Analysis
- 9.5.6 Math Analysis
- 9.5.7 Errors and Warnings Analysis
- 9.5.8 Partitioning Analysis
- 9.6 Software Testing
- 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.2.2.1 Normal Test Cases
- 9.6.2.2.2 Robustness Test Cases
- 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.5 Integration Testing
- 9.6.3.6 Performance Testing
- 9.6.3.7 Other Strategies
- 9.6.3.8 Complexity Measurements
- 9.6.3.9 Summary and Characteristics of a Good Test
- 9.6.4 Test Planning
- 9.6.5 Test Development
- 9.6.5.1 Test Cases
- 9.6.5.2 Test Procedures
- 9.6.5.3 DO-178C Requirements
- 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 Test Execution
- 9.6.6.1 Performing Dry Runs
- 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.5 Test Readiness Review
- 9.6.6.6 Running Tests for Certification Credit
- 9.6.7 Test Reporting
- 9.6.8 Test Traceability
- 9.6.9 Regression Testing
- 9.6.10 Testability
- 9.6.11 Automation in the Verification Processes
- 9.7 Verification of Verification
- 9.7.1 Review of Test Procedures
- 9.7.2 Review of Test Results
- 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.8 Problem Reporting
- 9.9 Recommendations for the Verification Processes
- 10 Software Configuration Management
- 10.1 Introduction
- 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 SCM Activities
- 10.2.1 Configuration Identification
- 10.2.2 Baselines
- 10.2.3 Traceability
- 10.2.4 Problem Reporting
- 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.7 Release
- 10.2.8 Archival and Retrieval
- 10.2.9 Data Control Categories
- 10.2.10 Load Control
- 10.2.11 Software Life Cycle Environment Control
- 10.3 Special SCM Skills
- 10.4 SCM Data
- 10.4.1 SCM Plan
- 10.4.2 Problem Reports
- 10.4.3 Software Life Cycle Environment Configuration Index
- 10.4.4 Software Configuration Index
- 10.4.5 SCM Records
- 10.5 SCM Pitfalls
- 10.6 Change Impact Analysis
- 11 Software Quality Assurance
- 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
- 11.2.1 Effective SQA
- 11.2.2 Ineffective SQA
- 11.3 SQA Activities
- 12 Certification Liaison
- 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.1 Overview of 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 SOI Review Specifics
- 12.4.6.1 SOI 1 Entry Criteria, Expectations, and Preparation Recommendations
- 12.4.6.1.1 SOI 1: When It Occurs
- 12.4.6.1.2 SOI 1: What to Expect
- 12.4.6.1.3 SOI 1: How to Prepare
- 12.4.6.2 SOI 2 Entry Criteria, Expectations, and Preparation Recommendations
- 12.4.6.2.1 SOI 2: When It Occurs
- 12.4.6.2.2 SOI 2: What to Expect
- 12.4.6.2.3 SOI 2: How to Prepare
- 12.4.6.3 SOI 3 Entry Criteria, Expectations, and Preparation Recommendations
- 12.4.6.3.1 SOI 3: When It Occurs
- 12.4.6.3.2 SOI 3: What to Expect
- 12.4.6.3.3 SOI 3: How to Prepare
- 12.4.6.4 SOI 4 Entry Criteria, Expectations, and Preparation Recommendations
- 12.4.6.4.1 SOI 4: When It Occurs
- 12.4.6.4.2 SOI 4: What to Expect
- 12.4.6.4.3 SOI 4: How to Prepare
- 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.1 Introduction
- 13.2 Determining Tool Qualification Need and Level (DO-178C Section 12.2)
- 13.3 Qualifying a Tool (DO-330 Overview)
- 13.3.1 Need for DO-330
- 13.3.2 DO-330 Tool Qualification Process
- 13.4 Special Tool Qualification Topics
- 13.4.1 FAA Order 8110.49
- 13.4.2 Tool Determinism
- 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.1 Introduction
- 14.2 Potential Benefits of Model-Based Development and Verification
- 14.3 Potential Risks of Model-Based Development and Verification
- 14.4 Overview of DO-331
- 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.2 Use of OOT in Aviation
- 15.3 OOT in Aviation Handbook
- 15.4 FAA-Sponsored Research on OOT and Structural Coverage
- 15.5 DO-332 Overview
- 15.5.1 Planning
- 15.5.2 Development
- 15.5.3 Verification
- 15.5.4 Vulnerabilities
- 15.5.5 Type Safety
- 15.5.6 Related Techniques
- 15.5.7 Frequently Asked Questions
- 15.6 OOT Recommendations
- 15.7 Conclusion
- 16 DO-333 and Formal Methods
- 16.1 Introduction to Formal Methods
- 16.2 What Are Formal Methods?
- 16.3 Potential Benefits of Formal Methods
- 16.4 Challenges of Formal Methods
- 16.5 DO-333 Overview
- 16.5.1 Purpose of DO-333
- 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
- 16.5.2.3 Verification
- 16.6 Other Resources
- Part V Special Topics
- 17 Noncovered Code (Dead, Extraneous, and Deactivated Code)
- 17.1 Introduction
- 17.2 Extraneous and Dead Code
- 17.2.1 Avoiding Late Discoveries of Extraneous and Dead Code
- 17.2.2 Evaluating Extraneous or Dead Code
- 17.3 Deactivated Code
- 17.3.1 Planning
- 17.3.2 Development
- 17.3.3 Verification
- 18 Field-Loadable Software
- 18.1 Introduction
- 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
- 18.6 Summary
- 19 User-Modifiable Software
- 19.1 Introduction
- 19.2 What Is User-Modifiable Software?
- 19.3 Examples of UMS
- 19.4 Designing the System for UMS
- 19.5 Modifying and Maintaining UMS
- 20 Real-Time Operating Systems
- 20.1 Introduction
- 20.2 What Is an RTOS?
- 20.3 Why Use an RTOS?
- 20.4 RTOS Kernel and Its Supporting Software
- 20.4.1 RTOS Kernel
- 20.4.2 Application Program Interface
- 20.4.3 Board Support Package
- 20.4.4 Device Driver
- 20.4.5 Support Libraries
- 20.5 Characteristics of an RTOS Used in Safety-Critical Systems
- 20.5.1 Deterministic
- 20.5.2 Reliable Performance
- 20.5.3 Compatible with the Hardware
- 20.5.4 Compatible with the Environment
- 20.5.5 Fault Tolerant
- 20.5.6 Health Monitoring
- 20.5.7 Certifiable
- 20.5.8 Maintainable
- 20.5.9 Reusable
- 20.6 Features of an RTOS Used in Safety-Critical Systems
- 20.6.1 Multitasking
- 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.6.5 Interrupt Processing
- 20.6.6 Hook Functions
- 20.6.7 Robustness Checking
- 20.6.8 File System
- 20.6.9 Robust Partitioning
- 20.7 RTOS Issues to Consider
- 20.7.1 Technical Issues to Consider
- 20.7.1.1 Resource Contention
- 20.7.1.2 Priority Inversion
- 20.7.1.3 Memory Leaks
- 20.7.1.4 Memory Fragmentation
- 20.7.1.5 Intertask Interference
- 20.7.1.6 Jitter
- 20.7.1.7 Vulnerabilities
- 20.7.2 Certification Issues to Consider
- 20.7.2.1 Creating a Safe Subset
- 20.7.2.2 User’s Manual
- 20.7.2.3 Reverse Engineering
- 20.7.2.4 Deactivated Features
- 20.7.2.5 Complexity
- 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.9 Problem Reporting
- 20.7.2.10 Partitioning Analysis
- 20.7.2.11 Other Supporting Software
- 20.7.2.12 Target Testing
- 20.7.2.13 Modifications
- 20.8 Other RTOS-Related Topics
- 20.8.1 ARINC 653 Overview
- 20.8.2 Tool Support
- 20.8.3 Open Source RTOSs
- 20.8.4 Multicore Processors, Virtualization, and Hypervisors
- 20.8.5 Security
- 20.8.6 RTOS Selection Questions
- 21 Software Partitioning
- 21.1 Introduction to Partitioning
- 21.1.1 Partitioning: A Subset of Protection
- 21.1.2 DO-178C and Partitioning
- 21.1.3 Robust Partitioning
- 21.2 Shared Memory (Spatial Partitioning)
- 21.3 Shared Central Processing Unit (Temporal Partitioning)
- 21.4 Shared Input/Output
- 21.5 Some Partitioning-Related Challenges
- 21.5.1 Direct Memory Access
- 21.5.2 Cache Memory
- 21.5.3 Interrupts
- 21.5.4 Interpartition Communication
- 21.6 Recommendations for Partitioning
- 22 Configuration Data
- 22.1 Introduction
- 22.2 Terminology and Examples
- 22.3 Summary of DO-178C Guidance on Parameter Data
- 22.4 Recommendations
- 23 Aeronautical Data
- 23.1 Introduction
- 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.2 DO-236B: Minimum Aviation System Performance Standards: Required Navigation Performance for Area Navigation
- 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 Software Reuse
- 24.1 Introduction
- 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 Product Service History
- 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 Reverse Engineering
- 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.1 Introduction
- 26.2 Reasons for Outsourcing
- 26.3 Challenges and Risks in Outsourcing
- 26.4 Recommendations to Overcome the Challenges and Risks
- 26.5 Summary
- Appendix A: Example Transition Criteria
- Appendix B: Real-Time Operating System Areas of Concern
- Appendix C: Questions to Consider When Selecting a Real-Time Operating System for a Safety-Critical System
- Appendix D: Software Service History Questions
- Index
Appendix B Real-Time Operating System Areas of Concern
Acronym
| API | application program interface |
| C | dead or deactivated code |
| COTS | commerical off-the-shelf |
| CPU | central processing unit |
| D | data consistency |
| FAA | Federal Aviation Administration |
| I | interrupts and exceptions |
| I/O | input/output |
| M | memory and I/O device access |
| Q | queuing |
| RTOS | real-time operating system |
| S | scheduling |
| T | tasking |
| TCB | task control block |
Overview
This appendix includes a table from the Federal Aviation Administration (FAA) Research Report DOT/FAA/AR-02/118, Study of commercial off-the-shelf (COTS) real-time operating systems (RTOS) in aviation applications. Table B.1 is publicly available at www.faa.gov; however, it is included for convenience. It identifies common areas of concerns for RTOSs. The following seven functional areas should be considered: data consistency (D), dead or deactivated code (C), tasking (T), scheduling (S), memory and input/output (I/O) device access (M), queuing (Q), and interrupts and exceptions (I). See Chapter 20 for additional information on RTOSs.
Table B.1 Typical RTOS Areas of Concern
References
1. V. Halwan and J. Krodel, Study of commercial off-the-shelf (COTS) real-time operating systems (RTOS) in aviation applications, DOT/FAA/AR-02/118 (Washington, DC: Office of Aviation Research, December 2002).
-
No Comment
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.