A Simulation Framework for VirtualIntegration of Integrated Systems

Roman Obermaisser∗, Martin Schlager∗∗Vienna University of Technology/Institute of Computer Engineering, Vienna, Austria

email:{romano,smartin}@vmars.tuwien.ac.at

Abstract— The simulation of distributed applications onvirtual integration platforms has the benefit of shorteningthe time-to-market by reducing the required number ofphysical prototype setups. This paper presents a simulationframework for a novel type of platforms for large dis-tributed real-time systems, namely integrated architecturesbased on time-triggered control (e. g., DECOS architecture).The simulation framework captures the specific temporalproperties of the execution platform in an integrated archi-tecture, where the communication resources (e. g., networkbandwidth) and the computational resources (e. g., CPUtime of node computers) are shared between multiple ap-plication subsystems. The simulation framework combinesa simulation of the communication system, a simulationof the operating system, an environmental simulation, andapplication code created from MATLAB/Simulink modelsof the application behavior. We show an implementationof the introduced framework for the DECOS architectureand describe an example based on an automotive headlampsystem.

Keywords— integrated architectures, simulation, valida-tion, virtual integration, real-time systems, model-baseddevelopment

I. INTRODUCTION

In recent years, the application of simulation methodsin the domain of real-time systems has become moreand more important. On the one hand this is due to thesteadily increasing complexity of embedded software andconstantly decreasing development cycle periods withinthe embedded domain (e. g., automotive, aerospace, rail-ways, space, industrial) which results in high cost pre-assure of the participating actors and which requires newdevelopment approaches. On the other hand the enormousadvances in the field of information technologies and theresulting accessibility of adequate computing resources topractically every engineer makes it economically feasibleto apply simulation methods, even in domains that havenot been using simulation techniques in the past, likee. g., in the industrial control domain or in the automotivedomain. For instance, after emphasizing on simulationearly in the development process, Toyota expected toidentify 80% of all problems on a new design before thefirst physical prototype stage [1].

There are several reasons for using simulation tech-niques in the development process of (embedded) real-time systems [2]: Testing of early system prototypes ispossible in an artificial (possibly hazardous) environmentthat is set-up according to a defined test scenario. Oncea simulation is set-up, a large number of simulation runs

can be performed without any significant cost implication.Furthermore, the environment of the System-Under-Test(SUT) may not be available, either because it has not yetbeen built, or because it is located at a different physicalsite.

In the automotive domain, the benefits of simulationtechniques have resulted in the notion of virtual integra-tion platforms. In [3], it is proposed that the integrationshould take place on a virtual platform that consists ofmodels of the hardware and software components thatconstitute the building blocks of the overall model of thedistributed function and architecture.

This paper exploits the concept of virtual integrationplatforms for the validation activities in integrated archi-tectures. We use a virtual integration platform to simulatedistributed applications prior to their deployment on thefinal target platform. Integrated architectures, such asAUTOSAR [4] or DECOS [5], permit the coexistence ofmultiple application subsystems (e. g., comfort, multime-dia, powertrain subsystems in car) on a shared distributedcomputer system. By sharing both the computational re-sources of the node computers (e. g., CPU time, memory)and the communication resources of the network, theoverall number of node computers and networks can besignificantly reduced. For this reason, integrated architec-tures are seen as seminal to overcome the high hardwarecost, weight, and wiring induced by present day federatedarchitectures (e. g., in the automotive domain [6], [7]).

In the DECOS architecture, virtual networks have beenintroduced in previous work as a solution to share a singlephysical network for multiple application subsystems [8].Likewise, partitioning operating systems have been intro-duced for the sharing of the computational resources [9],[10]. Both virtual networks and partitioning operatingsystems employ time-triggered schedules for mediatingaccess to the shared resources. Time-triggered control per-mits a clean encapsulation of application subsystems andfacilitates the correctness-by-construction of component-based systems [11]. Also, time-triggered control is suitedfor the implementation of safety-critical applications [12].

When implementing real-time applications (e. g., con-trol loops, alarm monitoring) using virtual networks andpartitioning operating systems, developers are interestedin the temporal behavior of the application subsystems.The sharing of a single distributed computer systembased on time-triggered communication schedules has animpact on the completion times of communication and

computational activities, e. g., due to the sampling delaysthat occur for events that are not synchronized to the time-triggered schedule.

In order to analyse the behavior of application sub-systems when implemented on an integrated architecture,we provide a comprehensive simulation framework inthis paper. The simulation framework combines (1) asimulation of virtual networks, (2) a simulation of time-triggered partitioning operating systems, (3) an environ-mental simulation, and (4) application code created frommodels of application functionality.

Using this simulation framework, developers can de-termine whether application subsystems operate correctlyin the integrated architecture. In particular, developerscan assess the effects of the temporal behavior of virtualnetwork and time-triggered partitioning operating systemson the application behavior. This ability is of particularimportance for reusing legacy applications, which havebeen developed for federated architectures.

The major contributions of this paper are:• Framework for virtual integration in an inte-

grated architecture. The presented framework en-ables developers to simulate the behavior of ap-plication subsystems that share computational andcommunication resources with other application sub-systems based on time-triggered schedules.

• Combination of virtual integration with environ-mental simulation. In the absence of the physicalenvironment, support for environmental simulation isessential for testing real-time applications by meansof simulation.

• Tool-support for virtual integration on the DE-COS execution platform. In the scope of this work,we have developed a tool chain that starts with MAT-LAB/Simulink models of the application behavior,the environment, and the DECOS execution plat-form. These models are automatically transformedinto input for simulation tools.

The remainder of the paper is structured as follows.Section II presents related work regarding the simulationof distributed real-time systems. In Section III the DECOSintegrated architecture is outlined. The system model forthe introduced virtual integration platform is the focus ofSection IV, whereas in Section V, the three relevant inputmodels for this platform are discussed. The simulationapproach on the virtual integration platform is explainedwithin Section VI. An automotive example in Section VIIdemonstrates the application of the presented conceptswith a real-world system. A conclusion of the paper isgiven in Section VIII.

II. RELATED WORK

Dependable real-time systems follow either a federatedor an integrated design approach. The traditional feder-ated approach had been to implement each subsystemas a self-contained unit with its own processing andinput/output systems [5]. In contrast, an integrated so-lution combines the complexity management advantages

of the federated approach, but also realizes the func-tional integration and hardware efficiency benefits of anintegrated system [13]. DECOS (Dependable EmbeddedComponents and Systems), a project within the SixthFramework Programme of the European Commission,aims at developing the basic enabling technology for sucha move from a federated distributed architecture to anintegrated distributed architecture [14].

In the literature, several approaches can be found tosimulate a (federated) real-time system or parts of it,i. e., to represent the system or parts of it by a model thatbehaves or operates like the system [15]. To the best ofour knowledge, none of the existing methods explicitlyfocuses on simulation within an integrated architecture.Usually, simulation methods have been applied to thedevelopment process of real-time systems in order totest and validate the system. For instance, for testing adistributed real-time system, the set-up of an environmentsimulator is proposed in [16], that mimics the behaviorof the real-time system’s physical environment. Emulat-ing non-existing physical entities, i. e., nodes, of a real-time system through a cluster simulation is discussedin [17], [18]. A testing method of distributed algorithmsthat includes a simulation model of the communicationsubsystem is presented in [19]. A comprehensive in-vestigation on pre-validation of system properties of asafety-critical distributed real-time system by a simulationenvironment can further be found in [20]. Moreover,a generic MATLAB/Simulink toolbox for simulation ofdistributed real-time control systems has been introducedin [21] that explicitly includes a real-time kernel modulefor task activation and a network module that can be tai-lored to a particular network model. In order to facilitatesynchronization among distributed simulator objects, anapproach for parallel and distributed real-time simulation,the so-called distributed time-triggered simulation (DTS)scheme, is given in [22]. The idea of the DTS schemeis to trigger distributed simulator objects of a real-timesimulation simultanously by a globally available real-time clock and thus to avoid complex synchronizationmechanisms among objects of a distributed simulator.

III. DECOS INTEGRATED ARCHITECTURE

This section describes the DECOS integrated archi-tecture for dependable embedded real-time systems [5],which provides a framework for integrating multiple ap-plication subsystems within a single, distributed computersystem.

A. System Structure

For the provision of application services at the con-trolled object interface, the real-time computer system islogically divided into a set of nearly-independent sub-systems, each providing a part of the computer system’soverall functionality. We denote such a subsystem as aDistributed Application Subsystem (DAS) (e. g., multime-dia, braking, or lighting subsystem in a car), since the im-plementation of the corresponding functionality will mostlikely involve multiple nodes that are interconnected by

an underlying communication system. In analogy to thestructuring of the overall system, we further decomposeeach DAS into smaller units called jobs. Jobs are the basicunits of work and exchange messages via so-called virtualnetworks in order to work towards a collective goal.

Physically, the real-time computer system in the DE-COS architecture consists of a set of nodes that areinterconnected by a Time-Triggered Backbone Network(TTBN). The virtual networks are implemented on topof this TTBN as overlay networks [8]. The selection of atime-triggered network is motivated by the requirementswith respect to predictability and fault-tolerance require-ments in safety-critical applications [23].

B. Generic Architectural ServicesThe DECOS architecture offers to system designers

generic architectural services (e. g., virtual network ser-vice, gateway service), which provide a validated stablebaseline for the development of applications. For theimplementation of these services, the DECOS architecturebuilds on top of the TTBN. Prototype implementations ofthe DECOS architecture are available with different time-triggered communication protocols used for the TTBN(e. g., TTP [24], FlexRay [25]).

1) Virtual Network Service: The virtual network ser-vice is an architectural service for establishing the virtualnetworks, each of which serves as the dedicated com-munication infrastructure for the jobs of a DAS. A jobcan send two types of messages on a virtual network,namely state messages and event messages. These twomessage types differ w.r.t. the information semantics [26,p. 31]. While state messages contain the absolute valueof a real-time entity (e. g., speed is 10 ms−1), eventmessages transport relative values (e. g., decrease of speedby 2 ms−1).

To the jobs, the virtual network service provides portsas the access points towards the virtual networks. For stateand event messages, two different types of ports are estab-lished by the virtual network service. A state port supportsthe reception or transmission of state messages. Sinceapplications are often only interested in the most recentvalue of a real-time entity, a state port contains a memoryelement that is overwritten with newer state values when-ever a message arrives at the port (i. e., update-in-place).An event port supports the reception or transmission ofevent messages. In order to reconstruct the current stateof a real-time entity from messages with event semantics,messages are queued at an event port in order to processevery message exactly-once. The loss of a single messagewith event semantics could affect state synchronizationbetween a sender and a receiver.

2) Virtual Gateways: The need for virtual gatewaysin the DECOS architecture arises through the logicalstructuring. In case the coordination of the behavior oftwo DASs requires an information exchange betweenthem, the structuring of the system into DASs inducesso-called virtual gateways. The main purpose of intro-ducing this new architectural element instead of directlyconnecting all jobs through a single virtual network is

Fig. 1. System Model of the Simulated Real-Time System

encapsulation. A particular message is only redirectedfrom one virtual network to a second one, if the virtualgateway has been explicitly parameterized to forward thismessage. Hence, jobs perceive only those messages fromanother DAS, which are required for realizing the DAS’sapplication service. This strategy minimizes the mentaleffort for understanding a DAS and its constituting jobs,because the designer can abstract from all messages inother DASs that are not explicitly imported through avirtual gateway. In addition, the provision of a separateencapsulated virtual network for each DAS establishesclear error propagation boundaries.

IV. VIRTUAL INTEGRATION PLATFORM

The virtual integration platform supports the simulationof a distributed computer system complying to the DE-COS architecture along with the environment. As depictedin Figure 1, the simulated distributed computer systemconsists of a set of simulated nodes, each hosting jobsof one or more DASs. The simulated TTBN is as asubstitute for a physical network interconnecting thesenodes. The simulation of the environment serves thepurpose of providing to the jobs the opportunity to interactwith simulated sensors and actuators.

A. Time-Triggered Backbone Network

This part of the virtual integration platform simulatesa network with a time-triggered communication protocol(e. g., TTP [24], FlexRay [27]). The TTBN executesTime Division Multiple Access (TDMA) and divides timeinto slots that are statically assigned to the nodes. Aparticular slot is used by one node to broadcast a message,while all other nodes receive the message. A periodicallyrecurring sequence of slots that enables each node to senda message is called a communication round.

The simulated TTBN provides to the simulated nodes atime-triggered message transport service, which performsperiodic exchanges of state messages at predefined globalpoints in time. At each simulated node, the interface tothe TTBN is a memory element. The memory elementcontains outgoing state messages that are written bythe application in the simulated node and read by thesimulated TTBN prior to broadcasting them. In addition,the memory element contains incoming state messagesthat are read by the application in the simulated nodeand updated by the simulated TTBN with state messagesreceived from other nodes.

In a physical TTBN, this memory element would beprovided by a communication controller at each node,

e. g., TTP controller C2 [28] or FlexRay ControllerMFR4200 [29]). This memory element, which is denotedCommunication Network Interface (CNI) in TTP andController Host Interface (CHI) in FlexRay, is provided bymost time-triggered communication protocols with syn-tactic differences of state messages (e. g., header format)and protocol-specific constraints (e. g., only one messagesent by a node per communication round in TTP [24],same size for all state messages in FlexRay [27]).

B. Simulated Node

A simulated node contains partitions, each of whichis an encapsulated execution space within a node witha priori assigned computational resources (e. g., CPU,memory) that can host a job. Partitions are the targetof job allocation and each job is always assigned in itsentirety onto a partition, i. e., a job is never fragmentedonto multiple partitions.

A simulated node also contains the DECOS middle-ware for the implementation of the generic architecturalservices (i. e., virtual networks, gateways). The DECOSmiddleware maps the memory element provided by theTTBN to ports that serve as the access points to thevirtual networks. In order to enable jobs of a DAS toexchange information, the middleware layer provides toeach job one or more state ports and event ports. Astate port contains a state variable that is accessed by theDECOS middleware at a priori specified global points intime. The state variable is either written by the DECOSmiddleware (data received from a virtual network anddestined to an input state port) or read by the DECOSmiddleware (data from an output state port and destinedto a virtual network). An event port, on the other hand,contains a message queue into which messages that are re-ceived from a virtual network are inserted by the DECOSmiddleware in case of an input event port. For an outputevent port, the DECOS middleware retrieves messagesfrom the queue and sends them via the correspondingvirtual network.

C. Environment

In order to perform integration tests that involve theinteraction between a given distributed computer systemand its environment, an environment simulation needs tobe set-up that resembles the physical surrounding of thecomputer system, i. e., the controlled object(s) and theoperator. The interaction between the computer systemand the environment is established via transducers. Atransducer is a device (i. e., sensor, actuator) that convertsenergy from one form to another in order to measure aphysical quantity or to transfer information [30].

Within the simulation framework, we assume that atransducer manages a set of real-time entities of the envi-ronment (e. g., speed of a motor). Each time a simulatednode needs to interact with the environment, it accessesa real-time entity of a simulated transducer element.

