SOFTWARE ACCOMPLISHMENT SUMMARY · 2019. 4. 18. · 5.1.3 Software Verification Process (DO-178C...

SOFTWARE ACCOMPLISHMENT SUMMARY

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/09/2018 Preliminary

1 Picou/Campbell 2/26/2019 Release for TSO Submittal

PAC45T

RTCA DO-178C

Software

Accomplishment

Summary

Document: 002-145-1784

Date: 2/26/2019

Revision: 1

PS Engineering Proprietary Document of 12 Written by Gary Picou, checked by Peter Campbell

TABLE OF CONTENTS

1.0 INTRODUCTION ........................................................................................................................... 5 1.1 Scope.......................................................................................................................................................... 5 1.2 Software Functional Summary ................................................................................................................... 5 1.3 Document Overview ................................................................................................................................... 5 1.4 Referenced Documents .............................................................................................................................. 5 1.4.1 Industry & regulatory documents .............................................................................................................. 5 1.4.2 PS Engineering available references and associated documents .............................................................. 6 1.5 Definitions .................................................................................................................................................. 6 1.6 Acronyms ................................................................................................................................................... 6 1.7 Plans Overview ........................................................................................................................................... 7

2.0 SYSTEM OVERVIEW (§11.20(A)) ........................................................................................... 7 2.1 Requirements allocated to hardware and software ................................................................................... 7 2.1.1 Non-complex hardware functions ............................................................................................................. 8 2.1.2 Hardware functions allocated to programmable logic devices ................................................................. 8 2.1.3 Software functions ..................................................................................................................................... 8 2.1.4 Architecture ............................................................................................................................................... 9 2.1.5 Processors .................................................................................................................................................. 9 2.1.6 Hardware/Software Interface .................................................................................................................... 9 2.1.7 Safety Features .......................................................................................................................................... 9

3.0 SOFTWARE OVERVIEW (§11.20(B)) .................................................................................... 9 3.1 Redundancy ............................................................................................................................................. 16 3.2 Multiple-Version Dissimilar Software ....................................................................................................... 16 3.3 Resource Sharing ...................................................................................................................................... 16 3.4 Fault Tolerance ......................................................................................................................................... 16 3.5 Failure Probability for Software related items. ......................................................................................... 16 3.5.1 Single Event Upsets .................................................................................................................................. 16 3.5.2 Timing considerations .............................................................................................................................. 16 3.5.3 Loss of Function (availability) and Loss of Integrity (Incorrect Operation) .............................................. 17

4.0 CERTIFICATION CONSIDERATIONS (§11.20(C)) ............................................................ 17 4.1 Certification Basis ..................................................................................................................................... 17 4.1.1 Means of Compliance .............................................................................................................................. 17 4.2 Software Design Assurance Level C .......................................................................................................... 17 4.3 System Safety Assessment ....................................................................................................................... 17 4.3.1 Software contributions to failure conditions ........................................................................................... 18

5.0 SOFTWARE LIFE CYCLE (§11.20(D)) .................................................................................. 18 5.1 Summary of life cycle processes ............................................................................................................... 19 5.1.1 Software Planning Process (DO-178C §4.0) ............................................................................................. 20 5.1.2 Software Development Process (DO-178C §5.0) ..................................................................................... 20 5.1.2.1 Software Requirements Process (DO-178C §5.1) ................................................................................ 20 5.1.2.2 Software Design Process (DO-178C §5.2) ............................................................................................ 20 5.1.2.3 Software Coding Process (DO-178C §5.3) ............................................................................................ 20 5.1.2.4 Integration Process (DO-178C §5.4) .................................................................................................... 20 5.1.3 Software Verification Process (DO-178C §6.0) ........................................................................................ 20 5.1.4 Software Configuration Management Process (DO-178C §7.0) .............................................................. 20 5.1.5 Software Quality Assurance Process (DO-178C §8.0) .............................................................................. 21 5.1.6 Certification Liaison Process (DO-178C §9.0) .......................................................................................... 21

PAC45T

RTCA DO-178C

Software

Accomplishment

Summary

Document: 002-145-1784

Date: 2/26/2019

Revision: 1


6.0 SOFTWARE LIFE CYCLE DATA (§11.20(E)) ...................................................................... 23

7.0 ADDITIONAL CONSIDERATIONS (§11.20(F)).................................................................. 23

8.0 SUPPLIER OVERSIGHT (§11.20(G)) .................................................................................... 23

9.0 SOFTWARE IDENTIFICATION (§11.20(H)) ...................................................................... 23

10.0 SOFTWARE CHARACTERISTICS (§11.20(I)) ................................................................ 24 10.1 DSP Memory and Executable Object Code Size and margins .................................................................... 24 10.2 PIC allocation and memory ....................................................................................................................... 24 10.3 DSP Timing ............................................................................................................................................... 25

11.0 CHANGE HISTORY (§11.20(J)) .......................................................................................... 25

12.0 SOFTWARE STATUS (11.20(K)) ....................................................................................... 26

13.0 COMPLIANCE STATEMENT (§11.20(L)) ........................................................................ 26

14.0 SOFTWARE VERIFICATION ................................................................................................ 26 14.1 Independence .......................................................................................................................................... 26 14.2 Verification Methods ................................................................................................................................ 26 14.2.1 Review Methods ...................................................................................................................................... 26 14.2.2 Analysis Methods ..................................................................................................................................... 26 14.2.3 Testing Methods ...................................................................................................................................... 27 14.3 Verification Environment ......................................................................................................................... 27 14.4 Reverification methods ............................................................................................................................ 27

15.0 VERIFICATION RESULTS ..................................................................................................... 27 15.1 Filter design .............................................................................................................................................. 27

16.0 COMPLIANCE MATRICES..................................................................................................... 28

PAC45T

RTCA DO-178C

Software

Accomplishment

Summary

Document: 002-145-1784

Date: 2/26/2019

Revision: 1


Table of Figures

FIGURE 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-4 DIGITAL SIGNAL PROCESSOR ARCHITECTURE DIAGRAM .......................................................................... 14 FIGURE 4-1 INTERCOM FAILURE CONDITION .............................................................................................................. 18 FIGURE 5-1 SOFTWARE LIFECYCLE OVERVIEW ............................................................................................................ 19 FIGURE 5-2 SOFTWARE CERTIFICATION DOCUMENT FLOW DOWN ........................................................................... 22 FIGURE 9– DSP TIMING MEASUREMENT ..................................................................................................................... 25

PAC45T

RTCA DO-178C

Software

Accomplishment

Summary

Document: 002-145-1784

Date: 2/26/2019

Revision: 1


1.0 Introduction

1.1 Scope

This document fulfills the intent of the Software Accomplishment Summary (DO-178C §11.20) data items for the

specific PAC45T Audio Control Panel applied to the T-1A Jayhawk avionics upgrade.

This is the primary data item for showing compliance with the Plan for Software Aspects of certification (Document

002-145-1780) and the software development verification activity processes used to satisfy the process objectives

within the development lifecycle.

1.2 Software Functional Summary

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.

1.3 Document Overview

This document provides an overview of verification processes accomplished on the article.

1.4 Referenced Documents

This section references the documents used to develop these plans.

1.4.1 Industry & regulatory documents

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 21.1309-1E System Safety Analysis and assessment for Part 23 Airplanes November17, 2011

AC25.1309-1A System Design and Analysis June 21, 1988

AC 20-148 Reusable Software Components December 7, 2004

TSO C139a Audio Systems and Equipment February 25, 2012

AS9100:C Quality Management System – Requirements for Aviation, Space

and Defense Organizations January 2009

AS9006A Deliverable Aerospace Software Supplement for AS9100 July 2013

ISO10007 Quality Management Systems – Guidelines for configuration

Management June 2003

PAC45T

RTCA DO-178C

Software

Accomplishment

Summary

Document: 002-145-1784

Date: 2/26/2019

Revision: 1


1.4.2 PS Engineering available references and associated documents

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

Software Quality Assurance Plan 002-920-1786 1 2/2/2014

Software Configuration Management

Document PAC45T

002-145-1000 New 11/18/2013

1.5 Definitions

Table 1 Definitions

Word/Phrase Definition

IntelliVox® Proprietary protocol for controlling a voice-activated intercom system

Fail-Safe Reversionary mode- flight crew is connected to communication radios (COM 1,

COM 2, Alert Audio Source, etc.) when the unit is turned off.

1.6 Acronyms

Acronym Definition

HW Hardware

HP Headphone Audio

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

SDP/SVP Software Development and Verification Plan

QMS Quality Management System

SAS Software Accomplishment Summary

PAC45T

RTCA DO-178C

Software

Accomplishment

Summary

Document: 002-145-1784

Date: 2/26/2019

Revision: 1


Acronym Definition

SCM Software Configuration Management

SDP Software Development and Verification Plan

SQA Software Quality Assurance

SVP Software Verification Plan

SW Software

VOX Voice Activated Relay (Intercom Squelch)

Table 2 Acronyms

1.7 Plans Overview

The Software Development Plan Document 002-145-1783, detailed the steps taken during development of the

PAC45T, with respect to the creation of software code and the requirements.

This Software Verification Plan section details how PS Engineering satisfy the verification process objectives,

including independence, verification test methods, environment, transitions criteria, and other considerations.

2.0 System Overview (§11.20(a))

The IntelliAudio® is an application of DSP at PS Engineering in a certified article. This is part of a Reusable

Software Component (RSC) that is integrated into designs for intercom and audio control systems.

The primary software component used in the system: a Texas Instruments Digital Signal Processor (DSP) that is

responsible for all tasks related to manipulation of the intercom and radio audio, as well as gating the audio when

there is no intelligible signal present.

There are also three PIC microcontrollers (μC), one in the CTL45T Control Head, and two in the HUB45R. One of

these is dedicated to the independent audio alert tone generator subsystem.

Item System Requirement Allocated to

1. Allow selection of radio audio to be routed to crew and/or

passenger headsets as desired

SW

2. Selection of intercom mode to allow intercommunication

between crew and passengers

SW

3. Voice detection/intercom squelch open HW

Table 2-1 System Requirements allocated DSP Software

2.1 Requirements allocated to hardware and software

Figure 1- System Block Diagram PAC45T -

The RSC is completely contained in software. However, this section is included to relate the peripheral hardware

required for the IntelliAudio® to perform the required functions.

See PAC45T Requirements Matrix 002-045-0178.

PAC45T

RTCA DO-178C

Software

Accomplishment

Summary

Document: 002-145-1784

Date: 2/26/2019

Revision: 1


2.1.1 Non-complex hardware functions

The functions associated with simple electronic hardware are:

Microphone inputs, radio inputs, music inputs, headphone outputs, speaker and line –level audio 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).

