Fusing Reality with the Virtual Reality of a Serious

(1)

Fusing Reality with the Virtual Reality of a Serious

Game

Mikael Svensson

November 4, 2010

Master’s Thesis in Computing Science, 30 credits Supervisor at BAE Systems H¨ agglunds: Johan Persson

Supervisor at CS-UmU: Jonny Pettersson Examiner: Fredrik Georgsson

Ume˚ a University

Department of Computing Science SE-901 87 UME˚ A

SWEDEN

(2)

(3)

Abstract

Real world military and civilian training causes hundreds of lethal accidents each year around the world. Until now the reality has been impossible to replace in civilian and military training. But with the emergence of serious games combined with the latest advances in 3d simulated environments Bohemia Interactive developed the COTS (Com- mercially Of The Shelf) game VBS2(Virtual BattleSpace 2). BAE Systems H¨ agglunds’

goal with this thesis is to investigate the potential of using VBS2 as the simulation platform in a new cost eﬀective and realistic vehicle training systems.

The major focus of this thesis is to ﬁnd a way to control vehicles in VBS2. After evaluating the tools available during this thesis project DSF (Device Simulation Frame- work) is chosen to control VBS2. DSF is used to solve the problem by simulating a USB HID Joystick which controls VBS2 through DirectInput. This thesis therefore contains an in-depth study of the USB2.0 protocol, the HID protocol, and the DSF framework.

The thesis shows in the end a prototype that can control VBS2 or any other game that

supports DirectInput. The thesis also reveals a general design of the core of the vehicle

trainer that connects the hardware simulator SimBas with VBS2.

(4)

ii

(5)

List of Figures

4.1 Figure of the general driver stack composed with knowledge from Mi- crosoft MSDN. . . . 9 4.2 A conceptual image of the driverstack under DirectInput composed with

knowledge from Microsoft MSDN. . . . . 11 5.1 A combined image of the driverstack under DirectInput and the DSF

architecture composed with knowledge from Microsoft MSDN. . . . . . 15 5.2 An image of the DSF object hierarchy composed with knowledge from

Microsoft MSDN. . . . 16 5.3 An image of the USB2.0 descriptors composed with knowledge from Mi-

crosoft msdn and the USB2.0 speciﬁcation. . . . . 17 5.4 An image of a report descriptor that describe a HID Joystick.The ﬁg-

ure is composed with knowledge from HID class specification,the USB2.0 specification, and HID usage tables specification. . . . 22 6.1 A conceptual image of the system. . . . 28 6.2 The state chart for the simulated HID device. . . . 30 7.1 A screenshot in Windows showing the prototype just after it have moved

the simulated joystick. . . . 36

v

(8)

vi LIST OF FIGURES

(9)

List of Tables

5.1 Table over items in ﬁgure 5.4. . . . 23 5.2 Table over the attribute ﬁeld of the input item. . . . 24 6.1 Table over the objects that is initiated. . . . 31

vii

(10)

viii LIST OF TABLES

(11)

Chapter 1

Introduction

This master thesis was done at BAE Systems H¨ agglunds head quarters in ¨ Ornsk¨ oldsvik as a thesis for the degree of Master in computing science and engineering at Ume˚ a University. The thesis work started of as an investigation in how to solve the problem of making cheaper and better training simulators for BAE Systems H¨ agglunds different Vehicles. This by using COTS(commercially off the shelf) games and more specific the military simulation game VBS2(Virtual Battle Space 2). As the work proceeded different problem areas were identified and the work ended in this Master thesis which proposes solutions in the different problem areas.

1.1 BAE Systems H¨ agglunds

BAE System H¨ agglunds is a division in the global company BAE that has about 107 000 employees all over the world. BAE Systems H¨ agglunds has about 950 employees in diﬀerent areas from production to development. BAE Systems H¨ agglunds develops, manufactures and modiﬁes military vehicles ranging from all-terrain vehicles to combat vehicles. BAE Systems H¨ agglunds has developed and manufactured many well known vehicles like CV90, BV206, Bv206s, BVS10, and SEP. BAE Systems H¨ agglunds has also an impressive industry history in making wooden furniture, buses, electric engines, trams, airplanes, and several other products.[1]

1.2 Background

The customers of BAE Systems H¨ agglunds often ask for a more cost-eﬀective alternative for training in a virtual environment. VBS2(see section 1.4) could be a solution to that request. VBS2 is the market leading serious game in the category of military simulation today and is a further development from Operation ﬂashpoint game idea by Bohemia Interactive Australia [6]. VBS2 might be interesting as a virtual environment and as a platform for future training systems from BAE System H¨ agglunds.

1.3 Systems today

The current training systems are made ”in house” with expensive third party 3d engines.

These systems are very expensive to develop and maintain. They can not compete with

1

(12)

2 Chapter 1. Introduction

the COTS games that does develop more and better functions faster.

1.4 VBS2

VBS2 is a serious game and an battlefield simulator. Serious games is a category of games that focuses on education for a real world subject like military tactics, health care, and firefighting [35]. Serious games have a pedagogical part that is incorporated into the game. One of the pedagogical parts in VBS2 is AAR(after action review). AAR records the training session in VBS2 and can replay the recording after the training session. The instructor can show exactly what happened and give advice on improvements. Another difference between normal games and Serious games like VBS2 is that normal games tries to enhance the game to be more entertaining and discard human drawbacks that is called the super soldier syndrome [29]. VBS2 on the other hand tries to mimic human capability and drawbacks. One of the futures of VBS2 is that it simulates the human eyes light sensitivity. When you remove the night vision goggles the eyes have to acclimatize to the dark which gives a more realistic night combat situations. VBS2 also has ballistic simulation that they claim is 99% realistic [2]. Their ballistic simulation uses correct parameters down to the rotation of earth which enables realistic weapons training. VBS2 is highly customizable to be able to simulate different real world areas and real world objects. VBS2 has been a real success story for Bohemia Interactive Australia and is now market leading. They have attracted several important users, for example NATO, USA, Australia and the Netherlands. Over all, this makes VBS2 a good candidate as simulation platform for new vehicle training systems.

1.5 BAE Systems H¨ agglunds Goal

The goal of BAE Systems H¨ agglunds with this thesis work is to investigate if it is possible to build a vehicle training system with VBS2 as the simulation platform. The diﬀerent parts of the goal are to ﬁnd a way to interact with VBS2, to design a prototype system, and to implement the most important parts of the system.

1.6 Outline

This thesis is divided into eight chapters which are followed by one appendix. This

chapter gives an introduction and background to the thesis. The chapter also states the

goal for the thesis. Chapter two describes the problems that are identiﬁed in the pilot

study. Chapter three investigate and discuss the two ways to control VBS2 which lead to

the decision to use DirectInput. Chapter four investigates the underlying architecture of

DirektInput which includes windows driver stack, USB, and HID. Chapter ﬁve discusses

how to use DSF to simulate a Joystick. Chapter ﬁve goes on and describes USB and HID

deeper and how DSF simulates the joystick. Chapter six describe ﬁrst the general design

of the vehicle training system and after that the chapter describes how the simulated

Joystick prototype is implemented. Chapter seven discusses the result and present what

should be done in the future. Chapter eight is acknowledgments and after chapter eight

follows the references. Appendix A contains the requirement document.

(13)

Chapter 2

Problem Areas

Chapter one describes the goals of this thesis and this chapter will explain the problems that needs to be solved to best satisfy the goals. This chapter is also largely the result of the pilot study done in the beginning of the thesis work.

The assignment is to investigate if it is possible to build a vehicle training system with VBS2 as the simulation environment. The parts of the assignment are to ﬁnd a way to control VBS2 from another application, make a design on a general vehicle trainer, and implement the most important parts of the system.

2.1 The design

A general vehicle training system must be designed to handle multiple roles. A combat vehicle has for example; a driver, a gunner, and a commander. The task of the com- mander is to find targets, to navigate, and to give orders. The task of the gunner is to eliminate targets, to steer the turret, and to choose weapons. The task of the driver is to drive the vehicle and to control all the functions of the chassis. The system has to be designed to be easy to change and to create new roles, because various vehicles may have different roles. The design has to involve a connection to the hardware through SimBas. SimBas is a modular simulation of hardware and software of all the different electronic components in a vehicle from BAE Systems H¨ agglunds. Real hardware can also be connected to SimBas to replace the simulated counterparts. The interaction with VBS2 shall be tested with a prototype. The full list of requirements can be found in appendix A.

3

(14)

4 Chapter 2. Problem Areas

2.2 The interaction with VBS2

The most important part of the system is the connection to VBS2. Other parts of the system will be useless without the ability to control VBS2. The goal is to be able to steer the vehicles in VBS2 as it would be in real life. There are two standard ways to control VBS2. The ﬁrst one is through DirectInput, that is an API (Application Programming Interface) for developers to collect user inputs from keyboards, mouses, joysticks, and other game controllers [11]. The other one is VBS2’s API FUSION that enables other programs to interact with VBS2. A literature study has to be done in order to decide which way that would be the best to chose for diﬀerent problems. The way that is selected will then have to be studied closer in a deeper literature study. The knowledge gained in the literature studies will also be used when implementing the prototype.

2.3 The implementation of the most important part of the system

As described in the section above the interaction with VBS2 is the most important part of

the system. The interaction with VBS2 is also the part where BAE System H¨ agglunds

will gain the most knowledge if implemented. The other parts of the system will be

implemented if time allows. To ease the maintenance the system has to be implemented

in C# mostly. The language used with the interaction with VBS2 is depending of the

result of the literature study.

(15)

Chapter 3

How To Control VBS2

Chapter 2 states that there are two ways to control VBS2, with Fusion and/or Direct- Input. This chapter will discuss these two ways and show which one of them is the best to use in this system.

3.1 Fusion

Fusion is an API built by SimCentric which is an add-on module to VBS2 [30]. The purpose of Fusion is to enable developers to control VBS2 from outside of the simulation.

The Fusion API is a collection of C++ classes that enables developers to create, modify, and get information from objects in VBS2. Fusion is released in stages, v1.0 released in May 2009 and v2.0 in April 2010 [7].

In v1.0 Fusion is abstracting the ASI (Application Script Interface) to the C++ API which is object oriented and easier to use. The purpose of the ASI’s is to create and modify entire scenarios or parts of scenarios in VBS2. The ASI has no direct control of the models in VBS2. In v2.0 SimCentric enables the developers to use the simula- tion core, which means that developers will have complete control over the models and environment in VBS2.[30]

3.2 DirectInput

DirectInput is an Microsoft API which enables developers to gather inputs from diﬀerent input devices without knowing the properties of the device beforehand. DirectInput also handles output for force feedback and haptic devices. When a developer needs input from a joystick they uses DirectInput to enumerate all attached devices to the computer.

The Developer can then choose which joystick to use and fetch the capabilities of that joystick. The joystick describes itself in a standardized way which enables a developer to develop applications that are compatible with a wide range of input devices.[12]

VBS2, as almost all other windows games supports DirectInput which are a widely used industry standard for input devices. DirectInput is incorporated in the original user interface of VBS2 which is an FPS (First Person Shooter) where you play a soldier in ﬁrst person. The soldier in a vehicle in the game can have diﬀerent roles. DirectInput

5

(16)

6 Chapter 3. How To Control VBS2

is limited by that role and can only do the actions that the role handles. For example a person in the game that plays the role of a driver can steer, accelerate, brake, and control lights. A combat vehicle has at least three roles; driver, commander, and gunner which have to be controlled in three separate instances of the game to have full control of the vehicle.

3.3 Comparison

Fusion and DirectInput are both clearly a way to control VBS2 but they have different approaches. DirectInput has a couple of advantages and disadvantages. DirectInput is an industry standard which means that a solution based on DirectInput will work with other games seamlessly. DirectInput will have good support in many years in the future and if that changes Microsoft will have a long transition period. One of DirectInput disadvantages is that it needs to have one VBS2 client per role in a vehicle, three to control a combat vehicle. The Game’s DirectInput interface can only use the predefined actions in the game. The predefined action covers almost all the needed actions except for example fire smokescreen which have to be chosen in a graphical list in the game.

When looking at Fusion’s disadvantages and advantages we have to take in to account the diﬀerent versions. This because the diﬀerences between v1.0 and v2.0 are too big.

Version 1.0 of Fusion is a powerful tool to modify scenarios in runtime. It has some functions to change a vehicles course but it either commands the AI in the game to turn or rotate the vehicle immediately without simulation. There is no good way to realisti- cally steer a vehicle in v1.0 [25]. Version 2.0 will include better functions to steer the vehicle according to information released at this point. Version 2.0 will make it possible to simulate the dynamics of the vehicle outside VBS2. This will make vehicles in VBS2 to behave more realistically. It’s a pity that v2.0 will be released in the end or after this project is ﬁnished which makes v2.0 not a feasible way to control VBS2 in this thesis.

The conclusion is that Fusion will not be a viable way to control VBS2 until v2.0 is

released. DirectInput is therefore the best way to control VBS2 in this project.

(17)

Chapter 4

DirectInput and the

underlaying driver stack

The previous chapter showed that DirectInput is the currently best way to control VBS2 in the time frame of this thesis. The purpose for this chapter is to study the possibilities to use DirectInput to control VBS2 without a physical joystick. This will be done by a deeper study in the design of the Windows driver stack and the speciﬁc drive stack that DirectInput uses. This to give a better understanding where and how to insert the simulated joystick in a way that it can fool the system in perceiving it as a physical joystick. Last in this chapter the chosen solution will be studied in closer detail.

4.1 DirectInput

As the previous chapter explained DirectInput is an API that developers use to abstract the underlying complexity of which and how the attached input devices are connected and used. The developer do not need to know which type of joystick it is or which port it is connected to beforehand. There is no purpose to study the DirectInput API any closer, because developers of applications that use DirectInput will take care of the connection between the API and the application. The interesting part is what will happen under DirectInput where it may be possible to connect a simulated joystick.

Under DirectInput is the driver stack which is diﬀerent depending on which version of Windows is used. After Windows XP the driver stack has nearly stayed the same. The scope of this thesis is therefore Windows XP and later. DirectInput is part of DirectX which in this thesis is version 5 or later.

4.2 Windows Driver stack

The basics of Windows driver stack is the ﬁrst step to understand the DirectInput driver stack. The driver stack describes how applications access and use hardware in a stan- dardized way. In this way you could change hardware and the applications will still work. This is done in the driver stack HAL (Hardware Abstraction Layer) which hides speciﬁc hardware from the above layer. The driver stack is divided into two parts, the kernel-mode and the user-mode.

7

(18)

8 Chapter 4. DirectInput and the underlaying driver stack

Kernel-mode contains the HAL and routines for memory management, I/O and so on.

Kernel-mode code has access to memory and hardware directly. It is running in so called privileged processor mode. Privileged processor mode does not have any restriction to the hardware and can access all memory. The kernel-mode does have some drawbacks.

It has not unlimited memory like user-mode which has virtual memory that is also stored on disk. The kernel-mode has also almost no safeguards to protect the memory from corruption. Debugging is also more diﬃcult than in user-mode.[24]

User-mode contains applications and user-mode drivers. User-mode applications and drivers have to go through the Win32 API to access any hardware. Win32 API works like a gate to the kernel. The user mode application calls the Win32 API and Win32 API calls the right kernel-mode function [27].

4.3 Driver layers

The driver stack can be described as a layered structure with each layer adding value to that device. See the conceptual ﬁgure 4.1 that describe the driver stack layers. The lowest layer is a hardware bus driver that handles a speciﬁc bus like USB or Firewire.

The bus driver is usually written by Microsoft and is part of the operating system. The Bus driver enumerates devices that are attached on the bus. Under the enumeration it identiﬁes the devices and creates a device object for each device. [25, 8]

A device object is a representation of that device and contains pointers to the next driver object. In this way is the driver stack chained together. Each driver (not mini drivers attached to a class driver) has to create a device object. More information on de- vice objects and driver stacks can be found in the documentation of the WDK(Windows driver kit).[9]

The layer above the bus driver is a pair of drivers, the port driver and a miniport driver. The miniport driver is often developed by the manufacturer of the hardware.

The miniport driver handles all the protocol specific requests between the bus driver and the port driver. For example the USB stack has three miniport drivers that each supports different version of the USB standard [28]. The port driver or in some cases like USB is called a host controller handles more generic request about the bus and is not aware of the version specific details of the bus. In this way newer and better versions of the protocol and hardware can be added without rewriting the whole stack. The only thing that needs to be rewritten is the miniport driver. The port driver is almost always supplied by the operation system.[25]

The class and miniclass driver pair is built up in a similar way. The class driver han-

dles a speciﬁc class of devices that is attached on the underlying bus or port. The class

driver is hardware independent which means that the class driver can be reused on other

buses or ports that have devices of the same class. The class driver is almost always

supplied with the operation system. The miniclass driver is the only thing that has to

be rewritten when the underlying bus or port is changed. The miniclass driver is often

supplied by the manufacturer. Every layer above the class driver in the stack does not

know whats is under the class driver layer and do not need to know. The layers above

only wants to know what type of class the device is to be able to use it.[25]

(19)

4.3. Driver layers 9

The kernel-mode client drivers handles request from the Win32 API or from a class driver below. The kernel-mode client driver handles tasks that can’t be done in user mode. The user-mode client driver works similar to the kernel-mode client driver but it is in user-mode. It handles requests from the Win32 API or from applications. User- mode client drivers are preferred because they are easier to develop and do not affect stability of the system as sever as kernel-mode client drivers. This conceptual model of the driver stack is the basic way to represent a general driver stack in Windows in a simpler way. In most cases not all layers are needed depending on what the purpose of the stack is. Some driver stacks may break the stack concept and have component outside the main stack that it calls. One other component not represented in the figure is the filter driver. The filter driver can be placed between every layer to filter out information or adding information.[25]

Hardware Bus Driver Miniport Driver

Port Driver Miniclass Driver

Kernel-Mode Client Driver User-mode

Kernel-mode

Win32 API User-Mode

Client Driver Application

Class Driver

Figure 4.1: Figure of the general driver stack composed with knowledge from Microsoft

MSDN.

(20)

10 Chapter 4. DirectInput and the underlaying driver stack

4.4 The driver stack below DirectInput

DirectInput driver stack follows the general conceptual design that is described in the section 4.3. The ﬁgure 4.2 is a conceptual image of the driver stack below DirectInput with a joystick connected.

In the bottom is the USB bus hardware which follows speciﬁed versions of a USB stan- dard. There are two versions of the USB standard used today 2.0 and 1.1.

Version 2.0 is used in situations when higher bandwidth is a priority. Version 1.1 is used in simpler devices like mouses and keyboards. There is also a 3.0 version but it has just been released and have not yet become a major standard yet. 3.0 has an even higher bandwidth than 2.0.[28, 34]

There are three standard protocols for hardware host controller chips that is widely used today Openhci (Open host controller interface), Uhci (Universal host controller interface), and Ehci (Enhanced Host controller interface). Openhci and Uhci are two diﬀerent host controller interfaces for USB 1.1, both are developed for each their hard- ware speciﬁcation. There are two groups of hardware and software companies behind the two standards. Intel created Uhci and all Intel’s USB 1.1 controller chips uses Uhci.

Openhci started as an collaboration between Microsoft, Compaq , and National semicon- ductors. Openhci and Uhci both support low-speed and full-speed bandwidth standards stated in the USB 1.1 speciﬁcation. This means that when there is an USB 1.1 host controller that Intel have constructed attached to the computer, the computer needs an Uhci driver and vice versa. When USB implementers forum started to develop USB2.0 they insisted to have only one Host controller interface standard. The name of USB2.0 Host controller is Ehci. Ehci takes care of all devices that is USB2.0 compatible and uses high-speed bandwidth standard. Backwards compatibility is ensured by using Uhci and Openhci as companion driver which handles the low-speed and full-speed devices.

