Martin Rowe: How does having such a verification of the test tool help?
Noah Reding: Suppose you're testing an ECU [engine control unit] and your test system gives you the wrong result. If you use that result to make changes in the ECU firmware, you could change its functionality and introduce a safety hazard without knowing it. You can, of course, manually verify your test tool. The kit is essentially a tester for TestStand that documents its verification, producing documentation that's compliant with ISO 26262.
Martin Rowe: How does the TestStand Qualification Kit work?
Noah Reding: The kit is an executable file that exercises TestStand. For example, suppose you want to compare two values, you want to verify that the test tool knows that five is greater than four. Tests on TestStand run in the background. TestStand runs through what we believe is the 80% use case, running functions built into TestStand that are most often used in automotive safety tests. TestStand takes data from application software modules that sit below it, processes the data, and makes decisions based on the results. The qualification kit verifies that TestStand is calling the appropriate underlying code, executes it, [and] verifies that data properly passes to TestStand from underlying code.
Martin Rowe: Is the qualification kit written with ISO 26262 in mind?
Noah Reding: There are two versions, one for automotive and another for mil/aero. There's overlap, but the documentation is specific to the applicable safety standard. For example, we have to provide a TestStand safety manual that explains how the kit performs its tasks. That becomes part of the overall safety documentation.
Martin Rowe: Noah mentioned that this kind of functional safety testing is relatively new in the automotive industry, but not in mil/aero. Both are large industries with components designed and manufactured in many locations. How can the auto industry learn from the mil/aero industry to make sure all components are properly tested?
Kyle Perkuhn: Test data needs to be shared among engineering groups. If a test fails, all engineers involved need to know so the failure can be addressed. IBM Rational has software that's used in the mil/aero industry for sharing test data, and we've partnered with IBM Rational to bring that into the automotive industry. Test data can flow from test tools into IBM Rational's quality management software. It integrates test data into the design and manufacturing process. We found that design requirements were reaching design engineers, but test was out of the loop. Now, a central requirements document can be shared among design and test engineers. An automated system for recording test results assures that, in the event of a quality audit, all functional safety requirements data is available.
— Martin Rowe, Senior Technical Editor, specializes in test and measurement.
Related articles from EE Times, EDN, and Design News: