Rapid Specification of Hardware-in-the-Loop TestSystems in the Automotive Domain Based on theElectric / Electronic Architecture Description of

VehiclesMartin Hillenbrand∗, Matthias Heinz∗, Klaus D. Muller-Glaser∗

∗Institute for Information Processing Technology (ITIV)Karlsruhe Institute of Technology (KIT), Karlsruhe, Germany

Email: {hillenbrand, heinz, klaus.mueller-glaser}@kit.edu

Abstract—The fast growth of complexity of modern cars,motorbikes and commercial vehicles continues. Although thenumber of applied Electronic Control Units (ECUs) decreases[1], they have to fulfill more and more functions concerning per-formance, comfort and safety [2], [3]. The electric and electronicarchitecture (EEA) of a vehicle forms the basis for those featuresand functionalities. An elaborated and evaluated EEA is devel-oped in the concept phases of the vehicle development lifecycle.For a short time, the tool PREEvision offers the possibilitiesto model EEAs considering different views to the architecture(requirements, software, hardware, wiring harness, topology,etc.). For test and evaluation of the vehicle’s functionalities,Hardware in the Loop (HiL) technology is utilized to cover theintegration phase of hardware and software. The specificationand design of HiL test systems (HiL-TS) is a complex andtime-consuming procedure that can be supported by informationabout electric and electronic artifacts and their relationship, bothavailable in the EEA model. This paper presents an approachfor rapid specification, development and application of HiL-TSsas well as rapidly prototyping systems.

I. INTRODUCTION

Modern vehicles form a complex system of systems inthe domains of functionalities, functions, control units andcommunication networks. The required functionalities of thevehicle (comfort, performance, safety, etc.) are realized by anetwork of intercommunicating functions. These functions arecomputed by a distributed control system of sensors, actuatorsand electronic control units (ECU). A complex network of bussystems and point-to-point connections realizes the intercom-munication between the hardware elements of the distributedcontrol system.

Testing hardware and software of the vehicle’s controlsystem is mandatory to ensure functional correctness and toverify the satisfaction of all requirements.

During the integration phase of software and hardware, HiLtechnology is used to perform reproducible and resilient testsof the functions realized by parts of the distributed controlsystem of the vehicle under development [2].

PREEvision, a new tool for modeling and evaluating theelectric and electronic architecture of a vehicle, has been de-veloped in cooperation with Daimler, the FZI (Forschungszen-

trum Informatik) and the ITIV (Institute for InformationProcessing Technology). An EEA model holds formalizedfunctional and structural information.

Several engineers (HiL specification, HiL integration, HiLoperation, test design, ECU specification, ECU integration,etc.) are, or can be involved in the specification and structuralsetup of a HiL-TS. The increasing complexity of ECUsrequires adequate test systems to verify specification com-pliance. A HiL-TS, not well disengaged, cannot contributeto the evidence that proves the correct implementation andfunctionality of a control unit. We need tool support to deriverelevant information for the specification and setup of a HiL-TS, to accelerate the development process while minimizingspecification failures.

As the EEA development is an iterative process, the EEAmodel can change retroactively. This also affects the specifi-cation HiL-TSs to verify the modeled and later implementedparts of the vehicle control system.

The methodology, depicted in this paper, allows a seamlessand rapid transition from EEA modeling to the set up ofhardware-in-the-loop test systems.

An overview of state of the art automotive testing with theapplication of HiL technology is presented in the followingchapter. Chapter III presents the modeling of EE architectures.Chapter IV introduces the procedure for rapid collection andformal presentation of relevant data from the EEA modelregarding development and specification of a HiL-TS. ChapterV describes the realization of this procedure. Chapter VIsummarizes the work and gives an outlook on further activities.

II. HARDWARE-IN-THE-LOOP TESTING

A. Hardware-in-the-Loop Test Systems

During the integration phase of the vehicle development,ECUs are tested against emulations of their electrical andfunctional environment for verification. This environment isrealized by a HiL-TS.

A HiL-TS consists of hardware and software components,whose elements can be categorized in different layers, depict-ing hardware and software parts Fig. 1. The control PC (testing

host) manages test execution and result analysis. The HiL-TS is composed as follows. A real time computer executesthe simulation of the functional environment (SFE). The IO-generation produces vehicle specific electric signals like digitaland analog IOs as well as datagram based communication likeCAN or FlexRay. The signal conditioning (SC) realizes theelectrical requirements at the connection to the system undertest (SUT). The fault insertion unit inserts electrical faultslike short circuits or open loads. A dedicated wiring harnessconnects the HiL-TS with the SUT. The HiL-TS software(simulation of the functional environment (SFE)) containsan executable model (simulation) representing the functionalbehavior of the environment of the SUT and a signal poolrepresenting the actual state of the executable model as wellas actual values of signals communicated with the SUT.

Functio

nal Layer

Basic 

SW 

Layer

Hardw

are 

Layer

ApplicationApplication

AnalysisAnalysis

Executable Test 

Description

Executable Test 

DescriptionSignal PoolSignal Pool

Host‐Com

AlgorithmAlgorithm

Simulation

Physical 

Layer

ECU Basic Software

Routing Layer

ECU Hardware

Signal Conditioning

Fault Insertion Unit

IO Generation

Operating System

PC‐IF

Computation Unit

HiL‐ Software

PC Hardware

Test Software

Testing HostHiL‐Test SystemSystem under Test

Fig. 1. HiL-TS Composition

As depicted in Fig. 1, in a HiL setup, a real world compo-nent (SUT) is connected to a simulated environment, whichhas to emulate the electrical interfaces of the SUT as well asto simulate the functional environment. Thereby, the behaviorof the SUT can be observed. In rapid prototyping (RP), asimulation platform is connected to a real world environmentto investigate the impact of the simulation to the environment.Comparing HiL- and RP-methodologies discloses their sim-ilarity; only the roles of real world devices and simulationchanges and therewith the perspective to the participatingcomponents.

HiL-TSs are applied at different stages of expansions and fordifferent purposes, two of which are described in the followingpassage.

In a component HiL-TS, a single ECU is connected to theHiL-TS (Fig. 1), which realizes the functional, electrical andelectronical environment of the ECU.

At an original equipment manufacturer (OEM) test site,almost all ECUs, which participate in the same bus system(power train CAN, etc.), are connected to a so-called integra-tion HiL-TS. ECUs, which are not yet available, can therebybe emulated by the HiL-TS. Each wire between the real ECUsare routed through the HiL-TS to observe waveforms, insertelectrical faults, manipulate signals or feed in output data from

emulated sensors to set a defined state of the environment.With 20 or more ECUs on a single bus system, computationand hardware effort of integration HiL-TSs are enormous. Theindividually designed wiring harness, which connects ECUs,sensors and actuators with the HiL-TS, counts up to severalthousand wires. Signal conditioning units, fault insertion units,and real time computers are usually rack mounted. Not rarely,more than five head-high racks contain the named componentsof a HiL-TS. Hardware-only costs for such HiL-TSs oftenexceed 500.000 Euro.

B. Specification of HiL Test Systems

State of the art, HiL-TSs are designed and specified manu-ally, based on the specification document of the SUT. This doc-ument describes the functionalities of the SUT in verbal formand UML-diagrams, (timing diagram, sequence diagram). Thepinning of the SUT connectors is presented in form of a list[4]. Electrical properties of pins are either contained in thislist or described in textual form. Due to the fact, that textualdescription is not unambiguous and the specification documentis a ”living document” [5], good communication between theinvolved roles are necessary to gain an appropriate HiL-TSspecification.

Every vehicle production series requires at least one ofthe described integration HiL-TSs and one component testsystem for most of the ECUs of the EEA of the vehicle.This may justify the manual specification and design ofthe HiL-TS. But the enormous amount of design time, thegrowing complexity of the EEA of vehicles and therewith thegrowing complexity of HiL-TSs and the possibilities for designfaults emerging from the manual specification, risingly requireformal description and automation. Just the determination ofthe electric properties of the large number of SUT pins, andtherewith the needed SC modules, needed to connect the realtime computer of the HiL-TS with the SUT, consumes a vastamount of time, which can be minimized by the applicationof our methodology.

The simulation model (SFE), running on the real time com-puter of the HiL-TS, is also individually designed. Althoughthe number of detailed designed and ready to use simulationsub models (transmission, engine, battery, road, etc.) increases,the whole simulation environment for the SUT has to bespecified and designed manually. Often, each frame and signaltransmitted by a bus system or point-to-point wiring has to bemodeled by hand to realize a consistent SFE. This also comesalong with high engineering efforts and costs.

The AUTOSAR consortium proposes a software archi-tecture of hardware dependent and -independent softwaremodules for ECU application, which strongly supports theconstruction of software libraries [6]. This allows the reuse ofbrand specific as well as standardized software modules forthe design and implementation of ECU software. Except forprecisely designed simulation models (engine, transmission,etc.), this approach is not yet facilitated in the domain of HiL-TS development.

III. EEA MODELING

The tool PREEvision [7] facilitates to design, model, com-pare and evaluate the EEA of a vehicle in the system conceptphase [8] of the vehicle development to achieve the optimaloverall costs, based on the architectural decisions for electricand electronic. For the first time, all data of the EEA design isavailable in one model. This facilitates the usage of metrics tomake an assessment of the EEA. The following section givesa short overview about PREEvision.

An EEA model designed in PREEvision is based onthe layered architecture depicted in Fig. 2 [9]. Each layerpictures a modeling view to the EEA. The EEA modelcontains requirements-, software-, hardware- and networking-information, which are represented by artifacts in a modeltree. Artifacts from the model tree can be visualized in one ormore diagram types, each specific to a particular view. Eachdiagram type offers a specific view on the architecture-model,its artifacts and connections (Function Network Diagram (FN),Component Network Diagram (CMP), Schematic Diagram,Wiring Harness Diagram, etc.). Mappings model the relationsbetween artifacts across diagram borders.

ECU 1

ECU 2

ECU 2

ECU 1

RAM

SoftwareCPU

PCB

ROM

ECU 1

Detailed

Detailed

Detailed

Compo

nent 

descrip

tion

Wiring

 harne

ss

Sche

matics

Sensor 1

Sensor 2

ECU 1

ECU 2Fuse BoxGround 

point

Groun

ding

 Co

ncep

t

CompositionSensor 1

Sensor 2

Function Actor 1Actor 2

Branch‐off

Inline connector

Installation space Installation space

Placed in

Segment

Topo

logy

Functio

n ne

twork

Require‐ments

Power distributionNetworking&

Communication

Actor 1

Actor 2

InstallationLocation

InstallationLocation

InstallationLocation

InstallationLocation

InstallationLocation

Placed in

Requirement 1.2 DescriptionRequirement 1.2.1 Description

Requirement 1.2.2 Description

1.21.2.1

1.2.2

Fig. 2. EEA Layered Architecture

EEA models follow an object-oriented approach. Eachartifact of an EEA model is an instance of a specific classdescription. Attributes of these classes as well as relationsare described in the PREEvision metamodel, which containsmore than 500 classes. EEA models, set up during the vehicledevelopment at OEMs contain up to 800.000 artifacts in themodel tree.

Based on an underlying rule- and metamodel, model query

rules can be described and later executed on the EEA modelfor evaluation and consistency check [10]. These rules can alsobe used to browse the EEA model for chains of artifacts witha particular relationship. Model query rules are graphicallydescribed in an appropriate editor (rule diagram). The chainsof artifacts pictured in a model query rule are composed ofclasses from the underlying metamodel as well as the defini-tion of associations, their instances in the EEA model haveto exhibit. The anchor objects of a model query are specifiedby a context block, enabling searches only on artifacts in aspecific context (connected to artifact named ”DCU”, beingdepicted in the diagram named ”powertrain”, etc.) After theexecution of the model query, all instances, which have therelationship required in the model query rule description, areavailable at the output of the model query block in a metricdiagram. Further calculations can be performed based on thisinformation.

