Automatic SDF-based Code Generation from Simulink Models for Embedded Software Development

2.6 MB·

by  Maher Fakih

Automatic SDF-based Code Generation from Simulink
Models for Embedded Software Development
Maher Fakih Sebastian Warsitz
OFFISInstituteforInformationTechnology CarlvonOssietzkyUniversitÃd’tOldenburg
Oldenburg,Germany Oldenburg,Germany
maher.fakih@offis.de [email protected]
7
1 ABSTRACT the help of mathematical models create executable specifi-
0
Matlab/Simulink is a wide-spread tool for model-based de- cations using a certain modeling framework. These frame-
2
sign of embedded systems. Supporting hierarchy, domain works typically provide automatic code generators which

n specificbuildingblocks,functionalsimulationandautomatic generateconsistentimperativecodereadytobedeployedin
a code-generation, makes it well-suited for the design of con- real environments. Matlab/Simulink [18] is one of the most
J trol and signal processing systems. In this work, we pro- wide-spread tools for model-based design of embedded sys-

1 pose an automated translation methodology for a subset of tems which combines above features in a single framework.
3 SimulinkmodelstoSynchronousdataflowGraphs(SDFGs) Simulink utilizes block-diagram to represent system models
includingtheautomaticcode-generationofSDF-compatible at the algorithmic level. For instance, in case of a control

] embedded code. A translation of Simulink models to SD- system,themodelconsistsofthecontrolleralgorithmblock
C
FGs, is very suitable due to Simulink actor-oriented mod- which controls the environment block (or the process to be
D eling nature, allowing the application of several optimiza- controlledtypicallymodeledasasetdifferentialequations).
s. tion techniques from the SDFG domain. Because of their A translation of Simulink models to Synchronous Dataflow
c well-definedsemantics,SDFGscanbeanalyzedatcompiling Graphs (SDFGs) [12] which are, opposed to Simulink, for-
[ phase to obtain deadlock-free and memory-efficient sched- mally based, is beneficial. Such a translation would pave
ules. In addition, several real-time analysis methods ex- thewaytowardstheapplicationofseveraloptimizationand
2 ist which allow throughput-optimal mappings of SDFGs to formalverificationtechniqueswell-establishedfortheSDFG
v
MultiprocessoronChip(MPSoC)whileguaranteeingupper- domain. Fore.g. inarecentworkin[7]theformalreal-time
7
boundedlatencies. Thecorrectnessofourtranslationisjus- verification (based on model-checking) of SDF applications
1
2 tified by integrating the SDF generated code as a software- running on Multiple-Processor-System-On-Chip (MPSoCs)
4 in-the-loop (SIL) and comparing its results with the re- withsharedcommunicationresourceswasshowntobemore
0 sultsofthemodel-in-the-loop(MIL)simulationofreference viable than the real-time (RT) verification of generic tasks.
. Simulink models. The translation is demonstrated with the Also for SDFGs deadlocks and bounded buffer properties
1 help of two case studies: a Transmission Controller Unit are decidable [12]. In addition with the help of mathemati-
0 (TCU) and an Automatic Climate Control. cal methods easy-to-analyze compile-time schedules can be
7
constructedforSDFGs. Furthermore,memory-efficientcode
1
optimizationareavailable[1,2]toenableefficientimplemen-
: CCSConcepts
v tations of embedded systems.
i •Computer systems organization → System on a
X Inthispaper,wepresentatranslationprocedureofadefined
chip; Embedded hardware;
subset of Simulink models to SDFGs based on the work in
r
a [24]. Weextendtheapproachin[24]byenablingthetransla-
1. INTRODUCTION tionofSimulinkmodelswithmultiratesfeaturestoSDFGs.
In addition, we integrate the translation procedure within
Model-based Design (MBD) of embedded systems is nowa-
Matlab/Simulinkandutilizetheautomaticcode-generation
days a standard, easy and efficient way for capturing and
feature to generate SDF-based code from Simulink models.
verifying embedded software functional requirements. The
Moreover, we enable an automatic setup of a verification
main idea is to move away from manual coding, and with
flow which allows a Software-In-the-Loop (SIL) simulation
showingthefunctionalequivalenceofthegeneratedcodeto
Permissiontomakedigitalorhardcopiesofallorpartofthisworkfor the reference model.
personalorclassroomuseisgrantedwithoutfeeprovidedthatcopies
The paper is structured as follows. We will first recap the
arenotmadeordistributedforprofitorcommercialadvantageandthat
copiesbearthisnoticeandthefullcitationonthefirstpage. Tocopy basicconceptsofsynchronousdataflowgraphsandSimulink
otherwise, or republish, to post on servers or to redistribute to lists, models identifying their main differences. Afterwards, we
requirespriorspecificpermissionand/orafee. discusstherelatedworkinSect.3mainlyaddressingtrans-
HIP3ES’2017,January25,2017,Stockholm,Sweden lation approaches of Simulink models to SDFGs. Next we
Copyright2017ACM978-1-4503-4486-9/17/04...$15.00 elaborate on our translation procedure in Sect. 4, starting
http://dx.doi.org/xx.xxxx/xxxxxxx.xxxxxxx
Rate Delay JPEG Encoder
Actor Channel
Simulink is a framework for modeling of dynamic systems
and simulating them in virtual time. Modeling of such sys-
768 128 64 64 64 64 tems is carried out graphically through a graphical editor
get_MB 2D CC DCT VLC consisting mainly of blocks and arrows (connections) be-
tween them representing signals. Each block has its input,
output and optionally state variables. The relationship of
Figure 1: SDFG of a JPEG Encoder the inputs with the old state variables and the outputs up-
dateisrealizedthroughmathematicalfunctions. Oneofthe
powerfulfeaturesofSimulinkistheabilitytocombinemul-
with description of the set of constraints on the Simulink tiple simulation domains (continuous and discrete). This is
model enabling the translation. In addition, we discuss veryusefulforembeddedsystems,whereingeneralthecon-
the code-generation and SIL verification features. Sect. 5 troller has discrete model and the environment often needs
demonstrate the viability of our translation approach with to be modeled as a continuous one.
the help of a Transmission Controller Unit (TCU) case
Simulinkalsosupportsastate-basedMoCtheStateflow [21]
study. Finally, we conclude our work and give an outlook
whichiswidelyusedtomodeldiscretecontrollers. Simulink
on open issues and future work.
allows a fast Model-in-the-Loop (MIL) verification, where
thefunctionalmodel(ofthecontrollerforexample)issimu-
lated and results are documented to be compared with fur-
2. BACKGROUND
ther refinements. In addition, a Software-in-the-Loop (SIL)
verification is also possible in which the controller model is
2.1 SynchronousDataflowGraphs
replaced by the generated code from the Embedded Coder
A synchronous (or static) data-flow graph (SDFG) [12] is [19](usuallyembeddedinaS-function)andthebehaviorof
a directed graph (see Fig.1) which, similar to general data- thecodeiscomparedwiththereferencedataachievedfrom
flowgraphs(DFGs),consistsmainlyofnodes(calledactors) MIL (described above).
modelingatomicfunctions/computationsandarcsmodeling
In [15] a method was presented to automatically transform
the data flow (called channels). In difference to DFGs, SD-
SDFGsintoSBDs(SynchronousBlockDiagrams),suchthat
FGsconsume/produceastaticnumberofdatasamples(to-
thesemanticsofSDFarepreserved, anditwasproventhat
kens) each time an actor executes (fires). An SDFG suits
Simulink can be used to capture and simulate SDF models.
wellformodelingmulti-ratestreamingapplicationsandDSP
Alsoauthorsin[8]supportthisfactthatdataflowmodelsfit
algorithms and also allows static scheduling and easy par-
welltoconceptsofblockdiagramsandareusedbySimulink.
allelization. A port rate denotes the number of tokens pro-
In general, the MoC of Simulink is much more expressive
duced or consumed in every activation of an actor. The
thanthatoftheSDFhavingtheadvantageofbeingableto
dataflowacrossachannel(whichrepresentsaFIFObuffer)
relax all limitations of the SDF MoC but at the cost of its
is done according to a First-In-First-Out (FIFO) fashion.
analyzability.
Channels could also store initial tokens (called delays indi-
catedbybulletsintheedges)intheirinitialstatewhichhelp
resolving cyclic dependencies (see [12]).
3. RELATEDWORK
Despite the analyzability advantage of SDFGs, yet this
In the last decade, several research [4, 5, 22, 25] have been
comes at the cost of their expressiveness. One of the main
conducted to enable a translation of Simulink models to
limitationsofSDFModelofComputation(MoC)isthatdy-
other formal models for the purpose of formal analysis. In
namismcannotbehandledfore.g. inthecasewheredepend-
thefollowing,wemerelydiscusspreviousworkenablingthe
ing on the current scenario the application rates changes
translation of Simulink models to SDFGs.
(c.f. [23]). Anotherlimitation(c.f. [12])oftheSDFMoCis
thatconditionalcontrolflowisonlyallowedwithinanactor In [14], only the source code of a so-called Simulink2SDF
functionality but not among the actors. However, emulat- tool was published which enables a very simple translation
ing control flow within the SDFG is possible even though of Simulink models to SDFGs. In this work all Simulink
notalwaysefficient(c.f. [23]). Duetoabovelimitations,for blocks,withoutanydistinction,weretranslatedtodata-flow
e.g. stopping and restarting an SDFG is not possible since actorsandsimilarlyconnectionsweretranslatedindata-flow
an SDFG can have only two states either running or wait- channels, the fact which makes the translation incomplete
ing for input. In addition, reconfiguration of an SDFG to aswewillseeinSec.4. Inaddition,ourapproachallowsthe
beableto(de)activatedifferentpartsdependingonspecific generation of executable SDF-code which is not possible in
modes is not possible. Moreover, different rates depending this approach.
on run-time conditions are not supported. Also modeling
In[6]atranslationofSimulinkmodelstohomogeneousSD-
exceptions which might require deactivating some parts of
FGs(HSDFGs)waspursuedwiththeobjectiveofanalyzing
the graph is not possible. An additional issue is that the
concurrency. HSDFGs are SDFGs with the restriction that
SDFmodeldoesnotreflectthereal-timenatureofthecon-
thenumberofconsumedandproducedtokensofeachactor
nections to the real-time environment.
mustbeequalto1[10]. Thetranslationhasbeendonefora
fixednumberoffunctionalblocksbutimportantattributes,
2.2 Simulink such as the data type of a connection between blocks, have
not been taken into consideration by the the translation. 1. Dataflow without connections (e.g. Goto/From
blocks): In contrast to Simulink, there is no dataflow
In [13] it was shown how a case study of a vehicle climate
without a channel connection in connected and consis-
controlmodeledinSimulinkisimportedtoatool(MoDAL)
tent1 SDFGs considered in this paper.
supporting SDF MoC. MoDAL, in turn, exports the model
in a format which can be imported by the Ptolemy tool 2. Grouping of connections (e.g. BusCreator block for
[11]. Ptolemy is then used to generate code from the SDF bus signals): In Simulink, connections with different
model. In[13],onlytheuse-casemodelhavebeentranslated properties (e.g. different data types) can be grouped
to an SDFG without general defining a translation concept into one connection. This is not possible in an SDFG
applicable at least to a subset of Simulink models. since the tokens transfered among a channel must have
the same properties.
In [3] a translation from Simulink models to SDFGs was
described. The aim of this work was to apply a method- 3. Connection style: While in Simulink the storage of
ology for functional verification of Simulink models based databetweenblockshasthesamebehavior asthatofa
on Contracts. Contracts define pre- and post conditions to registerwheredatacanbeoverwritten(incaseofmulti-
be fulfilled for programs or program fragments. In [9], the rate models), the inter-actor communication via chan-
ability of SDFGs to model multi-periodic Simulink systems nelsinSDFGsfollowsa(data-flow)FIFObufferfashion,
was formally proved. There, in addition to systems with where tokens must be first consumed before being able
harmonicperiods,alsonon-harmonicperiodsaresupported to buffer new ones.
(unlike our work and that of [3] where only harmonic peri-
U4 Sampling rates: In addition to the number of data
odsaresupported). However,authorsinabovework,giveno
transported over a connection by every block activation, a
clearclassificationofcriticalSimulinkfunctionalblocks(e.g.
periodicsamplingrateisassignedtoeachblockinSimulink
the switch block with dynamic rates see Sec. 4) which can-
tomarkitsperiodicactivationatthisspecificfrequency. If
notbesupportedinthetranslation. Inaddition,Triggered-
all blocks exhibit the same sampling periods in a model,
/Enabled subsystems and other important attributes such
then this model is called a single-rate model otherwise it
as the data type of a connection are not supported. Fur-
is a multi-rate model. In SDFGs, however, an actor is
thermore, SDF-based code-generation was not considered.
only activated based on the availability of inputs. Actors
Unliketheabovework,wepresentageneraltranslationcon- do not have explicit sampling periods and therefore data
cept based on a classification of blocks and connections in ratescanonlyberepresentedbytheratesassignedtotheir
Simulink models. Our approach enables the translation of (input/output) ports.
critical blocks (such as Enabled/Triggered subsystems) in-
cluding the enrichment of the translated SDFG with im- Because of the above differences, some constraints must be
portant attributes such as the data types of tokens, tokens’ imposed on the Simulink input model in order to enable its
sizeandsamplingratesofactors(incaseofmulti-ratemod- translationtoanequivalentSDFG,whichwewilldiscussin
els). This enables a seamless code generation of the model the following section.
intoSDF-basedembeddedsoftwarereadytobedeployedon
target architecture. We also provide an automation of the 4.1 ConstraintsontheSimulinkModel
processofSDF-basedcodegenerationtogetherwiththeSIL
verification to prove the soundness of the translation. Only Simulink models with fixed-step solver are supported
in the translation. In case of multi-rates, rate transi-
tions should be inserted to the Simulink model and the
4. SIMULINKTOSDFGTRANSLATION rates should be harmonic (divisible). These constraints
are indispensable to enable deterministic code generation
Asalreadystated(seeSec.2.2),SimulinkMoCismuchmore
[3,20],sinceweaimwiththehelpofSimulinkbuilt-incode-
expressive than the SDFG MoC. Unlike SDFGs, Simulink
generator to generate SDF-compatible executable code for
supports following additional features:
the translated SDF application. Even though it is possi-
ble to translate a Simulink model to multiple SDFGs, we
U1 Hierarchy (e.g. subsystem blocks): WhileinSimulink deal only with one application (implemented in Simulink)
multiplefunctionalblockscanbegroupedintoasubsystem, at a time in this paper, which results after translation into
in SDFGs each actor is atomic and therefore no hierarchy one equivalent SDFG. This application is considered to be
is supported. a control application having the general structure depicted
in Fig. 9. Moreover, a correct functional simulation of the
U2 Control-flow logic/Conditional (for e.g. switch Simulinkmodelisaprerequisiteforthetranslationinorder
block or triggered subsystem see [18]): In Simulink con- to get an executable SDFG. In addition to above general
trol flow is supported on the block level. This means that prerequisites, the following constraints are imposed on the
depending on the value of a control signal at a block, dif- input Simulink model to enable the translation:
ferentdataratescouldbeoutputbytheblock. Incontrary,
inSDFGsdataratesatinputandoutputportsofanactor
E1 Hierarchy: Hierarchical blocks (e.g. subsystems), in
arefixedandcontrolstructuresareonlyallowedwithinthe
whichoneormorefunctionalblocksofthetypesdescribed
functional code of an actor and can’t be represented in an
inU3-1 andU3-2 exist,arenotallowedtobetranslatedto
SDFG.
1Inconsistent SDFGs require unlimited storage or lead to
U3 Connections: deadlocks during execution[10].
atomicactors. Eithertheseblocksshouldberemovedfrom
theentrySimulinkmodel(fortheyserveonlyvisualization
improvementpurpose)orthemodelshouldbedissolvedat
the hierarchy level at which these components exist where
these blocks are translated and connected in accordance
with 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 blocks
of the form U3-1 and U3-2, which may be connected with
functionalblocksindifferenthierarchicallevels,woulddis-
Figure 2: Original Simulink model: Red having a sample
appear in the target SDFG. A translation of these blocks
time of 2, Green having a sample time 4
would 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 as 4.2 TranslationProcedure
Triggered/Enabled subsystems can be translated just like
Inthefollowing,wewillroughlydescribethetranslationpro-
the general subsystems. Upon dissolving the hierarchy of
cedure implemented to extract an SDFG from a Simulink
such subsystems, the control flow takes place now within
model with the help of an academical Simulink multirate
theatomicfunctionalityoftheactorwithoutbeingincon-
example in Fig. 2. For the translation two main phases
tradiction to SDFG semantics (c.f. Sec. 2.1). In such a
are required: the pre-translation phase where the original
translation, however, additional control channels must be
Simulink model is prepared and checked for the above de-
defined (see Sec. 4.2). Yet, the case described in U2 must
finedconstraintsandthetranslation phasewherethetrans-
still be prohibited. In order to do that, there is an option
lation takes place.
“allowing different data input sizes”in Simulink for such
blocks, which when disabled, prohibits outputs of variable
sizes of a control block2. A special case of these blocks 1. Pre-Translation phase:
is the powerful stateflow supported by Simulink. In our
translation we do not flatten the stateflow block and we (a) Checking Requirements: Here the Simulink
always translate it into one atomic actor. modelischeckedifitfulfillstheconstraintsdescribed
above. If this is not the case the translation is
E3 Connections abortedwithanoutputofthelistofunfulfilledcon-
straints.
1. Dataflow without connections: For blocks hav-
ing the same behavior described in U3-1 (such as
From/GotoorDataStoreRead,/DataStoreWriteblocks),
we assume that the source block (e.g. DataStoreWrite
block), intermediate block (e.g. DataStoreMemory
block)andthetargetblock(e.g. DataStoreReadblock)
whichcommunicatewithoutconnectionsareavailablein
theinputSimulinkmodel. Thisconstraintisimportant
asSimulinkallowsinstantiatingasourceblockswithout
for instantiating for e.g. the sink block.
2. Grouping of connections: In order to support the
translation of Simulink models with blocks having the
same behavior as those described in U3-23, two con-
Figure 3: Dissolving hierarchy to the desired level
straints must be imposed. The first one is that every
block which groups multiple signals (e.g. BusCreator)
into one signal must be directly connected to a block
(b) Dissolving hierarchy: In this step, a top-down
which have the opposite functionality (e.g. BusSelec-
flattening of the Simulink model (respecting E1),
tor). The second constraint is imposed on the block
till the required depth level is reached, is done (see
(e.g. BusSelector) which takes the grouped signals and
Fig. 3).
splitsthemagain. An“Outputasbus”shouldbeprohib-
itedintheoptionsofthisblock. Bydoingthis,grouping (c) Removing connecting blocks of type U3-
of signals for better visibility in the Simulink model is 1/U3-2: Here, blocks respecting the E3-1/E3-2
stillwiththelimitationaboveallowed,whileprohibiting constraint are removed. When doing this, the pre-
groupingofsignalsofdifferentparametersinonesignal decessor block of the source block (e.g. DataS-
in the target translation. toreWrite block) is directly connected either to the
intermediate (if existent) block (e.g. DataMem-
ory block) or to the successor block of the target
2According to [18] blocks having this option are: Action-
block (e.g. DataStoreRead block) and these con-
Port, Stateflow, Enable/Trigger Subsysteme, Switch, Multi-
port Switch and Manual Switch. necting blocks (source and target blocks) are re-
3e.g. BusCreator/BusSelector, Bus Assignment and Merge moved (see Fig. 4 where BusCreator/BusSelector
blocks [18]. and Goto/From blocks are removed).
a) b1 b2
sample λ sample λ/n
1 1 n 1
b) a1 R a2
Figure 6: Example of a Simulink slow-to-fast multirate
model shown in (a). By adding a rate-transition actor R, a
valid translation to SDFG can be achieved in (b).
Figure 4: Removing connecting blocks of type U3-1/U3-2
a)
b1 b2
(d) Inserting rate-transition blocks: Here rate- sample λ/n sample λ
transition block are inserted between blocks con-
nected to each other and having different sample
rates (see Fig. 5).
1 n 1 1
b)
a1 R a2
(n-1)D
Figure 7: Example of a Simulink fast-to-slow multirate
model (a) and its equivalent SDFG in (b).
(c) Extraction of Tokens’ sizes and types: The
numberofthedatatransferedoveraconnectionrep-
resentsthesizeofatokenproduced/consumedwhen
anactorfires(e.g. Constantactorproducesatoken
of size 2 in Fig. 8) and their data type represents
the data type of that token (e.g. double in Fig. 8).
These parameters can be extracted from the model
Figure 5: Inserting rate-transition blocks between blocks of
for every connection.
different sample rates
(d) Handling Multi-rates: The following method for
handling multirates was inspired from [3, 25]. To
2. Translation phase: Inthisstep,themodifiedSimulink determine the rates of the actors’ input and out-
model is directly translated into an SDFG (see Fig. 8) putportswemustdifferentiatebetweenthreecases:
according to the following procedure: fast-to-slow transition, slow-to-fast transitions and
transitions between blocks having the same rates.
(a) Translation of blocks: IfB isthesetofallblocks
For the latter case, source and destination actors
in Simulink model M then each block b ∈ B in
l are denoted by a rate of 1 on their ports indicating
M is translated into an unique actor in the trans-
the production/consumption of one token (of spe-
latedSDFGa ∈A(whereAisthesetofactorssee
l cific size per channel) whenever activated. In case
Fig. 8).
of slow-to-fast transition (see e.g. in Fig. 6 and in
(b) Translation of connections: Each output port Fig. 10), the rate of the output port of the rate-
bl.oistranslatedintoauniqueoutputportal.poand transition actor
eachinputportb.iistranslatedintoauniqueinput
l
portal.pi. Incasemultipleconnectionst1,t2,··· ,tn R.po.rate=bsrc.sp/bdst.sp, (1)
going out from an output port po1 in Simulink wherepo istheoutputportoftheactorR,bsrc and
(which is permitted in Simulink but not in the b arethesourceanddestinationblocksconnected
dst
SDFG, see connections of statechart before Fig. 2 via rate-transition block and sp the sample time of
and after translation Fig. 8), then for each one thecorrespondingblock. Therateoftheinputport
of these connections, the output port is replicated of R is set to 1. This basically realizes multiple
po11,po12,··· ,po1m (each having the same proper- copies of tokens of the slower actor for the faster
ties) in the resulting SDFG, in order to guarantee actor to run.
that every channel d ∈ D (set of all channels in an
In case of fast-to-slow transition, the rate R.p .rate
SDFG) has unique input and output ports. Now, i
of the input port (p ) of the rate-transition actor R
each connection t ∈ M in the Simulink model is i
can be calculated as follows:
translated into a channel d ∈ D in the SDFG (see
Fig. 8). R.p .rate=b .sp/b .sp, (2)
i dst src
Matlab/Simulink Code SDF based C-code
Generator
Model B3 Sdfg_B3.h
Sdfg_B3.c
Environment Check In1 In2
Requirements q ueue q1,q2,q3,q4;
sdfg_initialize(){
Clean 1 1 initQueue(q1,1,1,1,0);
q1 1 1 q2 …
Simulink Model }
stupni Controller stuptuo SDF Gbaesneedr aCt-ec ode q3 11 Product s dfIIPAOgnnrbu_12osts__d_1taaua_eccccapttttc(oo_otrraro)(((cr{ ))t();;o); r;( );
Abs }
Generate Product_actor(){
B2 B3 q4 1 dequeue(q1, P_U.In1);
B1 Verification Model 1 dequeue(q2, P_U.In2);
Product_step();
Out1 enqueue(q3, P_Y.Out1);
}
…
Verification model (SIL)
=
Controller
Environment
B2 B3 inputs inputs
B1 SDF based C-code
outputs outputs
S-function builder
?
Figure 9: Structure of the model transformation and code-generation framework. Simulink Model: consisting mainly of
a 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
ofthecontrollerSimulinkmodel. SDF based C-code: executablecodeofthegeneratedSDFG.Verification model: consistsof
the reference controller and environment models with an extra S-function builder block in which the generated SDF code is
embedded and connected to the environment allowing SIL verification.
1 Double 1 geredonethen,dependingonthehierarchylevelcho-
Chart Out1
1 sen,extraconnectionsareaddedinthisstepforhan-
1
Constant 1 1 Out2 dling (enabling/triggering) events. These edges are
needed when the hierarchy of a enabled/triggered
1 Double 1 subsystem is dissolved. In this case, each block, be-
Constant1 1 Single 1 Product1 1 1D 2 TraRnastitei on D1o uble 1 DUenlaity longingtothetriggeredorenabledsubsystemhasto
be sensitive to the (triggering/enabling) event and
Figure8: TranslatingmodifiedSimulinkmodelwithfast-to- thus is connected with the event source.
slow transitions into SDF
Finally, the actors in the resulting SDF graph can be stati-
callyscheduledtoobtainaminimalperiodicstaticschedule
The output port rate is set to 1. This mainly ac- (ConstantConstant1Product)2 (RateTransitionUnitDe-
cumulates tokens on the rate-transition actor and lay Chart Out1 Out2).
outputs the most freshest token of the faster actor.
Furthermore, in this case a number of delay tokens
4.3 Code-generationandSILSimulation
equal to:
AfterdescribingthetranslationprocedureofSimulinkmod-
d.delay=(bdst.sp/bsrc.sp)−1, (3) els into SDFGs, we will describe in the following the cor-
responding implementation on top of Simulink and how to
are placed on the input channel d∈D) of the rate-
utilize Simulink code-generator to enable SDF code gener-
transition actor in order to enable considering the
ation and SIL verification. Generating an equivalent SDF-
initial token produced by the fast actors at the first
compatible C code is useful to verify the functional equiv-
firing (see Fig. 7 and Fig. 8).
alence between Simulink models and the generated SDFGs
(e) Addingeventchannels: ifthesubsystemisatrig- on one side, and to enable the direct code deployment on
target hardware platforms, on the other side. functionalequivalenceofthetranslatedmodelandthe
original one, can be verified automatically.
Fig.9showsthedifferentstepsinvolvedinthemodeltrans-
formation process within our code-generation framework.
Thecodegeneratorconstitutesthemajorpartofourmodel 5. EVALUATION
transformation, taking the Simulink model as an input and
Wehaveconductedtwoexperimentstodemonstratethevi-
generating the SDF code and the verification (SIL) model
abilityofourapproachbeingableoftranslatingaTransmis-
as output. We implemented the code generator as a Mat-
sionController Unit (TCU)model(c.f. [16]) andaClimate
lab script taking use of the Matlab API to manipulate and
Controller model (c.f. [17]) each to a corresponding SDFG
extract needed information from Simulink models. The im-
and to generate for each case an equivalent SDF C code.
plementedcodegeneratorconstitutesmainlyofthefollowing
functions: The TCU model depicted in Fig. 10 is a typical model ex-
hibitingmultirates. ThetranslationfortheTCUsubsystem
• Check Requirements: theSimulinkmodelischeckedif (seenatthebottomofFig.10)wasstraightforwardsincethe
it fulfills the constraints described Sect.4.1. For e.g. model respected (per construction) the constraints made in
incaseofmultirates,theratesarecheckedwhetheror Sect. 4.2. Fig. 11 shows that the outputs (impeller torque,
not these are integers and divisible. outputtorque)ofboththereferenceTCUandthegenerated
SDF-compatible TCU code are equivalent.
• Clean Model: in this step, the chosen subsystem (to
be translated) is restructured according to the pre- More complexity is exhibited by the Automatic Climate
translationphase(seeSect.4.2): hierarchiesdissolved, Control System (seen in Fig. 12), where the Heater con-
routing blocks dissolved and rate-transition blocks in- troller subsystemwastranslated. Inadditiontothevariety
serted. In addition, every block of the desirable hier- of blocks used, the Heater subsystem is a triggered subsys-
archy is packaged in a subsystem and the connections tem which only executes when the enable signal is true. As
are updated since the code-generation is only possible seeninthegeneratedSDFG(seeFig.12),theEnableactor
for subsystems. is connected via extra-created channels to all actors within
the Heater Control SDFG. Only if a true value arrives at
• Generate SDF Code: this function uses the Simulink
these dedicated channels, then the corresponding actor will
Embedded Coder and an SDF API to generate SDF-
be activated to perform its internal computation. If this is
basedembeddedCcodefromthemodifiedmodelofthe
not the case, the actor will read its input queues, skip the
previous step (see example at the right of Fig. 9). In
computationpart(stepfunction)andupdateoutputqueues
this case, embedded C code is first generated for each
with values of the previous step results. Also the SIL and
block at the the chosen hierarchy level. The SDF-
MILresultsofthisexperimentshowequivalentvaluesasde-
based C code is generated by using the predefined
picted in Fig. 13 concluding a functionally equivalent SDF
SDF library files (SDFLib.h, SDFLib.c implemented
code-generation.
according to description in [23]) that have been al-
ready loaded into the folder structure. The output
aretwofiles(sdfg_<Name>.h, sdfg_<Name>.c)forev- 6. CONCLUSION
ery SDFG, in which the actors and channels are de-
Inthiswork,atranslationapproachforSimulinkmodels(re-
finedandinstantiatedaccordingtothetranslationcon-
spectingdefinedrules)toSDFGswaspresented. Thanksto
cept. For each actor a corresponding function is gen-
the automated code-generation of SDF code from the orig-
erated (E.g. Product_actor() see Fig. 9), in which
inal Simulink model and the Software-in-the-loop simula-
dataavailabilityofeveryinputchannelischecked(im-
tion,testscanbeautomatedtoshowthefunctionalequiva-
plemented as FIFO queue) and, if all inputs are read
lenceofthistranslation. Thetranslationwasdemonstrated
(E.g. dequeue(q1, P_U.In1)), the actor executes its
successfully with a medium-sized Transmission Controller
internalcomputationbehavior(implementedinastep
UnitmodelfromtheautomotivedomainandwithaClimate
function for e.g. Product_step()) and the results are
Controller use-case. In future work, we will take a look at
written into its output channels (E.g. enqueue(q3,
thepossibilityofoptimizingthecode-generationofSimulink
P_Y.Out1)). In addition, a basic valid static sched-
modelsforMPSoCs. Forthis,wecantakeuseofthegener-
ule is generated and implemented for the SDFG (see
ated SDF code and mature optimizing/parallelization tech-
sdfg_step() in Fig. 9).
niques from the SDF research domain [1, 2] to enable effi-
• Generate Verification model: the latest step targets cient implementations of embedded systems.
the realization of a SIL simulation (see bottom-right
of Fig. 9). For this, we further enhance the code
7. ACKNOWLEDGMENTS
generator to allow the automatic integration of the
generated SDF-compatible code into a C file of an S- This work has been partially supported by the SAFE-
function block. TheS-functionblockisthenautomat- POWER project with funding from the European Union’s
icallygeneratedandinsertedintoanew-createdverifi- Horizon 2020 research and innovation programme under
cationmodel. Theverificationmodelincludesalsothe grant agreement No 646531.
original subsystem (controller) with the environment
model. The S-function has the same interfaces as the
original subsystem which allows a seamless SIL sim-
ulation with the environment model. Doing this, the
Compiled SDF-based C-code S-function
SDF- based
0.01 Code
Generation
0.04
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) and
the MIL (see Fig. 11a) simulations.
References specifications. The Journal of VLSI Signal Processing,
21(2):151–166, 1999.
[1] S.Bhattacharyya,P.Murthy,andE.Lee. APGANand
RPMC:ComplementaryheuristicsfortranslatingDSP [3] P.Bost¨ormandJ.Wiik. Contract-basedverificationof
blockdiagramsintoefficientsoftwareimplementations. discrete-time multi-rate Simulink models. Software &
Design Automation for Embedded Systems, 2(1):33–60, Systems Modeling, pages 1–21, June 2015.
1997. [4] M. Bu¨ker. An Automated Semantic-Based Approach
[2] S. Bhattacharyya, P. Murthy, and E. Lee. Synthe- for Creating Task Structures. Dissertation, University
sis of embedded software from synchronous dataflow of Oldenburg, 2013.
Automatic Climate
Control System
Compiled SDF-based C-code S-function
SDF- based
Code
Generation
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, SimulinkCoder. http://www.mathworks.de/products/
and P. Niebert. From Simulink to SCADE/Lustre to simulink-coder/, 2015. (last accessed on 01.11.2015).
TTA:alayeredapproachfordistributedembeddedap- [20] MathWorks,Inc. ModelingGuidelinesforCodeGener-
plications. In ACM Sigplan Notices, volume 38, pages ation. Technical Report Version 1.10 (Release 2015b),
153–162, 2003. 2015.
[6] C. Dominik. Conception and Implementation of Par- [21] MathWorks, Inc. Stateflow official website. http://
allelism Analyses in MATLAB/SIMULINK Models for www.mathworks.com/products/stateflow/, 2015. (last
programming Embedded Multicore-Systems. Bsc. the- accessed on 01.09.2016).
sis, TU Mu¨nchen, 2011. [22] S. Miller, E. Anderson, L. Wagner, M. Whalen, and
[7] M. Fakih, K. Gru¨ttner, M. Fr¨anzle, and A. Rettberg. M. P. E. Heimdahl. Formal verification of flight crit-
State-based real-time analysis of SDF applications on ical software. In Proceedings of the AIAA Guidance,
MPSoCs with shared communication resources. Jour- Navigation and Control Conference and Exhibit, 2005.
nal of Systems Architecture - Embedded Systems De- [23] P. R. Schaumont. A Practical Introduction to Hard-
sign, 61(9):486–509, 2015. ware/Software Codesign. Springer US, 2013.
[24] S.WarsitzandM.Fakih. Simulink-modell-u¨bersetzung
[8] D. D. Gajski, S. Abdi, A. Gerstlauer, and G. Schirner.
insynchronedatenflussgraphen.In19thGI/ITG/GMM
Embedded System Design: Modeling, Synthesis and
Workshop Methoden und Beschreibungssprachen zur
Verification. Springer Science & Business Media, aug
Modellierung und Verifikation von Schaltungen und
2009.
Systemen, MBMV 2016, Freiburg im Breisgau, Ger-
[9] E. C. Klikpo, J. Khatib, and A. M. Kordon. Mod-
many, March 1-2, 2016., pages 89–101, 2016.
eling multi-periodic simulink systems by synchronous
[25] L. Zhang, M. Glab, N. Ballmann, and J. Teich. Bridg-
dataflowgraphs. In2016 IEEE Real-Time and Embed-
ingalgorithmandESLdesign: Matlab/Simulinkmodel
ded Technology and Applications Symposium (RTAS),
transformation and validation. In Specification & De-
Vienna, Austria, April 11-14, 2016, pages 209–218,
sign Languages (FDL), 2013 Forum on, pages 1–8,
2016.
2013.
[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 Conference
on EmbeddedSoftware,EMSOFT’11,pages3–12,New
York, NY, USA, 2011. ACM.
[12] E.A.LeeandD.G.Messerschmitt.Staticschedulingof
synchronous 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,andT.J.Koo. A
Case Study on SDF-Based Code Generation for ECU
SoftwareDevelopment.InProceedingsofthe2011IEEE
35thAnnualComputerSoftwareandApplicationsCon-
ference Workshops, COMPSACW’11, pages 211–217,
2011.
[14] S. Li. Simulink2sdf - converter. https://github.
com/zcold/Simulink2SDF,2013. (GitHub,open-source
Code, last accessed on 01.09.2016).
[15] R.LublinermanandS. Tripakis. Translatingdataflow
to synchronous block diagrams. In P. Eles and A. D.
Pimentel, editors, ESTImedia, pages 101–106. IEEE,
2008.
[16] MathWorks. Modeling an automatic
transmission 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-based
design. http://de.mathworks.com/products/simulink/
blocklist.html. (last accessed on 01.09.2016).
[19] MathWorks, Inc. Automatic Code Generation -