### Ingo Stürmer, Dietrich Travkin

### Automated Transformation of MATLAB

### Simulink and Stateflow Models

Ingo Stürmer – Model Engineering Solutions Dietrich Travkin – University of Paderborn

Object-oriented Modeling of Embedded Real-Time Systems (OMER4)
Paderborn, 31 October 2007
**2**

### Presentation Outline

###

### Motivation

###

### Modeling Guidelines

###

### MATE

###

### Model Transformation (Demo)

Model analysis and repair

Layout improvements

Design pattern instantiation

The way in which automotive embedded software is developed has undergone a change

Shift from traditional programming to model-based development

Use of MATLAB Simulink & Stateflow and TargetLink or RTW/EC

(Some) significant advantages of model-based

development

Early testing

Model-based code generation

Software quality now strongly dependent on models

used for software specification, simulation, and code generation

**3**

### Motivation: Model-based Development

**3**

**4**

### Example: Why do we need Modeling Guidelines?

**4**

2 feedback correction. 1 est. air flow. throttle (estimated) speed (estimated) ~= not normal operation hold integrator fuel_mode feedback_correction fail_O2 est_air_flow NOR enable integration e0 LOW 0 cZero 0.01-0.01z -1 1-0.8z -1 Throttle transient correction Pumping Constant 0.5 MAP (estimated) FUNCTION Function <= EGO GT Threshold EGO (estimated) z-1 T Discrete-Time Integrator 0.5 Constant 6 mode 5 fail_O2. 4 MAP 3 EGO 2 speed 1 throttle enable integration not normal operation

e1 e0

‘Hidden‘ inport ‘Magical‘ constant

Name of constant partially obscured

Crossed signal lines Fixed-point product block

with more than two operands

Signal name obscured

**5**

### Example: Why do we need Modeling Guidelines?

**5**

**Feedforward Control**

**Feedback Control**

**Intake Airflow Estimation and Closed-Loop Correction**

DISP DISP 2 feedback_correction 1 est_air_flow throttle_ sum est_air_flow speed_ ~= not normal operation hold integrator fuel_mode_ feedback_correction_ fail_O2_ est_air_flow_ NOR enable integration e1 e0 LOW disablemode CONST 0 cZero CONST 0.01-0.01z -1 1-0.8z -1 Throttle transient correction

Ramp Rate (Ki) CAL Pumping Constant CAL 0.5 Oxygen Sensor Switching Threshold CAL MAP_ MAP x PC x speed MAP x PC FUNCTION Function EGO_ <= EGO GT Threshold z-1 T 0.5 CONST 6 fuel_mode 5 fail_O2 4 EGO 3 MAP 2 speed 1 throttle enable integration not normal operation

PC
e1
e0
speed
speed
MAP
MAP
**6**

### Conclusion

**6**

What are the consequences of poor modeling?

A model that is difficult to read/understand

A model with only limited migration options

A model that is hard to maintain

Unsafe/faulty code

Adoption of modeling guidelines can significantly

increase the quality of the model (i.e. software) and result in:

Fewer errors

Greater comprehensibility (readability)

**7**

### Model-based Development: Challenges

**7**

###

### The increasing complexity of electronic systems

### and vehicle software is reflected in the increasing

### complexity of models

###

### Modeling tools offer limited mechanisms to

### handle this complexity and support the developer

###

### This is particularly evident in the fact that:

Support in checking and correcting models in

respect to modeling guidelines is not yet sufficiently
automated
**8**

### Presentation Outline

###

### Motivation

###

**Modeling Guidelines**

###

### MATE

###

### Model Transformation (Demo)

Model analysis and repair

Layout improvements

Design pattern instantiation

**9**

### Daimler Modeling Guidelines

**9**

A collection of best practices/expert know-how:

Autocode review

Model-based testing

Design of TargetLink MATLAB Simulink & Stateflow and TargetLink models

e.g. for passenger car and truck divisions

Currently over 200 guidelines and patterns for

MATLAB Simulink & Stateflow and TargetLink models alone

Central administration and publication on public-access

*e-Guidelines Server *

**Æ http://www.e-guidelines.de**

**Æ http://www.e-guidelines.de**

**10**

### Verifying Modeling Guidelines with Checks

Experience: Checking a complex MATLAB Simulink & Stateflow model (~20000 blocks) with model checks

Nearly 2000 Guideline violations detected

900; 45%

870; 43% 90; 4%

170; 8%

Unmittelbare Reparatur Reparatur mit User-Feedback Manuelle Änderung notwendig ungeklärt

Repair with user feedback

Direct (automatic) repair Unsettled

Manual change necessary

**Finding: ~90% of all **

**guideline violations can be **

**repaired with (interactive) **

**transformations**

**Tool Support needed for**