A computation block, as the graphical representation ofan editable java source file, is another artifact available inthe metric diagram. Artifacts pictured in the metric diagramcan be connected, representing a dataflow from one block toanother. Based on the results contained in model query blocks,computation blocks can perform calculations, evaluations aswell as text generations.

The results from computation and model query blocks canbe used to automatically generate reports, using a report block.Fig. 3 depicts a metric diagram, representing a combinationof the discussed elements.

‐1

DCM_Driver

SUT‐Context‐1

DCM_Driver::ECUJ1::ComponentSidedConnectorEcuPowerCanSync::ConnectorTypdef34::ComponentSidedPinKl30::SchematicPin

SutPowerConnection

‐1

DCM_Driver::ECUJ1:: ComponentSidedConnectorEcuPowerCanSync::ConnectorTypdef66::ComponentSidedPinKl31:: SchematicPin

SutGroundConnection

‐1

DCM_Driver::ECUJ3:: ComponentSidedConnectorEcuMirrorMotor:: ConnectorTypdef111::ComponentSidedPinHallMirMotHorizDriv_Minus::SchematicPin

SutConventionalConnection

‐1

DCM_Driver::ECUJ2:: ComponentSidedConnectorEcuLin:: ConnectorTypdef58:: ComponentSidedPinLinSupply::SchematicPin

SutBusSystem

‐1

Computation UserPresets

‐‐

Port: result

PreOrganization_SutPowerCon…Language: Java

‐1

Computation UserPresets

‐‐

Port: result

PreOrganizationSutGroundCon…Language: Java

‐1

Computation UserPresets

‐‐

Port: result

PreOrganization_SutConvent…Language: Java

‐1

Computation UserPresets

‐‐

Port: result

PreOrganization_SutBusSystemLanguage: Java

‐1

Computation UserPresets

‐

‐

Port: result

Merge_ConnectionInfoLanguage: Java

‐1

Computation UserPresets

‐‐

Port: result

FileGenerationLanguage: Java

‐1ReprotGen…

‐

‐

‐

‐

‐

‐

Fig. 3. Metric Diagram

A. Provision of SFEs for HiL-TSs

In [11] we presented a method to supply the HiL-TSdevelopment for any SUT with information from the EEAmodel of a vehicle. This allows for rapid development of theHiL-TS hardware as well as the SFE while reducing failuresemerging from wrong interpretations of the SUT specificationdocument or the communication between the involved roles.This was based on a concept of a ”free body” method for the

extraction of data from an EEA model as well as possibilitiesfor the usage of this data for the development of both, software(SFE) and hardware of a HiL-TS. As an example, Fig. 4depicts a simplified component network of a vehicular externalrear view mirror scenario. The ECU, encircled by the dashedline, represents the door control unit (DCU) of the driverdoor. The three ECUs at the right hand side depict an ignitionswitch, a compound named rest of world and the DCU of thepassenger door. The blocks at the left hand side are (fromtop) a switch panel, power supply and several actuators ofthe external rear view mirror (heating, dipping, folding, andadjustment of mirror glass). The following sections present theprocedure of attaining information about the encircled ECU,required for the specification of a component HiL-TS for thisECU.

Adjustment_FunctionDipping_FunctionFolding_FunctionHeating_FunctionSignal_Generation_Mirror_Adj...Signal_Generation_Mirror_Adj...Signal_Generation_Mirror_DippingSignal_Generation_Mirror_FoldingSignal_Generation_Mirror_Heating

DCM_Driver

Signal_Generation_Mirr...Signal_Generation_Mirr...Signal_Generation_Mirr...Signal_Generation_Mirr...Signal_Generation_Mirr...

DCM_Pass

Mirror_Adj_Aq_PrepRead_St_of_Sw_Prep

Contl_Elem_Driver

Electronic_Ignition_...

Electronic_Ignition_Switch

Lock_SystemRest_of_World

Rest_Of_World

Motor_Mirror_Horiz...

Motor_Mirror_Horiz_Driver

