certification cost estimates for future communication ... cost estimates for future communication...

Edition Number: 1.1 Issue 1 Page: C-i

Certification Cost Estimates for Future Communication Radio

Platforms

NOTICE: Price indications in this document are based on information from negotiated prices. Therefore, such prices are indicative and they may not constitute a negotiation base between parties.

Edition Number : 1.1 Edition Date : 29-01-09 Status : Issue 1 Intended for : EUROCONTROL

Certification Cost Estimate for Future Communication Radio Platforms

Edition Number: 1.1 Issue 1 Page: ii

DOCUMENT CHARACTERISTICS

TITLE

Certification Cost Estimates for Future Communication Radio Platforms

Document Identifier Edition Number: 1.1

D3 Edition Date: 29-01-09 Abstract

This document presents detailed information about certification cost estimation for future communication radio platforms to be utilised for Air Traffic Control data communications beyond 2020. Certification cost estimations are provided for certification levels D to A as no failure mode and hazard analysis for the operational use of the future radios have taken place yet. The study addresses different certification aspects and respective costs for different platform options: 1. Pure COTS products 2. SDR Forum based developments (SCA) 3. FPGA based developments 4. Reprogrammable processors

Keywords Certification COTS ED-12B / DO-178B ED-14E / DO-160E ED-80 / DO-254 FPGA IEEE802.16e MAC layer Physical Layer SDR

Contact Person(s) Tel / email Unit Eric THOMAS +33 (0)5 6171 7831 Rockwell Collins France

[email protected]

ELECTRONIC SOURCE

Filename: RCF_CertCostEstimate_D3-v00.doc Host System Software Size

Windows XP Microsoft Word 2003 SP2 2295808


Edition Number: 1.1 Issue 1 Page: iii

DOCUMENT APPROVAL The following table identifies all management authorities who have successively approved the present issue of this document.

AUTHORITY NAME AND SIGNATURE DATE


Edition Number: 1.1 Issue 1 Page: iv

DOCUMENT CHANGE RECORD The following table records the complete history of the successive editions of the present document. EDITION NUMBER

EDITION DATE

INFOCENTRE REFERENCE REASON FOR CHANGE PAGES

AFFECTED

01 10-10-08 First working draft all

0.2 dd-10-08 Second working draft all

0.3 dd-11-08 Third working draft all

0.4 dd-12-08

4th working draft including: - comments from EUROCONTROL - COTS information added - MBD information added - Supplement on RTOS added

all

1.0 12-12-08

Deliverable 1 version, includes: - comments from EUROCONTROL - DO-254 additional information - COTS and Reprogrammable

solutions - Summary and Conclusion

all

1.1 29-01-09

Deliverable 3 version, includes: - comments from EUROCONTROL - Summary and Conclusion

reworked per D2 presentation

all


Edition Number: 1.1 Issue 1 Page: v

CONTENTS

DOCUMENT CHARACTERISTICS.............................................................................ii

DOCUMENT APPROVAL..........................................................................................iii

DOCUMENT CHANGE RECORD..............................................................................iv

CONTENTS.................................................................................................................v

EXECUTIVE SUMMARY............................................................................................ix

1. SCOPE..................................................................................................................1

2. APPLICABLE DOCUMENTS ...............................................................................2

3. REFERENCE DOCUMENTS ................................................................................2

4. GLOSSARY OF TERMS.......................................................................................3

5. BACKGROUND....................................................................................................5 5.1 Avionics Certification.................................................................................................................5 5.2 EUROCAE ED-12B / RTCA DO-178B Overview......................................................................7

5.2.1 Software Life Cycle Processes..........................................................................................8

5.2.2 Special Considerations......................................................................................................9 5.2.2.1 Use of Previously Developed Software...................................................................9 5.2.2.2 Upgrading a Development Baseline .......................................................................9 5.2.2.3 Tool Qualification ..................................................................................................10 5.2.2.4 Alternative Methods ..............................................................................................10

5.2.3 RTOS in Certification.......................................................................................................10

5.2.4 Breakdown of DO-178B Objectives.................................................................................11

5.2.5 EUROCAE ED-12C / RTCA DO-178C............................................................................12

5.2.6 Model-Based Development .............................................................................................13

5.2.7 Impact on certification .....................................................................................................15

5.2.8 Pros and cons..................................................................................................................16

5.2.9 Costs ...............................................................................................................................17

5.3 EUROCAE ED-80 / RTCA DO-254 Overview.........................................................................18

5.3.1 Hardware Life Cycle Processes ......................................................................................19


Edition Number: 1.1 Issue 1 Page: vi

5.3.2 Tools................................................................................................................................20

5.3.3 D0254 cost versus D0178 ...............................................................................................21

5.3.4 D0254 and COTS............................................................................................................22

5.3.5 D0254 and embedded IP ................................................................................................23

5.3.6 Conclusion on DO 254 Costs (general) ..........................................................................24

5.4 EUROCAE ED-14E / RTCA DO-160E Overview....................................................................24

5.4.1 Major ED-14E / DO-160E Activities and Artefacts ..........................................................25 5.4.1.1 Qualification Test Plan ..........................................................................................25 5.4.1.2 Qualification Test Campaign.................................................................................25 5.4.1.3 Qualification Test Report.......................................................................................25

5.5 Metrics.....................................................................................................................................26 5.6 Avionics Equipment development process life cycle ..............................................................29

5.6.1 VDLmode4 example........................................................................................................30

5.6.2 VDLmode2 example........................................................................................................30

5.7 Internal vs External DER Costs ..............................................................................................31 5.8 Security Aspects .....................................................................................................................32

5.8.1 Background .....................................................................................................................32

5.8.2 Status for Aeronautical Data Links..................................................................................33

5.8.3 Security Assurance Levels versus Development Assurance Levels ..............................33

6. CERTIFICATION COST ESTIMATES ................................................................35 6.1 Generic Avionics Transceiver .................................................................................................35

6.1.1 Functional Overview........................................................................................................35 6.1.1.1 Baseband Module .................................................................................................35 6.1.1.2 Front End Module..................................................................................................36 6.1.1.3 Other Modules and Features ................................................................................37

6.1.2 Development Work Breakdown Structure .......................................................................37

6.1.3 IEEE 802.16e Background ..............................................................................................42 6.1.3.1 IEEE802.16e Physical Layer.................................................................................42 6.1.3.2 IEEE802.16e MAC Layer ......................................................................................43

6.2 SDR-based Development .......................................................................................................45

6.2.1 Platform Overview ...........................................................................................................45 6.2.1.1 RTOS and BSP .....................................................................................................46 6.2.1.2 CORBA Middleware Layer ....................................................................................47 6.2.1.3 Core Framework ...................................................................................................47 6.2.1.4 Radio Devices .......................................................................................................47 6.2.1.5 Radio Services ......................................................................................................47

6.2.2 Certification Cost Estimates Matrix .................................................................................48


Edition Number: 1.1 Issue 1 Page: vii

6.2.2.1 Considerations ......................................................................................................48 6.2.2.2 Matrix.....................................................................................................................49

6.3 COTS Products-based Development......................................................................................53

6.3.1 COTS RF Chipsets..........................................................................................................53

6.3.2 COTS Baseband Chipsets ..............................................................................................54

6.3.3 Platform Overview ...........................................................................................................55

6.3.4 Identified issues...............................................................................................................56

6.3.5 Pros and cons..................................................................................................................57


6.3.7 Alternative COTS Platform Overview..............................................................................59

6.4 FPGA-based Development .....................................................................................................60



6.5 Reprogrammable Processor-based Development..................................................................62



7. CERTIFICATION COST ESTIMATES SUMMARY.............................................64 7.1 Summary.................................................................................................................................64 7.2 Conclusions.............................................................................................................................64

7.2.1 Future Standards and Processes....................................................................................64

7.2.2 Platforms and Certification Costs Estimates ...................................................................65

7.3 Recommendations ..................................................................................................................68

APPENDIX ..................................................................................................................1

8. APPENDIX 1: SDR DATA ....................................................................................2 8.1 Terminology ..............................................................................................................................2

9. APPENDIX 2: COTS PRODUCTS DATA.............................................................4

9.1.1 RF Modules: TI’s TRF2436 ...............................................................................................4

9.1.2 Baseband Modules: Intel’s 2250 .......................................................................................5

9.1.3 Baseband Modules: Sequan’s SQN-1130 ........................................................................6

10. APPENDIX 3: FPGA DATA..................................................................................7


Edition Number: 1.1 Issue 1 Page: viii

10.1.1 FPGA: Xilinx’s Virtex4 .......................................................................................................7

10.1.2 FPGA: Xilinx’s Virtex4-QPro..............................................................................................8

11. APPENDIX 4: REPROGRAMMABLE PROCESSOR DATA................................9

11.1.1 Reprogrammable Processors: picoChip’s PC6530...........................................................9

12. APPENDIX 5: TOOLS and COTS Software ......................................................10

12.1.1 FPGA Design: Mentor Graphics’ ModelSim Designer ....................................................10

12.1.2 Model-Based Development: Esterel’s SCADE Suite ......................................................11

12.1.3 ORB: OIS’ ORBexpress (FPGA version) ........................................................................13

12.1.4 OS: LynuxWorks’ LynxOS-178........................................................................................14


Edition Number: 1.1 Issue 1 Page: ix

EXECUTIVE SUMMARY

This document presents detailed information about certification cost estimation for future communication radio platforms to be utilised for Air Traffic Control data communications beyond 2020. Certification costs are based on the IEEE 802.16e (Mobile WiMAX) standard, as:

• IEEE 802.16e has been selected as the Future Communication Infrastructure (FCI) technology to be used for airport surface operations. The FCI radios will operate in the C-band between 5.091 and 5.150 GHz.

• IEEE 802.16e presents many elements and functionalities that could be used for L-band Digital Aeronautical Communication System -1 (LDACS-1) radios yet to be standardized. These FCI radios will be used for in-flight operations, and will operate in the L-band.

Certification cost estimations are provided for certification levels D to A as no failure mode and hazard analysis for the new radio components of the FCI have taken place yet. The study is aiming at providing EUROCONTROL with a clear picture in different certification aspects and respective costs for different platform options:

1. Pure COTS products 2. SDR Forum based developments (SCA) 3. FPGA based developments 4. Reprogrammable processors


Edition Number: 1.1 Issue 1 Page: x

THIS PAGE INTENTIONALLY LEFT BLANK.


Edition Number: 1.1 Issue 1 Page: 1

1. SCOPE

This study is undertaken in response to EUROCONTROL Technical Specification for Certification Cost Estimation for Future Communication Radio Platforms (Price Enquiry N° 08-110699-E). The study will:

• Provide background information on software and hardware certification, processes, methods and standards

• Determine metrics for the estimation of certification costs for Design Assurance Level (DAL) D to DAL A designs

• Establish a baseline through the definition of a generic IEEE802.16e transceiver

• Derive certification costs for different implementations of the baseline transceiver

• Draw conclusions and recommendations In order to accomplish these objectives:

• Chapter 5 provides background information on avionics certification, and describes software development standards (ED-12B/DO-178B) as well as hardware development standards (ED-80/DO-254), and environmental conditions qualification. This chapter also discusses ongoing activities on ED-12C/DO-178C and model-based development. Security aspects and their relation with safety criticality are approached.

• Chapter 6 provides the certification estimates for 4 different architectures, i.e. software defined radio, commercial off the shelf, FPGA and finally reprogrammable processors. Cost matrices provide costs estimations based on effort (person.day), and prices of necessary tools are given for information. Indeed, prices are always negotiated between their provider and the customer, and may differ from one to the other.

• Chapter 7 summarizes the information collected during the study. • Finally, appendices gather data sheets on main products discussed in

the study.



2. APPLICABLE DOCUMENTS

Document Number Date Document Title

PE N° 08-110699-E 05-Mar-08 Technical Specification, Certification Cost Estimation for Future Communication Radio Platforms EUROCONTROL

3. REFERENCE DOCUMENTS

Document Number Date Document Title

[AVI-HDBK] 2000 The Avionics Handbook Cary R. Spitzer

[Part 21] Part 21 Certification procedures for products and parts

[CS 23] Certification Specifications for Airworthiness of Normal, Utility, Aerobatic, and. Commuter Category Aeroplanes

[CS 25] Certification Specifications for Airworthiness of Large Aeroplanes

[IEEE802.16e] 2005 Air Interface for Fixed Broadband Wireless Access Systems IEEE802.16 Task Group, Feb. 2006

[RTCA DO-160E] Environmental Conditions and Test Procedures for Airborne Equipment

[RTCA DO-178B] 1992 Software Considerations in Airborne Systems and Equipment Certification RTCA SC-167 / EUROCAE WG-12

[RTCA DO-254] Design Assurance Guidance for Airborne Electronic Hardware

[RTCA DO-278] Guidelines for Communications, Navigation, Surveillance, and Air Traffic Management (CNS/ATM) Systems Software Integrity Assurance

[SAE ARP-4754] 1996 Certification Considerations for Highly-Integrated or Complex Aircraft Systems

[SAE ARP-4761] Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment.

www.do254.com www.ieee802.org/16/tge/ IEEE 802.16e Task Group (Mobile

WirelessMAN®)



4. GLOSSARY OF TERMS

Term Meaning

16QAM 16-Quadrature Amplitude Modulation 64QAM 64-Quadrature Amplitude Modulation ABD-100/200 AC Advisory Circular AGC Automatic Gain Control ALC Automatic Level Control ANSP Air Navigation Service Provider ASIC Application Specific Integrated Circuit ATC Air Traffic Control ATN Aeronautical Telecommunication Network BER Bit Error Rate BS Base Station BSP Board Support Package CF Core Framework CMM Capability Maturity Model CMMI Capability Maturity Model Integration CORBA Common Object Request Broker Architecture COTS Commercial Off The Shelf DAL Design Assurance Level DER Designated Engineering Representative DFE Digital Front End DFE Decision Feedback Equalizer EAL Evaluation Assurance Level EMC Electro-Magnetic Compatibility EMI Electro-Magnetic Interference FCI Future Communication Infrastructure FEC Forward Error Correction FFPA Functional Failure Paths Analysis FFT Fast Fourier Transform FHA Functional Hazard Analysis FPGA Field-Programmable Gate Array GPP General-Purpose Processor HIRF High Intensity Radiated Field ICAO International Civil Aviation Organization IF Intermediate Frequency IPS Internet Protocol Suite JAA Joint Aviation Authority JTRS Joint Tactical Radio System LDACS L-band Digital Aeronautical Communication System LMS Least Mean Square MAC Media Access Control MASPS Minimum Aviation System Performance Standard MBD Model-Based Development MHAL Modem Hardware Abstraction Layer MIMO Multiple Input Multiple Output MOPS Minimum Operational Performance Specifications NLOS Non Line of Sight OE Operating Environment ORB Object Request Broker



Term Meaning OS Operating System PHAC Plan for Hardware Aspects of Certification PLD Programmable Logic Device POSIX Portable Operating System Interface (UNIX) PSAC Plan for Software Aspects of Certification QoS Quality of Service QPSK Quaternary Phase Shift Keying RD Radio Devices RF Radio Frequency RLS Recursive Least Squares RS Radio Services RSS Radio Security Services RTOS Real-Time Operating System SAL Security Assurance Level SCA Software Communications Architecture SDR Software Defined Radio SLOC Software Line Of Code SS Subscriber Station SWaP-C Size, Weight and Power - Cost VoIP Voice over IP WiMAX Worldwide Interoperability for Microwave Access WRC World Radio Conference



5. BACKGROUND

5.1 Avionics Certification

Most if not all aspects of design, production, maintenance and operation of civil aircraft are subject to extensive regulation by governments. Certification is a critical element in the safety-conscious culture on which aviation is based [AVI-HDBK]. The purpose of avionics certification is to document a regulatory judgement that an airborne system meets all applicable regulatory requirements, can be manufactured properly and finally installed safely onboard an aircraft. Certification authorities will show a great interest for four engineering topics:

1. System requirements: Requirements capture is often considered by avionics developers as the most important technical activity. The resulting system specification will indeed describe normal and abnormal operations, performance, safety, functional testing, training and maintenance procedures.

2. Safety assessment1: As early as possible in the project, developers should address the aircraft-level hazards associated with their proposed system, as there is an explicit correlation between the severity of a system’s hazard and the scrutiny to which the system will be subjected. Initial considerations of hazards are formalized in a Functional Hazard Assessment (FHA).

3. Environmental qualification: Environmental qualification is required for avionics to determine the performance of the equipment/system to its applicable environmental conditions. It is the responsibility of the applicant to identify the environmental conditions to which their systems may be exposed and to specify the applicable environmental and EMI/EMC requirements and the appropriate test methods (e.g. applicable environmental test conditions and test procedures for temperature, altitude, humidity, vibrations, susceptibility to radio frequencies, etc…, as specified by RTCA DO-160E). The applicable environmental qualification levels (applicable RTCA DO-160E categories) represent the most severe environment to which the equipment/system is expected to be regularly exposed during its service life. Environmental testing must be performed on test units representative of the final products, and may be witnessed by specialists designated by certification authorities.

4. Software assurance: Since software has become increasingly important in avionics development, it is frequently the dominant consideration in certification planning. Regulatory compliance for software will show conformance to guidelines as described in EUROCAE ED-12B / RTCA DO-178B. These are assurance standards and not development standards for software, and remain

1 Safety assessment will not be discussed further in this study. As no safety analysis was done for the FCI components, this study addresses Level D (i.e. minor failure condition) up to Level A (i.e catastrophic failure condition). This way the outcome of this study is indicative and representative of the expected costs for all FCI new radio developments (including the L-band radio platforms).



neutral with respect to development methods. Though free to choose their own methods, developers will have to demonstrate satisfaction of assurance criteria in the areas of planning, requirement definition, design and coding, integration, verification and validation, configuration management and quality assurance. In recent years, certification authorities have paid growing attention to programmable logic devices (PLD) such as application-specific integrated circuits and field-programmable gate arrays (FPGA). Findings of compliance were often handled by designated software specialists from certification authorities, and industries and governments have specified acceptable practices for assurance of all avionics hardware design processes through guidelines provided by RTCA DO-254.

SAE ARP-4754 is an overarching safety standard dealing with the systems development process of aviation systems and is intended to provide guidance directed toward highly-integrated or complex systems for demonstrating their compliance with applicable airworthiness requirements. It references RTCA DO-178B for software and RTCA DO-254 for hardware, as well as SAE ARP-4761 for safety engineering techniques. Nevertheless, SAE ARP-4754 has not been adopted by the industry which rather refers to aircraft manufacturer own procedures (e.g. ADB-100/200) or Part 21 and relevant CS2 (e.g. CS 23 and CS 25). As any other development activity, certification can be straightforward when properly managed, and applicants hold early discussions with appropriate certification authorities designated personnel:

• At the very beginning of the project when the applicant and the regulators jointly define their expectations on both sides.

• During development when open communication is maintained among suppliers, customers and regulators. Evidence of compliance with regulatory requirements will then be produced with little incremental effort as a side-effect of good engineering practices.

• Certification should follow in the end, as the complete demonstration of compliance will result from the joint efforts cumulated along the project.

An overall system development process is depicted Figure 1.

2 Unlike Standards or Guidelines developed by EUROCAE, RTCA or SAE, members of which include industry, academies, service providers and regulators, CS are developed by EASA based on previous work (e.g. JAR) from certification authorities.



Figure 1: Overall System Development Process

5.2 EUROCAE ED-12B / RTCA DO-178B Overview

EUROCAE ED-12B / RTCA DO-178B, provides the international aviation community with guidelines for determining, in a consistent manner and with an acceptable level of confidence, that the software aspects of airborne systems and equipment comply with airworthiness requirements [RTCA DO-178B]. These guidelines for the production of software for airborne system:

• Discuss the objectives for software life cycle processes • Describe activities and design considerations for achieving those

objectives • Describe the evidence that indicate that the objectives have been

satisfied DO-178B defines five software levels based upon the contribution of software to potential failure conditions as determined by the system safety assessment process. The software level implies that the level of effort required to show compliance with certification requirements varies with the failure condition category:

1. Level A: Software whose anomalous behaviour would cause or contribute to a failure of system function resulting in a catastrophic failure condition, resulting in many fatalities including the crew. A level A failure might occur 1 in 1 billion flights.

2. Level B: Software whose anomalous behaviour would cause or contribute to a failure of system function resulting in a hazardous/severe-major failure condition, i.e. would reduce the



capability of the aircraft or its crew to cope with adverse operating conditions potentially leading to fatal injuries to a small number of occupants. A level B failure might occur 1 in 10 million flights

3. Level C: Software whose anomalous behaviour would cause or contribute to a failure of system function resulting in a major failure condition, i.e. would reduce the capability of the aircraft or its crew to cope with adverse operating conditions potentially leading to discomfort and possibly injuries to occupants. A level C failure might occur 1 in 100,000 flights.

4. Level D: Software whose anomalous behaviour would cause or contribute to a failure of system function resulting in a minor failure condition, i.e. would not reduce significantly aircraft safety but potentially leading to inconvenience to occupants

5. Level E: Software whose anomalous behaviour would cause or contribute to a failure of system function resulting in a no-effect failure condition, i.e. would not affect the operational capability of the aircraft or increase crew workload. No guidelines apply once software has been confirmed as level E by the certification authority

5.2.1 Software Life Cycle Processes

Software life cycle processes include: 1. The software planning process: definition and coordination of

activities undertaken during the software development and integral processes for a project, i.e. definition of means for producing software which will satisfy system requirements and provide a level of confidence consistent with airworthiness requirements.

The software planning process should also consider particular features of the coding language and compiler (e.g. code performance optimization).

2. The software development processes: production of software

products, including sub-processes such as the software requirement process, the software design process, the software coding process and the integration process, i.e. definition and refinement of requirements allocated to software from the system requirements, implementation of source code and generation of an executable object code.

3. The integral processes: assurance of the correctness, control and

confidence of the software life cycle processes and outputs, including sub-processes such as the software verification process, the software configuration management process, the software quality assurance process and the certification liaison process

Artefacts produced during the software life cycle depend on the activities to be undertaken in regard to the selected software level. Figure 2 depicts main software development activities and outcomes.



Figure 2: Overview of DO-178B Activities and Outcomes

Major differences in the software life cycle processes depending on the selected software level lie in the thoroughness and rigor of activities (and associated artefact) for testing and integration, but above all verification processes. These have a significant impact on the development effort, hence cost, in particular for Level A software requiring tests for robustness and independence for all verification activities to be performed.

5.2.2 Special Considerations

5.2.2.1 Use of Previously Developed Software Modification to previously developed software already compliant with DO-178B may result from requirements changes, detection of errors or software enhancements. Impacts of the modifications shall be thoroughly analysed as they may have consequences on the software architecture, other requirements and/or coupling between other components.

5.2.2.2 Upgrading a Development Baseline DO-178B provides guidance for the acceptance of COTS software, or airborne software developed using other guidance or a lower software level. In brief, software life cycle data, including software aspects of certification, from the previous development shall be thoroughly analysed and evaluated to ensure that the new software verification process objectives are satisfied. If deficiencies exist in the software life cycle data, the data should be augmented to satisfy the objectives of the new application.



5.2.2.3 Tool Qualification DO-178B requires qualification for tools meant to eliminate, reduce or automate any software development process without its output being verified. These tools basically are software development tools (e.g. compilers) and software verification tools (e.g. static analyzer). The objective of the tool qualification process is to ensure that the tool provides confidence equivalent to the processes being eliminated, reduced or automated. DO-178B provides guidelines for tool qualification, which are similar to the qualification of the software application being developed using that tool.

5.2.2.4 Alternative Methods DO-178B discusses a set of alternative methods that can facilitate software development and still fulfil the objectives of the development processes. Formal methods used to improve software specification and verification, exhaustive input testing used as a substitute for software verification, or, product service history which can grant some credit to certification, are alternative methods that can be considered, presented in the PSAC documentation and discussed with certification authorities.

5.2.3 RTOS in Certification

Certification of Real Time Operating System (RTOS) is always an issue for users having developed (or integrated) an RTOS used in airborne systems and wanting it to be certified under DO-178B. DO-178B is much more than just a “certification” artefact checklist; it is a process that starts the same day as the development project itself. Hence, it is difficult if not nearly impossible to take an existing application that was not developed in cooperation with EASA and get it certified for any DO-178B levels, and definitely impossible for Level A applications (even though there are some guidance in DO-178B for upgrading COTS software, ref §5.2.2.2). At the very beginning of a DO-178B development project, a document called Plans for Software Aspects of Certification is supposed to be created and supplied to the certification authority for approval. This plan describes the process and tools and procedures that the developer will utilize during the development and verification of the avionics software application. This plan also describes the application and its use in terms of safety impact on the aircraft. The developer and the certification authority will decide what level of safety criticality the application should be developed to and certified to. This determines the objectives and deliverables that must be met and produced during the development and verification phases of the project. An entire development effort would be necessary to take an existing application like a general purpose RTOS - not to produce the actual code itself, but to go back and develop all of the additional material necessary to support the certification, and get it certified under DO-178B. For example, DO-178B Level A requires that verification testing include sufficient tests for 100% MCDC level object code coverage, and all of the tests are required to be



traceable back to specific software requirements that the code was designed to satisfy. There are a lot of objects to be met and deliverables required to be produced and sent or made available to the certification authority (source T-VEC). Note: It indeed took Rockwell Collins over 40 person years to certify LynxOS to level A, to become LynxOS-178.

5.2.4 Breakdown of DO-178B Objectives

DO-178B Annex A provides a levelling tabulation of the objectives, and illustrates which data item should include the objective evidence, how the evidence must be controlled and where independence is required in achieving the objective. Annex A may be viewed as a checklist for applicants adopting DO-178B for certification purposes. [AVI-HDBK] DO-178B contains objectives for the entire software development lifecycle which are summarized in Annex A tables. Figure 3 depicts the repartition of objectives per DAL over the software development lifecycle.

Figure 3: Breakdown of DO-178B Objectives

As can be seen on Figure 3, the main differentiator between levels is related to Verification activities, with respectively 8 objectives (out of 28) for DAL D, 27 (out of 57) for DAL C, 39 (out of 65) for DAL B and 40 (out of 66) for DAL A. The following table lists the different assurance activities to be undertaken per level.

DAL Assurance Activity Level D (28 objectives)

• Planning • Configuration Management • Quality Assurance • High Level Requirement Coverage • High Level Requirement Robustness • Certification Liaison • Tool Qualification



DAL Assurance Activity Level C (57 objectives)

• Level D, plus: • More planning • Verification Requirements • Design and Integration Process • Low Level Requirements Coverage • Verification Plan, Procedures & Results • Statement, Data & Control Coverage

Level B (65 objectives)

• Level C, plus: • Traceability • Verifiability • Independence • Decision Coverage • Transition

Level A (66 objectives)

• Level B, plus: • MCDC Coverage • More Independence • Source to Object Verification

Table 1: Assurance Activities per DAL

5.2.5 EUROCAE ED-12C / RTCA DO-178C

As can be read above, ED-12B / DO-178B is process and requirements oriented. These guidelines, mainly developed for development of handwritten code and released in 1992, have not revealed major safety flaws. Nevertheless, software engineering has greatly evolved since, and lessons learned from its application by industry and certification authorities on one hand and by the EUROCAE ED-94B / RTCA DO-248 Clarification Group have led EUROCAE WG-71 / RTCA SC-205 to undertake modifications for a new version of ED-12B / DO-178B, ED-12C / DO-178C. Among the issue listed in Oct. 2004 during RTCA Ad-hoc SW meeting (source QinetiQ – MISRA – Nov 2007), were:

• Model-based development (MBD) • Development tool qualification criteria • Separate documentation for CNS/ATM (EUROCAE ED-109 / RTCA

DO-278) • Security Guidance

EUROCAE WG-71 / RTCA SC-205 sub-groups are addressing:

• Software modelling and the ability to use modelling to supplant some verification techniques

• Object oriented software and the conditions under which it can be used

• Software tools and their qualification • Use of formal methods in software specification and design

Work started March 2005, aiming at delivering EUROCAE ED-12C / RTCA DO-178C “Guidance” supplemented by EUROCAE ED-94C / RTCA DO-248C



“Guidelines” by December 2008. The delivery to industry for comment is now foreseen not before early 20103. Within DO178C work, the MDB topic is presently one of the less mature as no consensus is being reached especially on verification and tests, and the certification authorities have lots of comments. If EASA are confident with the use of qualified code generators and are convinced of its merits, this will reduce more than significantly the verification costs, FAA and part of the industry are less confident in “auto coding”, and less convinced with the benefits of using MDB. Indeed, these tools are seen as software development tools, i.e. formal languages (e.g. UML) or schematics (e.g. Simulink), and authorities as well as customer will still require high level requirement specifications in textual forms. Industry nevertheless would expect MDB to be used earlier in the development process, starting at customer requirement capture phases and system design, these tools being able to accommodate rapid prototyping, hence early validation of high level requirements. Moreover, suites like Esterel’s SCADE or MathWorks’ Simulink include C code as well as VHDL autocoders, hence are suited not only for software development, but also system development as a whole. Similarly, Unified Modelling Language (UML) has been transformed into System Modelling Language (SysML) to cope with model based system design. A paper addressing the tool qualification aspects should be issued shortly. It seems “DO-178-like” recommendations for software development tools is on its way. This document is aiming at simplifying or at least clarifying the objectives to be achieved for verification, suppressing MCDC but keeping DC activities for high end software development tools. Tools will be categorized, and a matrix will indicate what category of tool is required for each software criticality level, i.e. tool category x DAL.

5.2.6 Model-Based Development

A model-based (software) development (MBD) is based on use of formal method of modelling for software specification (definition of High Level Requirements through a specification language with rigorous semantics). The Model-Based Design models (used as Low Level Requirements) are then derived from these High Level Requirements for design purpose. The design models are the input artefacts for the software code generation, which is performed either by using a qualified automatic code generator tool or by manual coding with software developers. The typical waterfall scheme of a model-based approach is described hereunder:

3 [Note EUROCONTROL]: ESA has already an MDB based software (ADA) development environment in place since mid 80 for safety related software development for on board satellite equipment. Software had been developed according to PSS-01guidelines.



System RequirementsProcess

Software RequirementsProcess

(Formal Model)

Software DesignProcess

(Model-Based Design)

Software CodingProcess

(Automatic Code Generation)

Software IntegrationProcess

High Level Requirements

Low Level Requirements& Architecture

Source Code

Figure 4: Waterfall scheme using modelling approach

Today, several development suites offer modelling capability, but only few of them have qualified tools. The main one is Safety Critical Application Development Environment (SCADE) Suite (www.esterel-technologies.com) and has a fully qualified chain of tools:

• Kernel Code Generator (KCG): automatic code generator, • Compiler Verification Kit (CVK): check consistency between object

code and C code, • Model Test Coverage (MTC): check coverage analysis at model level.

MathWorks’ Simulink Suite (www.mathworks.com) also offers a modelling approach but has no qualified tool for code generation. Nevertheless, gateways between Simulink models and SCADE exist, that would allow to use SCADE’s qualified code generator on Simulink models. Initiatives launched recently with huge budgets aim at developing qualified code generation tools as well as qualified verification tools, foreseen to support efficiently the production of certification artefacts (if not eliminate the need to have them produced), hence are expected to reduce the overall expensive certification labour. The Toolkit in Open Source for Critical Applications & System Development (TOPCASED) (www.topcased.org) initiative has been launched in 2004 in French AerospaceValley in order to develop a model-driven integrated development environment (IDE). Main partners on the project include industry (Airbus, Atos Origin, EADS, Rockwell Collins, THALES, Siemens VDO…), laboratories (ONERA, LAAS, CNRS…) and academies (ENSEEIHT, INSA, IRIT, INRIA, UPS…). Open source



versions are available for download and evaluation of a qualifiable code generator4. All applications cannot be modelled as easily with an MBD such as SCADE or Simulink. These are suited for algorithms such as filters, mathematics with iterations, logical systems and state machines. Complex algorithms including many loops, or dealing with a large number of inputs or a large amount of data are not easily modelled. The result in that case may be a large size generated code, unless experienced developers build the models in order to achieve a 20-30% overhead compared to hand-coding.

5.2.7 Impact on certification

Qualified tools of model-based development are the key components to lighten effort for software development activities and associated verification tasks for certification. For example, the use of qualified KCG tool avoids Code Reviews required for DO-178B, whereas using the qualified CVK tool reduces the Object Code Analysis effort required for DO-178B. Traceability is ensured through the use of SCADE Suite from System Requirements level to System Verification level. The impact on certification of using qualified tool for structural coverage analysis is a major debate today. It is not defensible for certification purpose to argue that structural coverage analysis (required at code level) could be simplified or even suppressed thanks to the use of the MTC tool: this tool only intervenes at model level and not at code level. Some proponents of model-based development easily tend to do this shortage, yet to be approved by certification authorities. It is today difficult to have a clear view on return on investment of model-based development. Too few avionics programs using this approach have been certified yet (e.g. Boeing’s B787 Landing Gear System and Braking System Control Unit are qualified Level A by FAA, Dassault’s F7X Full Digital Flight Control are qualified Level A by FAA and EASA, Airbus’ A380 Flight Control, Flight Warning System, Braking and Steering System and Cockpit Display System have been developed with SCADE as well). However, the suitability of SCADE Suite for certification constraints has been presented to FAA and judged DO-178B compliant by the FAA. A model-based development is estimated to bring a cost savings of approximately15-20% on the software application verification (which represents the main cost driver of certification).

4 The overall budget of the TOPCASED initiative is estimated to approx. 30-40 M€ and is partially covered through French R&D funding. The TOPCASED products cover a set of features (IDE modules) provided by individual partners of this open source consortium. Individual budgets are estimated to approx. 2-4 M€ each for the development of qualifiable tools. The initiative concerning the development of an automatic code generator is estimated to approx. 2 M€. It is foreseen similar budgets will be necessary to actually qualify each tool.



5.2.8 Pros and cons

There are pros and cons in using model-based development, as summarized hereafter.

Easy prototyping for final user demonstration and requirement capture Models easier to review than code Facilitated debugging tests, validation on host rather than on target platform Simplified verification activities though the use of qualified tools Easier management of late specification changes (requirements upgrade) Cost savings for software development

Pros

Greater development process automation (cascade of tools) High cost of qualified tools Automatic code generator5 generates non-optimized (i.e. slightly larger) number of code lines (SLOC) for complex functions Complex functions (loops, large amount of data, sophisticated algorithms) are not easy to model Open debate on simplification of structural coverage analysis activities

Cons

Too few FAA or EASA stamped certifications to assess real cost savings

Table 2: Model Based Development Pros and Cons The following picture illustrates the expected benefits of using a fully qualified and automated MBD on the development process. As stated above, the process is approved by EASA, but FAA still need to be convinced.

5 Qualified automatic code generators usually provide the developer with C code, i.e. replace hand writing. This code will need to be either compiled by a qualified compiler specific to the target processor, or a “basic” compiler (e.g. GNU) provided the generated object code is verified (e.g. use of SCADE’s CVK module). The Integrated Development Environment (IDE) would include the MDB tool, automatic code generator and the compiler.



Figure 5: Expected Benefits from Using MBD on the Development process

5.2.9 Costs

The following table lists orders of magnitude for SCADE Suite products: Product Unit Price (€)

SCADE Advanced Modeler per seat 30 000SCADE Simulink Gateway 25 000SCADE Qualification Package (KGC, Kit, CVK) 150 000SCADE MTC 20 000Yearly Maintenance:

• SCADE Advanced Modeler per seat • SCADE Simulink Gateway • SCADE Qualification Package • SCADE MTC

• 5 000 • 5 000

• 37 000• 4 000

Investments are presently high to setup a fully automated and qualified MBD, along with the adequate process, for the first time on a product. Also, trade-off between investing in these suites and outsourcing software verification to India or China is still considered. The main gains on costs will be on future evolutions of the product line, once the baseline is established. It is foreseen MBD will then facilitate the handling of the software changes as well as reusability of previously developed modules in the product line or across product lines, and result in cost efficiencies - especially for large software developments.



5.3 EUROCAE ED-80 / RTCA DO-254 Overview

EUROCAE ED-80 / RTCA DO-254 provide guidance for design assurance in airborne electronic hardware to ensure safe functions. It provides a framework of considerations for certification across the entire hardware engineering lifecycle. Alike DO-178B, DO-254 defines criticality or failure conditions which are determined using the system safety assessment process. The standard defines and assigns the exact same levels as DO-178B, ranging from Level A (catastrophic failure) to Level E (no effect). DO-254 also differentiates the rigor of the processes based on whether hardware is:

• Simple: when a set of comprehensive tests can be created to exhaustively determine correct functionality under all operating conditions

• Complex: when hardware cannot be categorized “simple” Simple hardware categorised items do not require extensive documentation of the design process. The supporting processes of verification and configuration management need to be performed and documented, but not extensively. There is thus a reduced overhead in designing a simple hardware item to comply with the DO-254. The main impact of the DO-254 is intended to be on the design of complex hardware items. The following figure (source HighRely) depicts where to apply DO-178B and DO-254 respectively.

Figure 6: Scope of DO-178B & DO-254



As figure 6 indicates, DO-178 is applicable for software running on a CPU from external memory. In case microcodes are used (running internal in the device) than DO-254 is applicable.

5.3.1 Hardware Life Cycle Processes

Hardware life cycle processes include: 4. The planning process: definition and coordination of activities

undertaken during the hardware design and support processes for a project, i.e. definition of means for producing hardware which will satisfy system requirements and provide a level of confidence consistent with airworthiness requirements.

5. The hardware design processes: design of hardware products,

including sub-processes such as the requirement capture process, the conceptual and detailed design processes, the implementation process and the product transition process, i.e. definition and refinement of requirements allocated to hardware from the system requirements, production of the hardware device and preparation for the replication (manufacturing) of the device.

6. The support processes: assurance of the correctness, control

and confidence of the hardware life cycle processes and outputs, including sub-processes such as the validation and verification processes, the configuration management process, the quality assurance process and the certification liaison process

Artefacts produced during the hardware life cycle depend on the activities to be undertaken in regard to the selected software level. Figure 7 depicts hardware design activities and outcomes.



Figure 7: Overview of DO-254 Activities and Artefacts

Major differences in the hardware life cycle processes depending on the selected hardware level are:

• Hardware implementing Levels A and B functions requires to use advanced design assurance method(s) such as a systematic Functional Failure Paths Analysis (FFPA is a structured, top-down, iterative analysis used to determine that the hardware architecture and implementation complies with the safety requirements), and/or another advanced methods acceptable to the certification authority. The use of such design assurance methods is optional for hardware implementing Level C or lower level functions for which the design assurance may be provided using only the standard guidance provided by the DO-254 (section 3 to section 11).

• Traceability should be consistent with the design assurance level of the function performed by the hardware. For Levels C and D functions, only the traceability data from requirements to test is needed.

• Requirements, design, validation/verification, and archive Standard are required only for Levels A and B.

• Independent verification: all verification of Levels A and B functions should be independent. Level C and lower functions do not require independent verification.

5.3.2 Tools

One key aspect of the DO-254 process is to determine that the tools used to create and verify designs are working properly. The process to ensure this is called “tool assessment” (though it is often mistakenly called “tool qualification”). Tool qualification is one method of tool assessment.



The purpose of tool assessment (and potentially tool qualification) is to ensure that tools that automate, minimize, or replace manual processes for hardware design and/or verification perform to an acceptable level of confidence on the target project. Tools are classified as either design tools or verification tools, depending on which design flow processes they automate. Likewise, as mentioned previously, designs are designated with a criticality level that corresponds to the resulting severity of failure. The rigor of the tool assessment process depends on both the tool classification as well as the criticality level of the designated project. The tool assessment and qualification process takes one of three forms:

7. Independent Output Assessment: another independent tool or method must validate the results of the tool.

8. Relevant History: the tool has been previously used and has been shown to provide acceptable results.

9. Tool Qualification: a plan has been established and executed to confirm that the tool produces correct outputs for its intended application.

Regardless of these classifications, the task of tool assessment falls upon the airborne applicant or airborne integrator (not the tool vendor). The applicant or integrator proposes the method of tool assessment as part of the DO-254 planning and documentation. The certification agency or its representative (DER) will determine if the proposed method of compliance to this requirement is adequate for the development process.

5.3.3 D0254 cost versus D0178

Presently, DO-254 is much more recent in its application than DO-178, and relatively less precise in the recommendations than DO-178 requiring more rigorous justifications, demonstrations and analysis. This fuzziness leaves flexibleness to audits which are, for the time being, less stringent than they would be for DO-178. This state of things leads to reduced DO-254 certification costs of approximately 20-30% for a DAL A development of a single software hosted on a single6 “DO-254-ruled” component, when compared to equivalent software on a “DO-178-ruled” component. Emerging components such as Xilinx’s Virtex 4 or Virtex 5 (www.xilinx.com) embed FPGA, DSP core and PowerPC core. These features are those commonly used in wireless communication systems, and may be the basis for Software Defined Radios (SDR) as discussed §6.2. There is little experience on use of such chips in avionics systems yet, but should their use spread in relevant system designs, it could be proposed with present status in DO-178C and DO-254 to certify these components as a single board hosting the split elements would, i.e. an FPGA, a DSP and a PowerPC:

• The DSP and the PowerPC cores would be certified through the software they run, i.e. through DO-178C

6 Reference is made here of single software on single FPGA (hence DO-254) to allow comparison with same software function on a processor (hence DO178). When multiple FPGA enter the design, the artifact to be submitted will be slightly more complex as the overall design will have to be submitted as well as each individual FPGA design.



• The FPGA and interfaces through DO-254 Single mode of failure could be a safety concern, as if the chip fails, then the whole radio fails. This would also be the case with a “split component” design, i.e. it is likely that if either the DSP or the PowerPC fails, than the whole radio would in turn fail. Using these integrated chips will possibly simplify the design of the radio (hence lower the costs of certification related to design artefacts, but this has little impact on the overall costs). Whether they will be actually used in the future other than for reduced SWaP-C (size, weight and power, as well as cost) considerations (i.e. provided their cost is less than the sum of the costs of equivalent FPGA, DSP and PowerPC) will need further investigation. Indeed, reliability and maintainability of the equipment also need to be considered during the design phases.

5.3.4 D0254 and COTS

