As more operational control and road user safety is devolved to the vehicle’s electronic systems, the automobile is becoming an increasingly complex domain. Traditionally isolated electronic control units (ECUs) that control fuel injection, steering and battery management now need to cooperate with complex advanced driver assistance system (ADAS) ECUs, relying on advanced techniques such as sensor fusion and artificial intelligence to make split-second decisions.
Guaranteeing operational safety under all driving conditions involves a rigorous design and test strategy. To address safety in vehicle design, the automotive industry has adopted the ISO 26262 standard; understanding the requirements of this standard will ensure automotive companies can design electronic control systems that are proven to be safe.
The risk-based approach taken by the ISO 26262 standard is different from that used in older safety standards which prescribed specific mechanisms for dealing with known safety hazards. It provides greater flexibility in terms of solution development but demands a stringent development methodology and approach to documentation.
While ISO 26262 follows the core concepts of the more generic IEC 61508 standard, it applies modifications for vehicle design. The most obvious difference between IEC 61508 and ISO 26262 lies in safety integrity level (SIL) categories. IEC 61508 specifies four SIL categories, which denote the severity of a safety failure for a given function; ISO 26262 also employs four automotive SIL (ASIL) categories, but with different risk-reduction factors that are more appropriate to vehicles.
While it does not appear in the IEC 61508 standard, the software development V-model is a viable safe-system-development methodology in ISO 26262. The model’s V formation depicts three phases on each side. The left side covers initial safety requirements, architectural design, and unit design and implementation. The right side focuses on test: unit test; integration test; and, finally, safety requirement verification. Each test phase connects to a corresponding design phase, while system-level testing determines how the whole car deals with failures. If testing is successful, the system has met system-level specification requirements.
Initially, model based simulated inputs can be used to test ECU core functionality. As the design matures into the prototype phase, techniques such as hardware-in-the-loop (HIL) will be used to introduce real-world inputs. A key advantage of HIL testing is that it safely tests failure modes that would otherwise be dangerous or impossible to evaluate. It also supports test script reusability with models and real-world inputs being used at various points in the lifecycle.
Effective testing requires high performance evaluation tools. Software development and test tool errors can lead to serious consequences for the final system’s safety. A lack of confidence in test tools leads to a lack of confidence in the safety process. For this reason, ISO 26262 includes the tool qualification concept, which is reflected in the Software Tool Qualification Plan (STQP).
The STQP should be created early in the development lifecycle, identifying each tool used in the project, down to the version, use cases and its intended environment. Each tool must also go through Software Tool Classification Analysis (STCA), a process that determines the level of confidence the team should have in each tool; the Tool Confidence Level (TCL). Two main elements control the TCL; Tool Impact (TI1 or TI2), and Tool Error Detection (TD1, TD2 and TD3).
Some tools, such as documentation preparation environments, have a limited impact on safety (for example, if they insert incorrect spacing or misalign diagrams), and would typically be classed as TI1. Test tools, in contrast, have a much greater impact if they fail: uncompleted tests could propagate unsafe behavior. Thus, they belong in the TI2 class.
The second element of TCL relies more heavily on the Tool Error Detection (TD) classifications. TD1 can be applied if there is a high degree of confidence in the tool’s ability to detect an error, while TD3 implies a very low degree of confidence in the possibility of detection.
The complexity of the V-model, together with the requirement to classify tools according to their TCL, can make custom test harness creation and qualification potentially risky and expensive, especially when it includes third-party tools evaluated according to ISO 26262.
NI TestStand, in contrast, provides a ready-to-run test management environment that has been demonstrated on ISO 26262 projects through all V-model test phases. Fully compliant with ISO 26262 principles and documented to support the STQP, TestStand provides a complete environment in which to develop, execute, and deploy test system software.
TestStand can support test sequences that incorporate modules written in any test programming language. These sequences specify how tests are run and the order of execution, together with reporting, database logging and connectivity, to requirements management and other enterprise systems, to ensure that results are correctly applied within the overall test plan.
TestStand fully supports HIL testing at every level through an execution API based on the Microsoft .NET framework. For example, it can automate VeriStand real-time sequences running on an NI PXI real-time controller, while simultaneously controlling a third-party instrument using drivers controlled through an interface such as IVI. TestStand also integrates with third-party test management and test-generation software platforms. For example, test-generation tools can create pathological inputs designed to force failures to evaluate system performance, and even insert failures into simulated hardware to evaluate built-in-self-test performance and other ECU reliability features.
The result is an environment that focuses on thoroughly testing embedded software instead of creating, qualifying, and documenting a custom test infrastructure from scratch.
In an increasingly complex environment with stringent safety assurance demands, vehicle development teams need to be able to deploy highly automated test systems that can make use of optimized elements and reusable test components. NI TestStand provides the infrastructure to support those requirements while ensuring that the development team’s test strategy qualifies under the vital ISO 26262 standard.
