Chapter 3

"Synthetic Natural Environments Representation"


Wesley Braudaway, Ph.D.
Science Applications International Corporation


A Synthetic Environment has been defined by the Defense Modeling and Simulation Office (DMSO) as an "environment within which humans may interact through simulation(s) and/or simulators at multiple networked sites using compliant architecture, modeling, protocols, standards, and databases." See the following location for the DMSO Masterplan:

Within the Synthetic Environment is a Synthetic Natural Environment (SNE) that represents the natural environment at a specific geographic location (geo-specific) or at a typical class of geographic locations (geo-typical) (e.g., mid-western desert area). From the Terrain Modeling Program Office’s glossary, a SNE "consists of the natural physical environment surrounding the simulation entities including land, oceans, atmosphere, near-space, and cultural information. " To find the glossary use the following:

An instance of a SNE can represent portions of the following environment depending on the needs of the simulation: the terrain, terrain features (both natural and man-made), 3-D models of vehicles and personnel, the ocean (both on and below the surface), the ocean bottom including features on the ocean floor, the atmosphere including environmental phenomena, and near space. In addition to physical objects, the SNE includes the specific attributes of these environmental objects as well as their relationships. The actual content of a SNE instance will vary depending on a synthetic environment’s requirement for a natural physical representation.


Use in Simulation

As a common representation of the physical environment, the SNE is a critical element in a simulation since it forms the playing field in which simulated operations and interactions occur. Depending on the purpose of the simulation (for our examples, different types of synthetic battlefields), the SNE may represent various aspects of the full dimension of ground, air, maritime and space operations across the entire spectrum of conflict and operations other than war (include domestic emergencies, nation assistance, disaster relief, peacekeeping, and peacemaking). For example, in a high fidelity simulation (near reality) the SNE must realistically represent the dynamic effects of natural and man-made phenomena on weapons, vehicles, communications, unit and individual performance. In this example, the SNE must reflect man-made and natural features as well as dynamic changes to the environment as a result of combat operations. The environment must also implement the influence of day, night and climatology effects on systems and operations.

The complete modeling of entities within a synthetic environment can be divided into the following components (as shown in Figure 1)

image30.gif (42232 bytes)

Figure 1: Components of the Synthetic Environment

Correlation across multiple applications (DIS, HLA Interoperability)

The role of distributed interactive simulation (DIS and now HLA) is to combine simulators, constructive simulations, and stimulated equipment of varying types into a simulation exercises to realize a common synthetic environment. These heterogeneous simulations (simulations built for different purposes, utilizing differing technologies, utilizing various vendor products and representing various services) must interact in a realistic manner within the synthetic environment. The ability to provide realistic interactions between these heterogeneous systems has been defined as interoperability. "Interoperability is achieved if the perception of the same events is similar and consistent when the events are viewed or experienced from different simulators." (from Farid Mamaghani, "Interoperabilty: It’s time for action" in Multi-Resolution Environments in Simulation Workshop, located at the following URL:

One requirement for achieving interoperability is that the simulations must operate in a common synthetic natural environment. Simulation systems interacting within DIS are distributed and provide their own local representation of the environment that is tailored to the performance and capability constraints of the system. The level of interoperability achieved between these simulations depends heavily upon the degree of consistency, completeness, and correctness between these local representations of environmental parameters and effect models. To obtain valid interactions, no simulated entity may gain a tactical advantage or disadvantage based solely on technical limitations of the terrain database.

Interoperability is complicated by these multiple, local and different representations of the same synthetic natural environment (one for each heterogeneous simulation). For example, a computer image generator represents a road by the set of polygons while a computer-generated force represents the same road as a topology of road segments. The complexity of the SNE adds to the difficulty of creating an interoperable environment. The variety of facets in a SNE include natural components such as terrain, vegetation, ocean bottom, weather, clouds, time-of-day, sea-states, etc. and synthetic components such as cultural features, bomb craters, weapons, chaff, flares, etc. Different uses and applications will lead to different trade-off selections in every aspect of the environmental representation from entity fidelity to terrain database content and special effects details. Obtaining SNE correlation may be the most complex challenge facing the simulation interoperability community. Historically, most simulations were developed for air applications at high altitudes and high speeds. The terrain and environment requirements for modern ground applications are much more demanding and have not been adequately developed.

In summary, a precondition to obtaining interoperability is to ensure that the SNE (the environmental ground truth) of multiple heterogeneous simulations is correlated (see Figure 2). Clearly, however, a correlated SNE is not a sufficient factor in ensuring that the resulting interactions between simulated entities represent valid, fair fight performance. The discussions of these other influences are contained in other chapters of this document.

Application requirements for SNE

The various representations of the SNE, impacting the complexity of the SNE correlation problem for interoperability, are driven by the variety of reasoning, visualization, fidelity and processing requirements of a wide range of simulation applications. In "Modeling and Simulation Requirements Database Summary Report", DMA and SAIC (Sept. 30 1993) conducted a review of the digital terrain requirements for a large set of simulation applications. The range of simulation applications included training, analysis, and systems acquisition as well as the range of simulation capabilities including visual

image31.gif (22277 bytes)

Figure 2: SE Interoperation

systems, computer generated forces, and sensor modeling. These different simulation systems and simulation uses require different aspects of a SNE representation. There are two fundamental uses of the SNE: algorithms that derive implications based on the representation of ground truth (i.e., reasoning) and algorithms that provide visualization. These two fundamental uses usually require different representations and stress different aspects of the SNE. For information on the DMS/SAIC document see the following:



Reasoning based on the SNE includes those algorithms that derive implications of the physical environment on the simulation of entities. These algorithms include impacts on entity movement, sensing other entities, and weapons effects. The following discussion is far from complete but offers some insight into the kinds of capabilities that simulation systems implement using their representation of the SNE.

The effect of the SNE on movement include the route and speed impacts of feature dense terrain (i.e., travel through forests or urban settings), the impact of traveling through wetland, the effort to avoid traveling across unfordable waterways, or traveling along the topology of a road network. These algorithms require an explicit representation of these SNE objects and attributes to implement the movement effects they create. For example, movement speed is determined by considering whether the unit is on or off road, terrain slope, vegetation and areas containing buildings, or traction as affected by soil wetness.

As another example, route planning algorithms use the representation of transportation networks such as roads (including bridges) or rivers to automatically compute a unit’s route of movement. These algorithms benefit from an explicit representation of the network topology. This topology provides an explicit representation of the spatial relationships between transportation segments (e.g., connectivity and adjacency) instead of deriving the spatial relationships using geometric calculations. For an image generator, where spatial relationships between environmental objects are not needed to create a scene, topology is of little use. However, for a computer-generated force trying to derive the best movement route, a topological structure improves the algorithm performance.

A wide range of algorithmic approaches exists to generalize the movement capability to include cross-country mobility. These algorithms range from very sophisticated vehicle/terrain interactions such as the NATO Reference Mobility Model used to support the design of new vehicles, to the calculations of abstract mobility corridors (such as in Eagle), to the abstract determination of go/no-go terrain movement segments based on map data.

Another important reasoning capability of movement, unit placement, and sensor functionality involves the determination of cover and concealment, which is primarily effected by terrain surface configuration (terrain elevation). Depending on the required level of fidelity, some systems use vegetation and vegetation density/visibility to determine the measure of cover and concealment.

Line of sight (LOS) algorithms occupy a central role in combat simulation. LOS is used in the detection and acquisition of both airborne and ground units, it is used to determine weapon impact, and it is used for communications network deployment. For some models that use only statistical terrain, LOS is inferred from probabilistic parameters with no reference to specific underlying terrain. In higher fidelity systems, LOS is calculated using terrain elevation only and in others feature height (vegetation and urban buildings) is added to the terrain heights. A large number of line of sight algorithms are in use and vary depending on the level of fidelity needed to support the simulation and the capacity of the simulation system to support algorithm complexity.

Line of sight algorithms used to emulate sensor detection first determine if a line from an observer to a target intersects intervening terrain or terrain features (observer and target heights are often considered). If the terrain surface intersects the observer to target line, LOS does not exist. If LOS exits, it may be degradation when terrain features (vegetation/urban areas) intersect the observed to target line. The amount of degradation is based on the terrain feature density. Other effects may also be considered to determine detection and identification including factors such as smoke or dust blocking the LOS and target-to-scene contrast. More advanced LOS algorithms consider the percentage of the target that is visible to the observer.


Depending on the use of the simulation, the SNE may be required to support 3-D, 2-D and/or topographic line map capabilities. Each capability uses different aspects of an SNE representation that is specifically designed to efficiently support the particular capability. For example, the primitive data types processed by a computer image generator are simple polygons and texture maps. Polygons are used to represent all objects within the visualizable portion of the SNE. Texture maps are digital images that can be applied to polygonal surfaces like "wallpaper." Polygons also have other, less obvious, graphic and dynamic attributes describing the way that object would appear, act and react in a simulation. Figure 3 illustrates a small range of possible 3-D visual views of the SNE. For additional snapshots refer to the following:


Figure 3: 3-D Visualization Categories

Most visual systems have hardware dependent constraints (the capacity of the real-time computer image generation hardware) that limit the complexity of the scene displayed during a simulation. In this context, complexity is defined by the number of polygons (3 or 4 sided flat surfaces), and the number of pixels ("picture elements" or discrete points on a display) that are required to represent a scene. To support the hardware limitations, large angles of view and long viewing ranges are implemented with low scene density representations (fewer polygons/pixels per unit area) and small angles of view and short viewing ranges equate to high scene density representations. The SNE supporting the visual system must be capable of providing these multiple levels of scene abstraction to support this capability.



The representation of the SNE is also determined by the needed fidelity (agreement with the real world) of the simulation application. The physical size of the area to be defined by the SNE can also vary from large air defense scenarios (thousands of square kilometers) to very small area urban warfare scenarios. It is expected (because of computational limitations) that large area scenarios typically require only a highly generalized modeling of the environment (low resolution data), whereas the smaller area scenarios require a more detailed representation of the actual terrain, requiring very high resolution data.

The representation alternatives within the SNE can include:

Application fidelity ranges from constructive (low fidelity aggregate) to virtual (high fidelity entity) simulations.


From the Terrain Modeling Program Office’s glossary, constructive simulation is "a computer model representing simulation elements, their functions and/or the terrain they operate on in an aggregated manner." It also defines aggregate unit level simulation (e.g., corp level) as a stochastic, event-driven time-stepped combat model with resolution at maneuver battalion (i.e., units smaller than battalions are normally not represented explicitly). The effects of these lower level units are estimated stochastically (i.e., attrition and movement).

Most large constructive simulations run faster than real time and simulate at a unit level of resolution rather than platform or individual level. The terrain surface of the SNE for a constructive simulation is represented by some type of grid organization to simplify algorithms that compute movement and sensor detection. While some representations use square grids, others use a hex grid representation. The hex representation, for simple movement algorithms, provides six directional options for a movement step event and hex polygons tile a terrain surface easily. Simulation using hex grids, such as Corps Battle Simulation (CBS), usually specify hex grid attributes to identify the surface condition (e.g., soil type, terrain feature density) that affect the amount of time it takes to move to an adjacent grid. The hex characteristics can include trafficability, elevation, roads, and chemical or nuclear contamination. The terrain type code and barrier type recorded as part of each hex grid identifies movement factors affecting unit movement within and between hexes. These terrain types could include water, desert, forest, mountainous, city, open terrain, etc.

Other simulations, like EAGLE Combat Model, implement ground maneuver over a network of mobility corridors. A terrain preprocessor that conducts a detailed analysis of digitized terrain data produces these corridors. This approach provides a representation that conforms closely to the way in which military personnel think about terrain. This terrain network is composed of mobility-corridor edges and nodes.

Line of sight is not typically required for these lower fidelity simulations where detection, interaction, and attrition is typically computed stochastically between particular units that are within a specific range (or neighboring grids) of each other.



The Terrain Modeling Program Office’s glossary defines virtual modeling and simulation as "a synthetic representation of warfighting environments patterned after the simulated organization and operations of actual military units. Differences in the representation of the simulated battlefield (i.e., whether real world, computer generated, or interactive players in simulators) are transparent to the participants who interact with their particular representation of the warfighting environment." Although this definition clearly indicates a high level of fidelity, the current state of image generator technologies and the trade-off decisions imposed by real-time performance, the expense of high speed computer capabilities, and algorithm complexity drives the implemented level of fidelity. The SNE for each application must be designed with these considerations and must correlate between the differing applications.

SNE Generation

Although interoperability issues are not fully understood, axioms do exist. For example, conventional wisdom dictates that correlated SNE representations should result from a generation process starting from the same integrated set of environment data sources. Additionally, it is known that a SNE interchange process is a necessary step in the development of correlated SNE representations for a set of interoperable simulations. A consistent, efficient, and unambiguous initial condition of interoperability is the measure of a good interchange and the pre-condition for achieving interoperability.

The production of a SNE representation is extremely expensive. It is imperative that common SNE data, exploitation software, and process models be reusable across multiple simulation applications. With declining budgets, the Department of Defense (DoD) cannot afford the luxury of producing multiple terrain products over the same geographic area. A number of execution agents have been established under the Defense Modeling and Simulation Office to ensure that modeling and simulation requirements for SNE are satisfied:

Refer to the following pages for more information about these offices:

The database generation technology is comprised of:

For further information on database generation technology refer to the following location:


Generation process

As shown in Figure 4, databases containing SNE data are generated by integration and data fusion from a variety of terrain and environmental data. The database development activity is typically supported by hardware and software tools that extract, smooth, and fuse the required data into a coherent representation. Source data for these databases can be obtained from several origins in various data formats and resolutions. This data is input to a proprietary database generation system where the data is manipulated to fit a specific image generator system and meet specific application requirements. The result is a generic (geo-typical), or location specific (geo-specific) database. From these databases, run-time versions can be generated that are application specific representations of the same SNE that are specifically designed for efficiency and specific characteristics of the application. To review an example of an application specific database standard refer to the following:

image32.gif (24269 bytes)

Figure 4 Current Database Generation

The generation of a high fidelity SNE representation includes the integration of terrain elevation data, natural and man-made features, and dynamic and atmospheric effects. The database can also be enhanced to credibly portray the effects of natural light (low light, dark night, etc.); natural and man-made obscurants (smoke, dust, fog, etc.); chemical and biological agents; electromagnetic forces, acoustic and seismic transmission; and dynamic terrain (cratering, ditches, rubbling, etc.).

These high-resolution databases are not only very expensive to generate, but also require much time to develop. Although the process is improving, there is currently no effective rapid SNE production capability that is needed to produce geo-specific databases supporting planning and rehearsal for crisis and contingency operations.

For a sample of vendor tools that generate SNE databases, refer to the follow example:

The typical SNE database generation process includes the steps of collecting the desired environment data from a set of data sources and integrating the collected data into a cohesive representation of a specific SNE. Simulation applications must then compile this representation into a run-time effective format that contains only that portion of the SNE relevant to the application.


Data Sources

The source data for the development of a SNE are acquired from a variety of repositories. The most common sources were developed by the Defense Mapping Agency (DMA), however more recently, the National Imagery and Mapping Agency (NIMA) provides this data. For information on NIMA refer to the following location:

NIMA manages and provides imagery and geospatial information to national policy makers and military forces. It supports national security objectives by providing timely, relevant, and accurate imagery, imagery intelligence, and geospatial information.

A wide variety of data sources exist that cannot be exhausted in the chapter but can be found by examining the provided web sites. The most common data sources for use in modeling and simulation include the digital terrain elevation data (DTED), interim terrain data (ITD), digital feature analysis data (DFAD), imagery data and cartographic data. These key data sources are defined as follows:

DTED is a digital elevation model of the terrain surface configuration characterized as a uniform matrix of elevation values for a specific geographic area. It provides basic quantitative data for all military systems that require terrain elevation, slope, and/or gross surface roughness information. DTED level 1 is based on a grid spacing of 100 meters; level 2 is 30 meter spacing, level 3 is 10 meter, and level 4 is 3 meter grid spacing. Smaller grid spacing provides a more accurate sampling of the specific geographic area but at the expense of larger data storage than required for larger grid spacing over the same area.

ITD is an interim product for digital terrain analysis that was provided until the objective Tactical Terrain Data (TTD) data source could be fielded in its final format. The ITD provides cultural/terrain feature models and is composed of six thematic layers: vegetation, surface materials, slope, surface drainage, obstacles, and transportation.

DFAD consists of selected natural and man-made, plain-metric features classified as point, line, or areal features as a function of their size and composition. Each feature is assigned an identification code and further described in terms of composition, height, length, and orientation (e.g., lakes, rivers, forest, glaciers, urban areas, predominant towers and bridges, roads, railroads and navigable waterways).

Further information about the typical Defense Mapping Data is described at the following location:

Weather and other environmental data can be obtained from systems such as the Master Environmental Library (MEL). MEL is a wide area network-based data discovery and retrieval system that provides access to geographically-distributed oceanographic, meteorological, terrain, and near-space information and data. MEL will eventually host a models-and-algorithm catalog that not only addresses the atmosphere and space domains, but will also be expanded to all environmental areas. More information about MEL can be found at the following location:

Ocean and bathemetry data can be investigated at the following location:



The integration of these data sources for developing a SNE is not an exact, straightforward, series of steps. The effort involves fusing and reconciling the data for a variety of reasons including the following:

This integration effort results in a database that is then compiled into a run-time format for a specific use. For example, visual systems typically function using a terrain skin model that consists of a set triangular polygons whose planar surfaces and varying vertex elevations represent a portion of the terrain surface. These polygons are constructed from the provided DTED elevation grid after the integration of other terrain topology such as ITD lake areals. One advantage of the triangular polygon representation of the terrain skin is that polygons can be merged to save on storage and run-time processing requirements for those terrain areas where little change in elevation exists.

The integrated SNE may be required to support a variety of uses including, but not limited to:


Application Data exchange

Once an integrated database describing the complete SNE is developed it must be exchanged amongst the various simulation systems that will interoperate and compiled into their specific run-time representation. The process of sharing these databases has been supported through the use of format translators that do not necessarily maintain a complete and consistent representation of the SNE. Without an effective interchange mechanism, most simulated environment database interchange continues to be accomplished by point-to-point unique conversions between two applications, as shown in Figure 5. These point-to-point solutions are expensive, time consuming, and often unreliable (causing losses and creating ambiguity). The chances of providing an interoperable SNE using this approach are not very good.

image33.gif (6982 bytes)

Figure 5: Point-to-Point Database Exchange

A number of standards have been developed to improve this exchange process. This chapter describes the Standard Simulator Database Interface Format (SIF) format and the more recent Synthetic Environment Data Representation and Interchanges Specification (SEDRIS).



The Standard DoD Simulator Digital Data Base/Common Transformation Program, also known as Project 2851, was initiated to eliminate the proliferation of redundant DOD training simulator databases and reduce the software development that produces point-to-point database exchanges. Project 2851 established the Standard Simulator Database (SSDB) as a central repository of validated simulator databases for use by the DoD training simulation community. SIF defined by Mil-Std-1821, serves as a vehicle for entering and extracting databases via the SSDB. The government’s objective was to require their database builders to supply databases to the SSDB in this SIF format. Simulation system developers could extract databases from the SSDB in either SIF or Generic Transformed Database (GTDB) format.

As a quick characterization of the SIF format, it is an ASCII string format that is compressed by elimination of leading or trailing blanks, the use of binary rather than ASCII data for long list of coordinates, and support for standard image compression techniques. More information about SIF can be found at the following location:

The SSDB was designed to support a wide variety of database formats that support a variety of image generators. However, to use this resource for developing interoperable SNE databases both the external producer and consumer of a SIF database must have a common understanding of the semantics defined within the database representation. The standard states explicitly that "SIF is not a ‘hands-off’ standard in that compliance with it cannot simply be written into a contract, and expected to achieve good results, without a mutual understanding of its implications in the context of the specific application." Information about the SDBF can be seen at following location:



The SIF standard supports the interchange of environmental data for a specific subset of SNE representations and for a specific subset of modeling and simulation applications. These applications are typically air flight simulations that required a visual scene representation of the ground but do not require a representation for directly interacting with the ground (i.e., providing flight above ground rather than ground transportation directly affect by the ground configuration and features). A standard is required that supports a broader class of SNE applications.

Additionally, Project 2851 provides an exchange format with little semantic representation of the data placed in that format. As stated previously, this requires careful coordination between the producers and consumers of the SNE information. As the modeling and simulation community grows and as the transition of people within the community continues, the SIF format will become impractical. This requirement for point-to-point coordination, therefore, reduces SIF to yet another point-to-point translation mechanism. In summary, the SIF format is missing the ability to support the complete class of SNE information and a semantic representation of the SNE data and relationships between the data.

SEDRIS addresses these limitations by providing a complete (terrain, ocean, atmosphere, and space) data model (rather than format) of the SNE. The data model provides both a means for representing all objects that make up a SNE and a means for describing the relationships between the objects. In contrast, a format specifies the actual bytes used to store data on a storage medium. The SEDRIS program not only defines a data model specification for representing an instance of a SNE but also provides a set of access methods to traverse the data model and a transmittal format (STF) that implements the storable version of the data model. With these capabilities SEDRIS represents significant progress toward interoperability among heterogeneous simulations by providing a means for obtaining a complete and unambiguous interchange of the SNE. For a description of the SEDRIS project refer to the following location:

The SEDRIS project objectives are described at the following location:

The SEDRIS data model is based on an object-oriented notation representing the SNE objects, their relationships and their attributes. Specific information about the SEDRIS data model and its specification can be found at the following location:

SEDRIS supports the generation of interoperable SNE databases by providing a consistent, integrated, and correlated view of the SNE that each simulation application translates into its specific run-time representation. However, SEDRIS, by itself, does not solve the interoperability problem. These other interoperability factors are described in other chapters.

Using SEDRIS to support SNE exchange, a database producer constructs a SNE in their native database format and using the SEDRIS application programmer’s interfaces (API), constructs a SEDRIS transmittal for exchange as shown in Figure 6. It is envisioned (as shown in Figure 7) that future SNE generation will start from a modeling and simulation master environment library represented as a complete SEDRIS transmittal containing an integrated set of SNE data sources. SNE consumers extract their SNE data from the SEDRIS transmittal using the SEDRIS API to construct their native run-time SNE database representations. The use of the API as a standard access method to a SEDRIS transmittal along with the common data model, ensures an unambiguous, loss-less data exchange between simulation applications.

image34.gif (6935 bytes)

Figure 6: SEDRIS Transmittal Development

Figure 7: The SNE Generation and Exchange for the Future

Some have hypothesized a relationship between the High Level Architecture and SEDRIS where no relationship currently exists except that they address very different aspects of the interoperability problem. SEDRIS addresses the problem of developing multiple databases having a correlated representation of the same synthetic natural environment. That is, database construction in preparation for a set of interoperable simulation executions. HLA, however, addresses the communication infrastructure for transmitting public data that allows simulations to interoperate during a simulation execution. Each simulation system contains a static representation of a SNE. Dynamic SNE data will be communicated using an HLA Federation Object Model specifically designed for effective and efficient (likely real time) data transfer. The SEDRIS data model was designed as a complete holistic representation of any SNE and not for real time communication of such data. The likelihood that the SEDRIS data model will be used explicitly via the HLA for interoperable communication is remote. It is not evident that there will be any influence to either HLA or SEDRIS with respect to the other.


SNE Representations

Simulation applications depend on an adequate representation of the SNE to support the simulation of unit or entity interactions with the natural environment. For high fidelity simulations, this interaction includes the dynamic effects of simulated weapons. This requires an effective and integrated representation of terrain, oceans, atmosphere, and space. This section provides a brief overview of the representation requirements for Land, Air, Space and Ocean applications.


Coordinate Systems

A key component of every SNE representation that is often overlooked and ultimately affects interoperability is the coordinate system used to represent any complex region of the earth. For more information, consider the following very informative tutorials:



The representation of the surface of the earth must include its configuration (elevation structure), composition (surface types), natural features (forests, lakes, rivers), and man-made features (roads, railroads, bridges, urban areas, buildings, tunnels, etc.). High fidelity modeling of the terrain surfaces includes the representation and effects of weather, tree types, shadows, thermal variations, and seasonal and diurnal variation such as ground wetness, grass and snow, and foliage coverage. The terrain surface also includes the representation of inland waters and sea floor bottoms less than 30 meter deep. A simulation should also be able to dynamically interact with the terrain in areas such as building or destroying bridges, dams, tank ditches, etc., and be affected by craters, mud, and other dynamic terrain features.


An SNE represents the atmosphere in an area ranging from the earth’s surface to the upper boundary of the troposphere. Depending on the simulation requirements, this SNE representation can account for obscurants such as haze, dust, smoke and contaminants such as nuclear, biological and chemical effects. Weather conditions may be required for the representation of fog, clouds, precipitation, wind, humidity, pressure, radiated energy, temperature, and illumination. The simulation should also be able to dynamically model the affects of generating, moving, dispersing, and dissipating atmospheric phenomena in both space and time dimensions.

An SNE representation of space continues above atmosphere beyond the upper boundary of the troposphere. The simulation requirements are driven by the requirements to affect satellite and spacecraft performance as well as communication effects caused by changes in the geomagnetic field and the presence of charged particles. These characteristics include atmospheric/Electro-magnetic propagation, solar radio emissions, Solar EUV flux, and solar phenomena.


The SNE representing the ocean includes both the ocean bottom and surface/sub-surface characteristics. The ocean bottom, much like the terrain surface, includes the configuration (depths, contours, and bottom composition) and bottom features. The surface representation includes the sea state, tides, and currents. The represented sub-surface characteristics include temperature, pressure, ambient noise, salinity gradients and acoustic conditions.


SNE Future Needs

The future of SNE development is being driven by three requirements. Firstly, as the state of modeling and simulation advances and as the computer processing power continues to increase, the requirements for higher fidelity, dynamic SNEs that cover a larger physical region become more extensive. Secondly, the SNE capabilities are also be driven by the desire to move the synthetic environment from low populated rural setting into more congested urban settings that are more representative of modern military operations. Finally, the application of modeling and simulation for mission planning and rehearsal places a challenging requirement on the SNE generation to be both very fast (24-48 hour developments) and accurately represent real locations (i.e., geo-specific).


Dynamic Environments

The recent application of image generators for ground-based simulation has increased the desire to improve the synthetic environment’s ability to interact with terrain. In reality, ground warfare involves extensive interaction with and modification of the terrain including effects such as tread marks and vegetation damage, cratering from weapons, real-time man-made alterations to terrain (bridge repair, obstacle construction), and weather effects. The changes to the SNE that provide both visual and behavioral effects within the synthetic environment are referred to as dynamic terrain. At present, very static and limited methods have been applied to this challenge such as placing craters or emplacement objects at pre-determined locations within the SNE. In an unlimited simulation, a more realistic capability allows modifications to the terrain anywhere and at any time.

In addition to dynamic terrain, there are SNE representation efforts to support dynamic environments including both dynamic effects of weather and dynamic phenomenology such as smoke propagation and dust trails. Dynamic environments include the objects, algorithms, data and techniques required to replicate weather, weather effects, background changes due to environmental effects, effects on acoustic propagation, and the transport and diffusion of aerosols as by-products of models and simulations.

New representations and modeling approaches are being defined to experiment with the capability to dynamically manipulate the SNE. These efforts include the following:


Military Operations in Built-up Areas (MOBA)

Military Operations in Built-up Areas (MOBA) and Military Operations in Urban Terrain (MOUT) are initiatives that require high fidelity and feature dense SNEs. The challenge is to develop a synthetic urban area providing urban training, crisis management, mission planning, rehearsal, intelligence, and command and control capabilities. This effort and the development of SNE generation data sources to support it are described in the following locations:


Mission Rehearsal

With increased SNE fidelity, simulation applications for mission planning and mission rehearsal become more viable. Mission rehearsal provides a capability to practice and improve tactical skills for a specific mission and in a specific location before mission execution. Rehearsal also provides feedback to the mission planner as to the risks and probability of mission success.

These applications require more realistic terrain that is "geo-specific". It is believed that geo-specific SNEs are vital to mission planning and mission rehearsal, since using synthetic or geo-typical terrain may develop the wrong expectations and responses when confronting the real situation. However, the expected database generation cycle to support these applications must be 24-48 hours, which cannot be supported today. Some related efforts can be found at the following locations:



One of the most critical preconditions to obtaining interoperability between multiple heterogeneous simulation systems is the correlation of the SNE represented locally by each simulation. Each local representation is specialized for efficient use by the application and is customized for the application’s specific requirements for a SNE. However, these individual representations must implement the same physical environment and must correlate to achieve interoperability. To obtain correlation between these multiple SNE representations, they must be generated from the same integrated SNE database through an effective interchange specification. SEDRIS will be that consistent, unambiguous, and loss-less database interchange mechanism.

The challenges for future SNE developments are driven by the requirement to be high fidelity representations of larger areas including a whole earth model. These future SNEs must more accurately represent specific geographic locations (geo-specific) and must be generated in a much shorter time than currently achieved. Additionally the SNEs must support a completely dynamic terrain and environment representation. More advances in simulation applications depend on significant advances to the representation of the synthetic natural environment.


Author's Biography

Wesley Braudaway, Ph.D. is a Chief Scientist and Direct of Technology for Science Applications International Corporation's Orlando's ASSET Group. Dr. Braudaway is also the lead for the ASSET Group Research Team involved in several Computer Generated Forces related research and development programs.   He was a member of the TASC/SAIC team implementing STOW's Integrated Compact Terrain Database (ICTDB) program and was the System Architect for CCTT SAF development. Dr. Braudaway received his Ph.D. from Rutgers University's Computer Science Department and has been actively involved in the M&S community since 1991.