Automatic SDF-based Code Generation from SimulinkModels for Embedded Software Development

Maher FakihOFFIS Institute for Information Technology

Oldenburg, Germanymaher.fakih@offis.de

Sebastian WarsitzCarl von Ossietzky UniversitÃd’t Oldenburg

Oldenburg, Germanysebastian.warsitz@uni-oldenburg.de

ABSTRACTMatlab/Simulink is a wide-spread tool for model-based de-sign of embedded systems. Supporting hierarchy, domainspecific building blocks, functional simulation and automaticcode-generation, makes it well-suited for the design of con-trol and signal processing systems. In this work, we pro-pose an automated translation methodology for a subset ofSimulink models to Synchronous dataflow Graphs (SDFGs)including the automatic code-generation of SDF-compatibleembedded code. A translation of Simulink models to SD-FGs, is very suitable due to Simulink actor-oriented mod-eling nature, allowing the application of several optimiza-tion techniques from the SDFG domain. Because of theirwell-defined semantics, SDFGs can be analyzed at compilingphase to obtain deadlock-free and memory-efficient sched-ules. In addition, several real-time analysis methods ex-ist which allow throughput-optimal mappings of SDFGs toMultiprocessor on Chip (MPSoC) while guaranteeing upper-bounded latencies. The correctness of our translation is jus-tified by integrating the SDF generated code as a software-in-the-loop (SIL) and comparing its results with the re-sults of the model-in-the-loop (MIL) simulation of referenceSimulink models. The translation is demonstrated with thehelp of two case studies: a Transmission Controller Unit(TCU) and an Automatic Climate Control.

CCS Concepts•Computer systems organization → System on achip; Embedded hardware;

1. INTRODUCTIONModel-based Design (MBD) of embedded systems is nowa-days a standard, easy and efficient way for capturing andverifying embedded software functional requirements. Themain idea is to move away from manual coding, and with

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copiesare not made or distributed for profit or commercial advantage and thatcopies bear this notice and the full citation on the first page. To copyotherwise, or republish, to post on servers or to redistribute to lists,requires prior specific permission and/or a fee.HIP3ES’2017, January 25, 2017, Stockholm, SwedenCopyright 2017 ACM 978-1-4503-4486-9/17/04. . . $15.00http://dx.doi.org/xx.xxxx/xxxxxxx.xxxxxxx

the help of mathematical models create executable specifi-cations using a certain modeling framework. These frame-works typically provide automatic code generators whichgenerate consistent imperative code ready to be deployed inreal environments. Matlab/Simulink [18] is one of the mostwide-spread tools for model-based design of embedded sys-tems which combines above features in a single framework.Simulink utilizes block-diagram to represent system modelsat the algorithmic level. For instance, in case of a controlsystem, the model consists of the controller algorithm blockwhich controls the environment block (or the process to becontrolled typically modeled as a set differential equations).

A translation of Simulink models to Synchronous DataflowGraphs (SDFGs) [12] which are, opposed to Simulink, for-mally based, is beneficial. Such a translation would pavethe way towards the application of several optimization andformal verification techniques well-established for the SDFGdomain. For e.g. in a recent work in [7] the formal real-timeverification (based on model-checking) of SDF applicationsrunning on Multiple-Processor-System-On-Chip (MPSoCs)with shared communication resources was shown to be moreviable than the real-time (RT) verification of generic tasks.Also for SDFGs deadlocks and bounded buffer propertiesare decidable [12]. In addition with the help of mathemati-cal methods easy-to-analyze compile-time schedules can beconstructed for SDFGs. Furthermore, memory-efficient codeoptimization are available [1, 2] to enable efficient implemen-tations of embedded systems.

In this paper, we present a translation procedure of a definedsubset of Simulink models to SDFGs based on the work in[24]. We extend the approach in [24] by enabling the transla-tion of Simulink models with multirates features to SDFGs.In addition, we integrate the translation procedure withinMatlab/Simulink and utilize the automatic code-generationfeature to generate SDF-based code from Simulink models.Moreover, we enable an automatic setup of a verificationflow which allows a Software-In-the-Loop (SIL) simulationshowing the functional equivalence of the generated code tothe reference model.

The paper is structured as follows. We will first recap thebasic concepts of synchronous dataflow graphs and Simulinkmodels identifying their main differences. Afterwards, wediscuss the related work in Sect. 3 mainly addressing trans-lation approaches of Simulink models to SDFGs. Next weelaborate on our translation procedure in Sect. 4, starting

arX

iv:1

701.

0421

7v2

[cs

.DC

] 3

1 Ja

n 20

17

768 128 64 64 64 64

get_MB CC DCT VLC

Actor Rate Delay

Channel JPEG Encoder

2D

Figure 1: SDFG of a JPEG Encoder

with description of the set of constraints on the Simulinkmodel enabling the translation. In addition, we discussthe code-generation and SIL verification features. Sect. 5demonstrate the viability of our translation approach withthe help of a Transmission Controller Unit (TCU) casestudy. Finally, we conclude our work and give an outlookon open issues and future work.

2. BACKGROUND

2.1 Synchronous Dataflow GraphsA synchronous (or static) data-flow graph (SDFG) [12] isa directed graph (see Fig.1) which, similar to general data-flow graphs (DFGs), consists mainly of nodes (called actors)modeling atomic functions/computations and arcs modelingthe data flow (called channels). In difference to DFGs, SD-FGs consume/produce a static number of data samples (to-kens) each time an actor executes (fires). An SDFG suitswell for modeling multi-rate streaming applications and DSPalgorithms and also allows static scheduling and easy par-allelization. A port rate denotes the number of tokens pro-duced or consumed in every activation of an actor. Thedata flow across a channel (which represents a FIFO buffer)is done according to a First-In-First-Out (FIFO) fashion.Channels could also store initial tokens (called delays indi-cated by bullets in the edges) in their initial state which helpresolving cyclic dependencies (see [12]).

Despite the analyzability advantage of SDFGs, yet thiscomes at the cost of their expressiveness. One of the mainlimitations of SDF Model of Computation (MoC) is that dy-namism cannot be handled for e.g. in the case where depend-ing on the current scenario the application rates changes(c.f. [23]). Another limitation (c.f. [12]) of the SDF MoC isthat conditional control flow is only allowed within an actorfunctionality but not among the actors. However, emulat-ing control flow within the SDFG is possible even thoughnot always efficient (c.f. [23]). Due to above limitations, fore.g. stopping and restarting an SDFG is not possible sincean SDFG can have only two states either running or wait-ing for input. In addition, reconfiguration of an SDFG tobe able to (de)activate different parts depending on specificmodes is not possible. Moreover, different rates dependingon run-time conditions are not supported. Also modelingexceptions which might require deactivating some parts ofthe graph is not possible. An additional issue is that theSDF model does not reflect the real-time nature of the con-nections to the real-time environment.

2.2 Simulink

Simulink is a framework for modeling of dynamic systemsand simulating them in virtual time. Modeling of such sys-tems is carried out graphically through a graphical editorconsisting mainly of blocks and arrows (connections) be-tween them representing signals. Each block has its input,output and optionally state variables. The relationship ofthe inputs with the old state variables and the outputs up-date is realized through mathematical functions. One of thepowerful features of Simulink is the ability to combine mul-tiple simulation domains (continuous and discrete). This isvery useful for embedded systems, where in general the con-troller has discrete model and the environment often needsto be modeled as a continuous one.

Simulink also supports a state-based MoC the Stateflow [21]which is widely used to model discrete controllers. Simulinkallows a fast Model-in-the-Loop (MIL) verification, wherethe functional model (of the controller for example) is simu-lated and results are documented to be compared with fur-ther refinements. In addition, a Software-in-the-Loop (SIL)verification is also possible in which the controller model isreplaced by the generated code from the Embedded Coder[19] (usually embedded in a S-function) and the behavior ofthe code is compared with the reference data achieved fromMIL (described above).

In [15] a method was presented to automatically transformSDFGs into SBDs (Synchronous Block Diagrams), such thatthe semantics of SDF are preserved, and it was proven thatSimulink can be used to capture and simulate SDF models.Also authors in [8] support this fact that dataflow models fitwell to concepts of block diagrams and are used by Simulink.In general, the MoC of Simulink is much more expressivethan that of the SDF having the advantage of being able torelax all limitations of the SDF MoC but at the cost of itsanalyzability.

3. RELATED WORKIn the last decade, several research [4, 5, 22, 25] have beenconducted to enable a translation of Simulink models toother formal models for the purpose of formal analysis. Inthe following, we merely discuss previous work enabling thetranslation of Simulink models to SDFGs.

In [14], only the source code of a so-called Simulink2SDFtool was published which enables a very simple translationof Simulink models to SDFGs. In this work all Simulinkblocks, without any distinction, were translated to data-flowactors and similarly connections were translated in data-flowchannels, the fact which makes the translation incompleteas we will see in Sec. 4. In addition, our approach allows thegeneration of executable SDF-code which is not possible inthis approach.

In [6] a translation of Simulink models to homogeneous SD-FGs (HSDFGs) was pursued with the objective of analyzingconcurrency. HSDFGs are SDFGs with the restriction thatthe number of consumed and produced tokens of each actormust be equal to 1 [10]. The translation has been done for afixed number of functional blocks but important attributes,such as the data type of a connection between blocks, have

not been taken into consideration by the the translation.

In [13] it was shown how a case study of a vehicle climatecontrol modeled in Simulink is imported to a tool (MoDAL)supporting SDF MoC. MoDAL, in turn, exports the modelin a format which can be imported by the Ptolemy tool[11]. Ptolemy is then used to generate code from the SDFmodel. In [13], only the use-case model have been translatedto an SDFG without general defining a translation conceptapplicable at least to a subset of Simulink models.

In [3] a translation from Simulink models to SDFGs wasdescribed. The aim of this work was to apply a method-ology for functional verification of Simulink models basedon Contracts. Contracts define pre- and post conditions tobe fulfilled for programs or program fragments. In [9], theability of SDFGs to model multi-periodic Simulink systemswas formally proved. There, in addition to systems withharmonic periods, also non-harmonic periods are supported(unlike our work and that of [3] where only harmonic peri-ods are supported). However, authors in above work, give noclear classification of critical Simulink functional blocks (e.g.the switch block with dynamic rates see Sec. 4) which can-not be supported in the translation. In addition, Triggered-/Enabled subsystems and other important attributes suchas the data type of a connection are not supported. Fur-thermore, SDF-based code-generation was not considered.

Unlike the above work, we present a general translation con-cept based on a classification of blocks and connections inSimulink models. Our approach enables the translation ofcritical blocks (such as Enabled/Triggered subsystems) in-cluding the enrichment of the translated SDFG with im-portant attributes such as the data types of tokens, tokens’size and sampling rates of actors (in case of multi-rate mod-els). This enables a seamless code generation of the modelinto SDF-based embedded software ready to be deployed ontarget architecture. We also provide an automation of theprocess of SDF-based code generation together with the SILverification to prove the soundness of the translation.

4. SIMULINK TO SDFG TRANSLATIONAs already stated (see Sec. 2.2), Simulink MoC is much moreexpressive than the SDFG MoC. Unlike SDFGs, Simulinksupports following additional features:

U1 Hierarchy (e.g. subsystem blocks): While in Simulinkmultiple functional blocks can be grouped into a subsystem,in SDFGs each actor is atomic and therefore no hierarchyis supported.

U2 Control-flow logic/Conditional (for e.g. switchblock or triggered subsystem see [18]): In Simulink con-trol flow is supported on the block level. This means thatdepending on the value of a control signal at a block, dif-ferent data rates could be output by the block. In contrary,in SDFGs data rates at input and output ports of an actorare fixed and control structures are only allowed within thefunctional code of an actor and can’t be represented in anSDFG.

U3 Connections:

1. Dataflow without connections (e.g. Goto/Fromblocks): In contrast to Simulink, there is no dataflowwithout a channel connection in connected and consis-tent1 SDFGs considered in this paper.

2. Grouping of connections (e.g. BusCreator block forbus signals): In Simulink, connections with differentproperties (e.g. different data types) can be groupedinto one connection. This is not possible in an SDFGsince the tokens transfered among a channel must havethe same properties.

3. Connection style: While in Simulink the storage ofdata between blocks has the same behavior as that of aregister where data can be overwritten (in case of multi-rate models), the inter-actor communication via chan-nels in SDFGs follows a (data-flow) FIFO buffer fashion,where tokens must be first consumed before being ableto buffer new ones.

U4 Sampling rates: In addition to the number of datatransported over a connection by every block activation, aperiodic sampling rate is assigned to each block in Simulinkto mark its periodic activation at this specific frequency. Ifall blocks exhibit the same sampling periods in a model,then this model is called a single-rate model otherwise itis a multi-rate model. In SDFGs, however, an actor isonly activated based on the availability of inputs. Actorsdo not have explicit sampling periods and therefore datarates can only be represented by the rates assigned to their(input/output) ports.

Because of the above differences, some constraints must beimposed on the Simulink input model in order to enable itstranslation to an equivalent SDFG, which we will discuss inthe following section.

4.1 Constraints on the Simulink ModelOnly Simulink models with fixed-step solver are supportedin the translation. In case of multi-rates, rate transi-tions should be inserted to the Simulink model and therates should be harmonic (divisible). These constraintsare indispensable to enable deterministic code generation[3, 20], since we aim with the help of Simulink built-in code-generator to generate SDF-compatible executable code forthe translated SDF application. Even though it is possi-ble to translate a Simulink model to multiple SDFGs, wedeal only with one application (implemented in Simulink)at a time in this paper, which results after translation intoone equivalent SDFG. This application is considered to bea control application having the general structure depictedin Fig. 9. Moreover, a correct functional simulation of theSimulink model is a prerequisite for the translation in orderto get an executable SDFG. In addition to above generalprerequisites, the following constraints are imposed on theinput Simulink model to enable the translation:

E1 Hierarchy: Hierarchical blocks (e.g. subsystems), inwhich one or more functional blocks of the types describedin U3-1 and U3-2 exist, are not allowed to be translated to

1Inconsistent SDFGs require unlimited storage or lead todeadlocks during execution[10].

atomic actors. Either these blocks should be removed fromthe entry Simulink model (for they serve only visualizationimprovement purpose) or the model should be dissolved atthe hierarchy level at which these components exist wherethese blocks are translated and connected in accordancewith the rest of the SDFG. This constraint is mandatory,otherwise if we allow an atomic translation of such hierar-chical functional blocks, their contained functional blocksof the form U3-1 and U3-2, which may be connected withfunctional blocks in different hierarchical levels, would dis-appear in the target SDFG. A translation of these blockswould thus no longer be possible and would cause a mal-function of the target SDFG (see restriction E3 ).

E2 Control-flow logic/Conditional: Blocks such asTriggered/Enabled subsystems can be translated just likethe general subsystems. Upon dissolving the hierarchy ofsuch subsystems, the control flow takes place now withinthe atomic functionality of the actor without being in con-tradiction to SDFG semantics (c.f. Sec. 2.1). In such atranslation, however, additional control channels must bedefined (see Sec. 4.2). Yet, the case described in U2 muststill be prohibited. In order to do that, there is an option“allowing different data input sizes” in Simulink for suchblocks, which when disabled, prohibits outputs of variablesizes of a control block2. A special case of these blocksis the powerful stateflow supported by Simulink. In ourtranslation we do not flatten the stateflow block and wealways translate it into one atomic actor.

E3 Connections

1. Dataflow without connections: For blocks hav-ing the same behavior described in U3-1 (such asFrom/Goto or DataStoreRead,/DataStoreWrite blocks),we assume that the source block (e.g. DataStoreWriteblock), intermediate block (e.g. DataStoreMemoryblock) and the target block (e.g. DataStoreRead block)which communicate without connections are available inthe input Simulink model. This constraint is importantas Simulink allows instantiating a source blocks withoutfor instantiating for e.g. the sink block.

2. Grouping of connections: In order to support thetranslation of Simulink models with blocks having thesame behavior as those described in U3-2 3, two con-straints must be imposed. The first one is that everyblock which groups multiple signals (e.g. BusCreator)into one signal must be directly connected to a blockwhich have the opposite functionality (e.g. BusSelec-tor). The second constraint is imposed on the block(e.g. BusSelector) which takes the grouped signals andsplits them again. An“Output as bus”should be prohib-ited in the options of this block. By doing this, groupingof signals for better visibility in the Simulink model isstill with the limitation above allowed, while prohibitinggrouping of signals of different parameters in one signalin the target translation.

2According to [18] blocks having this option are: Action-Port, Stateflow, Enable/Trigger Subsysteme, Switch, Multi-port Switch and Manual Switch.3e.g. BusCreator/BusSelector, Bus Assignment and Mergeblocks [18].

Figure 2: Original Simulink model: Red having a sampletime of 2, Green having a sample time 4

4.2 Translation ProcedureIn the following, we will roughly describe the translation pro-cedure implemented to extract an SDFG from a Simulinkmodel with the help of an academical Simulink multirateexample in Fig. 2. For the translation two main phasesare required: the pre-translation phase where the originalSimulink model is prepared and checked for the above de-fined constraints and the translation phase where the trans-lation takes place.

1. Pre-Translation phase:

(a) Checking Requirements: Here the Simulinkmodel is checked if it fulfills the constraints describedabove. If this is not the case the translation isaborted with an output of the list of unfulfilled con-straints.

Figure 3: Dissolving hierarchy to the desired level

(b) Dissolving hierarchy: In this step, a top-downflattening of the Simulink model (respecting E1 ),till the required depth level is reached, is done (seeFig. 3).

