skip to: onlinetools | mainnavigation | content | footer


Content on this page requires a newer version of Adobe Flash Player.

Get Adobe Flash player

Umbra Contact
(505) 844-3621

Umbra Technical Detail & Background

Content on this page requires a newer version of Adobe Flash Player.

Get Adobe Flash player

This page provides a summary of technical detail about Umbra.  Additional technical information is available through some of the papers listed on the Resources page of this website.  See the Products page for a high level overview and video.

Umbra Framework Technical Overview

Umbra Software Diagram

Umbra builds on concepts typically found in continuous-time (time stepped) data-flow-based simulations and control systems.  As with most time-stepped simulations, Umbra schedules most user computation through Umbra's application execution loop, which is known as the Umbra update cycle, and schedules most display computation through a graphic update portion of the cycle.  Umbra supports three levels of application programming.  Modules are typically written in C++ (a Java version has also been developed) as compiled elements.  The modules are typically instanced, organized, and managed with an interactive scripting language (i.e., Tcl) to form a complete application or define a base layer of capability.  An XML layer provides a flexible data abstraction to separate the "what" of various system models from the "how."

The basic unit of Umbra simulation is a module, which encapsulates a state and a computational model.  Modules also may have input ports from which they can read data and output ports with which they can present data.  Output ports can be connected to input ports, making the output port data readable there.  Modules have a virtual update (work) function that is automatically called once each time through the Umbra update cycle.  Umbra modules are typically defined in C++ and organized in dynamically linked (i.e., in the Windows OS) or shared object (i.e., in the Linux OS) libraries.  Ports and connections are typed and can present multiple interfaces.  Specific model classes are derived from the base module classes.  Non-native model libraries and legacy codes are integrated by writing encapsulating module libraries.

A collection of modules is connected together functionality with forward and feedback connectors to form an Umbra System as shown in this diagram.  This System includes a module representing a sensor model and another module representing a radio model.  They are connected via an Umbra connector to a module that represents a behavior module.  The behavior module is connected to the controller that sets the control state for the controller.  The controller is connected to the vehicle physics module which is then connected (via feedback) to the Controller module.  The Sensing and Communication worlds, considered as being outside the System, create and manage the Sensor and Radio module.

Umbra provides realistic physical environments to study the behaviors of agents that operate either as a single entity or as a collection of entities to perform high-level system tasks.  Umbra uses a world module to encapsulate the physical environments such as terrains, weather, plumes, communications, etc.  Umbra's world module enables heterogeneous physics to co-exist in the same simulation environment and share data between worlds in a loosely coupled relationship.  In addition, world modules are used to implement distributed computing environments such DMSO's High Level Architecture (HLA).

A key attribute of Umbra is its ability to correctly model the topological structure of integrated systems.  For example, robots are typically modeled with behavior, effectors and sensors with separate computational modules.  (Here, effector models typically include vehicle motion as well as radio transmissions and other effects modules.  Sensor modules typically include geometric sensors such as touch and proximity sensors as well as radio receivers and chemical sensor models).  These effector, sensor, and behavior modules are then configured into meta-modules that are connected in the same way that real sensors and effectors are connected to robot controllers.

Umbra is currently meant to run on stand-alone platforms (laptops, desktop PCs), but can also operated in distributed parallel operation in cluster settings.  As of 2003, the maximum number of modules run on a single machine has been ~8000.  Since entities (platforms, sensors, humans, etc.) are constructed of modules, the number of entities that can be simulated at one time will vary with the level of fidelity required.  The analytic framework can handle very high fidelity modules (for communications, for instance) at the same time it uses low fidelity modules to represent less important parts of the simulation.  Sandia is proceeding with parallelization of Umbra code by use of multi-core processors and graphic processor units (GPUs).

Unlike classical control system models, Umbra modules can be queried and commanded by the application program at any time.  In addition, modules can interact with each other through Umbra's scripting environment (or directly in the compiled environment) to support asynchronous event behaviors.  For example, Umbra's standard simulation clock can schedule and dispatch events that invoke behaviors on other modules directly or through Umbra's scripting system.  The result is that Umbra can best be described as providing a hybrid simulation engine that combines or mixes discrete event with continuous simulations.  An advantage of Umbra is that it presents these capabilities in a modular data flow environment that includes a wealth of 3D geometric viewing and analysis capabilities.


Analysis and visualization of dynamic physical-cyber operations have been difficult to achieve, yet is critical for truly understanding system security in the context of operation or mission. Sandia’s strong program in cyber security is leveraging Umbra to provide substance to cyber analysis.

Where other cyber simulation capability exists, Umbra can take advantage of existing work rather than reinvent or port other simulation code. For instance, Umbra has successfully co-simulated details of communication down to the protocol level with another popular package, OpNETTM.

As one solution, Umbra’s ability to simulate physical, cyber, and human behavior elements is being combined with OpInsight, a flexible dynamic transaction event visualization tool built upon Umbra. Dynamic visualization allows analysts to understand operational relevance and detect patterns in behavior displayed at rates faster, slower, or equal to real time. OpInsight is available to other applications and projects that are using Umbra. Because OpInsight visualizes dynamic transactions, it is also useful for viewing other interactions, such as social network activity. See more information about OpInsight.

Web site contact: