Monthly Archives: April 2020

ISO26262 & Model Based Design: A Match Made in Heaven?

A majority of components in an automobile are gradually coming under the purview of safety-relevant systems. Some of these include the Body Control Module, Powertrain, Power Steering, Battery Management System and so on..

Safety brings with it, higher degree of complexity and in turn, heavier and complicated source code. Manual coding of such complex system is not feasible, given the time and cost constraints. And the fact that competitors are racing against time to be the first to introduce a cutting-edge functionality, makes it even more important for development activities to move at an accelerated pace.

Model Based Design, that has revolutionized system development approach in several engineering domains, plays a significant role on this front.

Developing an ISO 26262 compliant software entails compliance demonstration through evidences (work-products, Test Reports from ISO 26262 Qualified tools and more). When you deploy the MBD approach of development, many of these issues are managed viz a viz verification and validation at earlier stages, back-to-back tests between code and model, tool qualification, etc.

So, does this qualify ISO 26262 and Model Based Design paradigm to be a match ‘’made in heaven’’? Let’s find out!

Finding Model Based Development Approach in ISO 26262 Standard Document

As one would imagine, MBD finds a mention in Part-6 of the ISO 26262 standard. Part-6 deals with Product Development at the software level and it is natural that MBD is dealt with in detail here.

Right from the Software Safety Requirements to verification of software architectural design and beyond, Model Based Development is included as a special case.

Sample this: In the software architecture design verification part, it is specifically mentioned that the testing methods mentioned in Table-6 are to be applied to the model in case of MBD approach.

While we go through the document, we find that MBD is deeply rooted in ISO 26262. Moreover, the extensive V&V (verification and validation) that ISO 26262 mandates, appears easier when we follow the MBD paradigm of software development.

Part-6 also has a separate annexure that talks specifically about Model Based Design and highlights its difference with the manual coding technique. The mere presence of a section dedicated to MBD is a testament to the fact that MBD and ISO 26262 get along very well together. And as the complexity of the automotive system grows, the collaboration will be at a more granular level.

Following notes from Part-6 will help in making the MBD-ISO 26262 relations clear:

1. In the case of model-based development, modelling the structure is an inherent part of the overall modelling activities
2. If model-based development with automatic code generation is used, the implementation related properties apply to the model and need not apply to the source code.
3. In the case of model-based development with automatic code generation, the methods for representing the software unit design are applied to the model which serves as the basis for the code generation.
4. In the case of model-based software development the software unit specification design and implementation can be verified at the model level.
5. For model-based software development, the corresponding parts of the implementation model also represent objects for the test planning.
6. In the case of model-based development, the analysis of structural coverage can be performed at the model level using analogous structural coverage metrics for models.
7. For model-based development, software unit testing can be carried out at the model level followed by back-to back comparison tests between the model and the object code.
8. For model-based development, the software integration can be replaced with integration at the model level and subsequent automatic code generation from the integrated model.
9. For model-based development, the test objects can be the models associated with the software components
10. In the case of model-based development, software architecture testing can be performed at the model level using analogous structural coverage metrics for models.

Source: ISO 26262 Standard Document: 2011

Looking closely at these notes, it can be easily deduced that models have been considered as the reference for unit and integration testing. The testing process is strengthened by performing back-to-back tests between the model and the generated code.

Now, that we have a fair understanding of how ISO 26262 and MBD get along, let’s shift our focus on the MBD based Reference workflow.

What is MBD Based Reference Workflow for ISO 26262 Compliant Development?

MBD based safety related software development requires additional V&V requirements to be fulfilled when compared to non-MBD software development. Therefore, a reference workflow that considers the MBD specific notes (mentioned earlier) as well as the best practices, has been created.

Such a workflow can aid in meeting the safety requirements as prescribed in ISO 26262 standard. It does so by addressing the design and implementation together with the required tests and verifications.

The models are created based on the requirements as per the ISO 26262 modelling guidelines. Models are verified against the requirements (Model-in-Loop Testing). Next, the code is generated as per the coding guidelines. Once the code is generated, it is verified against the model (Processor-in-Loop Testing). Both MIL and PIL gives the measurement of structural coverage (code coverage).

How Does the MBD Based Reference Workflow Help?

• It describes MBD approach including model based testing and auto-code generation from the models.
• The workflow highlights the stages at which the ISO 26262 guidelines need to be applied for testing.
• Verification of the auto-generated C code is demonstrated by back-to-back testing.
• The workflow also has a document list that comprises tables with methods and measures recommended by ISO 26262 and the simulations and code coverages at code and model level.

A V-Cycle Perspective of the MBD Based Reference Workflow for ASIL Compliance

Implementation of ISO26262 using Model Based Development can be ensured by aligning MBD workflow with existing software development workflow.

On the right-hand side of the V cycle following checks can be performed for ISO62626 based MBD.

• Requirement Traceability:
  • Requirement Traceability is being able to track the life of a requirement from its conception to realization.
  • The developer must ensure Bi-directional Traceability (both forward and backward) of the requirements implemented as a model and link them to designs, code, and tests.
  • This will help the user to assess project completeness & support for industry standards.
  • Any unintended behavior of the system can be prevented if Requirement Traceability is followed.

 

• Model Compliance Check
  • Executable model needs to be verified against multiple checks.
  • Once the model is implemented, one should check model’s architecture and compliance to different standards like DO-178, ISO 26262, IEC 61508, IEC 62304, MAAB Style Guidelines, MISRA C, etc.
  • These compliance checks enable you to replace duplicate design elements, reduce design complexity and identify reusable content.

   

  Errors in Design

  • Hidden design errors must be identified in your models that might get missed during simulation testing. This includes errors like detecting blocks in the model that result in integer overflow, dead logic, array access violations, division by zero, etc.
  • The developer should generate appropriate number of test cases for such errors to identify & fix the issue in design phase.

   

  Coverage Check

  • Additional test cases need to be generated which will be useful to run the model to satisfy CC (condition), DC (decision), & MCDC (modified condition/decision) and relational boundary coverage.
  • This will help to assess the effectiveness of simulation testing in models, software-in-loop (SIL) and processor-in-loop (PIL). You can use missing coverage data to find gaps in testing, missing requirements or unintended functionality.

   

  Fixed Point Data Errors

  • If the model is using fixed point data, it should be ensured that all fixed-point and floating-point data types and target-specific numeric setting meet numerical accuracy requirements and target hardware constraints.
  • Test and debug quantization effects such as overflows and precision loss before implementing the design on hardware.

  Once the model is ready with all possible checks done, one can move towards the left-hand side of the V cycle.

  Following checks can be performed on the left-hand side of V cycle on the generated code.

   

  Traceability

  • Code can be checked against requirement traceability using traceability report generated by code generation tool.

   

  Static Code Analysis

  • Identify run-time errors, concurrency issues, security vulnerabilities, overflow, divide-by-zero, out-of-bounds array access in the C code generated form model.
  • This is possible by performing static analysis and semantic analysis. One should also perform analyses of software control, data flow and inter-procedural behavior. Find the bugs and fix them.
  • These code verification results can be used to track quality metrics and check conformance with software quality objectives.

   

  Code testing

  Generated code must be tested in both standalone and integrated environment to ensure that there are no errors or differences in the obtained results and coverages compared to the results/coverages obtained in virtual testing.

Value-Add of Integrating MBD Methodology in ISO 26262 Compliance Development

• Most of the processes and steps to check safety standard compliance can be automated using standard tools available in the market.
• Due to this possibility of automation, overall process becomes efficient and quite accurate.
• This also offers an edge over competition when it comes to making your presence felt in the market.

Final Remarks

