Model based software design lecture notes

MBSD notes

2018-2019 Prof. Massimo Violante

Francesco Malacarne 1

Sommario

Hardware basics ............................................................................................................................................ 3

Model-based software design ...................................................................................................................... 9

Model of a system ..................................................................................................................................... 9

Design flow .............................................................................................................................................. 13

Code generation: algorithm export or full executable? ......................................................................... 22

Design guidelines .................................................................................................................................... 26

Simulink solver ........................................................................................................................................ 33

Solver for code generation ..................................................................................................................... 36

Auto-code generation ................................................................................................................................. 40

Model construction and configuration ................................................................................................... 40

Code generation

...................................................................................................................................... 42

Analysis of the generated code............................................................................................................... 46

How to deal with different solvers ......................................................................................................... 49

How to create a code generation? ......................................................................................................... 49

Some C language reviews ....................................................................................................................... 50

Pointer ................................................................................................................................................. 50

Functions ............................................................................................................................................. 50

Stateflow ..................................................................................................................................................... 50

Why can’t we use Simulink? ................................................................................................................... 51

Code generation of this system .............................................................................................................. 55

Led blinking model .................................................................................................................................. 55

Hazard indicator developement ......................................................................................................... 57

AUTOSAR ..................................................................................................................................................... 61

AUTOSAR introduction ............................................................................................................................ 61

Architecture description ......................................................................................................................... 63

AUTOSAR operating system .................................................................................................................... 71

Main features of the operating system .............................................................................................. 71

ISO 26262 .................................................................................................................................................... 74

Testing ......................................................................................................................................................... 88

Hardware testing .................................................................................................................................... 89

Software testing ...................................................................................................................................... 91 2

Unit testing .......................................................................................................................................... 95

Integration testing ............................................................................................................................ 101

System testing ................................................................................................................................... 103

NI myRIO introduction .............................................................................................................................. 108

Description of the system to be used ................................................................................................... 108

NI myRIO connection ............................................................................................................................ 109

Simulink parameters ......................................................................................................................... 109

NI myRIO board configuration and connection ................................................................................ 112

Calibration with Calibra ........................................................................................................................ 114

Simulink model description .................................................................................................................. 117

Skyhook controller .................................................................................................................................... 118

Introduction .......................................................................................................................................... 118

Design flow of model-based design ...................................................................................................... 123

ADC and DAC implementation .............................................................................................................. 125

Model implementation on the myRIO board ....................................................................................... 130

Errors to avoid ....................................................................................................................................... 133

Semi-active suspension system ................................................................................................................ 135

Laboratory 4 .............................................................................................................................................. 136

Assignment............................................................................................................................................ 136

MIL with noise ....................................................................................................................................... 136 3

Lectures

Hardware basics

ISO 26262: titled "Road vehicles – Functional safety", is an international standard for functional safety of

electrical and/or electronic systems in production automobiles defined by the International Organization

for Standardization (ISO) in 2011. It contains the guidelines for the processes, methods and tools used

during the development of any electronic device present in automotive industry.

AUTOSAR: is a worldwide development partnership of vehicle manufacturers, suppliers, service providers

and companies from the automotive electronics, semiconductor and software industry. The primary goal

of the AUTOSAR partnership is the standardization of a common methodology, basic system functions and

functional interfaces. 4

The CPU is able to do two operations only: reading or writing. A generic read cycle or write cycle always

start with an address line: it is necessary to specify where the operation (no matter what) is going to be

performed. The second instruction contains the actual operation that is wanted (read or write).

CPUs contain memory elements inside. These memories, called registers, are very fast but also very

expensive, that’s why they are very limited. Each element of the registers has a specific role in the overall

loop. 5

Memories inside a PC are only two types: volatile or non-volatile. The first one is much faster than the

latter one, but it is also more expensive, that’s why it is used to store data that must be easily accessible,

and it is flushed any time the PC is powered-off.

The software of an embedded system must be on a non-volatile memory, since it must be present any

time the system is powered-up.

What is an embedded system? It is a controller programmed and controlled by a real time operating

system with dedicated function within a larger mechanical or electrical system. It is embedded as a part

of a complete device often including hardware and mechanical components. 6

Why are there two different types of architecture? Because it depends on the application. A control device

for a fixed and specific system, needs only a few memory and a very small computational power, the

processor has to compute specific tasks only, therefore it could be more efficient to choose a MCU. By

contrast, when dealing with possible upgrade due to the increasing complexity of the system, it could be

necessary to add memory, then a SoC shall be used.

What is the best solution for an embedded system? A MCU in general. Why? Because it is cheaper, more

compact and designed to do a precise task. What is the drawback? Since the processor is not very powerful

and designed for a specific task only, the control algorithm must be as simple as possible.

There are special MCU that guarantees a working condition also in the presence of failure. These

architecture implementations, such as the Infineon AURIX family, are used when safety is the most

important parameter (for example when dealing with airbags).

The first operation that a CPU does is to associate a certain address to any device present into the system. 7

The basic software is not something we are going to discuss, it is behind the control algorithm, it allows

the system to work properly. 8

9

Model-based software design

What’s the problem with the standard coding procedure? That it requires too much time. The handwritten

coding part can be easily avoided by means of a software that automatically produces the code.

Model of a system