This means that it is possible to have up to three diﬀerent host controller drivers at the same time running in the same computer.[28, 3, 4, 34, 5]

These three drivers can also be called miniport drivers and are paired to the USB host controller driver also called port driver. USB host controller driver takes care of all hardware independent tasks. USB host controller driver is developed by Microsoft.

Every USB host controller has one USB root hub that contains all the ports that USB devices can be attached to. The USB devices that are attached to the hub belongs to one of the predefined USB classes. The supported classes are Hub device, HID (Human Input Devices), mass storage, audio, communication device, printer, content security, and image device -class. In this case the device is a Joystick which conforms to the HID device class. HID is a protocol for input devices of different configurations. Later in this thesis HID protocol will be discussed further.[28, 13]

Above the USB root hub driver is the HID USB miniclass driver. It handles all the

USB speciﬁc tasks for the HID class driver that is on top of the HID USB miniclass

driver. HID protocol can be used on other buses and ports if there is a miniclass driver

that takes care of that bus or ports speciﬁc protocol. The HID Class driver and HID

USB miniclass driver is Developed by Microsoft.[28, 26]

(21)

4.4. The driver stack below DirectInput 11

After the HID class driver is the transition to user-mode. In user-mode is DirectIn- put that is dynamically linked to HID.dll. HID.dll is a user-mode client driver that helps DirectInput to parse the information from the device.[20]

USB Minidriver USB Minidriver USB Minidriver

Openhci Uhci Ehci

USB bus Hardware USB Host controller driver

USB 2.0 USB 1.1

USB 1.1

USB root hub HID USB Miniclass driver

HID Class driver User-mode

Kernel-mode

DirectInput HID.dll

Application using DirectInput

Figure 4.2: A conceptual image of the driverstack under DirectInput composed with

knowledge from Microsoft MSDN.

(22)

12 Chapter 4. DirectInput and the underlaying driver stack

(23)

Chapter 5

Simulation of a Joystick in Windows

The knowledge presented in the chapter about DirectInput’s underlying driver stack enables some conclusions to arise about how the solution will look like. One conclusion is that the driver stack under DirectInput, especially the kernel-mode part has to be part of the solution.

If a solution is made in only user-mode by replacing HID.dll or put a filter between Win32 and DirectInput it will generate more problems than it is worth. This is mostly because it is not well documented and may affect the stability of other parts of the system. If it is possible to find the unofficial interface that is used between DirectInput and HID.dll it may not be safe to use it. Microsoft will for example not inform publicly if they change an unofficial interface and the change may have unknown consequences.

Therefore it is dangerous to use unoﬃcial interfaces.

Microsoft has an oﬃcial API to emulate mouse and keyboard messages in user mode but not for Joysticks and other HID devices. This is why the driver stack has to be in the solution. As described in chapter four, some parts of the stack can be changed with- out the layers above recognizing any diﬀerence. It is possible to remove the HID USB miniclass driver and replace it with another that receives events from an application in user-mode. This is a valid solution but is very hard to implement because it involves kernel-mode.

In this thesis time frame it is not possible to learn how to implement a driver that follows both the USB specification and the HID specification. The same goes if a filter driver is used. Another argument is that such a driver will affect the stability of the system if it is not built correctly. Microsoft has developed a framework that solves this problem in the same way as described above by just removing everything under the USB Hub driver and replace it with a simulated counterpart [14]. This framework is called DSF (Device Simulation Framework). DSF is the technique which is chosen in this thesis to solve the problem with controlling VBS2, this by implementing a simulated joystick.

13

(24)

14 Chapter 5. Simulation of a Joystick in Windows

5.1 Device Simulation Framework

DSF is developed to ease the testing of USB devices software before the hardware is built. This helps USB device developers to develop hardware and software in parallel.

It enables developers to create a simulation of a USB device and then to control it in user-mode via an application or a script. DSF is part of WDK and is divided in two parts, DSF runtime and DSF Interfaces. DSF Runtime installs all the drivers and the resources to run a simulated USB device. It also installs a Software enumerator and a utility program which enables adding or removing simulated Ehci controllers from the system. DSF interfaces installs the Managed DSF framework. The manged framework enables users to develop test applications in .net. But the framework can not create or modify simulated USB devices it can only use them.[10, 23]

Figure 5.1 shows the conceptual model of a system with simulated HID device using the DSF framework. On the right side in figure 5.1 is the driver stack under DirectIn- put that has been described in figure 4.2. The big difference compare to figure 4.2 is that DSF has replaced the Ehci controller with its own simulated Ehci controller. The simulated Ehci controller act as an real Ehci Controller but instead of being connected to the hardware it is connected to the DSF runtime and the simulated USB device.

The simulated Ehci controller has its own mini driver and port driver which has their hardware access calls re-routed to DSF own libraries in order to simulate for exam- ple interrupts. The DSF mini driver communicates with the simulated Ehci controller as if it would be a real hardware controller. No layer from and above the mini driver can see any diﬀerence between a hardware controller and the simulated controller.[14, 16]

On the left side of ﬁgure 5.1 is the DSF stack. On the top of the stack is the sim-

ulated USB device DLL (Dynamic link library) which is implemented by the user of

the framework. The simulated USB device is developed in User-mode and has to be

implemented in a programming language which supports describing in COM (Microsoft

Component Object Model) client code. This is because the DSF framework is devel-

oped by using that standard. The simulated USB device initiates a SoftUSBDevice

COM object which is a representation of a USB device. The SoftUSBDevice COM

object is built up very similar to the USB2.0 speciﬁcation and are the basis for all sim-

ulated USB devices. The SoftUSBDevice COM object will later be examine closer. The

SoftUSBDevice COM object is connected to it’s counterpart SoftUSBDevice object in

Kernel-mode. The SoftUSBDevice object in kernel-mode is plugged in to the simulated

Ehci controller with the help of DSF Runtime. More on that later. The COM object

is then used to handle all USB transactions which transmits conﬁgurations and reports

to the simulated Ehci controller which passes on the information up in the DirectInput

driver stack. In the bottom of the DSF stack is the DSF runtime. The runtime is built

to handle a variety of simulated devices and buses. But with existing release it can only

handle simulated USB buses.[14, 15]

(25)

5.1. Device Simulation Framework 15

DSF USB Minidriver Ehci DSF USB Host

controller driver

USB 2.0 USB root hub

HID USB Miniclass driver

HID Class driver User-mode

Kernel-mode

DirectInput HID.dll

Application using DirectInput Application

that uses the simulated USB Device

Simulated USB Device DLL

