The FTG+PM Framework for Multi-Paradigm Modelling:An Automotive Case Study

Sadaf Mustafiz†, Joachim Denil‡,§, Levi Lucio†, Hans Vangheluwe‡,†

†School of Computer Science ‡Department of Mathematics §TERA-LabsMcGill University, Canada and Computer Science Karel De Grote

University of Antwerp, Belgium University College, Belgium{sadaf,levi,hv}@cs.mcgill.ca, joachim.denil@kdg.be

ABSTRACTIn recent years, many new concepts, methodologies, andtools have emerged, which have made Model Driven En-gineering (MDE) more usable, precise and automated. Wehave earlier proposed a conceptual framework, FTG+PM,that acts as a guide for carrying out model transformations,and as a basis for unifying key MDE practices, namely multi-paradigm modelling, meta-modelling, and model transfor-mation. The FTG+PM consists of the Formalism Trans-formation Graph (FTG) and its complement, the ProcessModel (PM), and charts activities in the MDE lifecycle suchas requirements development, domain-specific design, verifi-cation, simulation, analysis, calibration, deployment, codegeneration, execution, etc. In this paper, we apply theFTG+PM approach to a case study of a power window inthe automotive domain. We present a FTG+PM model forthe automotive domain, and describe the MDE process weapplied based on our experiences with the power windowsystem.

Categories and Subject DescriptorsH.4 [Information Systems Applications]: Miscellaneous;D.2.10 [Software Engineering]: Design—methodologies

1. INTRODUCTIONIn recent times, model driven engineering (MDE) has beenadopted in industrial projects in widely varying domains.The automotive industry in particular is faced with manychallenges and opportunities.

Earlier [?], we proposed the FTG+PM framework for model-driven software development. It is intended to guide devel-opers throughout the MDE lifecycle. The idea behind theFTG is similar to the Formalism Transformation Lattice forcoupling different formalisms introduced by Vangheluwe in[?]. We go a step beyond multi-formalism modelling, anduse the notion of multi-paradigm modelling [?] as the basisof our work. In multi-paradigm modelling, every aspect ofa problem is modelled explicitly, at the right level(s) of ab-straction, using the most appropriate formalism(s). This isenabled by metamodelling and model transformation.

The Formalism Transformation Graph (FTG) is a hyper-graph with languages as nodes and transformations as edges.It charts the relationships among the multitude of languagesand transformations used to develop systems within a do-main. The Process Model (PM) precisely models the controland data flow between the transformation activities takingplace throughout the software development lifecycle start-ing from requirements analysis and design, to verification,

simulation, and deployment. We use a subset of the UML2.0 activity diagram formalism for the PM. Our frameworkis supported by AToMPM [?], A Tool for Multi-ParadigmModelling, for building metamodels, transformations, andfor executing the FTG+PM model transformation chain.

In this paper, we focus on the application of our approachand demonstrate the capabilities of the FTG+PM throughthe design of an automated power window. The case studyis inherently complex due to its heterogeneity and thus rep-resentative of industrial case studies. The model artifactswithin the FTG+PM range from abstract requirements andanalysis models, to more concrete design models, to modelsof source code. The discrete-time, continuous-time, discrete-event, and hybrid formalisms used in the FTG are appropri-ate to the levels of abstraction used at different stages of themodelling process. The MDE process is entirely based onmodels and transformations, starting from domain-specificrequirements and design models aimed at describing controlsystems and their environment and finishing with Automo-tive Open System Architecture (AUTOSAR) [?] code.

This paper is organised as follows: Section 2 describes theapplication of FTG+PM to the power window case study.Section 3 discusses related work in this area and Section 4draws some conclusions.

2. THE POWER WINDOW CASE STUDYWe apply our approach to a concrete problem in the auto-motive domain: the power window case study. The hetero-geneity of components in such a system make it a suitablecandidate for illustrating the MPM nature of the FTG+PMframework.

A power window is an electrically powered window and ispresent in the majority of the automobiles produced today.The basic controls of a power window include lifting and de-scending the window. Functionalities are added to improvethe comfort and safety of the vehicle’s passengers.