V. INPUT MODELS FOR SIMULATION

The virtual integration platform takes as an input threemodels (cf. Figure 2): (1) a model capturing the applica-tion behavior, (2) a model that describes the distributedexecution platform, and (3) a model of the environment.Using code generation tools, we produce for each modela set of software modules that can be executed withinthe simulation framework. The simulation frameworkprovides feedback to the designer concerning the behaviorof the application on a given virtual integration platform(defined via the models of the execution platform and theenvironment).

A. Application Model

The application model decomposes the overall system(e. g., on-board electronic system of a car) into DASsand jobs. Based on this system structure, the applicationmodel specifies the ports, which provide the interfacesbetween the jobs and the virtual networks. Each port isa message-based interface, which is represented in theapplication model via an operational specification thatdenotes the syntax of exchanged messages, the timing ofthe messages, and error conditions (e. g., input and outputassertions).

For specifying the behavior of the jobs, a suitableformalism can be selected that fits to the respective appli-cation domain. For example, in the implementation of thesimulation framework in Section VI, MATLAB/Simulinkhas been used. The behavioral specification defines foreach job a corresponding data transformation. Such adata transformation takes as an input the messages atthe input ports (i. e., from other jobs), the informationacquired from the sensors (i. e., at the interface to theenvironment), and the internal state of the job. The outputsof the transformation are messages written into outputports (i. e., destined to other jobs), information for theactuators (i. e., to the environment), and updates to theinternal state of the job.

B. Platform Model

The platform model describes the distributed platform,on which the application subsystems shall be executed.The platform model encompasses the following threeparts:

1) Partitions of Execution Environment: This part ofthe platform model defines the partitions (cf. Section IV-B). In the simulation framework, we assume a time-triggered operating system (e. g., [9]), which associateseach partition to a periodically recurring time slice. Con-sequently, a partition is characterized by the temporalattributes of the time slice (i. e., start and period ofinvocation, duration of execution), as well as by the spatialattributes (i. e., location of the partition expressed as aparticular node and processor within the node).

2) Virtual Networks and Gateways: As part of theplatform model, the configuration of the virtual networksand gateways is defined. The configuration of the virtualnetworks provides information on the types of avail-able virtual networks along with the control paradigm

Fig. 2. Model-based Integration on Virtual Integration Platform

(i. e., time-triggered or event-triggered), and the commu-nication topology (e. g., broadcast, point-to-point). Also,for each virtual network the mapping to the underlyingTTBN is specified by reserving TDMA slots at the time-triggered physical network. For the virtual gateways, theplatform model defines which messages shall be redi-rected between virtual networks.

3) Time-Triggered Backbone Network: The third partof the platform model captures the physical network ofthe platform. In particular, the TDMA scheme of theTTBN is laid down. In conjunction with the virtualnetwork configuration, this TDMA scheme determinesthe temporal properties (i. e., bandwidth, latencies) of thevirtual networks.

C. Environment Model

The model of the environment is derived from ananalysis of the natural environment and the used sen-sors/actuators. In analogy to the application model, wewill use MATLAB/Simulink for the implementation of thesimulation framework in Section VI.

VI. SIMULATION ON VIRTUAL INTEGRATIONPLATFORM

Using automatic code generation, the three input mod-els (i. e., for application, platform, and environment) aretransformed into code that can be executed on a Linux-based PC in conjunction with a simulation engine. TheReal-Time Workshop processes the MATLAB/Simulinkmodels for the application and the environment, thusproducing software modules for the jobs and the trans-ducers. For the platform, we use code generation toolsthat have been introduced in previous work [31], [32] forthe deployment on a physical target system.

We denote a task, which executes generated simulationcode, as a runnable. The simulation framework employsthree types of runnables: a TTBN runnable for simulatinga physical time-triggered network, node runnables for thesimulated nodes, and transducer runnables for simulatingthe environment.

The purpose of the simulation engine is the establish-ment of a binding between the runnables (cf. Figure 3).The simulation engine synchronizes the execution of therunnables by enforcing a time-triggered action lattice forthe computational activities of the simulated nodes, thecommunication activities of the simulated TTBN, andthe state changes in the environment. In addition, the

simulation engine provides mechanisms for the informa-tion exchange between runnables. The interaction betweenrunnables takes place across interfaces that are realized asshared memory regions:• Controller network interface (CNI): The CNI links

the node runnables of the simulation framework.• Controlled object interface (COI): The COI rep-

resents the interface between the integrated systemand its environment.

• Simulation system interface (SSI): The SSI is usedfor the interaction of different transducer runnables.

Fig. 3. Simulation Framework

Within the following sections we will outline thefundamental properties of the simulation engine and therunnables, including the respective interfaces.

A. Simulation Engine

The simulation engine manages the activation ofrunnables at pre-defined instants. Hence, it provides alogical simulation time that emulates a physical clock.Based on the progression of this logical time (i. e., in-crement of an internal counter variable), the simulationengine processes a deterministic, round-based schedule.The smallest entity of this schedule is a slot. Withineach slot the simulation engine can activate either oneor several runnables.

