Plan for Software Aspects of Certification

for the

<Program Name>

Document No: <Doc Number>

Revision: -

__________________________________________________ ___________
<Name>, Program Manager Date

__________________________________________________ ___________
<Name>, Technical Project Lead Date

__________________________________________________ ___________
<Name>, Engineer Date

__________________________________________________ ___________
<Name>, Quality Engineer Date

Notice
This document and the information contained herein are the property of <company
name>. Any reproduction, disclosure or use thereof is prohibited except as
authorized in writing by <company name>. Recipient accepts the responsibility for
maintaining the confidentiality of the contents of this document.
Plan for Software Aspects of Certification

REVISIONS
Requested/
Rev. Reason/Description Changed By Date

<Doc Number> Page 2 of 198 Rev. -

Plan for Software Aspects of Certification

Table of Contents

Section Page

1.0 INTRODUCTION ............................................................................................ 11

1.1 Purpose ...................................................................................................... 11
1.2 Scope ......................................................................................................... 11
1.3 Definitions .................................................................................................. 11
1.4 Part Number and Nomenclature ..................................................................... 12
1.5 Special Considerations Cross Reference .......................................................... 13
1.6 Team Members and Signature Authority ......................................................... 14
1.6.1 Independent Reporting Structure .............................................................. 15
1.6.1.1 Software Quality Assurance Independence ............................................ 15
1.6.1.2 Verification Independence of DO-178C Objectives .................................. 16
1.6.2 Signature Authority ................................................................................. 18
1.7 Organizational Responsibilities....................................................................... 19
1.8 Acronyms and Abbreviations ......................................................................... 21
1.9 Applicable Documents .................................................................................. 22
1.9.1 External Documents ................................................................................ 22
1.9.2 Internal Documents ................................................................................ 22

2.0 SYSTEM OVERVIEW ...................................................................................... 23

2.1 Mechanical Systems Top level Diagram........................................................... 23
2.1.1 System Functions Allocated to Mechanical Hardware ................................... 23
2.2 Electrical Systems Top Level Block Diagram .................................................... 24
2.2.1 System Functions Allocated to Electrical Hardware and Software .................. 25
2.2.1.1 Data Acquisition Printed Circuit Board #1 ............................................. 25
2.2.1.2 Input / Output Printed Circuit Board #2 ................................................ 25
2.2.1.3 Monitor Printed Circuit Board #3.......................................................... 25
2.3 System Functional Description ....................................................................... 26
2.3.1 System Failure Conditions ........................................................................ 27
2.3.2 High-Level Hardware Functions and Contribution to Potential Failures ........... 27
2.3.3 Safety and Partitioning ............................................................................ 27

3.0 SOFTWARE OVERVIEW ................................................................................. 28

3.1 Software Architectural Block Diagram ............................................................. 28
3.2 Processor #1 ............................................................................................... 28
3.2.1 States and Modes ................................................................................... 28
3.2.2 Tasks .................................................................................................... 28
3.3 Processor #2 ............................................................................................... 28
3.3.1 States and Modes ................................................................................... 28
3.3.2 Tasks .................................................................................................... 28
3.4 COTS Software Identification......................................................................... 28
3.4.1 Real Time Operating System .................................................................... 28
3.4.2 Board Support Package ........................................................................... 28
3.4.3 Compiler Provided Libraries ...................................................................... 28
3.5 Deactivated Code Partitioning........................................................................ 29
3.5.1 USB Interface Code ................................................................................. 29
3.5.2 RS-232 Interface Code ............................................................................ 29
3.5.3 Ethernet Interface Code .......................................................................... 29
3.5.4 Boot Load Code Partitioning ..................................................................... 29
3.6 Safety and Partitioning ................................................................................. 30

<Doc Number> Page 3 of 198 Rev. -

Plan for Software Aspects of Certification

3.6.1 Safety Monitoring ................................................................................... 30

3.7 Resource Sharing <Example Text> ................................................................ 30
3.8 Redundancy ................................................................................................ 30
3.9 Fault Tolerance <Example Text> ................................................................... 30
3.10 Timing and Task Scheduling .......................................................................... 30
3.10.1 Timing <Example Text> .......................................................................... 30
3.10.2 Task Scheduling <Example Text> ............................................................. 31

4.0 CERTIFICATION CONSIDERATIONS .............................................................. 32

4.1 Certification Basis and Means of Compliance ................................................... 32
4.2 Issue Papers and Certification Review Items (CRI) ........................................... 32
4.3 Software Development Assurance Levels ........................................................ 33
4.3.1 Display DAL and Worst Case Failure Condition ............................................ 33
4.3.2 Command DAL and Worst Case Failure Condition ........................................ 33
4.3.3 Monitor DAL and Worst Case Failure Condition............................................ 34
4.3.4 Video Processor DAL and Worst Case Failure Condition ................................ 34
4.4 Software Level Determination ....................................................................... 35
4.4.1 DO-178C Objectives By Design Assurance Level ......................................... 36
4.5 Compliance Matrix ....................................................................................... 37
4.5.1 Software Conformity Objectives ................................................................ 64
4.6 Certification Authority Level of Involvement .................................................... 71
4.6.1 Certification Authority Criteria for Level of Involvement ............................... 73
4.6.2 Proposed Level of Involvement ................................................................. 73

5.0 SOFTWARE LIFECYCLE .................................................................................. 74

5.1 V-Model Development Approach .................................................................... 75
5.2 Development of Multiple DAL’s Within A Single Lifecycle Process ........................ 76
5.2.1 Section 5 Applicability for Levels A, B and C CSCI(s) ................................... 76
5.2.2 Section 5 Applicability for Level D CSCI(s) ................................................. 77
5.3 Team Member Responsibility Summary .......................................................... 77
5.4 Relationship Between Processes and Activities ................................................. 81
5.5 Interaction Among Processes ........................................................................ 82
5.5.1 System Lifecycle Flow Diagram ................................................................. 82
5.5.2 Hardware and Software Lifecycle Flow Diagram .......................................... 83
5.5.3 Software Incremental Development Lifecycle Flow Diagram ......................... 84
5.6 Means of Providing Feedback......................................................................... 85
5.6.1 Feedback to the System and Safety Process ............................................... 85
5.6.2 Feedback to the Development and Integral Processes ................................. 86
5.7 Traceability of Reviews and Analysis Results ................................................... 87
5.7.1 Transition Review Planning ...................................................................... 88
5.7.2 Peer Review Planning .............................................................................. 88
5.8 Summary of Problem Reporting Methods ........................................................ 89
5.9 Software Planning Process ............................................................................ 90
5.9.1 Software Planning Process Objectives ........................................................ 90
5.9.2 Software Planning Process Inputs ............................................................. 90
5.9.3 Software Planning Process Outputs ........................................................... 91
5.9.4 Software Planning Process Activities .......................................................... 91
5.9.5 Technical Interfaces ................................................................................ 92
5.9.6 Software Planning Process Tool Usage ....................................................... 94
5.9.7 Software Planning Process Transition Criteria ............................................. 94
5.9.7.1 Transition Criteria for Entry into Planning Process .................................. 94
5.9.7.2 Transition Criteria for Exit from Planning Process ................................... 95

