Requirements for Intellectual Properties in Safety Critical Airborne Electronic Hardware

This paper will explain some issues related to Intellectual Properties (IP) which are part of complex components (ASIC, PLD, FPGA, microprocessors) in the domain of airborne electronic hardware.

The first part of the paper will explain the certification principles for civil aircraft, and will highlight some considerations in recent civil aircraft programs and will detail some issues concerning the usage of intellectual properties in safety critical applications, the airworthiness requirements, and give some possible answers.

The second part of the paper will propose an assessment process for intellectual properties, which indicates some constraints for both users and designers.

The last part of the paper will explain the challenge to face for future embedded electronics such as system on chip and intellectual properties in safety critical applications.

1 - Introduction

The use of increasingly complex electronic hardware for more of the safety critical aircraft functions generates new safety and certification challenges.  These challenges arise from a concern that said aircraft functions may be increasingly vulnerable to the adverse effects of hardware design errors that may be increasingly difficult to manage due to the increasing complexity of the hardware.  To counteract this perceived escalation of risk it has become necessary to ensure that the potential for hardware design errors is addressed in a more consistent and verifiable manner during both the design and certification processes.
For aircraft programs, such as Airbus A340-500/600, A380 and A400M, and now A350, the document DO-254 [RD1] has been applicable.
Airworthiness Authorities in the AC 20-152 [RD2] have detailed the scope of DO-254 [RD1] in hardware certification.
Complementary CAST papers ([RD3] and [RD4]) written by Airworthiness Authorities precise also the use of [RD1] in airborne electronic hardware domain.

As airborne electronic hardware becomes more complex, technology evolves and experience is gained in the application and use of the procedures described in  [RD1]. New emerging technologies, such as IP or SOC, used by aeronautical industries, should be taken into account in the scope of certification for airborne electronic hardware.

For integrating an IP core in a  [RD1] compliant design, the applicant needs to assess if the IP:

• Is managed, designed and verified with the same level of confidence as the PLD itself, or
• Needs additional data and/or re-generated through additional activities, in order to reach the desired level of confidence.

This document collects non-technical requirements for an IP used in critical airborne equipment. Technical Requirements are collected in the technical specification.  Its content can be used as a checklist and discussion guidance between the applicant and the IP providers: it presents data and activities related to IP management and integration, the discussion for a given project will determine the work sharing.

1.1 - Definitions

In this paper we do not address “Verification IPs”, that can be seen as a set of test benches coming with an IP. Those IPs should be addressed and properly assessed in the framework the Verification strategy.

In this paper  the applicant is the user of the IP.

2 – certification principles

2.1 - Certification considerations

To operate for the purpose of commercial air transportation, airplanes need a certificate delivered by an Authority that acknowledges that it meets all the applicable airworthiness requirements.

The certification is the legal recognition by the Certification Authority that the aircraft and its systems and equipments comply with the requirements. In particular, certification involves the assessment process of the design to ensure that it complies with a set of standards applicable to that type of product so as to demonstrate an acceptable level of safety.

In some programs, the certification liaison is not provided by the equipment manufacturer, but by the airframe or other customer with the equipment manufacturer in a supporting role. It is the responsibility of the applicant for certification to ensure that data is provided to the certification authority.

When some hardware items embedded in the equipment are procured from a subcontractor, the certification plan should identify which data are expected from the subcontractor and which are to be generated by the applicant.

Digital Devices and Mixed Signal Devices (IP, Integrated circuit, ASSP, ASIC, FPGA and PLD components) are significantly used in electronic equipments, which have functions that can affect the safety of the aircraft. These devices are more and more complex so aircraft functions may be increasingly vulnerable to the adverse effect of hardware design errors. It has become necessary to ensure that the potential design errors are taken in account and that the design and maintenance processes (including configuration management) are mastered.

The  [RD1] addresses IPs as COTS. General considerations about COTS are included in § 11.2: “COTS components are used extensively in hardware designs and typically the COTS components design data is not available for review. The certification process does not specifically address individual components, modules, or subassemblies, as these are covered as part of the specific aircraft function being certified. As such, the use of COTS components will be verified through the overall design process, including the supporting processes, as defined in this document. The use of an electronic component management process, in conjunction with the design process, provides the basis for COTS components usage.”

IP considerations can be refined for a given aircraft program, adding more requirements. For instance during A380 program, an agreed set of requirements indicated that “…the rigour of the development processes for a COTS (which also includes 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...”

Some new (compared to other programs) following characteristics have been justified and documented : the development assurance level of the hardware functions which are supported, specifically if lower than the development assurance level allocated to the equipment, the complexity (functional, physical), the In Service Experience.

Data requirements have also been documented : Electronic Component Management as recommended by  [RD1] §11.2, Product Service Experience as recommended by  [RD1] §11.3.

2.2 - Design Assurance level

There are five system Design Assurance Levels, (DAL), Level A through Level E, respectively corresponding to the five classes of failure conditions: catastrophic, hazardous/severe-major, major, minor, and no effect.

When an IP is a part of a complex digital component (ASIC, SOC, FPGA…) the same visibility should be given than the components itself.  

The expected data for the IP can be modulated according to the DAL of the design in which the IP is used.

3 - IP assessment process

Experience in IP assessment regarding certification shows that three different approaches can be proposed to meet requirements for IP in critical airborne electronic hardware :

• The IP is developed and verified according to a structured approach compliant with  [RD1] objectives,
• The IP has a relevant Service Experience,
• The IP is re-engineered to provide requested data.

In addition to these three approaches, architectural mitigation techniques at upper level can be used. In each case the applicant should present and justify to the authority the strategy to be used.

Note: it is recommended that the applicant always consider service experience. This approach can be a perfect complement to others. If data exist regarding service experience, this should be claimed and presented for certification credit.



Figure 1 : IP assessment process

Step 1: The IP can have been designed according to a structured approach. If yes, IP design life cycle and produced data should be presented in order to decide if the structured approach and associated data are compliant with  [RD1] objectives. See Section 4 for more details.

Step 2: Presentation of the structured approach

The IP provider presents to the applicant the IP development life cycle, and the associated data. Data considered is the one that can be submitted, but also the internal one that can be made available for an audit. Evidence shall be provided, so no credit can be given to a data mentioned in the presented life cycle but that can be neither submitted nor made available.

Step 3: Evidence should be provided that IP design has a relevant service experience. If yes, IP service experience data should be presented. See Section 5 for more details

Note: it is recommended for the applicant to always consider service experience. This approach can be a perfect complement to others. If data exist regarding service experience, this should be claimed and presented for certification credit.

Step 4: Document Service Experience

This step is made explicit to highlight that evidence must be provided for service experience. Relevant information must be gathered, analyzed as relevant and documented.

Step 5: Are architectural mitigation techniques employed?

If yes, evidence should be provided that the implemented architectural mitigation techniques mitigate design errors in the IP core. See Section 6 for more details.

Note: If the probability for reuse of the IP core is high, regeneration of hardware life cycle data may be the preferred approach rather than using architectural mitigation techniques.

Note: It is recommended for the applicant to always consider used architectural mitigation techniques to complement other approaches. If architectural mitigation techniques are used to mitigate for design errors, this should be claimed and presented for certification credit.

Step 6: Document architectural mitigation strategy

Document the rationales for the architectural mitigation techniques used. Information must be gathered, analyzed as relevant and documented.

Step 7: Regenerate hardware life cycle data

If IP design neither does have a structural approach producing the expected amount of data, nor a relevant service experience, nor architectural mitigation techniques that can be demonstrated, then additional reverse engineering activities should be performed. See section 7 of this document for more details.

Step 8: If the conclusion of the lifecycle presentation is that all the data necessary for  [RD1] compliance is available, the applicant will document the results of this review. No further assessment is necessary.

Step 9: At this step it may be helpful to reconsider mitigation techniques: It can still be an alternative to the re-generation of missing data, that can represent an important effort.

Step 10 : The strategy and the conclusions of the IP assessment shall be documented.

4 - Strategy based on IP Design Life Cycle Processes

4.1 - Purpose

The design life cycle ensures that the potential for design errors is addressed in a more consistent and verifiable manner. Each process should be addressed to reduce the probability of design and implementation errors that affect safety.

The  [RD1]document includes a default life cycle.

The IP provider can have its own development life cycle, Process Assurance and Quality Assurance processes.

The assessment will be performed through data-oriented and objectives-oriented approaches. It means that the IP provider’s development process can be considered as acceptable provided that it meets the objectives and produces the data described in Table 2.

4.2 - Life Cycle Process

When the IP’s have been developed with a structural approach, this approach needs to be documented and the following processes shall be clearly presented and detailed, especially concerning the activities performed, transition criteria and activity outputs.

[RD1] defines processes :

• Design processes are requirements capture, conceptual design, detailed design, implementation.
• Supporting processes are validation, verification, configuration management, process assurance.

These processes should be applied for IP, or equivalent processes should be cross-referenced.

4.3 - Data to be provided

The Table 2 below has to be considered as a reference for the set of documents to be provided. It contains data related to the IP itself (requirements, development, production and verification data).

It is perfectly acceptable that the IP provider provides a different combination of documents, provided that the objectives defined in column 3 are met.

It is considered that Plans (Design plan, Verification plan,…) and Standards (requirement standards, coding standards,…) mentioned in the  [RD1] document may not be part of the package delivered by the IP Provider. In that case, the IP package should contain data and a summary report of the structured process that produced data items, as mentioned in table 2.

A certificate, or equivalent, from the Quality department ensuring that the described process has been followed and managed is welcome.

The opportunity or need to access and/or audit mentioned plans and standards will be discussed on a case-by-case basis between the IP Provider and User (customer), depending on the mutual confidence, the DAL,…

Table 2 : IP Data to make available.

As described in the IP assessment process in section 4, only part of this data can be available for the IP. In that case, missing data shall be re-generated according to the additional activities described in section 7.

Note : The requested amount of data can be modulated according to the Design Assurance Level (DAL), taking as an example table from appendix A [RD1].

Table 3: Documents/data to be produced, depending on DAL

“Wide and successful” use of an IP in service may provide confidence that the IP’s design is mature and free of errors. The first way is to consider IP as Commercial Off-The-Shelf (COTS) Component. COTS components are used extensively in hardware designs and typically the COTS components design data is not available for review.

The IP shall be developed by a supplier for multiple customers. Service experience can be used to substantiate design assurance for COTS components. Service experience relates to data collected from any previous or current usage of the component. Data from non-airborne applications is not excluded.

Design and configuration shall be controlled by the supplier’s or an industry standard [RD6].

5.2 - Data to be provided

Note: It can be of mutual benefit if the Users community “commits” to provide the IP provider with service experience data. Each user can get benefits from service experience reported by others.

Data used to determine appropriateness of use and usage limitations may be available in specifications, data sheets, application notes, service bulletins, user correspondence and errata notices. These sources of information may also describe the functions associated with the IP, so the airborne intended use can be correlated to previous uses. The demonstration must be coherent with objective of functional safety.

It is necessary to bring the proof of good operation. This can be achieved while multiplying the number of applications by the number of hours.

Problem reports process may show that service experience has led to improvements now available in the current configuration. Problems identified but not fixed may still be mitigated by architectural means or by performing additional verification. Statistics on design errors and their impact on the safety assessment process.  A qualitative assessment can be used if statistics are not available.

6 - Strategy based on Architectural Mitigation Techniques

6.1 - Purpose

Architectural mitigation techniques at upper level (chip level or higher) can be used to mitigate design errors in the IP core. This strategy requires the applicant to fully understand higher level behavior of the design, i.e. what kind of errors the actual architectural mitigation techniques can mitigate.

Architectural mitigation is performed by identifying Functional Failure Paths (FFPs) associated with a proposed hardware implementation, and then analyzing design options to identify and propose design features and strategies that mitigate the effects of these FFPs. See also [RD1] appendix B.

6.2 - Architectural mitigation techniques

Examples of architectural mitigation techniques that can be employed to mitigate design errors are advanced encryption techniques, hardware (or software) diversity or monitors, and also redundancy, monitoring, or partitioning.

Redundancy is a technique for providing multiple implementations of a function (i.e. an IP)  either as multiple items, or multiple lanes within an item. It is a design technique based on the assumption that a given set of faults with the same system effect will not occur simultaneously in two or more independent elements.

6.3 - Data to be provided

The documentation for mitigation should include :

• identification of all failure conditions.
• identification of all implemented upper level functions. For these functions, Establishment of correlations between these functions and the IP core’s functions.
• analysis if a design error in the IP core is critical in the above described sense and provide the associated rationale for that.
• other means of failure mitigation for the parts that cannot be mitigated.
• A safety assessment to ensure that the architectural mitigation techniques are implemented.

This strategy described predominantly applies in the case when a complex electronic hardware component already exists, i.e. it was developed and is in production by some semiconductor manufacturer. It is of no importance if the original IP design has been developed by the manufacturer, by a third party or in a joint effort.

Hence, the reverse engineering is used to regenerate hardware life cycle data that is deficient or missing to satisfy the design assurance objectives. It can be performed either by the IP user, by the IP provider after discussion with the user, by a third party.

[RD1] section 11.1.4 explains in the case of previously developed hardware how to obtain  agreement with the certification authority for hardware previously developed at a lower hardware design assurance level or for non airborne applications.

8 - Conclusion , considerations about relationship between the User and the IP provider

There is obviously a market for IP providers in aerospace domain. Traffics forecasts announce a rate of about approximately 5,3 %, both for passengers and freight [RD8]. The number of aircrafts will improve, and also the demand for more and more complex electronic hardware for those embedded systems. Due to time to market constraints, and despite of more stringent airworthiness requirements, Aerospace companies should deal with IP world.

A good improvement compared to the current situation would be to have IP, at least the ones clearly dedicated to the avionics market, coming with a qualification package prepared by the IP provider. Without anticipating any result in terms of purchasing negotiation, it is considered as acceptable if such a package has an additional cost, provided that it reduces the additional activities to perform by the integrator and so reduces the global cost and schedule of IP integration.

Some IP providers begin to propose a “certification kit”, or equivalent, in order to help their aerospace customer using those complex IPs. this kind of package has been successfully used during certification for airborne electronic hardware for some aircraft programs [RD9], [RD10].

It may also be of mutual benefits if service experience data could be made available, if no confidential aspects prevent the user from giving this information to the IP provider.

Experience or lessons learned are shared with some European or US groups, with initiatives due to Aerospace companies [RD7].

Airworthiness authorities try also to determine what should be the airworthiness requirements needed when using innovative technologies [RD5].

So this world is changing, and relationship between IP providers and Aerospace companies should bring answers to these issues.

10 - Reference documents

[RD1] DO-254/ED-80 Edition 2 April 2000 Design Assurance Guidance for Airborne Electronic Hardware www.rtca.org www.eurocae.org

[RD2] AC 20-152 June 2005 Advisory Circular Document DO254 Design Assurance Guidance for airborne Electronic Hardware www.faa.gov

[RD3] CAST paper 27 rev0 June 2006 Certification Authorities Software Team (CAST) position paper: clarification on the use of DO254-ED80 Design Assurance Guidance for Airborne Electronic Hardware www.faa.gov

[RD4] CAST paper 28 rev0 December 2006 Certification Authorities Software Team (CAST) position paper : frequently asked questions (FAQ) on the use of DO254-ED80 Design Assurance Guidance for Airborne Electronic Hardware www.faa.gov

[RD5] FAA, December 2006, “Microprocessor evaluations for safety-critical, real-time applications: Authority for expenditure No. 43 Phase 1 Report,” DOT/FAA/AR-06/34, U.S. Department of Transportation, Federal Aviation Administration.

[RD6] SPRINT Open SoC Design Platform for Reuse and Integration of Ips http://www.sprint-project.net/, SOCLIB http://soclib.lip6.fr/Home.html, spirit consortium http://www.spiritconsortium.org/home/ ).

[RD7] DO254 Users Group (Europe) www.do254.com.

[RD8] Airbus Global market forecast http://www.airbus.com/en/corporate/gmf/

[RD9] FPGA/IP companies : Altera www.altera.com, TTTEch, Actel, Aldec

[RD10] CAD tools vendors : Mentor Graphics