a service oriented architecture to couple virtual prototypes with functional...

Fachbereich 4: Informatik EADS Innovation Works

A Service Oriented ArchitectureTo Couple Virtual PrototypesWith Functional Simulations

Diplomarbeitzur Erlangung des Grades eines Diplom-Informatikers

im Studiengang Computervisualistik

vorgelegt von

Marcus Berlage

Erstgutachter: Prof. Dr.-Ing. Stefan Muller(Institut fur Computervisualistik, AG Computergraphik)

Zweitgutachter: Dipl. Inf. Rene SchubotzEuropean Aeronautic Defence and Space Company

Koblenz, im August 2010

Erklarung

Ich versichere, dass ich die vorliegende Arbeit selbstandig verfasst und keineanderen als die angegebenen Quellen und Hilfsmittel benutzt habe.

Ja Nein

Mit der Einstellung der Arbeit in die Bibliothek bin ich einverstanden. � �

Der Veroffentlichung dieser Arbeit im Internet stimme ich zu. � �

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .(Ort, Datum) (Unterschrift)

0

Abstracts

Zusammenfassung

Mit Hilfe von virtuellen Prototypen werden Untersuchungen anProdukten, die sich noch in der Entwurfsphase befinden, vorgenom-men. Diese Arbeit stellt einen Ansatz vor, mit dessen Hilfefunktionales Verhalten und die daraus resultierenden Beziehun-gen zwischen funktionalen Objekten in virtuellen Prototypendargestellt werden. Zu diesem Zweck wird eine Service Orien-tierte Architektur entwickelt, um eine VR Software mit funk-tionalen Simulationen bidirektional zu koppeln. Die Kommu-nikation zwischen den voneinander unabhaengigen Systemen wirdvon BPEL Prozessen orchestriert. Diese rufen die bereitgestell-ten Web Service Operationen auf und koennen zusaetzlich genutztwerden, um selber funktionales Verhalten zu simulieren. Zusaet-zlich wird eine grapische Benutzeroberflaeche bereitgestellt, umSzeneobjekte mit der Simulation ihres funktionalen Verhaltenszu verbinden und die erstellten Verbindungen zu verwalten.

Abstract

Virtual Prototypes are often used to test products which are stillbeing developed and do not exist as real objects. This work isaiming to improve and enhance Virtual Prototypes by addingfunctional behaviour to the prototype and by establishing thefunctional relations between objects inside the prototype. A Ser-vice Oriented Architecture is developed to bidirectionally couplethe VR software with functional simulations. BPEL processesare used to orchestrate the communication between the inde-pendent systems. These processes invoke the Web Service oper-ations provided by the systems and can also be used to modelfunctional behaviour themselves. Thus, they can be functionalsimulations themselves. Additionally, a graphical user interfaceis implemeted to allow the user of the VR system to connectscene objects with their simulated functional behaviour and tomanage the connections.

i

CONTENTS CONTENTS

Contents

1 Introduction 1

1.1 Scope of Work . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Basic approach of this work . . . . . . . . . . . . . . . . . . . 3

1.4 Structure of the Work . . . . . . . . . . . . . . . . . . . . . . 3

2 Related Work 5

3 Basic Knowledge for this Work 14

3.1 Virtual Reality . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Business Process Execution Language . . . . . . . . . . . . . 16

3.3 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Requirements 21

4.1 Scenario Description and Stakeholder Analysis . . . . . . . . 21

4.2 Functional Requirements . . . . . . . . . . . . . . . . . . . . . 26

4.3 Technical Requirements . . . . . . . . . . . . . . . . . . . . . 28

4.4 User Interface Requirements . . . . . . . . . . . . . . . . . . . 29

4.5 Quality Requirements . . . . . . . . . . . . . . . . . . . . . . 30

5 Concept 31

5.1 VR System Concept . . . . . . . . . . . . . . . . . . . . . . . 31

5.2 Functional Simulation Concept . . . . . . . . . . . . . . . . . 33

5.3 Communication Concept . . . . . . . . . . . . . . . . . . . . . 35

5.4 General Architecture . . . . . . . . . . . . . . . . . . . . . . . 35

6 Implementation 40

6.1 The VDP Module . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.2 The Connector Node . . . . . . . . . . . . . . . . . . . . . . . 42

6.2.1 Noticing User Interaction . . . . . . . . . . . . . . . . 44

6.2.2 Sending Information to the Functional Simulation . . 47

6.2.3 Receiving Information from the Functional Simulation 51

6.3 The Connector Node Manager . . . . . . . . . . . . . . . . . 56

6.4 The Graphical User Interface . . . . . . . . . . . . . . . . . . 61

6.4.1 Designing the Modules Menu . . . . . . . . . . . . . . 61

6.4.2 Implementing the Actions Performed by the Buttons . 63

6.4.3 Handling Listener Events . . . . . . . . . . . . . . . . 65

6.4.4 Constructing the Module and its User Interface . . . . 66

6.5 The Functional Object . . . . . . . . . . . . . . . . . . . . . . 67

6.6 The BPEL Processes . . . . . . . . . . . . . . . . . . . . . . . 70

iii

CONTENTS CONTENTS

7 Deployment of the Module 747.1 User Guide for the Module . . . . . . . . . . . . . . . . . . . 747.2 Extending the Module to Incorporate New Processes . . . . . 78

8 Results and Validation 81

9 Conclusion 85

Bibliography 87

Table of Figures 90

List of Tables 92

Listings 93

iv

CONTENTS CONTENTS

List of Abbreviations

Abbreviation Meaning

ALiSS Assembly Line Solution SetAPI Application Programming Interface

BPEL Business Process Execution LanguageBPM Business Process ManagmentCAD Computer Aided DesignDLL Dynamic Link LibraryDMU Digital Mock-UpEADS European Aeronautic Defence and Space CompanyFBB Functional Building Block

FDMU Functional Digital Mock-UpFTP File Transfer Protocol

FURPS Functionality, Usability, Reliability, Performance, SupportabilityGMTL Generic Math Template Library

GUI Graphical User InterfaceHOTAS Hands ON Throttle And StickHTTP Hypertext Transfer ProtocolIEEE Institute of Electrical and Electronics EngineersJBI JAVA Business IntegrationLAN Local Area Network

OASIS Organisation for the Advancement of Structured Information StandardsODE Orchestration Director EngineRPC Remote Procedure CallSLX Simulation Language with Extensibility

SMTP Simple Mail Transfer ProtocolSOA Service Oriented Architecture

SysML Systems Modeling LanguageTCP/IP Transmission Control Protocol / Internet Protocol

UML Unified Modeling LanguageURL Uniform Resource LocatorVDP Visual Decision PlatformVDT Virtual Development and Training PlatformVP Virtual Prototype resp. Virtual PrototypingVR Virtual Reality

W3C World Wide Web ConsortiumWS-I Web Service Interoperability Organisation

WSDL Web Service Description LanguageX3D Extensible 3DXML Extensible Markup Language

v

1 Introduction

1.1 Scope of Work

The work presented herein is set in the context of the research project

AVILUS 1. AVILUS is a project under the management of the Innovation

Alliance for Virtual Technologies (IA VT) and is sponsored by the German

Federal Ministry of Education and Research (BMBF) with a total of 28

partners involved in the project. Several leading major companies accompa-

nied by medium sized enterprises and research facilities are joined together

in this project and have set themselves the goal to develop and test new

technologies in the field of virtual and augmented reality. The use cases for

industrial application of the technologies are provided by the key industries

from the sector of automotive and aeronautical engineering as well as from

the field of plant engineering. One of the focuses of the AVILUS project

is to enable a manufacturer to test his product designs in the context of

human interaction and perception. By using the potentials that reside in

the use of virtual technology it will be possible to evaluate a product at

all stages of the development process and thus integrate the human factor

and the role of the future user right from the beginning. The high level of

immersion provided by the use of virtual and augmented reality results in

a reliable source for studies on user friendliness and functional correctness

without having to actually build the product. The aforementioned method

to test and study a product, which until this point in time does not exist

as a real object, is called Virtual Prototyping (VP). In the field of so called

Virtual Prototyping Digital Mock-Up (DMU) is the keyword for innova-tive product development processes (Bullinger et al., 1999).

This thesis is aiming to improve and enhance Virtual Prototypes, here-inafter refered to as VP’s, by adding additional functionality to theVirtual Prototype. Virtual Prototypes are artificial, respectively vir-tual environments created for testing purposes. In the automotive andaeronautical engineering sector, VP’s are utilized to perform ergonomi-cal tests on products that are currently being developed. Since buildinga real-life model for every design step or modification of the product isexpensive both in cost and time, a less complicated tool for experimentsis needed. When building a Virtual Prototype, it is often possible touse the data and specs that are already available from the engineeringand design process, the technical drawings, or design studies. Moderndesign tools like 3D Studio Max, Maya, CATIA and other 3D modelingor CAD software are currently widely used in the field of engineeringand the files created by them can play an important role in the efforts

1http://www.avilus.de

http://www.avilus.de

1 Introduction

to build a Virtual Prototype. The use case scenario for this thesis willbe the industrial application of the Virtual Prototype to evaluate andverify concepts for aircraft designs. In this scenario, the VP must beable to offer realistic behavior and technical features and display cer-tain system configurations in a cockpit. All these attributes can thenbe examined with respect to Human-Computer-Interaction.

1.2 Motivation

The use of functional and visual simulation for the purpose of earlyevaluation and system tests is presently a common practice. Connect-ing the two up until now independently used tools on the other handis not bussiness as usual and is promissing to lead to some interestingfields of application.

• The visual simulation would gain additional sources for input asthe functional simulation would send state changes that can behandled by the simulation. No longer would it be limited in itsdepicted strings of actions by previously specified storylines thatresult in a plotline of animations. Developers responsible for thevisual simulation could use events coming from the functionalsimulation as input and connect this input to events in the 3Denvironment.

• To be able to work with both simulations - the functional andthe visual simulations - and deploy them, quite some trainingis required. The skills that are necessary to build a functionalsimulation cannot be applied to create a virtual environment andvice versa. They are used for different test scenarios and areconstructed by people who come from different fields of expertise.To combine the two separate simulations into one tool would onlycomplicate the work involved in building the simulation. If itwould be possible to connect the two simulations with a tool thatonly requires minimum training, and thus maintain and guaranteethe separation of concerns, this complication could be avoided.

• Another factor that is not considered in this work but might beinteresting to look at is related to the functional simulation. Onthe side of the functional simulation the benefits could be thatinput data can be acquired from a natural environment with re-alistic handling. Test cases which haven’t been thought of beforecould arise from real situations. Additionally, the control mecha-nisms for the tests performed with the functional simulation would

1.3 Basic approach of this work page 3

be quite intuitive and even persons who are new to the field offunctional simulation or who have no technical background couldeasily perform the tests.

As a consequence both simulations can make a step closer to the realitythey are supposed to represent and gain a level of depth by being con-nected. Also, the efforts necessary to build a visual representation ofa complex system would be lessened because the functional simulationcan manage all the state changes.In this work, a bidirectional coupling of a functional simulation witha visual simulation is developed to show the benefits and synergy.The visual simulation is provided by IC:IDOs Visual Decision Plat-form (VDP) and a simple functional simulation is installed with theuse of the Business Process Execution Language (BPEL)2. All commu-nication will by handled by Web Services with the use of SOAP3.

1.3 Basic approach of this work

By building a module for the software Visual Decision Platform (VDP)by IC:IDO4 the aim is to utilize functional simulations to equip the VRsystem with new features and possible applications. This module mustenable the user of the VDP software to connect objects from his virtualscene directly to any kind of simulation that offers a two-way commu-nication via Web Services and with a little workaround even with somesimulations that just offer a web interface for communication. As anexample for a possible application of this concept different types ofswitches and control systems inside a jet cockpit will be connected toa functional simulation. If those controls are used in the virtual en-vironment, say a push-button was pressed, this event will be send tothe functional simulation. The functional simulation then will send amessage back to the virtual environment and order a previously spec-ified scene object to react accordingly. This reaction can be a texturechange, a rotation or a translation of a scene object.

1.4 Structure of the Work

In the following section the solutions suggested in papers which arerelated to this work are presented and analysed. After this the fun-damentals and principles of the used tools and methods are explained

2http://www.oasis-open.org/committees/wsbpel/3http://www.w3.org/TR/soap/4http://www.icido.de

http://www.oasis-open.org/committees/wsbpel/

http://www.w3.org/TR/soap/

http://www.icido.de

1 Introduction

briefly. A short introduction to virtual reality and the correspondingtechnologies is offered, followed by BPEL, which is used for the part ofthe functional simulation. Web Services and SOAP, which are used forthe communication between the functional simulation and the virtualenvironment, are explained next. The next section describes the sce-narios which need to be considered in this work and the requirementsthis solution has to meet. By using the results from the requirements,the concept - developed during the course of this work - is outlined andthe software achitecture that emerged from this concept is described.In the section considering the implementation of the framework de-veloped in this work, these concepts and the architecture are used todevelop the components of the VDP module. The deployment of thismodule and the steps necessary to extend the module to incorporatenew functional behaviour are described in the next section. This isfollowed by a retrospective on the requirements, the concept and theimplementation, to validate the quality and usefulness of the approachpresented in this work. In the last section, the conclusion of this workis presented and possible extensions for the solution are suggested.

2 Related Work

The focus of this work lies in a specific type of computer simulation inthe area of development and testing. This type of simulation is calledVirtual Prototyping. This term is often used in different meanings asWang and Professor (2008) stated in his article ”Definition and Reviewof Virtual Prototyping”. In this article, he defines a Virtual Prototypeor Digital Mock-Up as follows:Virtual prototype, or digital mock-up, is a computer simulation of aphysical product that can be presented, analysed, and tested from con-cerned product life-cycle aspects such as design/engineering, manufac-turing, service, and recycling as if on a real physical model. The con-struction and testing of a Virtual Prototype is called virtual prototyping(VP) (Wang and Professor, 2008). It is important to mention that theproposed definition implies the importance of human-product interac-tion (Wang and Professor, 2008).At EADS Innovation Works the terms Digital Mock-Up and VirtualPrototype are defined differently. A Digital Mock-Up is considered tobe a digital model of a product that is developed. The model containsall relevant information related to that product, like the CAD-files thatdescribe the product’s geometry, but also cost analysis models, lifecycledata, clash analysis, and much more information. A Virtual Prototypeis defined as a way to analyse certain aspects of a product like visibility,ergonomical aspects, aesthetic aspects and others by utilizing methodsfrom the field of computer graphics. When using the terms DigitalMock-Up or Virtual Prototype in this work, the definitions stated byEADS Innovation Works are applied. Another important aspect ofthis work is the bidirectional coupling of a functional simulation and avirtual reality system (or graphical simulation). This aspect has beenaddressed by a number of scientific publications.

In his paper ”Integrating Operations Simulation Results with an Im-mersive Virtual Reality Environment” Rehn et al. (2004) presents aconcept to combine an operations simulation with a virtual reality sys-tem. The operations simulation system ALiSS, Assembly Line SolutionSet, developed by Deere & Company in the early 2000s is used for theindustrial application of simulating manufacturing operations in a fac-tory. The simulation system was built using two commerical simulationsoftware packages, SLX5 and Proof Animation6, both by the Wolver-ine Software Corporation. Proof Animation - responsible for the visual

5http://www.wolverinesoftware.com/SLXOverview.htm6http://www.wolverinesoftware.com/ProofProducts.htm

http://www.wolverinesoftware.com/SLXOverview.htm

http://www.wolverinesoftware.com/ProofProducts.htm

2 Related Work

simulation - only provided a visual representation of the simulated pro-cess for a standard 2D output on a monitor. To allow the use of animmersive virtual reality environment for testing and training purposes,all relevant information from the SLX package had to be extracted andthen made available to the virtual reality simulation program. For thispurpose a SLX module was developed and integrated into ALiSS. Toexchange the information between the two simulations, a standaloneASCII file, also refered to as VRF file, was used. A virtual realitysimulation program was then developed using the SGI OpenGL Per-former7 to create the scene objects and the VRJuggler8 software libraryto manage the environment. The program consists of four components:

• A graphics module to create and depict the 3D scene objects inthe virtual environment.

• A data processing module to interpret the VRF file containing theresults from the operations simulation ALiSS and the standardProof Animation layout files.

• A logical module responsible for the behavior of the scene ob-jects, such as the motion of an object, animation of an assemblyoperation and so on.

• An interaction module providing a user interface to control thevirtual reality simulation, to get information about scene objectsand to change the configuration parameters of the simulation.

All events simulated in the operations simulation ALiSS are written tothe VRF file including a timestamp. For every frame rendered by theVR system the VRF file needs to be examined for new events. Theclose coupling of the two simulations causes significant performanceissues. During initial development stages of the application we haveexperienced frame rates as low as one frame per second (Rehn et al.,2004). To resolve this issue the total number of polygons simultane-ously rendered by the system had to be decreased (Rehn et al., 2004).To synchronise the two independent but closely linked simulations, thetime elapsed during the rendering of a frame is used to compute thecurrent simulation time, which then will be used as a reference valuefor accessing the events stored in the VRF file.The concept introduced by Rehn et al. (2004) shows the problems thatreside in the close coupling of a functional simulation with a VR Sys-tem. To combine both of them into one system significantly effects the

7http://oss.sgi.com/projects/performer/8http://www.vrjuggler.org/

http://oss.sgi.com/projects/performer/

http://www.vrjuggler.org/

performance of both, but especially the performance of the VR system.The main arguments for the use of virtual reality are the effects on theuser caused by the sensation of immersion into a virtual environment.If the immersion into the virtual environment is prevented, becausethe system cannot display events in real time, the frame rate is too lowor the scene objects are only rudimentarily depicted, the use of a VRsystem seems to be futile.

Another paper on the subject of coupling discrete simulation and vir-tual reality systems also aims at the use of this approach for testingdesigns and providing new training methods in the context of plantengineering. With a focus on the necessary synchronisation of the twoindependent systems Strassburger et al. (2005) presents another so-lution with an application in the field of production, manufacturingand logistics. In his paper different methods for synchronisation areevaluated and a suitable solution for the approach of coupling simu-lations is presented with the method of the self-adapting buffer sizes.The adaptive buffer strategy controls the buffer size as a function ofthe visualization speed. If the visualization speed increases, the buffersize also increases autonomously(Strassburger et al., 2005). To test thesolution, the simulation system SLX is used for the part of the func-tional simulation, while with the Virtual Development and TrainingPlatform9 (VDT) and VRJuggler, two different VR systems are used.All three systems are extended with modules to implement the couplingand the suggested method of the self-adapting buffer size is applied inthe component of the VR systems.

• A communication unit is responsible for the sending and receivingof messages and commands exchanged between systems.

• A managment unit is responsible for integrating the received mes-sages into the respective system and for the controlled release ofoutgoing messages to the other system (Strassburger et al., 2005).

The messages are sent in a specific format, which is not further ex-plained in the paper, and the transport protocol used to transmit themessages is TCP/IP. In the client-server-architecture implemented forthe pilot project, the functional simulation takes the part of the serverwhich sends the visualization data to the VR system if requested by it.Only the synchronisation method introduced in this work was consid-ered for the concept developed in this work. The architecture and the

9http://www.iff.fraunhofer.de/de/iffdbde/Produkt_detail.php?ProduktId=41

http://www.iff.fraunhofer.de/de/iffdbde/Produkt_detail.php?ProduktId=41

http://www.iff.fraunhofer.de/de/iffdbde/Produkt_detail.php?ProduktId=41

2 Related Work

communication method were not described in detail and thus could notbe evaluated. Just like Rehn et al. (2004), Strassburger et al. (2005)uses the VR system as a sort of graphical user interface for the func-tional simulation. This approach is not suitable with the motivation forthis work, where the aim is to extend the possibilities of a VR systemby bidirectionally coupling it with one or more functional simulations.