<Doc Number> Page 4 of 198 Rev. -

Plan for Software Aspects of Certification

5.9.8 Integral Processes .................................................................................. 96

5.9.8.1 Software Verification Process Objectives and Activities ........................... 96
5.9.8.1.1 Software Verification Plan Preparation ............................................. 96
5.9.8.1.2 Software Reviews and Analysis ....................................................... 96
5.9.8.1.2.1 Software Planning Review ....................................................... 97
5.9.8.2 Software Configuration Management Objectives and Activities ................. 98
5.9.8.2.1 Configuration Management Plan Preparation .................................... 98
5.9.8.2.2 Configuration Identification, Baselines and Traceability ...................... 98
5.9.8.2.3 Configuration Status Accounting ..................................................... 98
5.9.8.2.4 Problem Reporting, Tracking and Corrective Action ........................... 99
5.9.8.2.5 Change Control and Change Review ................................................ 99
5.9.8.3 Software Quality Assurance Objectives and Activities ........................... 100
5.9.8.3.1 Software Quality Assurance Plan Preparation .................................. 100
5.9.8.3.2 SQA Independence during the Planning Process .............................. 100
5.9.8.3.3 SQA Lifecycle Process Audits ........................................................ 100
5.9.8.3.4 SQA Conformity Review Planning .................................................. 100
5.9.8.3.5 Software Transition Criteria Satisfaction Review ............................. 101
5.9.8.3.6 SQA Reporting and Corrective / Preventive Action........................... 101
5.9.8.4 Certification Liaison Objectives and Activities ...................................... 102
5.9.8.4.1 Means of Compliance and Planning ............................................... 102
5.9.8.4.2 Compliance Substantiation ........................................................... 102
5.10 Software Requirements Process ................................................................... 103
5.10.1 Software Requirements Process Objectives .............................................. 103
5.10.2 Software Requirements Process Inputs .................................................... 103
5.10.3 Software Requirements Process Outputs .................................................. 103
5.10.4 Software Requirements Process Activities ................................................ 104
5.10.5 Technical Interfaces .............................................................................. 106
5.10.6 Software Requirements Process Tool Usage ............................................. 107
5.10.7 Software Requirements Process Transition Criteria .................................... 108
5.10.7.1 Transition Criteria for Entry into Requirements Process ......................... 108
5.10.7.2 Transition Criteria for Exit from Requirements Process .......................... 109
5.10.8 Integral Processes ................................................................................ 110
5.10.8.1 Software Verification Process Objectives and Activities ......................... 110
5.10.8.1.1 Software Reviews and Analysis ..................................................... 110
5.10.8.1.1.1 Software Requirements Review ............................................ 111
5.10.8.2 Software Configuration Management Objectives and Activities ............... 111
5.10.8.2.1 Configuration Identification, Baselines and Traceability .................... 111
5.10.8.2.2 Configuration Status Accounting ................................................... 111
5.10.8.2.3 Problem Reporting, Tracking and Corrective Action ......................... 113
5.10.8.2.4 Change Control and Change Review .............................................. 113
5.10.8.3 Software Quality Assurance Objectives and Activities ........................... 114
5.10.8.3.1 SQA Lifecycle Process Audits ........................................................ 114
5.10.8.3.2 Software Transition Criteria Satisfaction Review ............................. 114
5.10.8.3.3 SQA Reporting and Corrective / Preventive Action........................... 114
5.10.8.4 Certification Liaison Objectives and Activities ...................................... 115
5.10.8.4.1 Means of Compliance and Requirements ........................................ 115
5.10.8.4.2 Compliance Substantiation ........................................................... 115
5.11 Software Design Process ............................................................................. 116
5.11.1 Software Design Process Objectives ........................................................ 116
5.11.2 Software Design Process Inputs .............................................................. 116
5.11.3 Software Design Process Outputs............................................................ 116
5.11.4 Software Design Process Activities .......................................................... 116

<Doc Number> Page 5 of 198 Rev. -

Plan for Software Aspects of Certification

5.11.5 Technical Interfaces .............................................................................. 117

5.11.6 Software Design Process Tool Usage ....................................................... 118
5.11.7 Software Design Process Transition Criteria .............................................. 120
5.11.7.1 Transition Criteria for Entry into Design Process .................................. 120
5.11.7.2 Transition Criteria for Exit from Design Process ................................... 121
5.11.8 Integral Processes ................................................................................ 122
5.11.8.1 Software Verification Process Objectives and Activities ......................... 122
5.11.8.1.1 Software Reviews and Analysis ..................................................... 122
5.11.8.1.1.1 Software Preliminary Design Review ..................................... 123
5.11.8.1.1.2 Software Critical Design Review ........................................... 124
5.11.8.2 Software Configuration Management Objectives and Activities ............... 125
5.11.8.2.1 Configuration Identification, Baselines and Traceability .................... 125
5.11.8.2.2 Configuration Status Accounting ................................................... 125
5.11.8.2.3 Problem Reporting, Tracking and Corrective Action ......................... 126
5.11.8.2.4 Change Control and Change Review .............................................. 126
5.11.8.3 Software Quality Assurance Objectives and Activities ........................... 127
5.11.8.3.1 SQA Lifecycle Process Audits ........................................................ 127
5.11.8.3.2 Software Transition Criteria Satisfaction Review ............................. 127
5.11.8.3.3 SQA Reporting and Corrective / Preventive Action ........................... 127
5.11.8.4 Certification Liaison Objectives and Activities ...................................... 128
5.11.8.4.1 Means of Compliance and Requirements ........................................ 128
5.11.8.4.2 Compliance Substantiation ........................................................... 128
5.12 Software Coding Process ............................................................................ 129
5.12.1 Software Coding Process Objectives ........................................................ 129
5.12.2 Software Coding Process Inputs.............................................................. 129
5.12.3 Software Coding Process Outputs ........................................................... 129
5.12.4 Software Coding Process Activities .......................................................... 130
5.12.5 Technical Interfaces .............................................................................. 130
5.12.6 Software Coding Process Tool Usage ....................................................... 131
5.12.7 Software Coding Process Transition Criteria ............................................. 132
5.12.7.1 Transition Criteria for Entry into Code Process ..................................... 132
5.12.7.2 Transition Criteria for Exit from Code Process ...................................... 133
5.12.8 Integral Processes ................................................................................ 134
5.12.8.1 Software Verification Process Objectives and Activities ......................... 134
5.12.8.1.1 Software Reviews and Analysis ..................................................... 134
5.12.8.1.1.1 Software Code Review ........................................................ 134
5.12.8.2 Software Configuration Management Objectives and Activities ............... 135
5.12.8.2.1 Configuration Identification, Baselines and Traceability .................... 135
5.12.8.2.2 Configuration Status Accounting ................................................... 135
5.12.8.2.3 Problem Reporting, Tracking and Corrective Action ......................... 136
5.12.8.2.4 Change Control and Change Review .............................................. 136
5.12.8.3 Software Quality Assurance Objectives and Activities ........................... 137
5.12.8.3.1 SQA Lifecycle Process Audits ........................................................ 137
5.12.8.3.2 Software Transition Criteria Satisfaction Review ............................. 137
5.12.8.3.3 SQA Reporting and Corrective / Preventive Action........................... 137
5.12.8.4 Certification Liaison Objectives and Activities ...................................... 138
5.12.8.4.1 Means of Compliance and Requirements ........................................ 138
5.12.8.4.2 Compliance Substantiation ........................................................... 138
5.13 Integration Process .................................................................................... 139
5.13.1 Integration Process Objectives ............................................................... 139
5.13.2 Integration Process Inputs ..................................................................... 139

