Loading...
News About John X. Wang

A Tribute to Dr. Nikola Tesla: Best Inventive Problem Solving (IPS) Practices for Embedded Software Testing

  • Jan 06, 2019 |

    As the author of the book My Inventions: The Autobiography of Nikola Tesla, Dr. Nikola Tesla once said,

    Of all things, I liked books best.”

    Dr. Nikola Tesla, one of the word's greatest electrical inventors and designers, was found dead on the night of January 7, 1943 in his suite at the Hotel New Yorker.

    Shall the Safety Engineering Community respond to these challenges by radically re-thinking the architecture of the HIL test platform and defining a next generation approach with inventive problem solving? Such a new architecture could introduce the concept of a HIL-Bus to integrate the functionality of multiple existing HIL sub-systems and meet the needs of a function-centric test environment. Dr. Nikola Tesla said:

    If you want to find the secrets of the universe, think in terms of energy, frequency and vibration.”

    Hardware-In-the-Loop (HIL) simulation is a technique that is used in the development and test of complex real-time embedded systems by thinking in terms of energy, frequency and vibration. etc.. HIL simulation provides an effective platform by adding the complexity of the plant under control to the test platform.

    Today, HIL simulation is a standard component in the vehicle development process as a method for testing electronic control unit (ECU) software. HIL simulation is used for all aspects of development, naturally including safety relevant functions and systems. This applies to all test tasks (from function testing to release tests, testing a single ECU or an ECU network, and so on) and also to different vehicle domains: The drivetrain, vehicle dynamics, driver assistance systems, interior/comfort systems and infotainment are all tested by HIL Thus, both the system modeling and control works can be then tested and/or validated quickly and safely in the real environment using this HIL setup. Hence, HIL testing methodology is the most time efficient and cost effective way to bring research and development of new systems and control algorithms one step closer to the real applications and productions. In vehicle development, the HIL test method is a well-known firm fixture in the product design progress as a method of testing electronic control unit software. ...

    Several commercial tool chains of HIL platforms for vehicles such as LABCAR, dSPACE, VeHIL or Autonomie are known. These kinds of tools can be utilized not only to test functionalities but also optimize the structure/parameters of one or even a network of control units. Consequently, they can improve the design success rate while eliminating the risk of development errors.

    The previous ECU-centric system architecture with its point-to-point communication infrastructure is no longer an efficient design approach. Automotive electronic systems are becoming truly distributed to achieve increased system functionality by tightly coupling ECUs. These changes encourage a significantly revised approach to automotive system test. This shift in system design is reflected in the evolution of ISO26262, derived from IEC61508, with its focus on functional safety assurance. It has a huge impact on automotive test platforms, HIL simulation, test platform provider.

    Which sections of iso 26262 apply to such a new architecture of the HIL test platform?

    The standard requires the following phases for software development: (The numbers correspond to the relevant section in the ISO 26262-6 standard.)

    6. Specification of software safety requirements

    7. Software architectural design

    8. Software unit design and implementation

    9. Software unit testing

    10. Software integration and testing

    11. Verification of software safety requirements

    Each of these phases requires specification of software tools used in development and testing.

    For Simulation & Test of Autonomous Driving in Real-Time

    Apply such a new architecture to ADAS HIL:

    • Verification & validation of automotive components (e.g. ECU)

    • Real-time model execution (Vehicle, Road, Traffic, Driver, Environment)

    • Standardized & modular HiL test system family: smartTEST L, M, S or XS

    • Measurement technology based on NI PXIe & NI CompactRIO

    • Control & evaluation of vehicle busses (CAN, LIN, FlexRay)

    • Signal conditioning with NI SLSC (Switch, Load & Signal Conditioning) or AEROspice / SMARTbrick

    • Active Breakout Panel (BOP) with Power BOP, Signal BOP, Video BOP, …

    • Power Distribution Unit (PDU) with safety system, circuit breaker, …

    • Software based on NI LabVIEW, NI TestStand, NI VeriStand & NI DIAdem

    • Fault Insertion Units (FIUs) compliant with ISO 26262 – Functional Safety

    • Customer-specific applications etc.

    ISO_DIS_26262-8(E) calls for the qualification of software development tools that are to be used in the development of safety related items under an ISO 26262 compliant process.

    Code Verification

    ISO 26262 provides several options for verifying software designs and implementations. The approach described in the CRC Press News allows for a limited trace review to detect unintended functionality in the generated code, such as code not traced to a block or signal. The approach enable automatically generating a trace matrix for this purpose. Alternatively, you can compare model coverage to code coverage using Simulink Coverage during software-in-the-loop (SIL) testing.

    Alternatively, you can check MISRA compliance with this approach. Use of MISRA checking and code coverage analysis is especially helpful if your project includes a mixture of generated and hand-coded software. For added rigor, you can select a sound static analysis tool to prove the absence of run-time errors such as divide-by-zero.

    ISO 26262 highly recommends back-to-back testing for ASILs C and D. It notes the importance of testing in a representative target hardware environment, and stresses the need to be aware of differences between the test and hardware environments:

    Differences between the test environment and the target environment can arise in the source code or object code, for example, due to different bit widths of data words and address words of the processors.

    However as every engineer should know, there are many sources for potential numeric differences across platforms, especially for floating-point data. Some begin as minor but accumulate and grow, especially in feedback control systems. Thus, ISO 26262 lists various in-the-loop methods for back-to-back testing. Software unit testing can be executed in different environments, for example:

    • model-in-the-loop tests;

    • software-in-the-loop tests;

    • processor-in-the-loop tests; and

    • hardware-in-the-loop tests.

    Summary

    Typically, the overall process compliance and considerations are taken into account for the robust design of the product, however we must be sure to not forget about the verification side of product development. Many of the functional safety standards specifically call out requirements and steps to be completed for test in addition to the design. At the same time, these considerations must be taken into account in all variations of verification that take place throughout the development cycle:

    This CRC Press News summarizes best Inventive Problem Solving (IPS) practices for Embedded Software Testing of Safety Compliant Systems. Dr. Nikola Tesla said:

    Invention is the most important product of man’s creative brain. The ultimate purpose is the complete mastery of mind over the material world, the harnessing of human nature to human needs.”

    See More
    Subjects
    Computer Science & Engineering, Energy & Clean Technology, Engineering - Electrical, Engineering - Environmental, Engineering - General, Engineering - Industrial & Manufacturing, Mathematics