Similar to the work of Strassburger et al. (2005), Mueck et al. (2002) de-scribed a solution to the problem of bidirectionally coupling a discretesimulation with a walkthrough system. His work also has a strong fo-cus on finding a synchronisation method which best suits this scenario.The architecture of the system consists of the commercial manufactur-ing simulation tool EM-Plant10, a coupling module and a walkthroughsystem; the latter were both developed for the prototype. For the syn-chronisation of the two simulations, the method of Fixed Follow-upTime is implemented. By using the transmission time of the first mes-sage sent from the simulation tool, an estimate for the follow-up timeis found. To make sure that walkthrough system time will not outrunsimulation time, we have added a tiny period ot time t0 as a reserve(Mueck et al., 2002).This paper again focuses primarily on the synchronisation. But againthe technology of virtual reality is only used to create an elaborategraphical user interface for a functional simulation, which does notmatch the aim of this work. The walkthrough system implementedfor the system seems very specific and not suited for tests concerningergonomical or aesthetic aspects of a product.

A current study commisioned by the Fraunhofer Society11 led to thedevelopment of a concept which also uses functional simulations cou-pled with a VR system. For this study Stork et al. (2009) introduceda new term, namely Functional Digital Mock-Up (FDMU). By com-bining different already-existing and widely-used simulation tools, thefunctional aspects can be added and considerably more insight in theproducts properties can be achieved (Stork et al., 2009). The concept ismore complex and elaborate and is aimed at a different scenario thanthis work, but has to be mentioned nonetheless. The FDMU frameworkwill be used for the cooperative development and validation of func-tional prototypes of complex mechatronic products(Stork et al., 2009).To describe these products, the Functional Building Block (FBB) hasbeen developed, which includes a description of the electro-mechanical

10http://www.plant-simulation.com11http://www.igd.fhg.de/igd-a2/fdmu/

http://www.plant-simulation.com

http://www.igd.fhg.de/igd-a2/fdmu/

behavior in the form of a functional model and information about thegeometry of the object in the form of 3D CAD data. A MasterSimu-lator will be responsible for all the communication between the FBBsand the different types of simulations. The different simulations areconnected to the MasterSimulator via FDMU Wrappers who provide acommon interface for communication.Although the FDMU concept has some commonalities with the con-cept that is developed for this work, the extent of the FDMU studyis much bigger and more complex. The focus of this work will be tofind a simple and flexible way to incorporate input from a functionalsimulation into the virtual environment and use the input to triggertransformations or texture changes. The coupling should not result inan increase in the necessary work effort, and the separation of the twoindependet simulation tools must remain.

An important starting point for the development of the concept pre-sented in this paper is a thesis that was just finished shortly before thebeginning of this work. The thesis by Seidel (2009) was also a part ofthe AVILUS research project, had an almost identical task formulationand presented a solution to the problem of coupling a VR system with afunctional simulation. The solution suggested in his thesis is analyisedin the following pages, and it is explained why this concept is not usedany further, as well as why a different approach is chosen.

To address the scenario his system was developed for, Seidel (2009)introduced an XML schema (see figure 1) describing the different typesof switches used in aircraft cockpits. This XML description is usedfor data exchange and can be seen as one of the key elements in hissolution. The description is very extensive and precise to cover ev-ery possible aspect and feature of a switch. One of its purposes is tocreate a common basis for the communication between the differentparticipants involved in the creation of a Virtual Prototype. Theseparticipants are described in more detail in section 4.1. The Designers,Engineers and the VP Developer all contribute to the construction ofthe Virtual Prototype by providing the data used for its construction.All of them use different tools in their development process, which re-sults in a variety of data formats. The XML description is supposed tobe used by all of the persons involved in the development process andby the system itself.

The software architecture is chosen to be a distributed system consist-ing of three components with the XML description as their common

2 Related Work

ID : stringBeschreibung : stringTyp : stringAnzahl Pins : intverriegelt : bool

SchalterID : stringBezeichnung : stringBeschreibung : stringVerriegelungsart : stringVerriegelungsrichtung : stringKontaktdauer : stringDisplayanzeige : stringDisplayinhalt : string

Zustand

1 *

11

aktueller Zustand

in : intout : int

Verbundene Pins

1 0..*

1*

Nachbarzustand

Typ : string

Zubehör

1

0..*

Achse : stringAchsentyp : stringmin : floatmax : float

Geometrische Bedingung

1 1..61

*

Figure 1: UML-diagram with the design for the switch description introduced bySeidel (2009).

data basis and data exchange format. The two main parts, the VRsystem and the functional simulation, are connected over a local areanetwork through the third component, the so-called Mediator. For thepart of the functional simulation, the software Rhapsody12 by Telelogicis used and the VR system consists of the software Visual DecisionPlatform (VDP) by IC:IDO. For the communication between the Me-diator and Rhapsody, an existing web-interface provided by Rhapsodyis used. The VDP is extended with a plugin which uses the XMLdescription as its data exchange format. All the information result-ing from interaction with switches inside the VR system is written tothe XML data and the Mediator is then contacted via a Web Serviceinterface. The Mediator maps the state information from the XMLdescription to a Rhapsody event and sends a message to the Rhapsodyweb-interface to trigger the event in the functional simulation. To getinformation about state changes from the functional simulation, theVDP plugin has to ask the Mediator for an up-to-date XML switchdescription. This method is called polling. The VDP plugin sends arequest to the Mediator which then checks Rhapsody for the presentstates in the simulation, this state is then written to an updated XMLdescription. The VDP plugin receives the result of the request in formof the updated XML file. In figure 2 the complete system as developedby Seidel (2009) can be seen.

The functional simulation Rhapsody is utilized by Seidel (2009) to cre-ate state charts with the use of SysML (see figure 3). To interact with

12http://www.telelogic.com/products/rhapsody/

http://www.telelogic.com/products/rhapsody/

on_lefton_right

off_lockedevToggleRight

evToggleLeft

evToggleLeftevToggleRight

evToggleLeft off_unlocked evToggleRight

evUnlock

Funktionale Simulation(Rhapsody)

Virtuelle Umgebung

(VDP)

Plugin

WebService

CRUD

Adapter

Mediator

WebServer

<switch>

<switch>

Figure 2: software architecture for coupling Rhapsody with the VDP introducedby Seidel (2009).

the system models run by Rhapsody, the events that need to be trig-gered from outside can be configured to be Web Managed. As a result,Rhapsody provides a web interface for communication (see figure 4).To initiate a state change or an event from outside of Rhapsody HTTP-

on_left on_right

off_locked

evToggleRight evToggleLeft

off_unlockedevToggleLeft

evToggleRight

evUnlock

Figure 3: Simulating a toggleswitch in Rhasopy withthe use of SysML

Figure 4: Webinterface provided byRhapsody

GET requests need to be send to Rhapsodys webserver. The three mainHTTP-GET requests as found by Seidel (2009) are listed below. Usingthe example of the state chart for a toggle switch as shown in figure 3the requests related to the issuing of an order for a state change, con-nected to the event that a toggle switch was unlocked, are the following.

• To address the event ToggleSwitch[0]::evUnlock the URL

2 Related Work

/cgibin?Abs_App=GetMibIds&ToggleSwitch[0]::evUnlock=R

is used. As a result of this request the ID for the event evUnlockis returned. This ID can be used to address the event directly.

• To change a variable for a specific object, in this case the eventevUnlock the URL

/cgibin?Abs_App=MibSaveVal&id=5&val=undefined

is called by using the ID returned by the GetMibIds function.This URL is used when the button Activate is pressed in theweb interface 4 shown above.

• The web interface uses the request

/cgibin?Abs_App=Refresh&1=R&tmID=3993393

to get up-to-date values for the objects it is displaying. In thiscase 1 denotes the object ID for the variable current_stateand tmID is a timestamp.

To map events from the VR system to Rhapsody events and thus allowa bidirectional communication, Seidel (2009) designed the Mediatorcomponent. In this Mediator a mapping table is used to retrieve theRhapsody event related to a state change caused by the VR systemand then trigger the HTTP command to update the simulation.Three basic steps have to be performed to build a Virtual Prototype forthis system. First, the functional simulation has to be designed usingRhapsody. Second, the cockpit scene has to be loaded into the VDP.Third the XML description needs to be created. The XML descriptioncan neither be generated by Rhapsody nor by the VDP or its plugin,but has to be written manually. Rhapsody can be controlled over itsbuilt-in web interface and the interaction with objects inside the virtualenvironment serves as the interface for the VDP plugin. The events in-side the VR system that result from state changes in Rhapsody arehardcoded in the plugin and only texture changes are implemented inits current state. If a new functional object which is not already de-cribed by the XML schema and the Rhapsody state charts needs to beintegrated into the cockpit scenario, the Mediator and the XML schemawould have to be extended to regard the features of this object.

The concept developed by Seidel (2009) is not further used becauseit is too static and an expansion of the system would only magnifythe drawbacks of the system. One of the disadvantages is the pollingmechanism which results in unnecessary network traffic. Mapping theswitch description to event calls for Rhapsody is fiddly and awkwardto handle and must be hardcoded in the Mediator for every new sce-nario. Thus Rhapsody is not used as the functional simulation in thiswork. Another method needs to be found to simulate the relationshipof functional objects and the events caused by interactions with them.Finally, the lack of a graphical user interface which can be used toconstruct a Virtual Prototype inside the VDP prevents a user-friendlyinteraction with the system. On account of the very static architec-ture, which only seems to be able to address the very specific scenarioof the switches modeled in the XML description and simulated in theRhapsody state charts, it is necessary to start from scratch and find adifferent approach.

3 Basic Knowledge for this Work


3.1 Virtual Reality

One of the most influential pioneers in the field of virtual reality andvirtual environments certainly is Ivan Sutherland, who laid the groundwork for the development towards virtual reality. His most cited andknown work ”The Ultimate Display” Sutherland (1965) can be seenas the first head-mounted display, although more commonly known as”The Sword of Damocles”due to its immense weight and the fact that ithad to be suspended from the ceiling. The actual term virtual reality orvirtual environment was coined with a great influence by Jaron Lanierin the late 1980s Conn et al. (1989). Lanier, founder of the companyVPL Research established in 1985, continued Sutherlands work withhis company by developing and building the most advanced and influ-ential input and output devices for virtual environments of his time.

The term virtual reality or virtual environment describes an artificalenvironment generated by computers. Key features of virtual enviro-ments are:

• Real Time: Generally any output on a display with significantlyless then 30 frames per second is not perceived as real in the senseof visual peception for the human eye. All reactions to interac-tion inside the environment have to be immediate and movementthrough the simulated space has to seem continuous.

• Interactivity: Interaction with objects in the virtual environ-ment has to be possible and the more intuitive the interaction isperformed, for example with the help of special input devices likefingertracking, the bigger the sense of immersion into the environ-ment gets.

• Immersion: As it has just been mentioned above, immersionis the ultimate goal of virtual environments. The user has tohave the impression of being a part of the virtual environment, tobe involved and immmersed. A famous statement made by IvanSutherland in his article ”The Ultimate Display” is:The ultimate display would, of course, be a room within which thecomputer can control the existence of matter. A chair displayed insuch a room would be good enough to sit in. Handcuffs displayedin such a room would be confining, and a bullet displayed in sucha room would be fatal. (Sutherland, 1965)

3.1 Virtual Reality page 15

• Multimodal Interaction: The term multimodal interaction comesfrom the field of human-computer interaction. Different devicesfor input and output can be used to provide the user of the virtualenvironment with an interface. Aside from the traditional moni-tor, keyboard and mouse setup, other modalities such as speech,tracking of body parts, haptic input and output, head-mounteddisplays or caves, just to name a few, can contribute to the senseof immersion.

To help classify an artificial computer generated environment Prof.Dr. Mueller (2009) of the University of Koblenz introduced a referencemodel in his lecture on the subject of ”Virtual Reality and AugmentedReality” at the University of Koblenz.

Presentation

Interaction

Object Behavior

VRnone

none

static behavior

dynamic behavior

interactive immersive

single event

sequence of events

realtime

Figure 5: Reference Model for Virtual Reality.

As it has already been outlined in the context of virtual reality, a vari-ety of input and output devices can be used. Since these devices do notplay a role in the context of this work they will not be explained in anymore detail. For further, more extensive information on virtual realityand all the related technologies the book ”Understanding Virtual Real-ity: Interface, Application, and Design” by Sherman and Craig (2002)was found to be very useful and complete. In the following the systemconfiguration used to create the virtual environment for the scenario ofthis work will be described.

The software used to depict the cockpit model in a virtual environmentis the Visual Decision Platform (VDP) by IC:IDO. This software offers


a variety of modules, which can be used when building and reviewingthe Virtual Prototype.The system used to run the VDP consists of thefollowing hardware:

• Master Computer for the Cluster: AMD Opteron, DualNVIDIA Quadro 4500, Windows XP 64 Bit.

• 2 Slave Computers for the Cluster: Intel Xeon, NVIDIAQuadro 4800, Windows XP 64 Bit.

• Visual Output Devices: NVIS Head Mounted Display nVisorSX60, or two passive Stereo-Beamer.

• Tracking: ART Tracking consisting of six cameras allowing Fin-gertracking for three respectively five fingers, a Flystick, Hand-targets for left or right hand and multiple free targets.

Furthermore, the virtual environment is accompanied by real objectsinside the lab. These objects are used for haptic feedback, so that theuser doesn’t just touch the air, but feels a resistance where the virtualobjects are supposed to be. The positions of all these objects have tobe aligned with the objects in the virtual environment, so that they areat the same places in both worlds. These real objects used for hapticfeedback are:

• Seat

• HOTAS System: abbreviation for Hands On Throttle AndStick, this represents the flight control stick and the throttle inan aircraft’s cockpit.

• Various Plexiglas Panels: these panels simulate the controlpanels inside the cockpit.

3.2 Business Process Execution Language

The open standard for the Web Services Business Process ExecutionLanguage (WS-BPEL 2.0) is managed by the Organization for the Ad-vancement of Structured Information Standards13 (OASIS) and is arevision of the original BPEL4WS 1.0, which was conceived by IBM,Microsoft and BEA in 2002. The BPEL4WS 1.1 specification was re-leased about a year later, with contributions from SAP and Siebel Sys-tems. At about the same time the BPEL4WS specification was submit-ted to the OASIS committee, to be developed into an open standard.

13http://www.oasis-open.org

http://www.oasis-open.org

3.2 Business Process ExecutionLanguage page 17

This led to the specification of the WS-BPEL 2.0 standard. BPELuses a number of specifications that build the Web Service space, likethe Simple Object Access Protocol (SOAP), the Web Service Descrip-tion Language (WSDL), the Extensible Markup Language (XML), theXML Path Language (XPath) and Universal Description Discovery andIntegration (UDDI) to specify interactions between Web Services. Pro-cesses designed using BPEL do not support user-based interaction, theysolely interact by exporting and importing information via Web Serviceinterfaces. The BPEL4WS 1.1 specification states, that BPEL4WS ismeant to be used to model the behavior of both executable and abstractprocesses (Andrews et al., 2003). An executable business process isused to model the behaviour of a participant in a business-related in-teraction. An abstract business process on the other side describes aprotocol to define the behaviour of the message exchange between theinteracting partners and is hiding the internal behaviour of the par-ticipiants. BPEL4WS provides a language for the formal specificationof business processes and business interaction protocols. By doing so,it extends the Web Services interaction model and enables it to supportbusiness transactions (Andrews et al., 2003). WS-BPEL is a languagewhich can be used to orchestrate Web Service interactions, this meansit can be used to control the message exchange for the communicationof distributed systems. For this purpose the BPEL offers the followingconcepts:

• Partner Link Types, Partner Links and Endpoint References todefine the communication partners, their roles and the specificaddresses used to contact them.

• Variable Properties, so the WS-BPEL process definition manip-ulating a variable can remain unchanged if a variable’s definitionis changed.

• Data Handling for XML data types and WSDL messages. This in-cludes the use of variables for maintaining the states of processes,query and expression languages like XPath 1.0 to control the be-haviour of a process, and data assignment to copy, construct andinsert data.

• Message Correlation to identify and route messages to the correctinstance of a process. This is needed in case conversations involvemore than two parties or use lightweight transport infrastructurewith correlation tokens embedded directly in the application databeing exchanged (Alves et al., 2006).


• Basic and Structured Activities to perfom the process logic. Ba-sic activities are those which describe elemental steps of the pro-cess behavior. Structured activities encode control-flow logic, andtherefore can contain other basic and/or structured activities re-cursively. (Alves et al., 2006) For example the flow activity canbe used for parallel processing.

• Scopes can be used to build a process in a process. These scopescan, for example, be used handle events, errors, message exchange,or the termination of a process.

In this work Apache’s Orchestration Director Engine (ODE) is usedas the Business Process Managment (BPM) engine for the BPEL pro-cesses. It supports a communication layer based on Axis2 for the WebServices HTTP transport and another based on the JAVA BusinessIntegration (JBI) standard.

3.3 Web Services

The World Wide Web Consortium14 (W3C) defines a Web Service as asoftware system designed to support interoperable machine-to-machineinteraction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with theWeb Service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serializationin conjunction with other Web-related standards (W3C, 2004b). WebServices provide application programming interfaces (API), which aredefined using a unique Uniform Resource Identifier (URI), and canbe accessed using the HTTP, and are therefore also called web APIs.The technologies, protocols and architectures used by Web Servicesare submitted to the W3C, so the key objective behind their develop-ment, which is to achieve a high level of interoperability and softwareportability, can be achieved by defining standards. The Web ServicesInteroperability15 (WS-I) organization establishes Best Practises forWeb Service interoperability which have to be considered when imple-menting a Web Service to guarantee interoperability across platforms,operating systems and programming languages. These rules are pub-lished in the so-called ”WS-I Basic Profiles”. Web Services use theSOAP protocol to exchange information between the provider and theconsumer of a service. The interface of a Web Service is described bythe XML-based Web Service Description Language (WSDL), which is

14http://www.w3.org/15http://www.ws-i.org/

http://www.w3.org/

http://www.ws-i.org/

3.4 SOAP page 19