(c) Removing connecting blocks of type U3-1/U3-2: Here, blocks respecting the E3-1/E3-2constraint are removed. When doing this, the pre-decessor block of the source block (e.g. DataS-toreWrite block) is directly connected either to theintermediate (if existent) block (e.g. DataMem-ory block) or to the successor block of the targetblock (e.g. DataStoreRead block) and these con-necting blocks (source and target blocks) are re-moved (see Fig. 4 where BusCreator/BusSelectorand Goto/From blocks are removed).

Figure 4: Removing connecting blocks of type U3-1/U3-2

(d) Inserting rate-transition blocks: Here rate-transition block are inserted between blocks con-nected to each other and having different samplerates (see Fig. 5).

Figure 5: Inserting rate-transition blocks between blocks ofdifferent sample rates

2. Translation phase: In this step, the modified Simulinkmodel is directly translated into an SDFG (see Fig. 8)according to the following procedure:

(a) Translation of blocks: If B is the set of all blocksin Simulink model M then each block bl ∈ B inM is translated into an unique actor in the trans-lated SDFG al ∈ A (where A is the set of actors seeFig. 8).

(b) Translation of connections: Each output portbl.o is translated into a unique output port al.po andeach input port bl.i is translated into a unique inputport al.pi. In case multiple connections t1, t2, · · · , tngoing out from an output port po1 in Simulink(which is permitted in Simulink but not in theSDFG, see connections of statechart before Fig. 2and after translation Fig. 8), then for each oneof these connections, the output port is replicatedpo11, po12, · · · , po1m (each having the same proper-ties) in the resulting SDFG, in order to guaranteethat every channel d ∈ D (set of all channels in anSDFG) has unique input and output ports. Now,each connection t ∈ M in the Simulink model istranslated into a channel d ∈ D in the SDFG (seeFig. 8).

b1 b2

a1 R a2

sample λ sample λ/n

n 1

b)

a)

1 1

Figure 6: Example of a Simulink slow-to-fast multiratemodel shown in (a). By adding a rate-transition actor R, avalid translation to SDFG can be achieved in (b).

b)

a) b1 b2

a1 R a2

sample λ/n sample λ

1 n 1 1

(n-1)D

Figure 7: Example of a Simulink fast-to-slow multiratemodel (a) and its equivalent SDFG in (b).

(c) Extraction of Tokens’ sizes and types: Thenumber of the data transfered over a connection rep-resents the size of a token produced/consumed whenan actor fires (e.g. Constant actor produces a tokenof size 2 in Fig. 8) and their data type representsthe data type of that token (e.g. double in Fig. 8).These parameters can be extracted from the modelfor every connection.

(d) Handling Multi-rates: The following method forhandling multirates was inspired from [3, 25]. Todetermine the rates of the actors’ input and out-put ports we must differentiate between three cases:fast-to-slow transition, slow-to-fast transitions andtransitions between blocks having the same rates.For the latter case, source and destination actorsare denoted by a rate of 1 on their ports indicatingthe production/consumption of one token (of spe-cific size per channel) whenever activated. In caseof slow-to-fast transition (see e.g. in Fig. 6 and inFig. 10), the rate of the output port of the rate-transition actor

R.po.rate = bsrc.sp/bdst.sp, (1)

where po is the output port of the actor R, bsrc andbdst are the source and destination blocks connectedvia rate-transition block and sp the sample time ofthe corresponding block. The rate of the input portof R is set to 1. This basically realizes multiplecopies of tokens of the slower actor for the fasteractor to run.

In case of fast-to-slow transition, the rate R.pi.rateof the input port (pi) of the rate-transition actor Rcan be calculated as follows:

R.pi.rate = bdst.sp/bsrc.sp, (2)

Matlab/Simulink Code Generator

SDF based C-code

Verification model (SIL)

Check Requirements

Clean Simulink Model

Generate SDF based C-code

Generate Verification Model

SDF based C-code

S-function builder

Model

Environment

Environment

Controller

ou

tpu

ts

inp

uts

inputs

outputs

Controller

outputs

inputs

Sdfg_B3.h Sdfg_B3.c

queue q1,q2,q3,q4;

sdfg_initialize(){

initQueue(q1,1,1,1,0);

… }

sdfg_step(){

In1_actor();

In2_actor();

Product_actor();

Abs_actor();

Out1_actor();

}

Product_actor(){

dequeue(q1, P_U.In1);

dequeue(q2, P_U.In2);

Product_step();

enqueue(q3, P_Y.Out1);

}

…

In1 In2

Product