In Figure 1, we depict a condensed version of the FTG+PMmodel we have built for developing the Power Window soft-ware controller. The power window FTG+PM was builtbased on our experience with a concrete, AUTOSAR-basedphysical realisation of a power window.

The model-driven development of the power window con-troller includes several phases all of which are encompassedin the FTG+PM model (Fig. 1). Depending on the intent,it is possible to construct different PMs based on the sameFTG and to traverse a particular path in the graph andapply a subset of the process for the purpose of simulation

:ModelPlant :ModelControl:ModelEnv:ModelNetwork

:ControllerToSC

:ScToPn:PlantToPN:EnvToPN

:PlantToCbd

:EnvToCbd

AND False

:ScToAUTOSAR

:ToInstrumented

:ArchitectureDeployment

:ECUDeployment

False

True

:DetailedDeployment

False

True

:SwToC

:ArToRte:ArToMw

:CombineC

:RefineNetwork

:ToDynamicSpecification

TRUE:ExtractTiming

Behaviour

:RefineTimingBehaviour

:RefineTimingBehaviour

:RefineTimingBehaviour

True

:Boolean :Boolean

:Control DSL:Plant DSL:Environment DSL

:Network Formalism

:Statecharts

:CBD:Encapsulated PN

:CBD:Encapsulated PN

:Encapsulated PN

:Network Formalism

:AUTOSAR

:Performance Model

:AUTOSAR

:AUTOSAR

:AUTOSAR

:Boolean

:Boolean

:Boolean

:C-Code :C-code

:C-code

:C-Code

:Requirements Diagram

:CBD

:TIMMO

:TIMMO

:TIMMO

:TIMMO

ModelRequirements

SafetyAnalysis HybridSimulation

CalibrationInfrastructure

EnvToCBD

Environment DSL

Causal Block Diagrams

PlantToCbd

Plant DSL

ControlToSc

Control DSL

StatechartsNetwork

FormalismEncapsulated

Petrinets

Hybrid Formalism

CombineCBD

AUTOSAR

ScToAUTOSAR

C-code SwToC

Algebraic Equations

ToSchedulabilityAnalysis

DEVS

ToDeploymentSimulation

Performance Trace

ExecuteCalibration

Performance Formalism

ExtractPerformance

ToInstrumented

Architecture Deployment

ScToPnPlantToPnEnvToPN

CombinePN

Reachability Graph

HybridSimula-tion Trace

SimulateHybrid

BuildRG

ToBinPackingAnalysis

RefineNetwork

ModelPlant ModelControlModelEnv

ECUDeployment

DetailedDeployment

ModelNetwork

ArToMwArToRte

CcombineC

SysML Req Diagram

TIMMO

CTL

ModelContext

ExtractRequirements

ToSafetyRequirement

ToDynamicSpecification

Extract Timing Behaviour

Refine Timing Behaviour

SysML Use Case Diagram

Textual Requirements

ModelTextualReq

Boolean

CheckCTLCheckContinuous

Petrinets

RefineUseCases

RefineRequirements

DEVS Trace

SimulateDEVS

Bin Packing Trace

CheckDEVSTrace

Schedulability Trace

CalculateSchedulability

CheckBinPacking

GenerateCalibration

CombineCalibration

RefineUseCase

Description

ModelUseCaseDescription

SearchECUSearchDetailed

CheckSchedulability

:Use Cases

:Use Case Diagram

:SearchECU

:SearchDetailed

:SearchArchitecture False

SchedulabilityAnalysis

DEVSSimulation

BinPackingAnalysis

SearchArchitectureInteger

:Integer

:Integer

:Integer

:BinPackingTrace

:SchedulabilityTrace

:DEVSTrace

1

2

2

1

3

1

Use Cases

language manual transformation automatic transformation

FTG

modelartifact

manual activity

automatic activity

PM

Figure 1: Power Window: FTG (left) and PM (right)

or verification (for instance). In the following sections, webriefly describe each activity and show some sample modelsand transformations. Due to space constraints, the meta-models of the languages and details of the transformationsin the FTG+PM are not shown here. The interested readercan refer to [?] for further details.

We discuss the FTG+PM model of the power window basedon the different dimensions and enablers of MPM presentedin [?]: levels of abstraction, formalisms, metamodelling, andmodel transformations.

2.1 Levels of AbstractionThe power window controller is a complex, time-critical,safety-critical, hard real-time embedded system. When giventhe task to build the control system for a power window, twovariables need to be considered: (1) the physical power win-dow itself, which is composed of the glass window, the me-chanical lifting mechanism, the electrical engine and somesensors for detecting for example window position or windowcollision events; (2) the environment with which the system(controller plus power window) interacts. This includes bothhuman actors and other subsystems of the vehicle, e.g., thecentral locking system or the ignition system [?].

The level of abstraction is associated with the task to beaccomplished and is determined by the perspective on thesystem, the problem at hand, and the background of the de-veloper. At a high level of abstraction, the tasks in our MDEprocess are the development activities starting from require-ments to code synthesis. The detailed tasks are declared astransformation definitions in the FTG and instantiated asactivities in the PM.

The MDE process comprises several activities with mod-els at different abstraction levels. Models at a higher level(starting from requirements models and DSMs) are refineduntil the executable model level (C source code) is reached.For each new modelling language, concrete syntax needs tobe defined in addition to abstract syntax, tailored to thedomain expert working on the specification of that model.Our approach integrates multi-view modelling by buildingdistinct and separate models of the power window systemto model different aspects of the system for different in-tentions. As an example, the domain-specific models aremapped to Petri nets with the intention of model checkingand to CBDs1 for simulation.

Systematically and automatically deriving models of differ-ent complexity significantly increases productivity as wellas quality of models. In particular, our deployment activity(discussed later in this section) follows this principle.

The abstraction levels are based on the different MDE phasesin the FTG+PM. We briefly discuss these phases here.

Requirements Engineering Before any design activitiescan start, requirements need to be formalised so they canbe used by engineers. Starting from a textual descriptioncontaining the features and constraints of the power window,a context diagram is modelled as a SysML use case diagram.The use cases are further refined and complemented with usecase descriptions. Finally, the requirements are capturedmore formally in a SysML requirements diagram.

1Causal Block Diagrams (CBD) are a general-purpose for-malism used for modelling causal, continuous-time systems,used in tools such as Simulink

:BuildRG

:CombinePN

:CheckReachableState

:Boolean

:Petri-Net

:Reachability Graph

:CTL

:Requirements Diagram

:Encapsulated PN

:Encapsulated PN

:Encapsulated PN

Encapsulated Petrinets

combinePN

Reachability Graph

BuildRG

CTL

ToSafetyRequirement

CheckReachableState

Petrinets

Boolean

:Network Formalism

:ToSafetyReq

Figure 2: FTG+PM: Model Checking Slice

Domain-Specific Design The control software system actsas the controller, the physical power window with all itsmechanical and electrical components as the process (alsocalled the plant), and the human actors and other vehi-cle subsystems as the environment. Using the requirementsmodels as a basis, we start the design activities by construct-ing domain-specific languages (DSLs) for the Environment,Plant, and Controller. A Network language is used to com-bine the three design languages and identify the interfacesbetween them.

Model Checking To ensure that there are no safety is-sues with the modelled control logic, formal verification canbe carried out. The domain-specific models used for definingthe plant, environment and the control logic are transformedto Petri nets where reachability properties are checked. It isthen necessary to transform requirements to a property lan-guage (CTL, Computation Tree Logic in our case) so theirsatisfaction can be checked on the Petri nets. In Fig. 2,we present the safety analysis activity of the power windowPM, along with the corresponding subset of the FTG. TheFTG+PM makes causal relations between the different ac-tivities explicit.

Simulation The piecewise continuous behaviour of the up-and-downward movement of the window is simulated usinga hybrid formalism. The hybrid model comprises the envi-ronment and plant models transformed into Causal BlockDiagrams (CBD) and the controller in the Statecharts for-malism.

