STTR Phase I Proposal

Brahms VE: A Collaborative Virtual Environment
for Mission Operations, Planning and Scheduling

 
Table of Contents

PART              

DESCRIPTION

PAGE

9.A

Proposal Cover

1

9.B

Proposal Summary

2

 

Table of Contents

3

1

Identification and Significance of the Technology or Intellectual Property

4

2

Phase I Technical Objectives

5

3

Phase I Work Plan

6

4

Related R/R&D and Bibliography of Related Work

13

5

Relationship with Phase II or other Future R/R&D

14

6

Commercial Applications Potential

15

7

Company Information  and Facilities

16

8

Key Personnel and Other Staff

17

9

Subcontracts and Consultants

20

10

Similar Proposals and Awards

20

9.C

STTR Proposal Summary Budget

21

 

Cooperative Agreement

 


Part 1 - Identification and Significance of the Technology or Intellectual Property


Fig 1: VR Platform representing the surface systems in the Apollo XVI mission as well as modeling of the geometry of lunar sites. This is the VR Environment that this STTR seeks to connect to the Brahms multiagent system.

1.1   Brahms Multiagent System with a VR Environment

With the advent of more capable robots and longer-duration human exploration missions, it becomes necessary to design systems synergistically, to take into account the limitations and capabilities of both people and machines.  The Brahms multiagent simulation system represents human practices within a model of the work environment (e.g., habitats, spaceports, and terrain), such that system simulations combine human cognitive and social behaviors with mechanisms and formal processes (robots and software agents).

Experiments with Brahms, a currently funded Thinking Systems project, indicate that it is suitable for modeling surface exploration practices, such as the communication and interaction between earth and the astronauts during the Apollo lunar traverses.  We (RIACS team) have modeled successfully how the astronauts used checklists and relied on Capcom to keep on schedule. However, the existing tool is unable to represent graphically in the simulation output the relative sightlines of the astronauts and the TV camera(s).  For example, it is not apparent from the simulation whether the astronauts can see each other, how the TV is pointed, or what is visible to earth. Consequently, the methods used by Houston during the Apollo traverses for tracking one astronaut on the TV while speaking to the other cannot be represented in the model.

The proposed project is to add a 3d graphic interface by which the geographic layout, rovers, tools, robotic systems, spacecraft, and astronauts can be depicted during the simulation.  The Brahms language is fully capable of modeling activity in such an environment, and the simulation engine is capable of driving the graphic output. What is required is coupling an existing VR language to Brahms. We have identified that the VR language and API embodied in the Dspace1 platform from DigitalSpace Corporation (DSC) is uniquely suited for pairing with Brahms.  DSC has developed its DSPace1 thin client VR platform to serve as a powerful scenegraph manager and java-based net-distributable cross-platform component for collaborative virtual environments. Discussions with RIACS staff in 1999-2000 showed that there was a good fit for integrating DSPace1 to Brahms to provide their needed visualization and simulation environment. Figure 1 above shows some of the models in the Dspace1 platform independently developed through DSC for an Apollo systems simulation.

The resulting tool composed of Brahms coupled to a VR graphic output (which we are terming Brahms VE for Brahms Virtual Environment) will be provide a unique combination of modeling language and VR visualization output, which is directly applicable to modeling and supporting a variety of other space activities such as flight operations, EVAs, robot planning and control, payload processing, onboard training, and virtual science, including fully autonomous missions with multiple, interacting robots. PSA (personal satellite assistant) and other ISS programs could benefit from the visualization, modeling and work planning capabilities of Brahms VE. We also anticipate that the Brahms VE platform would be applicable to modeling scientific fieldwork on Mars including the following key aspects:

·         Outdoor geographic modeling (terrain, climate) allowing the computation of sightlines and prediction of shadow casting by objects for power generation and visibility planning

         Simulation of interplanetary communication time lag to support tele-operator training and improved work planning efficiency

·         Modeling several weeks of time, with unmanned rover ground operations tele-operation or manned team planning and support on the surface

·         Predicting wear & tear on objects, including breakage

Part 2 - Phase I Technical Objectives

 The Phase I objectives are to demonstrate:

 (1)               the scoping, design and implementation of a prototype Brahms VE platform to be able to establish technical feasibility of the larger project goals

 (2)            representation of models and simulation content and testing in the Brahms VE prototype using the example of work practices and actual mission logs during the ALSEP deployment on the Apollo XVI mission. Show the sightlines of the astronauts and camera on the lunar surface and analyze how these sightlines explain difficulties and disco-ordinations that arose during ALSEP deployment.

Part 3 - Phase I Work Plan

 3.1 Implementation Plan

The Brahms Virtual Environment (Brahms VE) represents location-dependent information of objects and agents in a simulated terrain in three-dimensional view, with animation. The BRAHMS VE consists of two components: The VR Builder allows a model builder to create a visual representation of the locations, agents and objects used in a model. A VR Viewer represents the movement of the agents and objects in the 3d visual representation. To increase flexibility in debugging and replaying a simulation model, all simulation states are stored in a database retrievable by the VR Viewer (e.g., simulations may be replayed backwards). 

The tasks involved in developing the Brahms VE during the first year are:

1.      Familiarization with the Brahms language, system architecture and Dspace1

Analysis to relate the Brahms VE requirements to the existing Brahms language and engine, and the API and scenegraph capabilities of Dspace1.

2.      Project scoping and requirements analysis

Discuss the scope and requirements of the Brahms VE components with the users and other team members to come to a shared understanding of the Brahms VE expectations.

3.      Design and implementation VR Builder

Create an object-oriented design and Java implementation of a simple VR Builder allowing for the placement of VRML based models of locations, agents and objects. The Builder should link locations in the VR Builder with areas and paths in a Brahms model. Develop a document type definition (DTD) for the extensible markup language (XML) used to store a VR model as built in the VR Builder.

4.      Design and implementation VR Viewer

Create an object-oriented design and Java implementation of a VR Viewer that can load and display a three-dimensional world as built using the VR Builder (build in the API of Dspace1), and that can display the actual movement of agents and objects as they moved during the simulation of an associated Brahms model. The VR Viewer is controlled by the user (e.g., to produce overhead 2d projection) and driven by the application logic in locating and moving objects.

5.      Design and implementation VR Application Logic

Create an object-oriented design and Java implementation of the application logic. The application logic is the interface used to translate a 3D model to XML and back using the DTD. The application logic also reads Brahms VE related information from a Brahms database containing the simulation data for a simulated Brahms model. The application logic converts the simulation data to instructions for the VR Viewer using the Brahms VE API.

6.      Integration Testing

The various components will be unit tested in their design and implementation cycle. All components together require being integration tested to verify that all components successfully work together in the Brahms Builder and viewed in Dspace1 across net connected PC platforms.

Initial experiments with this interface in prototype form will include at minimum:

a) Using the ongoing ALSEP simulations to show the sightlines of the astronauts and camera on the lunar surface

b) Analyzing how these sightlines explain difficulties and disco-ordinations that arose during ALSEP deployment (e.g., why Young tripped over the heat flow experiment wire, why Capcom did not warn him of this danger)

c) Add a second camera controlled remotely, to show how two views would have helped Capcom assist the astronauts

d) Have a person play the role of Capcom dynamically in the simulation, e.g., stop the simulation and have the person adjust the views and determine what the person would have said to Young and Duke at various points.  How does changing sightlines improve the advice?

e) Begin to develop graphics for other scenarios including: Personal Satellite Assistants on the ISS and robots working with astronauts on the moon or Mars to set up a base camp and to explore.  (See relevance subsection for further description of these applications.) 

In order to achieve the objectives described in Part 2 of this Proposal, DSC has divided the project into seven major tasks.  The following table provides our projected allocation of hours by labor category by task.

 

TASK

 

DESCRIPTION

 

PI

 

PM

 

SE1

 

SE2

 

CD

 

TG

 

1

 

Familiarization with the Brahms language, system architecture and Dspace-1

 

100

 

25

 

5

 

5

 

0

 

5

 

2

 

Project scoping and requirements analysis

 

25

 

10

 

20

 

0

 

0

 

0

 

3

 

Design and implementation VR Builder

 

5

 

10

 

20

 

0

 

5

 

0

 

4

 

Design and implementation VR Viewer

 

5

 

20

 

10

 

10

 

10



0 

 

5

 

Design and implementation VR Application Logic

 

5

 

30

 

10

 

10

 

10

 

0

 

6

 

Integration Testing

 

0

 

0

 

10

 

20

 

5

 

45


7


Postmortem report for Phase II consideration


25


5


0


0


0


0

Where:

PI          =          Principal Investigator from DSC

PM        =          Project Coordinator RIACS

SE1      =          Software Engineer from DSC

SE2      =           Software Engineer from RIACS

CD       =           Content Development from RIACS and DSC

TG       =           Test Group from RIACS and DSC

3.2       Specification of the Architectural Requirements for the Brahms VE Platform

Technical Approach

Brahms is a multi-agent simulation program developed by Clancey, et al. (1998). The approach relates knowledge-based models of cognition (e.g., task models) with discrete simulation and the behavior-based subsumption architecture (Brooks, 1991; Clancey, 1997a,b, Nakashima, et al., 1996).  A full bibliography and discussion of related work appeared in the original Brahms proposal (NAS2-14217) and a partial one appears in Part 4 of this proposal.  In brief, other multiagent simulation systems lack one or more of the key elements of Brahms' design:

·         They focus on functional (idealized) models, rather than work practice, what actually happens;

·         Provide only procedural scripting languages, at best, for specifying agent behavior;

·         Do not model the environment;

·         Do not incorporate an appropriate model of human conceptualization (i.e., how possible activities are blended at runtime);

·         Do not model communications in an integrated way (e.g., modeling faxes, voice loops, time delays);

·         Do not model the protocols for agent cooperation (e.g., getting attention and ending a conversation)

·         Assume relationships (such as workflow) that a simulation should generate and validate.

Brahms, which has been under development since 1992 (in its first formation at Nynex Science and Technology), handles all these issues.  As such it provides a better basis for mission planning than conventional business process models or workflow representations.  However, even the commercial state of the art, exemplified by the Maxis ™ systems, such as SimCity™, allows visualizing geographic layout of an environment, objects, and agents as the simulation proceeds.

Brahms' chronological visual display (developed by prior funding) is also essential for understanding interactions during the simulation and visualizing coordination between astronauts, robots, and communication devices (see figure). Each agent's activities are laid out hierarchically on a time line.  Blue lines represent communications that are occurring between agents and devices. In the actual model, all the equipment packages, the layout of LEM, SEQBay door, and the lunar surface are specified. And the activities of the Capcom and Ed Gibson in the CM are also specified.  At runtime, the agents interact and move about in the simulated world.  

But the limitations are readily seen—there is no way of knowing how each agent is visually oriented or what the camera is showing.  By integrating Brahms with a 3d "virtual reality" graphics language, we will be able to depict all these relationships, as well as place cameras and avatars, by which views from any angle may be discerned.  On such a basis, flight controllers, astronauts, trainers, and mission planners will be able to visualize who will see what at each time during the planned operations, and thus better anticipate how collaboration should occur, how cameras should be placed, and what communication protocols will be required.  When robots are included in the operations, Brahms simulation will allow understanding how they will facilitate and complicate human activities, so again the discoordinations we see in all the Apollo lunar surface operations can be better anticipated and resolved in advance.

Examples of DSpace-1 graphics that will be integrated with Brahms simulation language. Activities include communication, agents and avatars, reading checklists, riding in rover, moving objects, etc.

Interface Requirements

Based on our analysis of ALSEP deployment and experience in building an ALSEP Brahms model, we have determined the following requirements for a Brahms VE 3D graphics interface:

a)      All objects and agents are rendered in a state-of-the art 3d graphic scene

b)      Locations of objects/agents update while simulation is running, i.e., objects/agents are animated

c)      Objects/Agents can be selected and different trace or debugging operators applied (e.g., get current status, trace events in a log, break simulation when event occurs, show movement trace)

d)      A simulated camera may be placed in this simulated world, with an indication such as dotted lines, showing the angle of view of the camera (which may be altered by changing the simulated lens from wide-angle to telephoto, etc.)

e)      An "avatar" can be placed in this simulated world, which represents a human agent who is interacting with the simulation.

f)        An ability to display the 3d view from any position allows the sightlines to be directly determined, i.e., what can a given agent, avatar, or camera see now?

g)      An avatar may pick up and move objects in the simulated world or speak to agents

h)      The simulation may be set to stop when a given object (agent or avatar) moves into the view of a given agent, avatar, or camera.

i)        To inspect a simulation, a simulation viewer may place an invisible camera in any location and then select the view of this camera. 

To meet these requirements, we have chosen to use the graphic scene language and thin 3D client DSpace1, developed by DigitalSpace (see figure 1).  Details are provided in the task/milestones subsection below.

Brahms Implementation Progress

Since Brahms became a NASA-supported project in FY99, the architecture has been generalized and ported to include the hardware and software architecture for long-term requirements of NASA mission planning and robot control.

 The architecture has the following software components:

1.      Language and Compiler

2.      Builder