Abs

Out1

1 1

1

1

1 1

1 1

q1 q2

q3

q4

=

?

B1

B2 B3

B1

B2 B3

B3

Figure 9: Structure of the model transformation and code-generation framework. Simulink Model: consisting mainly ofa controller and the environment model. Code generator: implementing the translation of Simulink models to SDFGs,generating SDF code and the verification model. In this figure, the transformation is exemplary applied on the sub-block B3

of the controller Simulink model. SDF based C-code: executable code of the generated SDFG. Verification model: consists ofthe reference controller and environment models with an extra S-function builder block in which the generated SDF code isembedded and connected to the environment allowing SIL verification.

Constant

Chart

Constant1

Out1

Rate Transition

Product1

1

1 1

1

1

1

1

1

1 2 1

1D

Unit Delay

Out2

1

1

Single

Double

1

Double

Double

Figure 8: Translating modified Simulink model with fast-to-slow transitions into SDF

The output port rate is set to 1. This mainly ac-cumulates tokens on the rate-transition actor andoutputs the most freshest token of the faster actor.Furthermore, in this case a number of delay tokensequal to:

d.delay = (bdst.sp/bsrc.sp)− 1, (3)

are placed on the input channel d ∈ D) of the rate-transition actor in order to enable considering theinitial token produced by the fast actors at the firstfiring (see Fig. 7 and Fig. 8).

(e) Adding event channels: if the subsystem is a trig-

gered one then, depending on the hierarchy level cho-sen, extra connections are added in this step for han-dling (enabling/triggering) events. These edges areneeded when the hierarchy of a enabled/triggeredsubsystem is dissolved. In this case, each block, be-longing to the triggered or enabled subsystem has tobe sensitive to the (triggering/enabling) event andthus is connected with the event source.

Finally, the actors in the resulting SDF graph can be stati-cally scheduled to obtain a minimal periodic static schedule(Constant Constant1 Product )2 (RateTransition UnitDe-

lay Chart Out1 Out2).

4.3 Code-generation and SIL SimulationAfter describing the translation procedure of Simulink mod-els into SDFGs, we will describe in the following the cor-responding implementation on top of Simulink and how toutilize Simulink code-generator to enable SDF code gener-ation and SIL verification. Generating an equivalent SDF-compatible C code is useful to verify the functional equiv-alence between Simulink models and the generated SDFGson one side, and to enable the direct code deployment on

target hardware platforms, on the other side.

Fig. 9 shows the different steps involved in the model trans-formation process within our code-generation framework.The code generator constitutes the major part of our modeltransformation, taking the Simulink model as an input andgenerating the SDF code and the verification (SIL) modelas output. We implemented the code generator as a Mat-lab script taking use of the Matlab API to manipulate andextract needed information from Simulink models. The im-plemented code generator constitutes mainly of the followingfunctions:

• Check Requirements: the Simulink model is checked ifit fulfills the constraints described Sect.4.1. For e.g.in case of multirates, the rates are checked whether ornot these are integers and divisible.

• Clean Model: in this step, the chosen subsystem (tobe translated) is restructured according to the pre-translation phase (see Sect. 4.2): hierarchies dissolved,routing blocks dissolved and rate-transition blocks in-serted. In addition, every block of the desirable hier-archy is packaged in a subsystem and the connectionsare updated since the code-generation is only possiblefor subsystems.

• Generate SDF Code: this function uses the SimulinkEmbedded Coder and an SDF API to generate SDF-based embedded C code from the modified model of theprevious step (see example at the right of Fig. 9). Inthis case, embedded C code is first generated for eachblock at the the chosen hierarchy level. The SDF-based C code is generated by using the predefinedSDF library files (SDFLib.h, SDFLib.c implementedaccording to description in [23]) that have been al-ready loaded into the folder structure. The outputare two files (sdfg_<Name>.h, sdfg_<Name>.c) for ev-ery SDFG, in which the actors and channels are de-fined and instantiated according to the translation con-cept. For each actor a corresponding function is gen-erated (E.g. Product_actor() see Fig. 9), in whichdata availability of every input channel is checked (im-plemented as FIFO queue) and, if all inputs are read(E.g. dequeue(q1, P_U.In1)), the actor executes itsinternal computation behavior (implemented in a stepfunction for e.g. Product_step()) and the results arewritten into its output channels (E.g. enqueue(q3,

P_Y.Out1)). In addition, a basic valid static sched-ule is generated and implemented for the SDFG (seesdfg_step() in Fig. 9).

