DO-254 Requirements Traceability

Transcription

1 DO-254 Requirements Traceability Louie De Luna, Aldec - June 04, 2013 DO-254 enforces a strict requirements-driven process for the development of commercial airborne electronic hardware. For DO-254, requirements must drive the design and verification activities, and requirements traceability helps to ensure this. Introduction Complex custom micro-coded devices such as PLDs, FPGAs and ASICs used in commercial airborne hardware are subject to the stringent development process outlined in the DO-254 guidance. This means that the design and verification activities for these types of devices must follow the requirements-based development process described in DO-254. The primary purpose of DO-254 is to provide assurance that the device under test meets its intended functions under all foreseeable operating conditions. Requirements express the functions of the device under test; therefore must drive the design and verification activities. This paper describes requirements traceability according to DO-254 guidance in the context of FPGAs, and provides explanations as to what it means for the applicants. This paper also enumerates the underlying purpose of requirements traceability and the benefits that can be achieved when done correctly. Requirements Capture Process The FPGA requirements capture process is the allocation of functions from the Circuit Card Assembly (CCA) to the FPGA device. The allocated functions are recorded and expressed as FPGA requirements. Figure 1 shows an example of a CCA containing a single FPGA device. Figure 1. Circuit Card Assembly containing a single FPGA

2 Requirements are captured and created based on the standards, method, rules, procedures and criteria defined during the planning process. The FPGA requirements capture process is iterative since additional requirements may be generated during the design process. FPGA requirements that are not allocated from the CCA functions and created as a result of a design decision, architectural changes or safety precaution are called derived requirements. FPGA requirements are reviewed for suitability and correctness in relation to the CCA requirements, and derived requirements are validated for correctness and completeness. Example activities involved in the FPGA requirements capture process are: Creation of FPGA requirements based on CCA functions allocated to the FPGA Creation of traceability links from CCA requirements to FPGA requirements Creation and justification of derived requirements that results from the design process Generating downstream and upstream traceability reports Recording all FPGA requirements in the Hardware Requirements Document (HRD) Once the requirements capture process is completed, the FPGA requirements that are captured and listed in the HRD become the basis for all FPGA design and verification activities. Requirements Traceability Requirements Traceability At its simplest form, traceability is linking all of the design and verification elements back to the requirements to identify the relationships between them. The outputs of traceability are the upstream and downstream reports showing the correlation between the project elements. Traceability reports are reviewed for correctness internally within organizations, and audited by certification authorities. Requirements traceability as defined in RTCA/DO-254 and FAA Order are as follows: RTCA/DO-254 page Traceability Data Hardware traceability establishes a correlation between the requirements, detailed design, implementation and verification data that facilitates configuration control, modification and verification of the hardware item. Hardware traceability data should include: 1. A correlation between the system requirements allocated to hardware and the requirements. 2. A correlation between the requirements and the hardware detailed design data. 3. A correlation between the hardware detailed design data and the as-built hardware item or assembly.

3 4. A correlation between the requirements, including derived hardware requirements, and detailed design data and the verification procedures and results. 5. The results of a traceability analysis. FAA Order page Traceability. Many RTCA/DO-254 sections talk about traceability, including Sections 5.1.1, 5.1.2, 6.1,6.1.2, 6.2.1, 6.2.2, 6.3.2, 6.3.3, and In this paragraph we clarify two areas for levels A and B: a. Applicants should ensure traceability between the hardware requirements, the conceptual design, the detailed design, and the implementation. b. Applicants should ensure both the traceability between the requirements and design data covered in paragraph 6-3a above and the corresponding verification and validation results. c. For levels C and D, applicants need to ensure only the traceability from requirements to test (see RTCA/DO-254, Table A-1, Note 6). Taking a closer look into the details of the RTCA/DO-254 guidance in conjunction with the FAA Order , traceability in the context of FPGAs entails linking the CCA requirements to the FPGA requirements, and linking FPGA requirements to the design and verification data and results. Proving that this level of traceability exists to the certification authority helps ensure that all design and verification activities for the FPGA under test are requirements-based. Responsibilities of the applicants In working through the different stages of the FPGA design life cycle, the responsibilities of the applicants to meet the objectives for traceability are as follows: Requirements Capture Link each FPGA requirement to the related CCA requirement it covers. Generate a downstream traceability report and ensure every CCA function has been allocated to the FPGA and captured as an FPGA requirement. Generate an upstream traceability report and ensure that each FPGA requirement traces up to the appropriate CCA requirement. Each FPGA requirement that does not trace up to a CCA requirement may be considered as a derived requirement and must go through the validation

4 process. Baseline or record the trace data between CCA requirements and FPGA requirements. Conceptual Design Link each conceptual design data to the related FPGA requirement it covers. Generate a downstream traceability report to ensure that each FPGA requirement is covered by a conceptual design data. Generate an upstream traceability to expose unnecessary conceptual design data. Baseline or record the trace data between FPGA requirements and conceptual design data. Detailed Design and Implementation Link the specific lines of the HDL design source (single line or multiple lines of code) to the related FPGA requirement it covers. Generate a downstream traceability to ensure that each FPGA requirement is fully implemented by an HDL function. FPGA designers must create additional functions as needed to fully implement each FPGA requirement. Generate an upstream traceability to expose unused HDL design functions. Unused functions of the HDL code may lead to unexpected behavior of the device, and must be removed or updated. Ensure that the post-synthesis and post-layout design meet the specified constraints. Baseline or record the trace data between FPGA requirements and HDL design data. Verification Link each verification test scenario to the related FPGA requirement it covers. Test scenarios are created based on the FPGA requirements, and they are reviewed for suitability and completeness to cover the related FPGA requirement. Test scenarios define how each FPGA requirement will be verified, and includes the appropriate input conditions, test sequence and expected results. Generate a downstream traceability to ensure each FPGA requirement is covered by a test scenario. Generate an upstream traceability to expose unnecessary test scenarios. Baseline or record the trace data between FPGA requirements and test scenarios. Link the specific lines of the testbench (single line or multiple lines of code) to the related test scenario it covers. Generate a downstream traceability to ensure that each test scenario is fully implemented by the testbench. Verification engineers must create the testbench with the appropriate test inputs, sequence and expected results as defined in the test scenarios. Generate an upstream traceability to expose unused functions or code of the testbench that needs to be removed or updated. Baseline or record the trace data between test scenarios and testbench. Link the specific simulation results to the related test scenario it covers. Simulation results are a combination of simulation logs, waveforms and coverage data. These results are analyzed and reviewed for correctness. Benefits of Requirements Traceability Benefits of Requirements Traceability Implementing and maintaining traceability throughout the FPGA development cycle ensures that what is being designed and tested is based on the requirements. Establishing traceability promotes

5 better project management, and provides an efficient way to organize, connect and track the FPGA development cycle. Although not explicitly defined in the guidance, requirements traceability offers significant benefits to the organization when done correctly. Several examples of the benefits are described below. Exposure of Coverage Gaps During the FPGA requirements capture process, running a downstream traceability from CCA to FPGA requirements exposes CCA requirements that are not covered by FPGA requirements. As an example shown in Figure 2, both CCA-002 and CCA-007 are not covered by any FPGA requirement. This is a result of either: the related FPGA requirements are not correctly linked to CCA-002 and CCA-007 requirements, or that the CCA-002 and CCA-007 requirements are not properly allocated to the FPGA. Either way, proper measures must be taken to correct this coverage gap. Figure 2. Spec-TRACER Downstream Traceability Likewise, during the rest of the FPGA design life cycle, running downstream traceability exposes FPGA requirements that have not been implemented by an HDL function, FPGA requirements that have not been covered by a test scenario, and test scenarios that have not been implemented by a testbench. Knowing whether there are coverage gaps or not helps keep track of the project status. Downstream

6 traceability easily exposes requirements coverage gaps during the FPGA development cycle. Exposure of unused HDL Functions Reusing HDL design sources across multiple projects offer several advantages, but one common disadvantage is the occurrence of unused HDL functions. Running an upstream traceability from the HDL design to the FPGA requirements easily exposes HDL functions that do not trace up to any FPGA requirement. This is a result of either: the HDL functions are not properly linked to the related FPGA requirements, or that the HDL functions are not being used at all. Unused functions of the HDL code may lead to unexpected behavior of the device, and they must be removed or updated. Impact Analysis Management Changes in the requirements may lead to changes to other project elements such as HDL design, test scenarios and testbench. Before the change occurs, organizations perform a change impact analysis to evaluate the ripple effect of the change to the rest of the project. Traceability is an effective way to expose the project elements that are impacted due to a requirement change. An example of impact analysis from Spec-TRACER is shown in Figure 3. Figure 3. Spec-TRACER Impact Analysis A change to the requirement description of CCA-041 impacts 3 FPGA requirements namely: FPGA-011 FPGA-021 FPGA-022

7 Test results management These FPGA requirements need to be evaluated whether or not they still fully cover CCA-041 (taking the CCA requirement change into consideration). If further modification is needed for any of the impacted FPGA requirements, then the design and verification elements linked to them also need to be evaluated. As shown in Figure 3, a change to FPGA-011 impacts the following design and verification elements, and all of them must also be evaluated and modified if needed. HDL_002_interrupt_unit.vhd --tag to HDL design function HDL_003_interrupt_unit.vhd --tag to HDL design function HDL_006_interrupt_contr.vhd --tag to HDL design function TST tag to Test scenario TB_003_testbench.vhd --tag to testbench Without an established traceability from CCA down to the FPGA design and verification elements, impact analysis would be quite difficult to manage and analyze. Since traceability between project elements exists, impact analysis is easily achievable. Test Results Management A mechanism to measure whether test case results have passed or failed is a key element in determining the completeness of the verification. Since there is an established traceability between test scenarios, testbench, simulation log files, and waveforms; tracking the result of each test scenario can be easily managed. In addition, with the help of traceability, determining and tracking which testbench achieved the maximum code coverage is also possible. Helps during Reviews and Audits During reviews and audits, the traceability reports are used as a map to determine the correlation of the CCA requirements, FPGA requirements, conceptual design, detail design, verification test scenarios, and results. With the help of the traceability reports, both the applicant and certification authority are able to easily reference and correlate all design and verification artifacts back to the FPGA and CCA requirements. Conclusion Requirements traceability provides evidence that design and verification activities are requirementsbased. A DO-254 compliant design entails linking each system function to the related FPGA requirement, conceptual design, HDL design, test scenario, testbench, and test results. Running a downstream traceability exposes uncovered requirements, and upstream traceability exposes derived requirements as well as unused HDL functions. Because of traceability, change impact analysis is simplified making it easy to identify the ripple effect of requirements changes before they occur. Change impact analysis is crucial and allows organizations to properly plan and allocate resources accordingly before implementing the requirement change. Traditionally, traceability is created and managed manually using Microsoft Word documents and Excel spreadsheets. With today s complex FPGA designs, continuing to use this traditional method has shown to be difficult, inefficient and time consuming. Aldec addresses this industry need with Spec-TRACER, a requirements lifecycle management solution that can help efficiently manage the requirements and automate traceability. Spec-TRACER enables organizations deliver high-reliability and DO-254 compliant designs.

8 Figure 4. Traceability for FPGAs