Motor_Mirror_Horiz...

Motor_Mirror_Vert_Driver

Motor_Folding

Motor_Fold_Mirror_Driver

Actuator_Dipping

Dipp_Act_Mirror_Driver

Actuator_Heating

Heat_Mirror_Driver

Groundpoint

Fuse Box Left

Fig. 4. Cut Out Method

IV. META MODEL FOR EEA DATA EXTRACTION

This chapter describes details concerning setup and proce-dure of the mentioned data extraction and the formal organiza-tion of the accumulated information, to be used as input datafor the development of a HiL-TS of the DCU.

This requires information about software modules (SFE),hardware elements and relations. The presentation of theextracted information is structured by a specific metamodelderived from the PREEvision EEA metamodel. The text boxesinside components of the depicted component network rep-resent funktions, computed by the particular components. Asubset of 40 metamodel classes were identified and organizedto cover the whole set of information, which is relevant for thespecification of a HiL-TS. Two class diagrams can picture thissubset. One diagram depicts classes and their associations tomodel software dependent information (Fig. 5). The content ofthe other diagram depicts the hardware dependent information(Fig. 6) of the SUT.

A. Data Extraction for HiL-TS Software (SFE)The part of the metamodel containing software dependent

information, enables the modeling of transmissions (frame-

and signal-transmissions), communication input- and output-ports, interfaces implemented by the communication ports,data elements of the interfaces as well as their attributes (datatype, default value, timing information, etc.) and signals asinstances of data elements. It covers information about theconnection realizing the data transfer.

Type and setup of connections (direct wired connection orbus system) as well as the organization of the transferredsignals in frames, the timing information of frames and thelogical interpretation of electrical values like voltage, currentor frequency are available. The central element in the softwarepoint of view to the EEA model is the signal.

‐SendType‐CycleTime

Port Communication Requirement

Abstract Hardware Component

Absstract Function Type

‐Number of Wires

Conventional Connection TypeConventional Connection

Frame Transmission

‐Transceiver Type‐Number of Wires‐Baud Rate‐Max. Frame Length

Bus ConnectionType

Signal Transmission

Required Port Type

Provided Port Type

‐Basic Type‐Number of Elements

Data Element

Actuator Function

Sensor Function

Bus Connection

Actuator Type

‐Bitlength‐Default Vaule‐Data Type‐Unit

Signal

Sensor Type

FunctionFunction Type

Required Port

Provided Port

‐Frame ID‐Length‐Frame Type

Frame

Controller

Interface

Actuator

SensorECU

Fig. 5. Metamodel Depicting Software Aspects

B. Data Extraction for HiL-TS Hardware

Details about the electric and electronic hardware artifacts,the physical communication layer and the power supply net-work (wiring harness) also support the design of the HiL-TShardware. They are structurized in the part of the metamodelcontaining hardware dependent information.

The abstract hardware component, as generalization ofsensor, actuator and ECUs, offers information about oper-ating conditions (voltage, current, cooling, start / stop con-ditions, etc.). Their connectors (ground-, power-, bus- andconventional-connector) indicate the component-sided and thewiring-harness sided connector- and pin-types, the pinning, theused wires and wire types. The central element in the hardwarepoint of view is the schematic pin.

-Max. Voltage-Min. Voltage-Max. Current

Abstract Hardware Component

-Terminal Type

Ground Connection

-Number of Wires

Conventional Connection Type

-Transceiver-Max. Baud Rate-Termination

Bus Connector Type

-Max. Current-Driver Type-Termination

Conventional Connector Type

Wiring Harness Sided Pin Type

-Terminal Type

Power Connection

Component Sided Pin Type

Conventional Connector

Conventional Connection

Wiring Harness Sided Pin

Schematic Connection

-Transceiver Type-Number of Wires-Baud Rate-Max. Frame Length

Bus Connection Type

Component Sided Pin

-Max. Wire Diameter-Min. Wire Diameter-Max. Isol. Diameter-Min. Isol. Diameter-Type of Connection-Male / Female-Max. Current

Pin Type

Schematic Pin Type