• Generate Verification model: the latest step targetsthe realization of a SIL simulation (see bottom-rightof Fig. 9). For this, we further enhance the codegenerator to allow the automatic integration of thegenerated SDF-compatible code into a C file of an S-function block. The S-function block is then automat-ically generated and inserted into a new-created verifi-cation model. The verification model includes also theoriginal subsystem (controller) with the environmentmodel. The S-function has the same interfaces as theoriginal subsystem which allows a seamless SIL sim-ulation with the environment model. Doing this, the

functional equivalence of the translated model and theoriginal one, can be verified automatically.

5. EVALUATIONWe have conducted two experiments to demonstrate the vi-ability of our approach being able of translating a Transmis-sion Controller Unit (TCU) model (c.f. [16]) and a ClimateController model (c.f. [17]) each to a corresponding SDFGand to generate for each case an equivalent SDF C code.

The TCU model depicted in Fig. 10 is a typical model ex-hibiting multirates. The translation for the TCU subsystem(seen at the bottom of Fig. 10) was straightforward since themodel respected (per construction) the constraints made inSect. 4.2. Fig. 11 shows that the outputs (impeller torque,output torque) of both the reference TCU and the generatedSDF-compatible TCU code are equivalent.

More complexity is exhibited by the Automatic ClimateControl System (seen in Fig. 12), where the Heater con-troller subsystem was translated. In addition to the varietyof blocks used, the Heater subsystem is a triggered subsys-tem which only executes when the enable signal is true. Asseen in the generated SDFG (see Fig. 12), the Enable actoris connected via extra-created channels to all actors withinthe Heater Control SDFG. Only if a true value arrives atthese dedicated channels, then the corresponding actor willbe activated to perform its internal computation. If this isnot the case, the actor will read its input queues, skip thecomputation part (step function) and update output queueswith values of the previous step results. Also the SIL andMIL results of this experiment show equivalent values as de-picted in Fig. 13 concluding a functionally equivalent SDFcode-generation.

6. CONCLUSIONIn this work, a translation approach for Simulink models (re-specting defined rules) to SDFGs was presented. Thanks tothe automated code-generation of SDF code from the orig-inal Simulink model and the Software-in-the-loop simula-tion, tests can be automated to show the functional equiva-lence of this translation. The translation was demonstratedsuccessfully with a medium-sized Transmission ControllerUnit model from the automotive domain and with a ClimateController use-case. In future work, we will take a look atthe possibility of optimizing the code-generation of Simulinkmodels for MPSoCs. For this, we can take use of the gener-ated SDF code and mature optimizing/parallelization tech-niques from the SDF research domain [1, 2] to enable effi-cient implementations of embedded systems.

7. ACKNOWLEDGMENTSThis work has been partially supported by the SAFE-POWER project with funding from the European Union’sHorizon 2020 research and innovation programme undergrant agreement No 646531.

0.01

0.04

SDF- based Code

Generation

Compiled SDF-based C-code S-function

Figure 10: SDF code-generation of the transmission controller model [16] (with slow-to-fast transitions)

(a) Model-In-the-Loop Simulation Results (b) Software-In-the-Loop Simulation Results

Figure 11: Verification results of the Transmission control model showing equivalent outputs of the SIL (see Fig. 11b) andthe MIL (see Fig. 11a) simulations.

References[1] S. Bhattacharyya, P. Murthy, and E. Lee. APGAN and

RPMC: Complementary heuristics for translating DSPblock diagrams into efficient software implementations.Design Automation for Embedded Systems, 2(1):33–60,1997.

[2] S. Bhattacharyya, P. Murthy, and E. Lee. Synthe-sis of embedded software from synchronous dataflow

specifications. The Journal of VLSI Signal Processing,21(2):151–166, 1999.

[3] P. Bostorm and J. Wiik. Contract-based verification ofdiscrete-time multi-rate Simulink models. Software &Systems Modeling, pages 1–21, June 2015.

[4] M. Buker. An Automated Semantic-Based Approachfor Creating Task Structures. Dissertation, Universityof Oldenburg, 2013.

Automatic Climate Control System

SDF- based Code

Generation

Compiled SDF-based C-code S-function

Figure 12: SDF code-generation of the single-rate triggered Climate controller model [17]

(a) Model-In-the-Loop Simulation Results (b) Software-In-the-Loop Simulation Results

Figure 13: Verification results of the Heat control model showing equivalent outputs of the SIL (see Fig. 13b) and the MIL(see Fig. 13a) simulations.