The activation of the involved runnables is realizedwith semaphores whereas a pair of semaphores is relatedto each runnable. Hence, the simulation engine starts acertain runnable by performing a V operation on thefirst semaphore and waits for the runnable to finish byperforming a P operation on the second semaphore.

Runnables are statically linked with the simulationengine. Thus, the identifier of a certain runnable, i. e., thepair of semaphores, as well as the instants of activationof this runnable are defined within the simulation engine.The dynamic behavior of the runnable is given withinthe particular runnable, and is therefore not part of thesimulation engine.

B. TTBN Runnable

The TTBN runnable emulates a physical TTBN thatconnects the nodes of an integrated architecture. Hence,the TTBN runnable enables the interaction of noderunnables across the CNI. Therefore, it operates on theCNI and periodically (i. e., each time it is activated bythe simulation engine) updates the CNI according to astatically defined Message Descriptor List (MEDL).

In order to better explain the purpose of the TTBNrunnable it should be mentioned that each node runnablehas access to a particular region of the CNI (i. e., aparticular shared memory region). Each node runnablecan read/write messages from/to this CNI region. Eachtime, the TTBN runnable is activated, it copies messagesthat have been written to a certain CNI regions by a nodeto all other CNI regions of all other nodes.

In a real (i. e., non-simulated) integrated system, thistask would be performed by communication controllersthat would send messages from a particular node, receivemessages from all other nodes, and perform the respectiveCNI read/write operations.

C. Node Runnables

As depicted in figure 3, the simulation frameworkinvolves a set of node runnables that correspond to theapplication behavior of the integrated system. Each noderunnable represents the dynamic behavior of an integratednode. Hence, each node runnable consists of a set of jobsthat are executed according to a time-triggered schedule.The deterministic activation of jobs by a node correspondsto the activation of partitions by a time-triggered operatingsystem.

As explained in the previous subsection, the interactionbetween different node runnables happens across theCNI. Furthermore, the interaction between node runnablesand the environment is realized via the COI. The COIis realized as a separate shared memory region. Thisshared memory region consists of messages that reflectinformation exchanged with transducers. For instance, thecurrent analog value of an infra-red distance sensor couldbe stored within an integer variable distance analog aspart of the COI. The involved transducer runnables (referto the next subsection) are responsible to periodicallyupdate the COI.

We propose the development of the dynamic behaviorof node runnables with MATLAB/Simulink. After a MAT-LAB/Simulink model has been realized, it is possibleto perform preliminary tests within MATLAB/Simulink.After that, C code of the model is automatically generatedwith the Real-Time Workshop Embedded Coder and thisC code is included in the node runnable.

The simulation framework provides wrapper code thatbasically performs three steps each time a node runnableis activated by the simulation engine:• Read input: All required input data from the CNI

and from the COI is read by the node runnable. Thisinput data is used to set the input variables of theMATLAB/Simulink model.

• Execute model: One step of the MATLAB/Simulinkmodel is executed by calling the respective functionthat is provided by the automatically generated code.

• Write output: The output variables of the MAT-LAB/Simulink model are read and this data is writtento the according CNI and COI regions.

The integration step that links a particular noderunnable wrapper to the MATLAB/Simulink model has tobe taken only once. If the respective MATLAB/Simulinkmodel is modified (e. g., for calibration purposes), thenode runnable is automatically updated after generatingcode for this updated model.

D. Transducer Runnables

The environment of the integrated system is simulatedby the use of transducer runnables. Each transducerrunnable maintains a set of real-time entities of theenvironment. The interaction between the node runnablesand the transducer runnables takes place via the COI.

Interaction between different transducer runnables hap-pens across the SSI – again a separate shared memoryregion. The SSI is used to exchange messages that arepart of a distributed environment simulation but that arenot visible at the COI. For instance, a simple applicationcould involve two transducer runnables. We assume thatthe first transducer runnable models the dynamic behaviorof an elecric motor that is turned on and off by anode runnable. A second transducer runnable models asensor that captures the current speed of this electricmotor and provides the speed information to another noderunnable. For such an application, the current speed valueof the electric motor would be written to the SSI by thefirst transducer runnable and would be read and furtherprocessed by the second transducer runnable.

The structure of a transducer runnable is quite similarto the structure of a node runnable. Hence, each time atransducer runnable is activated it reads data from the COIand from the SSI, it executes a transducer model, and itwrites data to the COI and to the SSI. As for the de-velopment of node runnables, we propose a model basedapproach (with MATLAB/Simulink) for the developmentof the transducer runnables. The simulation frameworktherefore provides wrapper code for the involvement ofautomatically generated code of transducer models.

VII. CASE STUDY

We decided to develop an automotive control systemfor an adaptive headlamp application as a case study.Adaptive headlamps can be found in today’s upscale carsin order to provide better illumination in curves. Weassume that two adaptive headlamps are mounted on thefront side of a car. Each adaptive headlamp turns withina defined deflection of ± 15 degrees when the car movesinto a curve.

In our example the adaptive headlamp consists of alight that can be switched on and off, a motor that movesthis light, and a sensor that captures the current angleof the headlamp. The operator, i. e., the driver, switchesthe light on/off by the use of a control element of thecars instruments. The movement of the adaptive headlampautomatically follows the movement of the front wheels.The current angle of the front wheels is captured by asensor that is mounted at this wheels.

As depicted in figure 4, the adaptive headlamp appli-cation involves three different DASs. Each DAS consistsof a set of Jobs (rectangles) and transducer elements(rounded rectangles). We assume that three DASs arerelevant for our application: a drive-by-wire DAS, acontrols and instruments DAS, and an adaptive headlampDAS. Message exchange between the three DASs takesplace via gateways. In figure 4 only the jobs of thedrive-by-wire DAS and the controls and instruments DASare outlined that are relevant for the adaptive headlampapplication.

The interaction with the environment is defined asfollows: The current wheel angle is aquired within thedrive-by-wire DAS. The position of the light switch iscaptured within the controls and instruments DAS. Theinteraction with the adaptive headlamp is controlled bythe adaptive headlamp DAS.

Within the adaptive headlamp DAS, the current wheelangle (Job 1) and the light switch position (Job 2) are re-ceived, calibrated, and forwarded to the controller (Job 3).Based on the wheel angle, the light switch position, andthe actual angle of the adaptive headlamp, the controllerdeliveres a control value. The adaptive light job (Job 4)is required for the interaction with the physical adaptiveheadlamp. In figure 4, all relevant messages that areexchanged between the jobs of the three DASs and allmessages that are exchanged between the respective DASsand the transducer elements are outlined.

A. TTBN Runnable

The TTBN runnable has been configured to realizemessage exchanges of the involved node runnables acrossthe CNI. A time-triggered communication schedule witha round duration of 10 ms has been selected for assigningTDMA slots to the interconnected nodes. The TTBNrunnable in the case study simulates a TTP network, thusall protocol-specific constraints of TTP [24] (e. g., maxi-mum message size of 240 bytes) are obeyed.

Fig. 5. Simulink Model

B. Node Runnables

As proposed in section VI, we followed a model-basedapproach for the development of the node runnables.Thus, we started to model each job of the adaptiveheadlamp control system as a MATLAB/Simulink sub-system. Figure 5 shows the top-level view of the MAT-LAB/Simulink model. Each dark grey colored block rep-resents the dynamic behavior of one job. The jobs of thedrive-by-wire DAS and the controls and instruments DAShave been left out for reasons of comprehensibility.

Each job is provided with a set of input values andproduces a set of output values. Both input and outputvalues are either stored within the CNI or within the COI(i. e., the respective shared memory regions). Hence, wedefined for each value the corresponding variable either aspart of the CNI (if it is transmitted as a message betweendifferent jobs) or as part of the COI (if it relates to areal-time entity of the environment). For instance, thevariable WheelAng is part of the COI, whereas the variableCalibWheelAng is part of the CNI.

In addition, the node runnable incorporates the DE-COS middleware for the establishment of the virtualnetworks and gateways. As mentioned above, the adaptiveheadlamp control system involves three different DASs.Each DAS uses its own virtual network. Furthermore, theDECOS middleware implements two gateways, namelya gateway from the controls/instruments DAS to theadaptive headlamp DAS and a gateway from the drive-by-wire DAS to the adaptive headlamp DAS.

C. Transducer Runnables

The adaptive headlamp application involves three trans-ducer runnables. The WheelSensor runnable resembles thedynamic movement of the front wheels and delivers thecurrent wheel angle. The LightSwitch runnable simulatesthe position of the light switch that is turned on and offby the driver via the cars instruments. The AdaptiveLightrunnable includes a model of the dynamic behavior ofthe motor that moves the headlamp. Thus, it calculatesthe current angle of the headlamp.

The development of the transducer runnables followsa model based approach as well. The light gray colored

Fig. 4. Adaptive Headlamp System

blocks of figure 5 represent the models for the transducerrunnables.

The purpose of setting up a simulation of the adaptiveheadlamp control system has been to test and fine-tune thePI controller with varying specifications of the physicalheadlamp. Hence, we set-up experiments with differentactuator parameters (e. g., response of the motor of theheadlamp given a certain control value) and with differentPI controller parameters (e. g., degree of acceptable over-shooting). In the next subsection, experimental results arediscussed.

D. Simulation Output

Before starting the simulation we have to select allvariables of interest (e. g., real-time entities, or eveninternal variables of the simulation model). A trace ofthese variables is stored during a simulation run. Afterselecting the time frame for a simulation run (which isa configurable property of the simulation engine) we canstart the simulation.

Figure 6 shows the output of the PI controller, i. e., thecontrol value, for an example scenario. Thereby weassume that the angle of the front wheels constantlyincreases within one second and then decreases at thesame pace. The corresponding angle of the adaptiveheadlamp shall increase/decrease within the range of ±15 degrees in case the light is switched on. If the light isswitched off, the angle of the adaptive headlamp shall be 0degrees (initial state). For the simulation, we assume thatthe driver switches on the light 0.1 seconds after startingto turn the wheels.

The small line in figure 6 depicts the setpoint value(i. e., the desired angle of the adaptive headlamp) whichis zero as long as the light is turned off and whichcorresponds to the actual wheel angle as soon as the lightis turned on. The thick line shows the output of the PIcontroller, i. e., the control value.