SoftUSBDevice Object

DSF Runtime

Simulated USB Ehci Controller SoftHIDProtocolXlator

Object

DSF Framework

HID USB Driver Stack

DSF Stack

Figure 5.1: A combined image of the driverstack under DirectInput and the DSF archi- tecture composed with knowledge from Microsoft MSDN.

5.1.1 The DSF COM object model

The core of the DSF COM object model is based on three COM objects DSF, DSFDe- vice, and DSFBus with respective interfaces IDSF, IDSFDevice, and IDSFBus. The DSF runtime is represented in the framework with the DSF COM object. DSF COM object is the root object in the hierarchy and may contain children devices of the object type DSFDevices. DSFDevices may also have children devices if it satisﬁes IDSFBus interface. Every device in the DSF framework has to satisfy the IDSFDevice interface in order to be added to the hierarchy. The hierarchy is built up in this way which is shown in ﬁgure 5.2. The DSF root object has several methods and properties. One of the properties is the children devices which is a collection of DSFDevices. The collection has its own object type DSFDevices which have only methods to read the collection.

It has unfortunately a name that can be mixed up with DSFDevice in plural. From

here on DSFDevices means DSFDevice in plural. DSF have several methods but the

most important method is HotPlug. HotPlug is used to attach an IDSFDevice to the

hierarchy. HotPlug can only attach a DSFDevice to an DSFDevice that also satisﬁes

(26)

16 Chapter 5. Simulation of a Joystick in Windows

IDSFBus interface. This is why DSFDevices may only have children if it also satisﬁes IDSFBus interface. When HotPlug is called to attach a IDSFDevice to a IDSFBus, for example to the simulated Ehci controller, it will notify the simulated Ehci controller through the DSF runtime that a new device has been attached. The simulated Ehci controller simulates a hardware interrupt to the DSF USB Ehci mini driver which acts like it is a real hardware device that has been attached. The IDSFBus have only two methods HotPlug and Unplug. HotPlug works in the same way as IDSF HotPlug with the diﬀerence that IDSF HotPlug returns the IDSFBus which the simulated device is plugged in to. This because IDSF do not have an Unplug method. The DSF COM object model contains several more types of objects which can be read about in the WDK documentation. [15, 14, 22]

IDSF

IDSFDevice

IDSFDevice IDSFBus

IDSFDevice

Figure 5.2: An image of the DSF object hierarchy composed with knowledge from Microsoft MSDN.

SoftUSBDevice is an USB device simulator and follows the DSF object model de-

scribed earlier. SoftUSBDevice has a property which returns the SoftUSBDevice own

DSFDevice object which then is used to HotPlug to ether the simulated Ehci controller

or a SoftUSBHub. SoftUSBDevice is designed to follow the USB2.0 speciﬁcation to

enable it to be perceive as an real USB device. The USB2.0 speciﬁcation speciﬁes that

descriptors shall describe the device to the host computer. These descriptors contains

all the properties of that device from its power needs to how the data pipeline shall be

set up. SoftUSBDevice is one of those descriptor representations. SoftUSBDevice and

the other descriptor representations have two sides here, they are both a representation

of the descriptor and part of the logic behind the simulated USB device.

(27)

5.1. Device Simulation Framework 17

SoftUSBDevice

SoftUSBConfiguration SoftUSBConfiguration

SoftUSBInterface SoftUSBInterface SoftUSBInterface SoftUSBEndpoint SoftUSBEndpoint

SoftUSBEndpoint SoftUSBEndpoint

Figure 5.3: An image of the USB2.0 descriptors composed with knowledge from Mi- crosoft msdn and the USB2.0 speciﬁcation.

5.1.2 USB2.0 Descriptors

The format of the descriptors is well defined in the USB2.0 specification but only the basic structure and important property will be described in this thesis. The structure of the descriptor can be described as a tree with four levels which can be seen in figure 5.3. Each level contains one type of descriptor. These types are device, configuration, interface, and endpoint. There are three more descriptors other speed configuration and device qualifier descriptors which is used when a high-speed capable USB2.0 device needs to run in full-speed or low-speed. device qualifier is similar to the device descriptor but do only contain the information needed the change the speed. other speed configuration is identical to the configuration descriptor. The full-speed and low-speed configurations will not be described here. The third descriptor is the string descriptor that contains all strings that describes the device in human readable text. All descriptors have 2 fields in common which is the length of the descriptor and the type of the descriptor which is identified by a number.[34]

Device descriptor

The root level of the descriptor tree contain one device descriptor which contain general information about the device. The important properties are USB specification version, device class, device protocol, string descriptors, id fields, and number of configuration descriptors. The property of the USB specification version number informs the host computer which version of the specification the descriptors will follow.[34]

Device class and device subclass property is set to the class of which this device belongs to. Examples of classes are HID and audio devices, these classes have been described in section 4.4. If this property is set to zero the class of the device is set in each interface.

Device protocol work in the same way if set to zero. Device protocol is used to specify which protocol that should be used. For example a USB hub device can have two dif- ferent protocols named single TT or multi TT. Both class and protocol deﬁnition are deﬁned by USB Implementers Forum. [34]

The Device descriptor has three types of string descriptors index properties that can be

set, Manufacturer, serial number, and product description. These three indexes corre-

(28)

18 Chapter 5. Simulation of a Joystick in Windows

spond to a strings in the string descriptor. If there is no string it most be set to zero.

The product description for example is the text that pops up in the right corner when the device is plugged in to the computer the first time. The Id fields in the device descriptor is used to identify the device from which vendor the device comes from and what product it is. The last property contains how many configuration descriptors this device has. A device descriptor have at least one Configuration descriptor.[34]

Configuration Descriptor

Each device can have one or more configurations. In this way the host can change the configuration depending on the situation which means that only one configuration is active at the time. The Configuration descriptor itself contains only four fields on top of the two fields that all descriptors have. The first of these four fields contain the length of this configuration descriptor and all interface and endpoint descriptors that this configuration contains. The second and third field contains the number of interfaces this configuration have and a id of this configuration. The id is used when the host sends the setconfiguration request that will set the configuration to the requested id. The last field contains an index to the string descriptor that describes this configuration in text.

[34]

Interface Descriptor

Each configuration has one or more interface and each configuration have all interfaces active at the same time. This means that a device can have for example two interfaces against the host that represents two different classes of devices. Interfaces can like device descriptors be part of a class of devices. An interface descriptor contain both class and subclass fields. If this setting should have any effect the class and subclass fields in the device descriptor have to be set to zero. One may notice when plugging in a mobile phone in a USB port that the operation system installs a number of devices. Which type of devices can differ, but usually it is a mass storage device and mobile modem device.

The interface descriptor contains both class and subclass ﬁelds like the conﬁguration

