Optimize Your Functional Safety Toolchain with MATLAB, Simulink and Polyspace
Overview
Choosing a toolchain for developing functionally safe electrical and/or electronic (E/E) systems is a demanding task. On one hand, the toolchain has to let engineers automate as many repetitive (and as such error-prone) tasks as possible.
Automation capabilities on the other hand may lead to silently injecting faults into the final product, or failing to detect issues therein. Therefore, standards require to manage the risk associated with automation use cases of development toolchains.
In this webinar, you will learn how to end-2-end develop high integrity systems using MATLAB, Simulink and Polyspace family of products. Hereby, you will learn how developing application software is ideally performed with Model-Based Design and production code generation, and how manual coding can support the development of non-application software components. You will also learn what Model-Based Design offers for effective and efficient integration and integration testing of application and non-application software.
Highlights
- Introduction to Functional safety and the importance of tool integration
- Reasons and strategies to optimize toolchains for functional safety
- Using Model-Based Design for system and software architectures
- Using MATLAB, Simulink and Polyspace for Unit detailed design and unit verification
- Integration testing with Model-Based Design
About the Presenters
Mohammad Abu-Alqumsan is a Product Manager at MathWorks. Mohammad focuses on quality, safety and cybersecurity and consults with industry participants on qualifying tools and developing workflows that comply with popular certification standards such as ISO 26262, SOTIF, IEC 61508, ISO 21434 and Automotive SPICE.
Alex Shin is a Principal Application Engineer at MathWorks. He specialises in helping customers in the area of simulation, verification and automatic code generation, primarily for commercial/production projects. His recent work includes defining simulation and verification process and implementation of Model-Based Design tools in large organisations. Mr. Shin received Bachelor’s degree from University of New South Wales in mechatronics engineering.
Recorded: 27 Jun 2023
Hello, everyone. Welcome to our webinar on optimizing functional safety toolchains with MATLAB, Simulink, and Polyspace. My name is Mohammad Abu-Alqumsan. I am a product marketing manager for the IEC Certification Kit at MathWorks. I have more than seven years of experience in the field of functional safety across the different industries. I am at MathWorks for more than three years where I work with industry participants on qualifying tools and developing workflows that comply with popular certification standards. I'm here with my colleague, Alex.
Hello. My name is Alex Shin and principal application engineer at MathWorks. I specialize in helping organizations applying model-based design for commercial projects based on different functional safety standards. I have been with MathWorks for around 15 years supporting different industries.
In this webinar, Alex and I will try to convince you with evidence that model-based design lets engineers develop systems to safety, cybersecurity, and quality management standards. Model-based design lets you also optimize your toolchain with high integration that adds to your effectiveness and efficiency. Last but not least, you will see how the IEC Certification Kit provides additional support to cover requirements of tool classification, qualification, and tool certification covering C, C++, HDL, and PLC workflows.
Here is today's agenda. We will start with an introduction to functional safety and standards. Then we will present the reference workflow for model-based design. You will then see how the IEC Certification Kit provides tool classification for tools that make up the reference workflow, in addition to evidence for the required tool qualification. We will then see how some additional resources can be helpful and beneficial to you to deepen your understanding of how model-based design is an ideal fit for functional safety projects.
All right. You are likely attending this webinar because you develop safety related products or work in a critical industry like automotive, rails, medical, or aerospace. Over the years, these industries have accumulated best practices to manage risks associated with new systems and products. Some of these industries have developed their own functional safety standards, and some even mandate external certification with respect to these standards like rails, medical, aerospace.
In automotive, functional safety is often subject to self certification, but tier one and tier two organizations do usually seek external certification. So let's start by revisiting the definition of functional safety. Functional safety, or FUSA, is usually defined as the absence of unreasonable or unacceptable risk due to hazards caused by malfunctioning behavior of electrical and/or electronic systems. System malfunctioning behavior can stem from failures in individual domains, or in other words, software and hardware.
While all software errors are systematic, hardware errors can be also random. Random hardware errors, in turn, can be permanent or transient. Very common examples of permanent hardware errors include open and short circuits. Transient random hardware errors include single or multiple bit upsets, which can be caused by cosmic rays.
As earlier mentioned, there is currently different industry specific functional safety standards that provide objectives and methods to identify and mitigate risks associated with developed systems. You might already know IEC 60158, which is considered a parent for all safety standards and remains generic for industries that do not have a specialized standard. With this common ancestor, functional safety standards share a lot of activities and methods in common.
ISO 26262 is relatively a recent standard, as it is first published in 2011 and revised in 2018. ISO 26262 enjoys a wide adoption in the automotive industry and is currently considered the state of the art in functional safety, and as such, we see its adoption and use beyond the automotive industry. This is why you will see ISO 26262 taken as an example throughout the presentation. The highlighted standards on this slide are explicitly and directly covered by model-based design, as we will see later.
But don't worry if you are working on other safety standards. There is a high chance that your requirements are also covered by model-based design. Let's have a bird's eye view on these standards, with ISO 26262 being an example. Automotive OEMs and the different tiers develop systems and subsystems to realize new functions and items.
Here is an example system implementing the intended function of an item. Standards required to analyze hazards and assess risks associated with these functions during concept phase. The result of this exercise is to assign an ASIL or automotive safety integrity level for the hazards and to derive safety goals that mitigate them.
ASILs are determined from the severity, controllability, and exposure of each identified vehicle level hazard that can be caused by the system possible malfunctions. ASILs can go from A to D, where D is the most critical. QM functions denote the additional class where quality management processes are sufficient to control and mitigate risks.
Results at this stage guide the rest of the development process, as the level of rigor required throughout the development activities is proportional to the ASIL level. The story of IEC 61508 and its derivative standards is not dramatically different. The standard defines safety integrity levels or cells that go from one to four. Some standards, like N50128 and N50657 define additional basic integrity level very similar to the automotive level.
So let's see how the determined integrity level would guide the development process. The reference process model in ISO 26262, for example, requires the specification of system safety requirements, and the allocation of these requirements to the system architectural design. At the software level, the standard requires comparable activities where the software architecture is detailed to a level that permits the design and implementation of individual software components.
On the right side of the V, further activities are required to verify software components, software software integration, software hardware integration, and finally, to verify system and vehicle integration. Other standards have a very similar approach, especially for software development activities. And the reason for this overlap is that software can only have systematic faults that stem from incorrect requirements, design implementation, et cetera.
Each activity in the reference process is covered by a clause which details the requirements, recommendations, and work products required for compliance. Requirements are in turn governed by the determined ASIL. In ISO 26262, this means referring to the methods tables from the standard and choosing methods that correspond to the determined ASIL. Here is an example from system level verification where you see simulation and system prototyping are highly recommended for ASIL C and D.
Also at the hardware software integration, back to back testing is highly recommended. Hereby, one needs to have a model for the implemented system to be able to compare results from exercising the model versus exercising the implementation. Another example for back to back testing comes from table five, concerning the testing of functional performance, accuracy, and timing for hardware software integration. These snippets from the standard show that models are highly recommended and necessary for system level activities for ASIL C and D.
At the software level, the standard highly recommends to use semi-formal notations for software architectural design and for software unit design. Please also note that the standard acknowledges the use of Simulink and stateflow to this end. Semi-formal notations are also highly recommended to specify safety requirements at system, hardware, and software levels.
Similarly, the standard recommends to simulate the dynamic behavior of the software architecture, as well as back to back testing between model and code to verify software units and their integration. To summarize, ISO 26262 highly recommends the use of models at different stages of product development. Here is a summary of the use cases from the shown tables mapped to the reference process model of ISO 26262.
Bottom line here is that when you develop ASIL C or ASIL D functions, you would need to use semi-formal notations, including models, throughout the development process. The standard also recommends using models for lower ASIL, ASIL A and ASIL B. Remember, ISO 26262 was just an example. Other standards have comparable requirements on the use of models and semi-formal notations.
As such, an optimized development toolchain would need to support semi-formal notations, including models, and need to support simulation for ASIL C and D. Let's consider this as a constraint on the choice of the toolchain. Also, in order to perform all required activities required by standards, the following objectives for choosing an optimized toolchain should be and usually are taken into consideration.
The toolchain should offer high levels of automation without compromising safety or quality. Ideally, it also should support defect prevention rather than late discovery of errors and is well integrated with minimal breaks. The toolchain should also cover aspects of tool classification, qualification, and certification. This is subject to supporting semi-formal notations, as we have seen already, and development of mixed criticality software, which is a common requirement in almost every project. Also, the toolchain should support traceability across all tool generated artifacts.
Based on experience working with customers across industries, we can say, with much confidence, that model-based design using MATLAB Simulink is an optimal approach when it comes to choosing a toolchain to achieve these objectives and given these constraints. We will use the remaining time to show why this is the case. So what is model-based design, or MBD? We describe model-based design as the systematic use of models throughout the development process, and there are two major components-- modeling and automation.
With Simulink, you can model and simulate your systems to try out new ideas and explore the design space more easily and within reasonable times. Your entire team can use one multi-domain environment to simulate how all parts of the system behave. This includes signal processing, communication systems, autonomous systems, control systems, and physical systems. You can develop simulation driven tests that are fast and repeatable to quickly validate your changes. The second component to model-based design is the automation of coding and verification.
With Simulink you can automatically generate code from your system and system model, and instead of writing thousands of lines of code by hand, you can automatically generate production quality C and HDL code that behave the same way as the model you created in Simulink. You can deploy the code directly onto your embedded processor for FPGA or ASIC. Simulink also provides tools for you to automate the testing and verification process so that you can test early and test often.
You can test your system under conditions that are too risky or time consuming to consider instead of using expensive prototypes. You can validate your design with hardware in the loop testing and rapid prototyping, all while maintaining traceability from requirements to the system architecture, to design, and to code. Now that we have introduced model-based design and functional safety, let's see how the reference workflow marries the two in a highly streamlined way.
Here is, again, the process reference from ISO 26262, which we have seen earlier. This is a flattened version of the process, which we will use to show you how model-based design, using the Simulink family of products, can support your activities effectively and efficiently. Starting at the system level, you can use Requirements Toolbox and System Composer to author system requirements and to design the system architecture.
You can use features of Simulink test to early verify your system architectural models. You can reuse Requirements Toolbox and System Composer to author software requirements and to design software architectures. Doing so, you will maintain bidirectional links between the software and the system level in terms of requirements and architectural design.
You can use Simulink and Stateflow to refine your software architecture to a level where software components and units can be identified and implemented. On the basis of the software unit models, you can perform static model verification using Simulink Check and Simulink Design Verifier. You can also use Simulink Test to dynamically verify the detailed design in these models. This constitutes an early verification even before code is generated, or even before the availability of your hardware.
Once these models are fully verified against the allocated requirements, they can be considered as a basis for code generation. After this early verification phase, you can automatically generate code from your models using Embedded Coder. You can use Polyspace bug finder to statically check the generated code for MESRA compliance. You can use Simulink Test additionally to dynamically verify the models and their generated code using software in the loop or cell and processor in the loop or PIL simulations.
You can also use Simulink test for back to back equivalence testing. Here is the typical workflow for back to back testing, which, as we have seen earlier, is a highly recommended method for ASIL C and D. With back to back testing, you compare the middle-- you compare the model simulation results to results obtained when you exercise the code. This is typically used to verify model code equivalence, even when the expected test results are not available for you.
Back to the workflow. At all software integration levels you can use the same static and dynamic verification methods demonstrated at the model and code levels for the software components and units. In model-based design you have also different options on how to integrate legacy C and C++ code with your design and implementation models.
And for this legacy code, you can use Polyspace products for static code analysis. In particular, you can use Polyspace bug finder to collect code metrics, check against coding standards like MESRA C or Cert C, and to check for common defects and vulnerabilities. You can additionally use Polyspace Code Prover and its underlying formal methods to prove the absence of certain critical runtime errors. You might be wondering by now, how about MATLAB code?
Before release 23A, our recommendation was to test MATLAB code from within Simulink and using Simulink Test. Starting with the release 23A, you can now test MATLAB code with MATLAB Test without needing to go through Simulink at all. Also you can collect the coverage metrics often required by safety standards, including statement, condition, and MCDC. Also, traceability between requirements, the MATLAB code, and test cases that verify them can be established and maintained with the help of the Requirements Toolbox.
Requirements Toolbox allows you for some releases now to link requirements to certain parts of your MATLAB code. You can use the traceability matrix, as usual, to show overall links between two artifacts, including MATLAB files and MATLAB Test files. In order to assess the real time aspects of your system, you may want to perform hardware in the loop testing.
To this end, you can use Simulink test and Simulink real time for hardware in the loop testing. Depending on your item, this can be helpful at the unit level, at each software software integration level, and at each software hardware integration level. Having seen this reference workflow now, it is fair to say that model-based design tooling offers highest levels of support that let you comply with safety standards. Here is an example from the software part of ISO 26262.
In the x-axis, you see this T table which make all method tables in ISO 26262, part 6, on product development at the software level. Particularly, you see a stack of recommended and highly recommended methods. An example is table nine, showing structural coverage metrics that shall be collected during software unit verification. For this table, model-based design offers full coverage. All tables shown together here, model-based design achieves almost complete coverage of these methods.
Remains uncovered are irrelevant methods like formal methods or methods that are manual by definition, like pair programming. Also uncovered are methods that require the full vehicle hardware. Other standards follow a very similar approach to product development phases and activities. For example, the reference process in ISO 26262 and ISO 25119 are almost exactly the same. As such, it is fair to expect similar high degrees of coverage when using model-based design.
For a quick reference, here is another example for method coverage obtained with model-based design from IEC 61508. With this, we have seen how this reference workflow can help you achieve requirements on product development from functional safety standards. But is this everything needed? What about tool qualification? Alex, do you have some thoughts here?
Sure thing, Mohammad. Functional safety standards such as ISO 26262 require tool classification and qualification to ensure that the software tools used during any stage of the development workflow, including design, development, testing, and verification, are reliable. The tool qualification process aims to determine if the software tool is suitable for its intended use in the development of safety related systems, and whether it can be relied on to produce accurate and consistent results.
In the context of functional safety, any potential software tool errors or faults can lead to safety related system failures, which may result in severe consequences. Qualifying a tool aims to reduce the risk of introducing faults or errors related to the tool itself, thereby improving the overall safety of the system. Tool qualification is a process that involves several stages, typically following planning, pre-qualification, qualification, and reporting, and standards like ISO 26262 documents the approach.
Here is an example tool classification qualification approach from IEC 61508. Tool classification aims to identify the risk associated with every tool. In IEC 61508, software tools are classified into tool types 1, 2, or 3 based on their potential impact on system safety and reliability. The higher the tool type, the more rigorous the testing and qualification requirements.
If a class 2 or 3 tool cannot be validated or evidence is not available to confirm the behavior of the tool, then effective measures to control failures of the safety related software that results from tool faults must be implemented. Here is another tool qualification approach. This time it's from ISO 26262. Just like IEC 61508, it's divided into two parts, classification and qualification. Let's go through the approach here. The goal of tool classification is to define tool confidence level based on a tool's impact and the capabilities for error detection.
The very first step is to define its use cases. For an example, if Simulink test is being classified, one of the use cases would be to assess test results. Tool impact one is given if a malfunction of a tool cannot introduce or cannot fail to detect errors in the safety related item being developed. In all other cases tool impact 2 is given, which means this use case of Simulink tests needs to be classified with tool impact 2.
Now you can determine tool error detection based on the measures that prevent the tool from malfunctioning and producing erroneous output or measures that detect the malfunctioning behavior. For the use case of Simulink test, tool error detection level 3 is determined, resulting in tool classification level 3 or TCL 3. If you now look at the tool qualification part, depending on the tool confidence level given, additional qualification measures may be required based on the ASIL given for the safety related item in development.
This is applicable to the use case of Simulink test we discussed. Depending on the use cases, tool impact, and the error detection capabilities, here are common tool classification levels mapped to the reference workflow for your reference. ISO 26262 also details further qualification measures required for tool classified as TCL 2 or 3. For tools classified as TCL 2 or 3, additional qualification methods in the table must be applied and documented.
The qualification methods available to use are increased confidence from use, where the user provides evidence of the tool's reliability and qualification. Evaluation of the tool development process, where tool developers are required to produce evidence of their development and testing process. Validation of the software tool, where the tool undergoes testing and verification activities to confirm its suitability for use in functional safety projects.
And development in compliance with a safety standard, where the tool must be developed according to defined safety standards. From the methods, MathWorks provides development, process, audit report, and validation framework for the software tool, which can be used for the additional qualification measures. Now let's look at how a tool can actually be classified and qualified. Here is an example for MATLAB Test. MATLAB Test provides use cases for developing, securing, measuring, and managing dynamic test cases of MATLAB code.
To help the optimization of functional safety tool qualification steps, MathWorks provides tool qualification package, which includes tool classification and qualification work products. Supporting work products for MATLAB Test can be installed using Certification Artifacts Explorer. So once the Explorer is opened, you can use MATLAB Live Script that guides how to set up your qualification project. From the Live Script, a hyperlink can be used to automatically create the project at a location of your choice.
So once the installation is complete, a MATLAB project environment will be generated to facilitate the work product management. You're now ready to start the classification and qualification steps. A good place to start is tool qualification package and workflow document. In the document, information that can be used to create work products such as tool criteria evaluation report and tool classifications are available. If we take a closer look, tool use cases, as well as potential malfunction or erroneous outputs, are summarized.
Further details on prevention, detection measures are documented in the tool qualification package and the conformance demonstration template. You can use MATLAB test conformance demonstration template to document the integration and usage status for your application under consideration. And use the tags such as insert details as guidance as to where you should customize the documentation. Some safety standards, based on tools confidence level, recommend the validation of software tools by using application independent test cases.
These tests demonstrate that a tool complies with its specified requirements. Here is an example tool validation suite for MATLAB Test. Test cases and test procedures are provided for MATLAB Test's validation. Just like how we set up the environment, hyperlink is provided, which will automatically run the test cases and provide report at the end of the run.
The validation results should be reviewed to make sure the tool meets its requirements. And in this example, we can see that the tool use cases are validated against the tool requirements. To help you optimize your efforts around tool classification and qualification, MathWorks has pre-qualified the tools that make up the reference workflow. Additionally, TUV SUD has evaluated the tools work products and audited the development process for the required tool certifications.
This provides a framework for our user's project teams to streamline tool qualification. We packaged the required qualification work products in what is called IEC Certification Kit. IEC Certification Kit also contains documents to help demonstrate workflow conformance for different safety standards. In addition, MathWorks also offers trainings and consulting services to help you jump start and apply the process based on your project requirements.
IEC Certification Kit provides pre-qualification results for users to reuse and adapt to their functional safety projects. Now let's further look into it. You can opt for the Artifacts Explorer of the IEC Certification Kit from the MATLAB Simulink apps menu or from command line. As you see in the Explorer, the kit covers different tools that include MATLAB, Simulink Stateflow, coder family, and verification tools.
For each tool covered by the kit, you will find TUV SUD certification artifacts, including the certificate and the assessment report. Information on digital certificates are also available on TUV SUD's web page. Also for each supported tool, the tool qualification plan details information on analyzed tool use cases and resulting classification. Apart from that, you can find each tool a conformance demonstration template. This document allows you to customize according to the development process you may eventually follow.
For tools that require to demonstrate evidence for highest confidence, tool validation is required. Tool validation suit is provided as part of IEC Certification Kit as well. As functional safety standards cover required methods activities based on development workflow, workflow conformance document is provided to help map model-based design to the methods and activities. With this additional support for tool qualification, let's see coverage achieved for a standard like ISO 26262.
Overall, model-based design provides tool use cases that fully, partially, and indirectly cover the highlighted parts causes shown with different color coding. This includes concept and product development phases, as well as supporting processes like tool qualification. At each activity highlighted here, you can additionally use features of model-based design to automatically generate reports and mark products as evidence for compliance. Further details are outlined in the workflow and tool use case mapping documents.
So IEC Certification Kit also comes with a comprehensive case study and demo example to show how you may comply with requirements from ISO 26262. You may want to use the case study as a starting point to apply for your own project and other functional safety standards. The case study also shows an example of how the reference workflow can fit into continuous integration platforms like Jenkins. IEC Certification Kit supports many different safety standards required by different industries, including automotive, rail, medical devices, and many more.
If you're working in the aerospace industry, we have DO Qualification Kit covering the relevant safety standards for you. In today's talk, we focused mostly on the functional safety standards. However, IEC Certification Kit has more to offer. It comes with workflow documents based on the implementation languages you are using, such as C, C++, HDL, and PLC. Also provides details on complying with cyber security standards as well as standards related to ADAS and automated driving.
If you're working on ASPICE project, which we often see automotive customers using in combination with ISO 26262, an additional workflow document provided to map model-based design use cases to best practices from the standard. Now that we've covered tool classification and qualification and IEC Certification Kit, Muhammad, what else can we share with the audience today?
Thanks, Alex. Yes, indeed. We have collected some useful links for later access as our participants will receive these slides within a week or so. These links guide you through our product pages, solution pages, user stories, and technical papers relevant to today's topic. We also left you some user stories to learn from other customers like Ford, CAF, LG Electronics how they use model-based design to develop products to the highest levels of rigor and safety standards.
Here are some other examples related to Automotive SPICE as an example for quality management from Bosch, Volkswagen, and Kugler Maag. Alex has mentioned our training offerings briefly, but here is a list of training courses that can introduce you to model-based design. I would like also to highlight this new training course focusing on model-based design for ISO 26262. Check it out.
Many organizations decide also to work with our consulting services to migrate their existing processes to standard compliant processes whether the existing processes are based on traditional approaches or already based on model-based design. So we encourage you to reach out to our consulting team to learn more about our offerings in this space and how the team can help you in your development projects and for your specific needs.
Today, we have merely scratched the surface of how you can ensure your standard compliance with model-based design. Nonetheless, we hope by now that you are convinced model-based design lets engineers develop systems to industry standards and provides a well integrated and an optimized toolchain that supports all activities throughout the development life cycle.
Capabilities like simulation, automation, and report generation are first class citizens in model-based design. Additionally, IEC Certification Kit lets you cover requirements on tool classification, qualification, and tool certification. The kit also provides examples, guidance, and referenced C, C++, HDL, and PLC workflows. And as always, the ultimate persuasive evidence may come from your actual experience with model-based design and its tooling.
With this, we come to the end of this webinar. We hope you will leave it feeling inspired and with better understanding of the need for optimized toolchain. And remember, if you have any further questions or comments, don't hesitate to reach out to your account manager, to Alex, or to myself, where you can find us on LinkedIn. Thank you again for joining us, and I look forward to hopefully seeing you in our next webinar. Thank you.