I. Abstract
The CDB standard defines a standardized model and structure for a single, “versionable”, virtual representation of the earth. A CDB structured data store provides for a geospatial content and model definition repository that is plug-and-play interoperable between database authoring workstations. Moreover, a CDB structured data store can be used as a common online (or runtime) repository from which various simulator client-devices can simultaneously retrieve and modify, in real-time, relevant information to perform their respective runtime simulation tasks. In this case, a CDB is plug-and-play interoperable between CDB-compliant simulators. A CDB can be readily used by existing simulation client-devices (legacy Image Generators, Radar simulator, Computer Generated Forces, etc.) through a data publishing process that is performed on-demand in real-time.
The application of CDB to future simulation architectures will significantly reduce runtime-source level and algorithmic correlation errors, while reducing development, update and configuration management timelines. With the addition of the High Level Architecture — -Federation Object Model (HLA/FOM)1 and DIS protocols, the application of the CDB standard provides a Common Environment to which inter-connected simulators share a common view of the simulated environment.
The CDB standard defines an open format for the storage, access and modification of a synthetic environment database. A synthetic environment is a computer simulation that represents activities at a high level of realism, from simulation of theaters of war to factories and manufacturing processes. These environments may be created within a single computer or a vast distributed network connected by local and wide area networks and augmented by super-realistic special effects and accurate behavioral models. SE allows visualization of and immersion into the environment being simulated2.
This standard defines the organization and storage structure of a worldwide synthetic representation of the earth as well as the conventions necessary to support all of the subsystems of a full-mission simulator. The standard makes use of several commercial and simulation data formats endorsed by leaders of the database tools industry. A series of associated OGC Best Practice documents define rules and guidelines for data representation of real world features.
The CDB synthetic environment is a representation of the natural environment including external features such as man-made structures and systems. A CDB data store can include terrain relief, terrain imagery, three-dimensional (3D) models of natural and manmade cultural features, 3D models of dynamic vehicles, the ocean surface, and the ocean bottom, including features (both natural and man-made) on the ocean floor. In addition, the data store can includes the specific attributes of the synthetic environment data as well as their relationships.
The associated CDB Standard Best Practice documents provide a description of a data schema for Synthetic Environmental information (i.e. it merely describes data) for use in simulation. The CDB Standard provides a rigorous definition of the semantic meaning for each dataset, each attribute and establishes the structure/organization of that data as a schema comprised of a folder hierarchy and files with internal (industry-standard) formats.
A CDB conformant data store contains datasets organized in layers, tiles and levels-of-detail. Together, these datasets represent the features of a synthetic environment for the purposes of distributed simulation applications. The organization of the synthetic environmental data in a CDB compliant data store is specifically tailored for real-time applications.
II. Keywords
The following are keywords to be used by search engines and document catalogues.
ogcdoc, OGC document, CDB, Common Data Base, simulation, synthetic environment, virtual, primer, data store
III. Security considerations
No security considerations have been made for this document.
IV. Submitting Organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
- CAE Inc.
- Carl Reed, OGC Individual Member
- Envitia, Ltd
- Glen Johnson, OGC Individual Member
- KaDSci, LLC
- Laval University
- Open Site Plan
- University of Calgary
- UK Met Office
V. Submitters
All questions regarding this submission should be directed to the editor or the submitters:
| Name | Affiliation |
|---|---|
| Carl Reed | Carl Reed & Associates |
| David Graham | CAE Inc. |
VI. Preface and Patent Call
The initial CDB specification was developed under a competitive contract awarded to CAE to meet requirements of the United States Special Operations Command.
The CDB standard is widely implemented by multiple, independent industry contractors for end-user simulation and mission rehearsal customers in many different countries over a period of ten years.
The industry-maintained CDB model and data store structure has been discussed and demonstrated at OGC Technical Committee meetings beginning in September, 2013.
At the suggestion of several attendees at the first CDB ad-hoc meeting in September, 2014, the current version of the existing CDB standard was slightly reformatted for consideration as an OGC Best Practice. The OGC Best Practice is the basis of work for this OGC standard.
VII. Relationship with other OGC standards
The OGC CDB standard is based on and derived from an industry developed and maintained specification, which has been approved and published as OGC Document 15- 003: OGC Common Data Base Volume 1 Main Body. An extensive listing of contributors to the legacy industry-led CDB specification is at Chapter 11, pp 475-476 in that OGC Best Practices Document (https://portal.opengeospatial.org/files/?artifact_id=61935).
Volume 0: Primer for the OGC CDB Standard: Model and Physical Data Store Structure
1. Conformance
Not applicable for this Best Practice document.
2. Terms, definitions and abbreviated terms
No terms and definitions are listed in this document.
A complete glossary of Terms and Definitions used in this standard are contained in OGC CDB Volume 3. The following description of a synthetic environment is provided as context for this Primer.
The synthetic environment is a representation of the natural environment at a specific geographical location including the external features of the man-made structures and systems. Therefore, the synthetic environment includes the terrain, the terrain features (both natural and manmade), three-dimensional (3D) models of vehicles, the ocean surface, and the ocean bottom, including features (both natural and man-made) on the ocean floor. In addition, the synthetic environment includes the specific attributes of the synthetic environment data as well as their relationships. The CDB Standard is more than just a means of creating visual (aka out-the-window) scenery. Unlike other simulation industry standards that only deal with data representational types of polygons, colors, and textures, CDB deals with all the data types needed in high-end virtual and constructive simulation applications.
2.1. Abbreviated terms
- CGF
Computer Generated Forced
- DB
Database
- DBGF
Database Generation Facility [IEEE std 1516]
- DIS
Distributed Interactive Simulation [IEEE std 1278]
- IG
Image Generator
- LOS
Line of Sight
- NVG
Night Vision Googles
- OTW
Out the Window
- RTP
Runtime Publisher
3. What is a CDB Conformant Data Store?
A CDB3 conformant data store provides a representation of the whole earth optimized for very high speed access and visualization. The physical data store model divides the earth geographically into geodetic tiles. Each tile is defined by a latitude/longitude boundary. Each tile contains one or more specific sets of features. The CDB model uses the WGS-84 coordinate reference system (CRS). Details of the model along with implementation requirements are provided in Volume 1: OGC CDB Core [16-113r3]. Any simulator client-devices access CDB geospatial content using a WGS-84 CRS based indexing and tiling scheme. The physical and logical tiling system specified in the CDB standard is similar to an equal area implementation of a Discrete Global Grid System (DGGS)4. However, the implementation predates the OGC DGGS standards work and as such does not implement all the OGC DGGS requirements.
A CDB data store contains the features and modeled representation of the synthetic environment. A CDB data store can contain:
terrain altimetry,
planimetry,
raster imagery,
attribution,
3D features with their modeled geometry,
texture and attribution.
This standard also makes provision for the representation of moving models. An example of a moving model is a tank moving across the terrain as viewed by a helicopter pilot. The representation of moving models is comprehensive and goes well beyond other visualization standards because it makes provisions for the standardized naming conventions, material and feature attribution, radar/laser reflectivity, aircraft and airport lighting systems, armaments, special effects, collision points/volumes just to name a few. These provisions ensure interoperable simulation applications that are accessing a CDB structured data store.
The CDB standard governs all requirements of the CDB data store, as follows:
Data content and representation of the synthetic environment;
Structure and organization of the synthetic environment; and
File format of the synthetic environment as stored on media.
The CDB standard describes a modeled environment representation for distributed simulation applications. Clause 5.10.5 of this document, “Use of CDB in Applications Requiring Dynamic Synthetic Environments”, discusses how a CDB-compliant simulator could be adapted to handle modifications of the synthetic environment in real-time.
Given that a CDB data store defines a structured storage structure for representation and attribution of terrain, geographic objects, moving objects and entities, it is possible to design a broad range of synthetic environment simulations that modify synthetic environments in real-time. Such simulations can modify the CDB data store and then notify other systems in a simulation federate5 that share a CDB data store about the changes. This provides a synthetic environment (SE) that is persistent and fully correlated across all simulation federates. For example, terrain “trafficability” could be handled by a new SE simulation that dynamically calculates soil moisture content as a function of localized rain precipitation and soil types/composition. A second simulation would then derive the resulting soil physics and determine vehicle wheel slippage across the varying terrain conditions.
The modification/notification approach is well-suited for a broad gamut of simulations. However, some simulations are very data intensive and require excessive broadcasting bandwidths to other federates. In such cases, these dynamic simulations would have to be replicated in the other client-devices of the federation. Good examples of this are visual system special effects (e.g., rotor downwash effect, missile plumes, muzzle flashes, cast landing lights). Typically such simulations are proprietary and intrinsic to the client-devices. Other examples of this include the varying effects of weather6 (local winds, temperature, humidity, particulates, etc.) and oceans (currents, temperature, etc.).
For ease of editing and review, the standard has been separated into 12 Volumes and a schema repository.
Volume 0: OGC CDB Companion Primer for the CDB standard. (Best Practice)
Volume 1: OGC CDB Core Standard: Model and Physical Data Store Structure. The main body (core) of the CBD standard (Normative).
Volume 2: OGC CDB Core Model and Physical Structure Annexes (Best Practice).
Volume 3: OGC CDB Terms and Definitions (Normative).
Volume 4: OGC CDB Use of Shapefiles for Vector Data Storage (Best Practice).
Volume 5: OGC CDB Radar Cross Section (RCS) Models (Best Practice).
Volume 6: OGC CDB Rules for Encoding Data using OpenFlight (Best Practice).
Volume 7: OGC CDB Data Model Guidance (Best Practice).
Volume 8: OGC CDB Spatial Reference System Guidance (Best Practice).
Volume 9: OGC CDB Schema Package: provides the normative schemas for key features types required in the synthetic modelling environment. Essentially, these schemas are designed to enable semantic interoperability within the simulation context. (Normative)
Volume 10: OGC CDB Implementation Guidance (Best Practice).
Volume 11: OGC CDB Core Standard Conceptual Model (Normative)
Volume 12: OGC CDB Navaids Attribution and Navaids Attribution Enumeration Values (Best Practice)
4. Using OGC standards with a CDB structured data store7
The U.S. Department of Defense (DoD) developed the Joint Training Data Services (JTDS) to support rapid scenario generation for the U.S. DoD M&S training community. The recently developed (2014) and deployed JTDS Common Terrain Generation Service (C-TGS) is a cloud-based service for the war fighter. C-TGS provides a robust capability to search, discover and retrieve Modeling and Simulation (M&S) terrain data. JTDS based the CB-TGS standard data structure on OGC-approved formats served by OGC Web Services. The goal for the Terrain Generation Service (TGS): Eliminate the current paradigm where every simulation uses a different proprietary format. Current data efforts are fraught with simulation issues and errors, and data mining, correlation and processing to support multiple simulation formats is manpower intensive.
The TGS Solution: Have a repository and user interface that provides access to a single source of data through a persistent web service AND set and enforce a standard data structure based on industry standard Open Geospatial Consortium (OGC) approved formats, to normalize terrain data across Force Development simulations.
Figure 1 — DoD C-TGS Architecture (Chambers and Sherman, 2014)
The above figure represents the implementation architecture for CB-TGS. Implementation software represents a mix of commercial/proprietary and open source. At the heart of the C-TGS are two data stores: A CDB structured data store and a 3d model data store. All applications at the Visualization and Dissemination level interface the data stores via OGC service interfaces.
Connecting OGC Web Services to an open, simulation-optimized terrain data store, such as a CDB structured data store, results in high-end performance for serving and rendering geospatial content, the ability to dynamically modify terrain and support for all levels of simulation. a high-end simulation system using CDB can dynamically update the terrain (such as a bomb crater) and have that dynamically updated terrain instantly served by the Geospatial Discovery Service to any OGC compliant system, such as Esri® ArcMap, QGIS, or a mobile web page. The underlying architecture and framework of the C-TGS provide a mechanism to move high-end simulation to the point where data sharing, crowd-sourcing, and dynamic terrain are in-sync with GIS tools and simulation system edits of the terrain repository.
5. Background and informative material
5.1. Intended Audience
The primary audience for the CDB standard includes distributed simulation system developers and synthetic environment database tool developers whose applications are intended to read and/or write synthetic environment database files. To this end, this document discusses concepts incorporated in the standard and contains a detailed description of the physical layout of the files as represented on disk.
5.2. Problem Definition
Complex mission simulators include a wide range of subsystems designed to simulate onboard equipment and to provide a rich gaming environment complete with weather, computer generated forces, ordnance, air traffic, networked players, etc. Each of these subsystems traditionally utilizes a proprietary runtime database (and format) for its synthetic representation of the gaming area. These application-specific formats have been generated off-line at a database generation facility using a variety of tools and processes. This traditional approach to simulation has several inherent disadvantages, including length of time needed for synthetic environment production for multiple simulation applications, loss of correlation due to compilation differences, complexity in configuration management, and an inefficient update process. The abundance of distinct database formats creates several challenges for configuration management, resulting in mismatched correlations, and in the increased timeline needed to generate these databases. The CDB Standard specifies an approach that establishes conventions for all simulator client subsystems (aka simulator client-devices). Further, the CDB Best Practices provide detailed guidance on how to use a set of industry-standard formats.
The confluence of digital multispectral high-resolution satellite imagery, real time sensor feeds, and highly capable visual systems has created dramatic new Mission Planning and Mission Rehearsal capabilities. As a result, recent environment databases built to take advantage of these new capabilities require orders of magnitude more storage than equivalent databases just a few years ago.
The CDB standard addresses these requirements through a common database model. CDB is intended as a standard for use in producing a highly performant, unified synthetic representation of the world. A data store built to the CDB Standard is referred to as a CDB structured data store or CDB conformant data store. A CDB structured data store is a single-copy data repository from which various simulator client-devices are able to simultaneously retrieve, in real-time, relevant information to perform their respective runtime simulation tasks.
The CDB standard enhances unity and correlation between various simulator level clientdevices (e.g., Visual, Radar), while improving maintainability. As a result, one of the main benefits of the CDB standard is the elimination of several types of correlation errors attributable to alternate, sometimes conflicting data representations required by each the simulator client-devices. The CDB standard achieves this by allowing all simulator clients-devices to share, in runtime, a single repository of the synthetic environment information. In addition, a CDB structured data store can also be used as a master repository for the authoring tools. As a result CDB content can be interchanged between data store workstations. Finally, in the case where one or more of the client-devices are not compliant to the CDB standard, it is possible to revert to the conventional compilation paradigm, (i.e., compile the CDB into one or more client-device loadable (usually proprietary) representations).
The actual storage formats of geospatial and model data in a CDB data store is based on the native formats, such as TIFF, used by industry-standard toolsets. This eliminates the time-consuming off-line database compilation process for each of the clients. The CDB standard redefines a new balance between offline and online compilation processes because modern computer platforms can now accomplish most of the compilation process in real-time8.
The CDB standard addresses the issues that have characterized the simulation industry for past decades (see Figure 2: CDB Approach to Synthetic Environment Generation), as follows.
Size of Synthetic Environment Storage: The CDB standard specifies how to consolidate the synthetic environment into a single data repository that provides a static representation of the earth. This includes all the relevant information so that all the simulator client-devices can perform their respective simulation tasks in order to meet the training and mission rehearsal requirements. This approach avoids any data content duplication. Storage intensive datasets can be optionally compressed using modern third-party algorithms. The CDB standard provides a fine-grained versioning scheme that avoids the replication of the entire DB when effecting small-area updates.
Scalability of Synthetic Environment Database: A CDB structured data store can be built to a size or a density that far exceeds the capabilities of some or all of its client-devices. The data structure defined by the CDB standard makes it possible to implement runtime filtering schemes to adjust the loaded content density to the specific capabilities of the client-devices. As a result, a CDB structured data store can be scaled to take advantage of future simulator technological improvements.
Environment Data Store (DB) Correlation: Since CDB structured content is unique (without data duplication), runtime source level correlation errors among clients are eliminated, thereby ensuring inter-subsystem coherence and simulator interoperability. In addition, it is possible to improve correlation by adjusting the runtime publishing process associated with each client-device.
Database Availability Timeline: The CDB data store generation process allows for small incremental updates, thereby shortening generation and build process times. Furthermore, the translation step into a CDB structured data store is rather straightforward since the industry-standard formats and encodings are used.
Configuration Management: Configuration management effort is reduced, because a single CDB structured data store corresponds to the synthetic environment of all the client-devices in the simulator. Furthermore, while a CDB data store instance is conceptually a single, yet layered entity, the standard specifies how incremental updates are performed resulting in efficient storage and handling of CDB data store versions.
Figure 2 — CDB Approach to Synthetic Environment Generation
5.3. Use of a CDB conformant data store as an Off-line Data store Repository
CDB can be used as a structured offline repository. This capability is described in Section 6.2 Volume 10 Implementation Guidance.
5.4. Use of a CDB conformant data store as a Combined Off-line and Run-time Data store Repository
A data store conforming to this CDB standard can be both used an offline repository for data store authoring tools or as an on-line (or runtime) repository for simulators. This approach is described in Volume 10 Implementation Guidance, section 6.4.
5.5. Client-Device Independence
The CDB standard is client-device independent. The standard is based on a requirement that all client-devices likely encountered on a tactical mission simulator need to be supported. The standard is completely independent of any vendor-specific devices.
5.6. Runtime Publisher
The runtime publishers provide the necessary level of abstraction. The level of abstraction provided by the publishers is purely a function of the selected implementation of the client-device and its associated publishers. A client-device can “understand” and be completely “aware” of a CDB compliant data store as defined by the CDB standard. In this case, such a device would not require a runtime publisher, because it is already CDB data store native.
The runtime publishers bridge the gap between the information content requested by the attached client-device and the information content and structure available to them in a CDB conformant data store. As a result, the runtime publishers must each be theoretically “aware” of the following CDB concepts:
Tile: Ability to understand the concept of earth surface areas hierarchically subdivided in accordance to the CDB standard;
Level of detail: Ability to understand the concept of resolution or level-of-detail, for terrain, cultural vector data, raster imagery, and model geometry;
Terrain surface representation: Ability to understand concepts pertinent to earth surface geometry and related attributes or properties;
Cultural vector data (point, linear, areal): Ability to understand the concept of point, linear and areal cultural data and related attribution, fixed or conformed to earth surface;
Grid-organized data and meshes: Ability to understand the concept of grid-organized single-value datasets (e.g., elevation grid) and multi-value datasets (e.g., color triplets);
Imagery: Ability to understand the concept of color raster imagery mapped onto terrain surfaces or models;
Model geometry (incl. light points): Ability to understand the concept of general surface geometry;
Model positioning capability: Ability to differentiate between statically and dynamically positioned models;
Descriptive attribution: Ability to understand the attribution concepts pertinent to the client-device.
5.7. Synthetic Environment Scalability & Adaptability
The concept of scalability when applied to synthetic environments not only applies to the geographic extent of the data store but more importantly it also reflects the ability to scale the environment in resolution and fidelity. These concepts are fully supported by the CDB Standard and are explained below.
Geographic extent: Correspond to the range of geographic extent of the earth surface that can be modeled.
Resolution: Correspond to the range of information density (for instance, the number of elevation values per km2) of the modeled datasets.
Fidelity: Correspond to the amount and type of synthetic environment data that can be modeled to support higher-fidelity simulator client-devices9. Consider for instance a simulator capable of supporting a single-surface earth skin representation versus one capable of representing tunnels, bathymetric data, location-dependent tide heights, location-dependent wave heights, etc. Clearly, the amount of information required by the higher-fidelity simulator is greater.
Precision: Correspond to the range of numerical precision (i.e., number of bit allocated to represent a quantity) of the modeled datasets.
Modelers face difficult challenges if they want a synthetic environment that is both scalable and adaptive. The solution to this difficult issue extends beyond the “mechanics” of achieving backward/forward compatibility. The solution also requires a complete “dissociation” of the data store from any constraints imposed by client-devices. Current practice today is for modelers to repeatedly adjust the content, resolution and density of synthetic environment databases to closely match the capabilities and performance of the targeted client-devices. When content is added to the database, previously modeled content is usually removed or simplified. Under such constraints it is difficult for a modeler to build a synthetic environment database capable of meeting anything but its immediate requirements.
Figure 3: Typical Evolution of a Database shows the evolution of a modeled region for use in a mission rehearsal. The initial version of the region may have only a few highresolution/high-fidelity areas. However, over a given time period modelers will be asked to model additional target areas. As a result, the size, complexity, resolution and fidelity of the synthetic environment database gradually increase. Without built-in provisions for scalability, significant rework of the database is required each time a target area is added.
Figure 3 — Typical Evolution of a Database
The CDB standard allows the “dissociation” of the synthetic environment database’s extent, resolution, fidelity, precision, structure and format from client-devices. This concept is not limited to aspects of formatting, numerical representation, internal structure, file structure, file systems, etc. More importantly the concept also covers aspects relating to synthetic environment database fidelity and resolution. Historically, the fidelity and resolution of synthetic environment databases has been intimately linked to the capabilities of the targeted simulator client-devices. More often than not, the source data was manipulated and adapted to constraints imposed by the client-devices. As a result, the content, resolution and density of synthetic environment databases were repeatedly adjusted to closely match the capabilities and performance of the targeted client-devices. The amount of time devoted to repeatedly adding/editing/removing content, and then repeatedly re-publishing would largely exceed the effort of creating and building the original synthetic environment database. The CDB standard offers the means to break this inter-dependence.
When assembling a CDB conformant data store, the synthetic environment database modeler is permitted (within their time-cost budget) to include content that significantly exceeds the capabilities of their simulator(s). The job of “adjusting” content to clientdevices is relegated to the runtime publishers; the modeler is freed from this laborintensive, repetitive task.
In a typical CDB data store implementation, it is anticipated that client-devices will independently control their respective runtime publishers so that the runtime published synthetic environment corresponds to their inherent capabilities (resolution, fidelity, etc.).
Nonetheless, the runtime publishing paradigm offers interesting new possibilities. For instance, it would be possible to individually adjust the fidelity and resolution of the synthetic environment for each client-device; this adjustment could be done at any time. As a result, it is possible to control and adjust the overall simulator fidelity and correlation to a level that was previously unachievable.
The CDB standard does not enforce a particular computer hardware infrastructure. The selected infrastructure allocated to the handling of a CDB data store is largely determined by the overall simulation requirements. Any leeway the simulator architect may have at their disposal when trading-off various simulator performance parameters against each other, are as follows:
Geographic extent
SE/Simulator Resolution
SE/Simulator Fidelity
SE/Simulator Precision
Desired level of client-devices correlation
Client-level SE load management
Simulated aircraft speed
CDB sharing
An experienced simulation engineer can typically undertake this analysis. However, the process requires a good understanding of the content available in the targeted CDB structured databases and of the content each client-device needs in order to meet the stated level of performance and fidelity.
Alternately, it is possible to implement a simulator with client-devices (or attached publishers) that are capable of automatically adjusting resolution and fidelity in order to overcome performance limitations attributable to the CDB storage infrastructure and/or runtime publishers.
Figure 4: Typical Implementation of the CDB standard on High-end Simulator provides a system block diagram of a typical implementation of the CDB standard on a high-end tactical flight simulator. The runtime CDB system serves the combined needs of a mission functions computer, an OTW/NVG IG, a Forward Looking Infrared (FLIR) IG, Radar and a Computer Generated Forces (CGF) subsystem equipped with its own terrain server. The runtime CDB data store system is scaled to reflect the collective capabilities of the attached client-devices; as a result, the storage system is configured to supply the necessary bandwidth. Similarly, the IO bandwidth of the CDB data store servers and processing performance of the runtime publishers are scaled to satisfy the demands of their respective client-devices.
Figure 4 — Typical Implementation of CDB Standard on High-end Simulator
Figure 5: Typical Implementation of CDB Standard on Desktop Computer shows a modest application of the CDB standard. This approach consists of a single desktop computer equipped with both stealth viewer and radar simulation application software. Each application is front-ended by a runtime publisher that in turn interfaces to the CDB data store via a standard file system. Given the more modest platform resources, some trade-offs in either resolution or fidelity might be required. This can be implemented in the runtime publisher or in the client-device application software.
Figure 5 — Typical Implementation of CDB Standard on Desktop Computer
5.8. Simulator Wide Unique Data Representation
A CDB data store is a single repository for the entire simulator’s synthetic environment data store (aka DB). The internal structure ensures that all datasets are uniquely represented yet available (through a publishing process) to each of the simulator clientdevices at runtime. This paradigm eliminates the extensive duplication of datasets that are shared by two or more client-devices.
The CDB standard is technically a normalized data storage model in the sense that it best meets the logical data design objectives of correctness, consistency, simplicity, nonredundancy and stability. Ignoring any tailoring or tuning for particular application requirements or performance, a normalized design provides the following advantages.
Minimize amount of space required to store data: Normalization precludes storing data items in multiple places.
Minimize risk of data inconsistencies within the data store: Since datasets are stored in only one place, there is no risk of datasets becoming inconsistent (uncorrelated).
Minimize possible update and delete anomalies: A normalized CDB data store eliminates the concerns related to update or delete operations.
Maximize the stability of the data structure: The process of normalization helps in associating attributes with entities based on the inherent properties of the data rather than on particular application requirements. Thus, new application requirements are less likely to force changes to the CDB model/data store design.
5.9. Key Benefits of the CDB Standard
The following outline the key benefits of using the CDB standard.
5.9.1. Improved Synthetic environment Data Store10 (DB) Generation Timeline
Important reductions in both the DB generation and DB update timeline are expected from an implementation of the CDB standard because of the following.
There is no need to compile distinct synthetic environment runtime data stores for each of the simulator client-devices.
All of the datasets common to two or more client-devices need not be duplicated. All associated client-specific structures are also eliminated.
Tiles and layers are technically independent from each other; as a result, there is no need to reprocess neighboring tiles and coincident layers. However, one exception to this relates to the level-of-detail generation.
The tile structure permits users to “pipeline” or overlap the DB creation/update process, see Figure 5: Pipelined DB Update Process, with DB transfer process11.
Figure 6 — Pipelined DB Update Process
The tile structure lends itself naturally to the concurrent or “parallel” production of the CDB data store.
The internal versioning mechanism lends itself well to CDB structured data store updates because only the affected tiles or layers need be retransmitted to the simulator. This represents a significant timesaving, especially in cases where small updates are constantly applied to a comparatively large CDB structured data store.
The conversion of the synthetic environment from its tool-native representation into a form directly entered by each of the simulator clientdevices is broken down into several publications accomplished in realtime on behalf of each of client-device. This approach permits the CDB standard representation of the synthetic environment to be “dissociated” from the resolution, fidelity, precision, structure and format imposed by each client-devices.
5.9.2. Interoperable Simulation-Ready Synthetic environment Data Store
A CDB compliant data store is a fully interoperable, simulator-ready synthetic environment DB, (i.e., it can be used “as-is” on any CDB-compliant simulator). Because the data store is free of any simulator dependencies, there is no need to undertake a timeconsuming and expensive rework of the runtime data store(s) in order to adapt it (them) to the format, structure, content, and precision constraints imposed by the simulator.
5.9.3. Improved Client-device Robustness/Determinism
The CDB standard tile organization provides the means to implement deterministic loading and/or paging of the data store because each tile corresponds to the same amount of data (i.e., a “quanta” of information called a LOD-tile), regardless of its position on earth and regardless of its assigned LOD. This is a key characteristic of the CDB standard and is necessary to ensure deterministic operation of client-devices, even when the data resolution varies considerably from region to region or when the data is modeled at an extremely high-resolution. It is quite straightforward for a client-device to determine the amount of memory it must locally allocate when loading (or paging-in) a geographical area of interest. If the geographical area of interest exceeds the clientdevice’s capabilities, it can easily revert to a coarser LOD, hence gracefully degrading, as opposed to aborting (due to an internal failure in allocating sufficient memory) or “skipping” over the offending area.
The tile organization lends itself to robust, deterministic management of memory within client-devices because memory can be allocated/de-allocated in fixed sized quantities. As a result, client-devices need not concern themselves with complex and nondeterministic memory de-fragmentation schemes that do not lend themselves to real-time applications.
5.9.4. Runtime-Adjustable Synthetic Environment DB Correlation and Fidelity
The CDB standard plays a critical role in improving the internal correlation of a synthetic environment because it eliminates the replication of runtime data stores for each of the client-devices. The prior art in simulation mandated replicated copies of the synthetic environment data store. Each copy was constrained by the content, formats, and structures specific to each client-device. As a result, the potential for correlation errors abounded. The CDB standard resolves this issue by defining a single, usable in real-time, open, synthetic environment data store representation.
The “runtime publishing” paradigm now permits the simulator vendor the means to not only control client-device load but to globally re-examine and control the level of correlation within a simulator (or across simulators). While the CDB standard does not provide explicit jurisdiction over the implementation of this mechanism in the clientdevices and/or publishers, it is nonetheless possible to improve parametric correlation, at runtime, via control of the client-devices/publishers.
This topic is discussed in more detail in the OGC CDB Best Practice, Volume 1 Section 1.6.6 , Synthetic Environment Database Correlation.
5.9.5. Increased Synthetic Environment Data Store Longevity
The longevity of synthetic environment databases for use in simulation has traditionally been a source of considerable aggravation within the user-community.
Traditionally a considerable level of effort (both human and machine) was required to adapt source-level data to a form that is directly usable by each of the simulator clientdevices, also known as the runtime-level vendor-specific database format; this is referred to as the “compilation” process. More often than not, the source data is manipulated and adapted to constraints imposed by one or more simulator client-devices. In most cases, the content, resolution and density of synthetic environment databases are repeatedly adjusted to closely match the capabilities and performance of the targeted client-devices. While it is true that the native tool format database remains independent of the targeted client-devices, it is clear that content of the source-level database roughly corresponds to the capabilities of the then-current client-devices. As a result, source-level databases become quickly outdated and do require a complete rebuild to take advantage of new simulator capabilities.
The CDB standard avoids these pitfalls because the model does not need to be adapted to the constraints imposed by simulator client-devices; that role is relegated to the runtime publishers. Hence, the synthetic environment a CDB data store can be built, right from the start, to a level of fidelity commensurate with the anticipated useful life of the targeted simulator(s).
5.9.6. Reduced Synthetic Environment Data Store Storage Infrastructure Cost
For equivalent synthetic environment content, the CDB standard offers a significant storage space savings and significant reductions in the required interconnect infrastructure to supply the synthetic environment data to the simulator(s).
The reduction in equipment and labor can be attributed to the following features.
Simulator-wide unique data representation: eliminate duplication of datasets across client-devices.
Compression of storage-intensive datasets: provides effective compression of key datasets.
Fine-grain versioning: A CDB structured data store is internally versioned. It is possible to revert to prior representations of the SE without restoring stored back-ups of the data store. Because the underlying mechanism is fine-grained, only in affected geographic areas or datasets of the data store need to be versioned.
5.10. CDB Model Overview
The following sections provide a general description and focus of the CDB standard.
5.10.1. CDB Standard Data Representation and Organization
The CDB standard provides the means of describing all feature sets relevant to simulation (such as terrain and 3D objects). These feature sets are logical re-groupings of datasets that are used directly by the simulator client-devices.
The standard currently supports the following representations.
Terrain: A representation of the terrain shape/elevation, raster imagery, surface attribution and other surface characteristics relevant to distributed simulations.
Point feature: A representation of a single location in space or on the earth’s surface. A Point feature consists of a single <latitude, longitude> coordinate with or without an elevation. When a point feature does not have an elevation, it is deemed to be on the surface of the earth. The information includes point-feature type identification, location, orientation, connectivity, attribution and other characteristics relevant to simulation.
Linear feature (aka LineString): A representation of predominantly man-made multisegmented line-oriented features conformed relative to the terrain (such as runways, roads, transmission lines, fences). The information includes linear feature type identification, location, orientation, lineal geometry, connectivity, attribution and other surface characteristics relevant to simulation.
Areal feature (aka Polygon or area): A representation of closed area features conformed relative to the terrain such as forested areas and fields. The information includes areal feature type identification, location, orientation, 2D geometry, connectivity, attribution and other surface characteristics relevant to simulation.
3D cultural model (aka Built Environment): Is a model that is statically positioned on the terrain or bathymetry skin. Cultural models are often a 3D representation of a man-made or a natural object positioned and conformed relative to the terrain. The information includes its geometry, articulations, raster imagery (texture, normal map, light map, etc.), lighting systems, and other characteristics relevant to simulation.
Moving model: A model that is not fixed at one location in the synthetic environment data store. The simulation host can update the position and orientation of a moving model at every simulation iteration cycle. A moving model is a 3D representation of man-made objects free to move within the data store. The information includes feature type identification, (vehicle class, type, model, etc.), geometry, articulations, raster imagery (texture, normal map, light map, etc.), lighting systems, connectivity to special effects, attribution and other characteristics relevant to simulation
Materials: A symbolic representation of the surface materials for all of the elements contained within the data store. Client-devices are required to simulate the synthetic environment over different portions of the electromagnetic spectrum: IR (e.g., FLIR, NVG), microwaves (e.g., Radar), audio (e.g., Sonar), etc. The fidelity of the sensor synthetic environment simulation model that runs in each of the client-devices is highly dependent on the richness and completeness of properties that characterize the synthetic environment data store in the electromagnetic spectrum of interest12.
Navigational data: A representation of ARINC-42413 and DAFIF14 data in the form of NAVAIDs, Airport/Heliport, Runway/Helipad, Waypoints, Routes, Holding Patterns, Airways, Airspace, etc.
In order to represent the above feature sets, the CDB standard logically organizes its data in mutually exclusive datasets. Furthermore, the CDB standard is platform and clientdevice independent. As a result, the internal data representation is free of client-device specifics and more closely aligned to DB structures/formats supported by prominent industry standard tools.
5.10.2. CDB Standard Logical Structure
The CDB standard is a structure for simulation and as such its storage structure is optimized for simulator client-devices runtime performance. Therefore, the internal storage structure is designed with these specific considerations in mind.
Promotes efficient real-time data access by the simulator client-devices without degrading their performance.
Allows simultaneous accesses by all of the various simulator client-devices.
Promotes efficient data store updates and deployment in order to reduce the deployment of a CDB structured data store onto one or more simulators.
To address these objectives, the storage structure geographically divides the world into tiles (bounded by latitudes and longitudes), each containing a specific set of features (such as terrain altimetry, vectors), models, which in turn are represented by the datasets (see Figure 7: CDB Standard Tile/Layer Structure). The datasets define the basic storage unit used in a CDB structured data store. The geographic granularity is at the tile level while the information granularity is at the dataset level. As a result, the storage structure permits flexible and efficient updates due to the different levels of granularity with which the information can be stored or retrieved. At the data store generation facility, it is possible to effect small updates, either at the tile level; the feature set level or the dataset level. Similarly, the storage structure fully supports real-time retrieval of content at the tile level and the dataset level. Finally, the incremental versioning mechanism allows users to efficiently deploy updates to a data store; only the files whose content differs from a prior version need be generated and transferred from the data store generation facility to the simulation facility.
Another benefit of the CDB standard storage structure is its ability to support concurrent generation and deployment.
Figure 7 — CDB Standard Tile/Layer Structure
5.10.3. Tile/Layer/Level-of-Detail Structure
The CDB standard offers a structure that is well suited for the efficient access of its contents. To this end, it relies on three important means to organize the synthetic environment data:
Tiles
Layers
Level-of-Detail (LOD)
5.10.3.1. Tiles
The CDB standard defines a top-level tile structure designed to organize the data for efficient access in real-time. The tile structure provides an effective means for simulator client-devices to access the datasets of a geographical area at a selected LOD. Since the spatial dimension of tiles varies inversely with LOD (i.e., resolution), client-devices can readily predict the amount of data contained within the tile; as a result, the management of memory within client-devices is simplified and much more deterministic.
The CDB standard Conceptual Model is logically organized as a strip of geo-unit aligned tiles along each earth slice. Each earth slice is divided into a decreasing number of tiles to account for the fact that the length of an earth slice decreases with increasing latitude.
5.10.3.2. Layers
The CDB model is also logically organized as distinct layers of information. The layers are theoretically independent from each other, (i.e., changes in one layer do not impose changes in other layers).
Layers are additive in fidelity, (i.e., the achievable level of the simulation fidelity increases with the number of layers).
Secondly, unavailable layers are automatically defaulted. A database modeler need not fully populate a CDB structured data store. There is no mandatory “coverage completeness requirement” imposed by the CDB standard. This feature permits the generation of a CDB conformant data store even when database modelers are confronted with limited data availability. The usefulness/faithfulness of the synthetic environment increases with the number of available layers.
The layering mechanism improves the efficiency of the client-devices since they need only access (and be aware) of the datasets that are relevant to them, at their prescribed level of fidelity. For instance, a simulator CGF client-device will not likely have a reason to use ground raster imagery. However, it is quite likely interested in accessing ground surface properties when determining traffic-ability.
5.10.3.3. Levels of Detail (LOD)
Level of detail (LoD) is a concept available in various disciplines from computer graphics and cartography to electrical circuit design. For GIS practitioners, the discipline where level of detail is most relevant and well known is 3D city modelling. In the CDB, LOD is a mechanism for allowing increasing levels of fidelity without impacting system performance. In CDB data stores, LODs are also an integral part of the physical database structure. The LOD requirement for simulation systems is similar with regard to requirements for increased fidelity in 3d City Models and standards such as CityGML.
The availability of LOD representations is critical to real-time performance, especially when dealing with grid-organized data. Most simulation client-devices can readily take advantage of a LOD structure because, in many cases, less detail/information is necessary at increasing distances from the simulated object. As a result, many client-devices can reduce (by 100-fold or more) the required bandwidth to access synthetic environment data in real-time.
Additionally, the availability of LODs can be readily exploited by simulator clientdevices to improve algorithmic efficiency. Devices such as Image Generators (IGs) can readily take advantage of an LOD structure because image perspective naturally reduces image detail with distance as a result of the perspective computation inherent to the IG. As a result, much less geometric detail and texture detail need be processed or considered at far range.
The spatial sampling of each successive LOD in a CDB data store follows power of two progressions. This is a prerequisite for the efficient and deterministic management of memory by all client-devices of a typical simulator.
The terrain LOD can be controlled to the tile level. Since the CDB standard specifies a variable LOD hierarchy spanning up to 34 levels, it is possible to control the allocation of LODs by area. The variable LOD hierarchy provides for efficient use of storage because the LOD hierarchy needs to be deepened only in the areas where higher resolution is desired. Figure 8: Variable Allocation of LOD, illustrates an earth strip made up of a series of tiles; some portions of the strip have been modeled with 3, 4, or 5 LODs according to the application requirements.
Figure 8 — Variable Allocation of LOD
5.10.4. CDB Structure, Organization on Media and Conventions
This CDB standard along with the CDB Best Practices describes the data content, representation, as well as the logical organization of the data stored in the data store:
The Data store structure comprises all of the data structures used to access data store content (such as file paths, Level-of-Detail (LOD), lists) to speed up access, information layering, versioning and configuration management; and
Naming Conventions: Used to describe a naming hierarchy for cultural models, moving models, lights and model components.
5.10.4.1. Other Applications of the CDB Standard
While the CDB standard was initially targeted primarily for use in Special Operations simulator applications, it is entirely suited to a broad range of other applications that make use of the same datasets; these include (and are not limited to):
Ground warfare simulation
Anti-submarine warfare
Visualization
Modeling and Simulation
Urban Planning
Natural Resource Management
Emergency Management
The implementation of the CDB standard on legacy simulator client-devices usually mandates the use of the runtime publishers. These costs are largely offset by the consolidation (and substantial reduction) of storage and associated infrastructure. In the future, it is anticipated that the runtime publishing computer infrastructure will be largely “absorbed” by higher performance client-devices that will natively process the data store without an intermediate conversion into a legacy internal format.
In applications that are less demanding than flight simulation, the CDB standard can be implemented without resorting to high-performance computer platforms. For instance, the simulator repository mass storage system (shown in Figure 8: Typical CDB Implementation on a Suite of Simulators) can be a single disk storage device. In demanding applications, the simulator repository can be implemented as a large-scale Storage Area Network (SAN). Similarly, the Update Manager IUM), the CDB server and each of the client-device runtime publishers can be implemented as software tasks within a single computer platform, or can even be migrated to software tasks running internally within the client-devices. Figure 5, Typical Implementation of CDB Standard on Desktop Computer, illustrates a desktop trainer consisting of a stealth viewer15 and radar simulations, implemented as software applications running on a single computer platform; both applications pull their synthetic environment data from a disk-resident CDB.
5.10.5. Use of CDB in Applications Requiring Dynamic Synthetic Environments
A CDB-compliant simulator already incorporates most of the architectural features required to support the handling of Dynamic Synthetic Environments (aka DSE). Figure 9, Versioning Paradigm Applied to Dynamic SE, illustrates how CDB-compliant simulator architecture can be extended to permit the runtime modification of the CDB. This can be accomplished by leveraging simulator architectures that natively adhere to the CDB data schema and to the CDB versioning capabilities.
This capability requires that the simulator be equipped with a Dynamic Synthetic Environment Generator whose interfaces conform to the CDB standard; all other elements of the simulator architecture are identical to those of a CDB-compliant simulator.
Two applications of this principle could be envisaged.
DB update from DIS: This is the so-called “Dynamic Terrain/Synthetic Environment”, where a group of confederates interoperate over a DIS network by receiving update commands that trigger runtime modification of the CDB.
DB creation/update from live data feed: Terrain areas could be created or modified on-the-fly, based on live data (such as terrain imagery or LIDAR data transmitted by a UAV) and provided instantly to the confederates.
Figure 9 — Versioning Paradigm Applied to Dynamic SE
5.10.6. Synthetic Environment Data Store Correlation
Please read section 1.6.6 of the OGC CDB 3.2 Best Practice for additional details on correlation https://portal.opengeospatial.org/files/?artifact_id=61935.
Annex A
(informative)
This table lists the documentation referenced throughout this document.
| Re | Title | Description |
|---|---|---|
| 1 | ARINC Standard 424-16 | Navigation System Data Base, Aeronautical Radio Inc., August 30, 2002. |
| 2 | ASTARS-04 CDB | Systems Requirements |
| 3 | Digital Geographic Information Exchange Standard (DIGEST), Standard V2.1 | The document can be obtained at the following address: http://www.digest.org/ |
| 4 | Enumeration and Bit Encoded Values for use with Protocols for Distributed Interactive Simulation Applications. | This is document SISO-REF-010. It accompanies IEEE Std 1278.1-1995 and can be obtained from the Simulation Interoperability Standards Organization at http://www.sisostds.org/ |
| 5 | Extensible Markup Language (XML) 1.0 (Third Edition) | Bray, Tim, et al. |
| 6 | Guide — PD6777, BSI’s Guide to the practical implementation of JPEG 2000 | The document can be found at: |
| 7 | IEEE Standard for Distributed Interactive Simulation — Application Protocols | IEEE Std 1278.1-1995 |
| 8 | JPEG 2000: Image Compression Fundamentals, Standards and Practice | Kluwer International Series in Engineering and Computer Science, Secs 642, by David S. Taubman and Michael W. Marcellin |
| 9 | MIL-STD-2411 Raster Product Format Specification | The Raster Product Format (RPF) is a standard data structure for geospatial databases composed of rectangular arrays of pixel values (e.g., in digitized maps or images) in compressed or uncompressed form. RPF defines a common format for the interchange of rasterformatted digital geospatial data among DoD Components. |
| 10 | MIL-C-89041 Controlled Image Base Specification | Controlled Image Base (CIB). This Specification provides requirements for the preparation and use of the RPF CIB data. CIB is a dataset of orthophotos, made from rectified grayscale aerial images. |
| 11 | OpenFlight Scene Description Database Standard, Version 16.0, Revision A, November 2004, Presagis Inc | The original document has been annotated by CAE to create the CDB-annotated OpenFlight Standard. |
| 12 | Product Standard for the Digital Aeronautical Flight Information File (DAFIF), Eight Edition, Doc. # PS/1FD/086 | National Imagery and Mapping Agency (NIMA), April 2003. |
| 13 | SEDRIS™ — Synthetic Environment Data Representation Interchange Specification | The Source for Synthetic environment Representation and Interchange. |
| 14 | Shapefile Technical Description — an ESRI White Paper — July 1998 | The original document has been annotated by CAE Inc to create the CDB-annotated Shapefile Technical Description. |
| 15 | The SGI Image File Format, Version 1.00, Paul Haeberli, Silicon Graphics Computer Systems | This specification can be found at: |
| 16 | TIFF rev 6.0 Adobe Developers Association, Adobe Systems Incorporated, 1585 Charleston Road and P.O. Box 7900Mountain View, CA 94039-7900 | A copy of this original standard can be found at: |
| 17 | XML Schema Part 0: Primer Second Edition | Fallside, David, Priscilla Walmsley. |
| 18 | XML Schema Part 1: Structures Second Edition | Thompson, Henry S., et al. |
| 19 | XML Schema Part 2: Datatypes Second Edition | Biron, Paul V., Ashok Malhotra. |
| 20 | ICAO Airline Designator | List of ICAO Airline Codes, |
| 21 | Radar Signatures and Relations to Radar Cross-Section. Mr. P E R Galloway, Roke Manor Research Ltd, Romsey, Hampshire, United Kingdom. | This document can be obtained at the following Internet address: |
| 22 | AN/APA to AN/APD — Equipment Listing. | This document can be obtained at the following Internet address: |
| 23 | Radar Polarimetry — Fundamentals of Remote Sensing. | This document can be obtained at the following Internet address: |
| 24 | RCS in Radar Range Calculations for Maritime Targets, by Ingo Harre. Bremen, Germany. (V2.0-20040206). | This document can be obtained at the following Internet address: |
| 25 | Decibels relative to a square meter — dBsm. By Zhao Shengyun. | This document can be obtained at the following Internet address: |
| 26 | MIL-C-89041 | Controlled Image Base (CIB) |
| 27 | MIL-STD-2411 | Defense Mapping Agency, Military Standard, Raster Product Format (RPF) |
| 28 | MIL-STD-2411-1 | Defense Mapping Agency, Registered Data Values for Raster Product Format |
| 29 | MIL-STD-2411-2 | Defense Mapping Agency, Incorporation of Raster Product Format (RPF) Data in National Imagery Transmission Format (NITF). |
| 30 | IEEE Std 1516-2000 | IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) |
| 31 | RPR-FOM Version 2 Draft 17 | Real-time Platform Reference (RPR) Federation Object Model (FOM) |
| 32 | MIL-PRF-89039 Amendment 2 | Performance Specification Vector Smart Map (VMAP Level 0), 28 September 1999 |
| 33 | MIL-PRF-89033 Amendment 1 | Performance Specification Vector Smart Map (VMAP Level 1), 27 May 1998 |
| 34 | MIL-PRF-89035A | Urban Vector Map (UVMap), 1st August, 2002 |
| 35 | OneSAF Ultra High Resolution Building (UHRB) Object Model | OneSAF UHRB Object Model (Version 2.2, Document Revision E, March 7th, 2008, Contract #: N61339-00-D-0710, Task Order: 28.) |
| 36 | OneSAF Ultra High Resolution Building (UHRB) On-Disk Format | OneSAF UHRB On-Disk Format Model (Version 2.2, Document Revision E, March 7th, 2008, Contract #: N61339-00-D-0710, Task Order: 28.) |
| 37 | U.S. Department of Transportation — Federal Aviation Administration — Advisory Circular 150/5340-1J | Standards for Airport Markings, AC- 150/5340-1J, dated 4/29/2005 |
| 38 | Federal Aviation Administration — Aeronautical Information Manual | Official Guide to Basic Flight Information and ATC Procedures, dated 14th February, 2008 |
Annex B
(informative)
Revision history
| Date | Release | Author | Paragragh | Description |
|---|---|---|---|---|
| 10/20/15 | C. Reed | Many | First major “scrub” | |
| 11/20/15 | C. Reed | Many | Prepare for first publication | |
| 2/20/2016 | D Graham and C Reed | Many | Prepare for OAB Review | |
| 4/3/2016 | D Graham | Prepare for RFC | ||
| 5/18/2016 | C. Reed | Minor edits | Figures. | |
| 10/5/2016 | 1.0 | C. Reed | Various edits | Preparation for publication as an official OGC BP |
| 11/20/2016 | 1.0 | C. Reed | Various | Edits for publication |
| 1/21/2017 | 1.0 | C. Reed | Ready for publication — add references | |
| 1/16/2018 | 1.1 | C. Reed | Various | Minor corrections to typos. |
Bibliography
[1] DIS [IEEE Std 1278]: 1278.1-2012 — IEEE Standard for Distributed Interactive Simulation--Application Protocols
[2] HLA [IEEE Std 1516]: 1516-2010 — IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) — Framework and Rules
[3] Volume 1: OGC CDB Core Standard: Model and Physical Data Store Structure.
[4] Volume 11: OGC CDB Core Standard Conceptual Model
The following informative references are applicable for this Primer.