also standardized by the W3C (see Moreau et al. (2006) and Chin-nici et al. (2007). A WSDL document contains definitions for the el-ements (<element>) which are contained in its messages and theirdata types (<types>) and for the messages transmitted by the ser-vice (<message>). The operations (<operation>) provided by theservice to send and/or receive the messages are encapsuled by the defi-nition of the port type respectively the interface (<portType>). Theprotocol and the data format used for the operations and their mes-sages are defined in the binding of the service (<binding>). Finally,the service (<service>) is connected with its port (<port>). Seelisting 7 for an example of a WSDL file. Web Services can be utilizedto connect distribute systems, in this context the design pattern calledService Oriented Architecture (SOA) is often applied.

3.4 SOAP

The SOAP Version 1.2 Part 0:Primer describes SOAP in the followingway. SOAP Version 1.2 provides the definition of the XML-based infor-mation which can be used for exchanging structured and typed informa-tion between peers in a decentralized, distributed environment. SOAPis fundamentally a stateless, one-way message exchange paradigm, butapplications can create more complex interaction patterns (e.g., re-quest/response, request/multiple responses, etc.) by combining suchone-way exchanges with features provided by an underlying protocoland/or application-specific information. SOAP is silent on the se-mantics of any application-specific data it conveys, as it is on issuessuch as the routing of SOAP messages, reliable data transfer, fire-wall traversal, etc. However, SOAP provides the framework by whichapplication-specific information may be conveyed in an extensible man-ner. Also, SOAP provides a full description of the required actionstaken by a SOAP node on receiving a SOAP message. (W3C, 2007)Originally SOAP was short for Simple Object Access Protocol, but thiswas dropped when SOAP became a W3C standard with version 1.2 in2003. SOAP is a specification for a network protocol located in theapplication layer. It uses transport protocols like HTTP, SMTP, FTP,RPC, or others for message transport and negotiation. The messagesconstructed by SOAP are defined in an XML-based structure. Theyconsist of a SOAP envelope with an optional header and a body. Theheader can be used to provide a mechanism for extending a SOAPmessage in a decentralized and modular way (Gudgin et al., 2007). Itcan, for example, contain information that is provided by other ap-plications, like routing tabels or keys for decryption. The body of aSOAP message carries the actual data. An exemplary SOAP message


is provided by listing 1.

1 <?xml version=”1 .0 ”?>2 <soap:Envelope3 xmlns:soap=”h t tp : //www. w3 . org /2003/05/ soap−enve lope ”4 soap : encod ingSty l e=”h t t p : //www. w3 . org /2003/05/ soap−encoding

”>5 <soap:Header>6 </ soap:Header>7 <soap:Body>8 </ soap:Body>9 </ soap:Envelope>

1: Basic structure of a SOAP message.

The envelope is sent inside the body of a HTTP Post request if HTTPis used as the transport protocol. In the case of Web Services, SOAPis utilized to build the Web services protocol stack and provides theframework for the Web Service messages. In this work the SOAP im-plementation for C++, called gSOAP16, is used to automatically con-struct SOAP and XML data bindings. The tools provided by gSOAPuse advanced mapping methods and autocode generation to developWeb Services applications in C and C++. They support the integra-tion of (legacy) C/C++ codes (and other programming languages whena C interface is available), embedded systems, and real-time softwarein SOAP/XML applications that share computational resources and in-formation with other SOAP applications, possibly across different plat-forms, language environments, and disparate organizations located be-hind firewalls (Engelen, 2010).

16http://www.cs.fsu.edu/~engelen/soap.html

http://www.cs.fsu.edu/~engelen/soap.html

4 Requirements

4.1 Scenario Description and Stakeholder Analysis

As it has been outlined in the Introduction 1, the context of this work isVirtual Prototyping. Cockpit designs for helicopters and airplanes needto be reviewed in a virtual environment with regard to ergonomical andfunctional properties. To enable the user of the Virtual Prototype to,for example, push a button and experience a reaction inside the virtualenvironment, say a control light that turns green, the VDP needs to beconnected with a functional simulation. Since the VDP doesn’t offer amodule to connect to any kind of functional simulation, it is necessaryto implement such a module.

The complete system consisting of the virtual environment, the func-tional simulation and of course the module itself concerns a number ofpeople from different areas of work. To get a sense of what the moduleneeds to be able to do, first all the participants have to be identified.

• Test Pilot: The most obvious participant is of course the personinteracting with the simulated objects inside the virtual environ-ment. This person will hereinafter be referred to as the Test Pilot.The Test Pilot will experience the effects of the coupling of thevirtual environment with the functional simulation, because in-teractions with objects inside the virtual environment will resultin the appropriate predefined event.

• VP Developer: Before the Test Pilot can use the system, theVirtual Prototype has to be build. A 3D model of the prod-uct that will be tested has to be loaded into the virtual realitysoftware, the functional simulation needs to be created, and themodule will be used to connect the virtual environment with thefunctional simulation. All these tasks require a person that hasthe knowledge and skills that are necessary to perfom them. Thisparticipant will be called the Virtual Prototype Developer or VPDeveloper. He will be responsible for creating, deploying, attend-ing and maintaining the Virtual Prototype.

• Designer: To depict the product inside the virtual environment,some sort of description of the product is needed. Designers oftenuse 3D modeling tools like CAD software to build a representationof the product. The data from these modeling tools can be usedby the VR software. Either the files can be imported directly intothe virtual environment or they need to be reformated to a dataformat that can be read by the VR software.

4 Requirements

• Engineer: Just like the Designers Engineers are also an impor-tant source for input data. They too use 3D modeling softwarein their design process that can be used to provide data for thevirtual environment. Additionally, the processes that need to besimulated by the functional simulation will be specified by them.

• VR System: The module will be developed to connect two sim-ulations. One of them is the virtual reality system that is usedto provide a realistic environment in which the product can betested. The module will be a part of the VR System.

• Functional Simulation: The Functional Simulation will be usedto describe certain sequences of events that have their origin in in-teractions perfomed inside the virtual environment. State changesinside the Functional Simulation on the other hand can result ina visual output inside the VR System.

Now that all of the participants are identified, their expected inter-actions with the system need to be assessed. The possible use casescoming from the participants will be described in the following.

The Test Pilot needs to be able to interact with objects inside theVirtual Prototype. If the object is related to a process in the func-tional simulation the module will have to notify the simulation. Thefunctional simulation will handle the notification and check if the inter-action is sufficient to cause a state change. This state change could haveeffects on other objects both inside the functional simulation and insidethe virtual environment. Thus it is imperative that the functional sim-ulation has to be able to notify the module about state changes on anyobject and order the module to perform the action that is related tothis state change. Possible actions will be a rotation of a scene object,a translation of a scene object or a texture change. This specific usecase is also described in figure 6.

The VP Developer has to build the Virtual Prototype. First he willneed the 3D data describing the scene the Test Pilot will interact withwhen inside the virtual environment. The geometry for the scene willbe obtained either from the Designers or the Engineers. The files pro-vided by them may not be in the file format the virtual reality softwarerequires. The VP Developer will have to reformat the data so that itcan be read by the virtual reality software, in this case by the VDP.Next, he will have to build the Functional Simulation that will laterbe connected with the virtual environment. The Engineers may havealready build some sort of functional simulation to test their design. If

4.1 Scenario Description andStakeholder Analysis page 23

Test Pilot Functional Simulation

VDP Connector Module

interacting with an objectinside the virtual environment

listening for transformations

sending transformation data

receiving request to transform an objector change its texture

<<include>>

performing the requested action

<<include>>depicting events caused by

the functional simulation inside the virtual environment

Figure 6: Use case diagram for the scenario where the module will be used by theTest Pilot.

possible, this simulation will be connected to the virtual environmentby using the module. In case the functional simulation the Engineersprovided cannot be connected by using the module, the VP Developerwill have to build a new functional simulation which can be connectedto the VR system by using the module. Now that all the ground work isdone the VP Developer will use the module for a bidirectional couplingof the two independent systems. He will have to connect scene objectsfrom the virtual environment with their corresponding processes in thefunctional simulation. After he has made all the necessary configura-tions to deploy the Virtual Prototype it will be helpful to be able tosave these settings. This way he can simply load the settings he al-ready made and start again right where he left off without having todo the same work every time the prototype is restarted. In case one ofthe scene objects that already is connected is no longer needed it willbe necessary to delete the settings made for this scene object. And todelete all configurations made so far, a reset command will be useful.See figure 7 for the resulting use case diagram for the VP Developer.

The Designers and Engineers create the demand for a realistic testenvironment. Their concepts and designs can be seen as the inputdata for this system. Both of them provide the system with the geo-metric objects that will be displayed in the virtual environment. TheEngineers additionally deliver the kinetic sequences and functional de-pendencies associated with these objects. The Functional Simulationwill be used to simulate these sequences and dependencies by describ-ing them through processes. Both the Designers and the Engineers can

4 Requirements

VP Developer

VDP Connector Module

Creating a connection between a scene object anda process inside the Functional Simulation

Saving all configurations

Loading configurations

Reseting all configurations

Deleting a connection for a scene object

FunctionalSimulation

Building processesto describe the chains

of events connected tothe virtual prototype

Importing scene

<<include>>

reformating3D geometry

data

Connecting the processeswith the virtual environment

<<include>>

Figure 7: Use case diagram for the scenario where the module will be used by theVP Developer.

also act as Test Pilots if they perform the tests themselves. Thereforethe use case diagram in figure 6 might also apply to the Designers andEngineers.

The VR System will be used to create the virtual environment;the more realistic and immersive the environment will be perceivedby the Test Pilot, the better. The VR System will consist of the VisualDecision Platform (VDP) by IC:IDO and the module that has to bedeveloped to allow the system communication with the Functional Sim-ulation. Aside from the need for a realistic graphic and the possibilityfor an intuitive interaction, which the VDP delivers, it is imperativefor this scenario that objects can be connected to a process in a Func-tional Simulation. If connected to their process the VR System willhave to listen for any changes on these objects. If changes occur thatare sufficient to cause the need to inform the Functional Simulation,the VR System will have to send a message with a description of thechange. On the other hand, if a message from the Functional Simula-tion is received the VR System will have to be able to react accordinglyand perform any action these messages are supposed to initiate.

The Functional Simulation is used to run processes which will rep-resent the behaviour and relationship of certain objects in the virtualenvironment. Some objects are related to other objects and an inter-

4.1 Scenario Description andStakeholder Analysis page 25

action - respectively a state change - for one object may also effectanother object. The simulation of these causal relationships and thepossibility to inform the VR System about the neccesary actions thatmight result from them are the key factors of the Functional Simula-tion. Just like the VR System the Functional Simulation has to beable to recieve messages from and send messages to its counterpart. Ifa message is received the information contained in it will be used tocheck if the object that sent the message has changed its state and ifthis state change has any implications on other objects that might berelated to it. In case another object is affected by a message and con-sequently has changed its state, the VR System needs to be informedof this change and the action this state change requires needs to beperformed by the VR System.

In figure 8 the use cases for both the VR System and the FunctionalSimulation are described.

VDP Connector ModuleFunctionalSimulation

Receiving message

Sending message

Sending message

Receiving Message

Extension Point:Scene Object

Performing requested action

Displaying the scene

Running processes

<<include>>

<<extend>> <<Precondition>>

{transformed}

extension point: Scene Object

Listening for transformation

Updating process states

<<include>>

<<extend>>

Extension Point:Process States

<<Precondition>>

{state changed}

extension point: Process State

<<extend>>

Checking for state changes

Figure 8: Use case diagram for the VR System and the Functional Simulation.

In the following sections the requirements elicited for the system asit has been outlined above will be specified. A number of differentclassification methods for requirements exists like the FURPS modeldeveloped by Hewlett-Packard and published by Grady and Caswell(1987). For this work the requirements will be divided in functionaland non-functional requirements. A functional requirement is a re-quirement that specifies a function that a system or system componentmust be able to perform (IEEE, 1990). The non-functional require-ments will be subdivided into:

4 Requirements

• the technical requirements which are used to describe the require-ments related to the hardware and software components that areused to develop and deploy the system.

• the requirements concerning the user interface which describe therequirements related to the graphical user interface (GUI) and theinput and output devices.

• and requirements concerning the quality of the system which de-scribe the quality features of the system. There are qualities re-lated to features that are observable at runtime, like usability orsecurity, and qualities related to the development of the system,like maintainability or extensibility.

4.2 Functional Requirements

RequirementID

Priority User Requirement

FR 1 Must Test Pilot The module must allow a bidi-rectional communication be-tween the VR System and theFunctional Simulation.

FR 1.2 Must Test Pilot If a scene object is related to aprocess in the Functional Sim-ulation and it is transformedin the VR System it must in-form the Functional Simulationabout the transformation.

FR 1.3 Must Test Pilot If a state change occurs in a pro-cess run by the Functional Sim-ulation the Functional Simula-tion must be able to order theVR System to perform the ac-tion related to this state change.

FR 1.3.1 Must Test Pilot The Functional Simulationmust be able to order the VRSystem to rotate a scene object.

FR 1.3.2 Must Test Pilot The Functional Simulationmust be able to order the VRSystem to translate a sceneobject.

Table 1: Functional Requirements Part 1

4.2 Functional Requirements page 27

RequirementID


FR 1.3.3 Must Test Pilot The Functional Simulationmust be able to order the VRSystem to change the textureof a scene object.

FR 2 Must VP Devel-oper

The VDP module must enablethe VP Developer to construct aVirtual Prototype by using boththe VR System and the Func-tional Simulation.

FR 2.1 Must VP Devel-oper

The VP Developer must be ableto import different file formatsinto the VR System.


If the files cannot be importeddirectly because of their formatthe VP Developer must be ableto reformat the files describingthe scene so that they can beimported.


The VP Developer must be ableto build calls to the VR Sys-tem that will be initated by theFunctional Simulation.


The VP Developer must be ableto build processes in the Func-tional Simulation which can getinput from outside the simula-tion via LAN or Internet.


The VDP module must providea GUI with all the input fieldsand methods that the VP De-veloper needs to connect a sceneobject with the Functional Sim-ulation.

FR 2.5.1 Must VP Devel-oper

The VDP module must providea way to create a connection be-tween a scene object and a pro-cess in the Functional Simula-tion.


4 Requirements

RequirementID



The VDP module must providea way to delete a connection be-tween a scene object and a pro-cess in the Functional Simula-tion.


The VDP module must providea way to delete all connectionsbetween scene objects and theirprocesses in the Functional Sim-ulation.


The VDP module must providea way to save all the connectionsbetween scene objects and theirprocesses in the Functional Sim-ulation.


The VDP module must providea way to load the saved connec-tions.


4.3 Technical Requirements

RequirementID

Priority SystemComponent

Requirement

TR 1 Must VR System The software for the VR Sys-tem must be the Visual DecisionPlatform by IC:IDO.

TR 2 Must VR System The module for the VDP mustwork for the desktop and theimmersive module.

Table 4: Technical Requirements Part 1

4.4 User Interface Requirements page 29

RequirementID

Priority SystemComponent

Requirement

TR 3 Must VR System The module must work if theVDP is run on a cluster.

TR 4 Must VR System The module must be able tocommunicate in a local area net-work.

TR 5 Must VR System The VR System and the Func-tional Simulation must not berunning on the same computer.

TR 6 Must VR System The module must be build withIDO-Develop.

TR 6.1 Must VR System The module must be written inC++ Code.

TR 7 Must VR System The operating system for theVR System must be WindowsXP.

TR 7.1 Must VR System The VR System must be builtfor a x64 architecture.

Table 5: Technical Requirements Part 2

4.4 User Interface Requirements

RequirementID

Priority Requirement

UIR 1 Must The GUI of the VR System must allow the VPDeveloper to perform the actions defined in thefunctional requirements (FR 2.5.1 - FR 2.5.5).

UIR 2 Must The GUI of the VR System must indicate that ascene object is connected to a simulation.

UIR 3 Must If a scene object is selected the VDP modules GUImust show the configurations of the connection.

Table 6: User Interface Requirements

4 Requirements

4.5 Quality Requirements

RequirementID

Priority Requirement

QR 1 Must The system must guarantee that there will notoccur any inconsistencies on an object’s state inthe Functional Simulation and in the VR System.

QR 2 Must The system must be able to display any changesresulting from the communication of the VR Sys-tem with the Functional Simulation in real time.

QR 3 Must The VR System must not be stopped because of amessage that is sent to or received from the Func-tional Simulation.

QR 4 Must The communication between the VR System andthe Functional Simulation must not result in adeadlock.

QR 5 Must The module for the VR System must be devel-oped in a way that it can easily be extended orremodeled to work for different test scenarios.

QR 6 Must The module for the VR System must be well doc-umented to allow easy maintenance.

QR 7 Must All possible errors resulting from invalid com-mands or false use must not cause the system tocrash.

QR 7 Should It should be possible to connect the VR Systemwith different Functional Simulations.

Table 7: Quality Requirements

5 Concept

5.1 VR System Concept

The virtual prototype is mainly perceived through the virtual environ-ment created and run by the VDP. The functional simulation wouldmainly be used to enhance the possibilies of the VR system. Thus itwas decided to start with the part of the system that would play themain role with regard to the virtual prototype and develop a conceptto expand its features by providing an interface for bidirectional com-munication with functional simulations.Geometric objects as depicted in virtual enviroments can undergo threedifferent transformations. They can be rotated, translated and theirtexture can be changed. Every possible change related to an objectand experienced inside the virtual environment could be caused by oneof these actions or a combination of them. To enable another programto order the VDP to perform any of these actions, it seems impera-tive to provide an interface for these three commands. The commandswould need the following information to allow the VR system to re-spond accordingly.

• Rotation: To perform a rotation on a scene object the VDP firstneeds to know which scene object should be rotated. If the com-mand is not issued directly to the scene object, the scene objectneeds to be unequivocally specified. This could either be done bygiving a name, or a unique ID to which only the scene object thatis addressed is connected to.The rotation can be described in different ways. Since the rep-resentation of a rotation as Euler Angles is ambiguous and cancause a Gimbal Lock it is best to describe the rotation in the formof a Quaternion or an Axis Angle.

• Translation: Just like a rotation a translation needs informationto identifiy the scene object if the command isn’t issued directlyto the scene object. The translation itself can be described bythree float values or a vector composed of three float values.

• Texture Change: Also the texture change requires an unmis-takable identification for the scene object that is affected by thecommand. The texture change also needs some sort of informationto determine which image should be loaded as the new texture.

This of course is only one of the necessary directions in which communi-cation will take place. Aside from receiving commands the VR systemwould need to send information about scene objects too. Mapping the

5 Concept

geometric properties of a scene object to a state inside the functionalsimulation is dependent on the object that is simulated and must bedone by the VP Developer. The mapping should not be performed bythe VR system. This would result in a system that is very specific andhard to expand or fitted to different scenarios. The mapping must beperformed by the functional simulation itself or a component that isset in between the two simulations. It is important that the mappingcan easily and quickly be created without requiring too much training.The messages the VR system is sending to the functional simulationneed to contain a subset or all of the following informations to allowthe functional simulation to map them to a state.

• Name or a unique ID of the scene object: The functionalsimulation must be able to identify the scene object that causedthe sending of the message. This scene object then needs to belinked with an object, a state, or a process inside the functionalsimulation.

• Transformation the scene object just underwent: To deter-mine if a state transition needs to be performed by the functionalsimulation it is necessary to examine the transformation data sentby the VR system. The identification of the scene object and thetransformation data can be used to assign a state change thatcorresponds to the received data. The transformation data canconsist of a rotation and/or a translation. This information canbe sent in different formats or just a part; for example, just therotation data could be transmitted.

• Timestamp for the event: A timestamp is necessary to ensurethat only up-to-date information is used. This way messages thatfor some reason arrive out of time or are already made irrelevantby other messages can be spotted and discarded. Also, the times-tamp can be sent back in a response message. The VR systemcould use the returned timestamp to determine if the receivedanswer is relevant or out of date.

Some switches used in aircraft cockpits can only be set to a certainposition after a lock mechanism has released the switch. One examplefor this is a type of toggle switch that needs to he lifted before it canbe tilted to another angle (see figure 9). This lock status is not con-sidered in this concept. The problem with such a mechanism is that ifthe Test Pilot is able to tilt the switch inside the virtual environment,regardless of the lock mechanism, it will not help to model this state.Discrepancies between the saved lock status and the actual position of

5.2 Functional Simulation Con-cept page 33

the switch could result in inconsistencies between the two simulations.The mechanism needs to be modeled by defining geometric constraintson the switch. This is possible with the help of an existing VDP mod-ule called IDO:Package. By defining the geometric constraints for theswitch, the Test Pilot will only be able to move the switch in the di-rections permitted in the constraints. Thus modeling the lock status isredundant and only the position of the switch needs to be consideredwhen mapping from the scene object to a state in the functional simu-lation.

Figure 9: Toggle switch with a lock mechanism.

To provide a way of constructing the virtual prototype and connectingit with the functional simulation from inside the VDP instead of creat-ing a plugin, a module with a graphical user interface is implemented.With the help of the module the VDP Developer has a user-friendlydevice to connect the virtual prototype with the functional simulation.The functional requirements and the requirements for the user interface(see section 4.2 and 4.4) can be used to determine the functions theGUI has to offer.

5.2 Functional Simulation Concept

Now that the concept for the communication interface which the VRsystem will provide is outlined, it is time to regard the functional simu-lation. The input received by the functional simulation and the requestsit can send to the VR system result from the messages sent to and fromthe VR system. This creates some requirements concerning the possi-

5 Concept

bilities the functional simulation needs to offer to be connected to theVR system.

• First of all, it must be able to send and receive messages.

• Also, the VP Developer must be able to specify the informationcontained in those messages.

• The simulation of a functional relationship associated with sceneobjects from inside the virtual environment must be easy to cre-ate.

• The processes running in the functional simulation must providea way to trigger the forwarding of a message to the VR system.

• The communication must be asynchronous so that the processdoes not have to wait for a reply and can still be addressed byother communication partners.

• The simulation must be able to receive and interpret the mes-sages sent from the VR system and send calls for the three basicmethods the VR system offers itself (see section 5.1).

These requirements led to the decision to use the Business Process Ex-ecution Language (see section 3.2) to build the functional simulation.The Business Process Execution Language provides features like theusage of query and expression languages; it can be used to assign data,and offers structured activities, like conditional behaviour, repetitiveexecution, selective event processing, parallel and control dependenciesprocessing, or the ability to process multiple branches. Thus the pro-cesses built using BPEL can be said to be turing complete and are ableto model any functional behaviour needed for the scenario of this work.BPEL also offers the ability to invoke Web Services from inside of theprocesses, which is exactly what is needed to trigger events inside thevirtual environment. The processes created with the use of BPEL canbe deployed as Web Services and other Web Services can be dynami-cally invoked from within the processes. The incoming and outgoingmessages can be defined by the VP Developer to comply with the sce-nario of the virtual prototype. A graphical user interface that allowsthe construction of processes exists with the open source BPEL edi-tor provided by Eclipse17, a GEF-based editor that provides a graphicalmeans to author BPEL processes (The Eclipse Foundation, 2010). An-other benefit gained from using BPEL is that the BPEL processes can

17http://www.eclipse.org/bpel/

http://www.eclipse.org/bpel/

5.3 Communication Concept page 35

also be used to include other sources. This way, a process can orches-trate the incoming messages from the VR system and distribute themto other functional simulations. For example, a notification about arotated scene object could be mapped to a state change event in Rhap-sody and the BPEL process could send the resulting call to Rhapsody’sweb interface. Many different simulation tools that already provide aHTML or Web Service interface could be incorporated this way.

5.3 Communication Concept

As a result of the choice to use BPEL to simulate the functional be-havior of objects, the use of Web Services (see section 3.3) as the com-munication platform arose. The module developed for the VDP has toinclude a Web Service through which BPEL processes can trigger thethree basic events Rotate, Translate and Change Texture. TheVDP module also has to provide a client to allow the VR system tosend information to the BPEL processes. The requests sent to the VRsystem will always be the three basic commands Rotate, Translateand Change Texture, but the requests sent to the functional simu-lation might be different for every simulated scenario. Thus it is nec-essary that the client side of the VR system that sends the requests tothe functional simulation can easily be modified to allow these changes.This must be considered when developing the system architecture forthe VDP module.To work around the problem of having to identify the object whichsent a message or was addressed by a message, it was decided to createa service and a client for every object that had to be connected. Bydoing so every object can unambiguously be defined by the address ofits Web Service.

5.4 General Architecture

The architecture resulting from the concept described above is nowspecified. As defined in the technical requirement TR 5 (see section 4.3)the functional simulation and the VR system must not be running onthe same computer. This results from the fact that both simulations areattended by different teams, which results in two independent work en-vironments. To comply with the principle of Separation of Concerns aloose coupling of the two simulations is required. This way both teamscan develop their simulations without having to regard requirementsfrom the other team. As a result of this requirement the two simu-

5 Concept

lations need to run on different computers, thus a distributed systemis built. To connect the two separate components, a Service OrientedArchitecture is implemented using SOAP and WSDL. In the W3C doc-ument defining Web Service Architecture for distributed systems it isstated, that in general SOA and Web Services are most appropriate forapplications:

• Where components of the distributed system run on different plat-forms and vendor products;

• Where an existing application needs to be exposed for use over anetwork, and can be wrapped as a Web Service.

(W3C, 2004a)Both of these reasons apply to this scenario. The VR system needs toenable the functional simulation to initiate rotations, translations, ortexture changes and the functional simulation must provide processeswhich recieve information from the VR system and subsequently decideabout state changes.In a paper on the subject of ”Bridging 3D Graphics and Web Ser-vices”, which was written to suggest possible solutions for the scenarioof this work, Schubotz (2009) addresses a scenario similar to this. Byusing Web Services to build a Service Oriented Architecture he aimsto extend the network capabilities of X3D. In this paper three differ-ent approaches to extend the network capability of X3D are presented,called External Networking, Internal Networking and Nodal Network-ing (Schubotz, 2009). The solution presented in this work is relatedto the Nodal Networking approach. Just like in X3D, the scene ob-jects in the VDP are all represented as nodes in a scene graph. Thisis a basic approach in all computer graphics related solutions. To al-low scene objects to communicate with other programs, respectively toreceive and send information, a Connector Node similar to the Ser-viceConsumer node and the Connection node (Schubotz, 2009) is usedto provide this ability. The Service Oriented Architecture used for thesolution presented in this work can be seen in figure 10.

By using the graphical user interface of the VDP module the VP De-veloper will create Connector Nodes for each scene object he wantsto connect with the functional simulation. The module will equipevery Connector Node with a Web Service so that the scene ob-ject can be manipulated from outside the VR system. To allow theConnector Node to send information to the functional simulation,a client for the Web Service of the BPEL process that simulates thefunctional behavior of the scene object will also be included in the

5.4 General Architecture page 37

Functional Simulation(BPEL)

VR System(VDP)

VDP Module

BPEL Process

Connector Node

Connector NodeBPEL Process

SOAP message

SOAP message

ODEOrchestration Director Engine

AXIS 2Web Service Provisioning

Extern Web Services

VDP / gSOAPWeb Service Provisioning & Consumption

SOAP message

SOAP message

Figure 10: Architecture of the system developed for this work.

Connector Node. If the Test Pilot interacts with the scene objectthe client will send all the necessary information to the correspondingBPEL process. To notice if an interaction with its scene object oc-cured, the Connector Node will have to listen for transformationsof his scene object.The BPEL processes used to model the functional behavior of the sceneobjects can be designed with the help of Eclipses BPEL editor (see fig-ure 11).

Figure 11: GUI of Eclipses open source BPEL editor.

5 Concept

The processes will be deployed as Web Services and will be contactedby scene objects which hold the functionalities modeled by them. Thetransformation data sent by the clients of the Connector Nodes willbe used to determine the state of the scene object. If the transforma-tion was not sufficient to cause a state change nothing will have to bedone by the process. Supposing the transformation data caused a statechange, the process must inform the VR system. Depending on thestate, the process will dynamically invoke the Web Service of the sceneobject that will have to be transformed or have its texture changedas a result of the state change. To give a better understanding of thewhole procedure, an examplary sequence of events will be described.A toggle switch will be tilted by the Test Pilot and as a result of thisa control light must turn green.

1. The scene object depicting the toggle switch is tilted by the TestPilot inside the virtual environment.

2. The Connector Node created for this toggle switch notices thetransformation of the scene object.

3. To inform the functional simulation the client of the ConnectorNode sends the transformation data to the Web Service of theBPEL process, which models the functional behavior of this switch.In the case of the toggle switch only the rotation data is needed.

4. The Web Service of the BPEL process receives the informationabout the interaction.

5. To determine the state of the switch the BPEL process examinesthe rotation data and maps it to the appropriate state.

6. Since the toggle switch is related to a control light, the process willnow invoke the Change Texture method provided by the WebService of the Connector Node that was created for the sceneobject depicting the control light. The information contained inthe message must be sufficient to specify the image, which willthen be set as the new texture.

7. The Web Service of the Connector Node for the control lightreceives the inforamtion contained in the Change Texture call.

8. The Change Texture call is noticed by a listener in theConnector Node.

9. The Connector Node hands the information received in thatmessage over to a method which will perform the texture change.

5.4 General Architecture page 39

Now that the general approach for the bidirectional coupling of a VRsystem with a functional simulation and the architecture that is used toperform this coupling are set, it is time to go into the details related tothis approach. The VDP module is broken down into its components,with the Connector Node being one of them. The implementation ofthe module and all of its classes is described in the following section 6.

6 Implementation

6 Implementation

The functional simulation created with the use of the Business Pro-cess Execution Language (BPEL) does not need any extensions to beconnected. The open source BPEL editor provided by Eclipse is usedto create the processes that are utilized to simulate the functional be-havior of certain scene objects from inside of the virtual environment.To publish the Web Services for the processes, the Apache ODE18 isused to deploy them on an Apache Axis219 server. The steps necessaryto publish the BPEL processes as Web Services will be described insection 6.6.

In this section, the implementation for the VDP module is described.The module is implemented with the use of the application program-ming interface (API) IDO:Develop provided by IC:IDO. IDO:Developis used in the 2010 version with the service pack 2 for a 64 Bit sys-tem. Due to the application programming interface IDO:Develop, theprogramming language used to implement the module for the VDPis C++. To work with IDO:Develop, Microsoft Visual Studio 200520

is used as the integrated development environment (IDE). With thehelp of CMake21 it is possible to create all the files for a MicrosoftVisual Studio 2005 solution which also contains some basic tutorialsfor IDO:Develop. The code for this work is included into this solu-tion and a CMakeList.txt file is written to build the new Visual Studioproject and integrated it into the solution provided by IDO:Develop.To provide a way to deal with the mathematic problems linked withthe transformations caused by user interaction ,especially those of lin-ear algebra, the Generic Math Template Library22 (GMTL) is suppliedwithin the IDO:Develop package and is linked by CMake. In case theimplementation requires means to create objects for a graphical userinterface the QT23 library is also linked to the project configurationcreated by CMake. Since the module developed for the VDP is sup-posed to provide a graphical user interface, a QT distribution needs tobe specified in the CMakeList.txt file. The newest QT version (4.6.3)could not be compiled with IDO:Develop, for this work QT 4.4.324 for

18http://ode.apache.org/19http://tomcat.apache.org/20http://msdn.microsoft.com/en-us/vstudio/dd430910.aspx21http://www.cmake.org/22http://ggt.sourceforge.net/html/gmtlfaq.html23http://qt.nokia.com/24ftp://ftp.qt.nokia.com/qt/source/qt-win-opensource-src-4.4.3.

zip

http://ode.apache.org/

http://tomcat.apache.org/

http://msdn.microsoft.com/en-us/vstudio/dd430910.aspx

http://www.cmake.org/

http://ggt.sourceforge.net/html/gmtlfaq.html

http://qt.nokia.com/

ftp://ftp.qt.nokia.com/qt/source/qt-win-opensource-src-4.4.3.zip

ftp://ftp.qt.nokia.com/qt/source/qt-win-opensource-src-4.4.3.zip

6.1 The VDP Module page 41

Windows is used. The cluster used to run the simulated virtual envi-ronment uses a 64 Bit architecture, thus the C++ code written for themodule has to be compiled for the 64 Bit architecture. A UML classdiagram of all the classes implemented for the module can be seen infigure 30 in the appendix section 9.

6.1 The VDP Module

To add all the features and functions needed for the bidirectional cou-pling of the VDP with a functional simulation, two possible ways areprovided by IDO:Develop. The first way is to develop a plugin. A plu-gin can be dynamically loaded, initialized and destroyed during run-time; it is provided as a way to integrate new features. Another wayto integrate new features into the VDP is a module. A module is anextension of a plugin. IC:IDOs VDP already comes with a variety ofmodules which serve different purposes; for example, the IDO:Packagemodule which is used in this work to create constraints for scene ob-jects. One characteristic of a module is that only one module can beactive. A module can be stopped and restarted at any time by usingthe ”Module-Switch-Bar” in the graphical user interface of the VDP.The characteristic that is most important for this work is that mod-ules are equipped with an API which can be used to integrate theminto the QT based graphical user interface of IDO:Explore. Toolbars,menues, dialogs and all the QT features can be used by the moduleto interact with the user. Because of the possibility to create a userinterface, the module approach is chosen for the solution developed inthis work. All modules are managed by the ModuleManager, whichprovides an API to add new modules to the 2D user interface. TheModuleManager is responsible for starting and stopping the module.By using the ModuleManager, the module can be added to the so called”Module-Switch-Bar” where all the modules that are integrated in theVDP have a button to activate them. It is also possible to create a”Module-Menu” or a ”Module-Docking-Dialog” for a module. This plu-gin and module architecture is described in the Programmers Guide forIDO:Develop IC: (2007) and can be seen in figure 12.

To create one’s own module and integrate it by using the ModuleM-anager, the new module must be derived from the IDOModule parentclass. The two virtual functions suspend(IDOModule *module)and resume(IDOModule *module) have to be implemented in thenewly created module. The function suspend(...) is called whenthe ModuleManager deactivates the module, because another mod-ule is selected, and the function resume(...) is called when the

6 Implementation

Renderer Plugin

Extractor Plugin

VDP

Module Manager

Package Module

Immersive Module

FunctionalityConnector Module

2D / 3D User Interface

Figure 12: Plugin and module architecture of the VDP.

ModuleManager activates the module again. During runtime the mod-ule is first created by calling the initialize() function, where aninstance of the class that is responsible for the modules user inter-face is created. The module class implemented in this work is calledFunctionalityConnectorModule, its main purpose is to encap-sulate all the features implemeted for the VDP as a result of this work ina module and to make them available by exporting them to a dynamiclink library (DLL). Additionally the FunctionalityConnector-Module will create an instance of the class Functionality-ConnectorModuleUI when the initialize() function is called.This class is used to create the user interface for the module. All the im-plementation details regarding the user interface of the module will beaddressed in section 6.4. See figure 13 for the UML class diagram of theFunctionalityConnectorModule and the Functionality-ConnectorModuleUI class.

6.2 The Connector Node

The concept to use a Connector Node to bidirectionally connect theVDP with a functional simulation, as outlined in section 5.4, led to thedevelopment of a series of classes, which are described in the followingpages. The IDOServiceConnector class is corresponding to theconcept of the Connector Node. The IDOServiceConnectorclass is used as the parent class for four different Connectors whichwere designed to address the scenario of this work. Its functions im-plementing the Web Service operations are virtual and need to be im-

6.2 The Connector Node page 43

Figure 13: UML class diagram of the FunctionalityConnectorModule and theFunctionalityConnectorModuleUI class.

plemented by these classes. The focus of this work is to bidirection-ally connect control devices located in an aircraft cockpit to a func-tional simulation; therefore, the Connectors are designed for dif-ferent types of switches. The IDOToggleSwitchConnector, theIDORotarySwitchConnector, the IDOPushButtonConnectorand the IDOTextureConnector are all derived from the parent classIDOServiceConnector and only implement the Web Service opera-tions that are relevant for them. See figure 14 for a UML class diagramof this specialisation. When adding a new Connector during run-time, a variable with the type of the parent class is created and thenan instance is created by calling the constructor of one of the special-ized classes is assigned to that variable. In this way, all the differentConnectors can be created stored and deleted as if they were of thesame type. It is not necessary to implement functions for every differentConnector type. This design pattern is called Factory Method andwas introduced by the so-called ”Gang of Four” Gamma et al. (1995).To simplify the following explanations, concerning all the classes cre-ated for the framework of this work ,the different Connectors willall be referred to by their parent class IDOServiceConnector.

If a scene object is connected to a functional simulation an instance ofthe IDOServiceConnector class is created and all other importantobjects needed for the connection will be created for, through, or with

6 Implementation

Figure 14: UML class diagram showing the different specialised Connectorclasses and their parent class.

this instance. The goal is to enable the user to connect a scene objectwith the functional simulation that is modeling the functional behav-ior and the functional relationships of the scene object. This involvesfour important tasks the Connector Node has to be able to fulfill.He needs to send information to the functional simulation if a sceneobject that is connected via a Connector Node is transformed byuser interaction. And he needs to receive information from the func-tional simulation and perform the actions required by them. Beforethe Connector Node can send and receive messages to and from thefunctional simulation, he must be able to recognize a user interactionwith his scene object. Also, he must recognize if a message was re-ceived by his Web Service and then perfom the action required by thismessage.

6.2.1 Noticing User Interaction

The VDP uses an event driven approach based on a Listener objectwhich connects the Sender of an event with his designated Recipient.It is possible to define new types of events, by using so-called IDOGUID’s,but in this case the VDP already provides an event type which canbe used to identify an interaction with a specified scene object. TheIDOSceneObject class provides an event type called


SCENEOBJECT_PROPERTY_CHANGED and one of the subevents ofthis event type, called SCENEOBJECT_ON_SET_TRANSFORM_BS, de-scribes the event of a scene object being transformed. This is exactlythe event which is needed to describe a user based interaction witha scene object. Now that the Sender of the transformation eventand the event he needs to listen for are known, the last thing that ismissing is the Recipient. The Recipient is called from inside theListener and is handling the events. The Connector Node itselfcould be made the Recipient, but to comply with the principle of”Separation of Concerns”, it was found to be better to create an inde-pendent class. Each IDOServiceConnector object holds a mem-ber variable, called m_recipient which is an instance of this class.To enable the Recipient in the Connector Node to handle theevents, a Listener must be created who is calling the Recipient.The scene object the Connector Node is responsible for is the eventSender for this Listener, and the Recipient is provided by theConnector Node in form of a member variable. It is not neces-sary for the scenario of this work to react to every transformation. Inthe case of a toggle switch only rotations, and only such that are suf-ficiently large enough need to be considered. In the case of a pushbutton, only sufficiently large translations need to be considered. Thusthree different Listeners were implemented to meet the different re-quirements: one Listener for rotations, one for translations and onefor transformations in general. These Listeners examine the trans-formation matrices for every transformation event, but only call theirRecipient to handle the event if the transformation event matchestheir criteria. This way transformations that are too small, or that donot meet the kind of transformation connected with the functionalityof the scene object, cannot result in sending messages to the func-tional simulation. Unnecessary network traffic is thereby preventedand communication is limited to the exchange of useful and impor-tant information. The classes developed for the solution presentedin this work can be seen in the UML diagram in figure 15. Themain class for implemeting the Connector Node concept is calledIDOServiceConnector, the Recipient for the Connector iscalled IDOServiceConnectorRecipient and the three differentListeners are called IDOSceneObjectListener, IDOScene-ObjectTranslationListener and IDOSceneObjectRot-Listener.

The three Listener classes are all derived from the template classIDOListener<Sender, Recipient>. The IDOSceneObject the

6 Implementation

Figure 15: UML class diagram with all the classes used to process user interaction.


Listener is watching is the template argument for the Sender andthe IDOServiceConnectorRecipient hold by the IDOService-Connector object is the Recipient. All three Listeners imle-ment the virtual functions requestSubEventType(size_tsubEventType) and update(IDOEventType::Type type,size_t subEventType, void* data=0) of their parent class.The requestSubEventType(...) function checks all events fortheir subevent type and returns a boolean value. If the subevent typeor types specified in the requestSubEventType(...) function oc-cured, the update(...) function is called. This function is then usedto call the Recipient to handle the event. The update(...) func-tion of all three Listener classes implemented for this work is calledif the subevent type is SCENEOBJECT_ON_SET_TRANSFORM_BS. Allthree Listener classes request the current transformation matrixfrom their scene object, which is also their Sender, and examinethis matrix. The IDOSceneObjectRotListener checks for a suf-ficiently large rotation, and if found calls his Recipient to han-dle the rotation. The IDOSceneObjectTranslationListenerchecks the transformation matrix of his Sender for a sufficiently largetranslation, and then calls his Recipient to handle the translation.And the IDOSceneObjectListener checks for both a sufficientlylarge translation and/or rotation and then calls his Recipient to han-dle the transformation. All three Listeners add a matrix containingthe transformation data as a parameter to their handle call, so thattheir Recipient has the information he needs to handle the transfor-mation event. The IDOServiceConnectorRecipient class is de-rived from the abstract class IDOListenerContainerRecipient.To handle the transformation events noticed by the Listeners, itprovides the handleSOEvent(gmtl::Matrix44f matrix) func-tion. This function extracts the translation and the rotation from thematrix and, depending on the type of the Connector, orders the WebService client, which is provided with the IDOServiceConnector-Recipient to send them to the functional simulation. The actionsperformed when listening for user interaction are also described in theactivity diagram in figure 16 by using the example of a toggle switch,which is tilted inside the virtual environment by the user.

6.2.2 Sending Information to the Functional Simulation

Now that the first important task of the Connector Node, the part oflistening for user interaction, is dealt with, it is time to consider the sec-ond task, which is sending the acquired information about user interac-

6 Implementation

Toggle switch tilted by user

IDOSceneObject calls IDOSceneObjectRotListener

IDOSceneObjectRotListener checks the subevent type

callListener(SCENEOBJECT_PROPERTY_CHANGED, SCENEOBJECT_ON_SET_TRANSFORM_BS)

requestSubEventType(SCENEOBJECT_ON_SET_TRANSFORM_BS)

IDOSceneObjectRotListener calls IDOServiceConnectorRecipient to handle the event

[SCENEOBJECT_ON_SET_TRANSFORM_BS]

update(SCENEOBJECT_PROPERTY_CHANGED, SCENEOBJECT_ON_SET_TRANSFORM_BS)

update() function of theIDOSceneObjectRotListener checks the

transformation matrix

[transformation was a rotation & rotation > threshold]

handleSOEvent(rotationMatrix)

IDOServiceConnectorRecipient orders his web service client to send the information

about the rotation to the functional simulation

sendToggleSwitch(...)

Figure 16: UML activity diagram describing the actions caused by a user inter-action with a toggle switch.


tion to the functional simulation. For this task the Connector Nodemust be able to invoke the Web Services of the BPEL processes thatare used to model the functional behavior of the scene objects. Thus aWeb Service client is required. As presented in the section above, theRecipient will be called by the Listener to handle the transfor-mation event. Handling the event will also include sending the trans-formation data, hence the Web Service client must be included in theRecipient. To make it easier to add new Web Service clients andto comply with the principle of ”Separation of Concerns”, a class isdesigned especially for that purpose. Each Recipient will hold amember variable, called m_client, which is an instance of this WebService client class. The order to invoke the Web Service of a BPELprocess is then given in the handleSOEvent(..) function of theIDOServiceConnectorRecipient. For the cockpit scenario ad-dressed in this work, clients for five different BPEL processes werecreated. The BPEL processes already provide a description of theirWeb Service in the form of a WSDL file. This file is used to cre-ate a client for the Web Service specified in it. By using the gSOAPtool wsdl2h, a C++ header file defining the operations of the WebService and his data types is generated from the WSDL file. Thisheader file is then used by the gSOAP compiler soapcpp2 to gener-ate an XML serializer for the data types and a client stub. For fur-ther information on gSOAP see section 3.4. All the C++ files createdwith gSOAP were included in the class IDOWSClient, which containsall the Web Service clients necessary to invoke the BPEL processes.This class provides four functions called sendToggleSwitch(...),sendRotarySwitch(...), sendPushButton(...) andsendGeneralObject(...). The sendToggleSwitch(floatangle, float rotXAxis, float rotYAxis, floatrotZAxis, IC::IDOFunctionalObject* fObj) function cancontact three different BPEL processes, which each model a differ-ent functional behavior connected to a toggle switch. The host ad-dress of the BPEL processes Web Service is used to determine whichWeb Service needs to be connected. This address is specified when aConnector Node for a scene object is created. Depending on thataddress the suiting client object is created and all the information re-quired by the BPEL process is sent to him. The following informationis send to the BPEL processes modeling the behavior of toggle switches:

• The information about the rotation of the scene object. Everytoggle switch process gets the rotation data in the Axis Anglerepresentation (angle, X-axis, Y-axis and Z-axis).

6 Implementation

• The address of the Web Service for the scene object that is asso-ciated with this scene object. To identify the scene object thatmight be affected by the scene object which sent the informationto the process, the host address of the Web Service of this sceneobject is included in every message to a toggle switch process.

• A timestamp for the time the message was send to the process.This way messages that arrive late and are already irrelevant dueto a newer message and will not result in incorrect state changes.

• The unique ID of the scene object that is sending the message.The process which is modeling a functional behavior where twotoggle switches are needed to be set in the same position to causea control light to change its colour additionally gets the ID of thescene object which is sending the message.

The sendRotarySwitch(float angle, float rotXAxis,float rotYAxis, float rotZAxis) function contacts the pro-

cess that was created to simulate the functional behavior of a rotaryswitch. In this case, it is not necessary to examine the host address ofthe processes Web Service, since only one process for rotary switcheswas created for the scenario of this work. The information that is sentto the rotary switch process is similar to that sent to the toggle switchprocess. The information about the rotation is included in the mes-sage, as well as the address of the associate of the scene object thatis sending the information, and finally the timestamp for the time themessage was sent.The sendPushButton(float xTransValue, floatyTransValue, float zTransValue) function also only has oneBPEL process it can contact. The information sent to this processconsists of

• the translation data, which is represented by three float values forthe X, Y, and Z axis,

• the host address of the associate of the scene object which sentthe message,

• and the timestamp for the moment the message was sent.

All three functions write an error message to the console if the invoca-tion performed by their client did not end with the SOAP_OK result.The sendGeneralObject(float xTransValue, floatyTransValue, float zTransValue, float angle, floatrotXAxis, float rotYAxis, float rotZAxis) function is not


used in the cockpit scenario and only prints out its parameters to theconsole, therefore it is not necessary to check for errors in this function.The UML class diagram for the IDOWSClient class and its relation tothe IDOServiceConnectorRecipient class is shown in figure 17.

Figure 17: UML class diagram showing the IDOWSClient class and its relationto the IDOServiceConncetorRecipient class.

6.2.3 Receiving Information from the Functional Simulation

Now the Connector Node can inform the functional simulation aboutuser interaction on scene objects, but one part of the communication isstill missing. The BPEL processes which simulate the functional behav-ior of scene objects must also be able to invoke a Web Service providedby the Connector Node to inform him about events. This Web Ser-vice is implemented in the IDOServiceConnector class. This classwas already mentioned in the beginning of the Connector Node sec-tion 6.2; it holds a member variable with an instance of theIDOServiceConnectorRecipient class, which again holds a mem-ber variable for the Web Service client. However the main functionof the IDOServiceConnector class is the deployment of a WebService which can be used to perform changes on its scene object.With the use of the gSOAP tool soapcpp2 the Web Service for the

6 Implementation

Connector Node is generated from a C++ header file (see list-ing 2). The IDOServiceConnector class is derived from the WebService class IDOWS::Service, which was created by the gSOAP toolsoapcpp2. Since more than one Web Service must be ready to acceptconnections at all times the IDOServiceConnector class is also de-rived from the IDOThreadBase class provided by the VDP framework.

1 namespace IDOWS {2 int ns changeTexture ( int s t a t e , int timestamp , struct

ns s i gna lResponse {} ∗ r e s u l t ) ;3 int ns t rans la t eSO ( f loat xAxis , f loat yAxis , f loat

zAxis , int timestamp , struct ns s i gna lResponse ∗r e s u l t ) ;

4 int ns rotateSO ( f loat xAxis , f loat yAxis , f loat zAxis ,f loat degree , int timestamp , struct ns s i gna lResponse ∗r e s u l t ) ;

5 int ns setNewState ( int s t a t e , int timestamp , structns s i gna lResponse ∗ r e s u l t ) ;

6 }

2: C++ header file used by the gSOAP tool soapcpp2 to create a Web Service

This way, every instance of the IDOServiceConnector class is athread, which can be started, interrupted and destroyed. The WebService provided by the IDOServiceConnector is running as long asthe IDOServiceConnector thread is running. Multiple ConnectorNodes can be run parallel without having to wait for one another. Thestandalone Web Service is implemented in the run() function whichis a virtual function inherited by the parent class IDOThreadBase.This way the Web Service is started as soon as the thread for anIDOServiceConnector object is started. The Web Service pro-vides the four functions which are specified in the header file 2 thatwas used to create the Web Service. These functions are:

• changeTexture(int state_, int timestamp,IDOWS::ns__signalResponse *result_), which is pro-vided to allow the BPEL processes or other Web Service based ap-plications to invoke a function which will result in a texture changefor the scene object that deploys this Web Service. The state_parameter defines the image which is to be set as the new texture.The timestamp is used to check if the invocation is up to date.If the timestamp is older than the last timestamp receivedby this Web Service, the texture change is not performed. If thetimestamp is newer than the last timestamp, the state_ ishanded over to the Recipient of the IDOServiceConnectorby calling his setTextureState(...) function. The result_


parameter is a *void struct which is included just for compiler rea-sons. The changeTexture(...) function has no return valueother than SOAP_OK.

• Invoking the function translateSO(float xAxis_, floatyAxis_, float zAxis_, int timestamp, IDOWS::ns__signalResponse *result_) results in a translation ofthe scene object for which the Web Service is provided. The pa-rameters xAxis_, yAxis_ and zAxis_ specify the values forthe translation in a three dimensional space. The timestampis again used to prevent that actions are performed in the wrongorder. Only messages that have a timestamp newer than thelast timestamp are regarded. If this condition is met, the trans-formation data is passed on to the Recipient in form of a 4x4matrix, by calling his setMatrixFromWS(...) function. ThetranslateSO(...) function also has no return value besidesSOAP_OK.

• rotateSO(float xAxis_, float yAxis_, floatzAxis_, float degree, int timestamp, IDOWS::ns__signalResponse *result_) is invoked if the scene ob-ject of the Web Service needs to be rotated. The parametersdegree, xAxis_, yAxis_ and zAxis_ describe a rotation ina 3 dimensional space by providing an Axis Angle representationof the rotation. The timestamp parameter is used to checkif the message is still relevant. If that is the case the informa-tion about the rotation is passed on to the Recipient of thisIDOServiceConnector, by calling the setMatrixFromWS(...) function of the Recipient. Just like the other Web Ser-vice operations, this one has no return value besides SOAP_OK.The result_ parameter is a *void struct.

• setNewState(int state_, int timestamp, IDOWS::ns__signalResponse *result_) serves no function in thescenario of this work. It is included as a basis for future purposes.

Now the Connector Node implemented in the IDOService-Connector class can receive messages via a Web Service interface.But still one necessary part is missing. He has to perform the ac-tions requested by the messages sent to his Web Service. To do so hemust be able to notice if a message was received. This again callsfor the use of a Listener. The Recipient for the Listeneralready exists in form of the IDOServiceConnectorRecipient,the functions that are needed to handle the event of receiving a mes-

6 Implementation

sage are added to this class. All that is left is to implement theSender and the event for which the Listener will listen. The eventis of course the reception of a message, this event is defined by usingIDOGUID’s, and is named SERVICE_MESSAGE_RECEIVED (see list-ing 3). The Sender of this event is the IDOServiceConnector,but to maintain the ”Separation of Concerns” an extra class calledIDOServiceConnectorSender is implemented. The IDOService-Connector will hold a member variable, called m_sender, which isan instance of this class. Hence the IDOServiceConnector is boththe Recipient and the Sender of the event SERVICE_MESSAGE_RECEIVED.

1 #include ”IDODefs . h”2 #include ”IDOEventType . h”3

4 BEGIN IC NAMESPACE5 namespace IDOEventType6 {7 // {05FD1C2F−E116−407e−A371−3D86D6CDFBC2}8 DEFINE IDOGUID( SERVICE MESSAGE RECEIVED,9 0 x5fd1c2f ,

10 0xe116 ,11 0x407e ,12 0xa3 ,13 0x71 ,14 0x3d ,15 0x86 ,16 0xd6 ,17 0xcd ,18 0xfb ,19 0xc2 )20 } ;21 END IC NAMESPACE

3: C++ header file defining the event type for receiving a message via the WebService of an IDOServiceConnector object

To distinguish between the event of receiving a message to rotate,to translate, or to change the texture, subevents are defined in theIDOServiceConnectorSender class. These subevents are calledSERVICE_MESSAGE_RECEIVED_TRANSLATE, SERVICE_MESSAGE_RECEIVED_ROTATE andSERVICE_MESSAGE_RECEIVED_TEXTURE. Whenever the Web Ser-vice of an IDOServiceConnector object receives a message, theSender object created for this Connector Node ıs used to informthe Listener. For this purpose the IDOServiceConnectorSenderclass provides the functions onTranslate(), onRotate() and


onTexture(), which call the Listener and hand over the correspond-ing subevent. Three functions are implemented in the IDOService-ConnectorRecipient class to handle these different subevents.

• handleServiceEventTranslate(IDOResourceID soID)transforms the scene object identified by the parameter soID.The matrix containing the information about the translation wasalready handed over by the Web Service when the message wasreceived. Now the matrix specifying the current position of thescene object in world coordinates is acquired and multiplied withthe matrix containing the transformation data from the Web Ser-vice. The resulting matrix is set to be the new position of thescene object by using the setTransformBSbyWS(...) func-tion provided by the VDP class IDOAppSceneObject-Manipulator.

• handleServiceEventRotate(IDOResourceID soID) ro-tates the scene object which is specified by the soID parameter.It also combines the matrix giving the current position of thescene object with the transformation matrix from the Web Ser-vice. By using the setTransformBSbyWS(...) function thenew position of the scene object is set to be the result of thatcombination.

• handleServiceEventTexture(IDOResourceID soID)sets the new texture for the scene object specified by the parame-ter soID. First the image that is to be set as the new texture mustbe found. The Web Service only received an integer value namedstate_ which is supposed to represent the image. To acquire theimage file, the name of the scene object plus an underline charac-ter plus the integer value defined in state_ are combined. Theresulting String is the name of the image file. This requires thatall images that are used as textures must be named accordingly,otherwise the texture changes cannot be performed. Also, all im-ages have to be in the PNG image format. The function createsa reference for the scene object and uses that reference to obtainthe material (IDOAppMaterial) of the scene object. After thisthe shader object (IDOAppShader) for the material is requested,which is used to get the shading pass (IDOAppShadingPass).If there is a first texture in the shading pass, this is removed anda new texture (IDOAppTexture) is created using the image filespecified by the state_ parameter from the Web Service.

To connect the IDOServiceConnectorSender with his IDO-ServiceConnectorRecipient a new Listener class is designed,

6 Implementation

called IDOServiceListener. Just like the other Listeners, thisclass is derived from the template class IDOListener<Sender,Recipient>, and the virtual functions requestSubEventType(...) and update(...) of the parent class are implemented.requestSubEventType(...) listens for the three subevent typesSERVICE_MESSAGE_RECEIVED_TRANSLATE, SERVICE_MESSAGE_RECEIVED_ROTATE and SERVICE_MESSAGE_RECEIVED_TEXTUREand the update(...) function calls the functions provided by theRecipient to handle them. The classes used to enable the Connectorto receive messages, and perform the actions that are related to them,are shown in figure 19. The sequence of action that results from receiv-ing a message to change a texture is described in figure 18.

A BPEL process invokesthe changeTexture() operation provided

by an IDOServiceConnector

The IDOServiceConnectorreceives the message

The IDOServiceListener callsthe IDOServiceConnectorRecipient

to handle the event

The IDOServiceConnectorSendernotifies the IDOServiceListener

The IDOServiceConnectorRecipient performsthe rotation

changeTexture(...) onRotate()

callListener(SERVICE_MESSAGE_RECEIVED, SERVICE_MESSAGE_RECEIVED_ROTATE)

handleServiceEventRotate(...)

Figure 18: UML activity diagram showing the sequence of actions that resultsfrom invoking a texture change.

6.3 The Connector Node Manager

All components needed to connect a scene object with a functional sim-ulation are now implemented. The next step is to design a class to man-age all the Connector Nodes. For this purpose, the IDOService-ConnectorManager class is implemented. This class is used to cre-ate, store and delete all the Connector Nodes and their Listeners.A new Connector Node is created by using the addConnector(IDOResourceID soID, int connectorType) function imple-mented in this class. The parameter soID specifies the scene object theConnector Node is created for, while the parameter connector-Type determines which type of Connector Node must be created.First, the function is checking if the scene object already has aConnector Node. To visually represent the Connector Node, a

6.3 The Connector Node Man-ager page 57

Figure 19: UML class diagram showing class involved in the deployment of a WebService interface and the handling of the actions requested by messagessend to that Web Service.

6 Implementation

scene object is created. This scene object has no geometry or ma-terial and can only be seen in the scene graph. It is appended as adirect child of the scene object for which it was created. The name ofthis scene object is composed of the String ”ConnectorNode” and thename of its parent scene object. Next the Connector is created byusing the connectorType parameter. Depending on the parameter,either an instance of the IDOToggleSwitchConnector class, theIDORotarySwitchConnector class, the IDOPushButton-Connector class, or the IDOTextureConnector class is created.So the IDOServiceConnectorManager is the factory for theseclasses. The thread that is created to run the Connector is givena name constructed out of the String ”connectorthread” and the ID ofthe scene object for which he is created. The ID of the scene objectthe Connector is created for and the ID of the scene object repre-senting the Connector Node are inserted in a std::map containercalled m_connectorIDs. This way, their relation is remembered andcan be used later. The Connector is also stored in a std::mapcontainer with the ID of the scene object he was created for as thekey element. This container is called m_connectorList. After this,the member variables for the Sender and the Recipient of theConnector are set. Finally, the two Listeners for the Connectorare created. Depending on the type of the Connector, either anIDOSceneObjectRotListener, an IDOSceneObjectTrans-lationListener, or in the case of an IDOTextureConnector noListener is created. The creation of the IDOServiceListener isdone in any of these cases. To create a Listener, the VDP framework de-ploys the template class IDOListenerCreator. Instead of creatingListeners by calling their constructor function, the create() func-tion of this class must be used. The Listener class which is meant tobe created is the template argument and the Sender, the Recipientand the event type are the parameters of the function. See listing 4for an example in which an IDOServiceListener is created. It isimportant to mention that the function addConnector(...) is justconstructing the Connector. To start the Connector, the thread inwhich the Web Service deployed by the Connector is running mustbe started. This is done by calling the startConnector(IDORe-sourceID soID) function provided by the IDOServiceConnectorclass.

6.3 The Connector Node Man-ager page 59

1 IDOListenerCreator : : c reate<IDOServiceListener >(m connectorList [ soID]−>getSender ( ) , m connectorList [ soID]−>ge tRec ip i en t ( ) , IDOEventType : :SERVICE MESSAGE RECEIVED) ;

4: Creating a Listener for the Web Service by using the create function providedby the IDOListenerCreator template class

The IDOServiceConnectorManager also provides a function todelete one Connector and one function to delete all Connectors.The function removeConnector(IDOResourceID soID) firstchecks if the scene object specified by the parameter soID has aConnector and if this is true, it performs all actions needed toremove this Connector and all the objects created for him. Firstthe Listeners created for the Connector are deleted. Then thethread in which the Web Service is running is shut down. The en-tries for the Connector made in the containers m_connectorListand m_connectorIDs are erased, and finally the scene object cre-ated to represent the Connector Node is removed from the scenegraph. The removeAllConnectors() function is basically doingthe same just for all the Connectors currently managed by theIDOServiceConnectorManager. Some helper functions are alsoimplemented for this class. The function sceneObjectHas-Connector(IDOResourceID soID) checks if the scene object spec-ified by the parameter soID has a Connector and returns a booleanvalue. The ID of the scene object for which a Connector was createdcan be obtained by calling the getSceneObjectID(IDOResourceIDconnectorID) function. To check if a port is already used by theWeb Service of an existing Connector, the functionportAlreadyInUse(int port) can be used, which returns aboolean value. The function rememberPort(int port) stores theport specified in the parameter port in a std::set container calledm_portList. This is used to remember all the ports that are alreadyused by the Web Services of the Connectors. To get an availableport, the function getFreePort() is called. This function checksthe container m_portList and returns a port that is not used by anyConnector. The ports suggested by this function range from 8082 to65535. Finally, the functions removePortFromList(int port)and resetPortList() can be used to erase one port from the portlist, to delete all ports stored in that list. In figure 20 a UML classdiagram for the IDOServiceConnectorManager class and all theclasses whose objects are managed by this class is shown.

6 Implementation

Figure 20: UML class diagram showing the IDOServiceConnectorManager classand all the classes managed by it.

6.4 The Graphical User Interface page 61

6.4 The Graphical User Interface

The characteristics of a VDP module have already been described insection6.1. In this section, it was mentioned that the Functionality-

ConnectorModule creates an instance of the class Functionality-ConnectorModuleUI when it is initialized. This class is responsi-ble for the graphical user interface of the module. Before the imple-mentation of this class and the class that is used to build the widgetfor the user interface is explained, it is necessary to look back at theConnector Node and consider all the information we need from theuser to build one and the things he will need when building a VirtualPrototype. The widget that is used for the menu of the module mustbe designed.

6.4.1 Designing the Modules Menu

The functional requirements and the user interface requirements de-fined in section 4.2 and section 4.4 also need to be regarded. The userinterface requirement UIR 1 demands that the GUI must allow theVP Developer to perform the actions defined in the functional require-ments FR 2.5.1 - 2.5.5. These actions correlate with the creation of aConnector Node, the removal of a Connector Node, the removalof all Connector Nodes, the storing of all configurations made dur-ing the construction of a Virtual Prototype, and the regeneration ofthat Virtual Prototype by loading the saved configurations. To per-form these actions, the user is provided with five buttons: a button tocreate a Connector Node, a button to remove a Connector Node,a button to save all Connector Nodes, a button to load previouslysaved Connector Nodes, and a button to reset all current config-urations (and thereby delete all the Connector Nodes created inthe current session). Since different types of Connectors are imple-mented for the different types of switches, the GUI must provide a wayto select the Connector which is best suited for a specific scene object.This is provided by using radio buttons. Before a Connector Nodecan be created, the scene object with which he is supposed to con-nect a functional simulation is needed. Selecting the scene objectis done by clicking on the according scene object node in the scenegraph, or by clicking on the geometric object for the scene object. Itis important to choose the correct node, otherwise the functional be-havior might not be simulated as planned. Finally the properties ofthe Connector Node must be specified. On account of the different