The future of Automotive Technology belongs to Automated Driving, Electric Vehicles and Telematics. Safety compliance as well as complexity aspects of these systems point towards a closer collaboration of model-based design approach and ISO 26262. And when you consider the value-adds of this integration, you have a winner!

Watch this space for more such insights on ISO 26262 as well as model based development of automotive applications.

How to Perform Hardware-in-Loop Testing for an Automotive Solution Development

New age Automotive ECU applications are complex systems. An insane amount of information needs to be processed in real-time and rendered to various other systems. An ADAS system, for example, uses an advanced algorithm to processes data from the cameras, radars, GPS and other sensors to assist the drivers in avoiding judgement errors while driving. Such a data-heavy system has to be fool-proof and to ensure that, the testing must be rigorous and comprehensive.

Testing such complex systems on a real vehicle to prove every possible use-case is not a viable option. It incurs huge overheads and it is very challenging to test every scenario. Moreover, performing the tests at the final assembly entails test-related changes that can seriously impact the schedule as well as the cost. Also, the entire assembled platform might not be available for testing at the required time.

Simulation happens to be the only plausible approach to such testing and thus arrives Hardware-in-Loop testing methods. Not only does it automate the testing process but also brings in the tests much early in the software development lifecycle.

While we make it sound very easy to have HIL Testing unravel the software defects without an assembled product, a lot actually goes into the process.

Let’s begin by understanding HIL Testing at a high level, followed with a detailed analysis of the HIL Test system and the testing process.

What is Hardware-in-Loop Testing?

In the simplest terms, HIL Testing is a method to validate a software in a simulated environment where ECU functions can be tested without having the actual vehicle system. HIL Testing is used to validate the communication, system integration and the functionality aspect of automotive software.

Ideally, an ECU under test receives huge number of I/O signals that represent different functionalities. A comprehensive test means that all these functionalities are tested under the scenarios based on the requirements. So, what exactly conspires during HIL tests?

During HIL Testing, the ECU is connected to a Test System that mimics an assembled product (an engine, a body control module or even the entire vehicle system). It interacts with the input and the output of the ECU under test, as if it were an actual vehicle.

Using a HIL Testing software, different test scenarios can be created, and the output validated. Depending on the software requirements, the test coverage can be expanded without worrying about the cost and physical risk to the system.

Hardware-in-Loop Testing Architecture

Finding HIL Testing in the V-Cycle Diagram

In the software development lifecycle, HIL Testing is the step where the software validation is performed. As clear from the V-cycle diagram, it is executed against the software requirements which may comprise functional as well as safety requirements (ISO 26262 compliance development).

Unit testing and integration testing precede the stage where the software is ready to be validated keeping the target hardware in loop.

A model based development paradigm takes a different approach where Hardware-in-Loop testing is preceded by Processor-in-Loop (PIL Testing), Software-in-Loop (SIL Testing), and Model-in-Loop (MIL Testing).

Understanding a Typical HIL Test System

A HIL test system is at the heart of HIL testing. The simulation part of the testing that we mentioned earlier, needs an environment that can trick the ECU into believing that it is connected to a real vehicle.

The test system provides this environment. And for that purpose, it requires a gamut of software and hardware components. Let’s discuss them!

1. Real-time Processing Unit: The processing unit is at the core of a HIL Test System. It performs the most intensive task of executing the components of the test system. Complex automotive controllers have a large number of I/O channels and bus communication to be handled. From logging of the data and I/O communication to test stimulus generation, it is the processing unit that keeps the tasks going.

   Why a real-time processor, you might ask? Well, the test system replaces actual ECUs and their I/O signals. For the test to be executed perfectly, an accurate simulation of the vehicle electronics has to be ensured. And hence, a real-time processing unit.

2. I/O Interfaces: The ECU under test needs to be connected to the HIL Test system for the signals to interact. The I/O interfaces are responsible for establishing this connection. These interfaces can be digital or analog signals.

   Using the I/O interfaces the test engineers can:

   • Generate stimulus signals
   • Manage the communication of the sensors and the actuators between DUT and Test System
   • Manage current/voltage and optical I/O channels

   The importance of I/O interfaces also lies in the fact that it has to make sure that the DUT must always behave in a way that it is controlling the actual hardware. Test System providers may provide both dedicated as well as configurable I/O interfaces.