In contrast to tests of the MATLAB/Simulink model,virtual integration within the simulation framework asproposed in this paper includes timing issues of messageexchange between the jobs. Hence, the time interval be-tween message send and message receive instants is mod-eled and the resulting effects on the control applicationcan be directly observed. Even for the relatively simpleadaptive headlamp application, we experienced significant

Fig. 6. Output of the PI Controller (Control Value)

differences between the behavior of the application whenrunning a simulation within MATLAB/Simulink, and whenexecuting the same application (i. e., the generated codefrom the MATLAB/Simulink model) within the simulationframework. The message send interval (e. g., the time ittakes until a message from the wheel sensor is receivedby the PI controller) heavily influenced the overall systembehavior and required us to re-calibrate the PI controller.

VIII. CONCLUSION

Virtual integration platforms (e. g., in the automotivedomain) enable designers to look at the interplay betweendifferent components, while avoiding the time and cost ofphysical prototype setups. From the point of view of thedevelopment process of a product, the reduction of theoverall number of prototype setups helps in decreasingdevelopment cost and shortening the time-to-market.

This paper has focused on a framework that provides avirtual integration platform for integrated architectures.The emerging architectural paradigm of integrated ar-chitectures is seen as seminal to overcome the plethoraof networks and Electronic Control Units (ECUs) inpresent day federated architectures. For example, today’spremium cars contain nearly a hundred ECUs as a resultof the so-called “1-Function – 1 ECU” design principle.

Therefore, we have realized a framework that enablesdevelopers to simulate the behavior of application sub-systems that are integrated on a shared distributed com-puter system. Emphasis has been placed on the accuratereproduction of the temporal behavior of the platform.

In conjunction with an environmental simulation, thedeveloper is thus in a position to simulate real-timeapplications as part of validation.

An automotive example with three application subsys-tems has demonstrated that the framework is suitablefor real-world scenarios. Starting from MATLAB/Simulinkmodels for the platform and the environment, code gen-eration tools have automatically produced the input for aLinux-based simulation engine.

ACKNOWLEDGMENTS

This work has been supported in part by the Eu-ropean IST project ARTIST2 under project No. IST-004527, the European IST project DECOS underproject No. IST-511764, and DOC [DOKTORANDEN-PROGRAMM DER OSTERREICHISCHEN AKADEMIE DERWISSENSCHAFTEN].

REFERENCES

[1] T. Curry, “The Business Benefits of Simulation,” Available athttp://www.nafems.org, 2003.

[2] M. Schlager, W. Elmenreich, and I. Wenzel, “Interface design forhardware-in-the-loop simulation,” in IEEE International Sympo-sium on Industrial Electronics. Montreal, Canada: IEEE, July2006.

[3] P. Giusto, A. Ferrari, L. Lavagno, J.-Y. Brunel, E. Fourgeau,and A. Sangiovanni-Vincentelli, “Automotive virtual integrationplatforms: why’s, what’s, and how’s,” in Proc. of the IEEEInt. Conference on Computer Design: VLSI in Computers andProcessors, Sept. 2002, pp. 370–378.

[4] AUTOSAR GbR, AUTOSAR – Technical Overview V2.0.1, June2006.

[5] H. Kopetz, R. Obermaisser, P. Peti, and N. Suri, “From a federatedto an integrated architecture for dependable embedded real-timesystems,” Technische Universitat Wien, Institut fur TechnischeInformatik, Treitlstr. 1-3/182-1, 1040 Vienna, Austria, Tech. Rep.Technical Report 22, 2004.

[6] P. Peti, R. Obermaisser, F. Tagliabo, A. Marino, and S. Cerchio,“An integrated architecture for future car generations,” in Proc. ofthe 8th IEEE Int. Symposium on Object-oriented Real-time dis-tributed Computing, May 2005.

[7] H. Heinecke, K.-P. Schnelle, H. Fennel, J. Bortolazzi, L. Lundh,J. Leflour, J.-L. Mate, K. Nishikawa, and T. Scharnhorst, “AU-Tomotive Open System ARchitecture - An Industry-Wide Initia-tive to Manage the Complexity of Emerging Automotive E/E-Architectures,” in Proceedinsg of the Convergence Int. Congress& Exposition On Transportation Electronics. Detroit, MI, USA:SAE, Oct. 2004, 2004-21-0042.

[8] R. Obermaisser and P. Peti, “Realization of virtual networks inthe DECOS integrated architecture,” in Proc. of the Workshopon Parallel and Distributed Real-Time Systems 2006 (WPDRTS).IEEE, Apr. 2005.

[9] B. Huber, P. Peti, R. Obermaisser, and C. E. Salloum, “UsingRTAI/LXRT for partitioning in a prototype implementation of theDECOS architecture,” in Proc. of the Third Int. Workshop onIntelligent Solutions in Embedded Systems, May 2005.

[10] M. Schlager, W. Herzner, A. Wolf, O. Grundonner, M. Rosenblattl,and E. Erkinger, “Encapsulating application subsystems usingthe DECOS core OS,” in The 25th International Conference onComputer Safety, Security and Reliability (SAFECOMP), Gdansk,Poland, Sept. 2006, pp. 386–397.