Deployment After the software has been created and ver-ified, it has to be deployed onto a hardware architecture,which contains a set of electronic control units (ECU) thatare connected using a network. Each ECU can execute aset of related and unrelated software components. Deploy-ment is the process of distributing these components over thehardware architecture and making other low-level choicessuch as scheduling. This can result in non-feasible solutionswhere the spatial and temporal requirements are violated.The deployment space can be searched for optimal solutions.In the power-window system, we only focus on the real-timebehaviour, which is checked on three approximation levels.On these levels, bad solutions are pruned while good so-lutions can be explored further. Fig. 3 shows the actionsinvolved in checking a single solution at the level of bin pack-ing analysis. Transforming to another language, executingthis new model to obtain execution traces and comparingthese traces to check a certain property is a common activ-ity that can be seen as a pattern for all three deploymentlevels in the FTG+PM of Figure 1.

Calibration To build the performance model, we can alsouse generative MDE techniques. The plant model, envi-ronment model and instrumented source code are combinedand executed in a Hardware-in-the-loop environment giving

:ToBinPacking Analysis

:CheckBinPacking

:CalculateBin Packing

:Algebraic Equations

: Boolean

:BinPacking Trace

:TIMMO

:AUTOSAR

:PerformanceModel

AUTOSAR

Algebraic Equations

Performance Formalism

ToBinPackingAnalysis

BinPacking Trace

Boolean

CheckBinPacking

CalculateBinPacking

Figure 3: FTG+PM: Bin Packing Slice

back execution time measurements. These measurementsare needed to calibrate a performance model that is used toguide the deployment space exploration.

Code Generation When a solution turns out to be feasi-ble after the three stages, code can be synthesised for eachhardware platform in the configuration (shown in Figure 1).This includes the generation of the C code of the application,the middleware, and the AUTOSAR run-time environment(RTE) that is required to glue the application and middle-ware code.

2.2 FormalismsWe have used a multitude of languages to model the powerwindow system at different levels of abstraction with dif-ferent intentions. We have used a combination of UMLmodelling languages, domain-specific modelling languages,natural languages, and general purpose languages (GPLs).

• Requirements Development: specification of requirementsusing textual requirements, SysML use case diagram, usecases, and SysML requirements diagram• Domain-Specific Design:– Environment DSL (to describe the interaction between actorsand other subsystems)– Plant DSL (to describe the physical processes within the me-chanical and electrical components)– Control DSL (to describe the logical operation of the hard-ware components)– Network formalism (to compose the DSMs by connections viaports)– Statecharts (to represent the reactive behaviour of the controlDSL)

• Model Checking: DSLs are mapped to encapsulated Petrinets for carrying out safety analysis; reachability analysisuses Petri nets which generates a reachability graph model;safety and liveness properties are expressed in CTL• Simulation: of continuous behaviour using a hybrid simu-lation formalism (based on causal block diagrams and Stat-echarts) and a hybrid simulation trace language (trace con-taining a time/signal value for the continuous part and atime/state value for the Statechart)• Analysis: TIMMO (TIMing MOdel) [?] timing analysis,for the maximum end-to-end latencies of the application• Calibration: calibration infrastructure for performance mod-els in a custom performance language (timing properties ofthe software function w.r.t. a hardware type). The gen-eration of the infrastructure is based on the environmentmodel, plant model, and instrumented source code (C GPL).• Deployment:– software deployed onto a hardware architecture using the AU-TOSAR middleware and metamodel– timing analysis using bin packing checks and schedulabilityanalysis, based on algebraic equations and bin packing and schedu-

lability trace languages (containing the results of the algebraicequations)– deployment simulation using DEVS (a modular and hierarchi-cal formalism for modelling and simulating systems), generatinga trace in the DEVSTrace language (containing the trace of thesimulation), and a final result as a boolean

• Code Synthesis: generation of the application code, mid-dleware and the AUTOSAR RTE in the C GPL language

2.3 MetamodellingThe languages are metamodelled using a base formalism, inour case class diagrams. The modelling environments aresynthesized in AToMPM from their abstract and concretesyntax models. Due to space reasons, the metamodels arenot shown here.

For the requirements languages, we use the standard SysMLuse case diagram and requirements diagram metamodels [?].In case of the DSLs, the abstract syntax and the concretesyntax are constructed in AToMPM based on elements spec-ified in the requirements. For Petri nets, the UML Petri netmetamodel is used. For the encapsulated Petri nets, thePetri net metamodel is extended with ports and a namedelement class.