Schematic Pin

Power Connector

Bus Connector

Ground Connector

-Number of Pins

Connector Type

Bus Connection

-Diameter-Max. Curr.-Isolation

Wire Type

Connector

ActuatorSensor

Wire

ECU

-Complementary Connector

Fig. 6. Metamodel Depicting Hardware Aspects

C. Presentation Format

Information about the SUT and its surrounding should beextracted from the EEA model. The obtained information hasto be structurized and filed in a way, which allows seamlessand computer aided utilization as well as for modeling andimplementation of the SFE.

Nowadays, the specification of a HiL-TS starts with a listbased organization of all information concerning the SUT-connection, -pinning and -pin description. The XLS (MicrosoftExcel) file format is used to display and edit the specificationdata for a HiL-TS [4].

At OEMs and tier one supplier, including the suppliersof HiL-TSs, a trend towards model-based design could beregarded, especially for comfort dependent functions [12].To gain compatibility with succeeding tools, the extractedinformation from the EEA model is presented in the XMLformat.

V. REALIZATION

The data extraction process begins with the identificationof a minimal cover of model artifact chains, containing allthe required information. These chains are specified as modelquery rules, based on the metamodel presented in chapter IV.In our example, the extraction should browse for data, relevantfor specifying a HiL-TS for the DCU. All model query rulesstart generally at an ECU. Using a model context block inthe metric diagram (left-most block in Fig. 3), containing theDCU, supplies the model query rules with this particular startobject.

A. Set Up of Data Extraction

A model query rule chain only allows to model sequentionalAND connections between chain links. The modeling ofalternative links is not supported. To gain total coverage ofthe relevant information discussed in chapter IV, the defini-tion of twelve independent rules is necessary. Four of thembrowse for the connections of the SUT (ground-, power-, conventional- and bus-connection). The determination ofsignal-transmissions and frame-transmissions communicated,with other ECUs via bussystems, require another four rules.Two rules browse for signal-transmissions communicated withother ECUs via point-to-point wired connections. Anothertwo rules are needed to determine the signal transmissionscommunicated with sensors and actuators. Each rule browsesthe model for chains containing about 20 artifacts, bearing adistinct relationship. An example for a graphically modeledrule is given in Fig. 7.

source :ECU ConventionalConnectorSUT :

ConventionalConnection :

ConvConnectorTypeSFE :

ConvConType :

ConventionalConnectorSFE :

EeComponentSFE :

SignalTransmission :

InterfaceAssignment :

SenderReceiverInterface :DataElement :

InformationUnitSignalMapping :

Signal :

PPortTransmissionMapping :ProvidedPort :

PortPrototype :

SensorBlock :

SensorBlockMapping :

*

*

*

*

*

ports

* *

*

*

*

*

*

*

* *

Fig. 7. Model Query Rule Diagram

In the depiction of the metric diagram, a succeeding metricblock reads the result of each rule. This metric block formatsthe input data according to a predefined structure and storesthe information in an XML-file. Another succeeding metricblock reads all previously generated XML-files and mergesthem into a single file, containing all information from theperformed queries (Fig. 3). Each artifact returned from a modelquery rule, represents an element in the XML format. Duringthe merge, redundant artifacts and information about theseartifacts are determined and erased based on their uniqueID. The result is a single XML file, containing all relevantinformation, usefully formatted towards HiL-TS specification.

Files, containing the relevant information for differentECUs, can be generated at once, defining different ECUs asstart nodes in context blocks for the applied model query rules.

In an integration HiL-TS, all wire-based connections be-tween all ECUs-under-test are routed over the HiL-TS. Thetracking of frames and signals communicated over these wiresrequires additional information. A metric block, succeedingto the previously described, merges all previously generatedXML-files into single file, containing all extracted informationfrom the EEA model, and therewith supporting the specifica-tion of an integration HiL-TS.

B. Test