**Model Analysis and Repair**

**11**

### Presentation Outline

###

### Motivation

###

### Modeling Guidelines

###

**MATE**

###

### Model Transformation (Demo)

Model analysis and repair

Layout improvements

Design pattern instantiation

###

### Conclusions

**12**

### MATE – Project Partners

**12**

**MATE: MATLAB Simulink and Stateflow Analysis and **

**Transformation Environment:**

(Dr. Ingo Stürmer)

University of Kassel (Prof. Albert Zündorf) Real-Time Systems Lab

(Prof. Andy Schürr)

University of Siegen (Prof. Udo Kelter) Software Engineering Group

(Prof. Wilhelm Schäfer)

**MATE**

**MATE**

**13**

### MATE – Main Features

**13**

###

### Model analysis

Find guideline violations

Complex analyses, e.g. data-flow analysis

###

### Model Transformation

Model repair operations (automatic / interactive)

Design pattern instantiation

Model polishing (e.g. layout improvements)

**Repair**

**Analysis**

**14**

### MATE Approach: Graph Transformations

**14**

**Abstract Syntax (Graph)**

**Concrete Syntax**

**…**

**…**

**…**

**…**:OutPort :OutPort :OutPort :Line :Line :ProductBlock name = “Product1“ :ConstantBlock name = “Constant3“ type = “int16“ value = 4 :ProductBlock name = “Product2“ :InPort no = 1 :InPort no = 2 ... ... ... ... outPorts outPorts outPorts inPorts inPorts target target source source line line line line block block block block block

Apply graph transformations

Î Graph representation of the model needed

**15**

### MATE Approach: Graph Transformations

**15**

**Pattern Specification**

**Specification of Graph Transformations**

**Generated Model Analysis and **
**Transformation Code**

**Abstract Syntax Graph**

**16**

### Presentation Outline

###

### Motivation

###

### Modeling Guidelines

###

### MATE

###

**Model Transformation (Demo)**

Model analysis and repair

Layout improvements

Design pattern instantiation

**17**

### MATE Features NOT shown during the demo

**17**

###

### Automatic generation of model checks and transformations

###

### Model difference calculation

###

### Calculation of model metrics

###

### Offline (Batch) transformations

###

### Report generation

**18**

### Conclusions

**18**

Modeling guidelines are an important and appropriate

means of guaranteeing the quality of both model and generated code

The high number of rules that must be verified makes

manual checking (of guideline compliancy) a time-consuming and error-prone process

Even when employing a static analysis tool, the

modeler must still review the model

High-level checks with graph transformations make

model analyses easier, that were difficult and laborious to realize with previous means (e.g. m-scripts)

### Contact

**Model Engineering Solutions**

Dr.-Ing. Ingo Stürmer

Friedrichstraße 50
10117 Berlin
Germany
Tel +49(0)30·20659-173
Fax +49 (0)30·20659-200
E-mail: stuermer@model-engineers.com
Internet: http://www.model-engineers.com
**19**
**20**

### Backup Slides

### MATE Tool-Architecture

### Calculation of Model Differences

### Model 1

### Data-flow Analysis

X= A x ((C-B)-(A-B)) MATE X outputError_max = 2.44140625E-4 output_min = -5.499437180625 output_max = -5.498948899375 MATE Y outputError_max = 0.0011238956451416016 output_min = 2.049329624296875 output_max = 2.0502628157031255 Y XData ty pe:sf ix(16) Scaling: 2^(-10)

Data ty pe:sf ix(16) Scaling: 2^(-9) Data ty pe:sf ix(16)

Scaling: 2^(-9)

Data ty pe:sf ix(32) Scaling: 2^(-16) Data ty pe:sf ix(32)

Scaling: 2^(-16) Data ty pe:sf ix(16)

Scaling: 2^(-11)

2 2

Data ty pe: sf ix(32) Scaling: 2^(-16) Data ty pe: sf ix(16)

Scaling: 2^(-11)

Data ty pe: sf ix(16) Scaling: 2^(-11)

Data ty pe: sf ix(16) Scaling: 2^(-11)

Data ty pe: sf ix(16) Scaling: 2^(-11)

Data ty pe: sf ix(16) Scaling: 2^(-11) A B B B B C D X Y E F

**25**

### Example of a Modeling Guideline: tl_0009

**Limitations with Regard to Operand Numbers for the Product Block**
**Description**

**If a fixed-point data type is specified for the output of the Product block, the **

*number of inputs must not exceed two. If a vector signal is fed into a Product*
block, the number of elements of the vector must not exceed two.

**Remark**

*The generation of proper fixed-point code for the Product block with more *

than two operands requires the specification of scaling information for intermediate results. TargetLink therefore requires the number of input variables not to exceed two for fixed-point data types.