Posts Tagged ‘Traceability’
Wednesday, August 2nd, 2017
Traceability is becoming increasingly important in most engineering projects, if only on the grounds of ‘good practice’, and it is specifically required for projects that have to meet safety standards such as DO-254 and ISO 26262.
To provide traceability, you must maintain the relationships between all aspects of a project; from the system-level requirements through implementation and verification. Unfortunately, many organizations reduce their traceability responsibilities to preparing a few matrices for major reviews and to comply with respective safety standards. Such an approach is very time-consuming and I would argue it does little if anything to improve the overall management of the project. Or the design for that matter.
Good traceability data helps prevent errors and omissions in specifications, design and test plans. The first step is to define a traceability model.
Figure 1. Example Traceability Model
(more…)
Tags: aldec spectracer, DO-254 Compliance, do-254/cts, requirements management tool, source code parser, spec-tracer, Traceability, traceability data, traceability matrix
No Comments »
Monday, May 23rd, 2016
 The hardest part of DO-254 is not the requirements. It’s not the design. It’s not the verification.
We just wrapped up this year’s 3-day DO-254 Practitioner’s Course, and each year I learn something new. In this year’s training we had attendees from major aerospace companies including Curtiss Wright, Rolls Royce, Sierra Nevada Corporation, Thales and Woodward. It’s always a pleasure to meet the aerospace folks and learn about their projects, goals and challenges. This is the fifth year we’ve done these trainings and each time I pick up subtle points from the instructor showing his impressive expertise in the subject.
This year’s subtle point that I picked up is about the hardest part of DO-254.
The hardest part of DO-254 is the cultural change that needs to take place in order for the organization to successfully comply to DO-254. This can be the make or break of the project. It doesn’t matter if you have top-notch planning documents if no one will adhere to them. It doesn’t matter if you’ve written 1000+ page requirements document, but the verification engineers cannot use them because the requirements are not verifiable. It doesn’t matter if you have the best design standards if your designers would not abide by them. It doesn’t matter if you have the latest verification tools but no one in your team understands how to satisfy tool assessment and qualification. It doesn’t matter if you have the most comprehensive review checklists if your reviewers will not use them and document the review activities and results.
DO-254 is a collection of industry best practices and all of its processes are tightly integrated, but it doesn’t matter if you have the DO-254 processes tightly in place if your team members will not abide by them. The hardest part of DO-254 is the cultural change that needs to be embraced by all team members. The cultural change is what can get you.
Many organizations new to DO-254 are eager to jump on board and start applying DO-254 to their projects due to its high demand in the avionics industry. You might be ready to take the leap and make the cultural change yourself, but is the rest of your team and organization ready for the cultural change?
If you’d like to learn more, or register for next year’s class, call us at 1+702-990-4400 or email training@aldec.com.
For the rest of this article, visit the Aldec Design and Verification Blog.
Tags: do-254, FPGA, safety-critical, SoC and ASIC Prototyping, Traceability, verification
No Comments »
Tuesday, August 25th, 2015
 You have been developing FPGAs for a long time, and you know your designs from top to bottom. You know every interface protocol, configuration and optimization. You can visualize your timing diagram like you can visualize your upcoming vacation in Hawaii. You can manually write down your memory mapping accurately while under oath. You can pinpoint all CDC paths and emulate metastability in your mind. You are confident that your designs are fault-tolerant and will function as intended. You are the master of your domain.
But… can you bet your life on it?
Are you willing to bet your life on your designs? What about the lives of the thousands of passengers sitting on the airplanes where your FPGA design is installed? How certain are you that it won’t fail in the field? If it were to fail, can it resume normal operation safely and timely? Not just MOST of the time, but EVERY time?
(more…)
Tags: Aldec, do-254, DO-254 Compliance, do-254/cts, FPGA Design, FPGAs, Requirements Management, safety-critical, spec-tracer, Traceability
No Comments »
Wednesday, July 16th, 2014
 If they’re being honest, anyone who has verified an FPGA under strict DO-254 guidance will tell you that it is stressful. Show me an engineer on their first DO-254 project – and I’ll show you someone pulling out their hair and downing what is probably their 5th cup of coffee while these important questions weigh heavy on their minds:
Have we reviewed all FPGA requirements and validated derived FPGA requirements? Do we have a good record of the review activities?
Do I have a test for each functional FPGA requirement? What’s the status of the tests? How do I track the progress and document the results?
(more…)
Tags: aviation, coverage, design, do-254, DO-254 Guidance, FPGA, HDL Design, Impact Analysis, Requirements-Based Verification, safety-critical, Testbench, Traceability, Validation, verification
No Comments »
Tuesday, June 24th, 2014
 Aldec has been working closely with Elbit Systems in Israel on an important DO-254 project for some time now. Using Aldec’s specialized solution DO-254/CTS™ as their primary FPGA physical testing platform, Elbit recently passed a critical EASA verification audit for DO-254/ED-80 DAL A FPGAs.
As a DO-254 evangelist, I have long recognized the value and benefits of Aldec’s solution to the avionics industry, so it was particularly rewarding to hear these words from Moshe Porian, Logic Design Verification Group Leader at Elbit Systems Aerospace Division, “Aldec helped us solve several of our verification challenges. This is the first time in Elbit’s history that we have been able to bring more than 5 FPGA devices to the audit.”
DO-254/CTS solved Elbit’s major challenges, enabling them to test in hardware 100% of FPGA pin-level requirements. As opposed to developing software test vectors, Elbit used their simulation testbench as test vectors for FPGA at-speed testing which cut their development costs. For the rest of this article, visit the Aldec Design and Verification Blog.
Tags: Aldec, design, do-254 project, do-254/cts, easa verification audit for do-254/ed-80 dal a fpgas, elbit systems aerospace division, elbit systems in Israel, FPGA, fpga at-speed testing, fpga physical testing platform, fpga pin-level requirements, logic design verification group leader, simulation, simulation testbench, software test vectors, test vectors, Traceability, verification
No Comments »
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.
(more…)
Tags: Aldec, conceptual design, design, do-254, FPGA, FPGA Design, fpga requirements, HDL Design, ibm doors, Impact Analysis, impact analysis defined, log files, post-layout design, requirements-based test cases, simulation runs, spec-tracer requirements lifecycle management solution, Testbench, Traceability, verification, waveforms
No Comments »
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.
Tags: Aldec, cca, circuit card assembly requirements, do-254, DO-254 Compliance, FPGA, FPGA Design, HDL Design, higher level requirements, ibm doors, line replaceable unit, lru, managing fpga requirements, spec-tracer, Traceability, traceability with excel, verification elements
No Comments »
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.
(more…)
Tags: Aldec, cca, circuit card assembly, conceptual design, detailed design, do-254, FPGA, fpga requirements, hardware design process, hardware requirements, HDL Design, implementation, individual system requirements, requirements capture, spec-tracer, test results, Traceability, verification results, verification test cases
No Comments »
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.
(more…)
Tags: device development life cycle, downstream traceability, FPGA, HDL Design, hdl functions, Impact Analysis, post-layout design, spec-tracer, suspect links, test results, Testbench, Traceability, upstream traceability, verification test cases
No Comments »
|
