DO-254 development takes place within the context of ARP4754 processes. The certification aspects of airborne electronic hardware are encapsulated by the development of the system in which the electronic hardware is used. Similarly, the system development is performed within the context of a certification program for an aircraft, a modification or update to an aircraft, or in the case of a technical standard order (TSO), the TSO approval process.
Figure 3.1 shows the airborne electronic hardware within a system and the system within the aircraft program concept.
The system and safety processes start before, or along with, the DO-254 planning processes. The system process outputs that factor into planning include:
• System description
• Hardware description
The safety process outputs that factor into planning include:
• Top-level hazards from the functional hazard assessment that are the drivers for the design assurance level.
• Preliminary system safety assessment that establishes the function design assurance level at the aircraft level and the item design assurance level for the hardware.
• Functional failure path analysis that establishes which failures the hardware participates in and the corresponding classification for the hazard associated with the failure.
Figure 3.2 shows the relationship between system and safety ARP4754 processes and electronic hardware DO-254 processes. The Formal Test phase included in Figure 3.2 is not mandated by DO-254.
The aircraft or TSO certification program will determine the certification basis for the program. The certification basis is the applicable Federal Aviation Regulations and their respective amendment level and any project specific FAA Issue Papers. The certification basis is typically defined in the system level certification plan. The certification basis for airborne electronic hardware will have the same certification basis as the equipment in which it is used. Certification programs conducted in concert with foreign certification agencies may have additional issues levied to meet the requirements of other countries. The outputs of the aircraft, system, and safety processes become inputs for the formulation of the project-specific Plan for Hardware Aspects of Certification, or PHAC. The aircraft and system process outputs and PHAC inputs are depicted in Figure 3.3.
FIGURE 3.1 Electronic Hardware Development Context
FIGURE 3.2 ARP4754 and DO-254 Processes
FIGURE 3.3 Inputs to Plan for Hardware Aspects of Certification
Project planning begins with a combination of several aspects—the idea for the design, gathering the processes and tools to accomplish the design, establishing the resources and organization to accomplish the tasks, evaluating customer-specific requirements, and evaluating project-specific aspects including the certification basis.
Planning considers hardware development from conception all the way through development and into production. Planning also includes production aspects after the design is complete to account for parts obsolescence or parts change. Planning should be a horizon-to-horizon vision of the project to ensure that all phases correctly describe the processes, methodologies, and tools used.
The planning can include a trade study or design trade-off that evaluates whether a particular design or implementation technology can be realized. Planning an FPGA design with a device that has been used in other programs and that uses the same design and verification tools will have less planning or preparation than embarking on a project that uses multiple intellectual cores developed on an FPGA, converts the design into an ASIC for production, and uses new verification tools and techniques.
Planning is performed for projects that encompass the full development life cycle, such as new equipment for a new aircraft, and also for projects that incorporate changes into existing designs.
There are several approaches companies can use for hardware management plans and standards. One approach is to create a common set of hardware management plans and hardware standards. The common set of plans and standards describe a consistent set of processes and procedures followed for AEH or PLD development. The plans and standards state which activities are used and which data is produced for each design assurance level. The Plan for Hardware Aspects of Certification is then created for each project. The PHAC describes the project-specific system, hardware, life cycle data, schedule, and design and verification tools. Any other aspects of the project that are unique are also described in the PHAC. In addition, the PHAC would take into account project-specific FAA Issue Papers and any applicable topics from foreign certification agencies.
Another approach is for organizations to create hardware management plans and standards that are specific to each project. The plans and standards are created or updated for each project. The Plan for Hardware Aspects of Certification is also created for each specific project. The PHAC describes the project-specific system, hardware, life cycle data, schedule, and design and verification tools. Any other aspects of the project that are unique are also described in the PHAC. In addition, the PHAC would take into account project-specific FAA Issue Papers and any applicable topics from foreign certification agencies.
A third approach is for organizations to create hardware management plans and standards specific to a technology. This could be the case for the differences in life cycles required for the development of an FPGA versus the development of an ASIC. The Plan for Hardware Aspects of Certification is then created for each specific project. The PHAC describes the project-specific system, hardware, life cycle data, schedule, and design and verification tools. Any other aspects of the project that are unique are also described in the PHAC. In addition, the PHAC would take into account project-specific FAA Issue Papers and any applicable topics from foreign certification agencies.
A fourth approach is for organizations to create hardware management plans and standards that are specific to development approaches. In this case the plans would focus on the unique requirements that are specific to different development approaches, such as new product development, modifications to previously developed hardware, reuse of previously developed hardware, etc. As with other approaches the PHAC would be specific to the project, and would describe the system, hardware, life cycle data, schedule, processes, and tools that are unique to each development approach, as well as the project-specific Issue Papers and topics from foreign certification agencies.
Planning also takes into account the groups, organizations, and even companies involved in the development of airborne electronic hardware. Using the tools, processes, procedures, and personnel of an experienced DO-254 team that is located within one facility of a company is quite different from planning for spreading the life cycle and activities across different groups, different companies, and groups located in different countries, or outsourcing some of the life cycle activities. Planning may need to consider protection of proprietary data that goes outside a company or even export controlled data that goes outside the country. Outsourcing may require a sub-supplier management plan, such as the one described in Section 13-3, Supplier Oversight Plans and Procedures, of FAA Order 8110.49.1
Planning takes an overall project perspective of the life cycle, activities, plans, standards, procedures, and the resultant documents and data, and finally, the hardware itself. Figure 3.4 shows this type of perspective.
DO-254 planning produces the plans, standards, and procedures for the project. The PHAC is the central output of the planning process as it starts the certification liaison activities with the certification authority and also invokes the plans and standards for the project. The central role of the PHAC is shown in Figure 3.5.
For DO-254, the plans should be written such that each plan is consistent within itself and also when all of the plans are considered as a group. Internal consistency means that terms used in the plan are used the same way, with the same meaning and the same spelling throughout the document. Internal consistency also means that references to sections, tables, and figures are correct. Consistency among a group of plans means that each plan uses terms in the same way, with the same meaning and with the same spelling. The transition criteria between the design plan, verification plan, validation plan, process assurance plan, and configuration management plan should all align. The outputs from a life cycle phase should serve as the inputs to the next life cycle phase. Outputs from the design process should serve as inputs to the verification and validation processes. Outputs from the design process activities should be the same data or documents used as inputs for the validation, verification, process assurance, and configuration management activities. Plans can start as hardware control category 2 (HC2) controlled while they are written. The PHAC is controlled as hardware control category 1 (HC1) after it has been released. The hardware configuration management plan is HC1 controlled for DAL A and B projects and can be HC2 controlled for DAL C and D projects. All other hardware management plans and standards can be HC2 controlled. In some cases, it may be beneficial to control plans and standards as HC1 data to ensure that changes to the plans or standards are reviewed, approved, released, and communicated to impacted parties.
DO-254 allows for various packaging of hardware life cycle data. Projects can combine plans and/or standards as long as the basic required content is provided. Note that embedding standards in a PHAC or combining other plans with the PHAC makes the included data HC1 controlled. Combining other plans or standards with the PHAC will also mean that the combined document is submitted to the FAA since the PHAC is a submittal document.
The plans produced in the planning phase and the respective DO-254 section describing the contents are:
|
• Plan for Hardware Aspects of Certification • Hardware Design Plan • Hardware Validation Plan • Hardware Verification Plan • Hardware Configuration Management Plan • Hardware Process Assurance Plan |
DO-254 Section 10.1.1 DO-254 Section 10.1.2 DO-254 Section 10.1.3 DO-254 Section 10.1.4 DO-254 Section 10.1.5 DO-254 Section 10.1.6 |
FIGURE 3.4 (See Color Insert.) DO-254 Life Cycle and Data
FIGURE 3.5 (See Color Insert.) Role of Plan for Hardware Aspects of Certification
The standards produced in the planning phase and the respective DO-254 section describing the contents are:
|
• Requirements Standards • Hardware Design Standards • Validation and Verification Standards • Hardware Archive Standards |
DO-254 Section 10.2.1 DO-254 Section 10.2.2 DO-254 Section 10.2.3 DO-254 Section 10.2.4 |
Another document that should be identified in the planning phase is the Electronic Component Management Plan (ECMP). The Electronic Component Management Plan defines the use and management of COTS components used in the hardware design process. The ECMP is typically coordinated with an organization’s purchasing or parts procurement department. The ECMP should describe:
• The parts allowed in the design process
• How change notifications from manufacturers are handled within the company
• How errata sheets from manufacturers are distributed to designers
• How parts are qualified (at the device level) when needed
• Procurement aspects such as lifetime buys
• How parts obsolescence is managed
The ECMP can be written in accordance with International Electrotechnical Commission (IEC) technical specification IEC TS-62239 titled Process management for avionics—Preparation of an electronic components management plan.2 The IEC technical specification describes all aspects of process management for electronic components and is an excellent reference for putting an ECMP in place. Note that unprogrammed FPGA devices should be managed in accordance with an ECMP.
The planning phase, transition criteria, inputs, outputs, and configuration controls are summarized in Table 3.1. Table 3.1 also lists the tools used to produce the documents in the planning phase. The list of tools used in each phase makes a convenient way to survey the tools when the tool qualification and assessment section of the PHAC is created. The table is meant as an example; a real project may require different information.
PLAN FOR HARDWARE ASPECTS OF CERTIFICATION
The Plan for Hardware Aspects of Certification should have the contents described in Section 10.1.1 of DO-254. Note that the target audience for a PHAC is the Designated Engineering Representative (DER), or for delegated organizations, the Authorized Representative (AR) or Unit Member (UM). The target audience for the PHAC also includes the staff of the FAA Aircraft Certification Service such as an engineer in the Aircraft Certification Office. It is important that the PHAC writer considers the target audience and readers of the document. In other words, the PHAC is written to satisfy the needs, questions, and criteria that the readers will use to evaluate the document. Since the PHAC is a submittal document, it is also important that the PHAC is written in a professional style and is free of inconsistencies and typographical errors. A review of the PHAC by an experienced technical writer can help ensure a professional finished document. In a formal sense, the PHAC is written in future tense, laying out the plan for the future planned hardware development.
Planning Phase Table
The PHAC is an FAA submittal document—it is sent to the FAA with an approval or recommendation for approval. If a DER/AR/UM is involved in the program, they will have recommend or approval authority for the PHAC. If the FAA retains approval authority of the PHAC, then it is submitted as recommended for approval and the FAA will make the final document approval and concur with the recommendation for approval. If the DER/AR/UM has approval authority and the FAA does not retain compliance, then the PHAC can be approved by the designee.
The PHAC describes how DO-254 is interpreted and applied for approval of the airborne electronic hardware for a given program. A PHAC is an instantiation of DO-254, with program specific details. As the PHAC represents an agreement with the FAA on certification aspects for airborne electronic hardware, it is essential to get the PHAC written, approved, and submitted to the FAA as early as possible in a program. Securing FAA concurrence with a recommendation of PHAC approval, or FAA approval of the PHAC, is an important milestone. Once approved, the program is performed in accordance with the PHAC, not DO-254.
The PHAC typically starts with a description of the system. This description sets the context for the readers and helps them evaluate and understand the functions and safety aspects. The system description includes the architecture and functionality of the system, the failure conditions, and references to applicable system level documentation. The system description also states how functions are allocated to hardware and software.
Drilling down to the next level, the PHAC describes each hardware item in the scope of the PHAC. The item description should include the device types and technologies, such as flash, anti-fuse, or static random access memory (SRAM) devices. The device type should also list the manufacturer name and part number, and include a list of device features such as internal random access memory (RAM), hardware functions in the device fabric (multipliers, processor cores, etc.), and the overall device size or gate count. Any new or unique technologies used should be included. The hardware item’s description should include safety aspects such as fail-safe, dissimilarity, partitions, and redundancy. Note that while circuits with discrete components may be readily shown to be of different design assurance levels and physically partitioned, it is not anticipated that claims of physical or functional partitioning within a PLD are used. Even with a device layout or floor planner option, PLDs use common routing resources and clocks, along with common power, ground, and physical package.
The certification considerations section of the PHAC should state the certification basis for the program. The certification basis is the applicable FARs and their respective amendment levels. Typically for a Part 25 program, this is 14 CFR Part 25.1301 and 25.1309. The amendment levels of the FARs can be put directly into the PHAC, or a reference to the system certification plan, which defines the amendment levels for all the applicable FARs, can be used. If the program has Issue Papers or similar items from foreign authorities, this is an ideal section to explain the proposed means of compliance to each Issue Paper. This section should also explain the proposed means of compliance to the FARs. The means of compliance should be stated as DO-254, in accordance with FAA Advisory Circular 20-152.
The design assurance level and functional failure path analysis should be summarized in the certification considerations section. The functional failure path analysis is used to show which circuits and/or components cause a failure. Since the failures are classified as hazards, the design assurance level associated with each failure is known. For PLDs, the DAL is determined by the most critical hazard associated with the device. For LRU application of DO-254, the functional failures and DAL of each circuit can be established. With proper partitioning and isolation it is possible to have multiple DALs for electronic hardware (non-PLD). An effective approach is to list the top-level events from the functional hazard assessment for the hardware. Then, describe the functional failure path(s) and the device(s) or electronic hardware in each functional failure path. Once the hazards, failures, and hardware are associated, the design assurance level is then stated. If any reduction of design assurance levels is permitted due to architectural aspects, then the redundancy/dissimilarity/control-monitor aspects should be stated along with a justification of the resultant design assurance level.
Additional topics to cover in the certification considerations section are a list of the submittal documents to the FAA for the program, the designee, and their authority requested, and the list of SOI audits used in the program.
The hardware design life cycle section of the PHAC includes an overview of the development methods and the development procedures. This section also describes the procedures and standards that will be applied. The design life cycle is typically described by phases. Each phase has transition criteria that consist of entry and/or exit criteria. The transition criteria describe the activities that need to be completed and the associated artifact or evidence produced that demonstrates the completed activity. Each life cycle phase should also list the tools used for the respective activities. This section of the PHAC is meant to be an overview of the design life cycle, thus the specific plans and standards should be referenced. Table 3.1 shows a concise method to collect and portray the entry criteria, exit criteria, activity, tools, outputs, and configuration controls for a life cycle phase. It is also helpful to reference the DO-254 objective(s) associated with the life cycle phase or a specific activity. This will be useful to the certification authority that reads and needs to approve the PHAC.
The hardware design life cycle data section of the PHAC explains how the program will deliver the data specified in DO-254 Table A-1. It is recommended that a table be included in the PHAC that shows the mapping between the life cycle data listed in DO-254 Table A-1 and the project specific life cycle data. When documents are combined, they can be listed multiple times in the PHAC table. An example of the life cycle data mapping for an FPGA is shown in Table 3.2. The document identifier should use the project specific designation. When DO-254 is used at the system level, the data should be more similar to what is shown in DO-254. In other words, the Top-Level Drawing would actually be used and not replaced with the PLD equivalent document.
Hardware Life Cycle Data
DO-254 Document |
Company Document |
Document Identifier |
FAA Submittal |
DER Disposition |
Plan for Hardware Aspects of Certification |
Plan for Hardware Aspects of Certification X123 PLD |
1002-PHAC |
Yes |
Recommend |
Hardware Design Plan |
FPGA Design Plan |
1002-HDP |
No |
Approve |
Hardware Verification Plan |
FPGA Verification Plan |
1002-HVP |
Yes |
Approve |
Hardware Validation Plan |
FPGA Verification Plan |
1002-HVP |
||
Hardware Process Assurance Plan |
FPGA Process Assurance Plan |
1002-HPAP |
No |
Approve |
Hardware Configuration Management Plan |
FPGA Configuration Management Plan |
1002-HCMP |
No |
Approve |
Requirements Standards |
FPGA and Hardware Requirements Standards |
1002-HRSTD |
No |
Approve |
HDL Coding Standards |
VHDL Design Standards |
1002-VHDSTD |
No |
Approve |
PLD Design Assurance Standards |
PLD Design Standards |
1002-PDS |
No |
Approve |
Validation & Verification Standards |
PLD Verification Standards |
1002-VVSTD |
No |
Approve |
Hardware Archive Standards |
Archive, Retrieval, and Data Backup |
1002-HWARSTD |
No |
Approve |
Hardware Requirements |
X123 PLD Requirements Document |
1002-HRD |
No |
Approve |
Conceptual Design Data |
X123 PLD Design Document |
1002-HDD |
No |
Approve |
Detailed Design Data |
X123 PLD Design |
1002-HDL |
No |
Approve |
Top-Level Drawing |
X123 PLD Hardware Configuration Index |
1002-HCI |
Yes |
Recommend |
Assembly Drawing |
X123 Netlist |
1002-NET |
No |
Approve |
Installation Control Drawing |
X123 Altered Item Drawing |
1002-AID |
No |
Approve |
HW/SW Interface Data |
n/a |
|||
Hardware Traceability Data |
X123 PLD Hardware Verification Report |
1002-HVR |
No |
Approve |
Hardware Review & Analysis Procedures |
X123 PLD Hardware Verification Procedures |
1002-HVP |
No |
Approve |
Hardware Review & Analysis Results |
X123 PLD Hardware Verification Report |
1002-HVR |
No |
Approve |
Hardware Test Procedures |
X123 PLD Hardware Verification Procedures |
1002-HVP |
No |
Approve |
Hardware Test Results includes elemental analysis results |
X123 PLD Hardware Verification Report |
1002-HVR |
No |
Approve |
Hardware Acceptance Test Criteria |
n/a |
|||
Hardware Environment Configuration Index (Order 8110.105a) |
X123 PLD Hardware Environment Configuration Index |
1002-HCI |
No |
Recommend |
Hardware Accomplishment Summary |
Hardware Accomplishment Summary X123 PLD |
1002-HAS |
a Order 8110.105 CHG 1, Simple and Complex Hardware Approval Guidance, Federal Aviation Administration, dated September 23, 2008.3
FIGURE 3.6 Decision Process Flow for Previously Developed Hardware
The additional considerations section of the PHAC includes a description of any previously developed hardware, usage of COTS components, product service experience, and an assessment of the development and verification tools used in the hardware life cycle. Previously developed hardware (PDH) can be claimed when the hardware, or PLD device, was developed and approved prior to FAA Advisory
Circular 20-152. The description of previously developed hardware should state the FAA project number that the hardware was originally approved under, the DAL for the original approval, the life cycle data substantiating the approval—such as the PHAC, HCI, and HAS, and summarize any applicable product service experience.
In addition, the previously developed hardware section should address whether the hardware is being reused as is, with an upgrade to the DAL, with a change to the hardware, with a change to the aircraft installation, with a change to the application or design environment, or with some combination of these considerations. Figure 3.6 illustrates the decision process flow for PDH.
The amount of reuseable data for PDH will depend on project circumstances. Unmodified PDH will only require that integration/system testing be conducted. Modified PDH will require:
• Test and verification of the modified aspects of the hardware
• Retest and reverification of parts that are affected by modified parts
• Integration/system testing
Changing the application will require:
• Reverification of interfaces to new equipment
• Reverification of hardware/software interface if different software used
A change of the design environment requires an assessment of the new design and/or verification tools for tool qualification.
An increase of the design assurance level requires:
• Assessing suitability of previous compliance data for new DAL
• Filling in gaps between previous and new DAL
• Determining which existing compliance data can be used
Commercial off-the-shelf components, including unprogrammed FPGAs, should be managed in accordance with an ECMP. Other COTS aspects should include the use of intellectual property (IP) cores. IP cores are designs that are purchased from a vendor that may or may not have been developed for DO-254 compliance. IP cores are typically used for standard interfaces such as Ethernet, 1553 bus, ARINC-429, universal asynchronous receiver/transmitter, or peripheral component interconnect (PCI). The life cycle data for an IP core should be commensurate with the DAL of the hardware. In other words, the life cycle data and verification activities should be the same as designs conducted in-house. When the IP core does not have the HDL source code available, it could preclude its use. The PHAC should describe the IP core, the documentation available from the vendor, and explain any additional activities that need to be performed to complete the life cycle activities and data. Structuring the IP core data as standalone documents is an effective strategy, especially when the IP core will be reused in subsequent designs.
Product service experience is used to justify the use of COTS components and previously developed hardware. The product service experience would ideally come from aircraft use. If aircraft usage data is not available, then an explanation should be included to justify the relevance of the data. There is always a first time for a device to be used in an aircraft application; the idea is to convey whether the device has been used in other industries or applications for a sufficient amount of time. Semiconductors that have been used in automotive applications are often ideal candidates since the device packaging and temperature ranges are often suitable for aerospace applications. The product service experience should explain why the data is meaningful and relevant. The data should explain:
• Whether the function and usage is the same or similar
• Whether the operational environment is the same or similar
• Whether the previous DAL is the same or similar to the proposed DAL
• Whether the hardware configuration is the same or similar
• Any errors or problems detected during the service period
• Failure rates during the service period
Product service experience can also be used to justify the upgrade of the design assurance level from D to C, C to B, or B to A. The service hours should be on the same order of magnitude as the required reliability. When assessing service hours for DAL A, the prior usage should be in the millions of hours since the failure rates will be on the order of 10−5 to 10−6.
TOOL ASSESSMENT AND QUALIFICATION
DO-254 requires that the tools used in hardware design and verification processes be assessed. The flow chart in Figure 11-1 of DO-254 illustrates the tool assessment and qualification process that must be conducted on each design and verification tool.
Tools can be classified as design tools or verification tools, or in some cases both. Design tools are the tools that are used to generate the hardware or some aspect of its design. This means that an error generated by a design tool can introduce errors into the electronic hardware. Examples of PLD design tools include synthesis and place and route tools. For electronic hardware such as circuit cards, examples of design tools would include schematic design entry tools and circuit board layout software. Verification tools have less effect on design assurance than design tools because their most serious effect is to fail to detect an error in the electronic hardware or its design. Examples of PLD verification tools include simulation tools, logic analyzers, and oscilloscopes. For electronic hardware, verification tools include analog and mixed-signal circuit simulation software, laboratory test fixtures, and bench instruments such as logic analyzers and oscilloscopes.
DO-254 does not provide specific rules or guidance for qualifying design tools. Design tool qualification can follow strategies described in DO-254 Appendix B, or they may use the guidance for qualification of software development tools provided in RTCA DO-178. Regardless of the approach, design tool qualification should be described in the PHAC and coordinated in advance with the certification authorities. In addition, design tool qualification will require cooperation from tool designers and ample schedule and budget resources.
The emphasis in DO-254 is on verifying a tool’s output. If the output of a design or verification tool is independently assessed, then no tool qualification is needed. Independent assessment includes any process that verifies that the tool output is correct, including the use of another tool to make the assessment, and may include a manual review of the tool output or the use of a separate, but dissimilar, tool to conduct a similar check. Qualification is not required for verification tools used for measuring completion of elemental analysis. DO-254 also allows the use of relevant tool history as a substitute for qualification.
Design tool qualification requires the generation of a tool qualification plan. The rigor of the qualification effort is determined by the type of tool, its intended application, and the design assurance level of the hardware that it will design. Compliance with the tool qualification plan is documented in a tool accomplishment summary.
If the output of the tool is not independently assessed, and there is no relevant history, Level A, B, and C design tools and Level A and B verification tools require a “basic” tool qualification. The “basic” tool qualification verifies that the tool produces the correct outputs for its intended application. The basic qualification tests the tool’s operation against its “requirements,” which are typically taken from its user manual or equivalent documentation of its functionality.
Tool assessment and qualification for each tool, including any rationale for qualifying or not qualifying the tools, should be documented in the PHAC. If relevant tool history will be used for a design or verification tool in lieu of assessing its outputs, or if a design tool will be qualified, they should be discussed in the PHAC and coordinated with the certification authorities during the planning phase of the program.
Tool Assessment Example
Vendor |
Tool |
Purpose |
Assessment |
Rationale |
Syn Free Corp. |
SynCity |
HDL synthesis tool |
Qualification not required |
Functional and post-layout simulation and device testing performed with verification tools |
MisPlaced Tools Inc. |
Route 66 |
Place and route tool |
Qualification not required |
Post-layout simulation and device testing performed with verification tools |
ProLogicDesign Associates |
Write Way |
HDL editor |
Qualification not required |
HDL text files output from the tool are reviewed |
Runner Up Inc. |
Run For Cover |
HDL code coverage |
Qualification not required |
Not required |
Tool assessment in the PHAC should list each design tool and verification tool. Adding the purpose of the tool and a brief description will help convey the usage and context. The PHAC should state whether the tool needs to be qualified, how the qualification will be performed, and the data produced as evidence of the qualification. If qualification is not required, the PHAC can state the rationale for not qualifying the tool. An example of the assessment can be formatted as shown in Table 3.3. The tools listed in the example are fictional.
The alternative methods section of the PHAC includes a description and justification for any methods that are not discussed in DO-254 or methods that are not applied as described in DO-254. Alternative methods might include use of development, verification, or validation techniques that are less traditional than those described in DO-254. The use of any alternative methods should be coordinated and discussed early in the program to minimize risk associated with the approach.
The certification schedule section of the PHAC describes the major milestones for the program and the timeline for submitting life cycle data to the certification authority. This information allows the FAA to plan their workload and allocate resources for the program. The major milestones may include dates or timeframes for first flight, type inspection authorization (TIA), equipment or aircraft certification, and the intended SOI audits. Note that dates should be kept to a high level of granularity since specific target dates can be subject to change. The intent is to convey a timeframe such as 4Q2014 (fourth quarter of 2014) rather than November 12, 2014.
The PHAC should also contain information specified in FAA Order 8110.105. The additional content for a PHAC from Order 8110.105 includes:
• A PHAC can be written for each hardware item or PLD in the equipment, or the PHAC can encompass all the PLDs in the equipment. Using separate PHACs for each PLD can be useful if the intent is to develop a PLD for reuse on future programs.
• The PHAC should state whether the hardware item is classified as simple or complex, and provide a justification if the classification is simple. Devices or hardware classified as simple should have a description of the proposed approach including the life cycle activities, data, and applicable plans and standards. The description for simple hardware should also describe the verification activities and environment and give a clear description of how the hardware is comprehensively tested.
• The PHAC should list the failure condition classifications associated with each hardware item. The PHAC should also provide a functional description of each hardware item.
• While DO-254 Sections 9.1 and 10.1.1.3 state that the proposed means of compliance should be stated in the PHAC, Order 8110.105 reiterates this point. Typically, the proposed means of compliance in the PHAC simply states that the hardware will be developed to meet the objectives in DO-254 commensurate with the design assurance level in accordance with FAA Advisory Circular 20-152.
• The Order also requires a description of the proposed design assurance level, and justification (this duplicates DO-254 10.1.1.3).
• The PHAC should also reference the applicable hardware management plans and hardware design standards. A list of certification data to be delivered and/or to be made available to the FAA should be in the PHAC (this duplicates DO-254 10.1.1.5).
• Any proposed alternative methods to those in DO-254 should be explained. The explanation of alternative methods should state how the objectives and guidelines are interpreted, and provide a description of the actual alternative methods. Alternate methods are also required per DO-254 Section 10.1.1.7. It is important to note that the FAA anticipates that usage of alternate methods is presented along with the compliance justification early in the project.
• A justification for reverse engineering life cycle data and activities for an existing component.
• Documentation and justification of relevant service history used to assess and preclude the qualification of tools. This should describe the version of the tool used on previous projects, any anomalies noted with the tools, any problem reports recorded for the tool, the way the tool has been used on other projects, and whether the tool output/data/reports are accurate and reliable.
• A description and justification of the level of verification coverage of the requirements that will be achieved by hardware testing. Note that hardware testing assumes tests performed on flight hardware (i.e., in circuit testing with a production equivalent circuit card). Some portion of the hardware testing can also be performed with a device tester as long as in-circuit tests at the board level are also performed. The PHAC can describe the approach if a combination of device tests and in-circuit tests are used.
• The completion criteria for the additional verification activity selected from DO-254 Appendix B.
Content for the PHAC not specifically listed in DO-254 that is particularly useful includes:
• The LRU or equipment part number
• The part number of the end hardware item (PLD)
• The part number of the HDL source code
• The part number of the netlist, fusefile, or programming file applied to the unprogrammed part
• The vendor name and part number of the unprogrammed PLD part
• The FAA certification project number
• A list of applicable FAA Issue Papers and a detailed description of the proposed means of compliance to each aspect of the Issue Paper
• A list of applicable foreign certification authority items (such as an EASA Certification Review Item) and a detailed description of the proposed means of compliance to each aspect of the item
The Hardware Design Plan is for the development engineers to guide the design of the hardware. The hardware design life cycle section of the HDP describes the processes to create the life cycle data and the hardware item. The hardware item could be a system, a circuit card assembly, or a programmable logic device. The design life cycle should also explain the coordination between the hardware design, process assurance, configuration management, verification, validation, certification liaison, and production transition.
The coordination between these various life cycle processes is expressed as transition criteria. Transition criteria can specify the minimum requirements in order to start a life cycle phase or process, the minimum requirements in order to finish a life cycle phase or process, or both. While the criteria can state an activity that needs to be complete, the criteria can also list the artifact or evidence that demonstrates that the activity is complete. For example, the transition into conceptual design can formally start when the requirements are baselined and have been peer reviewed. The evidence that the baseline occurred and that the peer review was performed would be a requirements document under configuration control and a completed peer review checklist stored in configuration control. As was shown in previous examples, the activities, associated artifacts, and transition criteria can readily be expressed in a table. Table 3.4 shows an example of the format.
Transition Criteria
Table 3.5 shows an example of using a table to describe the requirements capture process.
The hardware product description section of the HDP should include the intended usage of the hardware including the operational environment, any alternate usage, the target service life, and any plans for updates or upgrades to address obsolescence or features. The description should include device programming considerations for programmable devices such as in-circuit or device programmer. If the HDP is not specific to a project, the hardware product description can be captured in the project PHAC, and the hardware product description section of the HDP can then refer to the project PHAC.
The hardware design methods section of the HDP should include a description of the processes and procedures for capturing requirements, performing the conceptual design, performing the detailed design, and transferring the necessary data to production. Information on the use of requirements capture or management tools and tools for design or schematic capture should be included or referenced from the design plan. The design plan should also explain the data needed for the production environment such as fuse file, programming file, Gerber file, parts list, bill of materials, assembly drawings, and programming instructions for programmable devices. The design plan should also specify the types of parts permitted in a design and reference the Electronic Component Management Plan for parts selection criteria.
The design plan should explain the intended levels of requirements such as system, assembly, board, and PLD. The requirements method should explain how requirements are captured, the use of requirements management tools, how derived requirements are captured, and how the trace data for requirements is captured.
The hardware design environment section of the HDP should list the tools used in the design process. The tools should include software packages, hardware or computing platforms, and any specialized equipment.
The hardware item data section of the HDP provides a complete identification of the hardware to be produced. This should include the part number of the end system, the part number of sub-assemblies, and the part number of programmable devices. For programmable devices, the identification should include the manufacturer’s part number, the part number of the programming data, and the resultant part number of the programmed device. If previously developed hardware is being used, then this section should list the complete configuration identification of the hardware item and life cycle data that is being reused. The description should also clearly identify the new or updated hardware and life cycle data.
Transition Criteria for Requirements Capture
The other considerations section of the HDP includes a description of any factors needed for the production of the hardware including mounting, installation, programming, pick and place equipment limitations, solder reflow profiles, and provisions for manufacturing test.
The Hardware Validation Plan describes the processes and activities to validate the derived hardware requirements. DO-254 processes assume that all requirements allocated to the system have been validated in accordance with ARP4754. Thus, only the derived requirements added by the hardware design process need to be validated. The validation of derived requirements should satisfy the objectives in DO-254 Section 6.1.1. In most cases, the validation process for PLD derived requirements can be included in the Hardware Verification Plan. Derived requirements for a PLD typically involve a requirements review to check that the PLD derived requirements are correct and complete. Validation of derived requirements for application of DO-254 to all electronics in a system may involve activities beyond review. All requirements, including validated derived requirements, are subject to verification as described in the Hardware Verification Plan.
The validation methods section of the Hardware Validation Plan includes a description of how reviews are performed to validate derived requirements, how analyses are performed to validate derived requirements, and how testing is performed to validate derived requirements. The analysis may include simulation methods.
The validation data section of the Hardware Validation Plan describes the data produced from the selected validation method. For review of derived requirements, this can be a completed requirements review checklist. For analysis or simulation of derived requirements, this can be analysis or simulation results. For testing of derived requirements, this can be test results. The validation environment section of the Hardware Validation Plan describes the tools, checklists, and equipment used to validate derived requirements.
The Hardware Verification Plan describes the processes and activities to verify the hardware requirements. The requirements verification should satisfy the objectives in DO-254 Section 6.2.1. The verification methods section of the Hardware Verification Plan describes the various reviews, analyses, and testing performed and the methods used to accomplish them. The descriptions of the methods should include the methods’ processes, methodologies, activities, input data, and output data. Helpful information in this section would include a summary of how the verification method will be selected for each requirement, the order of precedence among the methods, and the conditions that can dictate when more than one method should be used to verify a requirement.
The verification data section of the Hardware Verification Plan describes the data produced as a result of performing the verification activities. The data would include peer review records, analysis procedures and results, and test procedures and results. Helpful information for this section includes how the data will be managed and archived, how it will be analyzed or otherwise evaluated to generate the verification results, and how the data and results will be documented as the hardware verification results life cycle data.
When DAL A or B hardware is produced, the verification independence section of the Hardware Verification Plan specifies how the independence is achieved. This section describes how the verification will meet the independence described in Appendix A of DO-254. In general, independence is achieved when the reviewer of a verification artifact is different from the author of the artifact. Qualified or properly assessed verification tools also provide an independent assessment of verification data. Test cases should be reviewed by someone other than the author of the test cases. Test procedures should be reviewed by someone other than the author of the test procedures. Test results should be reviewed by someone other than the person running the tests and compiling the results. Analysis procedures and results should be reviewed by someone other than the author of the data. Note that DO-254 permits the use of verification cases, procedures, and results developed by the hardware designer as long as the reviewer is a different person. Use of verification data from the designer is also permitted when there is additional independent verification of the same requirement and design, such as in other levels of system or software testing—provided that they were developed independently.
Note that independence is not dictated solely by whether the reviewer is a different person than the author or originator of the data being reviewed. It is often the case that a person who did not contribute to the data being reviewed, but who is familiar with the data and the engineering thought processes that went into its creation, will be incapable of conducting an independent review simply because they are too close to the data to remain objective or to see the data with a fresh perspective. While such a person will technically satisfy the independence criteria in DO-254, in reality they may not possess the independence to conduct a faithful review as intended by DO-254. On the other hand, while complete ignorance of the data and its associated technology will ensure an independent review, it may result in an inadequate review simply because the reviewer will not know enough about the topic to recognize an anomaly or discrepancy. Thus a reviewer will need to have some level of familiarity with the data being reviewed to ensure that the review is competent, but should not be so familiar that their ability to identify problems—and therefore their independence—will be compromised.
The verification environment section of the Hardware Verification Plan should describe the tools and equipment needed to perform the reviews, analyses, and tests. Analysis tools would include the simulation tools for circuit analysis, thermal analysis, or PLD timing. Hardware test equipment should include power supplies, function generators, digital multi-meters, oscilloscopes, logic analyzers, test stands, break out boxes, standard or specialized cables, or interconnecting wiring. Plans should include provisions to make diagrams of test equipment setup and drawings for any custom test equipment or wiring. A table can be used to list the review checklists used in the review activities.
The organizational responsibilities section of the Hardware Verification Plan should describe the various organizations involved in the verification and the activities that they perform. If credit for hardware verification is taken from software testing, then the software organization should also be listed in this section. If credit for hardware verification is taken from system testing, then the systems organization should also be listed in this section. If any of the activities are outsourced to another company or organization, then this section should specify those details. Things to consider and specify in the Hardware Verification Plan when outsourcing verification activities include:
• Technical oversight of the outsourced work—the amount of technical review performed to assess the quality and correctness of the data
• Impact on certification liaison, such as whether an audit needs to be performed at another location
• Process assurance oversight of the outsourced work—which organization will perform process assurance activities
• Coordination of configuration management aspects
• Where the data is managed
• How compliance data is transferred back to the developer’s configuration management system
• How problems discovered by the verification team are transferred back to the developer’s configuration management system
• Which configuration management tools are used to control compliance data
• Whether tests or simulations will be run for score at the outsource facility. This can introduce complexity and additional cost to coordinate any test witnessing or audit aspects.
HARDWARE CONFIGURATION MANAGEMENT PLAN
The Hardware Configuration Management Plan (HCMP) can be thought of as a collection of procedures for the control of the hardware and its associated life cycle data. The HCMP defines the controls and procedures for two categories of configuration management for life cycle data. Hardware control category 1, or HC1, uses formal release, baselines, and problem reporting to manage changes. Hardware control category 2, or HC2, is used to store and protect life cycle data such as verification results or process assurance records. HC2 data does not require formal baselines, problem reporting, and change control; the data is simply archived and a new version created. HC1 data requires that all configuration management activities described in DO-254 be applied, while HC2 data requires a subset of those activities.
Table A-1 in DO-254 shows which hardware control category applies to hardware life cycle data. In general, the following data items are always HC1 controlled, regardless of the design assurance level:
• Plan for Hardware Aspects of Certification
• Hardware Requirements Data
• Top-Level Drawing (Hardware Configuration Index for a PLD)
• Assembly Drawing
• Installation Control Drawing
• Hardware/Software Interface Data
• Hardware Accomplishment Summary
The process activities associated with hardware configuration management include:
• Configuration identification
• Baselines
• Baseline traceability
• Problem reporting
• Change control integrity and identification aspects
• Change control records, approvals, and traceability
• Release
• Retrieval
• Data retention
• Protection against unauthorized changes
• Media selection, refresh, and duplication
Configuration management, especially baseline and data retention activities, should be applied to the hardware development and verification tools. Commercially procured tools and in-house custom made tools should be preserved for any necessary future rework of the hardware item.
Configuration identification pertains to providing a unique identifier to each configuration item. All life cycle data such as drawings, documents, verification artifacts, process assurance records, and configuration management records should have a method to assign unique identifiers. File management tools with version control will ensure that changes to life cycle data have unique identifiers since the version is rolled with each check in of the data in the file management tool. Companies typically have part numbering schemes established through drawing room policies and procedures. Logs can be kept manually or electronically that track which drawing, document, or hardware identifier numbers have been allocated. While it is obvious that hardware and drawings should have unique part numbering schemes, DO-254 requires that all HC1 and HC2 life cycle data be uniquely identified. Many PLD designs could have a “top.vhd” or “arinc.vhd” file. Ensuring that the files are unique would require that the identifier include the entire file path name specification, and that the file path is unique for each project. An example would be C:serverrootprojectsprojectAlphadesignfilessourcedesign, where projectAlpha is the unique project name. The file “top.vhd” could then be distinguished between
• C:serverrootprojectsproject Alphadesignfilessourcedesign op.vhd
• C:serverrootprojectsproject Betadesignfilessourcedesign op.vhd
The unique identifiers need to be applied to all verification data produced during the life cycle. This includes data for physical hardware testing—test cases, test procedures, and test results—and to data for hardware simulation—test cases, testbenches, and test results. Peer review records from requirements, design, and verification data reviews also need to be uniquely identified. A structured naming practice that starts with the requirements can make it relatively easy to meet the unique identification constraint. Structured naming practices coupled with a structured hierarchy for file organization make storage and retrieval of data across multiple projects a manageable feat.
Baselines apply to individual documents, drawings, and data as well as collections or sets of data. A baseline can refer to the first release of a document, typically called Revision (—) or Revision 0, or it can refer to a collection such as the planning baseline. The planning baseline would be the collection of released hardware management plans and hardware standards and their respective revision level. Baselines can have maturity criteria for entry into system level environmental qualification testing, aircraft ground test, or aircraft flight test. For a PLD, a baseline for a particular version of the hardware is described in the hardware configuration index, or HCI.
Baseline traceability allows a description of the changes incorporated between subsequent releases of HC1 data. For a document, this would be the problem reports incorporated in a version to create the subsequent version, such as changes to Rev. A of a document to create Rev. B. Baseline traceability also allows a description of the changes incorporated between subsequent releases of the hardware item. If the top-level part number uses a XXXXX-YYY numbering scheme where XXXXX is the root number and YYY is the version, the 13579-001 can be traced to 13579-002 through the problem reports that describe the changes applied to the –001 version to create the –002 version. Systems and LRUs use a top-level drawing for the hardware to call out the drawings and their respective version. Baselines are particularly useful for accumulating credit for the verification activities when changes are being made to the hardware. Skillful use of baselines, problem reporting, change control, and change impact analysis can help justify where verification credit can be retained, and identify which verification activities must be repeated when a change is made.
Problem reporting uses a process to report, track, and disposition the status and resolution of problems. Often, the problem reporting system is also used for change management to incorporate new, changed, or even deleted functions and requirements. Problem reports are most effectively managed using electronic or web-based tools that also enforce the work flow and sign off of problem reports (PR). Problem reporting tools facilitate work flow automation, notification to users, and reporting for project management.
Change control starts when a configuration item is baselined and used for certification credit. Typically for HC1 life cycle data, this starts when a document or data has been reviewed and released. Once the life cycle data is baselined, protections should be put in place and enforced to ensure that any subsequent change is an authorized change. Since change control is usually linked with problem reporting, this usually means that life cycle data require a PR and approval from the change board to make changes once the data has been released. Drawings may follow a similar change and approval process, or use the problem reporting system. Any change to baselined or released life cycle data should cause a change to the configuration identification. This is typically done by incrementing the revision or version of the data or document. A document initially released as Revision N/C (no change) would be incremented to Revision A with the first authorized change(s). A testbench vhdl file would increment from version –001 to –002, a schematic would increment from Rev. A to Rev. B, and so on. The type of increment will be compatible with the storage tools and methods. Tools used for file management, such as Rational ClearCase, CVS, MKS, AccuRev, and others will automatically increment the file version for each check in. If these tools are used for management of PLD design and verification data, then their versioning information can be used to ensure the integrity and identification aspects of change control. Manual methods to ensure the integrity and identification aspects of change control, while more time consuming, are also acceptable. The coordination of problem reporting and version control should be described so that changes made to HC1 controlled released data are recorded, approved, and traceable. Once the change process starts, the PR should describe the starting version of the life cycle data and the resultant version when the changes are made. Document version updates and version updates to HC1 data in file management systems should be described. Updating the version of changed items facilitates tracing changes back to the original, or former, version. Problem reports should also record the changes made and the approval to make the changes.
The HCMP should describe the procedures used to release data, drawings, and documents. The release process is used to ensure that the baselined and controlled version of data is used in subsequent activities. An example is a released requirements document that is used for creating the design and the trace data from requirements to the design. The release is a promotion of the document or data from engineering control to a formal configuration management system. Released documents or data can be stored in access-controlled areas of a server, in a file management system, or a company production data management system. Any forms, approvals, routing, or controls should be explained in the procedure.
The HCMP also describes how life cycle data is retrieved. The retrieval can be from a server or application such as a file management system or from a formal company data management system. Data retrieval from off-site archives should also be described. It is prudent to periodically retrieve data from off-site archives and practice restoring databases, applications, and servers. Documenting the detailed procedures to retrieve and restore data will prove useful in the event of data loss or corruption.
Project life cycle data should be retained as long as the equipment is used in service on an aircraft. The data for FAA projects should be retained in the United States and written in English. Many corporate business systems or information technology services are set up to accommodate seven years data retention for legal or business purposes. The FAA requirement could easily extend the retention period to 20 or 30 years, perhaps longer. In addition to the life cycle data, it is important to retain the design and verification tools and a license to allow their use.
All released and archived data should be protected against unauthorized changes. The HCMP should describe server access controls, user account controls, and other methods used to ensure that the data is protected. Most file management tools facilitate this protection by updating the version of data or documents when they are checked in. The original version can always be accessed. Production data systems typically only allow read access to stored data; administrators are the only ones allowed to add data or documents. Problem reports for HC1 data record authorization to update or change released data and documents.
The HCMP should also describe how the media used to archive project data is selected, and when it is refreshed or duplicated. Optical, electronic, and magnetic media should use multiple copies in case of damage to or degradation of the media. Maintenance of archives should be described with considerations for the type of media. Periodic assessments of data storage technologies can be performed to evaluate more cost-effective or efficient technologies. Changes in media should be accompanied by data migration from old media to new media. It is very useful to describe the data produced as evidence of the management of project storage media. This will allow process assurance to audit records.
HARDWARE PROCESS ASSURANCE PLAN
The Hardware Process Assurance Plan describes the activities performed by process assurance. Process assurance needs to be performed independently of other life cycle design and verification activities. If a separate organization is not used for process assurance, then the plan should describe how the individuals maintain their independence from the life cycle tasks they were involved in when they perform process assurance activities. While DO-254 mentions product conformance in Section 10.1.6, the conformance is typically handled at the system level through formal FAA activities. Most projects describe conformity and delegation of conformity in the system level certification plan to ensure coordination with and delegation from the FAA. DO-254 applied at the system level or PLD level will use company configuration management processes, in lieu of formal conformity, for verification activities that meet DO-254 objectives. In this case, process assurance should ensure that test equipment is documented and that testing uses data from configuration controlled sources. The HPAP should describe the reviews and audits performed by process assurance. Process assurance should ensure that design and verification life cycle transition criteria are satisfied, that project standards are adhered to, and that all configuration management objectives are met.
The process assurance activities can be organized around the phases defined in the Hardware Design Plan and the Hardware Verification Plan. An example is shown in Table 3.6.
Process Assurance Activities
The table defines when a process assurance activity is performed, the specific activity needed, and the data produced as evidence of the activity. Note that process assurance does not necessarily need to be performed by technically oriented staff. Process assurance audits of the peer review process could be an independent peer review performed by process assurance, or process assurance could check that the peer review was performed correctly by engineering and that all issues captured in the review were resolved correctly.
Process assurance should define the level of auditing they will perform. For design and especially verification activities with multiple aspects, a sample target or percentage should be defined. For example, process assurance may audit 15 percent of the peer reviews of test cases and procedures. When sample percentages are used, they should be earned—that is lowered or reduced only after a track record of execution to project plans and standards has been demonstrated. Process assurance should also define oversight performed when design or verification activities are performed by external organizations or subcontractors.
The process assurance plan should also describe how deviations to project plans and standards are recorded and tracked. Any forms used to record and resolve deviations should be referenced. Authorizations and approvals for deviations and their closure should be included in the HPAP.
Hardware standards are the mechanism by which a company, through a formalized process, establishes the tangible characteristics of its products such as quality, reliability, durability, and consistency. Hardware standards can be used to foster a culture that promotes high quality and creativity. While the use of standards may not be required per DO-254 for DAL C and DAL D designs, the existence of hardware standards can indicate that a company has demonstrated a desire and/or commitment to standardize its design environment in a way that will engender consistent high quality in its products. Hardware standards are also used to assess the acceptability and quality of hardware design results by providing specific criteria to use in evaluations.
FAA Order 8110.105 clarifies the use of standards for HDL-based designs. The Order states that complex electronic hardware use coding (design) standards for HDL-based designs. The Order also specifies a review of the hardware requirements standards, design standards, validation and verification standards, and archive standards in the Hardware Planning Review, or SOI #1.
If standards are invoked for a project, then the standards become part of the certification basis and plans for the project. This means that the standards are part of the official certification data. Once invoked, a demonstration of compliance with the standards is needed. It behooves applicants and developers to have realistic and cost-effective standards. Training for the standards within the development group and to any sub-tier suppliers may be needed to ensure compliance by everyone concerned.
Tools can be used to enforce standards. Examples would include:
• Design rule checker in schematic editor/printed circuit board netlister.
• Fan-in, fan-out constraints during PLD synthesis/place and route.
• Code coverage tool to enforce verification completion standards.
Conversely, standards can be used to limit the scope of tool qualification. If a simulation tool requires qualification, the scope would be limited to the HDL functions and constructs permitted by the HDL design standards.
The standards should be referenced or invoked by the plan that uses them. The Hardware Design Plan should reference the requirements and design standards. The Hardware Validation Plan and Hardware Verification Plan should reference the validation and verification standards. The Hardware Configuration Management Plan should reference the hardware archive standards.
Well-crafted requirements and design standards can also be used as the basis for the validation and verification standards. The requirements standards will contain the criteria for creating, tracing, and justifying derived requirements. These criteria can then be used in the requirements validation review checklist. The requirements standards will contain the criteria for creating and tracing requirements. The criteria for the requirements can then be used in the requirements verification review checklist. The design standards will contain the criteria for creating the design and tracing it to the requirements. The design criteria can be used in the design verification review checklist.
Requirements standards include instructions for all aspects of writing requirements, validating requirements, using requirements management tools, tracing and validating derived requirements, and how to feed derived requirements back to the system design and safety process. The requirements standards should explain how to write requirements and include aspects such as the language and terminology, sentence construction, and definitions and applications of keywords such as “shall,” “will,” and “should.” The requirements standards should also explain requirements feedback and clarification:
• Identifying requirements to feed back
• Where to feed back the requirements
• Methods for feeding back requirements
• Assessment criteria
• Artifacts to produce
The methods for requirements capture should also be explained. This can include top-down functional decomposition, rapid prototyping with phases to capture requirements, and spiral or cyclic development where requirements are developed and captured with more detail each time through the cycle. The standards should also describe the organization and layout of the requirements document.
Hardware design standards describe the procedures, rules, and methods for the conceptual and detailed design. The design standards also describe the guidance and criteria to design the hardware. The standards should include instructions for the design representation, i.e., standards for how the design is captured. Design standards should include:
• HDL
• Allowable HDL types (VHDL, Verilog, ABEL)
• Type/revision of HDL libraries and packages
• Architectural considerations such as hierarchical or flat
• Coding style
• Coding standards
• Schematic
• Schematic capture software and tool version
• Library types
• Schematic structure
• Page size
• Symbol design, look, and feel
• Other
• Supporting representation such as flow diagrams, algorithm expression, state transition diagrams
• Pen and ink drawings
Design standards may also include naming conventions for signals at all levels of the design. Use of intellectual property (IP) cores should be described in the standards. The design standards may also describe how to assess design alternatives and perform trade studies. Trade studies considerations should include:
• When to conduct a trade study
• How to conduct a trade study
• Criteria for the trade study
• Relative priority for trade study criteria
• How to assess results
• How to select alternatives
The design standards can also include guidance to assess fail-safe and fault-tolerant design features. The guidance should specify:
• Characteristics of fail-safe and fault tolerant designs
• When to assess the design features
• How to assess the design features
• Assessment criteria
• Evaluation methods/criteria
• Selection criteria
Design tool guidance should be described in the design standards. Topics to cover include which tools to use, how to configure the tool, constraints to be used, directives to include, reduction algorithms (if selectable), and place/route constraints for PLD designs.
Component selection criteria can be discussed in the design standards. Criteria can include technology options such as transistor–transistor logic (TTL), low-voltage TTL (LVTTL), complementary metal oxide semiconductor (CMOS), or low-voltage CMOS (LVCMOS). Proper selection ensures compatibility with other circuits and can minimize the complexity of the power supply design. Device temperature range is largely a function of packaging and device selection option. Care should be taken to respect maximum rated transistor junction temperatures. Guidance can also discuss how to select PLD types—CPLD versus FPGA, FPGA versus ASIC. The component selection can also describe how to select appropriate programming technology such as flash, anti-fuse, and static random access memory (SRAM).
VALIDATION AND VERIFICATION STANDARDS
Validation and verification standards include guidance, criteria, and methods for the validation of derived requirements and the verification of the requirements and its design. The validation of derived requirements may be covered in the requirements standards, the validation standards, or some combination of the two. As suggested above, the criteria in the requirements and design standards can be used as the basis for the review criteria used in the validation and verification procedures. A convenient method for performing reviews is to list the applicable criteria in a checklist or spreadsheet, then list the requirements, design, or verification artifact they are applied to.
Verification standards describe the criteria for the verification activities including review, analysis, and test. Reviews are applied to all life cycle data such as plans, standards, requirements, design data, analysis data, and test data. Reviews for life cycle data should check that the content described in Section 10 of DO-254 is documented. For example, a PHAC should, at a minimum, contain the information described in Section 10.1.1 of DO-254, a Hardware Design Plan should contain the information described in Section 10.1.2 of DO-254, and so on. The review criteria should be described or referenced in the verification standards. Review criteria are typically listed on a checklist and applied to the data or document under review. The checklist can also provide a method to document the review and any associated action and closure. Review procedures should be described in the verification standards. The procedures describe who can perform a review, how to perform the reviews, and when the reviews should be performed.
The verification standards also provide the guidance and criteria for verification by analysis. Criteria for circuit and timing analysis should be included in the standards. This can include component derating criteria to assess function and performance with component tolerance, voltage, and temperature effects. When simulation is used, the standards should explain test case selection criteria—the combination of inputs and initial conditions needed to comprehensively verify a requirement. Test case selection should include normal or expected inputs as well as abnormal or unexpected inputs. Tests would also include factors such as glitches on inputs, asynchronous resets, and timing variations on clock domains—especially when two or more clock domains are involved. The standards should also describe the expected coverage achieved with the elemental analysis. Note that test coverage for standard components will be different than coverage of a complex device such as an ASIC or an FPGA.
Finally, the verification standards also provide the guidance and criteria for verification by test. The standards should explain test case selection criteria—the combination of inputs and initial conditions needed to comprehensively verify a requirement with in-circuit electrical test. Test case selection should include normal or expected inputs as well as abnormal or unexpected inputs. Tests would also include factors such as glitches on inputs, asynchronous resets, and timing variations on clock domains—especially when two or more clock domains are involved. Note that the ability to achieve incorrect, abnormal, or unexpected inputs with hardware testing is typically limited due to the physical constraints of the actual circuit card.
The archive standards work in conjunction with the hardware configuration management plan. The standards are used to establish and then maintain an archive of life cycle data. The standards should address the type of archive used, such as optical disc or magnetic tape. Considerations such as medium selection and refresh periods should be specified. Archives should include data from all tools and databases used in the hardware life cycle process, including data used in the manufacturing process. The archives should also include any servers used to store data or drawings. When backups are used as part of the archive process, the backup content and frequency should be specified. Archive integrity checks should also be specified. Integrity checks could include message-digest algorithm, such as MD5.
If an organization does not have published standards, a well-designed peer review checklist can serve the same function. For this approach to work, the review checklist should contain detailed and comprehensive review criteria that express the same standards that would otherwise be found in a standards document. The checklist can also serve as guidance for the development of its target review item. For example, a design review checklist would contain review criteria that would capture all of the organization’s design standards. Designers could use the checklist as a design standard by ensuring that the design meets all of the review criteria, and then the verification team could use the checklist as the basis for their design review where the design is confirmed to meet all the review criteria/standards. This approach provides a double layer of assurance that the design will meet its governing design standards.
Table A-1 of DO-254 designates the Plan for Hardware Aspects of Certification, Hardware Verification Plan, Top-Level Drawing, and Hardware Accomplishment Summary as the documents submitted directly to the FAA. In some cases, the HVP is not submitted if an adequate description of verification is included in the PHAC and FAA Aircraft Certification Office (ACO) specialists are given a project familiarization presentation or meeting.
A top-level drawing is used in DO-254 Table A-1 since DO-254 is written for all electronic hardware in the aircraft equipment such as a line replaceable unit (LRU). In the context of how DO-254 is written and was conceived, the top-level drawing makes sense. Since compliance to DO-254 is only required for programmable electronic hardware in Advisory Circular 20-152, the FAA requests that a hardware configuration index (HCI) is submitted in lieu of the top-level drawing. FAA Order 8110.105 Section 4-5.a describes the use of the HCI document.
Once the planning is complete, it is recommended that all team members read and become familiar with the contents of the plans and standards. Company training can also be conducted with slide presentations to help facilitate the familiarization process and learning curve. These meetings are also ideal opportunities for management to express their backing of the plans, standards, and processes. The plan reading and training can also extend to subcontractors or service provider organizations.
In short, planning is not a short process. Four of the DO-254 objectives are for planning. Many hours of work can be optimized or used in the most effective manner with adequate planning. Planning, and especially the Plan for Hardware Aspects of Certification, is project specific. While design, verification, process assurance, configuration management, and standards may be common to projects within an organization, it is always beneficial to take time at the beginning of a project to assess them. Effective planning can also incorporate lessons learned from prior programs and fine-tune the processes.
1. Order 8110.49 CHG 1, Software Approval Guidelines, Federal Aviation Administration, dated September 28, 2011.
2. IEC TS 62239, Process management for avionics—Preparation of an electronic components management plan, Geneva, Switzerland: International Electrotechnical Commission, 2003.
3. Order 8110.105 CHG 1, Simple and Complex Hardware Approval Guidance, Federal Aviation Administration, dated September 23, 2008.