<Doc Number> Page 6 of 198 Rev. -

Plan for Software Aspects of Certification

5.13.3 Integration Process Outputs ................................................................... 139

5.13.4 Integration Process Activities ................................................................. 139
5.13.5 Technical Interfaces .............................................................................. 140
5.13.6 Software Integration Process Tool Usage ................................................. 142
5.13.7 Integration Process Transition Criteria ..................................................... 142
5.13.7.1 Transition Criteria for Entry into Integration Process ............................ 142
5.13.7.2 Transition Criteria for Exit from Integration Process ............................. 143
5.13.8 Integral Processes ................................................................................ 144
5.13.8.1 Software Verification Process Objectives and Activities ......................... 144
5.13.8.1.1 Software Reviews and Analysis ..................................................... 144
5.13.8.1.1.1 System Integration Review .................................................. 144
5.13.8.2 Software Configuration Management Objectives and Activities............... 145
5.13.8.2.1 Configuration Identification, Baselines and Traceability .................... 145
5.13.8.2.2 Configuration Status Accounting ................................................... 145
5.13.8.2.3 Problem Reporting, Tracking and Corrective Action ......................... 146
5.13.8.2.4 Change Control and Change Review .............................................. 146
5.13.8.3 Software Quality Assurance Objectives and Activities ........................... 147
5.13.8.3.1 SQA Lifecycle Process Audits ........................................................ 147
5.13.8.3.2 Software Transition Criteria Satisfaction Review ............................. 147
5.13.8.3.3 SQA Reporting and Corrective / Preventive Action ........................... 147
5.13.8.4 Certification Liaison Objectives and Activities ...................................... 148
5.13.8.4.1 Means of Compliance and Requirements ........................................ 148
5.13.8.4.2 Compliance Substantiation ........................................................... 148
5.14 Software Testing Process ............................................................................ 149
5.14.1 Software Testing Process Objectives ....................................................... 149
5.14.1.1 Integration Test Objectives ............................................................... 149
5.14.1.2 Verification Test Objectives ............................................................... 150
5.14.2 Software Testing Process Inputs ............................................................. 150
5.14.3 Software Testing Process Outputs ........................................................... 150
5.14.4 Software Testing Process Activities ......................................................... 151
5.14.4.1 Test Case and Test Procedure Development ........................................ 151
5.14.4.2 Test Execution and Test Results Compilation ....................................... 151
5.14.5 Technical Interfaces .............................................................................. 152
5.14.6 Software Testing Process Tool Usage....................................................... 154
5.14.7 Software Testing Process Transition Criteria ............................................. 154
5.14.7.1 Transition Criteria for Entry into Software Testing Process .................... 154
5.14.7.2 Transition Criteria for Exit from Software Testing Process ..................... 155
5.14.8 Integral Processes ................................................................................ 156
5.14.8.1 Software Verification Process Objectives and Activities ......................... 156
5.14.8.1.1 Software Reviews and Analysis ..................................................... 156
5.14.8.1.1.1 Test Case and Test Procedure Reviews and Analysis ............... 156
5.14.8.1.1.2 Requirements-Based Test Coverage Analysis ......................... 156
5.14.8.1.1.3 Data Coupling and Control Coupling Analysis ......................... 156
5.14.8.1.1.4 Structural Coverage Analysis ............................................... 157
5.14.8.1.1.5 Source Code To Object Code Traceability Analysis .................. 158
5.14.8.1.1.6 System Verification Review .................................................. 158
5.14.8.2 Software Configuration Management Objectives and Activities ............... 158
5.14.8.2.1 Configuration Identification, Baselines and Traceability .................... 158
5.14.8.2.2 Configuration Status Accounting ................................................... 160
5.14.8.2.3 Problem Reporting, Tracking and Corrective Action ......................... 160
5.14.8.2.4 Change Control and Change Review .............................................. 161

<Doc Number> Page 7 of 198 Rev. -

Plan for Software Aspects of Certification

5.14.8.3 Software Quality Assurance Objectives and Activities ........................... 161

5.14.8.3.1 SQA Lifecycle Process Audits ........................................................ 161
5.14.8.3.2 Software Test Transition Criteria Satisfaction Review....................... 161
5.14.8.3.3 SQA Reporting and Corrective / Preventive Action ........................... 162
5.14.8.4 Certification Liaison Objectives and Activities ...................................... 162
5.14.8.4.1 Means of Compliance and Requirements ........................................ 162
5.14.8.4.2 Compliance Substantiation ........................................................... 162

6.0 SOFTWARE LIFECYCLE DATA ...................................................................... 163

6.1 Overview .................................................................................................. 163
6.2 Relationship of Lifecycle Data to Other Data Defining the System .................... 164
6.3 Trace Data ................................................................................................ 165
6.3.1 Trace Data Objective Evidence of Compliance ........................................... 165
6.4 Software Lifecycle Data to Be Produced and Controlled ................................... 166
6.5 Relationship of Lifecycle Data to Other Data Defining the System .................... 168
6.6 Software Lifecycle Data to be Submitted to Certification Authority ................... 169
6.7 Software Control Categories ........................................................................ 170
6.8 Software Lifecycle Data DER Delegation Plan ................................................. 171

7.0 SCHEDULE................................................................................................... 172

7.1 Master Project Schedule ............................................................................. 172
7.2 Stages of Involvement Audit Schedule.......................................................... 173
7.3 Certification Authority Web Interface ............................................................ 174
7.3.1 Qualtech Compliance Management System .............................................. 175
7.3.1.1 SecureWeb Security Management System .......................................... 176
7.3.1.2 Problem Reporting Management System ............................................. 177
7.3.1.3 Change Impact Analysis Management System ..................................... 178
7.3.1.4 Document Review Management System ............................................. 179
7.3.1.5 Reviews and Analysis Management System ......................................... 180
7.3.1.6 Requirements Traceability Management System .................................. 181
7.3.1.7 Coverage Analysis Management System ............................................. 182

8.0 ADDITIONAL CONSIDERATIONS ................................................................. 183

8.1 Use of Previously Developed Software .......................................................... 183
8.2 Tool Qualification ....................................................................................... 186
8.2.1 Criteria 1 Tools ..................................................................................... 186
8.2.1.1 Qualification of Criteria 1 Tools .......................................................... 186
8.2.2 Criteria 2 Tools ..................................................................................... 186
8.2.3 Criteria 3 Tools ..................................................................................... 187
8.2.3.1 Qualification of Criteria 3 Tools .......................................................... 187
8.3 Alternative Methods ................................................................................... 187
8.3.1 Product Service History ......................................................................... 188
8.4 Field Loadable Software .............................................................................. 189
8.5 Option Selectable Software ......................................................................... 190
8.6 User Modifiable Software ............................................................................ 190
8.7 Multiple-Version Dissimilar Software ............................................................ 190
8.8 COTS Software .......................................................................................... 190
8.9 Use of Suppliers, Sub-Tier Suppliers and Off-Shore Facilities ........................... 191
8.9.1 Supplier Identification and Roles ............................................................. 192
8.9.1.1 Acme Consultants, Inc...................................................................... 192
8.9.1.2 Supplier Competence Questionnaire Example ...................................... 194
8.9.1.3 Supplier Management Plan ................................................................ 196

<Doc Number> Page 8 of 198 Rev. -

Plan for Software Aspects of Certification

8.10 Deviations and Modifications to Plans ........................................................... 198

<Doc Number> Page 9 of 198 Rev. -

Plan for Software Aspects of Certification

List of Figures

Figure 1-1 Organization Chart .................................................................................... 15

Figure 2-1 System Level Block Diagram ...................................................................... 24
Figure 2-2 System Functional Diagram........................................................................ 26
Figure 5-1 Relationship Between Processes and Activities .............................................. 81
Figure 5-2 System Lifecycle Flow Diagram ................................................................... 82
Figure 5-3 Hardware and Software Lifecycle Diagram ................................................... 83
Figure 5-4 Software Incremental Development Lifecycle Flow ........................................ 84
Figure 5-5 System and Safety Process Feedback Flow Diagram ...................................... 85
Figure 5-6 Lifecycle Process Feedback Flow Diagram .................................................... 86
Figure 7-1 Certification Master Schedule ................................................................... 172
Figure 7-2 Certification Authority Web Intereface ....................................................... 174
Figure 7-3 Qualtech Compliance Management System ................................................ 175
Figure 7-4 SecureWeb Login Screen ......................................................................... 176
Figure 7-5 Problem Reporting Management System .................................................... 177
Figure 7-6 Change Impact Analysis Management System ............................................ 178
Figure 7-7 Document Review Management System..................................................... 179
Figure 7-8 Reviews and Analysis Management System ................................................ 180
Figure 7-9 Requirements Traceability Management System ......................................... 181
Figure 7-10 Coverage Analysis Management System .................................................. 182

List of Tables

Table 1-1 Definitions ................................................................................................ 12

Table 1-2 Part Number and Nomenclature ................................................................... 12
Table 1-3 Team Members and Signature Authority ....................................................... 14
Table 2-1 System Failure Conditions ........................................................................... 27
Table 4-1 List of Compliance Documents ..................................................................... 32
Table 4-2 List of Issue Papers and CRI’s ...................................................................... 32
Table 4-3 Design Assurance Levels ............................................................................. 36
Table 4-14 Compliance Matrix - Software Conformity Process ........................................ 70
Table 4-15 Certification Authority Involvement Based on DAL ........................................ 71
Table 4-16 Software Certification Experience ............................................................... 71
Table 4-17 Software Development Capability ............................................................... 71
Table 4-18 Software Service History ........................................................................... 72
Table 4-19 System and Software Application Complexity ............................................... 72
Table 4-20 FAA DER Capabilities – Todd R. White ......................................................... 72
Table 4-21 Level of Involvement Criteria Scoring ......................................................... 73
Table 5-1 V-Model Relationship Table ......................................................................... 75
Table 1-4 Summary of Problem Reporting Methods ...................................................... 89
Table 6-1 Lifecycle Data To be Produced ................................................................... 166
Table 6-2 Lifecycle Data To Certification Authority ...................................................... 169
Table 6-3 Software Control Categories ...................................................................... 170
Table 6-4 Software DER Delegation Plan ................................................................... 171
Table 8-1 Software Development Tools ..................................................................... 186
Table 8-2 Software Verification Tools ........................................................................ 187

<Doc Number> Page 10 of 198 Rev. -

Plan for Software Aspects of Certification

1.0 INTRODUCTION

1.1 Purpose

This Plan for Software Aspects of Certification (PSAC) defines the processes, procedures,
methods and standards to be used and the lifecycle data to be produced in order to satisfy
the objectives of DO-178C and any additional objectives required to satisfy the certification
basis of the aircraft. Once approved, this PSAC represents an agreement between the
applicant and the customer and/or certification authority.

1.2 Scope

This plan will be used by the customer and/or certification authority to determine if the
Software Lifecycle Process is commensurate with the rigor required for the level of software
being developed. Once approved, it is implemented during the software lifecycle
development. This Plan for Software Aspects of Certification complies with the
documentation requirements of RTCA/DO-178C, Section 11.1.

1.3 Definitions

Definition Meaning