The meta-model of CBDs used is based on the work ofDenckla and Mosterman [?]. It contains blocks, ports andrelations between these ports. The abstract syntax used forStatecharts is based on the UML Statecharts metamodel,with semantics as defined by Harel [?]. The hybrid formal-ism combines the Statechart and CBD metamodels.

For the deployment part of this work, we use a subset ofthe AUTOSAR metamodel defined by the AUTOSAR con-sortium. The requirements language, TIMMO, extends theAUTOSAR metamodel with timing concepts defined in [?].The algebraic equations language is based on simple mathe-matical formulas with float values, variables, equalities andalgebraic operators. The algebraic traces gained from ex-ecuting the algebraic equation contain a component nameand float value representing either the load on the hardwarecomponent or the response time of the software function.The simulation model is based on the DEVS formalism. TheDEVStrace language contains a time-stamp and action field.The boolean languages and integer languages just contain asingle value with either a boolean or integer respectively.

The performance model also extends the AUTOSAR metamodel with performance properties such as worst-case ex-ecution time, between a software function and a hardwaretype. This is gained by analysing the performance tracethat contain the software function name with a float value(representing the execution time).

2.4 The Glue: TransformationsIn this paper, we elaborate on a vertical slice of the FTG+PM.The transformations in the FTG take one of more models asinput and produces one model as output. The models thatare acceptable as inputs and outputs need to conform tothe metamodels described in Sections 2.2 and 2.3. Betweensquare brackets, we classify the transformations accordingto [?].

ModelContext derives a SysML use case diagram (Fig 4)based on the textual requirements. These transformationsare usually done manually by requirements engineers. Someautomatic transformations can be used to populate the use

Power Window Controller

OperateSideWindow

OperateRoofWindow

OpenWindow

CloseWindow

LockoutWindow

LowerWindow

RaiseWindow

StopWindow

<<include>> <<include>> <<include>><<include>>

<<include>>

<<include>> <<include>><<include>><<include>>

RoofWindow

SideWindow

PassengerWindow

DriverWindow

CentralLockingSystem

1

2..*

1 1..*

1

InfraredSensor

1..*

ForceDetecting

Sensor

1..*

Motor

1..*

IgnitionSystem

1

Driver

1

Passenger

*

Switch

*

Lockout

*

Pushpull

*

Rocker

*

RollUpWindows

<<include>>

LiftWindow

<<include>>

Figure 4: Power Window: SysML Use Case Dia-gram

Figure 5: Power Window: Plant DSL Model

case diagram and requirements diagram. [exogenous, hori-zontal]

RefineUseCases is a transformation between models ex-pressed as SysML use case diagrams (Fig 4). The refine-ment takes into consideration inputs and clarifications fromthe client. [endogenous, horizontal]

ExtractRequirements takes a SysML use case diagramand produces a SysML requirements diagram (not showndue to space constraints) which is refined with extra func-tional requirements and constraints based on the initial tex-tual requirements. [exogenous, vertical]

ModelPlant maps the requirements (inputs: SysML re-quirements diagram, use cases) to a DSL (output: Fig. 5)to represent the plant domain. [exogenous, vertical]

PlantToPN takes a plant DSL model (Fig. 6) and trans-forms that to an encapsulated Petri net2 [exogenous, ver-tical]

CombinePN takes three encapsulated Petri nets (not shownhere) derived from the environment, plant and control domain-specific models, as well as a network model that specifieshow the three communicate. The transformation outputsa Place/Transition Petri net (non-modular), which is theresult of the fusion of the three input modular Petri netsaccording to the input network model. [exogenous, hori-zontal]

ToSafetyReq takes as input a model of the safety require-ments, as well as the combined Petri net model represent-ing the behaviour of the whole system, and outputs a setof CTL formulas encoding the requirements. [exogenous,

2encapsulated Petri nets are a modular Petri net formal-ism, where transitions can be connected to an encapsulatingmodule’s ports.

Figure 6: Power Window: Petri Net for Driver Win-dow Plant Model

Figure 7: Power Window: Causal Block Diagram(CBD) for Plant Model

SWC

ControlDrv

SWC

CmdUp

SWC

UpDrv

SWC

CmdDown

SWC

CmdStop

Figure 8: AUTOSAR Software Component Model

vertical]Build RG takes the derived Petri net and generates a reach-ability graph. Note that ToSafetyReq and BuildRG shouldbe executed in parallel. [exogenous, vertical]