The key point of the modelling phase is that a model doesn’t have to be a precise copy of the original

system, it must be able to behave like the original one, but in a simplified version, namely without all the

features that are not relevant for our purposes. Obviously, omitting information, we approximate the

original system. This approximation can be good or not depending on the precision level we need to 10

achieve, there is not a unique solution. Moreover, depending on the situation, we could obtain two

different models starting from the same origin, because the relevant features could be different!

Models are created to test different alternatives for the solution. Furthermore, they are the starting point

for the code generation, depending on the model, a certain code will be produced. 11

During the modelling phase we do not care about the implementation; we concentrate on what the

system should do, not on how it does. Basically, we do not care what is the code language or the platform

where it will be plugged-in; the same model could be developed in different languages. There is a

complete decoupling between the model development and the platform used. By contrast, when

producing the code, it is necessary to specify the platform where this software will go.

We are going to develop models of control strategies by means of a specific modelling language (Simulink

+ Stateflow for instance). Our control strategies will be only modelled, we will not develop the code that

will execute this control strategy. After the modelling phase we have a transformation tool: this tool takes

the model and it transforms automatically in something else (an artefact, a C code automatically

generated by the Simulink embedded coder). The transformation tool uses different transformation rules

depending on the artefact we must produce. 12

Nevertheless, the key point is that the model is the same irrespective of the used code language, the

transformation tool will deal with some transformation rules depending on the desired output.

What to do with the code? It depends on the configuration. Rapid prototyping or not?

Static models can’t be simulated, cannot be fed by inputs to evaluate the output. Static model can also

describe different states of a machine (basically different working conditions). On the contrary, dynamic

models can be simulated over time to see how the output reacts depending on the input.

For developing these models, it is necessary a modelling language. In particular, as we want a model that

is independent from the platform we are going to use, the language must be platform independent

domain specific language: language that allows to define models that abstract the details of the execution

platform (don’t care about them). Simulink is the PIDSL we will use to develop control strategies. Stateflow

is the PIDSL we will use to define state machines. Depending on the purpose it is necessary to select the

correct DSL (the correct software that allows to model our system).

Then this platform independent model is converted into a platform specific model that a computer can

run. 13

Design flow

• System requirements: challenging stuff, we need to understand what the user want. These

requirements must be collected and specified in a not-ambiguous manner.

• System design: it consists in the definition of the path and the tools necessary to achieve the

desired requirements.

• Software design: how many software units should we have? How do they interact with each

other?

• Coding: each unit must be coded.

• Software integration: any unit must be integrated in a global system that is able to accomplish the

system requirements. In general, each unit is developed by different teams, integrating code

developed by different people is not an easy task. Possible problems: different measurement

units. This is a very important task.

• HW/SW integration: once the software is complete, each unit has been integrated, it is necessary

to plug this software on the designed hardware. The software is not going to run on a normal

computer, it will run on an embedded computer that has been specifically designed for that

purpose.

• Calibration: if all the other steps were ok, then it is possible to proceed with the vehicle integration

and calibration. 14

System requirements and software design are included into the bottom part of the schematic. Basically,

in this part we will develop a model with a domain specific language (Simulink for example) to create a

platform independent model (namely that can be used for any platform).

During this part of the process, we will model two different components: the plant to be controlled and

the controller action used to control the plant. Basically, we will have two different models, not only one.

If we just model the control function, we can not test the C code (simulate it), which is dangerous because

we can not know if it is reliable or not, if it works or not. Before testing the controller on the real system,

we have to be reasonably sure that it will behave correctly, that’s why we are also modelling the plant.

Why testing on the real system? Because model is abstraction, then we are neglecting something. The

model of the plant and the model of the controller don’t have to be written into the same language and

by means of the same platform. 15

Model in the loop testing: what does it means? We have a model of the plant, a model of the controller

and we test them. If something is not working, we have to perform changes. In this scenario the working

environment is a development PC. We define test scenarios (different inputs) and then we evaluate the

outputs checking whether the system is able to follow the reference we placed as input. All the

components are developed in Simulink or Stateflow and tested on our development PC. 16

Code generation: the code generation comes after the model in the loop testing. Once we are 100% sure

about the model and the controller, we continue the process with the automatic code generation. The

code generation is based on a transformation tool that will produce an artefact (a code), given all the

specifications we provided. Obviously, this code depends on the platform we are going to use for our

system, however the starting model is always the same. 17

Software in the loop testing: the process of testing the C code generated for the controller is called

software in the loop testing. The idea is to work on the Development PC (still to make simulation), but in

this case we are testing the model of the plant with the real C code generated by the code generation.

We want to evaluate whether the software we produced is able to behave as the controller model we

created as a starting point. Why should we do this? The automatic code generation adds details

(implementation details, since the code depends on the used platform), then it could happen to have

errors or problems due to time. This process is performed many times in order to optimize the code. 18

Processor in the loop testing: We are no longer working with a development PC, we put the real code on

the real platform (embedded system to be used in the final application) and we test it. The embedded

system has a bounded amount of power with respect to the development PC, since it only requires

performances and it must be cheap. In this case we are working with a real platform (rapid prototyping

system, actual ECU) and the Simulink plant model on a development PC. Why? Because we need to test

the code on a system which has the same power as the final one. However, the real time