loader image

Test Lösungen für Simulink Modelle und Seriencode

Virtual Validation for ADAS/AD

How can I create the needed millions of scenarios?

How can I avoid the test explosion problem?

How can I find out if my tests are passed or failed?

Products

Test Lösungen für Simulink Modelle und Seriencode

Virtual Validation for ADAS/AD

How can I create the needed millions of scenarios?

How can I avoid the test explosion problem?

How can I find out if my tests are passed or failed?

Blog

3 Reasons to Consider Using a Floating-Point Model to Generate Fixed-Point Code

Markus Gros

Berlin, Germany

Despite the availability of fast processors with dedicated floating-point support, we still see many projects generating fixed-point code from Simulink. The reason for this is not only the resource usage, but also the more transparent and predictable mathematical behavior. You can read more about this in our previous articles “What you should know about fixed-point” and “What you should know about floating-point”.

Assuming that we want to generate fixed-point production code from a Simulink model, there are basically two choices:

  • directly create a Simulink model with fixed-point types or
  • create a floating-point model first
 

The first option might seem natural, but starting with a floating-point model can have several advantages. Let’s try to look at it from three perspectives:

1. Development

In the automotive industry, applications in general and software in particular is getting more complex. With this growing complexity, we see many projects which separate the role of the function developer from the role of the software developer. The function developer might be an engineer with detailed domain knowledge (e.g. about the powertrain) while the software developer has the knowledge about the production code and the implementation details. In such a setting, it makes a lot of sense to allow the function developer to work in a somehow ideal mathematical world of float double types in Simulink, where he can focus on the actual algorithms, maybe do some rapid prototyping, and doesn’t need to think about implementation details like bit sizes or scalings. This would happen in a second step, where the software developer will configure and parametrize the code generator and in particular take care of the fixed-point data types and the scaling. 

2. Testing and Debugging

When test cases fail, we need to start a debugging to find the root cause. But if we directly implement everything in fixed-point the question is: Does the failed test case come from a problem with the algorithm or a problem with the scalings and resolutions of the variables.

If we create a floating-point model first, we can be sure that any errors found during requirements-based testing on model level (MIL) result from the algorithm itself.

In a second step, we can perform a Back-to-Back Test between model (MIL) and code (SIL/PIL) with suitable tolerances. Any deviations which occur in this second step would be caused by the scaling.

3. Reuse

Especially for larger projects, it is recommended to create a hierarchical software architecture where the actual software units are limited in their size. This is also directly mentioned in the ISO 26262 specification, which asks for “Appropriate hierarchical structure of the software components” and “Restricted size and complexity of software components”. We already talked about this topic in context of Model-based Development in our blog article “Modular Model-based Software Architecture for Efficient Unit and Integration Test”

Another positive effect of small software units is the potential to reuse them in different projects and/or on different target platforms. But this might require an adaption of the implementation data types. With a “master” Simulink model using FLP data types, we have the flexibility to generate different variants of the production code with either FLP data types or 8/16/32-bit FXP types. Each variant would require it’s dedicated Back-to-Back Test between model and code, but other test activities like Requirements-based Testing would only happen once at the model level. 

Settings for generating optimized fixed-point code from Simulink models with dSPACE TargetLink
TargetLink Import Block with floating-point datatype on model level and fixed-point type in code

Conclusion

Generating fixed-point code from a floating-point model can bring several benefits to the different stakeholders in a Model-based Development process. Function developers and software developers can efficiently focus on different aspects of the process. Test engineers can independently deal with different error sources. And last but not least, a model which is more independent from the actual implementation is more reusable within different projects and/or on different targets.

P.S.: Even in a floating-point model, it makes sense to use boolean/integer/enum types for the variables which do not represent a continous range of values.

Markus Gros

Berlin, Germany

Senior Vice President Marketing & Sales

Markus Gros studied Mechatronics at the University of Darmstadt and at the Universidad Politecnica de Catalunya in Barcelona. After his Diploma in 2007, he began working for dSPACE in Paris where he provided support, trainings and consulting to French customers in the Automotive and Aerospace Domain for topics including model-based development, automatic code generation, AUTOSAR and ISO 26262. In 2012, he joined BTC Embedded Systems AG where he is today responsible for global marketing & sales activities. Since the beginning of 2019, he also serves as President of the newly founded daughter company BTC Embedded Systems Inc. in Detroit.

Connect on LinkedIn

Popular Videos

Video abspielen
Video abspielen

Request Evaluation License

If you would like to try out our tools, we will gladly provide an evaluation license free of chargeEvaluations include a free launch workshop and also provide an opportunity for you to meet one-on-one with our support and engineering teams.

Schedule a Meeting

Do you have any questions or want to see our tools in action? If so, please use the link below to schedule a meeting, where a member of our engineering team will be happy to show you the features and use cases and directly answer any questions you might have.

Melden Sie sich für unseren Newsletter an!

Für den Newsletterversand wird Ihre Email Adresse vom DSGVO zertifizierten Dienstleister CleverReach verarbeitet. Weitere Informationen finden Sie in unserer Datenschutzerklärung.

Videos

Discover some of the main features of our products in these short videos.