6 Implementation

types of Connectors, the settings needed for their creation may vary.An IDOToggleSwitchConnector, for example, needs the followingconfiguration parameters:

• Hostname: The host address for the Web Service deployed bythe Connector

• Port: The port through which the Web Service of this Connectorcan be contacted.

• Endpoint: The URL for the Web Service deployed by the BPELprocess which models the functional behavior of the scene objectthis Connector is created for. This is needed so the Web Serviceclient of this Connector knows which Web Service he must sendhis messages to.

• Associate: The associate is the object that may be affected bythe events caused by the scene object of this Connector. Forexample, if tilting a toggle switch must result in a colour change ofa control light, the Web Service deployed by the Connector cre-ated for this control light is the associate. The complete URL ofthe associate must be specified (e.g. http://localhost:18084/Ser-vice/services). The Web Service client of this Connector willsend the URL to the Web Service of his BPEL process. The pro-cess can dynamically invoke the Web Service of the associate, ifthe message he received resulted in a state change that affects theassociate.

• Rotation Threshold: The rotation threshold is used by thescene objects Listener to determine if the rotation was suffi-ciently large to require the sending of a message. The thresholdmust not be related to the functional behaviour of the scene ob-ject, it is just used to determine when to send the transformationdata. This way not every tiny transformation results in the send-ing of a message.

In contrast to the configuration parameters above, the parametersneeded to create an IDOTextureConnector are not all the same.An IDOTextureConnector does not need a rotation or a trans-lation threshold in fact he does not even need a Web Service client,because there is no transformation data to send. He will need a host-name and a port for his Web Service, so his texture can be changed byinvoking the Web Service. Also, it is necessary to specify a the direc-tory of a folder, where all the image files that can be used as texturesare located. To avoid confusing the user of the module, the input fields


for the configuration parameters need to be changed depending on theConnector type chosen by the user. Only the parameters necessaryfor the selected Connector must be displayed. The widget which isdesigned to provide all the features mentioned before can be seen in fig-ure 21. The image shows the widget in a state where the Connectortype for a toggle switch is selected.

Figure 21: Screenshot of the widget designed for the VDP module Functionalty-Connector.

6.4.2 Implementing the Actions Performed by the Buttons

The FunctionalityConnectorModuleWidget class is derived fromthe QWidget class to provide all the QT features and it is also derivedfrom the IDOListenerContainerRecipient class, so a Listenercan call it to handle the events noticed by him. All the buttons and in-put fields, which can be seen in figure 21, are defined in this class.By using the Signal-Slot concept of QT, the buttons are con-nected to the slots that perform the actions related to them. TheFunctionalityConnectorModuleWidget class creates an instanceof the IDOServiceConnectorManager, called m_Service-ConnectorManager and is using this instance in its functions. Tohold all the Connector Nodes created in a session, an instanceof the QT class QDomDocument, called m_domDocument, is used.This object is representing an XML document and can read or writethe document to a file. The XML document is used to save or loadConnector Node configurations. Another important member vari-able is a reference of the IDOPicker called m_UIPicker. This classprovided by the VDP framework is responsible for all mouse-related se-lection and clicking operations. It is used to get the scene object that iscurrently selected. The constructor of the FunctionalityConnector-ModuleWidget class first creates an empty QDomDocument witha root node named ”FunctionalObjects”. Next the instance of the

6 Implementation

IDOServiceConnectorManager class is created by calling its con-structor. The reference for the IDOPicker is obtained by requestingit from one of the main classes of the VDP, called IDOExploreApp.Finally all the QT objects like buttons, input fields and slots arecreated and the layout of the widget is defined to group those ele-ments. When the button ”Create Connector” is pressed, the signal ofthis event is handled by the slot createConnector(). This slotfirst checks if a scene object is selected by using the reference of theIDOPicker. If a scene object is selected, the slot checks if the sceneobject already has a Connector Node, and if not, if the port speci-fied by the user is already in use. This is done by calling the functionssceneObjectHasConnector(...) and portAlreadyInUse(...) provided by the IDOServiceConnectorManager. Depend-ing on the Connector type selected by the user, the slot creates the re-quested Connector Node by using the addConnector(...) func-tion of the Manager and sets all the configuration parameters for thatConnector Node. The parameters are then written to the XML filerepresented by the QDomDocument and at last the thread in which theConnector is running is started. To save the Connector Node thefunction saveFunctionalObjectToXML(IC::IDOFunctional-Object* functionalObj) is called. This function writes all theinformation contained in the parameter functionalObj to the XMLdocument represented by the QDomDocument. The parameter is aninstance of the class IDOFunctionalObject which is used to de-scribe a Connector Node. For more information on this class seethe section 6.5. The structure of the XML document is shown in fig-ure 8.

To remove a Connector Node, the user must select the scene ob-ject representing the Connector Node and then press the button”Remove Connector”. The slot removeConnector() executes therequired action. This slot first checks if a scene objects is selected byusing the IDOPicker. If this is true, the ID of the scene object ob-tained from the IDOPicker is used to get the name of the scene object.The QDomDocument is then searched for a FunctionalObject withthat name. If found, the complete entry for this FunctionalObjectis removed. The port used by the Web Service of the Connectorwhich is removed is deleted from the port list by calling the functionremovePortFromList(...) provided by the Manager. Finally theConnector Node is removed by calling the removeConnector(...) function of the Manager. If the button ”Save To XML File” ispressed, the slot saveToXMLFile() will perform the requested ac-


tion. A QFileDialog is used to enable the user to select a directorywhere the file should be stored and to either choose an existing XMLfile, or to give the name for the new file that must be created. TheQDomDocument which is holding all the Connector Node configu-rations is then written to that file. Loading such an XML file is doneby pressing the ”Load XML File” button whose signal is handled by theloadFromXMLFile() slot. This slot opens a QFileDialog, so theuser can specify the file he wants to load. The file name returned by thedialog is handed to the function loadFunctionalObjectsFromXML(...) as the parameter. This function then checks if the file can beopened for reading and if that is true the content of the XML file iswritten to a temporary QDomDocument. All the FunctionalObjectsstored in the XML file are read and the Connector Nodes andListeners are created. The newly loaded and created Connector-Nodes are written to the QDomDocument holding all the runningConnector Nodes. This way if the ”Save To XML File” button ispressed all Connector Nodes will be stored, ones that were createdmanually and the ones that were created by loading an XML file. If aFunctionalObject from the XML file is connected to a scene ob-ject which already has a Connector Node, the Connector Nodefor this object is not created. By pressing the ”Reset” button allConnector Nodes are deleted. The slot reset() calls the remove-AllConnectors() and the resetPortList() function of the Man-ager and clears the QDomDocument holding all the Functional-Objects. To display only those input fields needed for the selectedConnector type, the five slots for the radio buttons, which are usedto select that type, set the required input fields visible and hide thosewho are not required. The IDOTextureConnector needs a texturefolder specified so he knows where to get the images for the requestedtexture changes. This texture folder can be specified by pressing the”Browse” button under the input field called ”Texture location”. Press-ing this button will call his slot pressedBrowseButton(), whichwill open a QFileDialog to allow the user to find the directory wherethe images for this IDOTextureConnector are stored.

6.4.3 Handling Listener Events

The user interface requirement UIR 2 demands that the GUI of theVDP indicates that a scene object is connected to a functional simula-tion. This is already handled by the IDOServiceConnectorManagerwho creates a scene object to represent the Connector Node and ap-pends it as a direct child of the scene object for which it was created.

6 Implementation

To regard the user interface requirement UIR 3, which demands thatthe GUI must display the configuration of the Connector Node ifhis scene object is selected, it is necessary to listen for the scene objectswhich are selected. If a scene object is selected by clicking on it, it mustbe checked if this scene object is a Connector Node and if so, theconfigurations of this Connector Node must be displayed in the wid-get. This again calls for the use of a Listener. Another Listeneris needed to check if a new scene is loaded, because this requires thatall the Connector Nodes which are currently running must be de-stroyed. The Listener implemented to send an event if a sceneobject is selected is called IDOSceneObjectSelectedListener.TheSender for this Listener is the IDOPicker and the event sentby him is the SCENEOBJECT_ON_SELECT event. The IDOScene-ObjectSelectedListener calls the IDOFunctionalityCon-nectorModuleWidget as his Recipient to handle the event. Thefunction provided for this call is the handleSceneObjectSelected()function, which will set the appropriate radio button as checked and dis-play all the configurations of the Connector Node, if the scene objectselected is a Connector Node. If the selected scene object is not aConnector Node, default values are displayed and the Connectortype for a toggle switch is checked.To detect if a new scene is loaded, which would require that all the cur-rently active Connector Nodesmust be deleted, the IDOGUIListe-ner is implemented. The Sender for this Listener is the IDOExp-loreApp, which is the class representing the IDO:Explore application.This class provides the event type LOAD_FILES_STARTED. This eventis emitted if the user is loading a new scene. If this event is received, theIDOGUIListener calls his Recipient, the IDOFunctionality-ConnectorModuleWidget, to handle the event. For this purpose,the function handleNewFileLoaded() is offered by the widget class.Calling this function results in the removal of all Connector Nodesand the clearing of the port list via the IDOServiceConnectorMana-ger. Also, the QDomDocument holding all the FunctionalObjectsis reset.

6.4.4 Constructing the Module and its User Interface

The class designed to integrate the widget into the module and to imple-ment all the operations that need to be perfomed by the widget is calledIDOFunctionalityConnectorModuleWidget. The widget pro-vided by this class is used by the FunctionalityConnectorModule-UI class. This class only has one function, which is the constructorfunction. This constructor, among other things, creates the widget for

6.5 The Functional Object page 67

the module. If an instance of the class FunctionalityConnector-ModuleUI is created by calling its constructor, a reference to theIDOQT2DGUI object of the VDP is obtained and this reference is usedto get a reference of the IDOQTModuleUIManager. This again is usedto get the dockwindow widget of the VDP and use it as the parent wid-get for the new widget that is now created. The module itself, whichwas passed on as a parameter in the constructor call, and the newwidget are then added to the IDOQTModuleUIManager. Now themodule and its GUI object are created and linked to the VDP. The twoListeners needed by the modules widget are also created in the con-structor of the FunctionalityConnectorModuleUI class. By us-ing the template class IDOListenerCreator, the IDOGUIListenerand the IDOSceneObjectSelectedListener are created and sup-plied with their Sender and Recipient (see listing 5).

1 IDOListenerCreator : : c reate<IDOGUIListener>(IDOExploreApp : :g e tS ing l e tonPt r ( ) , moduleWidget , IDOEventType : :EXPLORE APPLICATION STATE CHANGED) ;

2 IDOListenerCreator : : c reate<IDOSceneObjectSe lectedListener >(p icker , moduleWidget , IDOEventType : :PICKED SCENEOBJECTS CHANGED) ;

5: Creating the two Listeners for the widget by using the create function providedby the IDOListenerCreator template class

A UML class diagram for all the classes described in this section seefigure 22.

6.5 The Functional Object

As described in section 6.2 the Connector Node is not a single ob-ject but rather a concept, which consists of a number of classes, whichthrough their interactions realize this concept. The main class in thisframework is of course the IDOServiceConnector, but withoutall the other classes this class is useless. Many parameters have tobe specified so that these classes can perform their duties. Some ofthe parameters are required by more than one class and thus a con-tainer class for all the parameters is designed. This class is calledIDOFunctionalObject. For every scene object that is connectedto a functional simulation, an instance of this class is created to hold allthe configurations necessary for the connection. Since the informationcontained in the IDOFunctionalObject is used by the IDOService-Connector and the IDOServiceConnectorRecipient, and theIDOServiceConnector is holding an instance of the IDOService-

6 Implementation

Figure 22: UML class diagram for all the classes related to the module and itsmenu.

6.5 The Functional Object page 69

ConnectorRecipient in the form of a member variable, the IDO-FunctionalObject will be stored in the IDOServiceConnector-Recipient. This way the parameters saved in the IDOFunctional-Object can be accessed by the IDOServiceConnectorRecipientwhich is held by the IDOServiceConnector which are created andstored by the IDOServiceConnectorManager, whose instance isheld by the IDOFunctionalityConnectorModuleWidget. Thelatter is using the IDOFunctionalObject when saving the config-uration settings of Connector Nodes to an XML file. The membervariable for an instance of the IDOFunctionalObject, held by theRecipient, is called m_functionalObj. The following parametersare held by this variable and can be accessed via get and set functions.

• m_connectorType is an integer value, which represents thetype of the Connector. For the scenario of this work, fourdifferent types of Connectors are implemented (see section re-fConnectorNode).

• m_clientAssociate is the URL for the Web Service of theConnector Node, which might be affected by this object’s func-tional behaviour.

• m_clientEndpoint is the URL of the BPEL process, which isresponsible for modeling this object’s functional behaviour.

• m_soID is the unique ID of the scene object for which this objectis created.

• m_soName is the name of the scene object for which this objectis created.

• m_port is the port which must be used to contact the Web Ser-vice of this object.

• m_host is the name of the host for the Web Service of this object.

• m_rotThreshold is the rotation threshold set for this object.

• m_transThreshold is the translation threshold set for this ob-ject.

• m_textureFolder is the directory were all the images whichcan be used as textures for this object are stored.

All these parameters are either set by the modules widget or by themanager class that creates the Connector Nodes.

6 Implementation

6.6 The BPEL Processes

To provide the functional behaviour for the Virtual Prototype, thatis build to simulate the cockpit scenario of this work, five BPEL pro-cesses are designed. These processes all model the functional relationsand behaviour of control devices that are located in the cockpit of anaircraft. The first process is called BPELToggleSwitchProcess.This process can be used to simulate a toggle switch, that changes thecolour of a control light if tilted. The toggle switch has three stateswhich are mapped to the colour green, yellow and red for the controllight. The process receives the angle of the toggle switch in an AxisAngle representation, the URL of the Web Service that is deployed forthe control light and the timestamp for the moment the message wassend by the toggle switch. The angle is used to map the position of thetoggle switch to the colour of the control light. If the angle is smallerthen -29.9 degrees the state -1 is set, if the angel is bigger then 29.9degree the state 1 is set and otherwise the state 0 is set. The processsends the state and the timestamp that was received to the controllight, by invoking the operation ChangeTexture(...) deployed bythe Web Service that was created for the scene object of the controllight. The process is built with the use of the BPEL editor provided byEclipse is shown in figure 23. The two processes used to model the re-lationship between a rotary switch and a monitor and the relationshipbetween a push button and a monitor are similar. The process for therotary switch is called BPELRotarySwitchProcess, this processmaps the rotation data received from the switch to four different states(0, 1, 2, 3) and then invokes the operation ChangeTexture(...)deployed by the Web Service specified in the associate parameter. TheBPELPushButtonProcess does the same, but due to the character-istcs of a push button, which only has two states, he can only map totwo different states, depending on the translation data he receives. Thetwo processes are shown in figure 24. A more complex BPEL processis built to simulate a scenario where two toggle switches must be set inthe same position to change a control light. Aside from mapping therotation data to a state, this process must also be able to discriminatethe two toggle switches which will send messages to him. In contrastto the processes described above, this process is not finished after pro-cessing one message. He must serve a number of requests before hecan be terminated. To remember the states he assigned to the two tog-gle switches, he is holding two variables, and to identify the differentswitches, he is also holding the ID received in the messages from thoseswitches. If a message is send to this process, he first checks the ID ofthe scene object that send the message. Depending on the ID he will

6.6 The BPEL Processes page 71

Figure 23: BPEL process for the toggle switch to control light scenario.

Figure 24: BPEL process modeling the functional relation of a rotary switch anda monitor.

6 Implementation

then assign the state to the appropriate state variable. If both statesare the same the process will call the ChangeTexture(...) opera-tion of the Web Service that was specified by the associate parameter.The process can be seen in figure 25. The last process is very simple.

Figure 25: BPEL process for the scenario of two toggle switches.

It was build to show the use of another Web Service operation besidesthe ChangeTexture(...) operation used in all the other processes.This process is called BPELRotationEchoProcess and it just takesthe rotation data it receives from a Connector Node and then in-vokes the Web Service specified in the associate parameter with the callfor the operation rotateSO(...) using this rotation data. This waythe scene object of the Connector Node that receives the invoke isrotated to the same degree as the object that caused the invoke. Thisprocess is used to connect the flight control stick with the root node

6.6 The BPEL Processes page 73

of the whole cockpit. When the flight control stick is tilted in any di-rection, the complete cockpit is tilted in the same direction. This way,the aircraft can be steered.

7 Deployment of the Module


7.1 User Guide for the Module

To use the module, the VDP first must be aware of its existence. Tointegrate the module into the VDP, it is necessary to edit the con-figuration file idoDefault.ini. The directory where the module isstored in form of a DLL file and the name of the module must be addedto this file. The directory with the location of the Dll file is insertedunder the category [Plugin.Paths]. The name of the module mustbe entered under the category [Plugin.Load].When these modifications are done the module is integrated into theVDP and can be selected by clicking on the red button in the moduletoolbar of the VDP. In case the user switches to another module, allthe threads for the Connector Nodes are kept alive; therefore, ifthe user switches back to the FunctionalityConnectorModulehe can continue work right where he left. Loading a new scene auto-matically causes the module to destroy all active threads, therefore theuser must consider this and save the configurations he made to an XMLfile if he intends to use them again later. Also by saving the configura-tion the user doesn’t have to create the Connector Nodes manuallyevery time he wants to build a Virtual Prototype. By loading an XMLfile created for a configuration that was created earlier the user canrecreate a previously constructed Virtual Prototype. Additionally itis possible to load several XML files, redundant Connector Nodeswhich are contained in more than one file will only be created once.If a scene object already has a Connector Node, it is not possibleto create a second. When saving the Connector Nodes it does notmatter if they were created manually or by loading an XML file; allactive Connector Nodes are written to the XML file. To remove aConnector Node, the user must select the scene object which wascreated to represent the Connector Node he wants to delete andthen press the ”Remove Connector” button. In order to delete all theConnector Nodes which are currently active he can press the ”Re-set” button. The configuration of a Connector Node is displayedin the modules menu, when the scene object which represents it is se-lected. In the following, an example is given for the construction of twoConnector Nodes, one for a toggle switch and one for a control light.

Before creating the Connector Node it is important to identify thescene object which is associated with the functional behaviour modeledby a BPEL process. The toggle switch used in this example is com-posed of several scene objects which, taken together, form the complete

7.1 User Guide for the Module page 75

object. Not all of these scene objects need to be moved to trigger thesequence of actions related to the function of this switch. For example,the base in which the switch is mounted must and cannot be moved.In addition just moving the head of the toggle switch would not be thedesired event. If the scene object node is found that together with allhis child nodes forms the object that must be connected to a BPELprocess, this object must be selected in the scene graph by clicking onit (see figure 26).

Figure 26: Selecting the appropriate scene object node in the scene graph.

After selecting the scene object, the type of the Connector Nodemust be selected. For this example, the ToggleSwitch Connector ischosen by clicking on the corresponding radio button. The followingsettings are entered to enable the Connector Node to connect theswitch with his BPEL process:

• Hostname: c10006x64

• Port: 18083

• Endpoint: http://c08052x64:8080/ode-axis2-war-1.3.4-SNAPSHOT/processes/BPELToggleSwitchService


• Associate: http://c10006x64:18084/Service/services

• Rotation Threshold: 30

Finally theConnector Node is created by pressing the ”Create Con-nector” button. The scene object to represent the Connector Nodeis appended as a direct child of the Connector Node’s scene ob-ject. The name of this scene object is composed of the word ”Con-nectorNode” and the name of its scene object. If this scene object isselected the settings of the Connector Node are shown in the menu(see figure 27). The Connector Node for the control light is cre-

Figure 27: Displaying the settings of a Connector Node.

ated by selecting the scene object which holds the texture depictingthe control light and choosing the Connector Node type ”TextureConnector” by checking the radio button for that type. The settingsfor this Connector Node are:

• Hostname: c10006x64

• Port: 18084

• Texture location: c:/Cockpit/ControlLightTextures/

7.1 User Guide for the Module page 77

The location of the folder containing the images that are used as tex-tures is specified by pressing the ”Browse” button and selecting thatfolder. The image files in that folder have to meet the following require-ments. The file name has to be composed of the name of the scene ob-ject plus an underline character plus an number correlating to the statesreceived from the BPEL process. All image files must be using the PNGfile format. In this case, the image files must be called ”Body 22 1.png”,”Body 22 0.png” and ”Body 22 -1.png”. Now that both scene objectshave a Connector, their functional relationship can be simulated. Ifthe user tilts the toggle switch by a degree bigger than the rotationthreshold, the Web Service client of the toggle switch sends the rota-tion data to the BPEL process BPELToggleSwitchProcess, whichwill map the rotation to a state and then invoke the Web Service opera-tion ChangeTexture(...) provided by the control light. Figure 28shows all three possible results of the simulated functional relationship.

Figure 28: On the left side the toggle switch is tilted by 30 degrees, in the middlethe toggle switch is in his default position and on the right the toggleswitch is tilted by -30 degrees.

For the final demonstrator that was for the scenario of this work, theBPEL processes BPEL2ToggleSwitchesProcess, BPELRotary-SwitchProcess, BPELPushButtonProcess and BPELRotation-Echo are used. The control light is set into relation to two toggleswitches, a rotary switch is connected with the monitor showing a map,a push button affects the weapons monitor and the rotation data fromthe flight control stick is used to steer the whole cockpit. All the con-trol devices and the objects which are related to them are shown infigure 29 and are marked red.


Figure 29: For the final demonstrator Connector Nodes for all the objects thatare marked red were created to connect them to their correspondingBPEL processes.

7.2 Extending the Module to Incorporate New Processes

New BPEL processes can be integrated in the existing framework byusing two different approaches. The most simple approach is to re-model one of the existing BPEL processes. This approach can only beused if one of the existing processes receives all the information thenew process would need. To connect a scene object to this remodeledprocess, no further changes to the module or one of its components areneeded. This approach is not very helpful since a new process wouldbe integrated at the cost of losing another. The second appoach isto build a completely new BPEL process and then extend the WebService client used by the VDP’s FunctionalConnectorModuleso he can contact the Web Service of the new process. Building anew BPEL process is easy. It can be done by using the open sourceBPEL editor provided by Eclipse, or any other way one might prefer.In this work, the editor provided by Eclipse was used. For instruc-tions on how to get started with this editor, the tutorial25 publishedby the Institute for Applied Information Technologie at the Univer-sity of Hannover was found to be quite helpful. Once the new BPEL

25http://www.se.uni-hannover.de/lehre/tutorials//BPEL-ODE-Eclipse.php

http://www.se.uni-hannover.de/lehre/tutorials//BPEL-ODE-Eclipse.php

http://www.se.uni-hannover.de/lehre/tutorials//BPEL-ODE-Eclipse.php

7.2 Extending the Module to In-corporate New Processes page 79

process is built the WSDL file describing the Web Service of that pro-cess can be used to create all the files needed for the modules WebService client. To exemplify the modifications that have to be doneto integrate a new process into the module, the integration of theBPEL2ToggleSwitchesProcess into the module is described indetail. An existing Connector Node is extended to allow commu-nication with this process. The IDOToggleSwitchConnector isalready able to communicate with the BPELToggleSwitchProcessat this point. The function handleSOEvent(...) of his Recipientis calling the sendToggleSwitch(...) function of its Web Serviceclient in the event of a rotation. This function of the client must beextended, so he can also send the information to the new process. Tocreate client stubs for the module’s Web Service client the gSOAP toolswsdl2h and soapcpp2 are used. The steps performed to extend thefunction are the following:

1. Copy the WSDL file provided by the BPEL process into an emptyfolder.

2. Open the WSDL file and remove the line specifying the import forthe Web Service description of the VDP module. In the file cre-ated for the BPEL2ToggleSwitchesProcess, this line lookslike this:

1 <import l o c a t i o n=”ns . wsdl ” namespace=”h t t p : // tempuri .org /ns . xsd/ S e r v i c e . wsdl ”/>

6: Line which needs to be removed from the Web Service description ofthe BPEL2ToggleSwitchesProcess.

3. Open a console and type the command

wsdl2h -o BPEL2ToggleSwitches.hBPEL2ToggleSwitchesProcessArtifacts.wsdl

to create the C++ header file with service operation definitionsand types for the operation’s data.

4. Open the created header file and encapsule the contained classwith a namespace. For this example the namespace IDO2Toggle-SwitchesClient is set. The encapsulation in a namespace isnecessary so the Web Service client of the module can distinguishall the different clients created for the BPEL processes.


5. To create the client stub and XML serialization routines with theuse of gSOAP type the following command:

soapcpp2 -i -C -n -pIDO2ToggleSwitchesClient -I”C:\ProgrammFiles\gsoap-2.7\gsoap\import” BPEL2ToggleSwitches.h

The -i option indicates that we want C++ proxy and server ob-jects that include the client code, the -C option is used to onlygenerate the files needed for a client and the -I option specifiesthe directory from which the stlvector.h file can be imported. Formore information on how to build a client with the use of gSOAP,see the User Guide for gSOAP 2.7.17 by Engelen (2010), espe-cially the section 19.33 ”How to build a Client or Server in a C++Namespace” and the section 19.34 ”How to Create Client/ServerLibraries”.

6. Go to the WSClient folder located in the source code folder ofthe module and create a new folder for the files created with thegSOAP tools and copy them into this folder. It is important toalso insert the stdsoap.h file into this folder.

7. Open the IDOWSClient.cpp file and include the IDO...Bind-ingProxy.h and the IDO2ToggleSwitchesClient.nsmapfiles. Now the sendToggleSwitch(...) can be extended toinvoke the Web Service of the new process. The already existingcode can be used for help.

8. Edit the CMakeList.txt file of the module. The files IDO...-BindingProxy.cpp and IDO2ToggleSwitchesClientC.cpp must be listed.

After having done all these things, the solution for the module must beremade using CMake. Before the module can be rebuild using VisualStudio, it is necessary to open the properties for the stdsoap.cppfile by right-clicking on the file in the solution view. Select the optionC/C++ CommandLine and then the option Additional Options andenter -DWITH NONAMESPACES. The resulting source code for thesendToggleSwitch(...) function of the IDOWSClient can beseen in listing 9.

8 Results and Validation

The main goal of this work is to add the possiblity of simulatingfunctional behaviour and relationships within Virtual Prototypes. Toachieve this goal, the VR System which is used to display the Vir-tual Prototype is bidirectinally coupled with functional simulations.The functional simulations are only utilized to model the functionalbehaviour of the Virtual Prototype and are not themselves used toperform any tests. Because of this, it is not necessary to regard thereaction time respectivly the transmit time. The functional behaviourmust not be performed or displayed in realtime, although an interac-tion with a scene object must directly result in the appropiate event.It is not important if the reaction to an interaction is executed withina hundredth or a tenth of a second, but the user of the prototype musthave the feeling that it happens immediately. This is achieved by thesolution presented in this work.Since another solution for the exact same task formulation and sce-nario was developed before this work by Seidel (2009), the quality ofthe class framework presented in this work can be assessed by compar-ing the two. To have some objective criterias, the Source Lines of Codemeasurements are applied. The two different approaches and the fea-tures provided by them are compared and the complexity of the codewhich implements them, represented by the Lines of Code, is set intorelation with them. The Source Lines of Code measurements are ofcourse not the main criteria used to determine the quality. Other crite-rias like extensibility, documentation, interoperability or usability playa much more important role in the evaluation process. First, the SourceLines of Code measurements for both solutions are presented to give acomplete picture. The source code for the Web Service clients is notincluded, because it is not connected to the solution. Since the solutionsuggested by Seidel (2009) has no graphical user interface, two mea-surements for this works solution are given, one including the classesimplementing the GUI 10 and one without them 9. The source code forthe solution implemeted by Seidel (2009) includes the code written forthe IDOSwitchHandler plugin and the Mediator. The Source Lines ofCode measurements for his code are shown in table 8 For more detailson these two components see section 2.

Both solutions are able to address the main scenario, which is to con-nect switches with displays. In other words, a transformation of a sceneobject can result in a texture change for another scene object. TheIDOSwitchHandler plugin developed by Seidel (2009) requires a user


Table 8: Source Lines of Code measurements for the plugin developed by Seidel(2009).

Measurement Count

Source Files 24

Lines of Code 2449

Blank Lines of Code 560

Physical Executable Lines of Code 1385

Logical Executable Lines of Code 836

Code and Comment Lines of Code 13

Comment Only Lines of Code 504

Commentary Words 2107

Table 9: Source Lines of Code measurements for the FunctionalityConnectorMod-ule without the Classes implemented for the module’s GUI.

Measurement Count

Source Files 34

Lines of Code 3169







Table 10: Source Lines of Code measurements for the FunctionalityConnector-Module including the Classes implemented for the modules GUI.

Measurement Count

Source Files 40

Lines of Code 4458







interaction with a scene object to trigger the texture change, whereasthe FunctionalityConnector module, implemented for this work, allowsthe invocation of a texture change at all times and without any precon-ditions. Additionally this work also provides a way to trigger rotationsor translations from outside of the VR system. The plugin connects theVDP with the simulation tool Rhapsody and the coupling of the twoindepentent simulations is very strong. To allow communication, theMediator component must map the scene objects and their state to anevent inside Rhapsody. To perform this mapping, the user has to pro-vide an xml description of the switches, a configuration file in which thetexture scene object for each switch and the image files for this textureobject must be specified and a mapping table for the Mediator in whichevery switch scene object and all its possible states are set into relationwith their corresponding Rhapsody events. The module developed dur-ing this work only needs two kinds of information to connect a sceneobject with a functional simulation: the URL of a BPEL process’s WebService and the URL of the Web Service which is deployed for the sceneobject that might be affected by this scene object. The BPEL processesorchestrate all the invocations received from and send to the VDP andcan also be used to simulate functional behaviour themselves. The cou-pling implemented for the module is therefore very loose. Because themodule can be used to connect scene objects to different simulationtools it has a high interoperability, whereas the plugin which can onlybe used to connect a scene object to a Rhapsody simulation has a lowinteroperability. Extending the module to incorporate new functionalbehaviour is simple, only one function in the Web Service client classmust be edited. The plugin can also easily be extended by creating therequired XML switch description, the configuration file for the pluginand the mapping table for the Mediator. But this extensions can onlyincorporate functional behaviour linked to the switch-texture scenario.Adding functional behaviour for other scenarios would require muchwork. As a result the extensibility of the module is better then theextensibility of the plugin. By providing a graphical user interface,which can be used to create all the connections for the scene objects,the module also has a better usability and is more user-friendly. TheDoxygen documentation standard was used for the documentation ofthe module’s source code. This allows future developers to generate anup-to-date reference for the software. The source code of the plugin isdocumented, but without using any standards which allow the genera-tion of references. This, and the fact that the number of commentarywords included in the modules source code is 6437 (respectivly 7362 ifincluding the code for the GUI) and the plugin only has 2107 commen-


tary words, results in a better quality of the modules documentation.The IDOSwitchHandler plugin and the Mediator together have a totalof 2449 lines of code with 1385 physical executable and 836 logical ex-ecutable lines. This is less then the number of lines for the modulessource code (see table 9 and 10). But since the module offers morefeatures and can be applied for a bigger range of scenarios, the higheramount of source code lines is justified. It does not mean that the codewritten for the module is less effective. As a result of all the charac-teristics of the two solutions, the Service Oriented Architecture used inthe FunctionalityConnector module, is better suited to add functionalbehaviour to a Virtual Prototype.

Because of the cockpit control device scenario the Connector classesfor a toggle switch, a rotary switch and a push button were implemeted.These classes can be traded for more generalized classes. The Connec-tor class for the toggle switch and the rotary switch can be merged intoa Connector class for rotating objects. Both classes are basically thesame anyway and are just implemeted separately to address the switchspecific scenario of this work. The push button class can be renamedinto a Connector class for translated objects. A Connector classfor an object which can be rotated as well as translated, and the Lis-tener class for this Connector are already provided as a framework.Unfortunately both of these classes could not be finished in time, but donot require much more work to be fully implemented and incorporatedinto the module.

9 Conclusion

The main goal of this work is to enhance Virtual Prototypes by addingfunctional behaviour to the scene objects of which the prototype con-sists. This goal is achieved by designing a Service Oriented Archi-tecture, which allows users to bidirectionally couple the independentsimulation tools. The scene objects inside the VDP can be trans-formed and their textures can be changed by invoking Web Serviceoperations provided by Connector Nodes. Therefore, all possibleactions or events which might need to be triggered from outside can betriggered from outside of the VDP by invoking these operations. It isalso possible to create Web Service clients to inform a functional sim-ulation about interactions with scene objects. This way interactionswith scene objects performed by the user of the VDP can be set intorelation with their functional behaviour and relationship. The loosecoupling of the simulations is accomplished by using Web Services toprovide an interface for the VDP and by using BPEL processes to or-chestrate any operation calls sent by or to the VDP. The Apache ODE,which is used to run the BPEL processes, can map all incoming op-eration calls to their associated Web Services. As a consequence, theindependence of the simulation tools is maintained and the principleof Separation of Concerns is met. Another important requirement forthe construction of a Virtual Prototype is that the construction of theprototype must be simple and may not consume a large amount oftime. Due to the graphical user interface provided by the VDP mod-ule this requirement is fulfilled on the side of the VR system. For thepart of the functional simulation this requirement is also met, becausethe effort which is necessary to build a BPEL process and create aWeb Service client to contact this process is small. The integration ofthe BPEL2ToggleSwitchesProcess, for example, only took aboutone hour. Once the BPEL processes are constructed and the Web Ser-vice clients for these processes are integrated into the VDP module,the Virtual Prototype can be built using the graphical user interfaceprovided by the module. No expert or even advanced knowledge ofany kind is required to operate the graphical user interface. Creatingthe Connector Nodes to connect the scene objects with functionalsimulations is easy and consumes almost no time. Switching betweendifferent cockpit configurations can be done within moments by loadingpreviously created and saved Connector Node settings which weremade for the different cockpits. Thus different prototypes can directlybe compared.Possible extensions for the solution presented in this work can, for ex-

9 Conclusion

ample, address an automated generation of Web Service clients for theBPEL processes. If this can be done, the user of the VDP modulewould just have to specify the URL of a BPEL process’s Web Servicehis Connector Node is connected to and the client for this Web Ser-vice is created automatically. Also, the information required by theBPEL process must be identified, provided and asserted autonomicallyby the module. Another interesting field to look at is the automatic dis-covery of services, or the composition of Web Services to automaticallycreate new BPEL processes.

REFERENCES page 87

References

Web services architecture. Technical report, World Wide Web Consor-tium, February 2004a.

A. Alves, A. Arkin, S. Askary, B. Bloch, F. Curbera, Y. Goland,N. Kartha, Sterling, D. Konig, V. Mehta, S. Thatte, D. van derRijn, P. Yendluri, and A. Yiu. Web services business process exe-cution language version 2.0. OASIS Committee Draft, May 2006.

T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Ley-mann, K. Liu, D. Roller, D. Smith, S. Thatte, I. Trick-ovic, and S. Weerawarana. BPEL4WS, Business ProcessExecution Language for Web Services Version 1.1. IBM,2003. URL http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel/ws-bpel.pdf.

H.-J. Bullinger, R. Breining, W. Bauer, V. Reality, and F. Iao. Virtualprototyping - state of the art in product design, 1999.

R. Chinnici, H. Haas, A. A. Lewis, J.-J. Moreau, D. Orchard, andS. Weerawarana. Web services description language (wsdl) version2.0 part 2: Adjuncts. World Wide Web Consortium, Recommen-dation REC-wsdl20-adjuncts-20070626, June 2007.

C. Conn, J. Lanier, M. Minsky, S. Fisher, and A. Druin. Virtualenvironments and interactivity: windows to the future. In SIG-GRAPH ’89: ACM SIGGRAPH 89 Panel Proceedings, pages 7–18, New York, NY, USA, 1989. ACM. ISBN 0-89791-353-1. doi:http://doi.acm.org/10.1145/77276.77278.

R. Engelen. Web services glossary, May 2010. URL http://www.cs.fsu.edu/~engelen/soapdoc2.html.

E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design patterns: el-ements of reusable object-oriented software. Addison-Wesley Long-man Publishing Co., Inc., Boston, MA, USA, 1995.

R. B. Grady and D. L. Caswell. Software metrics: establishing acompany-wide program. Prentice-Hall, Inc., Upper Saddle River,NJ, USA, 1987. ISBN 0-13-821844-7.

M. Gudgin, M. Hadley, N. Mendelsohn, J.-J. Moreau, H. F. Nielsen,A. Karmarkar, and Y. Lafon. Soap version 1.2 part 1: Messag-ing framework (second edition), W3C recommendation. Techni-cal report, W3C, 2007. URL http://www.w3.org/TR/2007/REC-soap12-part1-20070427/.

http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel/ws-bpel.pdf

http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel/ws-bpel.pdf

http://www.cs.fsu.edu/~engelen/soapdoc2.html

http://www.cs.fsu.edu/~engelen/soapdoc2.html

http://www.w3.org/TR/2007/REC-soap12-part1-20070427/

http://www.w3.org/TR/2007/REC-soap12-part1-20070427/

REFERENCES

IDO:Develop Programmers Guide - VDP 2007. IC:IDO, 2007.

E. IEEE. Ieee std 610.12-1990(r2002). IEEE Standard Glossary ofSoftware Engineering Terminology, 1990.

J. J. Moreau, R. Chinnici, A. Ryman, and S. Weerawarana. Web ser-vices description language (WSDL) version 2.0 part 1: Core lan-guage. Candidate recommendation, W3C, March 2006.

B. Mueck, M. Fischer, W. Dangelmaier, W. Klemisch, H. Nixdorf, andH. Nixdorf. Bi-directional coupling of simulation tools a with walk-through system, 2002.

S. Prof. Dr. Mueller. Introduction for virtual reality and augmented re-ality. http://userpages.uni-koblenz.de/~cg/ws0910/VRAR/01_einfuehrung.pdf, 2009.

G. D. Rehn, M. Lemessi, J. M. Vance, and D. V. Dorozhkin. Integrat-ing operations simulation results with an immersive virtual realityenvironment. In WSC ’04: Proceedings of the 36th conference onWinter simulation, pages 1713–1719. Winter Simulation Confer-ence, 2004. ISBN 0-7803-8786-4.

R. Schubotz. Bridging 3d graphics and web services. 2009.

F. Seidel. Interaktive kopplung virtueller produktmodelle mit funk-tionalen systemmodellen, 2009.

W. R. Sherman and A. B. Craig. Understanding Virtual Reality: Inter-face, Application, and Design. Morgan Kaufmann Publishers Inc.,San Francisco, CA, USA, 2002. ISBN 1558603530.

A. Stork, P. Schneider, C. Clauss, A. Schneider, T. Bruder, andT. Farkas. Towards more insight with functional digital mockup.2009. URL http://publica.fraunhofer.de/documents/N-101622.html.

S. Strassburger, T. Schulze, M. Lemessi, and G. D. Rehn. Temporallyparallel coupling of discrete simulation systems with virtual realitysystems. In WSC ’05: Proceedings of the 37th conference on Wintersimulation, pages 1949–1957. Winter Simulation Conference, 2005.ISBN 0-7803-9519-0.

I. E. Sutherland. The ultimate display. In Proceedings of the IFIPCongress, pages 506–508, 1965.

http://userpages.uni-koblenz.de/~cg/ws0910/VRAR/01_einfuehrung.pdf

http://userpages.uni-koblenz.de/~cg/ws0910/VRAR/01_einfuehrung.pdf

http://publica.fraunhofer.de/documents/N-101622.html

http://publica.fraunhofer.de/documents/N-101622.html

REFERENCES page 89

B. The Eclipse Foundation. Bpel project. http://www.eclipse.org/bpel/, July 2010.

W3C. Soap version 1.2 part 0: Primer (second edition). online, April2007. URL http://www.w3.org/TR/soap12-part0/. W3CRecommendation.

G. W3C. Web services glossary, February 2004b. URL http://www.w3.org/TR/ws-gloss/.

G. G. Wang and A. Professor. Definition and review of virtual pro-totyping abstract. 2008. URL http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.94.567.



http://www.w3.org/TR/soap12-part0/

http://www.w3.org/TR/ws-gloss/

http://www.w3.org/TR/ws-gloss/

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.94.567

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.94.567

LIST OF FIGURES

List of Figures

1 UML-diagram with the design for the switch descriptionintroduced by Seidel (2009). . . . . . . . . . . . . . . . 10

2 software architecture for coupling Rhapsody with theVDP introduced by Seidel (2009). . . . . . . . . . . . . 11

3 Simulating a toggle switch in Rhasopy with the use ofSysML . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Webinterface provided by Rhapsody . . . . . . . . . . . 11

5 Reference Model for Virtual Reality. . . . . . . . . . . 15

6 Use case diagram for the scenario where the module willbe used by the Test Pilot. . . . . . . . . . . . . . . . . 23

7 Use case diagram for the scenario where the module willbe used by the VP Developer. . . . . . . . . . . . . . . 24

8 Use case diagram for the VR System and the FunctionalSimulation. . . . . . . . . . . . . . . . . . . . . . . . . 25

9 Toggle switch with a lock mechanism. . . . . . . . . . . 33

10 Architecture of the system developed for this work. . . 37

11 GUI of Eclipses open source BPEL editor. . . . . . . . 37

12 Plugin and module architecture of the VDP. . . . . . . 42

13 UML class diagram of the FunctionalityConnectorMod-ule and the FunctionalityConnectorModuleUI class. . . 43

14 UML class diagram showing the different specialised Connectorclasses and their parent class. . . . . . . . . . . . . . . 44

15 UML class diagram with all the classes used to processuser interaction. . . . . . . . . . . . . . . . . . . . . . . 46

16 UML activity diagram describing the actions caused bya user interaction with a toggle switch. . . . . . . . . . 48

17 UML class diagram showing the IDOWSClient class andits relation to the IDOServiceConncetorRecipient class. 51

18 UML activity diagram showing the sequence of actionsthat results from invoking a texture change. . . . . . . 56

19 UML class diagram showing class involved in the deploy-ment of a Web Service interface and the handling of theactions requested by messages send to that Web Service. 57

20 UML class diagram showing the IDOServiceConnector-Manager class and all the classes managed by it. . . . . 60

21 Screenshot of the widget designed for the VDP moduleFunctionaltyConnector. . . . . . . . . . . . . . . . . . . 63

22 UML class diagram for all the classes related to the mod-ule and its menu. . . . . . . . . . . . . . . . . . . . . . 68

LIST OF FIGURES page 91

23 BPEL process for the toggle switch to control light sce-nario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

24 BPEL process modeling the functional relation of a ro-tary switch and a monitor. . . . . . . . . . . . . . . . . 71

25 BPEL process for the scenario of two toggle switches. . 7226 Selecting the appropriate scene object node in the scene

graph. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7527 Displaying the settings of a Connector Node. . . . . 7628 On the left side the toggle switch is tilted by 30 degrees,

in the middle the toggle switch is in his default positionand on the right the toggle switch is tilted by -30 degrees. 77

29 For the final demonstrator Connector Nodes for allthe objects that are marked red were created to connectthem to their corresponding BPEL processes. . . . . . 78

30 UML class diagram of the FunctionalityConnectorModule.101

LIST OF TABLES

List of Tables

1 Functional Requirements Part 1 . . . . . . . . . . . . . 262 Functional Requirements Part 2 . . . . . . . . . . . . . 273 Functional Requirements Part 3 . . . . . . . . . . . . . 284 Technical Requirements Part 1 . . . . . . . . . . . . . . 285 Technical Requirements Part 2 . . . . . . . . . . . . . . 296 User Interface Requirements . . . . . . . . . . . . . . . 297 Quality Requirements . . . . . . . . . . . . . . . . . . . 308 Source Lines of Code measurements for the plugin de-

veloped by Seidel (2009). . . . . . . . . . . . . . . . . . 829 Source Lines of Code measurements for the Function-

alityConnectorModule without the Classes implementedfor the module’s GUI. . . . . . . . . . . . . . . . . . . 82

10 Source Lines of Code measurements for the Functional-ityConnectorModule including the Classes implementedfor the modules GUI. . . . . . . . . . . . . . . . . . . . 82

LISTINGS page 93

Listings

1 Basic structure of a SOAP message. . . . . . . . . . . . 202 C++ header file used by the gSOAP tool soapcpp2 to

create a Web Service . . . . . . . . . . . . . . . . . . . 523 C++ header file defining the event type for receiving a

message via the Web Service of an IDOServiceConnectorobject . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4 Creating a Listener for the Web Service by using the cre-ate function provided by the IDOListenerCreatortemplate class . . . . . . . . . . . . . . . . . . . . . . . 59

5 Creating the two Listeners for the widget by using thecreate function provided by the IDOListenerCreatortemplate class . . . . . . . . . . . . . . . . . . . . . . . 67

6 Line which needs to be removed from the Web Servicedescription of the BPEL2ToggleSwitchesProcess. 79

7 WSDL file describing a service with an operation for atexture change. . . . . . . . . . . . . . . . . . . . . . . 94

8 Exemplary XML File for Connector Node configura-tions. A Connector Node for a toggle switch and acontrol light, for a rotary switch and a monitor and for apush button and another monitor are contained in this file 96

9 Source code for the sendToggleSwitch(...) func-tion invoking either the BPELTogleSwitchProcess,or the BPEL2ToggleSwitchesProcess. . . . . . . 98

LISTINGS

7: WSDL file describing a service with an operation for a texture change.

1 <?xml version=”1 .0 ” encoding=”UTF−8”?>2 <d e f i n i t i o n s name=”S e r v i c e ”3 targetNamespace=”h t tp : // tempuri . org /ns . xsd/ S e r v i c e . wsdl ”4 xmlns : tns=”h t tp : // tempuri . org /ns . xsd/ S e r v i c e . wsdl ”5 xmlns:SOAP−ENV=”h t tp : // schemas . xmlsoap . org / soap / enve lope / ”6 xmlns:SOAP−ENC=”h t t p : // schemas . xmlsoap . org / soap / encoding / ”7 xmlns :x s i=”h t tp : //www. w3 . org /2001/XMLSchema−i n s t anc e ”8 xmlns:xsd=”h t tp : //www. w3 . org /2001/XMLSchema”9 xmlns:ns=”h t tp : // tempuri . org /ns . xsd ”

10 xmlns:SOAP=”h t tp : // schemas . xmlsoap . org / wsdl / soap / ”11 xmlns:MIME=”h t tp : // schemas . xmlsoap . org / wsdl /mime/ ”12 xmlns:DIME=”h t t p : // schemas . xmlsoap . org /ws/2002/04/ dime/

wsdl / ”13 xmlns:WSDL=”h t t p : // schemas . xmlsoap . org / wsdl / ”14 xmlns=”h t t p : // schemas . xmlsoap . org / wsdl / ”>15

16 <types>17

18 <schema targetNamespace=”h t t p : // tempuri . org /ns . xsd ”19 xmlns:SOAP−ENV=”h t tp : // schemas . xmlsoap . org / soap / enve lope /

”20 xmlns:SOAP−ENC=”h t t p : // schemas . xmlsoap . org / soap / encoding /

”21 xmlns :x s i=”h t tp : //www. w3 . org /2001/XMLSchema−i n s t anc e ”22 xmlns:xsd=”h t tp : //www. w3 . org /2001/XMLSchema”23 xmlns:ns=”h t tp : // tempuri . org /ns . xsd ”24 xmlns=”h t t p : //www. w3 . org /2001/XMLSchema”25 elementFormDefault=”u n q u a l i f i e d ”26 attr ibuteFormDefau l t=”u n q u a l i f i e d ”>27 <import namespace=”h t t p : // schemas . xmlsoap . org / soap /

encoding / ” schemaLocation=”h t t p : // schemas . xmlsoap . org /soap / encoding / ”/>

28 < !−− opera t ion r e que s t e lement −−>29 <element name=”changeTexture ”>30 <complexType>31 <sequence>32 <element name=”s t a t e ” type=” x s d : i n t ” minOccurs=”1 ”

maxOccurs=”1 ”/>33 <element name=”timestamp ” type=” x s d : i n t ” minOccurs=”1 ”

maxOccurs=”1 ”/>34 </ sequence>35 </complexType>36 </ element>37 < !−− opera t ion response element −−>38 <element name=”s igna lResponse ”>39 <complexType>40 <sequence>41 </ sequence>

LISTINGS page 95

42 </complexType>43 </ element>44

45 </ types>46

47 <message name=”changeTexture ”>48 <part name=”parameters ” element=”ns:changeTexture ”/>49 </message>50

51 <message name=”s igna lResponse ”>52 <part name=”parameters ” element=”ns : s i gna lRe spons e ”/>53 </message>54

55 <portType name=”ServicePortType ”>56 <opera t i on name=”changeTexture ”>57 <documentation>S e r v i c e d e f i n i t i o n o f func t i on

ns changeTexture</ documentation>58 <input message=”tns :changeTexture ”/>59 <output message=”t n s : s i g n a l R e s p o n s e ”/>60 </ opera t i on>61 </portType>62

63 <binding name=”S e r v i c e ” type=”tns :Serv i cePortType ”>64 <SOAP:binding s t y l e=”document ” t ranspo r t=”h t tp : // schemas .

xmlsoap . org / soap / http ”/>65 <opera t i on name=”changeTexture ”>66 <SOAP:operation soapAction=””/>67 <input>68 <SOAP:body par t s=”parameters ” use=” l i t e r a l ”/>69 </ input>70 <output>71 <SOAP:body par t s=”parameters ” use=” l i t e r a l ”/>72 </ output>73 </ opera t i on>74 </ binding>75

76 <s e r v i c e name=”S e r v i c e ”>77 <documentation>gSOAP 2 . 7 . 1 5 generated s e r v i c e d e f i n i t i o n</

documentation>78 <port name=”S e r v i c e ” binding=” t n s : S e r v i c e ”>79 <SOAP:address l o c a t i o n=”h t tp : // l o c a l h o s t : 8 0 ”/>80 </ port>81 </ s e r v i c e>82

83 </ d e f i n i t i o n s>

LISTINGS

8: Exemplary XML File for Connector Node configurations. A ConnectorNode for a toggle switch and a control light, for a rotary switch and a monitorand for a push button and another monitor are contained in this file

1 < !DOCTYPE Funt iona lObjec t sL i s t>2 <Funt iona lObjects>3 <Funct iona lObject name=”Rocker Switch Head11 ” >4 <FunctionalObjectType Type=”1 ” />5 <FunctionalObjectID ID=”4306 ” />6 <WebServiceIOPropert ies>7 <WebServiceHostName Host=”c10006x64 ” />8 <WebServicePort Port=”18083 ” />9 <ClientEndpoint Endpoint=”h t tp : // c08052x64:8080 /ode/

p r o c e s s e s / BPELToggleSwitchService ” />10 <C l i e n t A s s o c i a t e Assoc ia t e=”h t tp : // c10006x64:18084 /

S e r v i c e / s e r v i c e s ” />11 </ WebServiceIOPropert ies>12 <Geometr icPropert i e s>13 <RotationThreshold Rotat ionThreshold=”30 ” />14 </ Geometr i cPropert i e s>15 </ Funct ionalObject>16 <Funct iona lObject name=”Body 22 ” >17 <FunctionalObjectType Type=”4 ” />18 <FunctionalObjectID ID=”4466 ” />19 <WebServiceIOPropert ies>20 <WebServiceHostName Host=”c10006x64 ” />21 <WebServicePort Port=”18084 ” />22 <ClientEndpoint Endpoint=”” />23 <C l i e n t A s s o c i a t e Assoc ia t e=”” />24 </ WebServiceIOPropert ies>25 <TextureFolder Locat ion=”C:\ cockp i t \

cockp i t v i ewpo int e rgonomic s \Texturen setNewState \CONTROLLIGHT” />

26 </ Funct ionalObject>27 <Funct iona lObject name=” 01 Knob Asb20 ” >28 <FunctionalObjectType Type=”2 ” />29 <FunctionalObjectID ID=”4358 ” />30 <WebServiceIOPropert ies>31 <WebServiceHostName Host=”c10006x64 ” />32 <WebServicePort Port=”18090 ” />33 <ClientEndpoint Endpoint=”h t tp : // c08052x64:8080 /ode/

p r o c e s s e s /BPELRotarySwitchService ” />34 <C l i e n t A s s o c i a t e Assoc ia t e=”h t tp : // c10006x64:18091 /

S e r v i c e / s e r v i c e s ” />35 </ WebServiceIOPropert ies>36 <Geometr icPropert i e s>37 <RotationThreshold Rotat ionThreshold=”40 ” />38 </ Geometr i cPropert i e s>39 </ Funct ionalObject>40 <Funct iona lObject name=”Body 6 ” >

LISTINGS page 97

41 <FunctionalObjectType Type=”4 ” />42 <FunctionalObjectID ID=”1611 ” />43 <WebServiceIOPropert ies>44 <WebServiceHostName Host=”c10006x64 ” />45 <WebServicePort Port=”18091 ” />46 <ClientEndpoint Endpoint=”” />47 <C l i e n t A s s o c i a t e Assoc ia t e=”” />48 </ WebServiceIOPropert ies>49 <TextureFolder Locat ion=”C:\ cockp i t \

cockp i t v i ewpo int e rgonomic s \Texturen setNewState \MapMonitor ” />

50 </ Funct ionalObject>51 <Funct iona lObject name=”Swi tch 1 nc l1 3 ” >52 <FunctionalObjectType Type=”3 ” />53 <FunctionalObjectID ID=”2026 ” />54 <WebServiceIOPropert ies>55 <WebServiceHostName Host=”c10006x64 ” />56 <WebServicePort Port=”18092 ” />57 <ClientEndpoint Endpoint=”h t tp : // c08052x64:8080 /ode/

p r o c e s s e s /BPELPushButton2Service ” />58 <C l i e n t A s s o c i a t e Assoc ia t e=”h t tp : // c10006x64:18093 /

S e r v i c e / s e r v i c e s ” />59 </ WebServiceIOPropert ies>60 <Geometr i cPropert i e s>61 <Trans lat ionThresho ld Trans lat ionThresho ld=”3 ” />62 </ Geometr i cPropert i e s>63 </ Funct ionalObject>64 <Funct iona lObject name=”Glass Monitor 3 2 ” >65 <FunctionalObjectType Type=”4 ” />66 <FunctionalObjectID ID=”1656 ” />67 <WebServiceIOPropert ies>68 <WebServiceHostName Host=”c10006x64 ” />69 <WebServicePort Port=”18093 ” />70 <ClientEndpoint Endpoint=”” />71 <C l i e n t A s s o c i a t e Assoc ia t e=”” />72 </ WebServiceIOPropert ies>73 <TextureFolder Locat ion=”C:\ cockp i t \

cockp i t v i ewpo int e rgonomic s \Texturen setNewState \WeaponsMonitor ” />

74 </ Funct ionalObject>75 </ Funt iona lObjects>

LISTINGS

9: Source code for the sendToggleSwitch(...) function invoking either theBPELTogleSwitchProcess, or the BPEL2ToggleSwitchesProcess.

1 #include ”ToggleSwitch / IDOToggleSwitchClientBindingProxy . h”2 #include ”ToggleSwitch / IDOToggleSwitchClient . nsmap ”3 #include ”2 ToggleSwitches /

IDO2ToggleSwitchesClientBindingProxy . h”4 #include ”2 ToggleSwitches / IDO2ToggleSwitchesClient . nsmap ”5 #include ”IDOWSClient . h”6 #include <time . h>7

8 void IDOWSClient : : sendToggleSwitch ( f loat angle , f loatrotXAxis , f loat rotYAxis , f loat rotZAxis , IC : :IDOFunctionalObject∗ fObj )

9 {10 s i z e t found ;11 found = m cl ientEndpoint . f i n d ( ”

BPEL2ToggleSwitchesService ”) ;12 i f ( found != std : : s t r i n g : : npos )13 {14 IDO2ToggleSwitchesClient : :

BPEL2ToggleSwitchesBindingProxyBPELService ;

15 BPELService . namespaces =IDO2ToggleSwitchesClient namespaces ;

16 BPELService . soap endpoint =m cl ientEndpoint . c s t r ( ) ;

17 IDO2ToggleSwitchesClient : :ns1 BPEL2ToggleSwitchesProcessRequest

r eque s t ;18 r eque s t . degree = ang le ;19 r eque s t . rotXAxis = rotXAxis ;20 r eque s t . rotYAxis = rotYAxis ;21 r eque s t . rotZAxis = rotZAxis ;22 r eque s t . endpoint = m c l i en tAs so c i a t e ;23 std : : s t r i ng s t r eam st rSt r ID ;24 int ID ;25 s t rSt r ID << fObj−>getSOID ( ) ;26 s t rSt r ID >> ID ;27 r eque s t . c a l l e r I D = ID ;28

29 struct timeb t i m e m i l l i ;30 f t ime (& t i m e m i l l i ) ;31 struct tm∗ t ime in f o ;32 t ime t t ;33 t = time (NULL) ;34 t ime in f o = l o c a l t i m e (&t ) ;35 int timestamp = ( ( ( t ime in fo−>tm hour ∗

10000) + ( t ime in fo−>tm min ∗ 100) +t ime in fo−>tm sec ) ∗ 1000) + t i m e m i l l i .

LISTINGS page 99

mi l l i tm ;36 r eque s t . timestamp = timestamp ;37

38 i f ( BPELService . i n i t i a t e (& reque s t ) ==SOAP OK)

39 {40 std : : cout << ”Angle ” << ang le << ”

send to BPEL−WS” << std : : endl ;41 }42 else43 {44 BPELService . s oap s t r eam fau l t ( std : :

c e r r ) ;45 }46 }47 else48 {49 IDOToggleSwitchClient : :

BPELToggleSwitchBindingProxy BPELService;

50 BPELService . namespaces =IDOToggleSwitchClient namespaces ;

51 BPELService . soap endpoint =m cl ientEndpoint . c s t r ( ) ; /∗ z .B. ”h t t p:// l o c a l h o s t :8080/ ode/ proce s s e s /BPELToggleSwitchService ”; ∗/

52 IDOToggleSwitchClient : :ns1 BPELToggleSwitchProcessRequest

r eque s t ;53 r eque s t . degree = ang le ;54 r eque s t . rotXAxis = rotXAxis ;55 r eque s t . rotYAxis = rotYAxis ;56 r eque s t . rotZAxis = rotZAxis ;57 r eque s t . endpoint = m c l i en tA s so c i a t e ;58

59 struct timeb t i m e m i l l i ;60 f t ime (& t i m e m i l l i ) ;61 struct tm∗ t ime in f o ;62 t ime t t ;63 t = time (NULL) ;64 t ime in f o = l o c a l t i m e (&t ) ;65 int timestamp = ( ( ( t ime in fo−>tm hour ∗

10000) + ( t ime in fo−>tm min ∗ 100) +t ime in fo−>tm sec ) ∗ 1000) + t i m e m i l l i .m i l l i tm ;

66 r eque s t . timestamp = timestamp ;67 std : : cout << ”timestamp : ” << timestamp <<

std : : endl ;

LISTINGS

68 std : : cout << ”Assoc ia t e : ” <<m c l i en tAs so c i a t e << std : : endl ;

69

70 i f ( BPELService . i n i t i a t e (& reque s t ) ==SOAP OK)

71 {72 std : : cout << ”Angle ” << ang le << ”

send to BPEL−WS” << std : : endl ;73 }74 else75 {76 BPELService . s oap s t r eam fau l t ( std : :

c e r r ) ;77 }78 }79 }

LISTINGS page 101

Figure 30: UML class diagram of the FunctionalityConnectorModule.

a service oriented architecture to couple virtual prototypes with functional...

Documents