Modeling with TDL - Chess · 22 W. Pree CHESS seminar, UC Berkeley, Sept 26, 2006 Matlab/Simulink simulation of TDL modules before the simulation is started, the TDL compiler processes

Modeling with the Timing Definition Language (TDL)

Wolfgang Pree Professor

Department of Computer Science Univ. Salzburg, Austria

W. Pree 2 CHESS seminar, UC Berkeley, Sept 26, 2006

Overview

  What is TDL?   TDL component model   TDL tool chain   simulation in Matlab/Simulink   transparent distribution of components


What is TDL?

  A high-level textual notation for defining the timing behavior of a real-time application.

  Conceptually based on Giotto

  TDL = Giotto + syntax + cleanups + component architecture + control engineering enhancements.

Analogy: IDL (CORBA, MIDL) vs. TDL

IDL defines an interface for a distributed application

=> Separates interface from implementation

TDL defines the timing for a real-time application

=> Separates timing from implementation


Embedded hard real-time software


Multi-rate, multi-mode systems (Giotto)


Multi-rate, multi-mode systems (II)

LET-semantics


Logical Execution Time (LET) abstraction

ET <= WCET <= LET

results are available at 'terminate'

time task invocation

Logical Execution Time (LET)

Logical

Physical

start stop suspend resume

release terminate


Motivation for the TDL component model

  e.g. modern cars have up to 80 control units (ECUs)   ECU consolidation is a topic   run multiple programs on one ECU   leads to TDL component model

ECU1 Program1

ECU2 Program2

ECU3 Program3


TDL component model

  ProgramX is called a module   modules may be independent   modules may also refer to each other   modules can be used for multiple purposes

ECU Program1 Program2 Program3


Modules


Modules

public


Modules

public

private


TDL syntax by example module M1 {

sensor boolean s1 uses getS1; actuator int a1 := 10 uses setA1;

public task inc { output int o := 10; uses incImpl(o); }

start mode main [period=10ms] { task [freq=1] inc(); // LET = 10ms / 1 = 10ms actuator [freq=2] a1 := inc.o; // update every 10ms/2 = 5ms mode [freq=1] if exitMain(s1) then freeze; }

mode freeze [period=1000ms] {} }


Module import

module M2{

import M1; … task clientTask { input int i1; … } mode main [period=100ms] { task [freq=1] clientTask(M1.inc.o); … } }

TDL supports

  structured module names (e.g. com.avl.p1.M1)

  import with rename: (e.g. import com.avl.p1.M1 as A1;)

  group import: (e.g. import com.avl.p1 {M1, M2, M3};)


Module summary

  provides a named program component   provides a name space   partitions the set of actuators   allows for exporting sensors, constants, types, task outputs   may be imported by other module(s)   acts as unit of composition   acts as the unit of distribution   acts as the unit of loading   acts as the unit of execution

TDL supports multi mode & multi rate & multi program systems.


TDL tool chain


core tool chain

.tdl Compiler E-machine* .ecode

functionality code

*Simulink, FlexRay-AES, OSEK, INtime, RTLinux, ...


plug-in architecture of compiler

.tdl Compiler

Platform plugin* platform

specific

AST

platform specific

.ecode


functionality code

E-machine*


tool chain overview

.tdl Compiler

Platform plugin* platform

specific

AST

platform specific

.ecode

Decoder .txt TDL: Visual

Creator

Matlab/Simulink


functionality code

E-machine*

Model


Simulation in Matlab/Simulink


How can we ensure that simulated behavior and behavior on a specific platform are equivalent?

  we use the same E-machine implementation   in Matlab/Simulink the E-machine implementation is

wrapped within an S-function


Matlab/Simulink simulation of TDL modules

  before the simulation is started, the TDL compiler processes the textual representation of each TDL module and generates E-code that is then interpretetd by the S-function-E-machine

  The E-machine operates at a single discrete sample time that is computed from the minimum period used by any activity in all possible modes.


Transparent distribution


Transparent distribution of TDL modules (I)

  Modules are the natural choice as unit of distribution because dataflow within a module (cohesion) will most probably be much larger than dataflow across module boundaries (adhesion).

  The possibility to distribute modules across different computation nodes leads us to the notion of transparent distribution.


Transparent distribution of TDL modules (II)

  We define the term transparent distribution in the context of hard real-time applications with respect to two points of view:

  Firstly, at runtime a set of modules behaves exactly the same, no matter if all modules (i.e. components) are executed on a single node or if they are distributed across multiple nodes. The logical timing is always preserved, only the physical timing, which is not observable from the outside, may be changed.

  Secondly, for the developer of a module, it does not matter where the module itself and any imported modules are executed.


Communication scheduling requirements resulting from transparent distribution (I)

Example:


Communication scheduling requirements resulting from transparent distribution (II)

  sample execution of the two tasks on a single node:


Distributed components (I)

  M1 and M2 on different nodes.   We call the local memory buffer of node1 comm1 and

the local memory buffer of node 2 comm2.


Distributed components (II)


Distributed components (II)

communication window


Transparent distribution challenge

each mode combination => another static bus schedule The challenge was to beat the combinatorial explosion of the number of static bus schedules, as we need to generate potentially one static bus schedule for each mode/phase combination. If we have i communicating modules and each module k (1 <= k <= i) has kmodes modes, we would have to generate

bus schedules.


solution with what we call dynamic multiplexing


sample binding of several messages to one frame


Status quo

  ready   TDL:VisualCreator   TDL:Compiler and Bus Schedule Generator for FlexRay   TDL:Machine for Simulink, FlexRay-AES, INtime, OSEK   Decoder   TDL:VisualDistributor

  you can get a free trial version of the TDL:VisualCreator in Simulink (includes the TDL:Compiler)

  work in progress   fine-grained integration with DESIGNERPRO (DeComSys.com)   TDL extensions


Thank you for your attention!

Documents

Modeling with TDL - Chess · 22 W. Pree CHESS seminar, UC Berkeley, Sept 26, 2006 Matlab/Simulink simulation of TDL modules before the simulation is started, the TDL compiler processes