COTS IC Any COTS digital or hybrid electronic device which does not
execute software in a specific core. COTS ICs may be bus
controllers, flip-flop, multiplexers, converters, memories… The
hardware functions implemented within these components
may be simple or complex. (See also definition of SEH below).
COTS Graphical Processor Any COTS microcontroller specifically designed for graphical
applications. COTS graphical processors for airborne systems
are required to have built in mitigation against Hazardous and
Misleading information(HMI).
COTS Microcontroller Any IC which executes software in a specific core area (Central
Processing Unit) and implements peripheral hardware
elements such as, for example, input/output (I/O), bus
controllers… Such a peripheral element may be considered
simple (e.g. a UART, A/D, D/A) or complex (e.g. a bus
controller). (See also definition of SEH below).
Highly complex COTS Any microcontroller where at least one of the statements
microcontroller below is true:
- more than one Central Processing Unit (CPU) is embedded
and they use the same bus (which is not strictly separated or
which uses the same single port memory)
- several complex interfaces are dependent on each other and
exchange data
- several internal busses are integrated and are used in a
dynamic way (for example, a dynamic bus switch matrix)

<Doc Number> Page 11 of 198 Rev. -

Plan for Software Aspects of Certification

Definition Meaning

Integrated Circuit A circuit (also IC, microcircuit, microchip, silicon chip, or chip)
consisting of elements inseparably associated and formed in-
situ on or within a single substrate to perform an electronic
circuit function. Among the most advanced integrated circuits
are the microprocessors or "cores", digital memory chips,
ASICS and bus controllers. Integrated circuits can be classified
into analog, digital and hybrid signal:
- Digital integrated circuits are typically microprocessors,
DSPs, an micro controllers and work using binary mathematics
to process "one" and "zero" signals.
- Analog ICs, such as sensors, power management circuits,
and operational amplifiers, work by processing continuous
signals. They perform functions like amplification, active
filtering, demodulation, mixing, etc.
- Hybrid ICs can combine analog and digital circuits on a single
chip to create functions such as A/D converters and D/A
converters.
Digital and Hybrids ICs include ASIC, COTS ICs, highly
complex, COTS Microcontroller, Microprocessor, COTS
Microcontroller, COTS Graphical Processor, PLD, CEH, SEH.
Microprocessor A single Central Processing Unit which executes software and
does not contain any additional integrated peripheral hardware
element such as a UART, A/D, D/A, bus controller, Time
Processing Unit, Memory Management Unit, watchdog, etc.
Table 1-1 Definitions

1.4 Part Number and Nomenclature

Part Number Nomenclature

Table 1-2 Part Number and Nomenclature

<Doc Number> Page 12 of 198 Rev. -

Plan for Software Aspects of Certification

1.5 Special Considerations Cross Reference

Software Consideration Applicable Addressed In Doc / Section

General Processor, DSP, etc. Y/N

COTS Graphical Processor (CGP) Y/N
Product Service History Y/N
Legacy System Software Y/N
Previously Developed Software Y/N
Field Loadable Software Y/N
Option-Selectable Software Y/N
User-Modifiable Software Y/N
Safety Monitoring Software Y/N
COTS Software Y/N
Public Domain Software Y/N
Parameter Data / Databases Y/N
Operating System Y/N
Compiler Provided Libraries Y/N
Board Support Package Y/N
Dead, Unreachable or Deactivated Code Y/N
DAL Justification Y/N
Derived / Safety Requirements Y/N
Robustness Requirements / Testing Y/N
Structural Coverage Analysis Y/N
Data and Control Coupling Analysis Y/N
Partitioning (Multi-DAL) Y/N
Exhaustive Input Testing Y/N
Development Tool Qualification Y/N
Verification Tool Qualification Y/N
Single Event Upset (SRAM) Y/N
Formal Methods Y/N
Model Based Development Y/N
Object Oriented Technology Y/N
Domestic / Off-Shore Supplier Y/N
International Cert (EASA, TCCA, etc.) Y/N
Open Problem Report Management Y/N
Issue Papers / Certification Review Items Y/N

<Doc Number> Page 13 of 198 Rev. -

Plan for Software Aspects of Certification

1.6 Team Members and Signature Authority

Name Title

Signature Authority / PRB & CCB Members:

John Smith Systems Engineer
John Smith Software Lead
John Smith Independent Verification Engineer
John Smith Software Quality Engineer
John Smith Certification Liaison DER (PRB & CCB Only)

Team Members:
John Smith Systems Engineer
John Smith Safety Engineer
John Smith Software Design Engineer
John Smith Configuration Management Specialist
John Smith FAA Software Designated Engineering Representative

Peer Review Members:

John Smith Systems Engineer
John Smith Software Engineer
John Smith Safety Engineer (mandatory when derived requirements reviewed)

Transition Review Team:

John Smith Project Engineer
John Smith Certification Manager
John Smith Software Quality Engineer (SQA Records)
John Smith Systems Engineer
John Smith Safety Engineer
John Smith Independent Verification Engineer (V&V Records)
John Smith Configuration Management Specialist (CM Records)

Table 1-3 Team Members and Signature Authority

<Doc Number> Page 14 of 198 Rev. -

Plan for Software Aspects of Certification

1.6.1 Independent Reporting Structure

The following chart shows that the Quality Assurance Organization is independent from
Engineering. It also demonstrates that the verification and test activities are performed
independently by someone other than the development engineer.

John A. Smith
CEO

John B. Smith John E. Smith

Vice President Vice President
Engineering Quality

John C. Smith John D. Smith John F. Smith John G. Smith

Senior Director Senior Director SQA Engineer SCM Engineer
Development Verification & Test Quality Quality

Figure 1-1 Organization Chart

1.6.1.1 Software Quality Assurance Independence

SQA assesses the software life cycle processes and their outputs to obtain assurance that
objectives are satisfied, deficiencies are detected, evaluated, tracked, and resolved, and
software product and software life cycle data conform to certification requirements. The
SQA role is an oversight role for the entire project. As such, SQA does not perform any of
the development or verification activities. In addition, the SQA reporting structure is
independent of Engineering, Test, Manufacturing, and Project Management.

<Doc Number> Page 15 of 198 Rev. -

Plan for Software Aspects of Certification

1.6.1.2 Verification Independence of DO-178C Objectives

The following matrix shows the DO-178C objectives that will be satisfied with independence.
In addition, the item being verified and the role of the individual performing the verification
is also shown.

Table Objective Verification Item Being Interpretation

