6. CERTIFICATION COST ESTIMATES
6.1 Generic Avionics Transceiver
6.1.2 Development Work Breakdown Structure
It is assumed the transceiver can be implemented on a single board hosted in a standard ARINC 600 form factor for commercial air transport avionics. The
whole unit is likely to be at least 3MCU wide seen power dissipation limits and power amplifier efficiencies.
This board will provide a) the power supply, b) the RF module and c) the baseband module as well as the IP stack as an interface to user applications.
Hence, development of the transceiver will encompass system, hardware, software and mechanical engineering activities, all of which taking into account certification aspects at their respective level. Indeed, certification is not an “additional” task performed at the very end of the development of an avionics system. The effort (and level of effort depending on the determined safety level) is spread all the way through the different development activities.
The following table lists major activities to be undertaken during the
development of an airborne transceiver, and identify differences between a level D and a level A development.
Activities and tasks Outputs Comments 1 Capture Originating Requirements
1.1 Capture Source Requirements 1.2 Define Constraining Requirements
1.3 Trace Constraining Requirements to Source
1.4 Perform Configuration Control, Reviews and Change
Control Review minutes, change
requests 2 Define System, Manufacturing and Support
Requirements
2.1 Develop Build and Test Plan Strategy
2.2 Define Manufacturing Test and Support Requirements 2.3 Define Product Key Characteristics
2.4 Define System Requirements System requirements and critical
performance measures 2.5 Trace System Requirements to Higher Level Requirements
2.6 Perform Functional Hazard Assessment FHA
2.7 Define Certification Basis Certification basis, system
criticality level 2.8 Perform Preliminary System Safety Assessment PSSA
2.9 Perform Configuration Control, Reviews (incl. SyRR) and
Change Control Review minutes, change
requests 3 Design System
3.1 Define System Architecture System architecture
3.2 Identify System Elements
3.3 Define Interfaces between the System Elements Interface definition 3.4 Identify Key Inputs and Outputs
3.5 Allocate System Requirements to Sub-System, Hardware,
Software, Installation and ASIC13 System requirement allocation, System design
3.6 Trace System Requirements to System Architecture 3.7 Perform Configuration Control, Reviews (incl. SDR) and
Change Control Review minutes, change
requests 4 Define Hardware Requirements
4.1 Develop Hardware Requirements Hardware Requirements
4.2 Address Certification Issues
4.3 Perform Configuration Control, Reviews and Change Control
Review minutes, change requests
5 Develop Preliminary Hardware Design
5.1 Perform Functional Analysis and Trade-Off Studies Analysis and performance test plans
5.2 Allocate Hardware Requirements ASIC and FPGA requirements
5.3 Develop Hardware Architecture Design
5.4 Trace Hardware Requirements to Preliminary Design 5.5 Address Certification Issues
5.6 Document Preliminary Design
5.7 Perform Configuration Control, Reviews (incl. HPDR) and
Change Control Review minutes, change
requests 6 Develop Detailed Hardware Design
13Activity 3.5 “Allocate System Requirements to Sub-Systems, Hardware, Software, Installation and ASIC would be the starting point of the different architectures considered within the study, i.e. allocate most features to software in the SDR case, or allocate most features to hardware in the COTS chipsets case.
Activities and tasks Outputs Comments 6.1 Perform Hardware Design Synthesis and Analysis EMI/EMC analysis, hardware
environment analysis, hardware functional and design analysis, hardware reliability and maintainability analysis 6.2 Develop Test Procedures
6.3 Create Hardware/Software Interface Document
6.4 Address Certification Issues FFPA and Fault Tree analysis
6.5 Perform Configuration Control, Reviews (incl. HCDR) and
Change Control Review minutes, change
requests 7 Build Test Hardware and Software
7.1 Procure Test Hardware and Software 7.2 Confirm Prototype Build Readiness
7.3 Build Prototype Hardware and Special Test Equipment Assembled prototype hardware, prequalification test equipment 7.4 Perform Configuration Control, Reviews and Change
Control
Review minutes, change requests
8 Integrate, Test and Evaluate Hardware
8.1 Setup and Perform Integration Tests Verified hardware 8.2 Evaluate Integration Test results
8.3 Address Certification Issues Hardware accomplishment
summary (HAS) 8.4 Perform Configuration Control, Reviews (incl. HTRR) and
Change Control Review minutes, change
requests 9 Define Software Requirements
9.1 Define Software Requirements
9.2 Trace Software Requirements to Higher Level Requirements
9.3 Perform Configuration Control, Reviews (incl. SRR) and Change Control
Review minutes, change requests
10 Design Software Architecture 10.1 Define Software Architectural Design 10.2 Perform Trade-Off Studies
10.3 Allocate Software Requirements to the Software Architectural Design
10.4 Perform Configuration Control, Reviews (incl. SPDR) and
Change Control Review minutes, change
requests 11 Develop Software Detailed Design
11.1 Develop Software Detailed Design
11.2 Trace Software Requirements to Software Detailed Design 11.3 Perform Configuration Control, Reviews (incl. SCDR) and
Change Control Review minutes, change
requests 12 Implement Software Elements
12.1 Implement Software Elements
12.2 Trace Software Design to Software Elements 12.3 Perform Configuration Control, Reviews and Change
Control
Review minutes, change requests
13 Integrate Software Elements 13.1 Define Software Integration Plan 13.2 Develop Build Procedure 13.3 Integrate the Software Elements 13.4 Verify Basic Functionality
13.5 Perform Configuration Control, Reviews and Change
Control Review minutes, change
requests
Activities and tasks Outputs Comments 14 Develop Software Verification Cases and Procedures
14.1 Identify the Verification Method
14.2 Develop Software Verification Cases and Procedures 14.3 Trace Software Requirements to Software Verification
Cases and Procedures
14.4 Perform Configuration Control, Reviews and Change
Control Review minutes, change
requests 15 Verify Software
15.1 Develop Verification Strategy
15.2 Perform Software Verification Verified software
15.3 Perform Software Analysis
15.4 Perform Structural Coverage Verification 15.5 Develop Software Verification Summary
15.6 Assemble Software Accomplishment Summary Software accomplishment summary (SAS)
15.7 Perform Configuration Control, Reviews and Change
Control Review minutes, change
requests 16 Integrate System
16.1 Integrate the System Elements and Test Basic
Functionalities Integrated system
16.2 Perform Configuration Control, Reviews and Change
Control Review minutes, change
requests 17 Verify System
17.1 Perform System Verification System verification results, verified system
17.2 Develop System Verification Summary System verification summary 17.3 Perform Configuration Control, Reviews and Change
Control Review minutes, change
requests 18 Obtain Regulatory Approval
18.1 Perform Regulatory Agency Coordination Regulatory agency approval, concurrence
18.2 Assemble Approval data Packages
18.3 Perform Configuration Control, Reviews and Change
Control Review minutes, change
requests 19 Develop System Acceptance Procedures
19.1 Develop System Acceptance Procedures
19.2 Perform Configuration Control, Reviews and Change Control
Review minutes, change requests
20 Develop System Verification Cases and Procedures
20.1 Develop System Verification Cases and Procedures System verification cases and procedures
20.2 Trace System Requirements to System Verification Cases and Procedures
20.3 Perform Configuration Control, Reviews and Change
Control Review minutes, change
requests
Table 8: Activities Undertaken for the Development of an Airborne Transceiver
As is highlighted in the table above, the major difference between a DAL D and a DAL A development is in software verification activities which include structural coverage verification (ref. activity 15.4 in table above). These tests are costly in effort, hence the larger and more complex the software, the more expensive the certification artefact production.