CheckReachableState takes the CTL formulas and out-puts true if the reachability analysis is successful. [exoge-nous, vertical]

PlantToCBD transforms the plant DSL to a causal blockdiagram (Fig. 7). [exogenous, vertical]

CombineCBD takes the CBDs mapped from the DSLsand the Statechart model, and composes them to producea hybrid simulation model. [endogenous, horizontal]

SimulateHybrid uses the hybrid simulation model as thesource and produces a mixed continuous - discrete tracemodel. [exogenous, vertical]

CheckContinuous takes the continous trace model, en-sures that it conforms to the initial specified constraints,and outputs a boolean value depending on the success ofthe analysis. [exogenous, vertical]

ScToAUTOSAR encapsulates the given Statechart in anAUTOSAR-compliant model (Fig 8). A single softwarecomponent is used for the Statechart while for each inputsignal to the Statechart, a sensor-actuator component iscreated. [exogenous, vertical]

SwToC generates AUTOSAR-compliant C code of the ap-plication from the input AUTOSAR model. [exogenous,synthesis]

ToInstrumented generates instrumented C code of theapplication from the AUTOSAR model. This can be used

to create a performance model of the application used dur-ing deployment. [exogenous, synthesis]

Architecture Deployment adds information on the map-ping of software to hardware components to the AUTOSARmodel. Backtracking may take place during the explorationof the deployment space. [endogenous, vertical]

ToBinPackingAnalysis creates an output algebraic equa-tion from the AUTOSAR model and the performance modelto check the load of the hardware component. [endogenous,vertical]

CalculateBinPacking executes the algebraic equations cre-ated by the ToBinPackingAnalysis transformation. [exoge-nous, horizontal]

CheckBinPacking checks the result of the execution ofthe bin packing check with the RMA threshold defined byLiu and Layland [?]. [exogenous, horizontal]

SearchArchitecture decides how the exploration shouldproceed in case the schedulability test failed. [exogenous,horizontal]

ArToMW generates the middleware code for a single con-trol unit from the deployed AUTOSAR model. [exogenous,synthesis]

ArToRTE generates the run-time environment code for asingle control unit from the deployed AUTOSAR model.[exogenous, synthesis]

CombineC combines the application software code, therun-time environment code and the generated middlewarecode so it can be compiled. [endogenous, horizontal]

3. RELATED WORKResearch has been carried out in both academia and indus-try on the model-driven engineering of automotive cyber-physical systems [?, ?, ?]. [?] presents an MDE frameworkbased on SysWeaver for the development of AUTOSAR-compliant automotive systems. Typical design methods usedin domains such as automotive and aerospace follow the Vmodel for software development [?, ?]. Prabhu and Moster-man [?] illustrates the model-based design of an embeddedcontrol systems using the power window case study. Theycover the MDE process starting from behavioural modellingto code generation, and focus on the use of an integratedtool suite for MDE. Many links exist with research in processmodelling. These are not described due to space constraints.

4. CONCLUSIONWe have applied the FTG+PM framework to a non-trivialcase study of the design of an automotive power window con-troller. We have constructed the FTG and PM for the tar-get domain. This encompasses the various phases of model-driven development of the power window. As part of eachphase, we defined the appropriate formalism(s) and the re-lations between them. The process model was used to guidethe development of the power window controller.

The FTG and PM we have presented can be adapted foruse in various domains. It provides a complete model-drivenprocess that is based on meta-modelling, multi-abstractionand multi-formalism modelling, and model transformation.We believe that our experiences can be useful for othersworking on the development of systems in the automotivedomain. The power window FTG+PM is a skeleton whichcan be extended, refined, or adapted for various techniquesand technology, for example feature modelling for softwareproduct lines. We intend to study higher order characteris-

tics of transformation chains, and use the FTG+PM to au-tomatically reason about the properties of chains of modeltransformations. We further plan to work on integrating themodel-based testing phases in our framework and applyingit to our case study.

5. ACKNOWLEDGMENTSPart of this work has been developed in the context of theNECSIS project, funded by Automotive Partnership Canada.