[11] H. Kopetz and R. Obermaisser, “Temporal composability,” Com-puting & Control Engineering Journal, vol. 13, pp. 156–162, Aug.2002.

[12] J. Rushby, “Bus architectures for safety-critical embedded sys-tems,” in Proc. of the First Workshop on Embedded Software(EMSOFT 2001), ser. Lecture Notes in Computer Science, T. Hen-zinger and C. Kirsch, Eds., vol. 2211. Lake Tahoe, CA: Springer-Verlag, Oct. 2001, pp. 306–323.

[13] R. Hammett, “Flight-critical distributed systems: design consid-erations,” IEEE Aerospace and Electronic Systems Magazine, pp.18(6):30–36, 2003.

[14] M. Gruber, “DECOS project proposal,” 2004, austrian ResearchCenter, Vienna, Austria, http://www.decos.at.

[15] I. S. Board, “IEEE standard glossary of modeling and simulationterminology,” The Institute of Electrical and Electronics Engineers,Inc 345 East 47th Street, New York, NY 10017, USA, Tech. Rep.IEEE Std 610.3-1989, 1989.

[16] W. Schutz, “Testing distributed real-time systems: An overview,”Technische Universitat Wien, Institut fur Technische Informatik,Treitlstr. 1-3/182-1, 1040 Vienna, Austria, Research Report12/1995, 1995.

[17] W. Fleisch, T. Ringler, and R. Belschner, “Simulation of appli-cation software for a TTP real-time subsystem,” in EuropeanSimulation Multiconference (ESM), Istanbul, Turkey, June 1997.

[18] T. Galla, “Cluster simulation in time-triggered real-time systems,”Ph.D. dissertation, Technische Universitat Wien, Institut fur Tech-nische Informatik, Treitlstr. 3/3/182-1, 1040 Vienna, Austria, 1999.

[19] R. Pallierer, “Validation of distributed algorithms in time-triggeredsystems by simulation,” Ph.D. dissertation, Technische UniversitatWien, Institut fur Technische Informatik, Treitlstr. 3/3/182-1, 1040Vienna, Austria, 2000.

[20] J. Ehret, “Validation of safety-critical distributed real-timesystems,” Ph.D. dissertation, Technische Universitat Munchen,Fakultat fur Elektrotechnik und Informationstechnik, Arcisstrae 21,80333 Munchen, Germany, 2003.

[21] D. Henriksson, A. Cervin, and K.-E. Arzen, “TrueTime: Real-timecontrol system simulation with MATLAB/Simulink,” in Proceed-ings of the Nordic MATLAB Conference, Copenhagen, Denmark,Oct. 2003.

[22] K. H. K. Kim, “The distributed time-triggered simulation scheme:Core principles and supporting execution engine,” Real-Time Syst.,vol. 26, no. 1, pp. 9–28, 2004.

[23] J. Rushby, “A comparison of bus architectures for safety-criticalembedded systems,” Computer Science Laboratory, SRI Interna-tional, Tech. Rep., Sept. 2001.

[24] Time-Triggered Protocol TTP/C – High Level Specification Docu-ment, TTTech Computertechnik AG, Schonbrunner Strasse 7, A-1040 Vienna, Austria, July 2002.

[25] FlexRay Requirements Specification Version 2.1, FlexRay Consor-tium. BMW AG, DaimlerChrysler AG, General Motors Corpora-tion, Freescale GmbH, Philips GmbH, Robert Bosch GmbH, andVolkswagen AG., Dec. 2005.

[26] H. Kopetz, Real-Time Systems, Design Principles for DistributedEmbedded Applications. Boston, Dordrecht, London: KluwerAcademic Publishers, 1997.

[27] FlexRay Communications System Protocol Specification Version2.1, FlexRay Consortium. BMW AG, DaimlerChrysler AG, Gen-eral Motors Corporation, Freescale GmbH, Philips GmbH, RobertBosch GmbH, and Volkswagen AG., May 2005.

[28] TTP/C Controller C2 Controller-Host Interface Description Doc-ument, Protocol Version 2.1, TTTech Computertechnik AG,Schonbrunner Strasse 7, A-1040 Vienna, Austria, Nov. 2002.

[29] Freescale Semiconductor, “MFR4200 datasheet FlexRay commu-nication controllers,” Tech. Rep., Aug. 2005.

[30] ATIS Committee T1A1, American National Standards Insti-tute, Inc, “Telecom glossary 2000,” Feb. 2001, available athttp://http://www.atis.org/tg2k/.

[31] R. Obermaisser and B. Huber, “Model-based design of the com-munication system in an integrated architecture,” in Proceedingsof the 18th International Conference on Parallel and DistributedComputing and Systems (PDCS 2006), Dallas, USA, Nov. 2006,pp. 96–107.

[32] W. Herzner, B. Huber, A. Balogh, and G. Csertan, “The DECOStool-chain: Model-based development of distributed embeddedsafety-critical real-time systems,” DECOS/ERCIM Workshop onDependable Embedded Systems at SAFECOMP 2006, Gdansk,Poland, Sep. 2006.