FAA’s Advisory Circular AC 20-152, 30-May-05, stipulates “if you [manufacturers] choose to follow the guidance in RTCA/DO-254 for your level D devices, we do not need to review the life cycle data for that device. […] This AC recognizes the guidance in RTCA/DO-254 applies specifically to complex custom micro-coded components with hardware design assurance levels of A, B, and C, such as ASICs, PLDs, and FPGAs.” Also, “We [FAA] recognize that the hardware life cycle data for commercial-off-the-shelf (COTS) microprocessors may not be available to satisfy the objectives of RTCA/DO-254. Therefore, we don’t intend that you apply RTCA/DO-254 to COTS microprocessors7. There are alternative methods8 or processes to ensure that COTS microprocessors perform their intended functions and meet airworthiness requirements. Coordinate your plans for alternative methods or processes with us early in the certification project.” Components and/or computer boards manufacturers interpret the AC as massively deployed COTS products can be certified DO254 Level D by the fact that if these products would show defects, then they would have rapidly been revealed (hence corrected). Position of EASA9 is presently similar; DO-254 may not apply to COTS for DAL D. Indeed, Certification Review Items (CRI) are being put in place between EASA and airframers (i.e. Airbus) for aircraft under development (e.g. A380 and A350), addressing applicability of DO-254 for DAL C and

7 [Note-RCF]: COTS microprocessors include processors (e.g. Intel’s Pentium4 family, or Freescale’s PowerPC family) and digital signal processors (DSP) (e.g. Texas Instruments’ TMS320 family) currently used in certified avionics designs. Other complex micro-coded components (e.g. Picochip’s PC6530) are considered as ASICS. 8 [Note RCF]: COTS microprocessors are certified through a) justification (basically In Service Experience) and b) through DO-178 certification of the software they run. 9 An avionics manufacturer chooses to submit its application to FAA if the equipment is to fly in the US, or to EASA if the equipment is to fly in Europe. Fortunately, there are equivalences between the two organizations which facilitate the certification by one for equipment already certified by the other.



above only. Similarly, FAA and EASA have issued Certification Authorities Software Team (CAST) papers providing recommendations and clarifications on the use of DO-254 through Position Paper CAST-27 (June 2006).

5.3.5 D0254 and embedded IP

CAST-27 (June 2006) which deals (among other points) with COTS Intellectual Property such as complete custom micro-coded components, incl. FPGA, states “Since the use of a COTS IP can greatly impact the performance and functionality of a custom micro-coded component, the rigor of the development processes for a COTS IP implemented in a custom micro-coded device for use in airborne systems or equipment should be commensurate with its intended use and should satisfy applicable functional and safety-related requirements. Moreover, the guidance in section 11.2 of DO-254/ED-80 may not be sufficient for design assurance of a COTS IP implemented in a custom micro-coded device that support safety critical applications such as Level A or B aircraft functions. As a result, life cycle data (i.e., verification, testing, and analysis) of a COTS IP may need to be developed or augmented to demonstrate its intended function, satisfy applicable regulations, and meet airworthiness requirements.” Similarly, CRI for Airbus aircraft under development state “The rigour of the development processes for a COTS (IP) used in ASICs or PLDs design and implementation should be commensurate with its intended use and should satisfy applicable functional and safety requirements. Life cycle data may need to be augmented to satisfy the intent of DO 254/ED-80”, and “For specific digital devices such as ASICs or PLDs or complex COTS already part of a certified aircraft type, credit may be taken from this previous application if the use of the device is shown being equivalent, the service history acceptable and no In-Service Problem affect the device. For complex COTS10, the In Service Experience could be captured from other applications if shown relevant.“ A digital down converter (DDC) (e.g. Analog Devices’ AD6653) can be considered a COTS ASIC certifiable by justification through In Service Experience. Its data sheet would provide design details as DAL D artefact, and “black box” functional testing would complete the verification aspects. Use of more sophisticated COTS IP (e.g. Picochip’s PC6530) in avionics design may be more difficult to justify even if widely spread in commercial applications, and likely to be impossible to justify in DAL C (and above) designs.

10 [Note RCF]: The CRI considers microcontrollers, defined as “Any electronic component which executes software in a specific core area and implements complex peripheral hardware elements such as for example I/O (bus controllers) or graphic symbol libraries. Microcontroller could be “catalogue” COTS implemented in ASIC/FPGA development”, as complex COTS. Nevertheless, “microcontrollers with simple peripherals such as UART, A/D or D/A converters remain out of scope of this CRI” (hence are not governed by DO-254).



5.3.6 Conclusion on DO 254 Costs (general)

DO-254 will more than likely evolve in the coming years, and become as stringent as DO178 is. DO-254 requires qualified development tools (code generator) for DAL C and above designs, and qualified verification tools for DAL B and above designs. Tools and IDE are available to facilitate DO-254 certification of FPGA designs (e.g. Mentor Graphics’ ModelSim – source www.do254.org- or the widely spread Actel’s Libero -www.actel.com). Also, current MDB tools such as Esterel’s SCADE and MathWorks’ Simulink, offer VHDL auto-coding features as they do C language auto-coding. However, if Esterel’s SCADE KGC is qualified for DAL A software development, no such feature is today available for VHDL. Nevertheless, the need for qualified suites for certified FPGA design is increasing every day. Xilinx11 is looking into it, and it is more than likely that other providers (e.g. ACTEL or Esterel) will respond to the demand, offering qualified MDB suites for prices equivalent to suites qualified for DO-178C. For these reasons, i.e. similar approach, process and tools, it is foreseen that DO-254 certification costs will be equivalent to DO-178B/C certification costs in the next future.

5.4 EUROCAE ED-14E / RTCA DO-160E Overview

RTCA DO-160E / EUROCAE ED-14E defines a series of minimum standard environmental test conditions (categories) and applicable test procedures for airborne equipment. The purpose of these tests is to provide a laboratory means of determining the performance characteristics of airborne equipment in environmental conditions representative of those which may be encountered in airborne operation of the equipment. The standard environmental test conditions and test procedures contained in the DO-160E standard may be used in conjunction with applicable equipment performance standards as a minimum specification under environmental conditions, which can ensure a sufficient degree of confidence in performance during operations. The test levels or/and test procedures to be considered during equipment testing may be based on other guidance material (for ex. interim policy issued by the JAA for the HIRF). The test categories defined in DO-160 are intended to encompass the full spectrum of environmental conditions that airborne equipment may experience – from benign to very hostile. The selection of the appropriate and/or additional environmental conditions and test procedures is the responsibility of the authors of the performance standards for the specific airborne equipment. For each environmental

11 [Note EUROCONTROL]: Mentor Graphics has teamed with Thales and Xilinx to develop FPGA formal verification flows to meet next generation products.



condition, the equipment supplier must select from categories defined within the particular sections that category which best represents the most severe environment to which the equipment is expected to be regularly exposed during its service life.

5.4.1 Major ED-14E / DO-160E Activities and Artefacts

5.4.1.1 Qualification Test Plan The equipment supplier is in charge to document the Qualification Test Plan providing detailed instructions for performing the environmental tests on the equipment in accordance with its applicable D0-160E test conditions and test procedures. The equipment supplier must document also the equipment performances relative to the system specifications that must be monitored during the tests. Pass/fail criteria for performances test must be defined in the test plan, in particular for Catastrophic functions (level A functions) as well as Essential functions (level B and C) that must be monitored during the tests. The equipment must be tested in the configuration and with the interface wiring, cable layout and bonding the most representatives of its operational conditions.

5.4.1.2 Qualification Test Campaign The test must be conducted by an accredited test laboratory that will document the test results in a test report providing a detailed explanation of the results for each environmental test requirement.

5.4.1.3 Qualification Test Report The test laboratory will prepare a test report for documenting the result of the qualification tests. This report must provide a detailed explanation of the results for each environmental test requirement. Usually, an additional test report is issued by the equipment supplier to summarize the reporting of the complete test campaign in accordance to the equipment specifications and the qualification test plan. The following table lists the basic environmental conditions required to be tested for equipment installed in the avionics bay of an air transport aircraft, and provides a rough order of magnitude estimate of the cost of the test as invoiced by the test laboratory. To those costs, the equipment manufacturer shall add extra effort for planning, follow-up, investigations and result analysis activities globally estimated to 140 person.day.

Environmental Conditions Category and Requirement Cost (Euro) Temperature / Altitude DO-160E, Section 4, cat.A2 1800 Temperature variation DO-160E, Section 5, cat. B 1200 Humidity DO-160E, Section 6, cat. B 5500 Operational shock and crash safety DO-160E, Section 7, cat B 1700



Environmental Conditions Category and Requirement Cost (Euro) Vibration DO-160E, Section 8, curve R 5000 Explosion proofness DO-160E, Section 9, cat. X n/a Waterproofness DO-160E, Section 10, cat. Y (condensation) 600 Fluid susceptibility DO-160E, Section 11, cat. F 1700 Sand and dust DO-160E, Section 12, cat. X ( cat X means n/a) n/a Fungus resistance DO-160E, Section 13, cat. F 2000 Salt spray DO-160E, Section 14, cat. X n/a Fire, Flammability DO-160 E, Section 26, Category C 2000 Magnetic effect DO-160E, Section 15, cat. Z 1000 Power supply DO-160E, Section 16, cat. [BZ] 3000 Voltage spike DO-160E, Section 17, cat. A 1000 Audio frequency conducted susceptibility DO-160E, Section 18, cat. Z 1000 Induced signal susceptibility DO-160E, Section 19, cat. Z 2000 Conducted susceptibility DO-160E, Section 20, cat. W 3000

Radiated susceptibility DO-160E, Section 20, cat. G 100 to 200 V/m SW/CW and HIRF 700 to 3500 V/m PM

6000

Conducted emission of radio frequency energy

DO-160E, Section 21, cat. H 1000

Radiated emission of radio frequency energy

DO-160E, Section 21, cat. H 2000

Lightning induced transient susceptibility DO-160E, Section 22 cat A3G33J33 5000 Lightning direct effects DO-160E, Section 23, cat. X n/a Icing DO-160E, Section 24, cat. X n/a Electrostatic discharge DO-160E, Section 25, cat. A 2000 Bonding MIL-STD 464, parag. 5 1000

Manufacturer extra effort (person.day) Planning, follow-up, investigations, result analysis 140

Table 3: DO-160E Qualification Costs

5.5 Metrics

Industry has established metrics based on their own experience in development of certified avionics as part of their Capability Maturity Model – Integration (CMM/CMMI) process. These are used to measure their performance, but also to estimate development costs and assess benefits of new development methods (e.g. model-based development). The development costs depend on two main factors:

1. Design Assurance Level (DAL) 2. experience on similar developments

Indeed, costs for brand new developments are significantly higher than costs for re-use or evolutions of a well-mastered product line. A factor 3 to 4 can differentiate the two types of developments.



Software metrics are based on the number of software line of code (SLOC), i.e. C language or Ada instructions and not Assembler (which is seldom used nowadays in avionics, except for very limited parts of code necessitating speed or size optimization), and the following table lists associated development effort, which include documentation, production and validation of these lines of code for DAL D and DAL A software. DO178B DAL D DO178B DAL A

No Experience Experience No Experience Experience 25 SLOC / day 65 SLOC / day 3 SLOC / day 12 SLOC / day

Table 4: DO-178B DAL D and DAL A Metrics According to High Rely12 (www.highrely.com), DO-178B cost should be on the order of 25%-40% ( presuming basic high-reliability (SEI CMM and CMMI Level 2 or 3) software engineering principles are used), where in reality industry average is additional 75%-150%. Main reasons for this disparity are:

1. Inadequate DO-178B low-level software requirements 2. Vagueness within the five key DO-178B process plans prior to initiating

those lifecycles 3. Insufficient independence of DO-178B reviews 4. Insufficient DO-178B checklists for reviews 5. Inadequate DO-178B traceability between components 6. Insufficient advance coordination/approvals with Certification

Authorities 7. Incomplete DO-178B structural coverage for decision condition and

MCDC coverage 8. Over doing DO-178B tool qualification 9. Not applying DO-254 to hardware 10. Avionics outsourcing without a clear DO-178B Project Plan covering

details for the avionic outsource team Same figures are reported by Mentor Graphics for DO-254. Though the company agrees the certification process for the standard adds costs to the development process, these costs should be 25% to 50% higher than for non-compliant developments when the process is efficiently followed. However, industry averages approach 100% in additional costs. According to High Rely, main reasons for overspending on DO-254 certification are:

1. Neglecting independence 2. Differing tool selection 3. Inadequate formal planning 4. Insufficient hardware requirement detail 5. Inadequate and non-automated traceability 6. Excessive code iterations 7. Lack of path coverage during functional tests 8. Lack of automated testing 9. Improper application of DO-254 scope

12 Care should be taken when considering figures provided by High Rely as this consulting company provides DER activities but also training on DO-178B and DO-254 and how to interpret these standards.



10. Not using Company Designated Engineering Representatives (DER) Delta cost and schedule of DO-178B and DO-254 per criticality level by High Rely are listed in the following table:

Level E Level D Level C Level B Level A Baseline E+5% D+30% C+15% B+5%

