Software Architecture Document for the ERAS VR Simulation¶
23th May, 2014 - Document created.
Implementation of an interactive VR simulation of the Eras Mars Station.
A user will be represented by a virtual avatar, he fully controlls and with which he can interact with the environment. Using an Oculus Rift device, the user will get an immersive represantation of the ERAS Mars station, in which he can walk, look around and interact with.
Blender will be used for the development and its Blender Game Engine for the real time simulation.
Goal of the project is the implementation of full Oculus Rift support for the Blender Game Engine using the official Oculus SDK and a simulation in the BGE to demonstrate the the ERAS station.
Describes the scope of this requirements specification.
Make an overview in which you describe the rest of this document the and which chapter is primarily of interest for which reader.
This section describes the requirements which are important for developing the software architecture.
- Fast GPU: For VR a steady framerate of at least 60 frames/second is needed for acceptable simulation
- Oculus Rift device: a virtual reality headset is needed for proper headtracking and full immersion
- A working installation of Blender for development
- Ubuntu >13.10
Use Case View (functional requirements)¶
First person character controller with adjustable height and various input methods (keyboard, joystick, external hardware)
- Oculus SDK integration into Blender for:
- Sensor Fusion head-tracking
- Barrel distortion rendering
Integration with hand tracking project
This section describes how the software interfaces with other software products or users for input or output. Examples of such interfaces include library routines, token streams, shared memory, data streams, and so forth.
Describes how this product interfaces with the user.
GUI (Graphical User Interface)¶
Describes the graphical user interface if present. This section should include a set of screen dumps or mockups to illustrate user interface features. If the system is menu-driven, a description of all menus and their components should be provided.
CLI (Command Line Interface)¶
Describes the command-line interface if present. For each command, a description of all arguments and example values and invocations should be provided.
API (Application Programming Interface)¶
Describes the application programming interface, if present. Foreach public interface function, the name, arguments, return values, examples of invocation, and interactions with other functions should be provided. If this package is a library, the functions that the library provides should be described here together with the parameters.
Oculus Rift VR headset, for documentation see  & 
A high level description (from a software point of view) of the software interface if one exists. This section can refer to an ICD (Interface Control Document) that will contain the detail description of this interface.
Describe any communication interfaces that will be required.
Specifies speed and memory requirements.
Describe the architecturally significant logical structure of the system. Think of decomposition in terms of layers and subsystems. Also describe the way in which, in view of the decomposition, Use Cases are technically translated into Use Case Realizations
The ERAS software applicationg belong to the heterogeneous Distributed Control System (DCS) domain which can be represented as a layered architecture. This is a very common design pattern used when developing systems that consist of many components across multiple levels of abstraction as in ERAS case. Normally, you should be developing components that belong to the Application layer
Describe the decomposition of the system in subsystems and show their relation.
Use Case Realizations¶
Give examples of the way in which the Use Case Specifications are technically translated into Use Case Realizations, for example, by providing a sequence-diagram.
This section describes the technical implementation of the logical view.
Describe the physical network and hardware configurations on which the software will be deployed. This includes at least the various physical nodes (computers, CPUs), the interaction between (sub)systems and the connections between these nodes (bus, LAN, point-to-point, messaging, etc.). Use a deployment diagram.
Development and Test Factors¶
Describe any hardware limitations if any exist.
Software validation and verification¶
Give a detail requirements plan for the how the software will be tested and verified.
Describe the planning of the whole process mentioning major milestones and deliverables at these milestones.
Appendix A: Use Case template¶
Use Cases drive the whole software process and bind together all the phases from requirements capture to final delivery of the system and maintenance. They are a very effective way of communicating with customers and among team members. Before every discussion always provide the partners with a set of relevant Use Cases.
During meetings, they stimulate focused discussions and help identifying important details. It is important to keep in mind that Use Cases have to describe WHAT the system has to do in response to certain external stimuli and NOT HOW it will do it. The HOW is part of the architecture and of the design.
What follows is the empty template:
Use Case: <Name>¶
<List of Actors>
<Low, Normal, Critical>
<List of preconditions that must be fulfilled>
<Step-by-step description of the basic course>
<Step-by-step description of the alternate course>
<Step-by-step description of the exception course>
<List of postconditions (if apply)>