Archive for the ‘DO-254 Compliance’ Category
Wednesday, April 9th, 2014
Imagine if you could look into the future…
– See the impact of requirements changes before they occur.
– Know with certainty which lines of code in an HDL design or testbench file needed to be re-evaluated based on a change request.
– Understand how a requirement change impacts the project schedule to help plan and allocate resources effectively.
Impact Analysis Defined
Seeing the future is possible with Impact Analysis, a practice within the change control process of product development. Impact Analysis provides information on what design and verification elements, artifacts, hardware components and materials, personnel, assets or activities that may be affected due to a requirement change. Armed with Impact Analysis data, you can then determine which elements to re-evaluate, modify, and even re-create if necessary.
Thursday, February 20th, 2014
DO-254 defines 3 types of verification methods: Analysis, Test and Review. In order to satisfy the verification objectives defined in DO-254, applicants must formulate a requirements-based verification plan that employs a combination of the three methods.
Analysis vs. Test
A computerized simulation of the hardware item is considered an Analysis. Test is a method that confirms the actual hardware item correctly responds to a series of stimuli. Any inability to verify specific requirements by Test on the device itself must be justified and alternative means of verification must be provided. In DO-254, the hardware test is far more important than the simulation. Certification authorities favor verification by test for official verification credits because of the simple fact that hardware flies, not simulation models. Requirements describing pin-level behavior of the device must be verified by hardware test.
Tuesday, January 21st, 2014
Smart engineers work smart by using tools that are readily available and that they know how to use. Wise engineers work wisely by first evaluating the options, analyzing the results and making a strategic decision not only for the current project but, more importantly, for upcoming projects as well.
Recently, a customer developing avionics systems came to us with their frustrations in managing FPGA requirements. They managed higher level requirements, such as line replaceable unit (LRU) and circuit card assembly (CCA) requirements, in IBM DOORS. The FPGA requirements, test cases and their traceability to HDL design, testbench and simulation results were managed using Word and Excel. Since DOORS lacked the capability to trace to FPGA design and verification elements necessary for DO-254 compliance, the customer felt they had to choose Word and Excel.
Why? Because Word and Excel are readily available and the team members already know how to use them. But as their projects grew in complexity increasing the number of requirements to be managed, they found that Word and Excel have many shortcomings and realized that they are not the right tool when it comes to requirements management and traceability.
For the rest of this article, visit the Aldec Design and Verification Blog.
Friday, January 10th, 2014
When I first launched Aldec in 1984, home computers hadn’t quite taken off and innovations such as the compact disk and those oversized, power draining cellphones were still struggling to obtain mass acceptance.
Fast forward 30 years, even those of us in the electronics industry have whiplash from the speed at which technology is advancing and delivering new products. Buyers are more eager to become early adopters of innovative new technology, and smarter, faster tools are required to keep pace.
As a long-time member of the Electronic Design Automation (EDA) community, Aldec has had a front row seat to the technology race and over the years we have celebrated many successes of our own. Here, our product managers reflect on some of our most memorable highlights from 2013.
Wednesday, November 20th, 2013
As a DO-254 evangelist, I travel quite a bit attending conferences and meeting customers all over the world. One question I occasionally get from engineers is whether Aldec’s mil/aero verification solution, DO-254/CTS™, supports verification of FPGA designs with high speed interfaces (for example ARINC 818, LVDS, DDR3 or PCIe).
Depending where I’m at I’ll tell them, “Oui!” or “Hai!” or simply “You bet it does”. Occasionally I’ll respond, “화장실이 어디 있어요!” in hopes that someone will kindly direct me to the nearest restroom.
For the rest of this article, visit the Aldec Design and Verification Blog.
Monday, September 23rd, 2013
If DO-254 is both the mission and the map required to achieve compliance, then traceability represents the roads on that map. Consider this.
– Roads connect two or more places on a map; traceability connects two or more elements in a project (such as functions, requirements, concept, design, verification data and test results).
– Road names help identify specific places that are linked to it; traceability names help identify specific project elements that are linked to it.
– In the absence of roads, reaching your destination is practically impossible; in the absence of traceability achieving compliance is also practically impossible.
Wednesday, June 26th, 2013
An Interview with FAA Consultant DER, Randall Fulton
A few weeks ago I had the opportunity to sit down with an avionics industry certification expert, FAA Consultant Designated Engineering Representative (DER), Randall Fulton. We began discussing common mistakes in DO-254 projects, and then branched out to many different areas including future of DO-254, industry engineering best practices, and his advice to organizations new to DO-254.
Louie: In your experience, what are the common mistakes in DO-254 projects?
Randall: Starting certification liaison activities and the SOI-1 planning audit after the design already exists. Many projects also need to read the additional guidance from the FAA in Order 8110.105 to understand the impact and be prepared to show the data to satisfy the Order. Organizations also underestimate the resources required for a project. This includes staffing as well as managing all the data. Another common area is not appreciating the impact of effective requirements writing skills.
Monday, June 17th, 2013
For DO-254 Compliant FPGAs and ASICs
I have been getting a lot of questions from our customers about traceability in the context of DO-254 and airborne FPGAs and ASICs. It seems that there are several new concepts and terminologies associated to traceability that are new to most of us. So I thought I would shed some light in this blog and explain the basic 5 terminologies. Also I have always liked the word “demystify”, but never had the chance to use it – so here is my chance.
Traceability – Traceability is the activity that maps all of the design and verification elements back to requirements to ensure that what is being built and tested is based on the requirements. Traceability is the correlation between system requirements, FPGA requirements, conceptual design, HDL design, post-layout design, verification test cases, testbench and test results.
Downstream Traceability – A top to bottom reporting activity that shows the mapping or correlation between system requirements, FPGA requirements, HDL design, test case, testbench and test results. Running a downstream traceability can expose FPGA requirements that are not implemented by any HDL function or not covered by a test case.
Upstream Traceability – A bottom to top reporting activity that shows the mapping or correlation between test results, testbench, test case, HDL design, FPGA requirements and system requirements. Running an upstream traceability can expose derived FPGA requirements or unused HDL functions. Tools like Spec-TRACER can also use upstream traceability to expose all of the design and verification elements associated to a FAILED simulation result.