3.      Explanation Facility

4.      Virtual Reality Environment

5.      Virtual Machine

6.      Client/Server framework

During FY99 language was expanded to include the notion of containment allowing agents to carry objects and vice versa while moving, the language now includes a larger set of meta-types to allow for improved reusability of Brahms components (including "packages" to organize models). The compiler was expanded to support the new language constructs and generates XML (Extensible Markup Language) to represent the Brahms ‘byte-code’. For the XML a Brahms DTD (Document Type Definition) specifies the allowable XML elements and their format.

 The Builder is the intelligent development environment (IDE) for model builders allowing them to build and explore models. It now includes a model wizard, a model explorer, concept and activity creation dialogs and an explanation facility. The model wizard, concept and activity dialogs allow for the quick creation of simple models, the model explorer displays a tree representation of a model to ease exploration of the constructs in a model.  An associated explanation facility currently allows the model builder to request the beliefs and facts held by or about a Brahms concept and to find out where, when and by whom or what a belief or fact was created.

To visualize the movement of agents in a geographical model a prototype was developed during FY99 of a virtual reality environment (Brahms VE) as a proof of concept to visualize the movement of agents in a three-dimensional display. The Brahms VE has an application-programming interface (API) to allow control of the Brahms VE using external components and to allow visualization of a Brahms models in other third party 3D environments.

 Brahms’ simulations currently take place in a simulation engine developed in Gensym’s G2. A new virtual machine written in the Java language was 80% implemented in the past 15 months. The new virtual machine uses XML generated by the compiler as the format to load models. The virtual machine is fully object-oriented and allows for easy expandability. The initial release supports a discrete event data driven simulation engine and will in its next release include real-time extensions. The virtual machine has interfaces to allow control from within the Brahms Builder and stores all data related to a simulation run in a database for analysis by the explanation facility as well as the Brahms agent viewer.

Using Brahms as a multi-user system, such as for collaborative engineering, requires a client/server architecture. A base frame work has been implemented to allow for a distributed Brahms system. The frame work is based on enterprise JavaBeans (EJB). A first prototype and proof of concept was developed.  Funding for this activity is independently proposed in another NRA task in the Technical Area of "Next Generation Infrastructure Systems" (Clancey & Sierhuis), "Virtual Reality Simulation Environment for Habitat Design." 

Dspace1 Implementation Progress

DSC has engaged in a build of a Java and web driver scenegraph engine R&D effort starting in mid 1999. Selection of cross platform drivers from Wildtangent™ and Shout Interactive™ and creation of the first version of DSPace1 in early 1999 allowed us to proceed with discussions with RIACS on this joint STTR proposal. Built on a Java framework supporting generic scenegraph API calls and a plug-in architecture, DSPace1 is able to be interfaced with Brahms to provide it the visualization required in the end applications. DSPace1 is current being employed in another project for a K-12 educators community and has been qualified as ready by the DSC team. Architectural Elements of Dspace1 Include:

 (1)        An optimized, compressed streaming format to deliver both 3D scenegraph and behavior/animation formats optimized both for the personal computer user at home (consumer platform) and the scientist and engineer at an institution or company (high end platform). The format supports modular definition of geometric objects, re-use and local caching of scenes, behavior and other media types to increase bandwidth and reduce repeat visit load times. The cache supports its own cache limits and cleanup of less frequently used objects. The format is based upon database records and driven by ODBC and other database transaction standards, thereby capitalizing on the power, openness, management capability and economy of web-database engines, and not inventing a proprietary server or file  format.

(2)               Multi user presence within an instance of the scene to permit the sharing of 3D and 2D data and interaction between those present through the use of avatars (3D embodiment of users) and video, audio and text streams. The tool is optimized both for small scenegraphs and a limited number of users per scene graph to keep compute resources down and allow peer to peer operation.

