PLAN FOR SOFTWARE ASPECTS OF
CERTIFICATION
Prepared by:
Gary Picou
Vice President of Quality Systems
Reviewed and Approved by:
Peter Campbell
Vice President of Engineering
REVISION HISTORY
Rev. By Date Description of Change
New Picou/Campbell 11/26/2018 Draft for PAC45T
1 Picou/Campbell 02/25/2019 Release for TSO Submission
PAC45T
RTCA DO-178C
Software
Accomplishment
Summary
Document: 002-145-1784
Date: 2/25/2019
Revision: 1
PS Engineering Proprietary Document Page 2 of 12 Written by Gary Picou, checked by Peter Campbell
TABLE OF CONTENTS
1.0 ....... INTRODUCTION 4
1.1 SCOPE 4 1.2 DOCUMENT OVERVIEW 4 1.3REFERENCED DOCUMENTS 4
1.3.1Industry & regulatory 4 1.3.2PS Engineering associated documents 4
1.4 DEFINITIONS 5 1.5 ACRONYMS 5 1.6 PLANS OVERVIEW 6
2.0SYSTEM OVERVIEW (§11.1(A)) 6
2.1REQUIREMENTS ALLOCATED TO HARDWARE AND SOFTWARE 8 2.1.1Non-complex hardware functions 8 2.1.2Hardware functions allocated to programmable logic devices 8 2.1.3Software functions 8 2.1.4 Architecture 9 2.1.5 Processors 9 2.1.6Hardware/Software Interface 9 2.1.7 Safety Features 10
3.0SOFTWARE OVERVIEW (§11.1(B)) 10
3.1 REDUNDANCY 17 3.2MULTIPLE-VERSION DISSIMILAR SOFTWARE 17 3.3 RESOURCE SHARING 17 3.4 FAULT TOLERANCE 17 3.5FAILURE PROBABILITY FOR SOFTWARE RELATED ITEMS. 17
3.5.1Single Event Upsets 17 3.5.2Timing considerations 17 3.5.3Loss of Function (availability) and Loss of Integrity (Incorrect Operation) 18
4.0CERTIFICATION CONSIDERATIONS (§11.1(C)) 18
4.1 CERTIFICATION BASIS 18 4.1.1Means of Compliance 18
4.2SOFTWARE DESIGN ASSURANCE LEVEL C 19 4.3SYSTEM SAFETY ASSESSMENT 19
4.3.1Software contributions to failure conditions 19
5.0SOFTWARE LIFE CYCLE (§11.1(D)) 20
5.1SUMMARY OF LIFE CYCLE PROCESSES 22 5.1.1Software Planning Process (DO-178C §4.0) 22 5.1.2Software Development Process (DO-178C §5.0) 22
5.1.2.1Software Requirements Process (DO-178C §5.1) 22 5.1.2.2Software Design Process (DO-178C §5.2) 22 5.1.2.3Software Coding Process (DO-178C §5.3) 22 5.1.2.4Integration Process (DO-178C §5.4) 22
5.1.3Software Verification Process (DO-178C §6.0) 22 5.1.4Software Configuration Management Process (DO-178C §7.0) 23 5.1.5Software Quality Assurance Process (DO-178C §8.0) 23 5.1.6Certification Liaison Process (DO-178C §9.0) 23
PAC45T
RTCA DO-178C
Software
Accomplishment
Summary
Document: 002-145-1784
Date: 2/25/2019
Revision: 1
PS Engineering Proprietary Document Page 3 of 12 Written by Gary Picou, checked by Peter Campbell
6.0SOFTWARE LIFE CYCLE DATA (§11.1(E)) 25
7.0 . SCHEDULING (§11.1(F)) 25
8.0ADDITIONAL CONSIDERATIONS (§11.1(G)) 25
8.1ALTERNATIVE METHODS OF COMPLIANCE 25 8.2 NEW TECHNOLOGY 25 8.3 TOOL QUALIFICATION 25 8.4PREVIOUSLY DEVELOPED SOFTWARE (PDS) 26 8.5OPTION-SELECTABLE SOFTWARE 26 8.6USER-MODIFIABLE SOFTWARE 26 8.7 COTS SOFTWARE 26 8.8FIELD-LOADABLE SOFTWARE 26 8.9MULTIPLE-VERSION DISSIMILAR SOFTWARE 26 8.10PRODUCT SERVICE HISTORY 26
9.0SUPPLIER OVERSIGHT (§11.1(H)) 26
10.0COMPLIANCE MATRICES 27
TABLE OF TABLES
TABLE 2 DEFINITIONS 5 TABLE 3 ACRONYMS 6 TABLE 4 SYSTEM REQUIREMENTS ALLOCATED DSP SOFTWARE 6
TABLE of FIGURES
FIGURE 2-1 SYSTEM BLOCK DIAGRAM PAC45T 7 FIGURE 2 - HOST ΜCONTROLLER ARCHITECTURE OVERVIEW 11 FIGURE 3 - CONTROL HEAD ARCHITECTURE OVERVIEW 12 FIGURE 4 - ALERT TONE GENERATOR ARCHITECTURE OVERVIEW 13 FIGURE 3-5 DIGITAL SIGNAL PROCESSOR ARCHITECTURE DIAGRAM 14 FIGURE 4-1 INTERCOM FAILURE CONDITION 19 FIGURE 5-1 SOFTWARE LIFECYCLE OVERVIEW 21 FIGURE 5-2 SOFTWARE CERTIFICATION DOCUMENT FLOW DOWN 24
PAC45T
RTCA DO-178C
Software
Accomplishment
Summary
Document: 002-145-1784
Date: 2/25/2019
Revision: 1
PS Engineering Proprietary Document Page 4 of 12 Written by Gary Picou, checked by Peter Campbell
1.0 Introduction
1.1 Scope
This document fulfills the intent of the Plan for Software Aspects of Certification (PSAC), DO-178C data item for
the PAC45T Audio Controller for USAF T-1A Avionics Modernization Program. It is the is the primary means
used by the certification authority for determining whether an applicant is proposing a software life cycle that is
commensurate with the rigor required for the level of software being developed.
This PSAC is intended to comply with Advisory Circular 20-148, Reusable Software Components, dated December
7, 2004, with the exception that PS Engineering will use RTCA DO-178C instead of DO-178B.
1.2 Document Overview
This document provides an overview of the certification basis and features to be considered in the development of
the software for the PAC45T. This document also provides system overview, software overview, certification
considerations, software life cycle (processes), software life cycle data, initial software schedule, and additional
considerations.
1.3 Referenced Documents
In section headings, references to RTCA DO-178C are included in (parentheses).
1.3.1 Industry & regulatory
Document Number Document Name Revision Date
RTCA/DO-178C Software Considerations In Airborne Systems
And Equipment Certification
December 13, 2011
AC 20-115C Use of RTCA DO-178C July 19, 2013
AC 20-148 Reusable Software Components December 7, 2004
TSO C139A Audio Systems and Equipment Feb. 25, 2014
AS9006A Deliverable Aerospace Software Supplement for
AS9100, Quality Management Systems July 2013
1.3.2 PS Engineering associated documents
Table 1 shows a list of documents regarding the software life cycle for this component.
DOCUMENT TITLE NAME DOC PN REVISION DATE
PAC45T Plan for Software Aspects of
Certification
002-145-1780 2 2/27/2019
PAC45T System Product Definition 002-045-5495 9 2/06/2019
PAC45T Software Development and Verification
Plan
002-145-1783 1 1/6/2019
Software Accomplishment Summary 002-145-1784 1 2/27/2019
PAC45T
RTCA DO-178C
Software
Accomplishment
Summary
Document: 002-145-1784
Date: 2/25/2019
Revision: 1
PS Engineering Proprietary Document Page 5 of 12 Written by Gary Picou, checked by Peter Campbell
DOCUMENT TITLE NAME DOC PN REVISION DATE
Software Quality Assurance Plan 002-920-1786 1 2/2/2014
Software Configuration Management Document
PAC45T
002-145-1000 New 3/05/2019
Table 1 Documents
Definitions
Word/Phrase Definition
Software Partitioning The process of separating, usually with the express purpose of isolating one or more
attributes of the software, to prevent specific interactions and cross-coupling
interference.
Fail-Safe Reversionary mode- pilot is connected to communication radio (COM 1 & Alert Audio
Source 1)
Table 1 Definitions
1.5 Acronyms
Acronym Definition
H/W Hardware
HP Headphone Audio
HRTF Head Related Transfer Function
ICS Intercommunication system (intra aircraft)
ISO Isolate mode on ICS
LRU Line Replaceable Unit
MIC Microphone Audio
N/A Not Applicable
PDS Previously Developed Software
PIC Programmable Integrated Circuit
PSAC Plan for Software Aspects of Certification
QMS Quality Management System
RSC Reusable Software Component
SAS Software Accomplishment Summary
SCM Software Configuration Management
SDP Software Development Plan
SPD Serial Protocol Document
SQA Software Quality Assurance
PAC45T
RTCA DO-178C
Software
Accomplishment
Summary
Document: 002-145-1784
Date: 2/25/2019
Revision: 1
PS Engineering Proprietary Document Page 6 of 12 Written by Gary Picou, checked by Peter Campbell
Acronym Definition
SVP Software Verification Plan
TDM Time Division Multiplex
SW Software
VOX Voice Activated Relay (Intercom Squelch)
Table 2 Acronyms
1.6 Plans Overview
This Software plan details the steps taken during development of the Audio Controller software, with respect to the
creation of software code and the requirements to be met.
This PSAC also contains our Software Development Plan, with information regarding the Standards, Tools, and
development Environment.
2.0 System Overview (§11.1(a))
The Host microcontroller (μC) and Control Head μC(s) work together to configure the system in response to user
inputs and provide status information back to the user. Further, an independent alert system μC is present for
management of discrete alerts that are presented to the users in response to various external stimuli. While most
audio operations are performed in hardware, a DSP is used to process switched radio inputs and apply spatial
filtering when desired.
Item System Requirement Allocated to
1. Allow selection of radio audio to be routed to crew and/or
passenger headsets as desired
SW
3. Selection of intercom mode to allow intercommunication
between crew and passengers
SW
4. Voice detection/intercom squelch open HW
Table 3 System Requirements allocated DSP Software
PAC45T
RTCA DO-178C
Software
Accomplishment
Summary
Document: 002-145-1784
Date: 2/25/2019
Revision: 1
PS Engineering Proprietary Document Page 7 of 12 Written by Gary Picou, checked by Peter Campbell
DSP
(Radios)
FPGA0
(Radios & Intercom)
CODECs
Host
µcontroller
Transceivers
Control Data I/O
Analog Audio In/Out
Digital
Audio
Digital
Audio
Config
PAC45T
Hub
Status
FPGA1
(Music)
CODECs
Digital
Audio
Alert
µcontroller
Message Storage
Control Data I/O
Control Head
µcontroller
RS422
Transceiver
Control
PAC45T
Control
Head(s)
Hardware
Software
Alert Inputs
Figure 2-1 System Block Diagram PAC45T
PAC45T
RTCA DO-178C
Software
Accomplishment
Summary
Document: 002-145-1784
Date: 2/25/2019
Revision: 1
PS Engineering Proprietary Document Page 8 of 12 Written by Gary Picou, checked by Peter Campbell
2.1 Requirements allocated to hardware and software
This section is included to relate the peripheral hardware required for the PAC45T to perform the required functions.
See Requirements Matrix, Document 002-145-1785.
2.1.1 Non-complex hardware functions
The functions associated with simple electronic hardware are:
Microphone inputs, radio inputs, music inputs, headphone outputs
Microphone Inputs: typical 950mVrms (2.7Vpp). Attenuated prior to CODECs for 2Vpp.
Each microphone occupies a separate audio channel.
Radio Receiver Inputs: 2.4Vrms (6.8Vpp). Attenuated prior to CODEC for 2Vpp.
The aircraft radio receiver occupies a separate audio channel. The unswitched inputs are mixed in the CODEC and
the mix occupies a separate audio channel. Additional attenuation in the CODEC may be required to keep the mix
from clipping.
All CODEC inputs and outputs are rated for 0.707Vrms (2Vpp).
Headphone Outputs: 3.9Vrms (11Vpp). Gain applied at headphone amplifiers to account for 2Vpp max from
CODECs.
Each crew headphone channel (Left and right) has a dedicated headphone amp (pilot, copilot). Passenger
headphones are driven in pairs form dedicated headphone amps (passenger 1, passenger 2) (passenger 3, passenger
4)(passenger 5, passenger 6).
High and low pass analog filtering is available on all inputs and outputs.
PTT indications are connected to the FPGA for monitoring. However, audio routing from the crew mics to the radio
mic input is accomplished in hardware. No FPGA supervision of this function is required.
2.1.2 Hardware functions allocated to programmable logic devices
The specific hardware functions are article dependent and enumerated in those certification programs. However,
certain generic control functions are allocated to a Field Programmable Gate Array (FPGA) and a microcontroller.
Functions allocated to the FPGA include:
System health & reset functions
PTT and VOX monitoring
Digital audio routing and mixing.
Functions allocated to the microcontroller include:
Monitoring control head inputs
Updating control head displays
Intercom Logic and Sending Audio Routing Control Information to the FPGA and DSP
Audio CODEC control
2.1.3 Software functions
These generic control functions are allocated in software.
PAC45T
RTCA DO-178C
Software
Accomplishment
Summary
Document: 002-145-1784
Date: 2/25/2019
Revision: 1
PS Engineering Proprietary Document Page 9 of 12 Written by Gary Picou, checked by Peter Campbell
Functions allocated to DSP include:
All radio audio to headsets, including any spatial processing desired.
Functions allocated to the microcontroller include:
All radio audio to speaker, including line level inputs (speakers, CVR expansion audio)
Monitoring control head inputs
All other audio (such as unswitched, intercom, etc.(
Updating control head displays
Intercom Logic and Sending Audio Routing Control Information to the FPGA and DSP
Audio CODEC control
Tone Generator Alert Subsystem
Ref Table 2-1 for functions allocated to software.
2.1.4 Architecture
The architecture relies on a collection of DSP and FPGA resources to process all audio. All audio inputs are
digitized by CODECs and presented to an FPGA for processing. In the case of COM and AUX inputs, these are
passed off to the DSP where they are processed for use in each of the headset outputs. All other audio operations are
performed in an FPGA. Finally, the various audio mixes are routed back to CODECs for conversion back to analog
for the various audio outputs.
Figure 2-2 shows the simple intercom application and Figure 2-3 shows the PAC45T application in an audio selector
panel where more audio inputs and selection is required. The architecture remains the same except for the
configuration interface and audio processing not related to the PAC45T .
2.1.5 Processors
DSP: TI TMS320VC5509A
This device is responsible for processing radio audio for all headsets including spatial processing.
Host μC: Microchip dsPIC33FJ256GP506A
This device is used for configuring the system in response to user inputs and providing status information back to
the user.
Control Head μC: Microchip dsPIC33FJ256GP506A
This device is used to capture user inputs and communicate these to the Host μC. Status information from the Host
μC is also interpreted for display to the user.
Alert μC: Microchip PIC18LF2525
This device is used to manage the alert system which plays audible alerts in response to discrete system inputs.
2.1.6 Hardware/Software Interface
The Host μC communicates with the DSP, Alert μC and FPGAs via SPI.
The Host μC communicates with the Control head μC(s) via RS-422.
The Host μC communicates with all other hardware resources via i2c. These include discrete inputs to the system,
discrete outputs and relay controls for managing analog audio routing.
PAC45T
RTCA DO-178C
Software
Accomplishment
Summary
Document: 002-145-1784
Date: 2/25/2019
Revision: 1
PS Engineering Proprietary Document Page 10 of 12 Written by Gary Picou, checked by Peter Campbell
2.1.7 Safety Features
At the system level and malfunction of the unit can be mitigated by turning the unit off (or removing power via the
circuit breaker). This places the system in fail-safe mode which connects the pilot to communications transceiver #1
and copilot on communications transceiver #2.
System configuration options also allow for navigation receivers #1 and #2, Unswitched inputs #1 and #2, and the
Alert subsystem to be present in the fail-safe condition, further mitigating loss of function.
3.0 Software Overview (§11.1(b))
There are 4 separate software components that work together in the PAC45T:
Host μController
Alert μController
Control Head μController
DSP
Block diagrams of the software architecture are shown in Figures 2 -5.
PAC45T
RTCA DO-178C
Software Accomplishment Summary
Document: 002-145-1784
Date: 2/26/2019
Revision: 1
Config
Boot Idle
Error Handler
Exception Recovery
Boot 10ms
Boot 50ms
Idle
10ms
50ms
1s
60s
Scheduler
Host uController
Boot State 0
Boot State 1
Boot State 6
Boot State 7
Boot State 8
Boot State 5
Boot State 2
Boot State 3
Boot State 4
Boot Idle The Boot Idle task progresses through 9 states,
executing one state each time it is called. It
starts at State 0 and finished at State 8. Once
State 8 has completed successfully, the
Scheduler terminates the boot process and
begins normal operation.
Boot 0: Initialize i2C and UARTs
Boot 1: Initialize ADC, FPGAs, DSP
Boot 2: Load EEPROM configuration data
Boot 3: Initialize system variables & CODECs
Boot 4: Synchronization step with DSP
Boot 5: Initialize intercom state machine
Boot 6: Test DSP
Boot 7: Synchronization step with DSP
Boot 8: Initialize DSP, activate audio outputs
Boot 10ms
Service Event Log
Service EEPROM
Boot 50ms
Service WDT
Service Boot Indicators
Service Boot Timers
The Boot 10ms task services the event log,
which monitors the status of the system and
records this data to nonvolatile storage in the
EEPROM.
The Boot 50ms task performs several functions:
1) Service the system Watchdog Timer
2) Communicate boot status to the control
head(s)
3) Service boot timers which protect against
system lockup.
Idle
Service EEPROM
Service Control Heads
The system Idle task services a minimum set of
functions in order to preserve available idle
overhead. It does process 2 tasks which can
require rapid service in order to maintain
adequate system performance:
1) Service EEPROM, primarily EEPROM writes
which can be time consuming.
2) Service control heads. Up to 4 may be
connected to the system and are polled in
sequence with a goal of servicing all 4 in under
100ms.
10ms
Service Event Log
The 10ms task services the event log, which
monitors the status of the system.
50ms
Service WDT
Service GPIO
Service Alerts
The 50ms task performs several functions:
1) Service the system Watchdog Timer
2) Reads and writes all system I/O
3) Service alert system, primarily to pass ACK
commands requested by user via a control head
and to request the generation of system level
tones.
4) Service DSP: update DSP configuration and
monitor DSP status
5) Service FPGAs: update FPGA0 & 1
configurations and monitor their status
6) Process all user inputs, make all necessary
translations so that this data is usable by the
audio state machine and translate the current
system status into formats acceptable to the
various outputs including the control heads.
7) Service the audio state machine, which
configures all audio paths in the system in
response to the configuration set by the user(s)
Service DSP
Service FPGAs
Process User I/O
Service Audio State Machine
1s
Refresh GPIO Config
Refresh CODEC Config
Refresh DSP Config
The 1s task performs several functions, most of
which are system health related. This is a
chance to correct any configuration anomalies
which may have gone undetected.
1) Refreshes the configuration of all GPIO
2) Refreshes the configuration of all CODECs
3) Refreshes the configuration of the DSP
4) Stores all changes in the configuration of the
system to EEPROM.
Store Config
60s
Update Log
The 60s task exists solely to ensure the event
log duration is kept up to date with the latest
time accurate to the nearest minute. Otherwise,
the last log recorded would be at the time of the
last change in system status.
Figure 2 - Host μController Architecture Overview
PAC45T
RTCA DO-178C
Software Accomplishment Summary
Document: 002-145-1784
Date: 2/26/2019
Revision: 1
Config
Idle
Error Handler
Exception Recovery
25ms
Scheduler
Control Head uController
25ms
Service Fault
The25ms task performs 1 task:
1) Service Fault. Monitors for loss of data from
the Hub and turns off all LEDs to indicate this
condition to the user.
Idle
Process Rx Data
Update LEDs
Service User Inputs
The Idle task performs several functions:
1) Processes data received from the Hub
2) Updates all LEDs in response to received
data.
3) Service all user inputs including
potentiometers, switches and buttons.
4) package and transmit the current
configuration data to the hub
Process Tx Data
The Control Head uController architecture is composed of
4 primary stages:
Config – Initializes the uController when coming out of a
reset.
Scheduler – Runs a given task at the appropriate time.
Error Handler – Monitors the outcome of the task that was
just completed and should an anomaly be detected,
determines the correct course of action for recovery.
Exception Recovery – Initiates a reset in the event of a
system anomaly via a Watchdog Timer.
Figure 3 - Control Head Architecture Overview
PAC45T
RTCA DO-178C
Software Accomplishment Summary
Document: 002-145-1784
Date: 2/26/2019
Revision: 1
Config
5ms
Exception Recovery
25ms
Scheduler
Alert uController
25ms
Service ACK
Service Message Playback IC
Service Alerts Triggers
The 25ms task performs several functions:
1) Service ACK indication which will cancel the
current alert playback
2) Service the message playback IC. This
includes requesting a specific alert message be
played or stopped
3) Service alert triggers. Scan all alert inputs for
changes and properly queue active alerts for
playback
The Alert uController architecture is composed of 3
primary stages:
Config – Initializes the uController when coming out of a
reset.
Scheduler – Runs a given task at the appropriate time.
Exception Recovery - Initiates a reset in the event of a
system anomaly via a Watchdog Timer.
5ms
Service Host Interface
The 5ms task services the host interface.
Communication with the host via the SPI bus
occurs on an interrupt and the received data is
processed here. Data is also prepared for
transmit to the hub here.
Figure 4 - Alert Tone Generator Architecture Overview
PAC45T
RTCA DO-178C
Software Accomplishment Summary
Document: 002-145-1784
Date: 2/26/2019
Revision: 1
DR0
(To DSP McBSP0)
16 Timeslots
16 bits per timeslot
1 2 3 4 5 60 7 8 9 10 11 12 13 14 15
Com 1 Com 2 Com 3 Com 4 Com 5 Com 6 Com 7 Com 8 Aux 1 Aux 2 Aux 3 Aux 4 Aux 5 Aux 6 Aux 7 Aux 8
1 2 3 4 5 60 7 8 9 10 11 12 13 14 15
Pilot Left Copilot Right Copilot Left Pilot Right Obs1 Left Obs 1 Right Obs 2 Left Obs 2 Right (Unused) (Unused) (Unused) (Unused) (Unused) (Unused) (Unused) (Unused)
DX0
(From DSP McBSP0)
16 Timeslots
16 bits per timeslot
McBSP0
DMA
McBSP DRR
“rcv”
DMA0_RcvIsr():
Copies rcv to
rcvBufA to
AudioIn[][]
“rcvBufA”
“AudioIn[channel][sample]”
“SpatialAudio_Left[channel][sample]”
“SpatialAudio_Right[channel][sample]”
runSpatialAudio(position, input, channel):
Applies IntelliAudio to all Coms in AudioIn[][],
Stores result in SpatialAudio_Left[][] and
SpatialAudio_Right[][]
COMs
runIntelliVox():
Determines vox state of mic inputs based in
IntelliAudio algorithm. Stores results in
VOXstate_obj
“AudioOut[channel][sample]”
DMA
McBPS0
“xmt”
McBSP DXR
DMA1_XmtIsr():
Copies AudioOut[][] to
xmt
fractVecMix(source, level, dest):
Mixes all coms based on levels in MixLevel[][]. Chooses
either raw com audio or SpatialAudio_Left/Right based on
state of SpatialAudio on/off flags
DSP
SPCR2 is set to indicate McBSP is not ready for new data
SPCR2.XRDY is set when ready for new data from CPU or DMA.
XEVT is set (an interrupt) when ready for more data from DMA (corresponds with XRDY)
Setting SPCR2.XINTM to 00
causes TX interrupt XINT to be sent
each time XRDY is set.
AUX
Figure 3-5 Digital Signal Processor Architecture Diagram
PAC45T
RTCA DO-178C
Software Accomplishment Summary
Document: 002-145-1784
Date: 2/26/2019
Revision: 1
The DSP will adjust the volume for all user adjustable inputs. After adjustment, these inputs will be routed to the appropriate output. The DSP will communicate
with the host microcontroller for configuration information and to store states for power cycle using an SPI data bus. Processor: Texas Instruments, Digital
Signal Processor (DSP), TMS320VC5509A, 16 bit Fixed-Point, 108 MHz, 144LQFP, with dual 40 bit MACs running at 108 MIPS (9.3 nS instruction time).
The Audio is input to the DSP in a 16 bit linear format with a 16 kHz sample rate.
There are up to sixteen (16) channels of audio input/output available to the DSP.
Currently there are FIR filters executing on the DSP; a benchmark for one of these filters is: (99) taps with a (20) sample audio block size or vector length;
executes in less than 6 μs.
Tools: Code Composer Studio, Version: 6.1.1.00022, Texas Instruments, 2014.
PAC45T Audio
Controller RTCA DO-178C
Plan for Software
Aspects of Certification
Document: 002-145-1780
Date: 11/26/2018
Revision: New
This document last printed 3/5/2019 4:21:00 PM
Page 17 of 38 PS Engineering Proprietary
3.1 Redundancy
Not Applicable. There are no redundant functions allocated in the PAC45T . The specific device integrated with the
software uses a power off, fail-safe system to ensure air to ground communications in the event of anomalous
operation.
3.2 Multiple-Version Dissimilar Software
Not applicable
3.3 Resource Sharing
None
3.4 Fault Tolerance
The article integrated with the PAC45T uses a power off, Fail-Safe system to ensure air to ground communications
in the event of anomalous operation. In addition, an unswitched input with Crew Alerting System audio (CAS) will
be presented to the pilot headset with the unit in fail-safe.
The software DSP code portion of the PAC45 is for the volume control if the audio. In the event of a fault in the
airborne software, the fail-safe function allows continued communications.
3.5 Failure Probability for Software related items.
Based on the data provided by the DSP manufacturer (Texas Instruments), the probability of a failure within the
DSP is 3.64x10-8, with a 60% confidence level, at an elevated operating temperature (+55°C).
Based on the reliability data reported by the PIC manufacturer (microchip), the probability of a failure within the μC
is 2.7x10-9, with a 60% confidence level, at an elevated operating temperature (+55°C).
3.5.1 Single Event Upsets
For maximum robustness, fault recovery is assigned to hardware in the form of an FPGA. Each major system
component is polled constantly to ensure the system as a whole is operating properly. Should an anomaly be
detected, the FPGA issues a system wide reset to restart the system.
3.5.2 Timing considerations
The physical transport commands are via a SPI bus. The host μC performs all tasks on a timed loop model. There
exists a 10ms, 50ms, 1s, and 60s repeating loop for executing various tasks. The vast majority of tasks occur in the
50ms loop. Speed sensitive tasks, such as communication with user control heads, are permitted to operate in system
idle time.
All tasks in the 10ms loop complete within 1.5μs
All tasks in the 50ms loop complete within 16ms
All tasks in the 1s loop complete within 18ms
All tasks in the 60s loop complete within 12μs
System idle time is then 67% which is adequate for control head polling which occurs once every 5.9ms on average.
This is adequate to scan all 4 system control heads in 23.5ms which still leaves, on average, 21% of each 50ms
window to spare.
PAC45T Audio
Controller RTCA DO-178C
Plan for Software
Aspects of Certification
Document: 002-145-1780
Date: 11/26/2018
Revision: New
This document last printed 3/5/2019 4:21:00 PM
Page 18 of 38 PS Engineering Proprietary
Should a control head fail, a 10ms timeout is observed. In the worst case where there are 3 control head failures,
communicating with the remaining active control head will occur on roughly a 60ms interval which is sufficient for
an acceptably responsive user experience.
Host μC communication with various peripherals occurs via SPI bus. This bus is shared by the DSP, Alert μC and
FPGAs and is exercised in the 50ms loop.
In single 50ms processing window, which takes 16ms to execute the following time is spent exercising the SPI bus:
Alert μC: 240μs
DSP (1st pass): 120μs
FPGA0: 2.52ms
FPGA1: 220μs
DSP (2nd pass): 3.4ms
This totals 6.48ms of the 16ms spent in this task.
3.5.3 Loss of Function (availability) and Loss of Integrity (Incorrect Operation)
The PAC45T is primarily a cockpit audio control and intercommunications system. The worst-case malfunction will
result in unavailability for the audio sources. It will be obvious to the crew that the audio source selection functions
are not available. There is little chance that a crew will incorrectly interpret the condition of the unit. Information
provided by these audio sources, such as navigation source identification, is also available from other equipment.
The system in fail-safe mode connects the pilot to communications transceiver #1 and copilot on communications
transceiver #2.
System configuration options also allow for navigation receivers #1 and #2, Unswitched inputs #1 and #2, and the
Alert subsystem to be present in the fail-safe condition, further mitigating loss of function.
4.0 Certification Considerations (§11.1(c))
4.1 Certification Basis
The PAC45T system shall be FA-TSO authorized approved under one or more of the FAA-TSO standards under 14
CFR Part 21, Subpart O, Technical Standard Order Authorizations:
The Audio section is designed in accordance with TSO C139a, Aircraft Audio Systems and Equipment February 25,
2014. Compliance has been demonstrated by meeting the requirements of RTCA Inc. document DO-214A, (Audio
Systems Characteristics and Minimum Operational Performance Standards for Aircraft Audio Systems).
Compliance with the Technical Standard Orders environmental qualification shall be in accordance with RTCA/Inc.
DO-160G, (Environmental Conditions and Test Procedures for Airborne Equipment).
Software compliance required by TSO C139a, Section 3(e) shall be in accordance with DO-178C (Software
Considerations for Airborne Equipment).
4.1.1 Means of Compliance
PS Engineering will perform verification testing on articles incorporating this software. This testing includes:
Bench testing of all inputs, outputs, modes and functions.
Software and CEH verification in accordance with company policies, document 002-178-0300.
Audio Systems Testing in accordance with RTCA DO-214A, §2.4
Environmental testing in accordance with RTCA DO-160G, using DO-214A §2.5
PAC45T Audio
Controller RTCA DO-178C
Plan for Software
Aspects of Certification
Document: 002-145-1780
Date: 11/26/2018
Revision: New
This document last printed 3/5/2019 4:21:00 PM
Page 19 of 38 PS Engineering Proprietary
Installed systems tests in accordance with RTCA DO-214A, §3.0
4.2 Software Design Assurance Level C
Software assurance level in the system is Level C. This is justified and mandated by TSO C139, Paragraph 3(b), and
the software life cycle data will reflect this assurance level, in accordance with DO-178C, §2.3.4, Note 2.
However, the actual Failure Condition Category is No Effect, because of the fail-safe nature of the equipment; any
anomalous behavior can be remedied by turning the PAC45T unit off. This will restore pilot connection to the
communications transceivers. This will not affect the operational capability of the aircraft or increase crew
workload.
The aircraft intercom is non-essential and non-required.
4.3 System Safety Assessment
System safety assessment was conducted in accordance with SAE ARP4761, Guidelines and Methods for
Conducting the Safety Assessment Process of Civil Airborne Systems and Equipment and AC25.1309-1A. This
document is 002-145-1309.
4.3.1 Software contributions to failure conditions
The software in the PAC45T is robust, and does not have any user modifiable elements. The programming is static,
such that, once the devices are coded, they cannot change. Only a software programming error or a coding error can
result in an airborne anomaly.
Therefore, once the software dependent devices have been installed and tested, only a hardware failure would result
in a system anomaly.
Intercom
Fail
DSP
Fail
Loss of Intercommunications
will not have any effect on aircraft
safety or crew workload.
Level E
CC
HW
FailCODEC FAIL
E
Figure 4-1 Intercom Failure Condition
PAC45T Audio
Controller RTCA DO-178C
Plan for Software
Aspects of Certification
Document: 002-145-1780
Date: 11/26/2018
Revision: New
This document last printed 3/5/2019 4:21:00 PM
Page 20 of 38 PS Engineering Proprietary
In the event of a processor or a CPU failure, the intercom and or PAC45T may fail to function. This will either result
in an open intercom circuit, or one that cannot be opened. In any case, the intercommunication system is non-
essential and non-required, and the loss of availability will not have a negative impact on crew workload. Even in a
2-pilot required situation, headsets are not required.
5.0 Software Life Cycle (§11.1(d))
The software life cycle is detailed in the PS Engineering Plan for Software Certification. Figure 5-1 shows the flow
for the life cycle for this product. As the product is not yet in full production, all life cycle stages have not been
tested. However, this life cycle plan has been used successfully in other PS Engineering products. The life cycle for
all programmed devices in the PAC45T is requirements driven, with a closed-loop for detecting field problems and
incorporating changes into production.
Figure 5-2 shows the document relationships in the software lifecycle.
PAC45T Audio
Controller RTCA DO-178C
Plan for Software
Aspects of Certification
Document: 002-145-1780
Date: 11/26/2018
Revision: New
This document last printed 3/5/2019 4:21:00 PM
Page 21 of 38 PS Engineering Proprietary
RequirementsProof of Concept
Software Design
Ø System
Ø High Level
Ø Low Level
Ø Derived
Ø Inferred
Coding
Certification Rigor
Integration
Meet
Requirements
?
Verification
(meets requirements)
Validation
(Requirements meet actual
system functionality)
Update Concept
Based on
Validation
Certification
Meet
Requirements
?
Release
Field Feedback
Problem
Reports
Bug Fixes
Ø Hardware definition
Ø Constraints
Ø Safety Objectives
Ø Target Device
Verification
Ø Configuration
Management
Ø Hardware Verification
Ø Tool Qualification
Design Improvements
Figure 5-1 Software Lifecycle Overview
PAC45T Audio
Controller RTCA DO-178C
Plan for Software
Aspects of Certification
Document: 002-145-1780
Date: 11/26/2018
Revision: New
This document last printed 3/5/2019 4:21:00 PM
Page 22 of 38 PS Engineering Proprietary
5.1 Summary of life cycle processes
This section defines and summarizes the life cycle processes to be used for the PAC45T, and includes information
on the specific objectives and organizations involved. Details are contained in relevant sections and other
documents.
5.1.1 Software Planning Process (DO-178C §4.0)
This process is accomplished by engineering department, in coordination between the hardware and software teams
(or individuals) with the objective of:
Defining the overall architecture,
Defining the standards, platforms and tools to be used,
Defining the communication between elements of HW SW and CEH.
Individual responsibilities are assigned for the lifecycle processes to follow.
Sequence, feedback, and transition criteria are established.
Feedback provided to System Life Cycle Processes
5.1.2 Software Development Process (DO-178C §5.0)
The Software Development Plan is contained in document 002-145-178_, and included details of the development
processes, including the design, coding, and integration processes, and the company organization responsible for
that activity.
5.1.2.1 Software Requirements Process (DO-178C §5.1)
The software requirements process will start with a Product Definition (PAC45T Product Definition, document 002-
920-1213) created by the company, collaboration between sale/marketing, production, quality (certification), and
engineering. The process output is a Requirements Document/Matrix, 002-920-1783, which captures system, high-
level, low-level and derived requirements, and provides traceability forward to the verification activity.
5.1.2.2 Software Design Process (DO-178C §5.2)
The process for software design involves the principle engineer making design decisions to meet the stated
requirements, derived and low level requirements, and meet certification rigor.
5.1.2.3 Software Coding Process (DO-178C §5.3)
The process for software coding used best practices, industry standards, and company standards referenced in
document 002-178-0300.
5.1.2.4 Integration Process (DO-178C §5.4)
The purpose of the integration process is to place the executable object code in the target article. Engineering is
responsible for establishing the transition criteria. Engineering and production test are responsible for the post
integration verification activities to ensure requirements are met.
5.1.3 Software Verification Process (DO-178C §6.0)
Software verification process is accomplished by engineering, with the assistance of the test manager. They will
detect any errors, conflicts, omissions, between the software requirements (Requirements Document/Matrix, 0025-
920-1783) and the integrated code in the article. Verification ensures that the executable code meets software
requirements and is traceable backwards to the requirements.
PAC45T Audio
Controller RTCA DO-178C
Plan for Software
Aspects of Certification
Document: 002-145-1780
Date: 11/26/2018
Revision: New
This document last printed 3/5/2019 4:21:00 PM
Page 23 of 38 PS Engineering Proprietary
5.1.4 Software Configuration Management Process (DO-178C §7.0)
The purpose of the software configuration process is to enable version tracking throughout the software lifecycle,
specifically as the code is released to production. Engineering is responsible for documenting the changes, and the
Quality department tracks any production changes through the Engineering Change Order system.
5.1.5 Software Quality Assurance Process (DO-178C §8.0)
The Software Quality Assurance (SQA) is in place to ensure that all code conforms to the requirements, and that the
associated plans, processes and process objectives of the development through integration and verification are in
compliance.
5.1.6 Certification Liaison Process (DO-178C §9.0)
The Certification Liaison individual at PS Engineering is a Single Point of Contact between the company, and the
FAA or other certification authorities, and their designees.
PAC45T Audio
Controller RTCA DO-178C
Plan for Software
Aspects of Certification
Document: 002-145-1780
Date: 11/26/2018
Revision: New
This document last printed 3/5/2019 4:21:00 PM
Page 24 of 38 PS Engineering Proprietary
PAC45 Product Definition &
Requirements
(002-045-5495)
PAC45 PSAC
(002-145-1780)
SW Quality Plan
(002-178-0600)
PAC45
Configuration Management
Plan
(002-145-1785)
PAC45
Software Development and
Verification Plan
(002-145-1783)
PAC45 Verification Test
Results
(002-145-1782)
PAC45 Software
Accomplishment Summary
(002-920-1784)
PAC45 Configuration Index
(002-145-1000)
Software Tool Qualification
Plan
(002-178-0605)
Company-Wide Article Specific
Quality Management
System
(002-422-1105)
Figure 5-2 Software certification document flow down
PAC45T Audio
Controller RTCA DO-178C
Plan for Software
Aspects of Certification
Document: 002-145-1780
Date: 11/26/2018
Revision: New
This document last printed 3/5/2019 4:21:00 PM
Page 25 of 38 PS Engineering Proprietary
6.0 Software Life Cycle Data (§11.1(e))
PS Engineering considers the following as applicable data for the article Software Life Cycle to be tracked and
maintained to provide evidence of software design assurance and certification compliance in accordance with the
Quality plans:
Planning requirements documents (product Definition and Software Requirements)
Test Reports
Review checklists
Design Notes
Problem reports (internal and field)
Engineering Change Orders which incorporate outputs from the above
Software quality reviews and audits
Certification authority submitted documents (PSAC, Accomplishment Summaries, etc.)
Communication with certification authorities
Source code and executable object code
Software lifecycle data is captured on PS Engineering form 002-178-1104.
7.0 Scheduling (§11.1(f))
The PAC45T is a Reusable Software Component. The time is spent entirely on developing the DSP executable code.
The integration and verification activities are divided into separate tasks:
Development of DSP audio paths
Verification of DSP audio paths
Development of audio filters to control the audio band path to RTCA DO-214A requirements
Verification of audio band pass
Development of intercom voice-activated squelch to match the performance of the current analog circuits.
Verification of intercom voice-activated squelch
Development of the intercom mode control and audio routing functions.
Verification of intercom mode control and audio routing functions
Total system verification and Validation
Development is complete at this time.
8.0 Additional Considerations (§11.1(g))
8.1 Alternative Methods of Compliance
None
8.2 New Technology
None.
8.3 Tool Qualification
Design Environment is controlled by the Texas Instruments tool chain for the DSP, Code Composer Studio
(CCStudio) Integrated Development Environment (IDE) v6.
Tool Qualification shall be in accordance with PS Engineering document 002-178-0605.
PAC45T Audio
Controller RTCA DO-178C
Plan for Software
Aspects of Certification
Document: 002-145-1780
Date: 11/26/2018
Revision: New
This document last printed 3/5/2019 4:21:00 PM
Page 26 of 38 PS Engineering Proprietary
The tool will be qualified by satisfying the same processes and tool operational requirements. Test cases and
documentation will be used to qualify the tool. These tool qualification results shall be documented in the Tool
Checklists filed by engineering with the testing documents. The tool qualification plan is contained in 002-178-
0605.
8.4 Previously Developed Software (PDS)
PAC45T DSP was developed as a Reusable Software Component, and deployed in the PMA450 TSO since 2014.
This article uses a portion of that previously developed code.
8.5 Option-Selectable Software
None
8.6 User-Modifiable Software
None. No portion of the executable code or data can be changed except by the manufacturer. The Option-select are
predetermined by the manufacturer, and do not result in any deactivated code sections.
8.7 COTS Software
None used in airborne application. The executable code was created at PS Engineering.
8.8 Field-Loadable Software
None. All software is contained in onboard CPU memory and is not modifiable.
8.9 Multiple-version Dissimilar Software
None
8.10 Product Service History
PS Engineering has been using this family of devices in similar products since 2014, with no reported field software
issues in over 1,000 systems delivered thus far..
There are no un-use service difficulty reports for these products.
9.0 Supplier Oversight (§11.1(h))
PS Engineering uses COTS components procured from approved suppliers under our FAA-approved manufacturing
system, which is also consistent with AS9100:D.
All of the programmed devices are coded in our facility by PS Engineering employees in accordance with internal
procedures and a Software Quality Assurance Plan that will limit possibilities of errors and programming failures.
PAC45T Audio
Controller RTCA DO-178C
Plan for Software
Aspects of Certification
Document: 002-145-1780
Date: 11/26/2018
Revision: New
This document last printed 3/5/2019 4:21:00 PM
Page 27 of 38 PS Engineering Proprietary
10.0 Compliance Matrices
Table A-1 Software Planning Process
Objective Activity Output
Document Reference
Description Ref Ref Data Item Ref
1 The activities of the software life cycle processes are defined. 4.1.a
4.2.a PSAC 11.1
002-145-1780
4.2.c §5.1.1
4.2.d SDP 11.2 002-145-1783
§2.4
4.2.e SVP 11.3
002-145-1782
4.2.g
4.2.i SCM Plan 11.4 002-145-1785
4.2.l
4.3.c SQA Plan 11.5
002-145-1785
002-422-1105
§11.0
2 The software life cycle(s), including the inter-relationships between the processes, their sequencing, feedback mechanisms, and transition criteria, is defined.
4.1.b 4.2i 4.3.b
PSAC 11.1 002-145-1780
§5.0
SDP 11.2 002-145-1783
§2.4
SVP 11.3 002-145-1782
SCM Plan 11.4 002-145-1785
SQA Plan 11.5 002-145-1785
3 Software life cycle environment is selected and defined. 4.1.c
4.4.1 PSAC 11.1
4.4.2.a SDP 11.2 002-145-1783
§6.4
4.4.2.b SVP 11.3 002-145-2545
4.4.2.c SCM Plan 11.4 002-145-1785
4.4.3 SQA Plan 11.5 002-145-1785
4 Additional considerations are addressed. 4.1.d 4.2.f PSAC 11.1
002-145-1780
§8.0
4.2.h SDP 11.2 002-145-1783
PAC45T Audio
Controller RTCA DO-178C
Plan for Software
Aspects of Certification
Document: 002-145-1780
Date: 11/26/2018
Revision: New
This document last printed 3/5/2019 4:21:00 PM
Page 28 of 38 PS Engineering Proprietary
§7.0
4.2.i SVP 11.3 No additional
considerations to verify
4.2.j SCM Plan 11.4 No additional
considerations to manage
4.2.k
SQA Plan 11.5
5 Software development standards are defined. 4.1.e
4.2.b SW Requirements
Standards in PSAC
11.6 002-145-1780
§8.3
4.2.g SW Design Standards 11.7
002-145-1783
in SDP §6.2
4.5 SW Code Standards 11.8
002-145-1783
in SDP §6.2
6 Software plans comply with RTCA DO-178C. 4.1.f 4.3.a 4.6
Software Verification Results 11.14
002-145-1784 SAS §
7 Development and revision of software plans are coordinated. 4.1.g 4.2.g 4.6
Software Verification Results 11.14 SVR 002-145-2545
Table A-2 Software Development Process
Objective Activity Output
Reference Doc.
Description Ref Ref Data Item Ref
1 High-level requirements are developed. 5.1.1.a
5.1.2.a
Software Requirements Data 11.9
002-145-2546
§1.0
5.1.2.b
5.1.2.c
5.1.2.d
5.1.2.e
5.1.2.f
5.1.2.g
Trace Data 11.21 002-145-2545
DVT 5.1.2.j
5.5.a
Derived high-level requirements re defined and provided the system processes, including the System Safety Assessment process.
5.1.1.b 5.1.2.h Software
Requirements
Data 11.9
002-145-2546
§1.0 002-145-1309 5.1.2.i
3 Software architecture is developed. 5.2.1.a 5.2.2.a
Design Description 11.10 002-145-1780
§2.1.4 5.2.2.d
PAC45T Audio
Controller RTCA DO-178C
Plan for Software
Aspects of Certification
Document: 002-145-1780
Date: 11/26/2018
Revision: New
This document last printed 3/5/2019 4:21:00 PM
Page 29 of 38 PS Engineering Proprietary
4 Low-level requirements are developed. 5.2.1.a
5.2.2.a
Design Description 11.10 002-145-2546
§1.0
5.2.2.e
5.2.2.f
5.2.2.g
5.2.3.a
5.2.3.b
5.2.4.a
Trace Data 11.21 002-145-2545
DVT
5.2.4.b
5.2.4.c
5.5.b
5 Derived low-level requirements are defined and provided to the system processes, including the system safety assessment process.
5.2.1.b
5.2.2.b
Design
Description 11.10
002-145-2546
§1.0
5.2.2.c
6 Source Code is developed. 5.3.1.a
5.3.2.a
Source Code 11.11
Final
Rev 0.013
0x46a1
5.3.2.b
5.3.2.c
5.3.2.d Trace Data 11.21
002-145-1784 SAS
§12.0 5.5.c
7 Executable Object Code and Parameter Data Item Files, if any, are produced and loaded in the target computer. 5.4.1.a
5.4.2.a Executable Object
Code 11.12 002-145-2018
Configuration Index
5.4.2.b
5.4.2.c
5.4.2.d Parameter Data
Item File 5.4.2.e
11.22 002-145-2018
Configuration Index 5.4.2.f
PAC45T Audio
Controller RTCA DO-178C
Plan for Software
Aspects of Certification
Document: 002-145-1780
Date: 11/26/2018
Revision: New
This document last printed 3/5/2019 4:21:00 PM
Page 30 of 38 PS Engineering Proprietary
Table A-3 Verification of Outputs of Software Requirements Process.
Objective
Activity Output
REF DOC.
Description Ref Ref Data Item Ref
1 High-level requirements comply with system requirements. 6.3.1.a 6.3.1 Software Verification Results 11.14
002-145-2456 Rqmt’s
002-145-2545 DVT
2 High-level requirements are accurate and consistent. 6.3.1.b 6.3.1 Software Verification Results 11.14
002-145-2456 Rqmt’s
002-145-2545 DVT
3 High-level requirements are compatible with target computer. 6.3.1.c 6.3.1 Software Verification Results 11.14
002-145-2456 Rqmt’s
002-145-2545 DVT
4 High-level requirements are verifiable. 6.3.1.d 6.3.1 Software Verification Results 11.14 002-145-2456
Rqmt’s 002-145-2545
DVT
5 High-level requirements conform to standards. 6.3.1.e 6.3.1 Software Verification Results 11.14
002-145-2456 Rqmt’s
002-145-2545 DVT
6 High-level requirements are traceable to system requirements. 6.3.1.f 6.3.1 Software Verification Results 11.14 002-145-2456
Rqmt’s 002-145-2545
DVT
7 Algorithms are accurate. 6.3.1.g 6.3.1 Software Verification Results 11.14 002-145-2456
Rqmt’s 002-145-2545
DVT
PAC45T Audio
Controller RTCA DO-178C
Plan for Software
Aspects of Certification
Document: 002-145-1780
Date: 11/26/2018
Revision: New
This document last printed 3/5/2019 4:21:00 PM
Page 31 of 38 PS Engineering Proprietary
Table A-4 Verification of Outputs of Software Design Process
Objective
Activity Output
Ref. Doc
Description Ref Ref Data Item Ref
1 Low-level requirements comply with high-level requirements. 6.3.2.a 6.3.2 Software Verification
Results 11.14 002-145-1782
Verification test Results
2 Low-level requirements are accurate and consistent. 6.3.2.b 6.3.2 Software Verification
Results 11.14 002-145-1782
Verification test Results
3 Low-level requirements are compatible with target computer. 6.3.2.c 6.3.2 Software Verification
Results 11.14 002-145-1782
Verification test Results
4 Low-level requirements are verifiable. 6.3.2.d 6.3.2 Software Verification Results 11.14
002-145-1782 Verification test
Results
5 Low-level requirements conform to standards. 6.3.2.e 6.3.2 Software Verification Results 11.14
002-145-1782 Verification test
Results
6 Low-level requirements are traceable to high-level requirements. 6.3.2.f 6.3.2 Software Verification
Results 11.14 002-145-1782
Verification test Results
7 Algorithms are accurate. 6.3.2·9 6.3.2 Software Verification Results 11.14
002-145-1782 Verification test
Results
8 Software architecture is compatible with high-level requirements. 6.3.3.a 6.3.3 Software Verification
Results 11.14 002-145-1782
Verification test Results
9 Software architecture is consistent. 6.3.3.b 6.3.3 Software Verification Results 11.14
002-145-1782 Verification test
Results
10 Software architecture is compatible with target computer. 6.3.3.c 6.3.3 Software Verification
Results 11.14 002-145-1782
Verification test Results
11 Software architecture is verifiable. 6.3.3.d 6.3.3 Software Verification Results 11.14
002-145-1782 Verification test
Results
12 Software architecture conforms to standards. 6.3.3.e 6.3.3 Software Verification Results 11.14
002-145-1782 Verification test
Results
13 Software partitioning integrity is confirmed. 6.3.3.f 6.3.3 Software Verification Results 11.14
002-145-1782 Verification test
Results
PAC45T Audio
Controller RTCA DO-178C
Plan for Software
Aspects of Certification
Document: 002-145-1780
Date: 11/26/2018
Revision: New
This document last printed 3/5/2019 4:21:00 PM
Page 32 of 38 PS Engineering Proprietary
PAC45T Audio
Controller RTCA DO-178C
Plan for Software
Aspects of Certification
Document: 002-145-1780
Date: 11/26/2018
Revision: New
This document last printed 3/5/2019 4:21:00 PM
Page 33 of 38 PS Engineering Proprietary
Table A-5 Verification of Outputs of Software Coding & Integration Processes
Objective Output
Description Ref Ref Data Item Ref Ref DOC
1 Source Code complies with low-level requirements.
6.3.4.a 6.3.4 Software
Verification Results 11.14
002
-145
-24
56
Re
quir
em
ents
Matr
ices
002
-145
-25
45
Desig
n V
erificatio
n T
ests
2 Source Code complies with software architecture.
6.3.4.b 6.3.4 Software
Verification Results 11.14
3 Source Code is verifiable.
6.3.4.c 6.3.4 Software
Verification Results 11.14
4 Source Code conforms to standards.
6.3.4.d 6.3.4 Software
Verification Results 11.14
5 Source Code is traceable to low-level requirements.
6.3.4.e 6.3.4 Software
Verification Results 11.14
6 Source Code is accurate and consistent.
6.3.4.f 6.3.4 Software
Verification Results 11.14
7 Output of software integration process is complete and correct.
6.3.5,a 6.3.5 Software
Verification Results 11.14
8 Parameter Data Item File is correct and complete
6.6.a 6.6
Software
Verification Cases
and Procedures
11.13
Software
Verification Results 11.14
9 Verification of Parameter Data Item File is achieved.
6.6.b 6.6 Software
Verification Results 11.14
PAC45T Audio
Controller RTCA DO-178C
Plan for Software
Aspects of Certification
Document: 002-145-1780
Date: 11/26/2018
Revision: New
This document last printed 3/5/2019 4:21:00 PM
Page 34 of 38 PS Engineering Proprietary
Table A-6 Testing of Outputs of Integration Process
Objective Output
Description Ref Data Item Ref Document
1 Executable Object Code complies with high-level requirements.
6.4.2 Software Verification Cases and Procedures Software Verification Results
11.13
002
-145
-24
56
Re
quir
em
ents
Matr
ices
002
-145
-25
45
Desig
n V
erificatio
n T
ests
6.4.2.1
6.4.3 11.14
6.5 Trace Data 11.21
2 Executable Object Code is robust with high-level requirements.
6.4.2 Software Verification Cases and Procedures Software Verification Results
11.13 6.4.2.2
6.4.3 11.14
6.5 Trace Data 11.21
3 Executable Object Code complies with low-level requirements.
6.4.2 Software Verification Cases and Procedures Software Verification Results
11.13 6.4.2.1
6.4.3 11.14
6.5 Trace Data 11.21
4 Executable Object Code is robust with low-level requirements.
6.4.2 Software Verification Cases and Procedures Software Verification Results
11.13 6.4.2.2
6.4.3 11.14
6.5 Trace Data 11.21
5 Executable Object Code is compatible with target computer.
6.4.1.a Software Verification Cases and Procedures
11.13
6.4.3.a Software Verification Results 11.14
PAC45T Audio
Controller RTCA DO-178C
Plan for Software
Aspects of Certification
Document: 002-145-1780
Date: 11/26/2018
Revision: New
This document last printed 3/5/2019 4:21:00 PM
Page 35 of 38 PS Engineering Proprietary
Table A-7 Verification of Verification Process Results
Objective Output
1 Description Ref Ref Data Item Ref Document
Test procedures are correct.
6.4.5.b 6.4.5 Software Verification Results
11.14
002
-145
-24
56
Re
quir
em
ents
Matr
ices
002
-145
-25
45
Desig
n V
erificatio
n T
ests
2 Test results are correct and discrepancies explained.
6.4.5.c 6.4.5 Software Verification Results
11.14
3 Test coverage of high-level requirements is achieved.
6.4.4.a 6.4.4.1 Software Verification Results
11.14
4 Test coverage of low-level requirements is achieved.
6.4.4.b 6.4.4.1 Software Verification Results
11.14
5
Test coverage of software structure (modified condition/decision coverage) is achieved.
6.4.4.c
Software Verification
Results 11.14
6.4.4.2.a
6.4.4.2.b
6.4.4.2.d
6.4.4.3
6 Test coverage of software structure (decision coverage) is achieved.
6.4.4.c
6.4.4.2.a Software Verification Results
11.14 6.4.4.2.b
6.4.4.2.d
6.4.4.3
7 Test coverage of software structure (statement coverage) is achieved.
6.4.4.c
6.4.4.2.a Software
Verification Results
11.14 6.4.4.2.b
6.4.4.2.d
6.4.4.3
8
Test coverage of software structure (data coupling and control coupling) is achieved.
6.4.4.d
6.4.4.2.c Software
Verification Results
11.14 6.4.4.2.d
6.4.4.3
9
Verification of additional code that cannot be traced to Source Code is achieved.
6.4.4.c 6.4.4.2.b Software
Verification Results
11.14
PAC45T Audio
Controller RTCA DO-178C
Plan for Software
Aspects of Certification
Document: 002-145-1780
Date: 11/26/2018
Revision: New
This document last printed 3/5/2019 4:21:00 PM
Page 36 of 38 PS Engineering Proprietary
Table A-8 Software Configuration Management Process
Objective Output Ref Doc.
Description Ref Ref Data Item Ref
1 Configuration items are identified. 7.1.a 7.2.1 SCM Records 11.18 Software Configuration
002-045-1785
2 Baselines and traceability are established. 7.1.b 7.2.2
Software Configuration Index
11.16 Software Configuration
002-045-1785
SCM Records 11.18
3 Problem reporting, change control, change review, and configuration status accounting are established.
7.1.c 7.2.3
Problem Reports 11.17 NONE OPEN 7.1.d 7.2.4
7.1.e 7.2.5 SCM Records 11.18
SW Config Index 002-145-1000
7.1.f 7.2.6
4 Archive, retrieval, and release are established.
7.1.g 7.2.7 SCM Records 11.18 SW Config Index 002-
145-1000
5 Software load control is established.
7.1.h 7.4 SCM Records 11.18 SW Config Index 002-
145-1000
6 Software life cycle environment control is established. 7.1.i 7.5
Software Life Cycle Environment Configuration Index
11.15
SW Config Index 002-145-1000
SCM Records 11.18
PAC45T Audio
Controller RTCA DO-178C
Plan for Software
Aspects of Certification
Document: 002-145-1780
Date: 11/26/2018
Revision: New
This document last printed 3/5/2019 4:21:00 PM
Page 37 of 38 PS Engineering Proprietary
Table A-9 Software Quality Assurance Process
Objective Output
Description Ref Ref Data Item Ref Ref Docs
1
Assurance is obtained that software plans and standards are developed and reviewed for compliance with DO-178C, and for consistency.
8.1.a
SQA Records 11.19
002
-145
-17
84
Softw
are
Accom
plis
hm
ent S
um
mary
and
002
-145
-25
45
Desig
n V
erificatio
n T
esting
8.2.b 8.2.h
8.2.i
2 Assurance is obtained that software life cycle processes comply with approved software plans.
8.1.b
8.2.a
SQA Records 11.19
8.2.c
8.2.d
8.2.f
8.2.h
8.2.i
3
Assurance is obtained that software life cycle processes comply with approved software standards.
8.1.b
B.2.a
SQA Records 11.19
B.2.c
B.2.d
B.2.f
8.2.h
B.2.i
4 Assurance is obtained that transition criteria for the software life cycle processes are satisfied.
8.1.c
8.2.e
SQA Records 11.19 B.2.h
B.2.i
5 Assurance is obtained that software conformity review is conducted.
8.2·9
SQA Records 11.19 8.1.d
8.2.h
8.3
PAC45T Audio
Controller RTCA DO-178C
Plan for Software
Aspects of Certification
Document: 002-145-1780
Date: 11/26/2018
Revision: New
This document last printed 3/5/2019 4:21:00 PM
Page 38 of 38 PS Engineering Proprietary
Table A-10 Certification Liaison Process
Objective Activity Output Ref. Doc
Description Ref Ref Data Item Ref
1
Communication and understanding between the applicant and the certification authority is established.
9.a
9.1.b Plan for Software Aspects of Certification
11.1 002-145-1780 §5.1.6 9.1.c
2
The means of compliance is proposed and agreement with the Plan for Software Aspects of Certification is obtained.
9.b
9.1.a
Plan for Software Aspects of Certification
11.1 002-145-1780 §5.1.6
9.1.b
9.1.c
3 Compliance substantiation is provided. 9.c
9.2.a Software Accomplishment Summary
11.20 002-145-1784
§5.1.6
9.2.b
11.16 002-022-0000 9.2.c
Software Configuration Index