PLAN FOR SOFTWARE ASPECTS OF CERTIFICATION · 7, 2004, with the exception that PS Engineering will...

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 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


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


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


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


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


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


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


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


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


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


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


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


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

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


Plan for Software


Document: 002-145-1780

Date: 11/26/2018

Revision: New



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


Plan for Software


Document: 002-145-1780

Date: 11/26/2018

Revision: New



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


Plan for Software


Document: 002-145-1780

Date: 11/26/2018

Revision: New



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


Plan for Software


Document: 002-145-1780

Date: 11/26/2018

Revision: New



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


Plan for Software


Document: 002-145-1780

Date: 11/26/2018

Revision: New



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


Plan for Software


Document: 002-145-1780

Date: 11/26/2018

Revision: New



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


Plan for Software


Document: 002-145-1780

Date: 11/26/2018

Revision: New



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


Plan for Software


Document: 002-145-1780

Date: 11/26/2018

Revision: New



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


Plan for Software


Document: 002-145-1780

Date: 11/26/2018

Revision: New



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


Plan for Software


Document: 002-145-1780

Date: 11/26/2018

Revision: New



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


Plan for Software


Document: 002-145-1780

Date: 11/26/2018

Revision: New



§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.


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


Plan for Software


Document: 002-145-1780

Date: 11/26/2018

Revision: New



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


Plan for Software


Document: 002-145-1780

Date: 11/26/2018

Revision: New



Table A-3 Verification of Outputs of Software Requirements Process.

Objective

Activity Output

REF DOC.


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


Plan for Software


Document: 002-145-1780

Date: 11/26/2018

Revision: New



Table A-4 Verification of Outputs of Software Design Process

Objective

Activity Output

Ref. Doc


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


3 Low-level requirements are compatible with target computer. 6.3.2.c 6.3.2 Software Verification

Results 11.14 002-145-1782


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


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


7 Algorithms are accurate. 6.3.2·9 6.3.2 Software Verification Results 11.14


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


9 Software architecture is consistent. 6.3.3.b 6.3.3 Software Verification Results 11.14


Results

10 Software architecture is compatible with target computer. 6.3.3.c 6.3.3 Software Verification

Results 11.14 002-145-1782


11 Software architecture is verifiable. 6.3.3.d 6.3.3 Software Verification Results 11.14


Results

12 Software architecture conforms to standards. 6.3.3.e 6.3.3 Software Verification Results 11.14


Results

13 Software partitioning integrity is confirmed. 6.3.3.f 6.3.3 Software Verification Results 11.14


Results

PAC45T Audio


Plan for Software


Document: 002-145-1780

Date: 11/26/2018

Revision: New



PAC45T Audio


Plan for Software


Document: 002-145-1780

Date: 11/26/2018

Revision: New



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


3 Source Code is verifiable.

6.3.4.c 6.3.4 Software


4 Source Code conforms to standards.

6.3.4.d 6.3.4 Software


5 Source Code is traceable to low-level requirements.

6.3.4.e 6.3.4 Software


6 Source Code is accurate and consistent.

6.3.4.f 6.3.4 Software


7 Output of software integration process is complete and correct.

6.3.5,a 6.3.5 Software


8 Parameter Data Item File is correct and complete

6.6.a 6.6

Software

Verification Cases

and Procedures

11.13

Software


9 Verification of Parameter Data Item File is achieved.

6.6.b 6.6 Software


PAC45T Audio


Plan for Software


Document: 002-145-1780

Date: 11/26/2018

Revision: New



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.


11.13 6.4.2.2

6.4.3 11.14


3 Executable Object Code complies with low-level requirements.


11.13 6.4.2.1

6.4.3 11.14


4 Executable Object Code is robust with low-level requirements.


11.13 6.4.2.2

6.4.3 11.14


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


Plan for Software


Document: 002-145-1780

Date: 11/26/2018

Revision: New



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


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


11.14

PAC45T Audio


Plan for Software


Document: 002-145-1780

Date: 11/26/2018

Revision: New



Table A-8 Software Configuration Management Process

Objective Output Ref Doc.


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


Plan for Software


Document: 002-145-1780

Date: 11/26/2018

Revision: New



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


Plan for Software


Document: 002-145-1780

Date: 11/26/2018

Revision: New



Table A-10 Certification Liaison Process

Objective Activity Output Ref. Doc


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

PLAN FOR SOFTWARE ASPECTS OF CERTIFICATION · 7, 2004, with the exception that PS Engineering will...

Documents

Transcript of PLAN FOR SOFTWARE ASPECTS OF CERTIFICATION · 7, 2004, with the exception that PS Engineering will...