Ingo Stürmer, Dietrich Travkin. Automated Transformation of MATLAB Simulink and Stateflow Models

14 

Full text

(1)

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

(2)

† 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

(3)

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)

(4)

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

(5)

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

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

(6)

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

(7)

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

(8)

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

(9)

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)

(10)

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

(11)

MATE Tool-Architecture

Calculation of Model Differences

Model 1

(12)

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 X

Data 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

(13)

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.

(14)

Flowchart Design Pattern: if-then-else

if (condition1) { action1; } else if (condition2) action2; } else if (condition3) action3; } else { action4; }

Figure

Updating...

References

Updating...

Related subjects :