descriptor. If this setting should have any eﬀect the class and subclass ﬁelds in the

device descriptor has to be set to zero. An interface descriptor can also have alternate

interfaces which can be changed from the original interface after the conﬁguration of the

device. An original Interface descriptor will have to set the alternate interface ﬁeld to

zero, the ﬁrst alternate interface sets it to one, and so on. All interface descriptor has an

id ﬁeld and all alternate interfaces will set it to its original interface id. In the same way

as the previous types of descriptors, the interface descriptors have a ﬁeld containing the

number of descriptor in the level of the tree. In this case it is the endpoint descriptor

types. The last ﬁeld in the conﬁguration descriptor is the index to a string in the string

descriptor that should describe what function this the interface had. [34]

(29)

5.1. Device Simulation Framework 19

Endpoint Descriptor

Each interface has zero or more endpoints. If an interface has no endpoints it uses the default control pipe, also called endpoint zero. The purpose of an endpoint descriptor is to define a data pipe between the host and the device. To define the data pipe the end- point uses four fields; attributes, endpoint address, max packet size, and interval field.

The endpoint address field can be divided in to two parts, the endpoint number and the data direction of the endpoint. The endpoint number is a number between one and 15 which means that an interface can have 15 endpoints excluding endpoint zero. The data direction part defines the endpoint to be an IN endpoint or a OUT endpoint. It can’t be both an in and out endpoint at the same time. This does not apply to a control endpoint which ignores the data direction bit. The attribute field is divided into 3 parts which defines the endpoint’s transfer type and settings. The first part describes which of the four transfer type the endpoint uses. These four transfer types are Isochronous, control, bulk, and interrupt transfer. This thesis is not going in to details in how these different transfer types works. The full description can be found in the USB2.0 specification.[34]

The control transfer type diﬀers from the other three types. The control transfer type have no direction set in the endpoint address ﬁeld, because the control transfer type is bi-directional. This means that it sends data in both ways. The control transfer type is primarily used in endpoint zero which setups the device.[34]

The Isochronously transfer type sets up a pipe which has guarantied bandwidth and constant rate of data. When a packet is lost or the data in the packet is corrupted the isochronous transfer type drops it and will not try to resend it. This transfer type is therefore used when streaming audio and video where dropped packets are no big issue.

Isochronous transfer type is not suited for file transfer or other tasks that depends of the data is intact with no errors. The last two parts of the attribute field is only used by the isochronous transfer type. These two parts of the attribute field describe which type of synchronization and usage type the isochronous endpoint will use. More information about the synchronization and usage type can be found in the USB2.0 specification.[34]

The interrupt transfer type is for small data packages that are sent asynchronous. These packets are guaranteed a maximum speciﬁed latency and reliable transfers. Should an error occur the packet is resent as fast as possible. The interrupt transfer type is used by HID devices where latency and reliability is key when for example sending bottom click.[34]

The bulk transfer type is used when reliably sending large data packages without any latency demand. The bulk transfer type is used in mass storage devices for ﬁle transfer as described in class speciﬁcation of bulk mass storage devices[33].

The max package size ﬁeld and interval ﬁeld function depends on the transfer type

and device speed is used.[34]

(30)

20 Chapter 5. Simulation of a Joystick in Windows

5.1.3 Descriptor objects in SoftUSBDevice

In the DSF framework the four descriptors are represented by four COM objects. Soft- USBDevice represents the device descriptor, SoftUSBConfiguration represents the con- figuration descriptor, SoftUSBInterface represents the interface descriptor, and Soft- USBEndpoint represents the endpoint descriptor. Each of these object holds all the properties from respective descriptor but some of them have more functions and proper- ties that the simulation uses. When the simulated device gets the request for a descriptor it uses these objects to generate the descriptor and send it back to the host. These re- quests can be caught as an events in DSF. To catch these events a custom event handler that implements the ISoftUSBEndpointEvents interface has to be created. The event handler then will have to be connected to the SoftUSBEndpoint which will receive these requests and generate events. These request is usually sent to endpoint zero. The stan- dard getdescriptor(Configuration) request is handled by DSF which sends the descriptor tree including the HID descriptor back to the host. The getdescriptor(Report) request is not handled by DSF. This request needs to be handled by a custom event handler that catches the getdescriptor request with the descriptor type value set to report descriptor and returns the report descriptor. This is done with the ISoftUSBEndpointEvents in- terface method OnDeviceRequest which is called when a getdescriptor(Report) request is sent from the host to that endpoint.[14, 17, 31, 19]

5.1.4 HID Descriptors

The sections above describe how to create a generic simulated USB device. The last part of knowledge needed to create a simulated joystick is the HID class of devices. HID class devices is devices that takes input from human interaction with the device and translates it in to computer understandable form. Examples of HID class devices are ranging from a simple mouse or a keyboard to extremely realistic ﬂight joysticks. HID class devices are self describing as USB devices are. HID class devices sends descriptors to the host computer to describe its functions and how to parse data to and from the device. This minimizes the need for drivers to manage the device.[31]

HID class devices follows the HID standard which is described in two speciﬁcations;

HID class deﬁnition and HID usage tables[32, 31]. The HID standard can also be used on other interfaces then USB. In Windows HID is also used on serial, ps \2, and gaming ports. The HID class deﬁnition however is mainly focusing on the USB bus.[21, 34]

The HID class definition demands that interface and endpoints are defined according to the HID standard. A HID device must set its interface’s class field to three which is the id for the HID Class. The subclass field is set to zero if it is not a boot device. A boot device in the HID sense is a keyboard or a mouse that the BIOS can use. If it is a boot device the interface protocol field can be set to one if it is a keyboard or two if it is a mouse. If it is not a boot device the interfaces protocol is set to zero. The reason that these properties are set in the interface and not on device level is that the device may have more interfaces then just the HID interface. As described before a device can have more than one interface that support different classes of devices. For example an USB device can have one interface for Audio and one for HID.[31, 34]

The HID interface requires two endpoints; one interrupt in endpoint and endpoint zero

which is a control endpoint. The interrupt endpoint is used to send input to the host

(31)

5.1. Device Simulation Framework 21

with formatted data called reports. Endpoint zero is used to send data to the host when polled and receive data from the host. Endpoint zero also responds to request from the host. The HID interface may also have interrupt out endpoint that is used to send data to the HID device instead of sending it through endpoint zero. Endpoint zero is shared between all interfaces in a conﬁguration. When using multiple interfaces endpoint zero may be not have the capacity to be used as an out endpoint for feedback from the host.

Then the optional out interrupt endpoint is used.[31, 34]

The HID device uses three descriptors to describe itself. These three are the HID descriptor, the report descriptor, and the physical descriptor.[31]