Activity Verified
A-3(1) Software high- Reviews and High-level The reviews and
level Analyses of requirements analyses of the high-
requirements the High- level requirements will
comply with Level be performed by a
system Requirements person(s) other than
requirements. the developer of the
A-3(2) High-level high-level requirements.
requirements
are accurate
and
consistent.
A-3(7) Algorithms are
accurate.
A-4(1) Low-level Reviews and Low-level The reviews and
requirements Analyses of requirements analyses of the low-
comply with the Low- level requirements will
high-level Level be performed by a
requirements. Requirements person(s) other than
A-4(2) Low-level the developer of the
requirements low-level requirements.
are accurate
and
consistent.
A-4(7) Algorithms are
accurate.
A-4(8) Software Reviews and Software The reviews and
architecture is Analyses of architecture analyses of the software
compatible the Software architecture will be
with high-level Architecture performed by a
requirements. person(s) other than
A-4(9) Software the developer of the
architecture is software architecture.
consistent.
A-4(13) Software
partitioning
integrity is
confirmed.
A-5(1) Source Code Reviews and Source Code The reviews and
complies with Analyses of analyses of the Source
low-level the Source Code will be performed
requirements. Code by a person(s) other
than the developer of
the Source Code.

<Doc Number> Page 16 of 198 Rev. -

Plan for Software Aspects of Certification

Table Objective Verification Item Being Interpretation

Activity Verified
A-5(2) Source Code
complies with
software
architecture.
A-5(6) Source Code
is accurate
and
consistent.
A-6(3) Executable Requirements Executable The person(s) who
Object Code -Based Object Code created a set of low-
complies with Testing level requirements-
low-level based test cases should
requirements. not be the same
A-6(4) Executable person(s) who
Object Code is developed the
robust with associated Source Code
low-level from those low-level
requirements. requirements. It follows
that:

1. The same person(s)

could develop the low-
level requirements and
the Source Code,
provided another
person(s) develops the
test cases from those
low-level requirements,
or

2. The same person(s)

could develop the low-
level requirements and
their associated test
cases, provided another
person(s) develops the
Source Code.
A-7(1) Test Reviews and Test The reviews and
procedures Analyses of procedures analyses of the test
and expected the Test procedures will be
results are Procedures performed by a
correct. person(s) other than
the developer of the
test procedures.

<Doc Number> Page 17 of 198 Rev. -

Plan for Software Aspects of Certification

Table Objective Verification Item Being Interpretation

Activity Verified
A-7(2) Test results Reviews and Test results The reviews and
are correct Analyses of analyses of the test
and the Test results will be
discrepancies Results performed by a
explained. person(s) other than
the person(s) who
performed the tests.
A-7(3) Test coverage Requirements Test cases The requirements-based
of high-level -Based Test test coverage analysis
requirements Coverage will be performed by a
is achieved. Analysis person(s) other than
A-7(4) Test coverage the developer of the
of low-level test cases.
requirements
is achieved.
A-7(5) Test coverage Structural Test cases, test The exact independence
of software Coverage procedures, required depends on
structure Analysis and/or test how the structural
(modified results coverage analysis is
condition/deci carried out. For
sion) is example, if the
achieved. structural coverage
A-7(6) Test coverage analysis is performed on
of software the test cases, then the
structure structural coverage
(decision analysis will be
coverage) is performed by a
achieved. person(s) other than
A-7(7) Test coverage the developer of the
of software test cases. Similarly, if
structure the structural coverage
(statement analysis is performed on
coverage) is the test procedures and
achieved. test results, then the
A-7(8) Test coverage structural coverage
of software analysis will be
structure performed by a
(data coupling person(s) other than
and control the developer of the
coupling) is test procedures and test
achieved. results.

1.6.2 Signature Authority

“Signature Authority”, as used herein, is a project-level approval authority that is composed

of the following members at minimum:
 Project Manager

<Doc Number> Page 18 of 198 Rev. -

Plan for Software Aspects of Certification

 Software Lead
 Independent Verification Engineer
 Software Quality Engineer
Other team members may be required to sign specific documents in addition to this core
group, depending on the content of the document. For example, a Configuration
Management Specialist is required to sign the Software Configuration Management Plan to
acknowledge acceptance of the CM processes defined therein.

1.7 Organizational Responsibilities

Project Role Department Responsibility

Project Engineer Program Management Manage all project activities, including

planning, coordination of system life cycle
processes, and scheduling of major
milestones. Provides liaison with
company management.
Software Lead Software Engineering Manage all aspects of software
development including planning, technical
direction, collection and analysis life cycle
data, coordination of life cycle processes
and scheduling of major milestones.
Participate in the software release,
change, and baseline process as a
required member of the SCCB.
Systems Engineer Systems Engineering Develop high level requirements and the
high level architecture in accordance with
the DO-178B guidelines and engineering
procedures.
Safety Engineer Systems Engineering Performs the System Safety Assessment
(SSA) which determines and categorizes
the failure conditions of the system and
from that defines safety related
requirements. Reviews all requirements
changes. Approves derived requirements.
Software Engineer(s) Software Engineering Develop software standards, architecture,
requirements, design, source code and
executable code in accordance with
software procedures and DO-178B
guidelines. Conduct reviews and analysis
of life cycle data. Implement changes
during verification testing as required.

<Doc Number> Page 19 of 198 Rev. -

Plan for Software Aspects of Certification

Project Role Department Responsibility

Independent System/Software/Test Conduct independent verification

Verification Engineering including test development, reviews,
Engineer(s) analysis, and performing tests in
accordance with the Software Verification
Plan (SVP).
Software Quality Software Quality Assure that the software life cycle
Engineer Assurance processes produce software that conforms
to its requirements by ensuring that
project activities are performed in
compliance with the SQAP. Conduct
Product Reviews, Process Reviews, and
Audits throughout the software
development life cycle in accordance with
checklists provided in Appendix A of the
SQAP.
Configuration Configuration Provide configuration management of all
Management Specialist Management project life cycle data in accordance to the
Software Configuration Management Plan.
Assure that changes in hardware,
software, documentation, and delivered
products conform to the Configuration
Item (CI) baseline(s). Ensures the
integrity of configuration identification of
released products. The CM manager or
designee is the chair for the SCCB.
Certification Manager Program Ensure that the software development
Management/ Project and life cycle data meet customer
Technical Lead requirements and DO-178B and
guidelines

<Doc Number> Page 20 of 198 Rev. -

Plan for Software Aspects of Certification

1.8 Acronyms and Abbreviations

RAMS Reviews and Analysis Management System