(3)               The tool executable has a small footprint (at approximately 500K Bytes for the consumer platform enabling rapid access and lowering of demand on servers during high hit periods, such as during live mission coverage.

(4)               The tool runs as a plug-in to standard web browsers across common consumer platforms.

(5)               The tool uses peer to peer communications, populating instances of the scenegraph, behaviors, data channels, and user profiles from client to client and avoiding the use of a server for all but the minimum synchronization and updating of content. This will permit scalable operations supporting hundreds of thousands and perhaps millions of users exploring updated instances of the same spaces.

(6)               Core content servers serving as "seeds" to populate the client instances of a scene and its users. These servers would not be based upon a proprietary scenegraph format and protocols but instead be constructed as web-based database processes, using a number of engines and ODBC and other standards to send standardized records

(7)               The tool provides its own plug-in architecture to allow a wide range of developers to write extensions that can bring new behavior or simulation capabilities to the tool.

 No commercial 3D software technology offers the unique set of capabilities outlined above. The innovations in combination will produce a tool that will dramatically enhance the ability of the scientist and lay person alike to experience 3D scenes collaboratively and from several perspectives. For its application to NASA, both current and future missions as well as historic missions where planetary, asteroidal or cometary surfaces have or will produce 3D surface or other scene geometry can be represented through the portal. In fact, as specific locales in the solar system are modeled through the portal tool, an entire body of scenes and interactive content would emerge as a "virtual solar system". We choose to term the entire concept "Mission to a Virtual Solar System" with the portal tool as the first vehicle.

 3.3       Project Reference Website

The Project Reference Website will be a center for ongoing progress and resources surrounding the project, from the interview phase to the prototype test bed evaluation. The site will consist of the following components: 

·         Project goals, timeline, sponsors, participants

·         Team biographies and contact information

·         Examples of prior systems in the multi user virtual space

·         Samples of NASA mission-oriented content on first generation platforms

·         Documentary results of each phase of the project, from the posting of interviews to architectural and specification documents

·         Listserver for project participants

·         Access to existing DigitalSpace and other 3D virtual worlds on first generation platforms

·         Downloadable releases of test bed software and related tools and libraries

·         Links to related sites in the virtual worlds industry and STTR and other NASA sites

3.4   Design/Implementation/Testing of a Test Brahms VE System

DSC will design and implement a test bed Brahms VE system based on a minimum buildable prototype within the time allotted. Off the shelf APIs and rendering technologies provide the VR component integrating to the Brahms Java classes. The VR front end will be based on the thin Client DSPace1 platform. Elements to be utilized will include: Java, Wildtangent Web Driver, back end databases and 3D modeling and conversion through TrueSpace, GIS converters, texture map generators and other elements. Prior work in designing and hosting events and NASA-oriented content in 3D virtual worlds will provide content and experience necessary to create a minimal but effective test environment within the new prototype environment.

3.5   Business Plan

DSC's final report will include a "Business Plan" which has a dual purpose.  It provides guidelines on how DSC is to operate on a day to day basis and is also to be used as the basis for obtaining venture capital during Phase II.  The Business Plan, at a minimum, is to contain a description of:

 

•      DSC organization and staff;

•      DSC  management policies;

•      Brief product description;

•      Marketing plan (tools, potential markets, methods);

•      Accomplishments to date;

•      Financial considerations;

•      Projected cash flow.

 

3.6  Technology Transfer

RIACS, based on its extensive experience performing Government sponsored projects in conjunction with industry, will advise DSC on how to successfully transfer the technology.

 

 

3.7   Work Schedule

This section describes the work schedule for the Phase I effort.  DSC work is to be coordinated from its corporate offices located near Santa Cruz California. All RIACS work will take place at their offices at Ames Research Center at Moffet, California (approximately 27 miles from DSC's offices).  DSC design and testing teams are located at several places around the United States and internationally. In addition, key DSC programming resources will be employed from the San Francisco Bay Area. The schedule assumes a start date of 1 November 2000 with a completion date of 31 Oct 2001.  Any change in the start date causes a corresponding change in the completion date.

 

                                                          PHASE I SCHEDULE                                          

 

 

 

Nov

 

Dec

 

Jan

 

Feb

 

Mar

 

Apr

 

May

 

Jun

 

Jul

 

Aug

 

Sep

 

Oct

 

Familiarization with the Brahms language, system architecture and Dspace-1

 

¦

 

¦

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Project scoping and requirements analysis

 

 

 

¦

 

¦

 

 

 

 

 

 

 

 

 

 

 

 

 

Design and implementation VR Builder

 

 

 

 

 

¦+

 

d

 

d

 

d

 

 

 

 

 

 

 

Design and implementation VR Viewer

 

 

 

 

 

¦

 

¦+

 

d

 

d

 

d

 

 

 

 

 

 

Design and implementation VR Application Logic

 

 

 

 

 

 

 

 

 

d

 

d

 

d

 

d

 

d

 

 

 

 

Integration Testing

 

 

 

 

 

 

 

 

 

 

 

t

 

t

 

t

 

t

 

t

 

t

 

 

Postmortem report for Phase II consideration

 

 

 

 

 

+

 

 

 

+

 

 

+

 

 

+

 

+

 

*

Where:

¦ = Specification and or Design and Documentation

d = Software and Content Development

t = Software Testing

+ = Status Report

* = Final Report

 

Part 4 - Related R/R&D and Bibliography of Related Work

The DSC team consists of the Principle investigator, Mr. Bruce Damer, Mr. Stuart Gold (system architect), Ms. Nancy Levidow (executive administration of the project), Ms. Galen Brandt (creative director), our software engineers, our content developers, David Rasmussen, Troy Gerth, Benjamin Britton and developer Alex de Grigny. This team has already completed the following research:

 

•      Four years of producing collaboration, content and events within 3D shared virtual worlds on the Internet including such projects as: TheU virtual university architecture competition (see http://www.ccon.org/theu/ ); Avatars98, a conference inside cyberspace (see http://www.ccon.org/conf98/ ), Apollo IX and XI reenactments (see http://www.digitalspace.com/worlds/apollo/index.html ).

 

•      Supported industry conferences to forward the medium of virtual worlds, including the annual Avatars conferences, Digital Biota, Vlearn, Siggraph, CHI, CSCW, SCS Euromedia, Vircomm and others.

 

•      Published many papers and books on the subject of virtual worlds (see http://www.digitalspace.com/papers )

 

•      Reviewed systems and literature from the entire evolution of 3D and shared spaces on the internet from 1989.

 

4.1 Additional Bibliographic References

Brooks, R.A. (1991). Intelligence without representation. Artificial Intelligence. 47, pp. 139-159: Elsevier Science Publishers, B.V.

Clancey, W. J. (1997a). The conceptual nature of knowledge, situations, and activity. In P. Feltovich, K. Ford and R. Hoffman (eds.), Expertise in Context, pps. 247-291. Cambridge, MA: The MIT Press.

Clancey, W.J. (1997b). Situated Cognition; On Human Knowledge and Computer Representations. Cambridge, UK: Cambridge university Press.

Clancey, W.J., Sachs, P., Sierhuis, M., & van Hoof, R. (1998) Brahms: simulating practice for work systems design. Int. J. Human-Computer Studies, 49, 831-865.

Damer, B. (1998). Avatars, Exploring and Building Virtual Worlds on the Internet, Berkeley, CA: PeachPit Press.

Nakashima, H., Noda, I., and Handa, K. (1996). Organic programming language GAEA for multi-agents. Proceedings of the Second International Conference on Multi-Agent Systems. December 10-13, 1996, Kyoto, Japan. pps 236-243. Menlo Park: AAAI Press.

           

Part 5: Relationship with Phase II or other Future R/R&D

DSC's final report will demonstrate to NASA our total commitment to the development and marketing of the Brahms VE platform product for use in business collaboration, educational and scientific support.  DSC perceives the Phase I work to be a complete definition of the design of the product and a demonstration of a prototype of the major innovations identified in Part 1 of this proposal.  DSC envisions Phase II work to encompass the building of a full commercial product with associated production quality content, online support and technical and user documentation.

This effort is to form the basis of the Brahms VE platform product DSC brings to market.  At the start of Phase III, DSC plans to either finance its initial operation with venture capital, or if no venture capital is obtained, the principals are committed to self finance the venture during Phase III.  RIACS will serve as the initial beta site for the Brahms VE platform.

 

Part 6: Commercial Applications Potential

There are several classes of clients for a Brahms VE platform.  The first class is a specific industry which wishes to provide a general capability for people to collaborate online. This field is now dominated by text-based interaction and document sharing. Millions of websites have added some form of real time collaborative interaction and are candidates for using Brahms VE. The second class is a variety of clients who have serious needs in distance learning, business collaboration, e-commerce product sales and support, customer support, events, and scientific/engineering applications.

The first class requires a simple, streaming, low bandwidth, standards-based, small footprint 3D plug-in to common Web browsers. In addition, this class requires scalability to millions of simultaneous users in small groups. 

The second class requires much higher resolution content that is tuned for faster networks, secure transactions, support for live video and audio within the virtual environment, database back end support including world building, tracking and logging, rich simulation and behaviors, and larger numbers of users.

We feel that Brahms VE platform would deliver two distinct classes of product to the marketplace. Let us review some cases of industries that would readily employ the Platform:

The Corporate Marketplace:

Virtual environments delivered through this tool could serve the needs of business in the following areas: conferencing, collaboration on problem solving, customer support, training, seminars, team meetings and online tradeshows.

K-12, Colleges and Universities:

As described above, we will be designing the platform to able to support students on "virtual fieldtrips" to visit models of mission sites and interact with project scientists and engineers in real time. In general, for K-12, college and university level students, "virtual field trips", historic reenactments, exploration of mathematical and other abstract concepts, virtual scientific co-laboratories could all be enabled with this technology.

Museums and Science Centers:

There is a market for these 3D virtual worlds supporting museums through kiosks or at-home access to 3D virtual rooms representing art exhibitions or animated models for natural history and science centers, especially showing NASA solar system missions past and future.

 

Other--DSC plans to identify numerous lucrative vertical markets.

 

DSC plans to make use of its business plan developed as part of Phase I to obtain venture capital.  The principals of DSC have already met with several venture capitalists who are enthused about our project and we expect they will support our venture once we can demonstrate some of the capabilities of our prototype.  In addition, DSC's principal stockholders (all current employees are stockholders) are committed to self financing DSC if no venture capital is obtained.

Part 7: Company Information and Facilities

DigitalSpace Corporation (DSC) was incorporated in the state of California on 24 August 1995.  DSC is a company organized to exploit the multi-user virtual worlds market.  DSC was founded by Mr. Bruce Damer (the proposed Principal Investigator). DSC is located near Santa Cruz California and currently leases an office space in a 2 story building at 14733 Bear Creek Road, Boulder Creek, California. Additional DSC employees have offices in San Francisco and London England. The company is based on the following concepts:

•      that the Internet and especially 3D virtual worlds, can be effective meeting places and enable communications, learning and team based projects. DSC uses these spaces daily in a proof of concept that a company can base its operations on them; 

•      as the need for teleworking, distance learning, virtual communities of interest and visualization grows, so will grow the capabilities of ordinary consumer personal computers to deliver real-time 3D multi-user experiences. It is the convergence between these needs and the capabilities of consumer computing hardware that will create a large industry producing and hosting virtual worlds in the near future.

All DSC employees and contractors have at least one personal computer (most have IBM PCs, Pentium class with network connectivity). On these premises, DSC has engaged dozens of clients to produce both demonstration and fully functional virtual spaces since 1995. See our web site at http://www.digitalspace.com for a portfolio of projects and clients. We will feature a number of them here for their relevance to the STTR proposal:

 

ORGANIZATION: American General Finance, Houston Texas

CONTRACT VALUE: $225,000

DESCRIPTION: Currently designing and developing a multi user virtual community portal for educators. Dspace1, DSC's platform, is being use to present a 3D auditorium for educational presentations.

 

ORGANIZATION: Datafusion Inc, San Francisco California

CONTRACT VALUE: $100,000

DESCRIPTION: Designed and developed a prototype virtual world for Datafusion's knowledge map product, depicting problem and resolutions graphically in navigable layered 3D spaces.

 

COMPANY: International Health Insurance, Copenhagen, Denmark

CONTRACT VALUE: $50,000

DESCRIPTION: Worked closely with this financial services client to build a virtual headquarters in 3D complete with help desk functions delivered in five languages by automated agents. This world was also tested with a satellite based paging system to inform help desk personnel when a client enters the virtual world.

 

COMPANY: The Contact Consortium

CONTRACT VALUE: $220,000

DESCRIPTION: Coordinated the Consortium's three annual conferences beginning in 1996. Created program, fund raising plan, financial and logistical support, and build a new technology platform so that the Consortium's 1998 conference could be held entirely inside the Internet in 3D virtual worlds.

 

Part 8: Key Personnel and Other Staff

 

8.1   Management and technical staff members

The following brief resumes are the proposed management/technical staff members which form the DSC/RIACS STTR team for Phase I.  The initial portion of Part 3 of this proposal specifies the hours allotted for each task by our proposed staff members.

 

Name:                           Bruce Damer

Years of Experience:     20

Position:                        Principal, President and CEO, DigitalSpace Corporation

Education:                     Bachelor of Science in Computer Science (University of Victoria, Canada, 1984); MSEE (University of Southern California, 1986)

STTR Assignment:        Principal Investigator and Program Manager. Mr. Damer will be the Principal Investigator and also manage the overall STTR Phase I effort.  He will coordinate all interaction between DSC and RIACS, be responsible for all staffing, technical design, reporting and documentation.   Mr. Damer will devote a minimum of 100 hours per month of his time to the NASA STTR project.

Experience:                   Mr. Damer is the world's recognized expert on avatars and shared online graphical virtual spaces having created much of the early literature, conferences and awareness of the medium. Mr. Damer is a visiting scholar at the University of Washington Human Interface Technology Lab and a member of the staff at the San Francisco State Multimedia Studies Program. Prior to founding DSC, Mr. Damer co-founded and was (and still is) a director of the Contact Consortium, the world's first and largest non profit forum for research and development of multi-user virtual worlds hosted on the Internet (see http://www.ccon.org ). Prior to this he was Chief Technology Officer of a highly successful software product development company (Elixir Technologies) from 1987-1994. His responsibilities at Elixir were overseeing an advanced document system development that used technology transferred from Xerox Palo Alto Research Center to generate the majority of the world's time-sensitive documents for industry and government. See http://www.digitalspace.com/papers for a complete bibliography of Mr. Damer's work.

 

Name:                           Stuart Gold

Years of Experience:     26

Position:                        Principal, DigitalSpace Corporation

Education:                     Royal Institute of British Architects

STTR Assignment:        Key Technical Expert who will evaluate the technology components and architecture for the Brahms VE VR platform as well as coordinating and engaging in both the server/database development for the prototype and the content development for the prototype.

Experience:                   Mr. Gold is a pioneer of online systems, starting with his work on transaction processing for Prestel in the 1970s and concluding most recently with his leadership in the design and delivery of online virtual worlds including: TheU Virtual University Architecture Competition, International Health Insurance Virtual Headquarters, and Avatars98 Inside Cyberspace. Mr. Gold has also been trained as an architect and he brings this experience to the form and function of virtual spaces that DSC produces. See http://www.ccon.org/theu for his recent projects.

 

Name:                           Nancy Levidow

Years of Experience:     20

Position:                        Business Coordinator, Treasurer, DSC

STTR Assignment:        Ms. Levidow will be coordinating the logistical and reporting aspects of the STTR Phase I work.

Experience:                   Ms. Levidow has coordinated DSC work, conferences, finances, and key marketing and client relationships  since 1997.

 

Name:                           Maarten Sierhuis

Years of Experience:     10

Position:                        Staff Scientist, RIACS

STTR Assignment:        Mr Sierhuis will be coordinating the planning, development and review processes for the RiACS side of the STTR team. Mr.Sierhuis' current work involves the development of the multi-agent modeling language and simulation environment for simulating work practice (BRAHMS) that will be the focus of the virtual environment construction.

Experience:                   Since 1991, Maarten has been working as a member of technical staff at Bell Atlantic (in the former research and development organization of NYNEX, also known as NYNEX Science & Technology). As an MTS he was part of the Expert Systems Laboratory, designing knowledge-based systems in the telephone maintenance domain. From its inception four years ago, he has been a member of the Work Systems Design group, developing and applying a methodology for work practice analysis. In this group, he was the project manager of a research project on the design and application of a multi-agent modeling and simulation environment for work practice analysis (Brahms). Currently, he is working part-time on his doctoral dissertation on modeling and simulating work practice, at the University of Amsterdam, in The Netherlands. He has also been involved in the research and development of a modeling and facilitation methodology for distributed collaborations. This methodology is widely used within different organizations in Bell Atlantic. Before working at Bell Atlantic, Maarten worked at IBM East Fishkill developing knowledge-based systems for the production control of chip manufacturing. Before that, Maarten worked in The Netherlands, as a project leader in the Knowledge-Based Systems group of one of the largest European software houses. In 1986, Maarten received his engineering degree in Higher Informatics, specializing on knowledge-based systems and knowledge acquisition, from the Polytechnic University of The Hague,The Netherlands.

Part 9: Subcontracts and Consultants

DigitalSpace Corporation plans to use USRA/RIACS as as its research institution.  RIACS technical staff will perform a minimum of 30% of the proposed Phase I effort.  This will include the following tasks:

 

•      Participation in the design of the Brahms VE architecture and interfaces;

 

•      Development and testing of a prototype Brahms VE environment;

 

•      Participation in the technology transfer.

Part 10: Similar Proposals and Awards

DigitalSpace Corporation has no current active proposals submitted to Government agencies.  We also do not plan to submit proposals for related work during 2000 if awarded a contract by NASA.  DigitalSpace Corporation has not received any Government award for work related to the virtual world system it is currently developing.

 

DigitalSpace Corporation has not received previous NASA STTR or SBIR awards.

 Back to > DigitalSpace Proposals