U.
S. D epartment of Tra nsportation Federal Aviation Admi nistration Advisory Circular ct: Subje Best Practices for Airborne Electronic Hardware Design Assurance Using EUROCAE ED-80( ) and RTCA DO-254( ) Date: 10/7/22 Initiated By: AIR-622 AC No : 00-72 1 PURPOSE This advisory circular (AC) provides “best practices” for airborne electronic hardware (AEH) design assurance and, is intended to be complementary information to EUROCAE ED-80, Design Assurance Guidance for Airborne Electronic Hardware, RTCA DO-254, Design Assurance Guidance for Airborne Electronic Hardware, and AC 20-152A, Development Assurance for Airborne Electronic Hardware. This document provides additional clarifications, explanatory text, or illustrations that could be helpful when addressing some of the objectives of AC 20-152A. This document is not intended to cover each section of AC 20-152A. The contents of this document do not have the force and effect of law and are not meant to bind the public in any way.
This document is intended only to provide clarity to the public regarding existing requirements under the law or agency policies.
Note: EUROCAE ED-80 is hereafter referred to as “ED”; RTCA DO-254 is hereafter referred to as “DO.” Where the notation “ED-80/DO-254” appears in this document, the referenced documents are recognized as being equivalent.
2 AUDIENCE We wrote this AC as a means of assisting applicants, design approval holders (DAH), and developers of airborne systems and equipment containing electronic hardware intended to be installed on type certificated aircraft, engines, and propellers, or to be used in Technical Standard Order (TSO) articles.
3 BEST PRACTICES
3.1 Custom Devices These practices provide complementary information to AC 20-152A, Custom Device Development, section 5. Applicants may consider using these best practices when developing custom devices.
3.1.1 Clarifications to ED-80/DO-254, Appendix A for the Top-level Drawing
3.1.1.1 Hardware Environment Configuration Index (HECI) The purpose of the HECI is to aid the reproduction of the hardware life cycle environment for hardware regeneration, re-verification, or hardware modification. The HECI may be included or referenced in the Hardware Configuration Index (HCI). The HECI should identify:
1. Life cycle environment hardware (e.g., computer or workstation) and operating system (OS) when relevant,
2. Hardware design tools,
3. The test environment and validation/verification tools, and
4. Qualified tools and qualification data.
3.1.1.2 Hardware Configuration Index (HCI) The purpose of the HCI is to identify the configuration of the hardware item(s). The HCI should include:
1. A pplication specific integrated circuit (ASIC)/programmable logic device (PLD) part number,
2. Media used to produce the physical component (e.g., the PLD/ field programmable gate array (FPGA) programming file or ASIC netlist/GDSII stream format),
3. Identification of each source code component, including individual source files, constraints, scripts and versions,
4. Identification of any previously developed hardware,
5. Identification of any commercial off-the-shelf (COTS) Intellectual Property (IP),
6. Identification of the test bench source code and scripts, including the versions,
7. Hardware life cycle data items and their versions as defined in ED- 80/DO-254, Table A-1,
8. Archive and release media (e.g., for the source data),
9. I nstructions for building a PLD programming file or ASIC netlist,
10. Instructions for loading the bitstream file into the target PLD or FPGA hardware,
11. Reference to the HECI, and
12. Data integrity checks for the PLD programming file (not applicable for ASICs).
3.1.2 Additional Information for Objective CD-1 on Simple/Complex Classification Based on the definition of simple hardware in ED-80/DO-254, a custom device with complex functions that is exhaustively verified with the help of a formal analysis or a verification tool could be theoretically classified as simple. AC 20-152A clarifies that the classification as simple or complex is based on the design content of the device, regardless of the proposed verification method. Therefore, such a device would be classified as complex following the criteria of AC 20-152A.
Below is an illustration of the types of criteria commonly used by industry, and it is not an exhaustive list. The applicant is responsible for determining the criteria that are applicable to its own development process:
• Simplicity of the functions, simplicity of data/signal processing or transfer functions,
• Number of functions, number of interfaces,
• Independence of functions/blocks/stages, Specific to digital designs:
• Synchronous or asynchronous design,
• Number of independent clocks, number of state machines and their independence, number of states, and state transitions per state machine.
3.1.3 Additional Information for Objective CD-2 on Development Assurance of Simple Custom Devices A simple device is defined and designed to implement specific hardware functions. Due to the simplicity of the device, the life cycle data is reduced.
The functional performance of the device has to be ensured by verification means in order to demonstrate that the simple device adequately and completely performs its intended functions within the operating conditions without any anomalies.
The functions of a simple device may be defined through a requirement capture process or may be a part of the definition of functions for the overall hardware.
Operating conditions, in addition to the environmental conditions, encompass all the functional modes for the device configurations and all the associated sets of inputs as determined to completely cover the functions of the device in its intended hardware implementation.
3.1.4 Additional Information for Objective CD-7 on Verification of Implementation Timing Performance Objective CD-7 specifies that applicants should verify the timing performance of the design, accounting for the temperature and power supply variations applied to the device and the semiconductor device fabrication process variations.
There are certain variations in the conditions in which the device performs its function that may impact the timing behavior of the device. If not all the cases are verified, the timing aspects might result in device malfunctions under certain conditions.
The following examples identify constraints that may impact the timing behavior of a device, and information to help assess them:
• The temperature range is a design constraint input from the equipment environment or taken from the device limitation/characterization limits. Two different temperatures need to be managed:
o Junction temperatures: the static timing analysis (STA) tools and technology limitations are based on the junction temperatures; and o External temperature: application constraints are related to the external temperature of the device.
Conversions between these two constraints have to be carefully managed when analysis is performed.
• For voltage ranges, there are also two characteristics to take into account:
constraints from the environment (the board, voltage generator accuracy) and constraints from the chosen device. Note that the voltage aspect is unambiguous.
• Device process variation is related to the chosen device, and the device manufacturer often characterizes the technology variations within the library.
To verify the timing performance of the design accounting for the temperature and power supply variations applied to the device and the semiconductor device fabrication process variations, an analysis is expected to be performed on all the corner cases to measure the impact of such constraints (temperature, voltage, and process) in terms of timing that could also affect the frequency at which the device can operate.
Static timing analysis can be used to conduct such an analysis. The source of each STA constraint (delays and frequency constraints) has to be identified. In addition, the timing parameters to be considered for launching an STA include:
• Input frequency: an external constraint with different characteristics (e.g., accuracy, duty cycle), and
• Input/output delays (e.g., setup, hold, skew).
STA provides timing results that highlight setup and hold violations but does not analyze delays longer than a clock period (multi-cycle paths, pulse width generation, etc.). Additional verification may be needed to address those timing aspects not covered by STA.
3.1.5 Additional Information for Objective CD-9 on Recognition of HDL Code Coverage Method For objective CD-9, the applicant determines the code coverage criteria that support the code coverage method. The applicant should define criteria covering the hardware description language (HDL) code elements that are used in the design and exercising the various cases of HDL code. The following items suggest the type of criteria that could be used to cover the HDL logic. These criteria are still to be translated into the specific metrics proposed by the chosen code coverage tools:
1. Every statement has been reached.
2. All the possible branch directions have been exercised.
3. All the conditions expressed in a statement or for taking a branch have been exercised.
4. Every state of a finite state machine (FSM) and every state transition has been exercised.
3.1.6 Additional Information for Objective CD-10 on Tool Assessment and Qualification As described in objective CD-10, in a context where the applicant plans to use a verification tool for a DAL A or B custom device, or a design tool for a DAL A, B, or C custom device, the applicant can choose to provide confidence in the use of the tool through an independent assessment of the tool outputs.
Example:
Custom device development using the following tools:
• Design tools: synthesis tools, layout tools, programming file generation tools,
• Verification tools: simulation tools, STA tools.
Confidence in design tools can be gained through the fact that the outputs from the design tools are independently verified by post-layout simulation and physical tests during requirements-based testing. No further tool assessment is needed.
Confidence in verification tools can also be gained through independent assessment.
For instance, physical tests, either by re-running part of the simulation test sequences or re-testing the requirements, allow confirmation of the results generated via the simulation test cases or procedures. The following criteria can be used to determine whether the tool can be independently assessed using this approach:
• A significant and representative set of custom device requirements is covered by both simulation and physical tests, and
• The results for the simulation and the physical test of the same requirement are equivalent.
Another example of independent assessment can be to re-run simulation tests on a dissimilar simulation tool and compare the results obtained from each simulation tool to ensure their equivalence.
Generally, independent assessment of the tool outputs is the preferred method for tool assessment.
When the applicant largely covers custom device requirements through physical tests, it reinforces the confidence in the tools.
3.1.7 Additional Information for Objective CD-11 on Tool Assessment and Qualification When the applicant intends to present tool history to claim credit for tool assessment, objective CD-11 expects the applicant to provide sufficient data and justification to substantiate the relevance and credibility of the tool history.
In general, the tool history is applicable to a specific version of the tool, because it is difficult to determine whether different versions or releases of the same tool constitute the same tool.
If using a different version of the tool compared with the one that has a relevant tool history, the applicant would then be expected to analyze the differences between the tool versions to ensure that the tool history is relevant to the version of the tool used.
A list of characteristics/criteria that can be part of the relevant history data of the tool includes:
• The similarity of the tool operational environment in which the tool service history data was collected to the one used by the applicant.
• The stability/maturity of the tool linked to the change history of the tool.
• The service experience of the custom devices developed using the tool.
• The tool has a good reputation and is well supported/maintained by the tool supplier.
• The number of tool users is significant.
• The tool has already been used in the applicant’s company on certified developments without raising any major concerns.
• The list of errata is available and shows that these errata do not impact the use of the tool in the development of the particular custom device.
If the tool has not been used by the applicant’s company in the frame of another custom device development, it is preferable not to use the tool history for assessing the tool, and instead to conduct an independent assessment approach.
3.1.8 Use of COTS IP in Custom Device Development These practices provide complementary information to AC 20-152A, Custom Device Development, Section 5.11. Applicants may consider using these best practices when using commercial-off-the-shelf intellectual property (COTS IP) in a custom device.
3.1.8.1 Clarification of Objective IP-2 on Assessment of the COTS IP Provider & COTS IP Data
3.1.8.1.1 Assessment of Service Experience of COTS IP The COTS IP should have been used in numerous application cases, and the IP errata should be available and stable. The applicant will assess and document the relevance of the service experience from data collected from previous or current usage of the component and consider the equivalence of the usage domain to ensure a certain level of maturity of the IP for the user’s application. This data might be obtained with the support of the COTS IP provider, but it might be difficult to demonstrate relevant service experience especially for Soft and Firm IP. Some additional development assurance needs to be defined to address the risk of insufficient or unrelated service experience.
3.1.8.1.2 Assessment of the COTS IP Provider & COTS IP data The following paragraph provides some high-level examples of the assessment of different source formats of COTS-IP; they are included for illustration only.
The following are two typical cases of insufficient coverage when assessing COTS IP with the objective IP-2 criteria:
• A Soft IP is proposed by an experienced provider, but with unknown COTS IP service experience. The COTS IP provider offers limited support for the COTS IP, which may be part of an FPGA provider’s catalog.
• A new Soft IP is proposed by a new company with some documentation. The COTS IP provider does not offer any support.
There is insufficient evidence of complete verification to make it trustworthy. The applicant may be the first user.
An example of a COTS IP assessment with the objective IP-2 criteria that helps to define the appropriate development assurance activity on the COTS IP is as follows:
• A communication Soft IP is proposed by an experienced provider. The COTS IP has existed for more than two years and has been used in many applications by many customers. The version of the IP is stable, and errata are available. The COTS IP is also available as COTS hardware in an FPGA family. The Soft IP is distributed with a set of design constraints and the associated implementation results are usable for various sets of technology targets (which could be PLDs/FPGAs or ASICs). The test procedures used by the COTS IP provider are not available, but a report providing results of those tests is delivered.
Moreover, compliance with the communication standard has been established by the COTS IP provider through an external set of
8 p rocedures and reports that are also available. This assessment and availability of external sets of procedures support the applicant in defining an acceptable verification strategy.
3.1.8.2 Clarification of Objective IP-4 on Verification Strategy for the COTS IP Function The COTS IP assessment should determine the extent to which the COTS IP provider verified their IP. This verification could vary from IP with no/little verification performed to IP that is delivered with detailed life cycle data. The amount of verification performed by the IP provider will drive the applicant’s verification strategy.
Taken together, the verification performed by the COTS IP provider and the verification performed by the applicant in the integrated device shows complete verification of all the used functions of the COTS IP. Thus, if there is little verification data from the COTS IP provider, the applicant will need to do more verification activities to verify the functionality of the IP. If extensive data is provided, then the applicant may only need to show the proper implementation and integration of the IP within the custom device. This activity may be supported by the use of COTS IP provider’s test cases, or by proven test vectors for a COTS IP performing a standardized interface function.
The verification strategy describes the verification data delivered with the COTS IP, as well as the verification data to be developed by the applicant.
The verification activities proposed by the applicant should address any missing items from the data delivered with the COTS IP and ensure the proper implementation and integration of the IP within the custom device.
3.1.8.3 Clarification of Objective IP-6 on the Requirements for the COTS IP Function and Validation Depending on the need for requirements-based testing as a part of the chosen verification strategy for the COTS IP, the level of detail and the granularity of the AEH custom device requirements may need to be extended to particularly address the COTS IP function and further design steps of the COTS IP.
When custom device requirements need to be refined to capture the COTS IP functions per the verification strategy, it will be performed using all the documentation and design data available. The requirement capture process will encompass all the IP functions, including the means to deactivate any unused functions.
The following aspects could be captured as derived requirements:
1. Error or failure mode detection and correction behavior performed by the IP.
2. Design constraints that control the interaction of the IP with the rest of the design of the custom device.
3. Configuration parameters or settings used to alter or limit the functions provided by the IP.
4. Controlling or deactivating unused features or characteristics of the design.
5. Design constraints to properly perform the implementation and mitigate the use of the IP features, modes, and design characteristics with known failures or limitations, for DAL A and DAL B, the behavior of the IP during robustness conditions, boundary conditions, failure conditions, and abnormal inputs and conditions.
6. The mitigation of known errata that would adversely affect the correct operation of the function.
When the applicant chooses a verification strategy that solely relies on requirements-based testing, a complete requirement capture of the COTS IP following ED-80/DO-254 is necessary. It is recommended that this activity should begin with a thorough understanding of the COTS IP architecture, and both its used and unused functions. The applicant could propose a method in the Plan for Hardware Aspects of Certification (PHAC) for determining and assessing the completeness of the requirements capture process, in order to guarantee that the requirements cover all the used functions, and the deactivation means for the unused ones (for non-interference with the used functions).
3.2 COTS Devices These practices provide complementary information to AC 20-152A, COTS Devices, Section 6. Applicants may consider using these best practices when using COTS devices.
3.2.1 Additional Information for COTS Section 6.3 and Objective COTS-1 on COTS Complexity Assessment The applicant assesses the complexity of the COTS devices used in the design and produces the list of all the complex COTS devices. This list of complex COTS is expected to be known at an early stage and documented in the PHAC or delivered together with the PHAC. It is understood that the list may evolve during development, and the list should be made available to the regulatory authority once the parts selection process is completed.
As stated in AC 20-152A, the applicant is not expected to assess the complete bill of material to meet objective COTS-1, but only those devices that are relevant for the classification, including devices that are on the boundary between simple and complex.
10 T he assessment and the resulting classification (simple or complex) for those devices that are on the boundary and classified as simple would be documented in a life cycle data item that is referred to in the PHAC and Hardware Accomplishment Summary (HAS).
The following examples provide some characteristics of complex and simple devices for illustration, and on which the complexity assessment is performed by applying the generic criteria identified in AC 20-152A, Section 6.3. These examples are provided for illustration only. Other combinations of characteristics will occur in actual projects.
EXAMPLES OF COTS DEVICES AND COMPLEXITY
THEIR ASSOCIATED CHARACTERISTICS ASSESSMENT An
• example of a single-core processor/microcontroller with:
Multiple and complex functional elements that interact with each other - PCIe interface, Ethernet, Serial Rapid IO, a single core processor;
Complex
• A significant number of functional modes where each interface has several selectable channels/modes of operation;
• Configurable functions allowing different data/signal flows and different resource sharing within the device so the different data paths within the device are fully configurable in a dynamic manner.
An example of a single-core processor/microcontroller with:
• A single advanced reduced instruction machine core Complex processor;
• Inter-processor communication that uses a simple mailbox protocol;
• A programmable real-time unit (PRU) subsystem that contains 2 RISC processors and complex access to many peripherals;
• A PRU that is highly programmable with 200 registers, and each of the peripherals is also configurable. The PRU is complex.
An
• example of a single-core processor/microcontroller with:
Several functional elements that interact with the single core processor but not with each other: PCI interface, SPI, I2C, JTAG, 1 core processor;
Simple
•
• A significant number of functional modes where the interface has few modes of operation;
Limited configurable functions allowing one major data path using a limited number of discrete signals on SPI or I2C. There is limited and fixed resource sharing in the device.
EXAMPLES OF COTS DEVICES AND COMPLEXITY
THEIR ASSOCIATED CHARACTERISTICS ASSESSMENT An example of a 32-bit reduced instruction set computing (RISC) microcontroller with:
Simple
•
•
•
•
• Internal buses that are all simple master-slave protocol, A processor that has dedicated resources, No interconnect fabric, no multiple masters, A single point of access to all the peripherals, Independent time processor units (TPUs) with microcode that are accessed through the slave peripheral control unit.
An example of a stand-alone controlled area network (CAN) controller with a serial peripheral interface (SPI) with: Simple
• A single controller with one SPI bus.
An example of a communications infrastructure digital signal processor (DSP) with:
Complex
• A single DSP,
• An interconnect between DSP and peripherals that is an interconnect switch with multiple masters, multiple slaves and is highly configurable,
• Multiple internal bridges between the peripherals and the interconnect switch and programmable priorities.
An example of an analog-to-digital converter with:
• An 8-Channel/16-Channel, software selectable, 24-Bit Simple ADC.
An example of a digital SPI temperature sensor with:
• An analog temperature sensor, Simple
• Conversion to digital,
• An SPI output.
An example of an FPGA component with some Hard IP embedded in silicon with: Simple
• An FPGA fabric (out of the COTS scope),
• Embedded RAM/ROM memories,
• Embedded FIFOS,
• A PCI port,
• A/D and D/A converters,
• 16x16 configurable multiplier blocks.
An example of an FPGA component with Hard IP embedded in silicon with: Complex
• An FPGA fabric (out of the COTS scope),
EXAMPLES OF COTS DEVICES AND COMPLEXITY
THEIR ASSOCIATED CHARACTERISTICS ASSESSMENT
• Embedded RAM/ROM memories,
• Embedded FIFOS,
• A PCIe port,
• A Processor Core,
• A coherency fabric/interconnect,
• A/D and D/A converters.
3.2.2 A dditional Information for COTS Section 6.4.1 on the Electronic Component Management Process
3.2.2.1 Clarification of Objective COTS-2 on the Electronic Component Management Process IEC 62239 and SAE EIA-STD-4899 define items and processes that support the establishment of industry electronic component management plans which would be considered as industry recommended standards to support the topics mentioned in objective COTS-2.
Generally, the electronic component management plan (ECMP) describes a standard process that is re-used and re-applied from certification project to certification project. This approach is understood to ease the certification process.
Regarding the assessment of maturity:
When selecting a device, the applicant assesses the maturity of the device and analyzes whether its maturity is sufficient to ensure that the potential for design errors has been reduced. This assessment of maturity could encompass some of the following items:
• The time of the device in service.
• Widespread use in service: an indication of widespread use could be given (multiple applications, a large minimum number of chips sold, etc.).
• Product service experience per DO-254/ED-80, Section 11.3 from any previous or current usage of the device.
• The maturity of the intellectual property embedded into the device,
• A decreasing rate of new errata being raised.
There are no quantitative targets expressed but there is a necessity for an engineering assessment of the device’s maturity, starting with the selection process.
3.2.2.2 Clarification of Objective COTS-3 on Using a Device outside the Ranges of Values Specified in its Datasheet