Table 5: High Rely’s Delta Cost and Schedule per DAL According to these figures, the larger gap in cost and schedule is between Level D and levels above (30% to go from D to C or 50% for B (from D) and 57% for level A (from D). Figures below provide extrapolations of metrics observed in industry (Figure 8) and application to High Rely figures (Figure 9).

Figure 8: Metrics Observed in Industry



Figure 9: Application to High Rely Figures

The figures highlight the disparity with the productivity (hence costs) discussed by High Rely. The truth is probably in between. Also, it is proposed to adopt the metrics defined in the table below for the study, assuming:

• Conventional developments, i.e. no MDB, are performed by design teams with experience in airborne radio development

• The design organization follows CMMI Level 3 processes set internally • The developments are supported by highly automated processes and

tools DAL D DAL C DAL B DAL A

65 42 29 24 - (D-35%) (C-30%) (B-17%)

Table 6: Metrics for the Study

5.6 Avionics Equipment development process life cycle

Figure 10 below depicts the overall process for the introduction of new avionics, starting from the proof of concept phase end ending with the certification of a new transceiver. Main activities are “layered” on three levels:

• Proof of concept: involving ANSP, industry, research labs… to undertake simulations, prototyping and experiments

• Standardization: involving ICAO, EUROCAE / RTCA (airborne side) and ETSI (ground side), industry, research labs… to establish MAPS



and MOPS for the transceiver, and finally EASA / FAA to establish ETSO / TSO

• Industrialization: involving industry (airborne and ground-based equipment manufacturers) to undertake the development of certifiable equipments

The process could be as short as a couple of years or as long as tens of years depending on the motivation (namely the business case) for industry, i.e. airborne equipment manufacturers, and end-users, i.e. airlines.

5.6.1 VDLmode4 example

For instance, the Self-organized Time Division Multiple Access protocol patented by Hakan Lans in 1988 and used by VDL Mode 4, was adopted by ICAO in 2001, MOPS finalized in 2006, and few radios have been recently certified level D by Swedish avionics manufacturers.

5.6.2 VDLmode2 example

Main milestones for VDL2 are: • 1988 beginning of works by ICAO on aeronautical telecommunication

digital network • 1990: decision to use VHF as air/ground means • 1991: Aeronautical Mobile Communication Panel (AMCP) in charge of

VDL standard • 1996: VDL2 SARPS are approved • 1997: VDL2 SARPS are applicable • 2002: VDL2 MOPS are issued • 2002: First aircraft equipage • 2004: Core Europe coverage

Note: the CMU carrying VDL2 ATN stack is only certified DAL-D



Figure 10: Overall New Avionics Introduction Process

Note: Blue label avionics prototype is neither airworthiness approved nor certified. A Red label has airworthiness approval but is not certified.

5.7 Internal vs External DER Costs

Certification liaison processes are designed to streamline the certification process by ensuring that issues are identified early in the process. While DO-178B, for instance, outlines 20 distinct data items to be produced in a compliant process, 3 of these are specific to this process and must be provided to the certifying authority:

1. Plan for Software/Hardware Aspects of Certification (PSAC) 2. Software Configuration Index (SCI) 3. Software/Hardware Accomplishment Summary (SAS/HAS)

Other data items may be requested by the certification authority, if deemed necessary. Applicants are encouraged to start a dialogue with certification authorities as early in the process as possible to reach a common understanding of a means of achieving compliance with DO-178B / DO-254. This is especially important as new technology is applied to avionics. EASA can at its discretion appoint individuals who meet required qualification to act on its behalf. These appointees, Designees, receive authorization under FAR Part 183 and act in a variety of roles. Avionics developers are most likely to encounter a Designated Engineering Representatives (DER) who will approve engineering data as the EASA would. Company DER or consultant DER will only approve or recommend approval of technical data to the EASA.



The EASA workload and scheduling may make the use of DER a pragmatic reality. An applicant actually hiring a DER has more flexibility in managing his/her time on the project. The applicant should evaluate the DER as any other engineering resource, and their cost and benefits in the project. Also, an experienced DER can be source of valuable guidance and recommendations, and steer the applicant toward compliant approaches or assist the applicant with recovery strategies. An annual fee is levied on all current holders of European Technical Standard Order (ETSO) Authorisations (ETSOA) to cover cost to the EASA Agency of ensuring that its ETSOA remain valid. According to the EASA “Commission Regulation (EC) n°593/2007 of 31 May 2007, on the fees and charges levied by the European Aviation Safety Agency”, the applicant for a given certification task will consist of a variable amount proportional to the workload involved, expressed as a number of hours multiplied by the hourly fee (225 € actually). The hourly fee reflects all costs arising from certification tasks charged on an hourly basis:

• Demonstration of design capability by means of alternative procedures

• Production without approval

• Acceptable Means of Compliance to Airworthiness Directives

• Technical assistance requested by foreign authorities

Typically, four 2-3 day audits (depending on criticality and complexity) will be performed by EASA representatives throughout the project:

1. Planning and Definition 2. Conception 3. Test and verification 4. Final acceptance

5.8 Security Aspects

5.8.1 Background

More and more air-ground communications between ATC and an aircraft (pilot), but also between the airline and an aircraft (pilot and avionics computers), rely on data link. It is foreseen data link communications will become primary means of communication in a next future due to safety (e.g. language proficiency), efficiency (e.g. automation) and spectrum issues (e.g. bandwidth). Nevertheless, introduction of data link communications raises a number of issues among which security. Indeed, Air Navigation Service Provider (ANSP) and Airlines want:

• assurance that the organization who claims to have sent the message through data link is the actual organization who sent it (Authentication)



• confidence that the data being received has not been changed or corrupted (Integrity)

Also, airlines do not want a competitor or malicious organization eavesdropping on the message and learning something the airline does not want publicly known (Privacy).

5.8.2 Status for Aeronautical Data Links

Many specifications and studies are ongoing in the aeronautical community with respect to data link technology and security aspects (e.g. Secured ACARS ARINC 620 specification). The International Civil Aviation Organization (ICAO) has defined the data communication protocols and services to be used for implementing Aeronautical Telecommunication Network (ATN) using Internet Protocol Suite (IPS) as published in Amendment 83 to Annex 10 of its Convention. ICAO has adopted the Internet Protocol version 6 (IPv6) for internet layer as specified in RFC 2460. IPv6 will provide better scalability and already integrates many features that IPv4 only partially delivers. Aircraft are required to implement Mobile IPv6 as defined in RFC3775, unlike ATN/OSI there is no need to implement a routing protocol on air-ground links as the mobiles will operate with a default route per interface. It is foreseen that certain aircraft may make use of Mobile IPv6 extensions such as Networks in Motion (NEMO) as specified in RFC3963. ICAO mandates that IPS mobile nodes shall implement the security provisions of the access network, in this case, those security features offered by Wimax. For air-ground communication security, ICAO refers to the following Request for Comment (RFC) but recommends that their actual use is subject to system threat and vulnerability analysis:

• RFC4301: IP Encapsulating Security Payload protocol • RFC4868: AUTH_HMAC_SHA2_256-128 integrity algorithm for ESP

authentication • RFC4106: ESP encryption and authentication with AES-GCM with 8

bytes ICV, 128bits key length • RFC4306: use of Internet Key Exchange (IKEv2) Protocol • RFC5280: Use of Internet X.509 Public Key Infrastructure Certificate

and Certificate Revocation List. • RFC3647: Use of Internet X.509 Public Key Infrastructure Certificate

Policy and Certificate Practices Framework. • RFC4877: Use of Mobile IPv6 Operation with IKEv2 and the Revised

IPSec Architecture.

5.8.3 Security Assurance Levels versus Development Assurance Levels

Security levels are defined through Security Assurance Levels (SAL) and internationally accepted Common Criteria standards which define Evaluation Assurance Levels (EAL). There is no direct relationship between SAL or EAL and DAL as DO-178B only deals with safety aspects. A DAL E software (e.g.



Windows®) can provide capabilities to support high security levels necessary to some applications. EAL are defined as follows:

• EAL1 (Functionally Tested): applicable where some confidence in correct operation is required, but the threats to security are not viewed as serious

• EAL2 (Structurally Tested): requires the cooperation of the developer in terms of the delivery of design information and test results, but should not demand more effort on the part of the developer than is consistent with good commercial practice

• EAL3 (Methodically Tested and Checked): permits a conscientious developer to gain maximum assurance from positive security engineering at the design stage without substantial alteration of existing sound development practices

• EAL4 (Methodically Designed, Tested and Reviewed): permits a developer to gain maximum assurance from positive security engineering based on good commercial development practices which, though rigorous, do not require substantial specialist knowledge, skills, and other resources

• EAL5 (Semi-formally Designed and Tested): permits a developer to gain maximum assurance from security engineering based upon rigorous commercial development practices supported by moderate application of specialist security engineering techniques

• EAL6 (Semi-formally Verified Design and Tested): permits developers to gain high assurance from application of security engineering techniques to a rigorous development environment in order to produce a premium TOE for protecting high value assets against significant risks

• EAL7 (Formally Verified Design and Tested): applicable to the development of security TOE for application in extremely high risk situations and/or where the high value of the assets justifies the higher costs

Nevertheless, DO178B (ref DO178B§ TBD) considers adapting DAL levels meant for safety to “confidence” levels meant for other purposes than safety, e.g. security. DO-178C will provide guidance with respect to security in aeronautical software developments.



6. CERTIFICATION COST ESTIMATES

6.1 Generic Avionics Transceiver

6.1.1 Functional Overview

Figure 11 depicts the main functions of a generic avionics transceiver. It is aimed at providing a functional overview, regardless of the actual implementation of the radio. This architecture will be derived within each individual section hereafter, depending on the functional allocation to hardware solutions.

Figure 11: Generic Transceiver (draft)

6.1.1.1 Baseband Module Typical implementations include both the modem processing and the waveform processing into a module also known as the baseband module. This baseband module supports analogue to digital conversions, and the waveform physical and MAC layers, and eventually upper protocol layers. As a minimum, the baseband module will perform:

• For reception: o Adaptation of the intermediate frequency (IF) signal provided

by the front end module o Analogue to digital conversion of the IF signal o Down conversion and channel filtering



o Digital automatic gain control (AGC) and automatic level control (ALC) if needed

o Processing of the waveform physical layer Synchronization and demodulation Forward error correction (FEC) decoding and de-

interleaving o Processing of the waveform protocol (MAC and upper layers)

• For transmission: o Processing of the waveform protocol (MAC and upper layers) o Processing of the waveform physical layer

Coding and interleaving Modulation

o Up conversion and channel filtering o Digital to analogue conversion of the IF signal

6.1.1.2 Front End Module The front end module, also known as RF/IF module, processes analogue signals from the antenna to the baseband module (modem), and vice-versa. Under control of the baseband module, the RF/IF module will perform:

• For reception: o Amplification or attenuation of the received analogue signal

from an external or internal power amplifier (LNA) o Improvement of the signal dynamic by use of variable gain

elements coupled with the AGC and ALC functions o Down conversion of the input RF signal to a first or second

intermediate frequency towards the baseband module o IF filter

• For transmission: o Up conversion of the IF signal provided by the baseband

module to the desired RF frequency o Analogue filtering as required to comply with the spectral

containment of transmitted signals by the waveform o Amplification of the transmitted RF signal by an external or

internal power amplifier (HPA) • For both transmission and reception:

o Wide band filtering needed to ensure the objectives of co-site performance

o Narrow band filtering adapted to the waveform canalization. There are pros and cons in implementing front ends using discrete analogue components or fully integrated digital front ends (DFE), as summarized hereafter.

Analogue Front End Digital Front End Pros Low cost Less surface for hardware

implementation (can be hosted by same FPGA as the one used for the baseband module)



Well known technology (hence, easy and quick development)

Easy to implement by digital processing engineer (with minimum radio knowledge) as debug is at software level

Easier maintenance (a couple of discrete components)

Simple design (sample can occur right after the antenna though this implies requirements regarding the A/D converter, e.g. dynamic range)

Larger surface for hardware implementation

Expensive (requires sampling twice as fast as the input frequency)

Requires radio skills for the development

Emerging technology

Cons

Requires expertise for optimal performance

Difficult maintenance as the same component hosts many features

Table 7: Analog versus Digital Front End Pros and Cons

6.1.1.3 Other Modules and Features Other modules and features to be taken into account in the design, implementation, validation and certification efforts include:

• Transceiver Management o Coordination of the different processing functions and units

(depending on actual implementation and allocations of resources to DSP, FPGA and general purpose processors)

o Health Monitor and Built In Test (BIT) • User Space:

o Internet Protocol Stack • Other:

o Time Reference Dispatch of a synchronization time reference clock

between the different modules o Sensors

Thermal management Power/voltage management

o Power Supply Conversion of aircraft 28VDC input into secondary

voltages needed by the different boards Transparency time Over-current protection Monitoring

o EMI filtering and lightning protections

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


4 Define Hardware Requirements 4.1 Develop Hardware Requirements Hardware Requirements 4.2 Address Certification Issues 4.3 Perform Configuration Control, Reviews and Change


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


6 Develop Detailed Hardware Design

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


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


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


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


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


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


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




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


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


16 Integrate System 16.1 Integrate the System Elements and Test Basic

Functionalities Integrated system



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


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


19 Develop System Acceptance Procedures 19.1 Develop System Acceptance Procedures 19.2 Perform Configuration Control, Reviews and Change


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



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.



6.1.3 IEEE 802.16e Background

WiMAX (Worldwide Interoperability for Microwave Access) is a technology providing wireless high speed data communications. The technology is based on the IEEE802.16 standard. The current version of the standard, IEEE802.16e, covers "Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands," was approved, as IEEE Std 802.16e-2005, by the IEEE-SA Standards Board on 7 December 2005. It was published on 28 February 2006. (source www.ieee802.org). IEEE802.16e was introduced to support mobility (handover between base stations, as well as to add improvements to previous IEEE Std 802.16d-2004 such as non-line of sight (NLOS) coverage and Quality of Service (QoS) for Voice over IP (VoIP) applications. These enhancements are based on advanced processing techniques such as scalable Fast Fourier Transform (FFT), antenna diversity schemes and adaptive antenna systems, Multiple Input Multiple Output (MIMO) technology and Turbo Coding.

6.1.3.1 IEEE802.16e Physical Layer The main components of the IEE802.16e physical layer are depicted Figure 12. These include for the transmit part:

• A Scrambler (or Randomiser) module which replaces sequences in a bit stream into other sequences by injection of a pseudo-random number (PN) sequence

• A Forward Error Correction (FEC) Encoder module which encodes the bit stream based on polynomial processing, cascading well known Reed-Solomon and Convolutional Encoder algorithms, or Turbo Code algorithms

• An Interleaver module which reorganises and packs the bit stream after injection of preambles

• A Modulation (or Mapper) module which performs bit to complex (I, Q) conversions for modulation schemes such as 64QAM, 16QAM or QPSK depending on transmission parameters from the Medium Access Control (MAC) layer

• An Orthogonal Frequency Division Multiple Access (OFDMA) Symbol Generation module which creates the OFDM symbol based on MAC transmission parameters

• A Guard & Padding module which formats data for the following IFFT module

• An Inverse Fast Fourier Transform (IFFT) module which modulates the carriers

• A Cyclic Prefix Addition module which add a cyclic prefix to each OFDM symbol

On the receive counter-part, these will include:

• A Cyclic Prefix Removal module • A Fast Fourier Transform (FFT) module



• A Preamble/Guard Identification module • A OFDMA Symbol Extractor module • A Demodulation (Demapper) module • A De-Interleaver module • A Decoder module (Viterbi followed by Inverse Reed-Solomon) • A De-Scrambler module • And, a Channel Estimation module which estimates the error

introduced on the channel using LMS, RLS filtering techniques applied on the training symbol, followed by a Channel Equalization module which reduces the bit error rate (BER), solving multi-path issues, using appropriate equalizer techniques such as Frequency Domain Equalizer (FEQ) followed by DFE14 (Decision Feedback Equalizer).

Figure 12: IEEE 802.16e Physical Layer

6.1.3.2 IEEE802.16e MAC Layer The IEEE802.16 e Medium Access Control (MAC) layer focuses on managing the resources of the wireless link in an efficient manner (source Intel Technology Journal Vol. 8, issue 3). It uses a scheduling algorithm for which the subscriber station (SS) needs to compete only once when entering the network. After that, the SS is allocated an access slot by the base station (BS). The time slot remains assigned to the SS and can enlarge and contract. The scheduling algorithm allows the BS to control Quality of Service (QoS)

14 The DFE module is actually more integrated with the FEQ processing then following the FEQ module in the IEEE802.16e models used for this study. Decisions are basically be taken based on processing the training sequence and the preamble.



parameters by balancing the time-slot assignments among the application needs of the SS. The IEEE802.16e MAC layer is organized around 3 sub-layers as depicted Figure 13:

1. The service-specific convergence sub-layer: is responsible for performing all operations that are dependent on the nature of the higher-layer protocol (e.g. IPv4, IPv6…), such as header compression and address mapping. Its primary tasks are to classify service data units to proper MAC connection, enable and preserve QoS, and enable bandwidth allocation.

2. The common part sub-layer: performs all the packet operations that are independent of the higher layers, such as fragmentation and concatenation of Service Data Units (SDU) into MAC Protocol Data Units (PDU), transmission of MAC PDU, QoS control, and Automatic Repeat Request (ARQ).

3. The security sub-layer: is responsible for encryption, authorization, and proper exchange of encryption keys between the BS and the SS.

These sub-layers are basically defined as finite state-machines, setting bit fields and exchanging MAC PDU frames.

Figure 13: IEEE 802.16e MAC Layer



6.2 SDR-based Development

A Software-Defined Radio (SDR) system is a radio communication system where components that have typically been implemented in hardware (i.e. mixers, filters, amplifiers, modulators/demodulators, detectors. etc.) are instead implemented using software on embedded computing devices. A basic SDR may consist of a computer equipped with an analog-to-digital converter, preceded by an RF front end. Significant amounts of signal processing are handed over to the general purpose processor, rather than done using special-purpose hardware. Such a design produces a radio that can receive and transmit a different form of radio protocol (waveform) just by running different software. Software radios have significant utility for the military and cell phone services, both of which must serve a wide variety of changing radio protocols in real time. The Joint Tactical Radio System (JTRS) is a program of the US to produce radios that provide flexible and interoperable communications. This goal is achieved through the use of SDR systems based on an internationally endorsed open Software Communications Architecture (SCA). This standard uses Common Object Request Broker Architecture (CORBA) on POSIX operating systems to coordinate various software modules. The SCA is a set of rules for deploying and interconnecting the signal processing objects of a SDR. The SCA enables integration of hardware and software components from different vendors into seamless products and improves software reusability, system scalability, and interoperability of systems regardless of manufacturer. Adherence to the SCA also allows rapid insertion of new technologies into fielded SDR systems. The SCA is now managed by the Joint Tactical Radio System (JTRS) Program Executive Office (JPEO) (http://sca.jpeojtrs.mil/) and is reviewed by the OMG and SDR Forum (www.sdrforum.org) working groups. In the long term, software-defined radio is expected by its proponents to become the dominant technology in radio communications.

6.2.1 Platform Overview

The SCA defines the Operating Environment (OE) and specifies the services and interfaces that applications use from that environment. The Common Operating Environment (COE) abstracts the software away from the hardware and provides a consistent interface to the waveform so that the waveform may be more easily ported between platforms. The OE is comprised of:

• POSIX-based Real Time Operating System (RTOS) with associated Board Support Package (BSP)

• CORBA Middleware layer • Core Framework (CF)



The OE imposes design constraints on waveform and other applications to provide increased portability of those applications from one SCA-compliant radio platform to another. The SCA also provides a building block structure for defining Application Programming Interfaces (APIs) between application software components. In particular, these elements are grouped as:

• Radio Devices (RD) • Radio Services (RS) • Radio Security Services (RSS)

These elements execute on the radio hardware as shown in Figure 14, and are discussed in more detail in the sections that follow. Figure 14 below depicts:

• On top part, an SCA compliant architecture comprising “red/black” partitioning for military secured data link

• On bottom part, an SCA compatible architecture that is proposed for this study, for which security aspects have been removed and more likely to fulfil the civil communication needs

Figure 14: Common Operating Environment (COE) Processing Elements

6.2.1.1 RTOS and BSP The Real Time Operating System (RTOS) chosen for this study is a COTS product, e.g. LynuxWorks’ LynxOS-178 (already level A certified). There is a



tailored BSP that allows this OS to execute on the underlying processing elements in the SDR.

6.2.1.2 CORBA Middleware Layer The Common Object Request Broker Architecture (CORBA) is a transport mechanism for moving data from one location to the next. The CORBA Middleware chosen for this study is a COTS product, e.g. OIS’ ORBExpress which is available for LynxOS-178. None are certified yet.

6.2.1.3 Core Framework The Core Framework (CF) is a “core” set of open software Application Programming Interface’s (API) to abstract out both the hardware and the OS. That is, the CF defines interfaces and profiles that provide for the deployment, management, interconnection, and intercommunication of software application components in embedded, distributed-computing communications systems.

6.2.1.4 Radio Devices Radio Devices (RD) abstract away the hardware in the system for both waveform and non-waveform applications. RD provides software applications with access to the hardware resources on the platform, (e.g., the Ethernet interface, the serial data interface, the frequency reference, eventually a GPS…). A significant element of the RD code is the Modem Hardware Abstraction Layer (MHAL), which provides an abstraction to the Modem Digital Signal Processor (DSP) and Field Programmable Gate Array (FPGA) hardware. The MHAL RD provides an interface for loading and unloading Modem DSP and FPGA, and for executing and terminating Modem DSP processes, as well as a push packet interface between the MHAL physical and logical destinations.

6.2.1.5 Radio Services Radio Services (RS) are a set of radio functions that are common across more than one waveform or support the field operation of an SDR system. Radio Services provide the platform with management and control capabilities. Examples of RS are presented in the following table.

Radio Service Description System Control Controls platform states and coordinates

application execution Fault Management Collects, stores, and manages reported

faults. Utilizing the SCA “runTest” mechanism, the Fault Management Service coordinates execution of Built In Test (BIT) on the platform.



Radio Service Description Configuration Monitors and stores installed and executing

applications. It allows updating of the installed platform and waveform software.

Simple Network Management Protocol (SNMP)

Manages the Management Information Base (MIB) data and provides external control elements access to it.

Time Management Collects time sources, chooses the best source, and distributes it through the system. The Time Management Service is used in conjunction with the Timing Device in a software managed time system.

Internet Protocol (IP) Routing Routes IP packet flow through the radio. Network Services COTS TCP/IP stack and route policy

supporting the Open Shortest Path First (OSPF) dynamic routing protocol.

Table 9: Radio Services in a Software Defined Radio

6.2.2 Certification Cost Estimates Matrix

6.2.2.1 Considerations There is no certified ORB available yet, and unlikely to be certified “as is” due to dynamic allocation of structures for instance. ORBExpress are working with Rockwell Collins as part of OMG on a “High Ensurance CORBA”. Likewise, there is no certified Core Framework available yet. Industry is actively working on “light core frameworks” that would be certifiable. A lot of initiatives and activities are ongoing for “Certified RTOS”. If few are available today or are quite expensive, more should be affordable in the future. Indeed, experience has shown that it may not be worth for an airborne equipment manufacturer to develop and get certified its own operating system. DDC-I (www.DDCI.com) propose (Nov-2008) certified RTOS with a dual strategy based on HeartOS (small to medium size embedded applications) and Deos (large size embedded applications, incl. secure radios). The pricing assumes DO-178 Level-A certification artifacts, one week of training, 3 development seats (floating) and one year's support:

• Deos: $250K USD • HeartOS: $150K USD

Same as above, Level-D:

• Deos: $100K USD • HeartOS: $60K

The user space IPv4/IPv6 stack is different from the IP stack used by the kernel, and will have to be certified separately.



6.2.2.2 Matrix The following matrix provides certification costs estimates for waveform software modules that are included in an SDR. These costs are established by application of metrics providing effort (person.day) based on the number of lines of source code (SLOC) depending on the design assurance level as proposed §5.5. The SLOC were computed using a Rockwell Collins France qualified tool, on a compilation of:

• Existing software modules (e.g. SDR, VDL4 transceiver, L22 modem) • Modules generated from Matlab/Simulink models (e.g. WiMAX PHY

and MAC Layer) • Open Source (e.g. ORB)

Module SLOC DAL D (p.d.)

DAL C (p.d.)

DAL B (p.d.)

DAL A (p.d.)

BASEBAND TX/RX Converters

Analog to Digital Conversion of IF to BB

100 2 2 3 4


100 2 2 3 4

MHAL DSP Interface 2500 38 60 86 104GPP Interface 2500 38 60 86 104Receive IF Interface (Sample, Gain Control)

3750 58 89 129 156

Transmit IF Interface (Sample, Gain Control)

3750 58 89 129 156

IEEE802.16e PHY Scrambler / Descrambler 600 9 14 21 25FEC CODEC15 (Reed-Solomon, Convol, Viterbi)

1100 17 26 38 46

Interleaver / De-interleaver 600 9 14 21 25Modulation Mapper, De-Mapper

700 11 17 24 29

OFDMA Symbol Generator 50 1 1 2 2Cyclic Prefix Addition / Removal

600 9 14 21 25

IFFT / FFT16 400 6 10 14 21Channel Estimation, Equalization (FEQ+DFE)

100 2 2 3 4

15 The number of SLOC estimated is for a generic FEC CODEC function, able to support any Reed-Solomon, Convolution, or Viterbi algorithm. 16 The number of SLOC estimated is for a generic IFFT/FFT function, able to support any FFT size supported by WiMAX. The adaptation will be part of the padding function that processes data upfront.



IEEE802.16e MAC Common Sub-Layer 8600 132 205 297 358Convergence Sub-Layer 15600 240 371 538 650Security Sub-Layer 8400 129 200 290 350

PROTOCOLS IPv6 Stack17 413000 6354 9833 14241 17208ORB & Middleware 580000 8923 13810 20000 24167Core Framework 16000 246 381 552 667Generated CORBA Code 44000 677 1048 1517 1833Radio Devices 2000 30 48 68 84

TRANSCEIVER MANAGEMENT Health Monitoring (BITE) 500 8 12 17 21

TOTAL 1104950 17000 26308 38102 46039

Table 10: SDR-based Solution Software Certification Cost Estimates The following tables provide expenses for RTOS certification and necessary development tools:

Description Cost (€)

Replay of LynxOS178 test suite 70 000 LynxOS178 Certification Package 320 000 DSP Software Development Tools 2 500 FPGA Software Development Tools 1 400 GPP JTAG Debugger 1 500

Note: As RCF benefits of negotiated agreements with LynuxWorks for LynxOS178 Certification Package.

Assuming a certified SDR basis, the certification of the IEEE802.16e waveform customization would represent the following costs:

Module SLOC DAL D

(p.d.) DAL C (p.d.)

DAL B (p.d.)

DAL A (p.d.)

BASEBAND TX/RX TOTAL 49450 762 1175 1702 2060

Table 11: IEEE802.16e Waveform Software Certification Cost Estimates

SDR implementations may vary form a manufacturer to another. Nevertheless, any parts (module) of the software identified above cannot run on any processing unit type, i.e. FPGA, DSP or GPP. A likely implementation is depicted Figure 15, using the processing units for what they are best suited would be:

• DSP, or DSP + FPGA, for signal processing, e.g. extraction, FFT, gain control…

17 The number of SLOC estimated for the IPv6 Stack covers the following set of RFC: RFC2460, RFC1987, RFC4291, RFC2385, RFC4443, RFC2475, RFC2597, RFC4213, RFC4301, RFC4302, RFC4303, RCF4305... Lighter IPv6 stacks are now available (Oct-08) for embedded products, e.g. uIPv6 by Cisco, Atmel and SICS (www.sics.se, www.ipso-alliance.org).



• FPGA for the waveform • GPP for the operating system, transceiver management, user IP stack



Figure 15: SDR-based Generic Transceiver Overview



6.3 COTS Products-based Development

This section addresses the implementation of the airborne IEEE802.16e radio using Commercial-Off-The-Shelf (COTS) WiMAX solutions. These solutions could be based on products such as Intel WiMAX Connection 2250 (www.intel.com) and Sequans SQN 1130 (www.sequans.com) as far as chipsets are concerned, or Proxim Wireless (www.proxim.com), Texas Instruments and Alvarion (www.alvarion.com) as far as boards are concerned. Greenhills (www.ghs.com) also proposes COTS software solutions (based on SDR/SCA) for WiMAX implementations.

6.3.1 COTS RF Chipsets

The following table lists COTS RF chipsets features provided by different manufacturers for WiMAX solutions.

Manufacturer Model

Analog Device AD9353

Atmel AT86RF535B

Texas Instruments TRF2436

Features

• RF transceiver with integrated ADC and DAC

• IEEE 802.16 WiMAX

• 3.3 GHz to 3.8 GHz

• 3.5 MHz < BW < 20 MHz

• Superior receiver sensitivity with NF 3.2 dB

• Highly linear and spectrally pure transmitter

• Tx EVM: −36 dB

• SNR > 134 dB/Hz at fOFFSET > 22 MHz

• Tx power control

• Range: 0 dB to 58 dB

• Resolution: 0.25 dB

• Autonomous AGC and Tx power control

• Single-chip 3.5GHz WiMAX Transceiver

• Fully Differential Design

• Low-IF/Zero-IF Transceiver Architecture; Requires No External Filters

• Self Calibration Mode for RX / TX Filters

• Support Channel Bandwidths of 3.5, 5.0, 7.0, 8.75MHz, and 10MHz

• Modulation up to 64QAM

• Highly Integrated 802.16 d/e Radio Frequency Front End ASIC

• Fully Integrated Up/Down Converters, LNAs, PAs and T/RSwitches

• Super Heterodyne Architecture for Superior Adjacent Channel Rejection Performance

• Frequency Range: 2.4 to 2.5 and 4.9 to 5.9 GHz

• Noise Figure: 4 dB ISM Band,6 dB 5 GHz Bands Typical

• Typical Gain: 38 dB TX, 20 dB RX

• IF = 374 MHz

Applicability Wideband is not in the 5091 and 5150 MHz band

Wideband is not in the 5091 and 5150 MHz band

Wideband OK

Remarks 64QAM Only High IF18 (374 MHz)

18 [Note EUROCONTROL] : High IF are common today seen the better image rejections they provide.



6.3.2 COTS Baseband Chipsets

The following table lists COTS Baseband chipsets features provided by different manufacturers for WiMAX solutions.

Manufacturer Model

Intel WiMax Connection 2250

Sequans SQN1130

Fujitsu 802.16e-2005 Mobile

WiMAX SoC

Features

PHY • OFDMA 512/1024 PHY mode with support for channel

• Bandwidths up to 10 MHz

• Support for TDD and H/FDD duplexing modes

• PUSC with all subchannels and dedicated pilots, FUSC,

• AMC 2x3 for AAS Beam Forming support

• Concatenated Reed-Solomon and Convolutional

• Encoding Forward Error Correction

• Adaptive modulation (BPSK, QPSK, QAM16, QAM64)

• Enhanced link budget support

PHY • S-OFDMA PHY with 512 and 1024-point FFT

• Supports 2 Rx antennas and 2 Tx antennas

• MIMO: Matrix A + MRC, Matrix B,

• Collaborative MIMO

• TDD with a configurable UL/DL split

• Adaptive QPSK, 16QAM and 64QAM modulation

• Fast feedback channel

• H-ARQ

• Fast scanning

• Analog IQ interfaces with integrated A/D and D/A converters

PHY • 512/1024 FFT OFDMA PHY with MAC processors

• Support for 5MHz and 10MHz channel bandwidth

• Adaptive modulation schemes including 64QAM, 16QAM and QPSK

• Programmable automatic gain control (AGC) supporting a broad range of RF attenuators

• Support for 2x2 STC/MIMO

• Support for antenna diversity



Manufacturer Model

Intel WiMax Connection 2250

Sequans SQN1130

Fujitsu 802.16e-2005 Mobile

WiMAX SoC

MAC

• Payload Header Suppression

• IPv4, IPv6, 802.3 Convergence Sub-Layers

• ARQ, HARQ

• UGS, RT-VR, NRT-VR, ERT-VR, and BE QoS classes

• Sleep and Idle mode power management support

• 802.16 Authorization Policy and EAP Authorization

MAC

• Layer-2 packet forwarding

• AES-CCM encryption

• PKMv2 privacy protocol

• Real-time services

• Concatenation, fragmentation, packing

• Automatic repeat request (ARQ)

• Payload header suppression (PHS)

• Advanced QoS features

• Optimized handover

• Sleep mode

• Idle mode

MAC

• Security implementation based on AES-CCM encryption/decryption

Applicability Remarks

Table 12: COTS RF and BB Chipsets Features


Although the identified COTS chipsets in their actual version do not have all the required features for the implementation of the IEEE 802.16e avionics radio (frequency is not matching IEEE 802.16e requirements for C-band frequency between 5.091 and 5.150 GHz) except for Texas Instruments’ TRF2436 front end, the gap is very thin to fill and this is not considered as a limiting factor for using COTS WiMAX chipsets to develop a COTS radio in the future.

The driving principle is to replace software elements of the SDR radio with commercial chipsets integrated on a single board. The proposed solution is based around the following architecture:

• a COTS RF chipset, e.g. TI’s TRF2436 • a COTS Baseband chipset, e.g. Sequan’s SQN1130, • a COTS microcontroller, e.g. ATMEL ARM9, hosting



o a micro kernel, e.g. Micrium’s uC/OS II o the transceiver management software o a light IPv6 stack, e.g. CISCO’s uIPv6

Figure 16 COTS based architecture

The proposed microcontroller is for instance an ATMEL ARM9 or ARM11 32-bit controller to pilot the selected chipsets. A light Real Time Operating System (RTOS) without time and space partitioning would fit the required real time constraints for the COTS based solution. A possible solution for this COTS-based design could be the uC/OS-II micro kernel (Micrium), which is already DO178-B Level A certified (existing certification package provided by Micrium). A possible IPv6-ready protocol stack for this COTS-based solution could be the CISCO uIPv6 stack which is released under an open-source license. It can fit on the most constrained platforms thanks to its 11.5 Kb code size and required 2 Kb of RAM. Estimated number of SLOC is around 2300, which is significantly less than the SLOC of classical IPv6 stack proposed for the SDR solution. Nevertheless, this stack will not comprise all RFC listed §5.8.2.

6.3.4 Identified issues

The use of COTS WiMAX chipsets for this solution raises the issue of DO-254 certification for DAL higher than DAL D as none are certified yet. This implies either:



• to get the certification package from the chipset provider (with additional cost): this is unrealistic considering that, today, Texas or Intel components are dedicated to mass marketing and that the chipsets manufacturers have no interest in certifying these chipsets for avionics use (limited market for these components in comparison to certification effort, liability concerns),

or

• to certify the COTS chipset by performing all the certification tasks required for DO254 compliance (time consuming engineering effort especially for verification activities): this is constrained by the possibility to retrieve source code files of all functions from the chipset manufacturer. It is foreseen that parts of the design will be hidden.

This issue may limit the candidates for COTS RF and Baseband chipsets selection. Electronic chipset manufacturers such as Intel or Motorola have been pioneers in design and quality assurance processes for hardware and software design. Electronics manufacturers were granted CMMI Level 3, and even 5, well before the aeronautical industry. Their design process, based on ISO-9001 or similar (e.g. ISO/TS 16949:2002), is comparable to the design process recommended by both DO-254 and DO-178B. However, their verification level is at most comparable with DAL C. Nevertheless, it is unlikely these manufacturers will provide their artefacts, and it will be difficult to justify a level higher than DAL D to the authorities.

6.3.5 Pros and cons

There are pros and cons in implementing the IEEE 802.16e avionics radio using COTS WiMAX chipsets, as summarized hereafter.

Simpler hardware design: no required expertise for RF / Baseband functions / simplified interface Compact hardware design Simpler integration task: integrated function

Pros

Limited choice of COTS chipsets for certification constraints: availability of all design artefacts and source code files Higher price for chipset purchase

Cons

Difficult to justify certification higher than DAL D.

Table 13: COTS-based Solution Pros and Cons


The following table provides expenses for uC/OS-II certification package:



Description Cost (€)

uC/OS-II Certification Package (Level A to Level D) 30 000 Note: As RCF already owns a Certification Package (that was used for another RCF product), the uC/OS-II Certification Package for the IEEE 802.16e avionics is sold with a special rate of 15 000€. Verification tasks and associated effort, which are known to be very time consuming within a certification process, are expected to be of same level than the ones estimated for the SDR solution, limited to DAL D (should DAL D be considered by the authorities).

Module SLOC DAL D

(p.d.) DAL C (p.d.)

DAL B (p.d.)

DAL A (p.d.)

BASEBAND TX/RX Converters


N.A 2 N.A N.A N.A


N.A 2 N.A N.A N.A

IEEE802.16e PHY Scrambler / Descrambler N.A 9 N.A N.A N.AFEC CODEC (Reed-Solomon, Convol, Viterbi)

N.A 17 N.A N.A N.A

Interleaver / De-interleaver N.A 9 N.A N.A N.AModulation Mapper, De-Mapper

N.A 11 N.A N.A N.A

OFDMA Symbol Generator N.A 1 N.A N.A N.ACyclic Prefix Addition / Removal

N.A 9 N.A N.A N.A

IFFT / FFT N.A 6 N.A N.A N.AChannel Estimation, Equalization (FEQ+DFE)

N.A 2 N.A N.A N.A

IEEE802.16e MAC Common Sub-Layer N.A 132 N.A N.A N.AConvergence Sub-Layer N.A 240 N.A N.A N.ASecurity Sub-Layer N.A 129 N.A N.A N.A

PROTOCOLS IPv6 Stack CISCOμIPstack 2300 40 N.A N.A N.A

TRANSCEIVER MANAGEMENT Health Monitoring (BITE) 500 8 N.A N.A N.A

TOTAL N.A 617 N.A N.A N.A

Table 14: COTS Chipsets-based Solution Software Certification Cost Estimates COTS-Chipsets implementations may vary form a manufacturer to another. Nevertheless, a likely implementation, depicted Figure 17, could be based on the overview description above (§6.3.3.



Figure 17: COTS Chipsets-based Generic Transceiver Overview

6.3.7 Alternative COTS Platform Overview

An alternate solution is to integrate a COTS IEE802.16e board into an avionics grade “box” that would provide chassis, power supply and power amplification, as well as connectors. This was done for introduction of WiFi components for gatelink solutions. These cannot be certified, and DO-254/DO-178B DAL E only applies. Such equipment is nevertheless DO-160E qualified for airworthiness aspects.



6.4 FPGA-based Development

The use of FPGA has revolutionized the way DSP subsystems are configured. With a large number of gates, hardware multipliers and high-speed serial interfaces, an FPGA can outperform a microprocessor by a factor of ten or more. FPGA are applicable to a variety of applications including radar, signal intelligence and image processing that have elements of computing that are characterized by repetitive fixed-point processing that can be expressed in highly parallel form. FFT, pulse compression, filters, and digital down converters are examples of functions that FPGA perform well. In deployed systems, this technical advantage translates to smaller, lower-power and lower-cost systems. Notes:

• Standard grade19 XILINX and ALTERA FPGA use SRAM technology, are sensible to heavy ionospheric particles, and include CRC monitoring. Some airframers (e.g. Airbus) pay great attention on the design of avionics using those chipsets20, and even forbid them.

• ACTEL use Flash technology, which is not sensible to heavy ionospheric particles. Nevertheless, these chipsets show lower performance than their competitors and are not likely suited for complex signal processing.

Though XILINX (and others) can provide IP based on MathWorks’ Simulink model-based development (MBD) tool for their Virtex family FPGA, developers of certified solutions will more likely reuse legacy processing modules (e.g. FFT) than redesign and auto-code one using a non certified model-based environment. These MDB suites can indeed deliver object code for DSP and FPGA, but none are today qualified for DAL higher than DAL D. Though the automatic code generation features of such tools have become extremely efficient, the code generated is far from being optimal and often necessitates re-writing. Use of MBD auto-coding is not yet suited for certifiable solutions, but accelerates the prototyping phases at the beginning of a new development project, i.e. proof of concept phases. If these components are quite expensive (approx10 k$) and could be disregarded as solutions for avionics by manufacturers, today, their use in commercial products could make them more affordable in the future.


Though there is little experience on use of chips such as Xilinx’s Virtex 4 or Virtex 5 (www.xilinx.com) embed FPGA, DSP core and PowerPC core in avionics systems components, the features these chips offer are those commonly used in wireless communication systems, and may be the basis for

19 Xilinx has today high performance devices available –QPRO- being able to withstand up to 250 krad Si, which is enormous. These are nevertheless meant for defense and aerospace markets, rather than commercial aeronautics markets. 20 [Note EUROCONTROL]: ARINC 818 – Digital Video Bus – is designed around FPGA. It is foreseen they will eventually be used in the near future.



Software Defined Radios (SDR) as discussed §6.2. These chips could ideally host and run the whole software defined radio software by themselves in a small form factor platform. However, relevance of SWaP-C considerations for the C-band IEEE802.16e radio to be fitted in a 3-MCU or larger chassis is questionable. A platform overview of a “Virtex FPGA-based” transceiver as proposed by Xilinx (www.xilinx.com) is depicted Figure 18.

Figure 18: “Virtex FPGA-based” Generic Transceiver Overview


As discussed §5.3.3, should these integrated FPGA be considered airworthy, e.g. through In Service Experience, certification costs of the software they host and run would be similar to the costs of a “conventional” SDR.



6.5 Reprogrammable Processor-based Development

picoChip (www.picochip.com) provides PC6530 system reference designs for a complete software-defined IEEE802.16e implementation, including PHY and MAC layers, i.e. a single chip baseband module. These designs allow customers to easily develop a final product based upon a series of standard deliverables. Indeed, the PC6530 comprises a WiMAX compliant basestation MAC and PHY entity. These entities are derived from the IEEE802.16e-2005 OFDMA specification, and are designed to comply with the WiMAX Forum profile for interoperable certification. These chips are meant for cost effective implementations, since they integrate a “whole” transceiver on a single chip as depicted Figure 19: picoChip's PC6530 Overview (source picoChip).

Figure 19: picoChip's PC6530 Overview (source picoChip)


A “picoChip-based” transceiver would basically be close to the COTS Chipset based transceiver discussed §6.3.3, but with most front-end and baseband features performed by the same chip. Some adaptations will be necessary on the front-end side (e.g. power amplification), and a microcontroller will control the chip and add the light user IP stack. Figure 20 provides an overview of the “picoChip-based” transceiver concept.



Figure 20: “picoChip-based” Generic Transceiver Overview


These chips are considered as ASICS as they embed the software they run, whereas microprocessors run software from external memory and they are far too sophisticated to be part of the microcontroller family as defined §5.3.4. As such, certification costs should be similar to those established for the COTS-based solution, §6.3.6.



7. CERTIFICATION COST ESTIMATES SUMMARY

7.1 Summary

As can be read in the first chapters of this document, standards used for avionics certifications are evolving (and even still in progress, i.e. DO-178C) as the study is being performed. Though industry and certification authorities have established certification standards (i.e. DO-178B and DO-254), these same organisations are issuing guidelines and clarifications for applicability of these standards (i.e. CATS papers and CRI). The aim is indeed to adapt (simplify) the process for simple designs on one hand, and make sure complex ones are rigorously handled on the other, hence reduce certification costs still maintaining airworthiness objectives). As hardware development recommendations (i.e. DO-254) are foreseen to reflect those issued for software development (i.e. DO-178), both software and hardware development methods (incl. design and verification) and tools are converging and look very similar (i.e. same MDB suites generating either C code for software platforms, and VHDL for hardware platforms). Advanced technologies are emerging from most electronic components manufacturer involved in digital processing (e.g. Xilinx), commercial wireless solutions (e.g. Sequans, picoChip) or both (e.g. Intel). These technologies enable highly integrated designs, and their price could be attractive for radio manufacturers as they spread. However these sophisticated commercial components are difficult to certify on safety critical developments, since they were not designed to meet the airworthiness criteria required in avionics using recommended processes.

7.2 Conclusions

7.2.1 Future Standards and Processes

If today, DO-254 is not applicable for DAL-D ASIC and FPGA through application of Advisory Circulars, CRI and other guidelines which would “zeroize” certification costs for DAL-D developments, it is foreseen next “DO-254A” release will be as stringent for hardware as DO-178C will be for software. Also, it is foreseen in the near future that Model Based Development techniques and associated qualified tools will be used following similar processes and will produce similar artefacts for both hardware and software. “Pressing a button” will produce indifferently certified code for a general purpose processor or for an FPGA, once the model has been thoroughly verified. If so, DO-254A certification costs should be similar to DO-178C certification costs at equivalent DAL.



Nevertheless, though a branch of the standard “V” process as been “sawed” by developing with MBD techniques, it is not sure certifications cost will be much lower than presently. Indeed, the verification activities (which basically make the costs) will have to be performed anyway, even if slightly easier to perform on the model itself than they were on the code and executable.

7.2.2 Platforms and Certification Costs Estimates

It is today very difficult and risky to project what certification costs will be in the evolving environment in which technology runs much faster than standardisation, and economical considerations need to be taken into account. What would have seemed initially an “arithmetic” exercise (sum of SLOC numbers multiplied by metrics) turned out to be investigations for what is to be expected in the near future in terms of recommended practices, methods and tools ending in a “not that crystal clear crystal ball” exercise. Hence the figures provided in this document are best guesses of what RCF foresees in the next future during which IEEE802.16e C-band radios would be developed. These figures are based on the following assumptions:

• DO-254 and DO-178 certification costs are likely similar (same objectives, same process, same artefacts, same tools)

• Use of MBD suites will not significantly reduce the overall certification costs (less code verification, but greater model verification)

• COTS chipsets (e.g. TRF2436 and SQN1130) and reprogrammable devices (e.g. PC6530) can only be used on DAL D designs (no detailed artefacts available from the manufacturers) based on their In Service Experience in commercial mobile wireless IEEE805.16e equipment

• Sophisticated FPGA (e.g. Virtex5) embedding FPGA, DSP and microprocessor cores will be qualified as FPGA (DO-254) for their logical processing features, and as microprocessors and DSP (DO-178C) for their general purpose and digital processing features

As far as the lower layers, i.e. front end and baseband modules, are concerned, all solutions are equivalent as long as the aim is developing and certifying a DAL D transceiver. The main cost driver (ref. §6.2.2) is the higher level protocol stacks (i.e. IPv6) and the SCA modules of a software defined radio. These were only considered for the SDR-based solution and possibly for the “Virtex FPGA-based” solutions, which are the only solutions foreseen to be certifiable at levels higher than DAL D. However, the numbers will remain extremely high (several M€), as long as no certified IPv6 stack and ORB are available. Issues, pros and cons for the different platforms as well as associated certification cost estimates are summarized in the following tables.



SDR-based Development Issues • ORB:

o No certified ORB available o ORB not certified “as is” (dynamic allocation)

• Core Framework: o No certified CF available

• RTOS: o Few Certified RTOS available, and quite expensive

• IP Stacks: o Different from kernel IP stack, hence to be certified

separately

Pros • Standard Architecture • Adapted to support multiple waveforms (maybe not

relevant for Mobile WiMAX only)

Cons • Huge software

COTS-based Development Issues • DO-254 DAL-D only

o no chipset qualified o no certification package available

Pros • Simple hardware design

• Compact hardware design (maybe not relevant for 3+ MCU)

• Simple integration

Cons • Limited choice of COTS chipsets • High prices for chipset purchase (today) • Difficulty to justify level higher than DAL-D • Will require In Service Experience justification of the chip

to enable their use in critical avionics solutions

FPGA-based Development Issues • Potential sensitivity to heavy particles Pros • Integrated devices

o “SDR on chip” (maybe not relevant for 3+ MCU)

Cons • Price (today) • Will require In Service Experience justification of the chip

to enable their use in critical avionics solutions Reprogrammable Processor-based Development

Issues • DO-254 DAL-D only o no chipset qualified o no certification package available



Pros • Simple hardware design • Compact hardware design (maybe not relevant for 3+

MCU) • Simple integration

Cons • Limited choice of COTS chipsets

• High prices for chipset purchase (today) • Difficulty to justify level higher than DAL-D • Will require In Service Experience justification of the chip

to enable their use in critical avionics solutions

Table 15: Issues, Pros and Cons of Each Platform Two transceivers classes have been identified:

1. DAL-D only capable: developed using COTS-based or Reprogrammable solutions, highly integrated and supported by minimal software

2. DAL-C (and higher) capable: developed using SDR compatible architecture, either through split FPGA/DSP/GPP or through integrated FPGA architectures and supported by full featured software

Certification costs effort main figures (expressed in person.day) for the two classes are summarized in the following table. Min and Max values are also provided for the “SDR platforms” by applying different metrics listed earlier (§5.5).

Function / Module Number Of SLOC

COTS DAL-D

SDR DAL-D

SDR DAL-C

SDR DAL-B

SDR DAL-A

9 13 15 16 9 14 21 25

Scrambler Descrambler

600 NA

9 15 30 50 17 24 28 30 17 26 38 46

FEC CODEC 1100 NA

17 28 55 92 9 13 15 16 9 14 21 25

Interleaver De-Interleaver

600 NA

9 15 30 50 9 13 15 16 9 14 21 25

Mapper De-Mapper

600 NA

9 15 30 50 1 1 1 1 1 1 2 2

OFDMA Symbol Generator

50 NA

1 1 3 4 9 13 15 16 9 14 21 25

Cyclic Prefix Add / Removal

600 NA

9 15 30 50 6 9 10 11 6 10 14 17

IFFT FFT

400 NA

6 10 20 33 Channel Estimation 100 NA 2 2 3 3



Function / Module Number Of SLOC

COTS DAL-D

SDR DAL-D

SDR DAL-C

SDR DAL-B

SDR DAL-A

2 2 3 4 Equalization 2 3 5 8 130 187 221 232 132 205 297 358

MAC Common Sub-layer

8600 NA

134 215 430 717 236 339 400 422 240 371 538 650

MAC Convergence Sub-layer

15600 NA

244 390 780 1300 127 183 215 227 129 200 290 350

MAC Security Sub-layer

8400 NA

131 210 420 700 6258 8978 10590 11162 6354 9833 14241 17208

IPv6 Stack (full) 413000 NA

6453 10325 20650 34417 NA NA NA NA NA NA NA NA

IPv6 Stack (µIPv6) 2300 40

NA NA NA NA 8788 12609 14872 15676 8923 13810 20000 34417

ORB and Middleware

580000 NA

9063 14500 29000 48333 242 348 410 432 246 381 552 667

Core Framework 16000 NA

250 400 800 1333 667 957 1128 1189 677 1048 1517 1833

Generated CORBA Code

44000 NA

688 1100 2200 3667 30 43 51 54 31 48 69 83

Radio Devices 2000 NA

31 50 100 167 16 575 23 782 28 050 29 56616 830 26 046 37 772 45 581

Total 1093950 4021

17 093 27 349 54 698 91 163Other Costs (Efforts person.day)

Environmental Qualification 140 140 140 140 140Other Costs (Expenses k€)

Environmental Qualification 50 50 50 50 50

Table 16: Major Certification Costs for COTS-based and SDR-based Platforms

7.3 Recommendations

RCF would recommend EUROCONTROL perform a Functional Hazard Analysis (FHA) and work with RCF on DAL allocation to the foreseen radio platforms. Indeed, current ATC radios are DAL-C. Also, even for aerodrome

21 This is a theoretical value corresponding to the DO-178 part, since DO-254 would not apply to COTS DAL-D. Actually, standard engineering practices include a minimum set of “black box” verification activities in this case estimated approx. 550 person.day.



surface operations, ATC digital communications may be safety critical (e.g. taxi-routing, clearances…) as runway incursion is a big concern for all ATM stakeholders. RCF would also recommend EUROCONTROL and RCF work on a Feasibility Study as follow-on activity in order to perform:

• Cost and Business Analysis of COTS-based platforms which seem promising on a certification standpoint for DAL-D platforms. Implementation of these chipsets should nevertheless be looked into thoroughly, especially with regard to maintainability of the platform as well as impact on upgrade. In Service Experience information should be collected. Also, turn-over rate and obsolescence of these commercial components with much shorter life-cycles than avionics need to be considered. Radio architecture alternatives based on COTS chipsets should be assessed to reach an equivalent DAL-C through redundancy for instance. Indeed, redundant architectures provide a higher equivalent DAL. It could be assessed if worth (i.e. cost efficient) whether to have two cross-linked DAL-D radios on board or to have a single DAL-C radio built on redundant (dissymmetrical) DAL-D COTS, based on a “D+D=C” principle.

• Future Communication System Functional Analysis to discuss the overall ATC / AOC communication means foreseen to be required beyond 2020+. Indeed, it is expected at least a C-Band IEEE802.16e radio is required for aerodrome operations and at least an L-Band (LDACS-1 or LDACS-2) radio is required for airborne operations. For long-haul flights, a SATCOM radio will also be necessary. All communications will more than likely be through Mobile IPv6 protocols. Hence, it should be assessed whether each radio should host the IPv6 stack, or if that stack could be hosted by an external unit as it is the case today for the ATN stack hosted by Communication Management Units (CMU). Certification costs of the stack would have to be supported once for the CMU, and not for each data link radio.

--- End of Main Document ---


Edition Number: 1.1 Issue 1 Page: C-1

APPENDIX

ASFA Airborne SDPD Industry Information Synthesis and Analysis Report


8. APPENDIX 1: SDR DATA

8.1 Terminology

Core Framework The Core Framework is the essential (“core”) set of open application-layer interfaces and services to provide an abstraction of the underlying software and hardware layers for software application designers. CORBA (Common Object Request Broker Architecture) CORBA provides platform-independent programming interfaces and models for portable distributed-oriented computing applications. CORBA is the middleware of the SCA OE. Its independence from programming languages, computing platforms, and networking protocols makes it highly suitable for the development of new applications and their integration into existing distributed systems. CORBA has associated with it some unique terminology; the most important of which is explained in the following list. − A CORBA object is a “virtual” entity capable of being located by an ORB and having client requests invoked on it. It is virtual in the sense that it does not really exist unless it is made concrete by an implementation written in a programming language. − A target object, within the context of a CORBA request invocation, is the CORBA object that is the target of that request. − A client is an entity that invokes a request on a CORBA object. − A server is an application in which one or more CORBA objects exist. − A request is an invocation of an operation on a CORBA object by a client. − An object reference, also known as an IOR (Interoperable Object Reference) is a handle used to identify, locate, and address a CORBA object. − A servant is a programming language entity that realizes (i.e., implements) one or more CORBA objects. Servants are said to be incarnate CORBA objects because they provide bodies, or implementations, for those objects. Servants exist within the context of a server application. In C++, servants are object instances of a particular class. CORBA Component A software component that implements CORBA interfaces (facets). A CORBA component is described by a Software Component Descriptor. A CORBA component encapsulates its internal representation and implementation; it provides a well-defined interface (operations, attributes, exceptions, and events) to component clients via CORBA IDL. Device (SCA Device) 1. Hardware device refers to a physical hardware element (typically a module performing a function or set of functions identified in its Device Profile). 2. The SCA defines a Device interface class. This logical Device interface is an abstraction of a hardware device that defines the capabilities, attributes, and interfaces for that device. IDL (Interface Definition Language) The OMG IDL is CORBA’s fundamental abstraction mechanism for separating object interfaces from their implementations. OMG IDL establishes a contract between client and server that describes the types and object interfaces used by an application. This description is independent of the implementation language, so it does not matter whether the client is written in the same language as the server. IDL Definitions are compiled for a particular implementation language by an IDL compiler. The compiler translates the language-



independent definitions into language-specific type definitions and APIs (Application Program Interface). These type definitions and APIs are used by the developer to provide application functionality and to interact with the ORB. The translation algorithms for various implementation languages are specified by CORBA and are known as language mappings. CORBA defines a number of language mappings including those for C++, Ada, and Java (along with many others). An IDL compiler produces source files that must be combined with application code to produce client and server executables1. Details, such as the names and numbers of generated source files, vary from ORB to ORB. However, the concepts are the same for all ORBs and implementation languages. The outcome of the development process is a client executable and a server executable. OMG (Object Management Group) In 1989, the OMG was formed to address the problems of developing portable distributed applications for heterogeneous systems. It is now the world’s largest software consortium, with more than 800 members. Two key specifications produced by the OMG, the OMA (Object Management Architecture) and its core, the CORBA specification, provide a flexible architectural framework that accommodates a wide variety of distributed systems. Real-Time CORBA Real-Time CORBA is an emerging specification that provides additional interfaces to support typical real-time controls such as priorities, thread pools, and guaranteed message transfer times. Real-Time CORBA does not guarantee necessarily high-performance speed of operations. Waveform (SCA definition) A Waveform is the set of transformations applied to information that is transmitted over the air and the corresponding set of transformations to convert received signals back to their information content. XML (eXtensible Markup Language) XML is a markup language designed specifically for delivering information over the World Wide Web. XML is used within the SCA to define a profile for the domain in which waveform applications can be managed. XML’s definition consists of only a bare-bones syntax.When you create an XML document, rather than use a limited set of predefined elements, you create your own elements and assign them any names you like – hence the term extensible. You can therefore use XML to describe virtually any type of document, from a musical score to a digitally-programmable radio. However, for an SCA compliant environment, this extensibility is limited to the SCA-defined Document Type Definitions (DTDs). A DTD provides a list of the elements, attributes, notations, and entities contained in a document, as well as their relationship to one another. DTDs specify a set of rules for the structure of a document. The DTD defines exactly what is allowed to appear inside a document.



9. APPENDIX 2: COTS PRODUCTS DATA

9.1.1 RF Modules: TI’s TRF2436



9.1.2 Baseband Modules: Intel’s 2250



9.1.3 Baseband Modules: Sequan’s SQN-1130



10. APPENDIX 3: FPGA DATA

10.1.1 FPGA: Xilinx’s Virtex4



10.1.2 FPGA: Xilinx’s Virtex4-QPro



11. APPENDIX 4: REPROGRAMMABLE PROCESSOR DATA

11.1.1 Reprogrammable Processors: picoChip’s PC6530



12. APPENDIX 5: TOOLS AND COTS SOFTWARE

12.1.1 FPGA Design: Mentor Graphics’ ModelSim Designer



12.1.2 Model-Based Development: Esterel’s SCADE Suite



12.1.3 ORB: OIS’ ORBexpress (FPGA version)



12.1.4 OS: LynuxWorks’ LynxOS-178

certification cost estimates for future communication ... cost estimates for future communication...

Documents