Music Input: 1.5Vrms (4.2Vpp). Attenuated prior to CODEC for 2Vpp. Not processed in DSP (not enabled in

PAC45T)

Headphone Outputs: 3.9Vrms (11Vpp). Gain applied at headphone amplifiers to account for 2Vpp max from

CODECs.

Speaker Outputs: 6 Vrms (x2)

Line Level outputs to drive external speaker amplifiers: 500 mVrms

Each crew headphone channel (Left and right) has a dedicated headphone amp (pilot, copilot, observer 1). Passenger

headphones are driven in pairs form dedicated headphone amps (passenger 1, observer 2) (passenger 2, passenger 3)

(passenger 4, passenger 5).

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.

2.1.2 Hardware functions allocated to programmable logic devices

These generic control functions are allocated to Field Programmable Gate Arrays (FPGA).

Functions allocated to the FPGAs include:

System health & reset functions

PTT and VOX monitoring

Digital audio routing, mixing, and volume control.

2.1.3 Software functions

These generic control functions are allocated in software.

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

PAC45T

RTCA DO-178C

Software

Accomplishment

Summary

Document: 002-145-1784

Date: 2/26/2019

Revision: 1


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 IntelliAudio 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 IntelliAudio API.

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.

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.20(b))

There are 4 separate software components that work together in the PAC45T:

PAC45T

RTCA DO-178C

Software

Accomplishment

Summary

Document: 002-145-1784

Date: 2/26/2019

Revision: 1


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.

3.1 Redundancy

Not Applicable. There are no redundant functions allocated in the software. The PAC45T utilizes a 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 IntelliAudio® uses a power off, Fail-Safe system to ensure air to ground

communications in the event of anomalous operation. The 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.

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 data provided by the PIC manufacturer (microchip), the probability of a failure within the μC is

3.64x10-8, 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.

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:

PAC45T

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

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)

4.0 Certification Considerations (§11.20(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

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 D, but designed and verified to Level C at the request of the

customer.

The Failure Condition Category is No Effect, because of the fail-safe nature of the equipment; any anomalous

behavior can be remedied by turning the 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 on Civil Airborne Systems and Equipment and AC25.1309-1A. This

document is PAC45T Functional Hazard Assessment 002-145-1309.

PAC45T

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

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

In the event of a processor or a CPU failure, the intercom and or IntelliAudio® 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.20(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

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

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

5.1 Summary of life cycle processes

This section defines and summarizes the life cycle processes to be used for the IntelliAudio, and includes

information on the specific objectives and organizations involved. Details are contained in relevant sections and

other documents.

PAC45T

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

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

045-5495-1213) created by the company, collaboration between sale/marketing, production, quality (certification),

and engineering. The process output is a Requirements Document/Matrix, 002-145-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.

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.

PAC45T

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

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

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

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

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

6.0 Software Life Cycle Data (§11.20(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.

There are no changes from the PSAC.

7.0 Additional Considerations (§11.20(f))

There are no additional considerations changes since the PSAC.

8.0 Supplier Oversight (§11.20(g))

PS Engineering uses COTS components procured from approved suppliers under our FAA-approved manufacturing

system, which is also consistent with AS9100:C.

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.

9.0 Software Identification (§11.20(h))

PS Engineering uses a 10-digit part number, with a prefix that indicates the type of, the middle three indicate either a

unit or the target of the part number, and the last four have details of the specific component value. In addition, some

drawings and documents can have a revision number or letter trailing.

See document 002-145-1785, Configuration Index for current information.

In the case of Micro Coded devices, (Software and CEH) there are several points of configuration control applied,

which may be revised independently.

Article Microprocessor FPGA

(ref. DO-254)

PIC µController

(ref. DO-254)

Part Number Part Number Part Number Revision Identification

Raw

component

526-144-5509 926-028-1790 526-044-3364- None (discrete part

number)

Manufacturer

Part Number

TMS320C5509APGE A3P060-QV100 dsPIC33FJ64MC804-IPT None (discrete part

number

Code part

number

920-003-0011 910-068-0001 910-069-0001 Last 4 digits of part

number

PAC45T

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

Configuration

Management

Document

(CMD)

920-003-1000_Rev A 002-068-0000

RevA

002-069-0000_RevA Document remains at

0000, Revision Letter

appended

Table 2 - Software Configuration example

The configuration of the PAC45T can be determined by a serial tag label:

FPGA – A

PIC – A

DSP– A

The configuration identification is ties to the stored code under Version Control, and the number identifies that

specific code version.

Baseline release to production is AAAAA.

10.0 Software characteristics (§11.20(i))

10.1 DSP Memory and Executable Object Code Size and margins

Total memory Available: 196K words of SARAM , 64K words of DARAM

Program CODE

Code Sections:

SARAM0 3900/16384 23%

SARAM1 25221/180000 13%

Total Code Space Used: 29121/196000 15%

Data Space:

Data Sections:

DARAM0 6672/7680 86%

DARAM1 2018/20480 9%

DARAM2 224/8192 2%

DARAM3 5592/28672 19%

Total Data Space Used: 14506/65024 22%

10.2 PIC allocation and memory

1. Allocation of memory address fields into which data can be loaded.

a. Main PIC:

i. Program Memory: 75%

ii. Data Memory: 86%

b. Alert PIC:

i. Program Memory: 9%

ii. Data Memory: 17%

PAC45T

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

10.3 DSP Timing

16 KHz Audio Frame Pulses

X 4 = AUDIO BLOCK

250 uS

DSP Audio Processing Time

82.6 uS

Audio Buffer Full start DMA Transfer

DMA Transfer Complete

Flag Audio Ready to ProcessAudio Process IDLE Time

168 uS

82.6 uS / 250 uS = 33 %

DSP Audio Processing Takes 33 %

of Allowed Execution Time

Figure 3– DSP Timing measurement

Timing within the DSP is based on the audio sample rate. The processor takes four samples per audio block; each

audio block can be up to 250 µSeconds long to process all the audio. However the processing time needed for the

four blocks is 82.6 µS, or 33% of the allowed time.

11.0 Change History (§11.20(j))

Since the design began and PSAC was created, the following issues have been addressed.

1. Number of times alerts are repeated in failsafe changed from 4 to 3 (Mantis: 0000034).

2. Changed alerts power up lock out time from 5 to 30 seconds.

3. Added support to Call chime playing during alerts.

4. Alert modifications:

a. Stop playing edge alert immediately on de-assertion (as opposed to when a .wav file finishes).

b. Start playing any "New" alert immediately on assertion (as opposed to when a previous .wav file

finishes).

c. Added priority order if multiple alerts are asserted on same alert sample cycle (priority is alert

order 1-9).

d. Added bit to Main PIC / Alert PIC protocol to notify main PIC when Alert7 or Alert 10 (Seat belt

alerts) plays next.

e. Added priority order if multiple alerts are asserted on same alert sample cycle (Alert priority

order: 8,4,5,3,9,2,6,1,7).

f. Added round robin order for multiple continuous alerts to match Nextant priority order.

g. Added Alert7 Alternate Mode. New mode plays one message on alert7 assertion and another on

de-assertion. Also only plays messages once (no repeat).

PAC45T

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

h. More refinements to the way alerts operation in failsafe and in general after various power up

conditions.

5. Flipped configuration switch polarity to account for inverted PCB

No changes were made during the development and testing process that were related to any safety issues. Initial

analysis indicated that the DSP would introduce exceptions into RTCA DO-214A, however, the design was refined

and no exception is needed at this time for the audio panel function.

12.0 Software Status (11.20(k))

There are no open problem reports with the Software used in the PAC45T.

13.0 Compliance statement (§11.20(l))

PS Engineering certifies that the software contained in the PAC45T, is in compliance with the relevant portions of

RTCA DO-178C, for the design Assurance Level of C.

PS Engineering has followed the processes stated in the applicable plans, used industry and company standards to

create software code to meet the requirements stated in the associated documents, and tested the output of the

process to demonstrate compliance with the requirements.

14.0 Software Verification

This Software Verification Report section details how PS Engineering satisfied the verification process objectives,

including independence, verification test methods, environment, transitions criteria, and other considerations.

14.1 Independence

Level C does not require full independence, but PS Engineering has a “second set of eyes” on software verification

activities that involves a person other than the developer verify the code and requirements, and review of the

verification to the requirements by production test and quality managers. The person who creates the source code is

not the same person who creates the test cases.

14.2 Verification Methods

The fundamental verification method is a complete system test. All of the functions can be deterministically verified

by applying known stimulus in the form of audio signals and user actions, and verifying that the output signals

behave as expected.

Testing the audio outputs in accordance with RTCA DO-214A will verify that the audio is processed properly.

The audio routing and combinations that follow the modes is easily verified by listening.

Robustness and boundary testing is accomplished by stimulating the system with excess audio signals. Spatial audio

can be verified by listening to audio sources which will appear in the stereo headset at a specified azimuth from the

listener.

14.2.1 Review Methods

Code review is accomplished by desk analysis and manual review as well as reviewing the outputs of the tools, such

as PC-LINT.

14.2.2 Analysis Methods

Code analysis will be using the PC-lint static analysis tool or built in tool within a Development System; conforming

to MIRSA-2004 rules.

PAC45T

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

14.2.3 Testing Methods

Functional tests, using analog audio signal generators, oscilloscope, distortion analyzers, audio power meters; all the

same test equipment that has been previously used to test audio systems without any airborne software. The only

testing difference will be the addition of the spatial component, which can be tested adequately by a person with

normal hearing.

14.3 Verification Environment

Verification of the code is based upon the ability to stimulate all of the inputs, select all modes and inputs and

achieve the expected output for any combination of the functional requirements. This is accomplished using signal

sources, and monitoring headphone outputs to verify correct output.

14.4 Reverification methods

Reverification after code changes is accomplished by end-to-end testing of the system to verify all requirements are

met and performance is unchanged

15.0 Verification Results

15.1 Filter design

Filter design is verified by generating filter coefficients for the desired filter, running those coefficients through a

test simulation. The output of the simulation is processed with a high resolution FFT, with the resulting Frequency

Response displayed. The filter coefficients are executed on the target hardware. The resulting frequency response is

measured. All (3) data outputs are compared.

(1) Filter Design Program (QED2000), (2) simulation, PC based ‘c’ code, (3) Real Filter in the DSP or CODEC.

As observed below, all (3) outputs match – Indicating the Design Tool produces the desired result, Test Pass

PAC45T

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

16.0 Compliance Matrices

PAC45T

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

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

PAC45T

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

4.2.h SDP 11.2 002-145-1783

§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

PAC45T

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

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

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,

5.2.1.b 5.2.2.b Design

Description 11.10

002-145-2546

§1.0

PAC45T

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

including the

system safety assessment process. 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

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

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


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


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


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


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

PAC45T

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

DVT

PAC45T

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

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


002-145-1782

Verification test

Results



Software


002-145-1782

Verification test

Results


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


traceable to high-level

requirements. 6.3.2.f 6.3.2

Software


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


Software


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

PAC45T

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

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

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

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


00

2-1

45

-24

56

Req

uir

emen

ts M

atri

ces

00

2-1

45

-25

45

Des

ign

Ver

ific

atio

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


PAC45T

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

9

Verification of

Parameter Data

Item File is

achieved.

6.6.b 6.6 Software


PAC45T

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

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

00

2-1

45

-24

56

Req

uir

emen

ts M

atri

ces

00

2-1

45

-25

45

Des

ign

Ver

ific

atio

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

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

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

00

2-1

45

-24

56

Req

uir

emen

ts M

atri

ces

00

2-1

45

-25

45

Des

ign

Ver

ific

atio

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


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

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

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

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

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

00

2-1

45

-17

84

So

ftw

are

Acc

om

pli

shm

ent

Su

mm

ary

an

d

00

2-1

45

-25

45

Des

ign

Ver

ific

atio

n T

esti

ng

8.2.b 8.2.h 8.2.i

2


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


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


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


that software

conformity review is

conducted.

8.2·9

SQA Records 11.19 8.1.d

8.2.h

8.3

PAC45T

RTCA DO-178C


Document: 002-145-1784

Date: 2/26/2019

Revision: 1

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

SOFTWARE ACCOMPLISHMENT SUMMARY · 2019. 4. 18. · 5.1.3 Software Verification Process (DO-178C...

Documents

Transcript of SOFTWARE ACCOMPLISHMENT SUMMARY · 2019. 4. 18. · 5.1.3 Software Verification Process (DO-178C...