3. Software Interface: Software components are essential to the HIL Test System as these are required for writing test cases, creating required stimulations and generating test reports.

   Typical software components that aid the HIL Test system are:

   • Test Case Scripting: The tool is required to create test cases using scripting language. Various scripting languages are used depending on the HIL Test system brand. For example, Vector VT System uses VTest Studio for writing test cases in CAPL script. On the other hand, DSpace uses Python for the same.
   • ECU simulation: A software tool for simulating other ECUs in a vehicle is of the prime importance in an automotive HIL testing setup. The ECU under test might have to interact with other ECUs during its operation. And therefore, during the HIL testing all such ECUs need to be simulated.
4. Device Under Test (DUT): Device under test (DUT) is the control unit, the functionality of which is being validated. It can be a powertrain ECU, a Battery Management System ECU or any other automotive control unit. For testing purpose, DUT is connected to the HIL Test System.

In addition to these, there are components that manage power supply by simulating the battery and other auxiliary modules like load boards.

Widely Used HIL Test Systems in Automotive Application Development

Several vendors have their HIL Test Systems out in the market. In the context of architecture, application framework and concept, most HIL test systems are almost identical. The only difference that one can spot is that they cater to diverse industries. For instance, VT System from Vector is designed specifically for automotive application development. DSpace caters to power electronics industry as a whole.

We will now discuss some of the popular HIL Test Systems that are deployed in Hardware-in-Loop testing.

• Vector VT system: VT System is a popular modular test system that is designed to access the ECU’s inputs and outputs for validation. The system works together with tools like CANoe and VTest Studio. Based on CAN Bus protocol, VT System also supports CAN, LIN and other communication protocols.
• National Instrument Lab View: Lab View from NI, is a HIL test framework that helps the engineers create flexible test applications using a graphical programming approach. A test system designed to integrate a vast range of hardware, LabVIEW serves diverse industries to develop smart machines and industrial equipment.
• DSpace System: The Test System comprises the complete tool-chain (software and hardware) required for a simulated test environment. The biggest advantage of using DSpace for automotive software development is that it is designed to support the tests methods and coverages mandated by ISO 26262 standard.

HIL Testing in Action: Testing a Motor Control System

Motor Controller ECU has some highly safety-critical tasks at hand viz. power steering, EV powertrain and so on. State-of-the art HIL Testing, thus becomes mandatory.

Generally, the motor controller ECUs need to be tested for

• PWM measurements
• Checking whether Encoders and resolvers are working fine at higher clock rate
• Evaluating the functioning of the Position sensor

A HIL Test system simulates the power electronics, electric motor and the vehicle environment at the signal, electrical and mechanical levels.

And for this, the HIL Test system needs access to

• ECU connections in order to control them
• Power supply
• Communication Bus (CAN)
• I/O channels

The HIL Test System does the following tasks:

• Simulates other ECUs with the help of CANoe or equivalent tool (depending on the type of HIL Test system deployed)
• Generates the required sensor input such as PWM signals, required voltage
• Simulates the actuator (electric motor) with electronic load and measures the output from the motor controller ECU such as PWM duty cycle
• Measures the voltage and current supplied

The Test Cases are written in software tools such as VTest Studio using scripts (CAPL, Python). The test reports are generated after the required tests are executed.

Conclusion

Hardware-in-Loop testing gives the automotive industry a chance to test their solutions before the actual target platform is ready. Not only does this ensure reduced time-to-market but also leads to a better and more technically matured product.

The probability of call-backs is reduced significantly when you have a thoroughly tested product in hand. Thanks to some great HIL Test Systems, automated HIL Testing is redefining the automotive industry and the future only looks brighter.