[5] P. Caspi, A. Curic, A. Maignan, C. Sofronis, S. Tripakis,and P. Niebert. From Simulink to SCADE/Lustre toTTA: a layered approach for distributed embedded ap-plications. In ACM Sigplan Notices, volume 38, pages153–162, 2003.

[6] C. Dominik. Conception and Implementation of Par-allelism Analyses in MATLAB/SIMULINK Models forprogramming Embedded Multicore-Systems. Bsc. the-sis, TU Munchen, 2011.

[7] M. Fakih, K. Gruttner, M. Franzle, and A. Rettberg.State-based real-time analysis of SDF applications onMPSoCs with shared communication resources. Jour-nal of Systems Architecture - Embedded Systems De-sign, 61(9):486–509, 2015.

[8] D. D. Gajski, S. Abdi, A. Gerstlauer, and G. Schirner.Embedded System Design: Modeling, Synthesis andVerification. Springer Science & Business Media, aug2009.

[9] E. C. Klikpo, J. Khatib, and A. M. Kordon. Mod-eling multi-periodic simulink systems by synchronousdataflow graphs. In 2016 IEEE Real-Time and Embed-ded Technology and Applications Symposium (RTAS),Vienna, Austria, April 11-14, 2016, pages 209–218,2016.

[10] E. Lee and D. Messerschmitt. Synchronous data flow.Proceedings of the IEEE, 75(9):1235–1245, 1987.

[11] E. A. Lee. Heterogeneous actor modeling. In Pro-ceedings of the Ninth ACM International Conferenceon Embedded Software, EMSOFT ’11, pages 3–12, NewYork, NY, USA, 2011. ACM.

[12] E. A. Lee and D. G. Messerschmitt. Static scheduling ofsynchronous data flow programs for digital signal pro-cessing. IEEE Trans. Computers, 36(1):24–35, 1987.

[13] G. Li, R. Zhou, R. Li, W. He, G. Lv, and T. J. Koo. ACase Study on SDF-Based Code Generation for ECUSoftware Development. In Proceedings of the 2011 IEEE35th Annual Computer Software and Applications Con-ference Workshops, COMPSACW’11, pages 211–217,2011.

[14] S. Li. Simulink2sdf - converter. https://github.com/zcold/Simulink2SDF, 2013. (GitHub, open-sourceCode, last accessed on 01.09.2016).

[15] R. Lublinerman and S. Tripakis. Translating data flowto synchronous block diagrams. In P. Eles and A. D.Pimentel, editors, ESTImedia, pages 101–106. IEEE,2008.

[16] MathWorks. Modeling an automatictransmission controller. https://de.mathworks.com/help/simulink/examples/modeling-an-automatic-transmission-controller.html.(last accessed on 01.09.2016).

[17] MathWorks. Simulating automatic cli-mate control systems. https://de.mathworks.com/help/simulink/examples/simulating-automatic-climate-control-systems.html.(last accessed on 01.09.2016).

[18] MathWorks. Simulink - simulation and model-baseddesign. http://de.mathworks.com/products/simulink/blocklist.html. (last accessed on 01.09.2016).

[19] MathWorks, Inc. Automatic Code Generation -

Simulink Coder. http://www.mathworks.de/products/simulink-coder/, 2015. (last accessed on 01.11.2015).

[20] MathWorks, Inc. Modeling Guidelines for Code Gener-ation. Technical Report Version 1.10 (Release 2015b),2015.

[21] MathWorks, Inc. Stateflow official website. http://www.mathworks.com/products/stateflow/, 2015. (lastaccessed on 01.09.2016).

[22] S. Miller, E. Anderson, L. Wagner, M. Whalen, andM. P. E. Heimdahl. Formal verification of flight crit-ical software. In Proceedings of the AIAA Guidance,Navigation and Control Conference and Exhibit, 2005.

[23] P. R. Schaumont. A Practical Introduction to Hard-ware/Software Codesign. Springer US, 2013.

[24] S. Warsitz and M. Fakih. Simulink-modell-ubersetzungin synchrone datenflussgraphen. In 19th GI/ITG/GMMWorkshop Methoden und Beschreibungssprachen zurModellierung und Verifikation von Schaltungen undSystemen, MBMV 2016, Freiburg im Breisgau, Ger-many, March 1-2, 2016., pages 89–101, 2016.

[25] L. Zhang, M. Glab, N. Ballmann, and J. Teich. Bridg-ing algorithm and ESL design: Matlab/Simulink modeltransformation and validation. In Specification & De-sign Languages (FDL), 2013 Forum on, pages 1–8,2013.