CAMS Coverage Analysis Management System
CC1 DO-178C Control Category 1
CC2 DO-178C Control Category 2
CI Configuration Item
CM Configuration Management
COTS Commercial off the Shelf
CPU Central Processing Unit
CSC Computer Software Component
CSCI Computer Software Configuration Item
CSU Computer Software Unit
DER Designated Engineering Representative
DRMS Document Review Management System
FAA Federal Aviation Administration
FHA Functional Hazard Assessment
IVT Independent Verification Testing
MC/DC Modified Condition/Decision Coverage
MISRA Motor Industries Software Reliability Association
MLCP Master Load Control Procedure
PEMS Project Event Management System
PRMS Problem Reporting Management System
PSAC Plan for Software Aspects of Certification
PSSA Preliminary System Safety Assessment
PVCS Serena PVCS Version Control Software
QA Quality Assurance
RTCA Radio Technical Commission for Aeronautics
RTMS Requirements Traceability Management System
SAS Status Accounting System
SCI Software Configuration Index
SCM Software Configuration Management
SCMP Software Configuration Management Plan
SCS Software Coding Standard
SDD Software Design Description
SDS Software Design Standard
SDP Software Development Plan
SECI Software Environment Configuration Index
SQA Software Quality Assurance
SQAP Software Quality Assurance Plan
SQE Software Quality Engineer
SRS Software Requirements Standard
SSA System Safety Assessment
SVC&P Software Verification Cases and Procedures
SVCP Software Verification Cases and Procedures
SVP Software Verification Plan
SWRD Software Requirements Document
VR Verification Results
VSS Visual Source Safe

<Doc Number> Page 21 of 198 Rev. -

Plan for Software Aspects of Certification

1.9 Applicable Documents

The following documents are listed for reference only. Each document is applicable to this
plan only to the extent specified herein.

1.9.1 External Documents

RTCA/DO-178C Software Considerations in Airborne Systems and Equipment
Certification
FAA Order 8110.4C Type Certification
FAA Order 8110.49 FAA, Software Approval Guidelines
AC 20-115C Advisory Circular, RTCA Inc., Document DO-178C, Software
Considerations in Airborne Systems and Equipment Certification

1.9.2 Internal Documents

<Ref Doc> Plan for Software Aspects of Certification (Ref. DO-178C, 11.1)
<Ref Doc> Software Development Plan (Ref. DO-178C, 11.2)
<Ref Doc> Software Verification Plan (Ref. DO-178C, 11.3)
<Ref Doc> Software Configuration Management Plan (Ref. DO-178C, 11.4)
<Ref Doc> Software Quality Assurance Plan (Ref. DO-178C, 11.5)
<Ref Doc> Software Requirements Standards (Ref. DO-178C, 11.6)
<Ref Doc> Software Design Standards (Ref. DO-178C, 11.7)
<Ref Doc> Software Code Standards (Ref. DO-178C, 11.8)
<Ref Doc> Software Requirements Document (Ref. DO-178C, 11.9)
<Ref Doc> Software Design Description (Ref. DO-178C, 11.10)
<Ref Doc> Build Procedure for Source Code (Ref. DO-178C, 11.11)
<Ref Doc> Load Control for Executable Object Code (Ref. DO-178C, 11.12)
<Ref Doc> Software Verification Cases and Procedures (Ref. DO-178C, 11.13)
<Ref Doc> Software Verification Results (Ref. DO-178C, 11.14)
<Ref Doc> Software Environment Configuration Index (Ref. DO-178C, 11.15)
<Ref Doc> Software Configuration Index (Ref. DO-178C, 11.16)
<Ref Doc> Software Accomplishment Summary (Ref. DO-178C, 11.20)

<Doc Number> Page 22 of 198 Rev. -

Plan for Software Aspects of Certification

2.0 SYSTEM OVERVIEW

This section provides an overview of the system, including a description of the mechanical
enclosure and interfaces, electrical functions and their allocation to hardware and software,
the architecture, processor(s) used hardware / software interfaces and safety features.

<Example Text>
The Avionics Passenger Counter is a module that will keep track of how many passengers
are currently in the aircraft/cabin. The current number of passengers in the cabin will be
displayed on a display panel in real-time. The system will have a keypad entry so that the
flight attendant can enter a passenger headcount correction/adjustment. The passenger
headcount and any fault status information collected will be transmitted via ARINC 429 via
the PIC processor and ARINC 429 I/O FPGA.

2.1 Mechanical Systems Top level Diagram

2.1.1 System Functions Allocated to Mechanical Hardware

<Doc Number> Page 23 of 198 Rev. -

Plan for Software Aspects of Certification

2.2 Electrical Systems Top Level Block Diagram

<This is a diagram of equipment showing a high-level interconnect of black boxes with

emphasis on identifying the Printed Circuit Boards (PCB) at the LRU Level.>

Figure 2-1 System Level Block Diagram

<Doc Number> Page 24 of 198 Rev. -

Plan for Software Aspects of Certification

2.2.1 System Functions Allocated to Electrical Hardware and Software

2.2.1.1 Data Acquisition Printed Circuit Board #1

The Data Acquisition PCB has four primary functions. They include…

Device Primary Functions COTS

FPGA #2 <Primary function implemented in this device> N
FPGA #2 <Primary function implemented in this device> N
DSP #1 <Primary function implemented in this device> N
XYZ #1 <Primary function implemented in this device> Y

2.2.1.2 Input / Output Printed Circuit Board #2

The Input / Output PCB have five primary functions. They include…

Device Primary Functions COTS

CPLD #1 <Primary function implemented in this device> N
FPGA #1 <Primary function implemented in this device> N
XYZ #1 <Primary function implemented in this device> Y
XYZ #2 <Primary function implemented in this device> Y
XYZ #3 <Primary function implemented in this device> Y

2.2.1.3 Monitor Printed Circuit Board #3

The Monitor PCB has four primary functions. They include…

Device Primary Functions COTS

DSP #1 <Primary function implemented in this device> N
DSP #2 <Primary function implemented in this device> N
XYZ #1 <Primary function implemented in this device> Y
XYZ #2 <Primary function implemented in this device> Y

<Doc Number> Page 25 of 198 Rev. -

Plan for Software Aspects of Certification

2.3 System Functional Description

<Example Text>
The passenger headcount function is performed by counting the number of entries and
exits. The module uses an Entry/Exit-Sensor to detect passengers’ movements in and out of
the cabin. The number of passengers in the cabin is tracked by an up/down counter in an
FPGA. The passenger load is displayed in real-time on the display panel. The keypad entry
can asynchronously load the counter thereby adjusting/correcting the passenger load on the
display/system.

Entry/Exit
Sensor

DISPLAY
F0 F1
Complex
IC - Reset
FPGA
Controller