The HID descriptor contains general information about the HID device such as country code, HID version number, and number of descriptors. The country code is needed to describe localized hardware for example keyboards which have different setups depend- ing on the language it represents. The number of descriptor field describes how many descriptors this HID device has. This field has to be set to at least one because the device has to contain at least one report descriptor. The physical descriptor is optional and shall only be used if necessary. The HID descriptor also contains the properties of the report descriptor and the optional physical descriptor. When the HID device responds to the USB standard getdescriptor(configuration) request, it inserts the HID descriptor between the interface it belongs to and the endpoints of that interface. The report descriptor is not sent with the HID descriptor, it is sent in response to the get- descriptor(Report) request. The getdescriptor(Report) request is sent after the device is configured.[31, 34]

5.1.5 Report Descriptors

The report descriptor diﬀers from the other descriptors that have been described in this thesis. The report descriptor does not contain its size or type. That is declared instead in the HID descriptor. The report descriptor is not formatted as a table with ﬁelds that are in a predetermined place and size. The report descriptor is built up with items. Almost all items describe a property of the HID device and the other items are supporting them with various functions. The report descriptor also has another purpose then describing the device. It also describes the format of the report that is sent to or from the host with the input or output data from the device.[31]

Figure 5.4 gives an example of an report descriptor that describe a simple joystick

with eight buttons. On the left side is the text description of the joystick which is one

way to explain the report descriptor in human readable form. On the right side is the

actual report descriptor in hexadecimal form. The hexadecimal value on one row is

equal with the text with the same background color on the same row. The ones with

green background are items and with the blue background are values or properties of

the item in front of the value or property. A report descriptor can be very complex

to describe complex and specialized devices. But this thesis will only explain the basic

report descriptor in ﬁgure 5.4 is the one used later in chapter 6.

(32)

22 Chapter 5. Simulation of a Joystick in Windows

Figure 5.4: An image of a report descriptor that describe a HID Joystick.The figure is composed with knowledge from HID class specification,the USB2.0 specification, and HID usage tables specification.

The item that the report descriptor contains can be grouped in to three types; global, local, and main. These three types diﬀer from each other in the way they behave when parsed. The items that belongs to the main type are the items input, output, feature, collection, and end collection. Three of them; input, output and feature is data items which adds data ﬁelds to an input or output report. The collection and end collection is non-data items and groups the other main items to a collection of controls or feedback controls that is related.[31]

Global and local items diﬀers in scope on which main items is aﬀected. Local items

only eﬀect the next main item and global items becomes the default value for that prop-

erty. The list of global and local items is long and only the ones that is used in the

report descriptor in ﬁgure 5.4 will be described. The table 5.1 show the items from the

report descriptor in ﬁgure 5.4 which is then grouped in to the diﬀerent item types.[31]

(33)

5.1. Device Simulation Framework 23

Table 5.1: Table over items in ﬁgure 5.4.

Global

Usage Page Logical minimum Logical maximum Report Count Report Size Local

Usage

Usage Minimum Usage Maximum Main

Input Collection End collection

Usage Page

To explain the report descriptor in ﬁgure 5.4 each items purpose have to be described separately ﬁrst. First item in the list above is Usage page which decides the page to the next Usage item belongs to. In this way Usages is grouped in to meaning full groups.

For example generic desktop that is used in figure 5.4 contain general usages such as mouse and joystick. Generic desktop also contain more specified usages as X and Y axis controls which mouses and joysticks are using. Another Usage page is Simulation which contain for example usages as flight simulation device and spaceship simulation device.[31, 32]

Logical minimum and maximum

Next items are logical minimum and logical maximum which sets the boundery of the value that the controls are expected to return. For application this is important to know what the minimum and maximum are, for example when using a joystick the boundaries is used to scale the input in the application.[31]

Report count and Report size

Report count describes how many data ﬁeld that are added to the report when the next main data item is parsed. Report size sets the default size in bits of the ﬁeld that is added. [31]

Usage, Usage minimum and maximum

As described in the section about usage pages are usages a representation of one speciﬁc

control or device that may contain several speciﬁc controls. For example mouse is one

usage and a mouse may contain ﬁve speciﬁc controls X, Y, and two Buttons. The order

of usages is the order they are mapped in the report to the host. To make it easier to

add a group of controls from the same usage page usage minimum and usage maximum

(34)

24 Chapter 5. Simulation of a Joystick in Windows

is used. For example the Button usage page contains usages button one to button 65535.

To describe eight buttons on a joystick only with usage the report descriptor needs to have one usage for each button. But with usage minimum and maximum items only needs to one usage minimum set to button one and usage maximum set to button eight.

Usage, usage minimum and usage maximum are local items and do only eﬀect the next main data item.[31, 32]

Input

The Input item is the last item before the data fields is added to the report. The input item describes the attributes of the data fields that are added. The attributes is represented by six switches that each have two opposite states which is shown in table 5.2. Bit 0 decides if the data is constant or contains data. Constant data is often used without usage as padding when byte aligning the report descriptor. The report descriptor in figure 5.4 is already byte aligned and do not need padding. Bit 1 decides if the data fields are each an single variable or the field is a Array of data. For example four buttons that each has two states; pressed or not can be represented in two ways.

When representing the buttons with bit one on the input attributes set to variable each button gets one field with the size of one bit. When a button is pressed its bit changes to one and it can be pressed simultaneously with other buttons in the group. When using bit one set to array instead the buttons are represented by one field that is three bits. Then when one button is pressed its id number is sent in the field, this means that only one button can be pressed at the same time. To be able to press two buttons at the same time the report needs one more field and 3 field to support 3 simultaneously pressed buttons. Bit 2 decides if the data is absolute or relative. A mouse pointer is always relative to the position it is in before so the data is the change from the previous position. A joystick pointer on the other hand always has absolute position. This means that the data is the current position. Bit 3 shows if the data should go to its lowest value when the maximum value is exceeded and vice versa. Bit 4 decides if the data is scaled linearly or not. Bit 5 decides if the data have a preferred state. Buttons is in preferred state when it is not pressed. Bit 6 decides if the data is outside of the logical boundaries and therefor is not considered meaningful can be considered a null value.[31]

Table 5.2: Table over the attribute ﬁeld of the input item.

Bit 0(Default) 1

0 Data Constant

1 Array Variable

2 Absolute Relative

3 No wrap Wrap

4 Linear Nonlinear

5 Preferred state No preferred state 6 No null state Null state

Collection and End Collection

The collection item has one property that describes what type of collection it is. There are seven diﬀerent types of collections but only two of them will be described here.

These two types are application and physical. Application type tells the host that

(35)

5.1. Device Simulation Framework 25

