It also provides guidance for development assurance when using Commercial-Off-The-Shelves (COTS) electronic devices and Intellectual Property.This publication paves the way for a new approach in writing AMC in the domain of development assurance, with a focus on the objectives, offering to the industry the flexibility to detail the activities to meet these objectives.
Airborne Electronic Hardware Software And SystemThis material is intended to be used when showing compliance for and across airborne electronic hardware, software and system development.
They result from 4 years of work in coordination with FAA, including a joint EASAFAA public consultation phase, and with the support of the US and European industry associations ASD, GAMA, AIA. Airborne Electronic Hardware Code Are ExecutedThis includes ensuring all lines of code are executed, all functional behavior is demonstrated, the assumptions between hardware and software interfaces are exercised and the list goes on. The FAA and partners are in the process of implementing new technologies and capabilities to shape a modern, resilient, and secure National Airspace System that serves more than 2.7 million passengers and 44,000 flights per day. They also are well-versed in RTCADO-254 standard, which is the means of compliance for the development of airborne electronic hardware containing FPGAs, PLDs and ASICs. There are five levels of compliance, A through E, which depend on the effect a failure of the hardware would have on the operation of the aircraft. Level A is the most stringent, defined as catastrophic effect (such as the loss of an aircraft), while a failure of Level E hardware will not affect the safety of the aircraft. Airborne Electronic Hardware Verification And ValidationMeeting Level A compliance for complex electronic hardware requires a much higher level of verification and validation than Level E compliance. But now we have the SoC FPGAs coming up, so theyre becoming popular in avionics. When it comes to certification for those types of devices, the hard embedded processors in SoCs are mainly Arm-based, and are treated as a COTS with a separate guidance. The software apps running on the processor need to comply to DO-178C, while the hardware IPs on the FPGA fabric needs to comply to DO-254. When were talking about DO-254 for SoC FPGAs, were really talking about the hardware IP, peripherals, and custom hardware logic on the FPGA fabric that have to be verified as part of the entire system with the processor. ![]() The results from the physical test is still the preferred approach. ![]() They want a reproducible path at the end, so you have to have all the scripts, etc., to recreate the design. Also, you must have the traceability between your top down from the requirements, and bottom up from the test that you do to prove that the requirements have been met. Other than that, its a regular design job where the incremental steps may have to do with safety mechanisms, fail-safe kind of operation, and different hardware security measures that you might put into place. Theres a lot of room for improvement in verification, Carlson said. When we talk about metrics for verification, you get some people who still talk about line coverage. One guy in a space program talked not about line coverage, but the the number of tests. What do they test The idea of using formal verification as much as possible, along with simulation, emulation and early software bring up for the hardwaresoftware integration issues, speak to the notion of Shift Left that is foreign to most of them in practice, if not even in concept. However, there is a tool assessment qualification and another guidance for the tools that would be used for design and verification. If a tool will be used for design purposes and design means it could introduce faults into the design or the verification tool could fail to detect errors during the verification, then both design and verification tools have to go through a tool assessment and qualification. DO-254 is applied for any hardware, and especially if there is complex hardware that includes a processor, such as an FPGA or an SoC FPGA. Here, DO-254 is applied at the chip level, which means they dont have any access into the FPGA so they cant probe it. So they cant do the requirements-based testing on the FPGA chip, which is the main concept of DO-254, and the majority of design and verification challenges originate from that.
0 Comments
Leave a Reply. |