Open Geospatial Consortium

Submission Date: 2018-03-20

Approval Date:      2018-08-27

Publication Date:      2018-12-19

External identifier of this OGC® document:

Additional Formats (informative): F+G2fvLtTjLSr4cADESA7XbHd8gco4fq2dAz0VXYYJMi2DSAeKJh+S1n4d8GPmwVvHdyvi8MNmyvuUrCagAAAABJRU5ErkJggg==

Internal reference number of this OGC® document:        15-120r5

Version: 1.1

Category: OGC® Best Practice

Editor:      Carl Reed

Volume 0: Primer for the OGC CDB Standard: Model and Physical Data Store Structure

Copyright notice

Copyright © 2018 Open Geospatial Consortium

To obtain additional rights of use, visit


This document defines an OGC Best Practices on a particular technology or approach related to an OGC standard. This document is not an OGC Standard and may not be referred to as an OGC Standard. It is subject to change without notice. However, this document is an official position of the OGC membership on this particular technology topic.

Document type:        OGC® Best Practice

Document subtype:   

Document stage:    Approved

Document language:  English

License Agreement

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.



This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

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 simulated [2].

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 man-made 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. 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.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

iv. Submitting organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

Organization name(s)

  • 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

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 (

v. Submitters

All questions regarding this submission should be directed to the editor or the submitters:



Carl Reed

Carl Reed & Associates

David Graham

CAE Inc.

1. What is a CDB Conformant Data Store?

A CDB [3] 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. The Section titled "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 federate [5] 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 weather [6] (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 CDB 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)

2. Conformance

Not applicable for this Best Practice document.

3. References

The following are the key normative references for this Primer

  • OGC 15-113r5, Volume 1: OGC CDB Core Standard: Model and Physical Data Store Structure version 1.1.

  • OGC 16-007r4, Volume 11: OGC CDB Core Standard Conceptual Model version 1.1.

The following informative references are applicable for this Primer.

  • HLA [IEEE Std 1516]: 1516-2010 - IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Framework and Rules

  • DIS [IEEE Std 1278]: 1278.1-2012 - IEEE Standard for Distributed Interactive Simulation—​Application Protocols

4. Terms and Definitions

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.

4.1. Abbreviations

  • CGF Computer Generated Forces

  • 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

5. Using OGC standards with a CDB structured data store

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 [7]. 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 C-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.


The above figure, DoD C-TGS Architecture (Chambers and Sherman, 2014), represents the implementation architecture for C-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.

6. Background and informative material

6.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.

6.2. Problem Definition

Complex mission simulators include a wide range of subsystems designed to simulate on-board 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 client-devices (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-time [8].

The CDB standard addresses the issues that have characterized the simulation industry for past decades (see Figure 1: CDB Approach to Synthetic Environment Generation), as follows.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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 1. CDB Approach to Synthetic Environment Generation

6.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 of OGC CDB v1.1 Volume 10 Implementation Guidance.

6.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 OGC CDB v1.1 Volume 10 Implementation Guidance, Section 6.4.

6.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.

6.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:

  1. Tile: Ability to understand the concept of earth surface areas hierarchically subdivided in accordance to the CDB standard;

  2. Level of detail: Ability to understand the concept of resolution or level-of-detail, for terrain, cultural vector data, raster imagery, and model geometry;

  3. Terrain surface representation: Ability to understand concepts pertinent to earth surface geometry and related attributes or properties;

  4. 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;

  5. 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);

  6. Imagery: Ability to understand the concept of color raster imagery mapped onto terrain surfaces or models;

  7. Model geometry (incl. light points): Ability to understand the concept of general surface geometry;

  8. Model positioning capability: Ability to differentiate between statically and dynamically positioned models;

  9. Descriptive attribution: Ability to understand the attribution concepts pertinent to the client-device.

6.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.

  1. Geographic extent: Correspond to the range of geographic extent of the earth surface that can be modeled.

  2. Resolution: Correspond to the range of information density (for instance, the number of elevation values per km2) of the modeled datasets.

  3. Fidelity: Correspond to the amount and type of synthetic environment data that can be modeled to support higher-fidelity simulator client-devices[multiblock footnote omitted]. 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.

  4. Precision: Correspond to the range of numerical precision (i.e., number of bits 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 2: 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 high-resolution/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 2. 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 client-devices is relegated to the runtime publishers; the modeler is freed from this labor-intensive, 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:

  1. Geographic extent

  2. SE/Simulator Resolution

  3. SE/Simulator Fidelity

  4. SE/Simulator Precision

  5. Desired level of client-devices correlation

  6. Client-level SE load management

  7. Simulated aircraft speed

  8. 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 3: 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 3. Typical Implementation of CDB Standard on High-end Simulator

Figure 4: 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.