The implementation was tested on the complete model ofthe external rear view mirror, described in chapter III. Theprocedure of data extraction and file generation for a singleECU (DCU of driver door) takes about 4 seconds on an actualPC with dual core processor. The generated XML-file containsabout 1000 elements and attributes. The procedure for twoECUs (DCU of driver door and DCU of passenger door) takesabout 5 seconds on the same PC, generating a final XML-filecontaining about 1400 elements and attributes.

VI. SUMMARY AND OUTLOOK

The general procedure and usability of supporting thespecification and design of HiL-TSs and SFEs by informationbased on the EEA model of a vehicle was prior discussedin [11]. In this paper we described the detailed procedure ofidentification and accumulation of relevant information out ofthe EEA model and the organization, presentation and storageof this data for further specification of HiL-TSs.

All PREEvision EEA models base on the same metamodel.Due to the fact, that the presented approach utilizes modelquery chains, based on the PREEvision metamodel, it canbe applied independently from modeling guidelines. So theprocess from determining the SUT, till the finished generationof the output files, takes only a few seconds. This makes themethod very feasible in cases the EEA model changes and aseamless integration of modifications, concerning the HiL-TShardware or the SFE, into the TS development is required forrapid and on time provision of HiL test systems. The procedureof data extraction and formatting was evaluated on the com-pletely detailed EEA model of a vehicular system. Comparedto the manual determination of this data out of specificationdocuments or communication between the roles involved inthe HiL-TS specification and setup, the computation time ofthe procedure with of several seconds is disappearing. Andit obviates the possibility of design failures caused by wronginterpretation or transfer of information.

Further research activities will focus on the seamless inte-gration of the derived information into the development anddesign flow for HiL-TSs.

REFERENCES

[1] H. Lau, H.-J. Pahl, C. Blume, C. Klomke, S. Anderlik, P. Voss, andA. Koblitz, “Der vw polo v,” ATZextra, 2009.

[2] E. Sax, Automatisiertes Testen eingebetteter Systeme in der Automobilin-dustrie. Carl Hanser Verlag, 2008.

[3] J. Bortolazzi, “Lecture Systems Engineering for Automotive Electron-ics,” Institute for Information Processing Technology (ITIV), KarlsruheInstitute of Technology (KIT), Tech. Rep., 2009.

[4] S. Fuchs and E. Sax, “Automatisierte Konfiguration von HiL-Prufstanden,” in auto test, 2008.

[5] K. D. Muller-Glaser and M. Hillenbrand, “Systems and SoftwareEngineering,” Institute for Information Processing Technology (ITIV),Karlsruhe Institute of Technology (KIT), Lecture Notes, 2009.

[6] AUTOSAR, “Technical Overview, Document Version 2.2.2, Part ofRelease 3.1,” Autosar Consortium, www.autosar.org, Tech. Rep., 2008.

[7] aquintos, “EE-Architekturwerkzeug PREEvision,” aquintos GmbH,www.aquintos.com, Tech. Rep., 2009.

[8] Industrieanlagen-Betriebsgesellschaft mbH, “V-modell’97,” iABG,www.v-modell.iabg.de, Tech. Rep., 1997.

[9] J. Matheis, D. Gebauer, C. Reichmann, and K. D. Muller-Glaser,“Ganzheitliche abstraktionsebenenubergreifende Beschreibung konsis-tenter Elektrik/Elektronik-Architekturen,” in Systems Engineering In-frastructure Conferende Seisconf, 2008.

[10] D. Gebauer, J. Matheis, C. Reichmann, and K. D. Muller-Glaser, “Ebenenubertreifende, variantengerechte Beschreibung vonElektrik/Elektronik-Architekturen,” in Diagnose in mechatronischenFahrzeugsystemen, vol. Haus der Technik Fachbuch. Expert-VerlagGmbH, 2008, pp. 142–151.

[11] M. Hillenbrand and K. Muller-Glaser, “An Approach to Supply Simula-tions of the Functional Environment of ECUs for Hardware-in-the-LoopTest Systems Based on EE-architectures Conform to AUTOSAR,” jun.2009, pp. 188 –195.

[12] J. Friedman, “Matlab/simulink for automotive systems design,” vol. 1,mar. 2006, pp. 1 –2.