the data inside the collection is of interest to the applications and may contain one common purpose. For example an keyboard can have an integrated pointing device and in the report descriptor the pointing device and the keyboard may be divided into two collections which both are of application type. In this way the host can divide the device in two devices which will be easier to handle than handeling every combination of devices.

Physical type of collection contains data that is collected in the same geometrical point.

For example a pointing device gets the X and Y axis data from the same sensor and is therefore usually in a physical collection.[31]

Joystick Report Descriptor

The report descriptor in ﬁgure 5.4 is divided into three groups where one contains the other two. Each of these groups have in the ﬁgure 5.4 a box around itself to mark the items that belongs together.

The outer group that contains the other two groups contains a usage page and a usage which specifies that this HID device is a Joystick. The outer group then starts an appli- cation collection to inform DirectInput or other applications where to look for controls to the joystick. The first inner group begins with a usage page and a usage that specifies that this section is about the actual stick on the joystick that is referred to as a pointer in the report descriptor. One note is that the usage page is not necessary in this group since the generic desktop page is already defined in the outer group and is therefore already the default page. It is only added in this report descriptor to make it easier to follow.

The first inner group then starts a physical collection to group the two axis together which is measured in the same point. This two axis is specified by the usages X and Y which tells the application how to handle the different axis. After the usages the report descriptor describes that the axis will have a boundary between -127 to 127. The data is then sett by the report count and report size to be one field each which is 8 bits wide.

The data is then specified by an input item which states that this is data, variable and is absolute. The rest of the input attributes is set to zero which is the default setting. This group ends the physical collection and in the same time it ends itself. The next inner group also starts with a usage page but it uses usage minimum and usage maximum instead of usage. The usage page is set to the buttons page which contains the buttons from one to button 65535 and in that order. Usage minimum and maximum then spec- ifies that button 1 to 8 will be used. The buttons are then specified to be two state buttons, their values is bound between zero and one. Each of the buttons gets one field with the size of one bit in the report which is specified by the report count and report size. The input item specifies that the data has the same attribute as the other inner groups input item which are data, variable, or absolute. The last inner group ends with the input item and the outer group ends itself with the end of the application collection.

This whole report descriptor describes a Joystick whit two axes and eight buttons. It

also states a map over the report data which contains two eight bit ﬁelds and eight one

bit ﬁeld. This gives DirectInput all information to use the joystick.[31, 32]

(36)

26 Chapter 5. Simulation of a Joystick in Windows

5.1.6 The Report and DSF

When the simulated HID device has sent the report descriptor and the host have received it the simulated device is ready to send reports. The reports sent to the host is sent through the IN interrupt endpoint. There are two ways it can be implemented in DSF.

One is to use the SoftUSBEndpoint method queueINData which adds the report to the in queue. The in queue is then drained when the host requests data. This is call polled simulation. The other way is to connect a event handler to the SoftUSBEndpoint in the same way as the event handler for endpoint zero was connected. This event handler will not handle OnDeviceRequest. Instead it must handle the OnReadTransfer.

OnReadTransfer is called when the host requests data and the OnReadTransfer sends the report back to the host. This is called an event-driven simulation. The diﬀerence is that the polled version puts the report in a queue and waits for the host to send the request. The event-driven version generates the report when the simulated HID device receives the request for more data. The polled version is easier to test if DirectInput receives the input but is more diﬃcult to implement in order to handle higher throughput and lower latency. The USB bus architecture makes it a polled bus where the host is always initiating all data transfers.[19, 18, 34]

This is the last part of information needed to create the simulated joystick. The next

chapter will use this information to implement a simulated joystick prototype.

(37)

Chapter 6

Design and Implementation

6.1 Design

Chapter one describes the problems that the solution should solve. This section gives a general design of a system that gives a solution to these problems. The level of detail in this design is low because of limited time. The connection to VBS2 was prioritized before a high detailed design because without the connection to VBS2 the design would not have any purpose. The design purpose in this section is to give a picture of how every part is connected.

The ﬁrst thing when designing is to locate the problems that the system needs to solve.

This system is dependent on two other applications VBS2 and SimBas. This means that this system have to handle also there limitations and demands. VBS2 is a FPS(First Person Shooter) which means that the player only plays one character at the time and the player plays the character as if it was himself in the game. In vehicles in the game the characters can have different roles. To control all the vehicle functions, all the roles have to be controlled. This means that the player needs an instance of VBS2 for every roll it needs to control. The computational power requirements of VBS2 is quite high which means that multiple instances of VBS2 can’t be run on the same computer. This means that a vehicle trainer with a gunner, a driver, and commander then needs three instances of VBS2 on three different computers. The different vehicles in VBS2 have different types of roles and can vary in numbers. Therefor the design of the system has to be dynamic in the case of creating and modifying roles. Chapter three points out that the best way to control VBS2 is through DirectInput which is done with help from the DSF framework

The simulation of the vehicles electrical system and interfacing towards the hardware is done with SimBas and has to run on a computer of its own.

6.1.1 The hardware

The hardware for the vehicle trainer is set up in the way that VBS2 and SimBas demand, which is discussed above. Each role has a computer of its own connected through a local network to the server that contains SimBas. The structure of the hardware in the system is illustrated in ﬁgure 6.1. There are three computers in the picture; each one has one

27

(38)

28 Chapter 6. Design and Implementation

role and one instance of VBS2. Each instance of VBS2 is connected to an VBS2 server.

This is not shown in the ﬁgure. The lower computer is the server and is running SimBas.

All the computers in the system are connected to each other via a local network. The local network of the vehicle trainer can then be connected to any another vehicle trainer, VBS2 server, or a VBS2 client controlled by the instructor.

Figure 6.1: A conceptual image of the system.

6.1.2 The software

The software that handles the connection between the instances of VBS2 and SimBas is called EVCCom(External Vehicle Control Communication) in this design. EVCCom has two parts; the client part and the server part. EVCCom is a distributed system that has the responsibility to distribute messages between clients and a server. These messages may be handle diﬀerently depending on its priority and if the message can be dropped in case a client is ﬂooded or the messages time to live has expired.

Clients

Each role computer has one instance of the game and one instance of the client part

of EVCCom. The Clients communicates with the server part of EVCCom through the

communications layer. The Clients communication layer takes care of receiving mes-

sages and sending messages back to the server. The communication layer ﬁlters out the

messages that it should not receive or the messages time to live has expired. The client

is the one that knows which messages it should receive not the server. The server sends

all messages to all clients. The communication layer also has the task of delivering mes-

sages with higher priority before the one with lower priority. The Order of the messages

is not important because the messages have only one receiver and the clients are not

dependent on each other. The client is also enabled to send messages to the server.

Fusing Reality with the Virtual Reality of a Serious