F2
Keypad
7 8 9
4 5 6
1 2 3
0 RTN

F5
F3 F4

Power supply

F0
Hardware Faults

F1 Transmitter
Line Driver
ARINC 429

F2
PIC ARINC 429
Microcontroller FPGA
F3

F4

F5

Figure 2-2 System Functional Diagram

<Doc Number> Page 26 of 198 Rev. -

Plan for Software Aspects of Certification

2.3.1 System Failure Conditions

2.3.2 High-Level Hardware Functions and Contribution to Potential Failures

No Function Example of Potential Failure DAL

01 Provision of secure and timely data Transmission of deploy command to A

flow to and from applications and landing gear in flight
Input / output devices, e.g.
sensors and actuators

02 Controlled access to processing Omission in schedule of fuel system B

facilities pumping control partition

03 Provision of secure data storage Corruption of fuel system execution B

and memory management code by lower integrity partition

04 Provision of consistent execution Incorrect or inconsistent flight data is B

state loaded into system

05 Provision of health monitoring and Fuel system partition shut down A

failure management when no error has occurred

06 General provision of computing Total loss of IMA platform A

capability

Table 2-1 System Failure Conditions

2.3.3 Safety and Partitioning

The system is composed of diagnostics and other fail-safe mechanisms used to ensure that
failures of the system are detected and that the system goes to a safe state if it's unable to
perform a safety function.

<Doc Number> Page 27 of 198 Rev. -

Plan for Software Aspects of Certification

3.0 SOFTWARE OVERVIEW

This section describes the software functions with emphasis on the proposed safety and
partitioning concepts.

3.1 Software Architectural Block Diagram

<Identifies each processor and the tasks to be performed within each>

3.2 Processor #1

3.2.1 States and Modes

3.2.2 Tasks

3.3 Processor #2

3.3.1 States and Modes

3.3.2 Tasks

3.4 COTS Software Identification

3.4.1 Real Time Operating System

<Describe the use of an RTOS, including qualification information>

3.4.2 Board Support Package

<Describe the use of a BSP, including qualification information>

3.4.3 Compiler Provided Libraries

<Describe the use of Libraries, including qualification information>

<Doc Number> Page 28 of 198 Rev. -

Plan for Software Aspects of Certification

3.5 Deactivated Code Partitioning

How is the operational software protected from the activation of this code?

3.5.1 USB Interface Code

3.5.2 RS-232 Interface Code

3.5.3 Ethernet Interface Code

3.5.4 Boot Load Code Partitioning

The Boot Load Code is partitioned from the operational software and, if activated during
flight, the crew will see a fault indication. Anomalous behavior of the Boot Load software,
as shown by the system safety assessment, would cause or contribute to a failure of system
function with no effect on aircraft operational capability or pilot workload. Software whose
anomalous behavior would cause or contribute to a failure of the system function with no
effect on aircraft operational capability or pilot workload is identified as Level E.

<Doc Number> Page 29 of 198 Rev. -

Plan for Software Aspects of Certification

3.6 Safety and Partitioning

The system is composed of diagnostics and other fail-safe mechanisms used to ensure that
failures of the system are detected and that the system goes to a safe state if it's unable to
perform a safety function.

3.6.1 Safety Monitoring

The following safety monitoring rules and techniques will be used:

 Safety monitoring software will be assigned the software level associated with the most
severe failure condition category for the monitored function.

 Assessment of the system fault coverage of a monitor will be used to ensure that the
monitor's design and implementation are such that the faults which it is intended to
detect will be detected under all necessary conditions.

 The monitor and protective mechanism will not be rendered inoperative by the same
failure that causes the failure condition.

3.7 Resource Sharing <Example Text>

The system is based on Superloop architecture. As such, resource sharing is managed to

prevent deadlocks. For example, if the analog board suffers a critical failure with the Dual-
Port RAM and locked, in this event, the board would automatically be shipped. This results
in no data from the analog board; however, the balance of the system is fully operational.

3.8 Redundancy
<Information Here If Applicable>

3.9 Fault Tolerance <Example Text>

The software will be designed so that it will continue to operate, possibly at a reduced level,
rather than failing completely, when some part of the system fails. During this condition, a
visible fault indication will be present.

3.10 Timing and Task Scheduling

3.10.1 Timing <Example Text>

The development team understands that numerous types of problems can arise when the
software misses its timing constraints. Two types of constraints are recognized: hard timing
requirements and soft timing requirements. A hard timing requirement denotes that if a
constraint is missed, the program is in error; a late result is just as bad as a wrong result. A
soft timing requirement indicates a constraint that the program should obtain on average,
or one in which the value of the result degrades with time; occasionally missing a deadline
is not considered an error.
The following timing-related problems that will be addressed in the system architecture:
 Priority inversion

<Doc Number> Page 30 of 198 Rev. -

Plan for Software Aspects of Certification

 Schedulability and processor utilization

 Interrupt and event response times

It is recognized that such problems may go undetected by verification testing alone, since
they only occur under specific timing conditions. As such, code review analysis is combined
with testing to aid in uncovering these problems.

3.10.2 Task Scheduling <Example Text>

Scheduling is handled as a function of the Superloop architecture. Critical events are
handled by hardware interrupts. Timers handle non-critical events.

<Doc Number> Page 31 of 198 Rev. -

Plan for Software Aspects of Certification

4.0 CERTIFICATION CONSIDERATIONS

4.1 Certification Basis and Means of Compliance

The certification basis for the software is Title 14 CFR 2x.1301 and 14 CFR 2x.1309.
RTCA/DO-178C has been selected as the means of compliance. The objectives will be
satisfied during the lifecycle development and integral processes. The Quality Assurance
Engineer will compile applicable artifacts and submit them to the Certification Authority.
Verification objectives are satisfied through a combination of reviews and analysis, the
development of test cases and procedures, and the subsequent execution of those test
procedures. Reviews and analysis provide an assessment of the accuracy, completeness,
and verifiability of the requirements, architecture, and design implementation.
The product will be developed in compliance with the following:

Reference / Issue Description

FAA TSO- TSO, Description

FAA Order 8110.4C Type Certification
Table 4-1 List of Compliance Documents

4.2 Issue Papers and Certification Review Items (CRI)

Document Number Title

Issue Paper SE-3.3 Guidance for Conducting Change Impact Analysis

Issue Paper SE-3.5 Use of Commercial Off The Shelf Software in Aircraft Avionics
Systems

CRI F-10 Management of Open Problem Reports (Software and CEH)

Table 4-2 List of Issue Papers and CRI’s

<Doc Number> Page 32 of 198 Rev. -