Synthetic Environment (SE) Core Database Development Process
Robert Cox
PEO STRI, PM CONSIM
Guillermo Flores
PEO STRI, PM CONSIM
Mark Johnson
PEO STRI, PM CONSIM
Dolores Lowe
PEO STRI, PM CONSIM
Connie Perry
PEO STRI, PM CONSIM
Keywords:
ABSTRACT: The SE Core is part of the United States Army's overarching strategy of developing simulation systems that help make our Warfighters the best trained in the world. The two primary initiatives under the SE Core program are the Architecture and Integration (A&I) and the Database Virtual Environment Development (DVED). The A&I is not the focus of this presentation and will not be discussed. The SE Core's primary mission is to rapidly generate correlated simulation system terrain databases. The master SE Core database is populated from a union of multiple authoritative data sources by using a suite of commercial and government-off-the-shelf database tools. The SE Core DVED architecture and tools will enable the generation of SE Core runtime terrain databases in days or weeks vice months or years.
The focus of this presentation is to describe the SE Core DVED production process. Key areas that will be discussed will include the overall process and then focusing on the details to include: the initial database request process; how source data for the requested database is gathered and prepared for use; the refinement and enhancement of the source data; the standardization process; and the verification and quality measures employed before delivery. Additionally, the authors will present the current production along with the various formats and map projections that are supported. The presentation will end with exemplars of future efforts that SE Core DVED will be pursing in the future.
1
1. Introduction
The acquisition of simulation training databases has been a very complex, lengthy, and costly endeavor. SE Core’s effort is developing processes and tools to create non-proprietary, open format, image generator (IG) independent Environmental Representation (ER) databases1.
The SE Core Master Database (MDB) is the central repository for the creation of correlated databases used to train, mission plan, or mission rehearsal in the Live, Virtual, or Constructive (LVC) domains. Within the DVED the database architecture is coupled with a suite of COTS tools that enable database development.
The SE Core effort will also develop common virtual vehicle models, common virtual sensor simulation software, and the virtual simulation component of the dynamic environment. The dynamic environment will include approximate visual effects from simulation (e.g., munitions, mobility, engineering, rubbled buildings, etc.)2.
The SE Core process is flexible, data-driven, and extensible. The Standard/Rapid Database Generation Capability (STDGC) is designed to standardize, align, and clean source data in the Master Terrain Database Generation Toolkit (MTDGT), which also is used to generate synthetic environment data using the Runtime Database Generation Toolset (RDGT). Data is exported in various formats from a standard application programmer interface (API)3. Furthermore, the SE Core process addresses other challenges such as miscorrelation between simulations and lower database generation costs.
In this paper we will first provide some background on the terrain database generation process. Next, we will present the SE Core methodology to include how a database is requested, the procedure for gathering source data, the standards that are used by SE Core, and the techniques used to refine and enhance the data. We will end with a discussion of the verification and quality process used by SE Core.
2. Background4
Military training simulation systems have been around for decades. Most of these systems have used some derivation of the real environment to represent the three-dimensional reality. In the last three decades the price-performance benefits of computer technology and the demand for reconfigurable, less expensive, and more realistic representations have driven simulation systems towards real-time digital computing and fully synthesized environments.
Until the early 1980's, simulators were mostly stand-alone systems designed for a specific task training purpose. Until the introduction of the SIMNET program, no one had ever used a multitude of simulators in a combined forces training environment, interacting over a network in real-time. SIMNET technology allowed crewmembers in one simulator, to interact with many other manned or unmanned simulators located at the same or other training sites.
Environmental Representation databases are comprised of many parts. Those parts include but are not limited to the terrain surface, terrain features, 3-dimensional models, textures, images, and other data such as system specific data to satisfy computational requirements and labels for producing electronic and paper maps.
There are several constraints on the creation of environmental databases. Perhaps the most prominent of these is dictated by the real-time computation requirements. Since processing power is often limited, once a computing platform is chosen for a given cost-performance range, the software must be designed for best real-time performance. This means both the data and the data structures stored in a platform-specific version (runtime) of an environmental database play an important role in optimizing the system performance. Given the fixed computational budget of a system, the database designer must take into account the application-specific requirements, the size and extents of the database, the desired density and fidelity, as well as the type and amount of the available raw data elements that must be incorporated into the database.
There are other application-specific requirements that must be taken into account such as those related to whether the database will be used for air, ground, sea, near ground, or any combination of these simulations. The detail needed by a simulator that allows an individual to walk on the terrain is much greater than that expected for a helicopter simulator typically flying several hundred feet in the air. Database density, size and extents, viewing range, field of view, and other important simulation requirements dictate the amount and type of data that can be included in a database without overwhelming the performance requirements.
Often the intended simulation platform imposes specific constraints. The specific special purpose hardware architectures, designed for the sole purpose of real-time image generation, impose vastly different constraints on the database contents. Two database designers building a database of the same region for two different IGs often arrive at entirely different end results. The polygon or object processing capacity of an IG limits the database density to levels that can be processed in real-time. Similarly, image rendering techniques drive whether a database can contain textures and how many, or if the image generator can render all the objects that are potentially viewable in a scene within a fixed frame time. There are other architecture-specific features such as caching scheme, processing of transparent objects, or image enhancement techniques like anti-aliasing drive how a database may be partitioned.
These types of computation constraints are not unique to visual systems. Any information technology application that must achieve specific real-time performance measures has to reflect such objectives in its design. This in turn impacts the data structures, data types, and the information that is needed and expected to be available from a database.
Interoperability of multi-fidelity systems on the same network is highly desirable; in fact it is often demanded. The challenge is in determining the "right" type and amount of environmental data that each simulator should use to ensure interoperability. Most successful heterogeneous networked exercises have been conducted under restricted conditions.
A common misconception is to equate success in the interchange of data with success in interoperability. Interchange of data does not guarantee interoperability, but is one necessary condition for achieving it. Since the variables affecting interoperability are many and complex, effective mechanisms for making the database interchange process successful become significantly more difficult and challenging.
A critical factor in constructing and sharing environmental data is incorporation and use of good tools. Most tools are special purpose, given the various criteria and techniques employed by different suppliers for constructing and tailoring databases. As the domain of networked simulation expands and other information technology sectors emerge, the need for more common and yet more sophisticated tools will increase.
Figure 1 is the SE Core processes with the objective to be able to collect, generate, and manage the Master Database (MDB) with the highest fidelity of source data available. There are four major parts of the process. For this paper the focus will be on how a database is requested, the gathering of source data and its refinement. We will include a discussion of the standards and quality measures that are used.
Figure 1: SE Core Process
3. Database Request Process
The SE Core Database Request process is shown in Figure 2.
Figure 2: SE Core Database Request Process
Initially a program fills out a database request. If the data already exists in the MDB and a means to generate the required formats is available (e.g. plug-ins) the request is forwarded directly to the production team and the desired data in the requested format is prepared and sent back to the requesting program.
If the desired data is not already in the MDB, the request is validated by the US Army TRADOC Capabilities Manager (TCM) Virtual to include the size of the database region, the level of fidelity required, and any other requirements of interest to the customer which have been validated by TCM Virtual.
The database can be divided into separate zones if the customer requires. Those zones range from providing only the terrain skin for a reqion in the database to high fidelity inserts of urban environments. Currently, there are five (5) different zones available for the customer to request and they include levels of fidelity of the transportation network, population density to include buildings and building interiors, any hydrography, significant military operational features, and various vegetation that is required.
Once the request has been validated, it is passed to the program manager. At this point, source data is collected (discussed in the next section) and any revisions to the request are processed depending on the needs and availability of data. If all is acceptable to the customer, the request is passed to the database development team. The current and future data formats available from SE Core will be discussed in a later section.
The customer is provided with a database request form. That form allows the customer to specify the content they require. This includes but is not limited to the features they require (e.g. bridges, roads, agricultural areas), areas of significance to include their location (e.g. specific buildings, airfields), and the format of the database transmittal. The customer can also use this form to request any high resolution inserts that are of importance to them.
4. Source Data
When a database request form has been submitted and it has been approved, the process of gathering source data begins (Figure 3).
Figure 3: SE Core Source Data Collection Process
There are five (5) questions that must be answered as the database request is fulfilled. Those questions are:
1. What are the technical requirements (database and system)?
2. What are the resources required for acquisition?
3. What are the storage/space requirements for the data?
4. What coordination of acceptance of the source data must be done and how do we deliver the resultant data?
5. Are there any conversions that are expected?
The SE Core has also developed an extensive document that outlines the source data investigated for use5. The reference document lists over 160 different types of data that are currently investigated for use in building an SE Core database. The principle data types that SE Core uses include:
1. Imagery: CIB, Buckeye, and Quickbird
2. Vector: VMAP, Urban Tactical Planner, NAVTEQ, DAFIF, and Shape Files
3. Elevation: DTED, LIDAR
4. Models: Site Photos, Building diagrams, CAD
Once the five questions have been answered and the source data identified and collected, SE Core is now ready to start processing of the data to include refining and enhancement. However, before this discussion is presented, a brief discussion of source data standardization will be presented.
5. Standards
All data is spatially partitioned based on MIL-PRF-89041A6. The imagery is stored based on the US NGA CIB format. For consistency, the vectors are also partitioned based on the CIB schema with one important difference; they are not chopped to the tiles, but references the groups of features to the CIB tiles they intersect. All data is stored in latitude/longitude using the WGS-84 reference datum. If source data uses a different coordinate system or reference datum, the SEDRIS developed ISO/IEC 18026 – Spatial Reference Model7 is used for coordinate conversion or datum transformation.
Data element also have metadata attached. Currently, the metadata includes such information as the user that inserted the data into the database, notes on why the data was populated, and the origin of the data. SE Core will be expanding the level and type of metadata in the coming year.
The SE Core data model is based on the SEDRIS ISO/IEC 18023-1 Data Representation Model (DRM)8 and all data concepts are defined by the SEDRIS ISO/IEC 18025 Environmental Data Coding Specification (EDCS).9
Along with the above standards, the SE Core program is in compliance with the US NGA standards that are developed by ISO Technical Committee (TC) 211.
Regional information is stored as areal features with the attribution that defines the region. For example, a feature for a given area has the attribution that defines possible textures that can be applied to models within the spatial extent of that region. In addition, regions can be stacked with a priority based on user needs.
There are several tools that are used to certify the data is ready for use. These tools check for invalid and null geometry and attribution. Plus, the tools check for compliance to the SE Core standards for geometry, spatial referencing, definition, labelling, etc. There will be a complete section on the SE Core quality process and where in the SE Core process checks are performed to make sure the user request has been met.
6. Data Refinement and Enhancement
A database, while required for a specified purpose or training event in totality, oftentimes contains certain areas in it that are more essential than others for that particular use. Therefore, SE Core has developed a stratification of “zone” that help both the user and SE Core to focus resources in those areas that are required by the customer to have greater attribution, while developing the full database.
There are five separate zones that are based on map projections (e.g. 1:250, 1:100). The zones contain the level of fidelity that the map projection would have, but in some cases there is more information added based on the requirements that must be met. The additional information could be based on: