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

Transcription

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 Presentation Outline 2 Motivation Modeling Guidelines MATE Model Transformation (Demo) Model analysis and repair Layout improvements Design pattern instantiation Conclusions

2 Motivation: Model-based Development 3 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 Example: Why do we need Modeling Guidelines? 4 Crossed signal lines 1 throttle throttle (estimated) 2 speed speed (estimated) z z -1 Throttle transient correction Fixed-point product block with more than two operands 1 est_air_flow est. air flow. 3 EGO EGO (estimated) 4 MAP MAP (estimated) Pumping Constant Constant 0.5 FUNCTION Function Description of signal flow from left to right violated e1 Magical constant Hidden inport 6 mode 0.5 fuel_mode LOW <= e0 e0 EGO GT Threshold 5 fail_o2. fail_o2 NOR enable integration ~= not normal operation not normal operation enable integration Name of constant partially obscured hold integrator 0 czero T 2 z-1 feedback_correction feedback Discrete-Time correction. Integrator Signal name obscured

3 Example: Why do we need Modeling Guidelines? 5 FUNCTION Intake Airflow Estimation and Closed-Loop Correction Function 1 throttle throttle_ z z -1 Throttle transient speed correction est_air_flow_ 1 est_air_flow 2 speed speed_ speed DISP PC sum est_air_flow 3 MAP MAP MAP_ Pumping Constant CAL MAP DISP MAP x PC MAP x PC x speed Feedforward Control 4 EGO EGO_ Ramp Rate (Ki) 0.5 CAL CONST e1 0.5 <= e0 e0 e1 T z-1 feedback_correction_ 2 feedback_correction 5 fail_o2 6 fuel_mode Oxygen Sensor Switching Threshold CAL fail_o2_ fuel_mode_ EGO GT Threshold ~= not normal operation NOR enable integration 0 czero CONST hold integrator LOW not normal operation enable integration disablemode CONST Feedback Control 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) Maintainability, testing, reuse, and expandability

4 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 Presentation Outline 8 Motivation Modeling Guidelines MATE Model Transformation (Demo) Model analysis and repair Layout improvements Design pattern instantiation Conclusions

5 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 Verifying Modeling Guidelines with Checks 10 90; 4% Manual change necessary Experience: Checking a complex MATLAB Simulink & Stateflow model (~20000 blocks) with model checks Nearly 2000 Guideline violations detected Unsettled 170; 8% Unmittelbare Reparatur Reparatur mit User-Feedback Manuelle Änderung notwendig ungeklärt Finding: ~90% of all guideline violations can be repaired with (interactive) transformations 900; 45% Direct (automatic) repair 870; 43% Repair with user feedback Tool Support needed for Model Analysis and Repair

6 Presentation Outline 11 Motivation Modeling Guidelines MATE Model Transformation (Demo) Model analysis and repair Layout improvements Design pattern instantiation Conclusions MATE Project Partners 12 MATE: MATLAB Simulink and Stateflow Analysis and Transformation Environment: (Dr. Ingo Stürmer) Software Engineering Group (Prof. Wilhelm Schäfer) Real-Time Systems Lab (Prof. Andy Schürr) University of Kassel (Prof. Albert Zündorf) MATE University of Siegen (Prof. Udo Kelter)

7 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) Analysis Repair MATE Approach: Graph Transformations 14 Apply graph transformations Graph representation of the model needed Graph representation of the model in focus Concrete Syntax outports :OutPort block source :ProductBlock name = Product1 line line :Line :ConstantBlock line :Line name = Constant3 type = int16 line value = 4 block source :OutPort outports inports target :InPort no = 1 block :ProductBlock block name = Product2 block target :InPort no = 2 inports Abstract Syntax (Graph) outports :OutPort...

8 MATE Approach: Graph Transformations 15 Abstract Syntax Graph Pattern Specification Specification of Graph Transformations Generated Model Analysis and Transformation Code Presentation Outline 16 Motivation Modeling Guidelines MATE Model Transformation (Demo) Model analysis and repair Layout improvements Design pattern instantiation Conclusions

9 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 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 timeconsuming 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 19 Model Engineering Solutions Dr.-Ing. Ingo Stürmer Friedrichstraße Berlin Germany Tel +49(0) Fax +49 (0) Internet: Backup Slides 20

11 MATE Tool-Architecture Calculation of Model Differences Model 1 Model 2

12 Data-flow Analysis X= A x ((C-B)-(A-B)) A B B Data type: sfix(16) Scaling: 2^(-11) X Data ty pe:sf ix(16) Scaling: 2^(-11) X C B MATE X outputerror_max = E-4 Data type: sfix(16) Scaling: 2^(-11) Data type: sfix(16) Scaling: 2^(-11) output_min = output_max = D B Data type: sfix(16) Scaling: 2^(-11) 2 Data type: sfix(16) Scaling: 2^(-11) Data type:sfix(32) Scaling: 2^(-16) Y E Data type: sfix(32) Scaling: 2^(-16) Y Data ty pe:sf ix(16) Scaling: 2^(-9) MATE Y Data ty pe:sf ix(32) outputerror_max = Scaling: 2^(-16) 2 Data ty pe:sf ix(16) Scaling: 2^(-10) output_min = output_max = F Data ty pe:sf ix(16) Scaling: 2^(-9) M-Script Implementation of Rule tl_0009

13 Example of a Modeling Guideline: tl_ 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. Example of a Modeling Guideline (cont.)

14 Flowchart Design Pattern: if-then-else if (condition1) { action1; } else if (condition2) action2; } else if (condition3) action3; } else { action4; } Design pattern Pseudo code